朝颜的计算机网络学习笔记【Chapter 5.运输层】

课程来源： 「湖科大」计算机网络微课堂视频传送门

Chapter 5.运输层

5.1 运输层概述

• 之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异 构网络互联起来所面临的问题，实现了主机到主机的通信。
• 但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
• 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。
• 运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议 等)， 它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
• 根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP，这两种协议就是本章要讨论的主要内容。

5.2 运输层端口号、复用与分用的概念

• 运行在计算机上的进程使用进程标识符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，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
  • 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中， 不同计算机中的相同端口号是没有联系的。

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EMheyMcD-1646141591549)(./assets/复用和分用.png)]

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AxQToXyw-1646141591550)(./assets/常用端口号.png)]

5.3 UDP和TCP的对比

用户数据报协议UDP（User Datagram Protocol）	传输控制协议TCP（Transmission Control Protocol）
1、无连接，可随时发送； 2、支持单播、多播以及广播，即支持一对一、一对多和一对全的通信； 3、UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界，即面向应用报文； 4、UDP向上层提供无连接不可靠传输服务（适用于IP电话、视频会议等实时应用）；	1、面向连接，需要使用三报文握手建立连接，使用四报文挥手释放连接； 2、进支持单播，即利用三报文挥手建立的逻辑通信信道进行一对一的通信； 3、面向字节流； 4、TCP向上层提供面向连接的可靠传输服务（适用于要求可靠传输的应用，例如文件传输），即基于TCP连接的可靠信道中不会出现传输差错、误码、丢失乱序、重复

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c26U70qu-1646141591550)(./assets/UDP用户数据报.png)]
UDP用户数据报首部仅8字节

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n5UrHyVQ-1646141591551)(./assets/TCP报文段.png)]
TCP报文段首部最小20字节，最大60字节

5.4 TCP的流量控制

流量控制概述

• 一般来说，我们总是希望数据传输得更快一些。
  • 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
• 所谓流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

TCP流量控制过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B5dqhNwc-1646141591552)(./assets/流量控制过程.png)]

零窗口探测也具有重传计时器，防止零窗口探测报文丢失；

即使接收窗口为0也必须接受零窗口报文段、确认报文段以及携带有紧急数据的报文段。

5.5 TCP的拥塞控制

拥塞控制概述

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。 这种情况就叫做拥塞（congestion）。
  • 在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eSQ8q9ZQ-1646141591552)(./assets/吞吐量与输入负载的关系.png)]

TCP的四种拥塞控制算法

1. 慢开始（slow-start）
2. 拥塞避免（congestion-avoidance）
3. 快重传（fast retransmit）
4. 快恢复（fast recovery）

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

1、数据是单方向传送，而另一个方向只传送确认。

2、接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。

3、以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

• 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
  • 拥塞窗口cwd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些。
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。
• 发送方将拥塞窗口作为发送窗口swnd，即swnd=cwnd。
• 维护一个慢开始门限ssthresh状态变量：
  • 当cwnd<ssthresh时，使用慢开始算法；
  • 当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法；
  • 当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

慢开始与拥塞避免算法

• “慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；
  • 慢开始的拥塞窗口初始为1；
  • 后续每收到多少，其拥塞窗口就增大多少；
  • 拥塞窗口超过了慢开始门限，则改用拥塞避免算法；
• “拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞；
  • 拥塞避免算法无论收到多少报文，其拥塞窗口都是线性加1；
  • 用拥塞避免算法时若碰到超时重传的情况，则重新将拥塞窗口更新为1，慢开始门限更新为该时刻拥塞窗口的一半，然后重新按照慢开始算法来运算。

快重传算法

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nBvbp9rx-1646141591553)(./assets/快重传.png)]

快恢复算法

• 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法；
  • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
  • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3。
    • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；
    • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
    • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

TCP超时重传时间的选择

• 超时重传时间的选择是TCP最复杂的问题之一
• 超时重传时间一般来说应略大于往返时间RTT，但是因为每次发送TCP数据报文段，其往返时间都不一样的，所以超时重传时间的设定就比较麻烦，不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。
• 所以需要利用每次测量得到的RTT样本，计算加权平均往返时间RTTs (又称为平滑的往返时间）

RTTs1 = RTT
新的RTTs = (1 - α) × 旧的RTTs + α × 新的RTT样本

在上式中，0 ≤ α < 1：
	若α很接近于0，则新RTT样本对RTTs的影响不大；
	若α很接近于1，则新RTT样本对RTTs的影响较大；

已成为建议标准的RFC6298推荐的0值为1/8，即0.125。

• 用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。
  显然，超时重传时间RTO应略大于加权平均往返时间RTTs。
• RFC6298建议使用下式计算超时重传时间RTO：

RTO = RTTs + 4 × RTTd

其中，加权平均往返时间RTTs已在上面作了解释；RTT偏差的加权平均RTTd公式如下：

RTTd1 = RTT1 ÷ 2
新的RTTd = (1 - β) × 旧的RTTd + β × | RTTs - 新的RTT样本 |，0 ≤ β < 1

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

往返时间RTT的测量比较复杂

• 源主机若误将确认当作是对原报文段的确认，所计算出的RTTs和RTO就会偏大，降低了传输效率；
• 源主机若误将确认当作是对重传报文段的确认，所计算出的RTTs和RTO就会偏小，导致报文段没必要的重传，增加网络符合
• 针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。
  • 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
• 因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

总结：

• 若没有发生超时重传：RTO = RTTs + 4 × RTTd
• 若发生了超时重传：RTO = 2 × 旧RTO

5.7 TCP可靠传输的实现

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

5.8 TCP的运输连接管理

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

1 TCP的连接建立

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

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

TCP使用“三报文握手” 建立连接的具体过程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DL9TN0HH-1646141591554)(./assets/三次握手流程.png)]

• seq = x是主机甲的初始序号， 主机甲随意指定
• seq = y是主机乙的初始序号， 主机乙随意指定
• ACK代表是确认报文
• SYN代表同步
• ack = x + 1，代表对主机甲发送的seq = x的确认
• ack = y + 1，代表对主机乙发送的seq = y的确认
• 注意：
  • TCP的标准规定，SYN = 1的文段不能携带数据，但要消耗掉一个序号
  • TCP的标准规定，普通的确认报文段如果不携带数据，则不消耗序号。

为什么要对确认建立连接的报文进行再次确认？两报文握手可以吗？

不多余！这是为了防止已失效的连接请求报文段突然又传送到了TCP服务
器，因而导致错误。

2 TCP的连接释放

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Fv4xSgt3-1646141591554)(./assets/四报文挥手.png)]

• MSL（Maximum Segment Lifetime）意思是是长报这段寿命，RFC793建议为2分钟。
  • 可以确保TCP服务进程可以收到最后一个TCP确认报文段而进入关闭状态。不然的话客户端发送完最后一次确认了之后【可能丢了】直接关闭，没有经过MSL，服务器端重复超时重传，永远也关不了了。
  • 可以使本次连接持续时间内产生的所有报文段都然网络中消失。
• seq = u，代表之前客户已传送过的数据的最后一个字节的序号加1
• ack = v，代表TCP客户进程之前已收到的数据的最后一个字节的序号加1
• seq = w，是服务器端自定的

保活计时器：

如果客户端出现故障，服务器端怎么发现呢？

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

5.9 TCP报文段的首部格式

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q81ubw78-1646141591555)(./assets/TCP报文段首部格式.png)]

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

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

**序号seq：**占32比特，取值范围[0，2^32 - 1]，序号增加到最后一个后，下一个序号就又回到0。

• 用来指出本TCP报文段数据载荷的第一个字节的序号。

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

**选项：**选项越多，TCP功能越丰富。

• 最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度。
• 窗口扩大选项：为了扩大窗口（提高吞吐率）
• 时间戳选项：
  • 用来计算往返时间RTT
  • 用于处理序号超范围的情况，又称为防止序号绕回PAWS
• 选择确认选项：用来实现选择确认功能

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