运输层直接面向运行在不同主机上的应用进程提供通信服务。应用程序交付的数据怎样送到正确的进程、怎样避免接收端被发送端压垮、怎样在网络出现丢包或拥塞时继续传输都是这一层需要解决的问题。本章以 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 需要略大于加权平均往返时间图中的计算关系为RTORTTS4×RTTD RTO RTT_S 4 \times RTT_DRTORTTS​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 的各项机制就能串成一个完整体系。参考资料湖科大《计算机网络》课程第五章相关内容