【计网】运输层

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，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。

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

5.3 UDP和TCP的区别

用户数据报协议UDP (User Datagram Protocol)	传输控制协议TCP (Transmission Control Protocol)	示意图
无连接	面向连接
支持一对一，一对多，多对一和多对多交互通信	每一条TCP连接只能有两个端点EP，只能是一对一通信
对应用层交付的报文直接打包	面向字节流
尽最大努力交付，也就是不可靠；不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
首部开销小，仅8字节	首部最小20字节，最大60字节

5.4 TCP具体实现

5.4.1 TCP的流量控制

• 一般来说，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
• 所谓流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
  • TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

5.4.2 TCP的拥塞控制

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏这种情况就叫做拥塞(congestion)。
• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
  
• 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
• 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些。
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。
• 发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。
• 维护一个慢开始门限ssthresh状态变量：
  • 当cwnd < ssthresh时，使用慢开始算法；
  • 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法；
  • 当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

• 1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCPReno版本）。有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。

  • 这将导致发送方超时重传，并误认为网络发生了拥塞；
  • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
    

• 所谓快重传，就是使发送方尽快进行重传，而不是等待超时重传计时器超时再重传。

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

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

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

5.4.3 TCP超时重传时间的选择

5.4.4 TCP可靠传输的实现

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

  • 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去；
  • 接收方只接收序号落入发送窗口内的数据；
    

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

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

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

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

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

  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。

  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

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

5.4.5 TCP运输连接管理

（一）TCP连接的建立（三报文握手）

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

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

三报文握手过程

1. 第一次握手：客户端发送SYN报文

   • 客户端状态：从CLOSED状态进入SYN-SENT状态。
   • 报文内容：
     • 设置SYN=1，表示这是一个同步报文。
     • 生成一个随机的初始序列号（seq=x）。
   • 目的：客户端向服务器发起连接请求，并告知自己的初始序列号。

2. 第二次握手：服务器发送SYN-ACK报文

   • 服务器状态：从LISTEN状态进入SYN-RCVD状态。
   • 报文内容：
     • 设置SYN=1和ACK=1，表示这是一个同步确认报文。
     • 生成一个随机的初始序列号（seq=y）。
     • 确认客户端的序列号（ack=x+1）。
   • 目的：服务器确认客户端的连接请求，并告知自己的初始序列号。

3. 第三次握手：客户端发送ACK报文

   • 客户端状态：从SYN-SENT状态进入ESTABLISHED状态。
   • 报文内容：
     • 设置ACK=1，表示这是一个确认报文。
     • 确认服务器的序列号（ack=y+1）。
     • 序列号为seq=x+1（客户端的初始序列号加1）。
   • 目的：客户端确认服务器的响应，连接正式建立。

4. 服务器状态转换

   • 服务器状态：从SYN-RCVD状态进入ESTABLISHED状态。
   • 目的：服务器确认客户端的ACK报文，连接正式建立。

• 第一次握手：客户端发送SYN报文，请求建立连接。

• 第二次握手：服务器发送SYN-ACK报文，确认客户端的请求并告知自己的初始序列号。

• 第三次握手：客户端发送ACK报文，确认服务器的响应。

为什么不能是两报文握手？

（二）TCP连接的释放（四报文挥手）

四报文挥手（Four-Way Handshake）是TCP协议中用于终止连接的过程。它确保客户端和服务器之间的通信通道在关闭前能够完成数据传输并正确释放资源。

1. 第一次挥手：客户端发送FIN报文

   • 客户端状态：从ESTABLISHED状态进入FIN-WAIT-1状态。
   • 报文内容：
     • 设置FIN=1，表示客户端请求关闭连接。
     • 设置ACK=1，表示确认之前的数据传输。
     • 序列号为seq=u，确认号为ack=v。
   • 目的：客户端通知服务器，它已经完成数据发送，请求关闭连接。

2. 第二次挥手：服务器发送ACK报文

   • 服务器状态：从ESTABLISHED状态进入CLOSE-WAIT状态。
   • 报文内容：
     • 设置ACK=1，表示确认客户端的FIN报文。
     • 序列号为seq=v，确认号为ack=u+1。
   • 目的：服务器确认客户端的关闭请求，但可能还有数据需要发送。

3. 第三次挥手：服务器发送FIN报文

   • 服务器状态：从CLOSE-WAIT状态进入LAST-ACK状态。
   • 报文内容：
     • 设置FIN=1，表示服务器请求关闭连接。
     • 设置ACK=1，表示确认之前的数据传输。
     • 序列号为seq=w，确认号为ack=u+1。
   • 目的：服务器通知客户端，它也已经完成数据发送，请求关闭连接。

4. 第四次挥手：客户端发送ACK报文

   • 客户端状态：从FIN-WAIT-2状态进入TIME-WAIT状态，等待一段时间后进入CLOSED状态。
   • 报文内容：
     • 设置ACK=1，表示确认服务器的FIN报文。
     • 序列号为seq=u+1，确认号为ack=w+1。
   • 目的：客户端确认服务器的关闭请求，连接正式关闭。

5. 服务器状态转换

   • 服务器状态：从LAST-ACK状态进入CLOSED状态。
   • 目的：服务器确认客户端的ACK报文，连接正式关闭。

• 第一次挥手：客户端发送FIN报文，请求关闭连接。
• 第二次挥手：服务器发送ACK报文，确认客户端的关闭请求。
• 第三次挥手：服务器发送FIN报文，请求关闭连接。
• 第四次挥手：客户端发送ACK报文，确认服务器的关闭请求。