运输层直接面向运行在不同主机上的应用进程提供通信服务。应用程序交付的数据怎样送到正确的进程、怎样避免接收端被发送端压垮、怎样在网络出现丢包或拥塞时继续传输，都是这一层需要解决的问题。
本章以 TCP 为主线展开：先区分 UDP 与 TCP，再依次理解流量控制、拥塞控制、可靠传输、连接管理和报文段首部。把这些机制连起来，才能看清 TCP 的“可靠”从何而来。
一、运输层：把数据交给正确的应用进程
网络层解决的是主机到主机的交付，而一台主机上通常同时运行浏览器、聊天软件、视频程序等多个应用进程。运输层需要继续完成进程到进程的交付。
端口号就是区分应用进程的标识。发送端把应用数据封装进运输层报文段时，会写入源端口和目的端口；接收端据此将数据交给对应的应用进程。
这也对应两个概念：
- 复用：多个应用进程都可以通过运输层发送数据，运输层为每份数据加上端口号等控制信息后再向下交付。
- 分用：运输层接收到报文段后，根据目的端口号等信息，把数据分发给正确的应用进程。
二、UDP 与 TCP：两种不同的运输方式
UDP 和 TCP 都属于运输层协议，但提供的服务不同。选择哪一种，取决于应用对可靠性、实时性和通信方式的要求。
UDP 是无连接协议，应用层交付一个报文，UDP 就直接为其封装首部并发送。它支持一对一、一对多、多对一和多对多通信，首部只有 8 字节，开销较小；但 UDP 只提供尽最大努力交付，不使用流量控制和拥塞控制。
TCP 是面向连接的协议。一条 TCP 连接只有两个端点，因此只能进行一对一通信。TCP 面向字节流：应用程序写入的数据会先形成连续的字节序列，再由 TCP 按合适大小取出一部分，加上首部组成 TCP 报文段发送。它通过确认、重传、窗口以及连接管理等机制提供可靠传输，首部最小为 20 字节、最大为 60 字节。
可以用下面的判断方式区分二者：如果应用更需要低开销、支持多播或广播，并且能够自行处理丢失问题，可以考虑 UDP；如果应用要求数据按序、可靠地到达对端，则需要 TCP 提供的连接和控制机制。
三、TCP 流量控制：先让接收方来得及处理
发送端发送得过快时，接收端的接收缓存可能溢出。流量控制解决的正是“接收方来不及接收”的问题：接收方根据自身缓存的可用空间，限制发送方的发送窗口，从而控制发送速率。
TCP 使用滑动窗口实现流量控制。接收方会在报文段首部的窗口字段中告知当前接收窗口大小，发送方据此调整自己还能发送多少数据。接收方的窗口变小，发送方就要收缩发送窗口；接收方处理了缓存中的数据、窗口重新变大后，发送方才可以继续发送更多数据。
当接收方通告零窗口时，发送方不能无限期地等待。它会启动持续计时器，计时器超时后发送零窗口探测报文，询问接收方窗口是否已经恢复。这样可以避免窗口更新报文在网络中丢失后，双方一直停在等待状态。
流量控制关注的是接收端的处理能力。即使网络非常空闲，只要接收缓存不足，发送端仍然必须放慢速度。
四、TCP 拥塞控制：再避免把网络压垮
流量控制保护接收方，拥塞控制保护网络。当网络中某项资源的需求超过它所能提供的可用部分时，排队、时延和丢包都会增加，网络性能随之变坏，这就是拥塞。
TCP 用拥塞窗口表示发送端依据网络状态允许发送的数据量，并通过四个阶段调整它：
- 慢开始：连接开始时，拥塞窗口从较小值起步，并在每轮传输中快速增长，用来尽快探测可用带宽。
- 拥塞避免：当拥塞窗口达到慢开始门限后，增长速度改为更平缓，避免继续快速注入数据而造成拥塞。
- 快重传：发送端连续收到多个针对同一数据的重复确认时，可以推断某个报文段可能丢失，不必等到超时才重传。
- 快恢复：快重传后不必完全回到最初的发送规模，而是调整门限和拥塞窗口，在更谨慎的状态下继续传输。
图中还展示了两种不同的拥塞信号：发生超时重传时，通常说明网络问题更严重，拥塞窗口会大幅回退；收到三个重复确认时，说明网络仍在传送后续数据，可以通过快重传和快恢复减少等待时间。
拥塞控制关注的是网络可承受的发送量。实际发送窗口同时受到接收窗口和拥塞窗口约束，任何一方变小，发送端都需要相应收缩发送规模。
五、超时重传时间：RTO 为什么不能固定
发送方在规定时间内没有收到确认，就会重传数据。这个等待时间称为超时重传时间 RTO。RTO 太短会把只是暂时变慢的报文误判为丢失，造成不必要的重传；RTO 太长又会让真正丢失的数据迟迟得不到恢复。
RTO 需要略大于加权平均往返时间，图中的计算关系为：
RTO=RTTS+4×RTTD RTO = RTT_S + 4 \times RTT_DRTO=RTTS+4×RTTD
其中，RTTSRTT_SRTTS是加权平均往返时间，RTTDRTT_DRTTD是 RTT 偏差的加权平均。新的 RTT 样本不会直接覆盖旧值，而是按权重进行更新；这样既能反映当前网络状况，也不会因为一次偶然波动而剧烈改变计时结果。
如果发生超时重传，RTO 会增大为原来的两倍。这样做是为了在网络可能已经拥塞时减少继续重传带来的额外压力。
六、可靠传输：滑动窗口、确认与重传协同工作
TCP 的可靠性不是只靠“丢了就重传”。它以字节为单位编号，发送方和接收方各自维护窗口，并通过确认机制推进数据交付。
发送方在未收到确认前，可以把发送窗口中允许发送但尚未确认的数据连续发出；接收方只接收序号落在接收窗口内的数据。由于确认信息和窗口通告需要经过网络传递，发送方的发送窗口并不总是与接收方当前的接收窗口完全相同。
对于没有按序到达的数据，TCP 可以先将其暂存在接收窗口中，等缺失的字节到达后，再按序交给上层应用进程。这样既能保证应用读取到的是有序字节流，也能避免因为简单丢弃乱序数据而导致发送方重复传送大量数据。
确认机制通常采用累计确认：接收方确认某个序号，表示此前连续的数据已经收到。确认还可以捎带在反向传输的数据中，以减少单独发送确认报文的开销；但确认不能被无限推迟，否则发送方可能因迟迟收不到确认而触发不必要的超时重传。
七、TCP 连接管理：三次握手与四次挥手
TCP 是面向连接的协议。正式传送数据前，需要先建立运输连接；数据传送完成后，还需要释放连接。
1. 三次握手建立连接
三次握手的过程可以按报文方向理解：
- 客户端主动打开，发送 SYN 报文段，请求建立连接，并给出自己的初始序号。
- 服务器处于监听状态，收到请求后回复 SYN 和 ACK：一方面确认客户端的请求，另一方面也给出服务器自己的初始序号。
- 客户端再发送 ACK，确认服务器的请求；双方进入 ESTABLISHED 状态，随后可以进行双向数据传送。
建立连接不仅是让双方知道对方存在，还要协商部分参数，并为连接分配缓存、连接表项等运输实体资源。图中还体现出：带有 SYN 的报文段会占用一个序号，而不携带数据的普通确认报文不占用序号。
2. 四次挥手释放连接
连接释放通常分成四个报文段：
- 主动关闭的一方发送 FIN，表示自己不再发送数据。
- 被动关闭的一方先回复 ACK，确认收到关闭请求；此时它仍可继续把剩余数据发送给对端。
- 被动关闭的一方完成发送后，再发送 FIN。
- 主动关闭的一方回复最后一个 ACK，进入 TIME-WAIT 状态，等待一段时间后才真正关闭。
之所以常见“四次”，是因为 TCP 连接是全双工的：两个方向的数据流可以分别关闭。主动关闭方在 TIME-WAIT 中等待两个最大报文段生存时间，既为可能到来的重传 FIN 留出处理机会，也避免旧连接中的报文在网络中滞留后影响新的连接。
八、TCP 报文段首部：控制信息放在哪里
TCP 从发送缓存中取出部分字节，加上首部后形成 TCP 报文段。首部最小为 20 字节，包含可靠传输和连接管理所需的核心信息。
其中几个字段最常出现在前面的控制过程中：
- 源端口和目的端口：支持复用与分用，把报文段交给正确的应用进程。
- 序号：标识报文段中第一个数据字节的位置，支持按序重组和丢失判断。
- 确认号：指出下一次希望收到的字节序号，用于累计确认。
- 窗口：通告接收方当前可以接收的数据量，是流量控制的依据。
- 标志位：SYN 用于建立连接，FIN 用于释放连接，ACK 表示确认号有效，RST、PSH、URG 等标志也承担对应的控制作用。
- 校验和：用于发现传输过程中的差错。
首部中的选项字段长度可变，因此 TCP 首部总长度会在最小 20 字节和最大 60 字节之间变化。
总结
运输层通过端口号实现应用进程间的通信，而 TCP 在此基础上用滑动窗口、确认、重传、流量控制、拥塞控制和连接管理共同保证传输可靠。理解这些机制时，可以始终追问三个问题：接收方是否来得及处理、网络是否承受得住、丢失或乱序后怎样恢复。顺着这三条线，TCP 的各项机制就能串成一个完整体系。
参考资料
- 湖科大《计算机网络》课程第五章相关内容