【计算机网络详解】——运输层（学习笔记）

📖 前言：两台主机的通信，实际上两台主机中的应用进程进行通信，而在一台计算机中，用不同的端口号标识不同的应用进程。本节将介绍传输层的相关内容，包括端口号的分配方法、端口号的复用与分用、以及传输层的典型协议TCP与UDP。

---

🕒 0. 思维导图

🕒 1. 概述

计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。

但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。

如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。

🕘 1.1 端口号

• 运行在计算机上的进程使用进程标识符PID来标志。
• 因特网上的计算机并不是使用统一的操作系统，不同的操作系统又使用不同格式的进程标识符。
• 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
• TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。
  • 端口号使用16比特表示，取值范围0~65535；
    • 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如：FTP使用21/20，HTTP使用80，DNS使用53。
    • 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如：Microsoft RDP微软远程桌面使用的端口是3389。
    • 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
• 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。

🕘 1.2 发送方的复用和接收方的分用

• 复用：应用进程都可以通过运输层再传送到网络层。
• 分用：运输层从网络层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程。

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号：

🕒 2. UDP与TCP

用户数据报协议UDP （User Datagram Protocol）	传输控制协议TCP （Transmission Control Protocol）
无连接，随时可向目的主机发送报文	面向连接，发送数据前需要"三报文握手"建立连接，数据传输结束后需要"四报文挥手"释放连接
支持单播、多播和广播	仅支持单播
收到应用层报文后直接为报文添加UDP首部就进行发送，即面向应用报文	面向字节流，其将应用进程交付下来的数据块仅仅看作是一连串的字节流，TCP将这些字节流编号并存储在缓冲中；接收方一边接收数据，一边将缓冲中的数据交给应用进程。
UDP向上层提供无连接不可靠传输服务（适用于IP电话、视频会议等实时应用），使用复用和分用、差错检测功能	TCP向上层提供面向连接的可靠传输服务（适用于要求可靠传输的应用，例如文件传输），使用流量控制和拥塞控制，不会出现传输差错（误码、丢失、乱序、重复）
首部仅8字节	最小20字节，最大60字节

🕒 3. TCP的流量控制

一般来说，我们希望数据传输能快一些，但如果发送方把数据发送得过快，接收方就可能来不及接收，这会造成数据的丢失。

流量控制（flow control）定义：让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口实现流量控制

• TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
• TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送1字节零窗口探测报文（即使窗口为0也可接收）。

工作流程：

【2010年题39】主机甲和主机乙之间建立了一个TCP连接，TCP最大段长度为1000字节。若主机甲的当前拥塞窗口为4000字节，在主机甲向主机乙连续发送两个最大段后，成功收到主机乙发送的第一个段的确认段，确认段中通告的接收窗口大小为2000字节，则此时主机甲还可以向主机乙发送的最大字节数是（ ）
A.1000
B.2000
C.3000
D.4000
【解析】TCP发送方的发送窗口= min[ 自身拥塞窗口，TCP接收方的接收窗口 ]
题目未给出TCP发送方的发送窗口的初始值，则取拥塞窗口值作为发送窗口值

🕒 4. TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞（congestion）。

在计算机网络中的链路容量（即带宽)、交换结点中的缓存和处理机等，都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制主要是四个算法：慢启动（慢开始slow-start）、拥塞避免（congestion avoidance）、快速重传（快重传fast retransmit）、快速恢复（快恢复fast recovery）

下面介绍这四种拥塞控制算法的基本原理，假定如下条件：

• 数据是单方向传送，而另一个方向只传送确认。
• 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
• 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。

• 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大；但只要网络出现拥塞，拥塞窗口就减少一些。
• 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。

维护一个叫慢启动门限 ssthresh （slow start threshold）状态变量

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd > ssthresh 时，就会使用拥塞避免算法。
• 当 cwnd = ssthresh 时，既可使用慢启动算法，也可使用拥塞避免算法。

🕘 4.1 慢启动

TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量。

慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个例子：

• 连接建立完成后，一开始初始化 cwnd = 1，表示可以传一个 MSS 大小的数据。
• 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个
• 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个
• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

可以看出慢启动算法，发包的个数是指数性的增长。

假定 ssthresh = 8，此时改用拥塞避免算法。

🕘 4.2 拥塞避免

规则：每当收到一个 ACK 时，cwnd 线性+1。

当重传计时器超时，判断网络很可能出现了拥塞，触发超时重传

当发生了超时重传，则就会使用拥塞发生算法

此时sshresh 和 cwnd 的值会发生变化：

• ssthresh 设为发生拥塞时cwnd值的一半
• cwnd 重置为 1，并重新开始慢开始算法

接着，就重新开始慢启动，慢启动是会突然减少数据流的，这种方式太激进了，反应也很强烈，会造成网络卡顿。

参考链接：🔎 TCP 重传、滑动窗口、流量控制、拥塞控制

🕘 4.3 快速重传

• 慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法（TCP Tahoe版本）。
• 1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCP Reno版本）。
  • 有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。这将导致发送方超时重传，并误认为网络发生了拥塞；发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
• 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
• 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
  • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认；
  • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
  • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
  • 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1）。使用快重传可以使整个网络的吞吐量提高约20%。

🕘 4.4 快速恢复

后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。

当收到3个连续重复的ACK，则进入快速恢复算法，如下：

• cwnd = cwnd/2 ；
• ssthresh = cwnd；
• cwnd = ssthresh （有的版本是cwnd = ssthresh + 3，+ 3 的意思是确认有 3 个数据包被收到了）
• 重传丢失的数据包
• 如果再收到重复的 ACK，那么 cwnd + 1；
• 如果收到新数据的 ACK 后，设置 cwnd = ssthresh，接着就进入了拥塞避免算法

注：

• “慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；
• “拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易。

【2009年题39】一个TCP连接总是以1KB的最大段长发送TCP段，发送方有足够多的数据要发送。当拥塞窗口为16KB时发生了超时，如果接下来的4个RTT（往返时间）内的TCP段的传输都是成功的，那么当第4个RTT时间内发送的所有TCP段都得到肯定应答时，拥塞窗口大小是（）
A.7KB
B.8KB
C.9KB
D.16KB

解析：

🕒 5. TCP超时重传时间（RTO）的选择

正常情况下，超时重传时间应该设为略大于往返时间。但是由于各区域的速率可能不一致，因此将超时重传时间设置为一个固定值是行不通的。

利用每次测量得到的RTT样本，计算加权平均往返时间$RT{T}_S$（平滑的往返时间）。

显然，超时重传时间RTO应略大于加权平均往返时间$RT{T}_S$。

​RFC6298建议使用下式计算超时重传时间RTO：

$$RTO=RT{T}_S+4\times RT{T}_D$$

• 加权平均往返时间$RT{T}_s$：
  $RT{T}_{S1}=RT{T}_l$
  新的$RT{T}_S=(1-\alpha )\times \text{ 旧的 }RT{T}_S+\alpha \times$新的RTT样本
  $0\le \alpha <1$
  已成为建议标准的RFC6298推荐的$\alpha$值为1/8，即0.125。

• RTT偏差的加权平均$RT{T}_D$：
  $RT{T}_{D1}=RT{T}_1÷2$
  新的$RT{T}_D=(1-\beta )\times \text{ 旧的 }RT{T}_D+\beta \times \mid RT{T}_S-\text{ 新的 }RTT\text{ 样本 }\mid$
  $0\le \beta <1$
  已成为建议标准的RFC6298推荐的$\beta$值为1/4，即0.25。

往返时间测量问题：

针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。

这又引起了新的问题。设想出现这样的情况:报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。

因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

🕒 6. TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输。

• 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
  • 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
• 对于不按序到达的数据应如何处理，TCP并无明确规定。
  • 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP要求接收方必须有累积确认和捎带确认机制（捎带下一个希望接收的报文），这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
  • TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
• TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

🕒 7. TCP的运输管理

• TCP是面向连接的协议，它基于运输连接来传送TCP报文段。
• TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
• TCP运输连接有以下三个阶段：
  • 建立TCP连接（三报文握手）
  • 数据传送
  • 释放TCP连接（四报文挥手）
• TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

🕘 7.1 连接建立（握手）

TCP的连接建立要解决以下三个问题：

• 使TCP双方能够确知对方的存在；
• 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；
• 使TCP双方能够对运输实体资源（(如缓存大小、连接表中的项目等）进行分配。

一开始。TCP服务器进程与客户进程都首先创建传输控制块，用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前的发送和接收序号等。

• 一握手（TCP连接请求报文）
  同步位SYN=1：表明这是一个TCP连接请求报文段。
  seq=x：TCP客户进程所选择的初始序号。
• 二握手（TCP连接请求确认报文）
  SYN=1，ACK=1：表明这是一个TCP连接请求确认报文段。
  seq=y：作为TCP服务器进程选择的初始序号。
  确认号字段ack=x+1：这是对TCP客户进程选择的初始序号的确认。
• 三握手（普通的TCP确认报文）
  确认位ACK=1：表明这是一个普通的TCP确认报文段。
  seq=x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x。（发送的下一份TCP报文序号仍然是x+1）
  ack=y，这是对TCP服务器进程选择的初始序号的确认。

注意：

• TCP规定SYN=1的报文段不能携带数据，但要消耗掉一个序号。
• TCP规定普通的TCP确认报文段回以携带数据，但如果不携带数据。则不消耗序号。

Q：为什么TCP客户进程最后还要发送普通的TCP确认报文段呢？是否多余？
A：不多余，这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误。

🕘 7.2 连接释放（挥手）

• 一挥手（TCP连接释放报文）
  • 终止位FIN、确认位ACK设置为1：表明这是一个TCP连接释放报文段，同时也是对之前接收数据的确认。
  • 序号seq=u：等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1。
  • 确认号ack=v：等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。
• 二挥手（普通的TCP确认报文）
  • ACK=1：表明这是一个普通的TCP确认报文段。
  • seq=v，等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。（发送的下一份TCP报文序号仍然是v）
  • ack=u+1，这是对TCP连接释放报文段的确认。
• 三挥手（TCP连接释放报文段，最后确认状态）
  • FIN=1，ACK=1：表明这是—个TCP连接释放报文段，同时也对之前收到的报文段进行确认。
  • seq=w：在半关闭状态下，TCP进程可能发送一些数据，导致序列号增加；如果没有发送数据则w=v
  • ack=u+1：这是对之前收到的TCP连接释放报文段的重复确认。
• 四挥手（普通的TCP确认报文）
  • ACK=1：表明这是一个普通的TCP确认报文段。
  • seq=u+1，等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。
  • ack=w+1，这是对TCP连接释放报文段的确认。

注意：TCP规定终止位FIN=1的报文段即使不携带数据，也要消耗掉一个序号。

MSL（Maximum Segment Lifetime）意思是最长报文段寿命，RFC793建议为2分钟。

Q：TIME-WAIT时间等待有必要等待吗？
A：时间等待是为了避免以下这种情况：

保活计时器：

TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）。

若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

🕒 8. TCP报文段的首部格式

• 为了实现可靠传输，TCP采用了面向字节流的方式。
• 但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。
  • 一个TCP报文段由首部和数据载荷两部分构成；
  • TCP的全部功能都体现在它首部中各字段的作用。

• 源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程
• 目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程
• 序号：占32比特，取值范围$[0,2^{32}-1]$，序号增加到最后一个后，下一个序号就又回到0。作用是指出本TCP报文段数据载荷的第一个字节的序号
• 确认标志位ACK：取值为1时确认号字段才有效，为0时确认号字段无效
  • TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。
• 确认号：占32比特，取值范围$[0,2^{32}-1]$，序号增加到最后一个后，下一个序号就又回到0。可理解为若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据
• 数据偏移：占4比特，并以4字节为单位
  • 用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处。这个字段实际上是指出TCP报文段的首部长度。
  • 首部固定长度为20字节，因此数据偏移字段的最小值$(0101{)}_2$ ；首部最大长度为60字节，因此数据偏移字段最大值为$(1111{)}_2$
• 保留字段：占6比特，保留为今后使用，但是目前应置为0
• 窗口：占16比特，以字节为单位。指出发送本报文段一方的接收窗口。
  • 窗口值作为接收方让发送方设置其发送窗口的依据，这是以接收方的接收能力来控制发送方的发送能力，称为流量控制。
• 检验和：占16比特，检测范围包括TCP报文段的首部和数据载荷两部分
  • 在计算校验和时，要在TCP报文段的前面加上12字节的伪首部
• 同步标志位SYN：在TCP连接建立时用来同步序号
• 终止标志位FIN：用来释放TCP连接
• 复位标志位RST：用来复位TCP连接
  • 当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接；RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接
• 推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付
• 紧急标志位URG：取值为1时紧急指针字段有效；取值为0时紧急指针字段无效。
• 紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度
  • 当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据
• 选项：增加选项可以增加TCP的功能
  • 最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度
  • 窗口扩大选项：为了扩大窗口（提高吞吐率）
  • 时间戳选项：
    • 用来计算往返时间RTT
    • 用于处理序号超范围的情况，又称为防止序号绕回PAWS
  • 选择确认选项：实现选择确认功能
• 填充：由于选项长度可变，因此使用填充来保证报文段首部能被4整除

🕒 9. 课后习题

1. 【2017 题39】若甲向乙发起一个TCP连接，最大段长MSS=1KB，RTT=5ms，乙开辟的接收缓存为64KB，则甲从连接建立成功至发送窗口达到32KB，需经过的时间至少是
   A、25ms
   B、30ms
   C、160ms
   D、165ms

2. 【2020年 题38】若主机甲与主机乙已建立一条TCP连接，最大段长MSS为1KB，往返时间RTT为2ms，则在不出现拥塞的前提下，拥塞窗口从8KB增长到20KB所需的最长时间是
   A、4ms
   B、8ms
   C、24ms
   D、48ms

3. 【单选题】在一个TCP连接中，MSS为1KB，当拥塞窗口为28KB时发生了超时事件。如果在接下来的3个RTT内报文段传输都是成功的，那么当这些报文段均得到确认后，拥塞窗口的大小是
   A、4
   B、8
   C、9
   D、16

4. 【单选题】A和B之间建立了TCP连接，A向B发送了一个报文段，其中序号字段seq=200，确认号字段ack=201，数据部分有2个字节，那么在B对该报文段的确认段中（ ）
   A、seq=202, ack=200
   B、seq=201, ack=201
   C、seq=201, ack=202
   D、seq=202, ack=201

答案：
1.A（解析：🔎 视频讲解） 2.C（解析：视频讲解）
3.B（解析：当发生超时事件时，TCP拥塞算法变成慢开始，并且发送窗口swnd更新为1，慢开始门限ssthresh更新为28KB/2=14KB。
第1个RTT结束后，发送窗口swnd增长到2；
第2个RTT结束后，发送窗口swnd增长到4；
第3个RTT结束后，发送窗口swnd增长到8。）
4.C（解析：seq_B = ack_A ack_B = ack_A + 1）

---

OK，以上就是本期知识“运输层”的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟📌~
💫如果有错误❌，欢迎批评指正呀👀~让我们一起相互进步🚀
🎉如果觉得收获满满，可以点点赞👍支持一下哟~

❗ 转载请注明出处
作者：HinsCoder
博客链接：🔎 作者博客主页