# 运输层概述

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

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

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

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

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的 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 时，既可使用慢开始算法，也可使用拥塞避免算法。

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

  1. 将 ssthresh 值更新为发生拥塞时 cwnd 值的一半；
  2. 将 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 (又称为平滑的往返时间)

RTTS1=RTT1RTT_{S1} = RTT_{1}

新的RTTS=(1−α)×旧的RTTS+α×新的RTT样本新的RTT_{S} = (1 - \alpha )\times 旧的RTT_{S}+\alpha \times 新的RTT样本

在上式中，0≤α<10\le \alpha < 1

若α\alpha 很接近于 0, 则新 RTT 样本对RTTsRTT_{s} 的影响不大；

若α\alpha 很接近于 1, 则新 RTT 样本对RTTsRTT_{s} 的影响较大；

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

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

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

RTO=RTTS+4×RTTDRTO=RTT_{S}+4\times RTT_{D}

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

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

RTTD1=RTT1÷2RTT_{D1}=RTT_{1}{\div} 2

新的RTTD=(1−β)×旧的RTTD+β×∣RTTS−新的RTT样本∣新的RTT_{D}=(1-\beta )\times 旧的RTT_{D}+\beta \times \left | RTT_{S}-新的RTT样本 \right |

0≤β<10\le \beta < 1

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

针对出现超时重传时无法测准往返时间 RTT 的问题，Karn 提出了一个算法: 在计算加权平均往返时间RTTSRTT_{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 运输连接有以下三个阶段:

  1. 建立 TCP 连接
  2. 数据传送
  3. 释放 TCP 连接

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

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

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

  1. TCP 的标准规定，SYN= 1 的报文段不能携带数据，但要消耗掉一个序号。
  2. 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, 2322^{32}- 1], 序号增加到最后一个后，下一个序号就又回到 0。
指出本 TCP 报文段数据载荷的第一个字节的序号。

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

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

数据偏移：占 4 比特，并以 4 字节为单位。
用来指出 TCP 报文段的数据载荷部分的起始处距离 TCP 报文段的起始处有多远。
这个字段实际。上是指出了 TCP 报文段的首部长度。
首部固定长度为 20 字节，因此数据偏移字段的最小值为(0101)2(0101)_{2}
首部最大长度为 60 字节，因此数据偏移字段的最大值为(1111)_

保留：占 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 字节为单位的)。