第八章：运输层

GoodBoyboyGPT

本文介绍了计算机网络体系结构中的运输层，解决了主机间进程通信问题。讨论了 TCP 和 UDP 协议、端口号、流量控制和拥塞控制等内容。详细说明了 TCP 的慢开始、拥塞避免、快重传和快恢复算法，并强调使用快重传可以提高网络吞吐量约 20%。

此内容根据文章生成，并经过人工审核，仅用于文章内容的解释与总结

运输层概述

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

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

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

运输层直接为应用进程间的逻辑通信提供服务

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

运输层端口号、复用与分用

运行在计算机.上的进程使用进程标识符PID来标志。

因特网.上的计算机并不是使用统一的操作系统，不同的操作系统(windows, Linux, Mac OS)又使用不同格式的进程标识符。

为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对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,留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。

端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。

服务	常用端口号	协议
RIP	520	UDP
DNS	53	UDP
TFTP	69	UDP
SNMP	161	UDP
DHCP	67/68	UDP
SMTP	25	TCP
FTP	21/20	TCP
BGP	179	TCP
HTTP	80	TCP
HTTPS	443	TCP

UDP和TCP的对比

UDP：

无连接
支持一对一，一对多，多对一和多对多交互通信
对应用层交付的报文直接打包
尽最大努力交付，也就是不可靠
不使用流量控制和拥塞控制
首部开销小，仅8字节

TCP：

面向连接
每一条TCP连接只能有两个端点EP，只能是一对一通信
面向字节流
可靠传输，使用流量控制和拥塞控制
首部最小20字节，最大60字节

TCP流量控制

所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。

TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后向接收方发送零窗口探测报文。

TCP拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。

这种情况就叫做拥塞(congestion)。

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

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

拥塞算法

慢开始(slow-start)
拥塞避免(congestion avoidance)
快重传(fast retransmit)
快恢复(fast recovery)

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

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

发送方将拥塞窗口作为发送窗口swnd,即swnd = cwnd.

维护一个慢开始门限ssthresh状态变量:

当cwnd < ssthresh时,使用慢开始算法;
当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法;
当cwnd = ssthresh时，既可使用慢开始算法,也可使用拥塞避免算法。

重传计时器超时
判断网络很可能出现了拥塞，进行以下工作:

将ssthresh值更新为发生拥塞时cwnd值的一半;
将cwnd值减少为1,并重新开始执行慢开始算法。

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

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。

1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复(TCP Reno版本)。

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。
这将导致发送方超时重传, 并误认为网络发生了拥塞
发送方把拥塞窗口cwnd又设置为最小值1, 并错误地启动慢开始算法，因而降低了传输效率。

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。

要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认:
即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。

发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法

发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半，开始执行拥塞避免算法。
也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大-些，即等于新的ssthresh + 3。

既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络
这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中
可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些

TCP超时重传时间选择

超时重传时间RTO应略大于往返时间RTT

不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO.

利用每次测量得到的RTT样本，计算加权平均往返时间RTTs(又称为平滑的往返时间)

$RTT_{S1} = RTT_{1}$

$新的RTT_{S} = (1 - \alpha )\times 旧的RTT_{S}+\alpha \times 新的RTT样本$

在上式中， $0\le \alpha < 1$

若 $\alpha$ 很接近于0,则新RTT样本对 $RTT_{s}$ 的影响不大;

若 $\alpha$ 很接近于1,则新RTT样本对 $RTT_{s}$ 的影响较大;

用这种方法得出的加权平均往返时间 $RTT_{s}$ 就比测量出的RTT值更加平滑。

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

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

$RTO=RTT_{S}+4\times RTT_{D}$

已成为建议标准的RFC6298推荐的 $\alpha$ 值为1/8,即0.125。

RTT偏差的加权平均 $RTT_{D}$ 计算公式：

$RTT_{D1}=RTT_{1}{\div} 2$

$新的RTT_{D}=(1-\beta )\times 旧的RTT_{D}+\beta \times \left | RTT_{S}-新的RTT样本 \right |$

$0\le \beta < 1$

已成为建议标准的RFC6298推荐的 $\beta$ 值为1/4，即0.25。

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

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

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

TCP可靠传输的实现

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

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。

网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

对于不按序到达的数据应如何处理，TCP并无明确规定。

如果接收方把不按序到达的数据一律丟弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利,
因为发送方会重复传送较多的数据。
TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传,这反而浪费了网络的资源。
TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

TCP运输连接管理

TCP连接的建立

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。
TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

TCP运输连接有以下三个阶段:

建立TCP连接
数据传送
释放TCP连接

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

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

TCP使用“三报文握手”建立连接

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

TCP的连接释放

TCP通过“四报文挥手”来释放连接

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

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

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

TCP报文首部格式

为了实现可靠传输，TCP采用了面向字节流的方式。

但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。

一个TCP报文段由首部和数据载荷两部分构成;
TCP的全部功能都体现在它首部中各字段的作用。

源端口:占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。

目的端口:占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。

序号:占32比特,取值范围[0, $2^{32}$ - 1],序号增加到最后一个后，下一个序号就又回到0。
指出本TCP报文段数据载荷的第一个字节的序号。

确认号:占32比特，取值范围[0, $2^{32}$ - 1],确认号增加到最后一个后，下一个确认号就又回到0。
指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数据的确认。
若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。

确认标志位ACK:取值为1时确认号字段才有效;取值为0时确认号字段无效
TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。

数据偏移:占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报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

选项:
最大报文段长度MSS选项: TCP报文段数据载荷部分的最大长度。
窗口扩大选项:为了扩大窗口(提高吞吐率)。
时间戳选项:

用来计算往返时间RTT
用于处理序号超范围的情况，又称为防止序号绕回PAWS。
选择确认选项

填充:由于选项的长度可变，因此使用填充来确保报文段首部能被4整除(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。