传输层协议介绍

1.传输层的功能

互联网在网络层使用IP协议，能够实现IP包在不同主机之间传输。那么IP包到达目的主机之后，其携带的用户数据是对应着上层的哪个应用，这就是传输层的主要功能之一。传输层定义了不同的进程，对应着上层的不同应用。两台主机之间的通信，实际上是两台主机对应的进程之间的通信。同一个主机可以同时有多个不同的进程对外传递或接收数据。

由于网络层的IP协议仅提供“尽力而为”服务，并不能保证通信的服务质量，传输层的另外一个重要功能就是要对数据报的发送和接收进行一定的管理控制。根据具体需求不同，传输层主要有两种不同的传输协议，即TCP和UDP。

传输层数据报的封装如图6.7所示。

图6.7　数据封装示意

2.端口分配方式

在传输层中是用不同的端口（Port）号来标识和区分不同的进程。需要注意的是，端口号只在某个主机本地有意义。也就是说，不同的主机会根据自身对外通信的情况等，自主地给本地的进程分配端口号。不同主机的端口号是没有关联的。

互联网中的大部分应用采用的是客户端-服务器方式，即普通用户的主机会首先向服务器发起通信请求。根据网络分层的原理，我们可以知道某个用户数据要想传递出去，需要先在传输层封装成数据报，再到网络层封装成IP包。到达接收端的时候进行步骤相反的处理，对应的高层进程就能最终获得传递过来的数据。这需要发送端在生成数据报的时候就要填写接收端对应进程的端口号。而端口号仅在本地有意义，从理论上来说，发送端并不知道接收端分配的端口号是多少。为了解决这个问题，人们定义了服务器使用的熟知端口号（Well-known Port Number），给常用的应用程序分配了固定的端口编号。这样客户端就可以知道接收端服务器的进程端口号。同时，客户端为此次通信对应的进程动态分配一个本地有意义的端口号，又叫作短暂端口号（Ephemeral Port）。在此次通信结束后，该端口号将被释放，可以分配给其他进程使用。

3.用户数据报协议

用户数据报协议（UDP，User Datagram Protocol）在传输层提供无连接、不可靠的服务，适合对实时性要求较高、以实现效率为首要目标的应用。此时，接收端收到的UDP数据报可能会出现丢失、重复、乱序等情况，传输层并不能保证通信的可靠性，而是由上层应用程序负责。

UDP协议的数据报由UDP首部和用户数据两部分组成。首部只有8字节，格式如图6.8所示，各字段的含义介绍如下。

图6.8　UDP数据报

①源端口（16 bits）：发送端对应进程的本地端口号。

②目的端口（16 bits）：接收端对应进程的本地端口号。

③长度（16 bits）：指明该UDP数据报的长度，包括首部和用户数据，以字节为单位。

④校验和（16 bits）：为了接收端对UDP数据报进行校验，检测传输中是否有错误。需要注意的是，在计算UDP数据报的校验和时，需要增加12字节的“伪首部”，其中包含了源IP地址、目的IP地址和数据报长度等，目的是为了验证该UDP数据报是否正确传输到接收端。这个“伪首部”仅供计算UDP数据报的校验和使用，并不向上层或者下层递交。

在发送时，UDP协议将上层的用户数据封装到UDP数据报中，向下交付给网络层，进行IP包的封装，以及后续底层处理。接下来IP包在网络中进行转发，目的主机收到IP包之后，网络层提取出IP包的数据部分，即UDP 数据报，提交给传输层UDP 协议，按照目的端口号寻找本地进程进行匹配。如果匹配成功，将该数据报保存到对应端口的接收队列中；如果匹配失败，则丢弃该数据报，并通知源端主机。

4.传输控制协议

传输控制协议（TCP，Transmission Control Protocol）在传输层提供面向连接、可靠的服务，提供全双工通信，适用于大量数据传输、对可靠性要求较高的情况。与UDP相比，TCP的协议复杂，效率较低，但是能够在传输层保证服务质量。应该根据上层应用的实际需求，选择是使用UDP协议还是使用TCP协议。

我们说TCP是面向连接的，也就是每一条TCP连接都是由通信对端的两个端点确定的。这种端点被称为套接字或插口（Socket），定义为（本机IP地址：本地进程对应端口号）。这样给定连接的两个端点，就可以唯一标识一个TCP连接。因此，一个主机的某个TCP插口可以被多个连接所共享，即本地的应用进程可以同时与多个目的主机的进程分别通信而不会发生混淆。而相对地，UDP协议中一个本地端口号只能供与之绑定的进程与一个目的主机的进程通信。

TCP数据报分为首部和用户数据两部分，首部对于实现其复杂的控制功能起着重要的作用。固定长度的TCP首部有20字节，此外还有若干可选项，如图6.9所示。下面介绍首部各主要字段的含义。

图6.9　TCP数据报

①源端口（16 bits）：发送端对应进程的本地端口号。

②目的端口（16 bits）：接收端对应进程的本地端口号。

③序号（32 bits）：指明该TCP数据报所发送的用户数据第一个字节的序号。TCP是面向字节流的，也就是说对于一次TCP连接中所传递的所有字节，发送端都对其按顺序编号，便于接收端按照顺序整理接收到的数据。

④确认序号（32 bits）：指明期望收到通信对方下一个TCP数据报的第一个用户数据字节的序号。TCP是全双工的，因此发送端主机同时也作为反方向通信时的接收端。这个字段就是此时起作用。

⑤首部长度（4 bits）：指明该TCP数据报的首部长度，以4字节为单位计算。

⑥保留字段（6 bits）：暂不使用，设置为0。

⑦控制位（6 bits）：6个控制位字段，各占1比特。

紧急UGR 与后面的紧急指针（16 bits）配合使用，指明该数据报中优先级较高、需要尽快传送的字节。UGR 设置为1，代表紧急指针字段有效；UGR 设置为0，代表紧急指针字段无效。

确认ACK 与确认序号配合使用。ACK 设置为1，代表确认序号字段有效；ACK 设置为0，代表确认序号字段无效。

推送PSH 在发送端希望接收端收到数据报后尽快交付上层应用时使用。

复位RST 在TCP连接出现严重差错必须释放连接，然后再重新建立连接时使用。

同步SYN 用于建立TCP连接时通信双方同步序号。

终止FIN 用于通信结束，释放连接时使用。

⑧窗口（16 bits）：当本主机作为接收端时，通知对方此时最多可以发送的字节数，也就是通知发送端设置的发送窗口大小。这个字段与TCP的流量控制机制有关。

⑨校验和（16 bits）：为了接收端对该TCP数据报进行校验，检测传输中是否有错误。与UDP类似，计算检验和的时候需要加上“伪首部”，格式与UDP的“伪首部”一样，具体填写内容按照TCP协议的规定进行修改。

TCP是面向连接的，意味着在传输用户数据之前，通信双方需要先建立连接，通信结束后，双方需要释放连接，通信过程中连接是一直保持的。下面介绍TCP建立连接的过程，也称为“三次握手”。假设主机A 向主机B提出通信申请，建立TCP连接，如图6.10所示。

图6.10　TCP建立连接

①主机A 生成连接请求数据报，其首部控制字段的同步位SYN 设为1，同时为自己要发送的数据选择一个初始序号x。主机A 将该数据报发送给主机B。

②主机B收到该数据报，同意建立连接，向主机A 发送确认报文，将其首部控制字段的SYN 和ACK 都设为1，确认序号为（x+1）；同时主机B也为自己要发送的数据选择一个初始序号y。

③主机A 收到主机B发出的确认报文之后，还需要再次发送一个数据报，向B 进行确认。该数据报首部的控制字段ACK 设为1，确认序号为（y+1），而序号字段填写（x+1）。

由此，主机A 和B完成了建立TCP连接的过程，下面就可以开始传输用户数据。在这个过程中建立的连接是双向的。

TCP的可靠传输主要体现在其差错控制、流量控制和拥塞控制上。相关的算法机制比较复杂，主要的概念和设计思想介绍如下。

TCP是面向数据流的，对所有传输的字节进行编号，在接收端也要对接收到的字节进行确认，返回确认ACK 消息，携带期望正确接收的下一个字节的序号。这是TCP 差错控制的主要思想。如图6.11所示，发送端确认了编号1～3的数据已经被接收端正确接收，此时发送端又收到了新的ACK，写有编号5，代表接收端顺利接收了编号为4的数据，期望收到的下一个数据编号为5。

图6.11　TCP差错控制

如果发现传输数据丢失，就要对丢失的数据进行重传。TCP 重传有两种机制：时间驱动重传和数据驱动重传。发送端会对每个报文的确认ACK 消息设定对应的返回等待时间，如果在此期间没有收到确认ACK 消息，则认为该报文已经丢失，就要进行重传。这就是时间驱动重传。一般来说，考虑到底层通信网络的不确定性，重传等待时间的设定是个非常复杂的问题，与TCP报文端到端的往返时延RTT 有关。考虑到RTT 是一个变量，往往采用自适应算法动态更新重传等待时间，将其设置为略大于更新后的加权平均往返时间RTTs。RTTs的更新采用如下公式：

本次更新后的RTTs=（1-α）×更新前的RTTs+α×此次获得的RTT

其中α为权重值，可以根据实际情况进行灵活调整。根据标准中RFC 6298推荐，将α 设为1/8。

接收端收到报文，如果发现错误、重复等问题，则返回给发送端的确认ACK 还是按照期望正确接收的下一个序号。此时发送端就会连续收到重复的ACK，进而得知报文可能丢失，可以提前触发重传。这就是数据驱动重传。

考虑到接收端的缓存和处理能力有限，如果发送端发送数据太快，可能出现接收端来不及接收的情况，由此要进行流量控制，由接收端控制发送端的数据发送情况。TCP 的流量控制采用端到端动态自适应滑动窗口，只有处于窗口内的数据才可以发送出去，该窗口的大小由接收端进行灵活调整，并告知发送端。如图6.12所示，在图（a）中，根据接收端通知的窗口大小，此时编号为4～7的数据都可以发送，其中编号4和5的数据已发送等待确认，编号6和7的数据尚未发送，但是处于窗口范围，可以发送；编号8和9的数据在窗口之外，不能发送。接着，发送端收到了接收端发来的新消息，其中确认了编号为4的数据已经正确接收，同时告知发送端缩小窗口。更新后的发送端状态如图（b）所示，此时编号5和6的数据都在窗口范围中，其中编号5的数据是已发送等待确认，编号6的数据未发送但是可以继续发送，而原来在窗口中的数据7此时已经移出窗口范围，不能发送。

图6.12　TCP流量控制

当对网络资源的需求超过网络实际所能提供的资源时，网络的传输性能就会下降，即出现拥塞。网络拥塞往往由很多因素引起，并没有明确的判定标准，常见的表现有分组丢失率和通信时延的持续增加等。当网络发生拥塞时，需要减少进入网络中的数据量，否则网络性能会急剧恶化，直至完全失效，出现拥塞崩溃。因此，发送端需要根据对往返时延、丢包率等指标的监控进行预测，调整发送数据的速率，避免拥塞，即进行拥塞控制。TCP的拥塞控制也是基于自适应窗口机制的，由发送端根据实际情况控制允许发送的未经确认的最大报文数量。需要注意的是，在实际中，发送端的发送窗口设置既要考虑流量控制，也要考虑拥塞控制，一般取二者中的较小值。

TCP拥塞控制的常见算法有慢启动（Slow Start）、拥塞避免（Congestion Avoidance）、快速重传（Fast Retransmit）和快速回复（Fast Recovery）等。基本思路是根据发送端接收到的ACK 和重传情况动态调整窗口大小。下面以慢启动和拥塞避免算法为例进行介绍。慢启动算法的基本步骤如下。

①刚开始发送端并不清楚网络中的负载情况，出于谨慎，将窗口设为1。

②每收到一个新的确认ACK 消息，将窗口大小增加1。

③为了避免窗口增加过大导致拥塞，设置一个慢启动门限值ssthresh。若此时的窗口值小于ssthresh值，继续执行慢启动算法；当窗口大小超过ssthresh值时，停止使用慢启动算法，改用拥塞避免算法。

拥塞避免算法的基本思路是每经过一个往返时延RTT 就将窗口值加1，而不管在此期间已经收到了多少个确认ACK 消息。

图6.13描述了一个TCP进行拥塞控制的例子。

图6.13　TCP拥塞控制

为了便于理解，图6.13中纵坐标的窗口单位采用报文个数而不是字节数，横坐标是传输次数。慢启动门限的初始值设为16。假设每次传输时，在窗口中的报文都会被及时发送出去。在开始传输的时候，窗口值为1，采用慢启动算法，每收到一个确认ACK 消息，窗口值加1，可以看出，在这个阶段窗口值是指数增长的。所以慢启动算法只是窗口初始值较小，实际增长速度很快。到点a时，窗口值为16，等于ssthresh值。接下来采用拥塞避免算法，每次传输时窗口值都加1，这个阶段窗口值是线性增长的。到点b时，窗口值为26，假设出现了超时未收到确认ACK 的情况。此时，发送端判断网络中可能出现了拥塞，要减少输入网络的数据量，将窗口值降为1，重新使用慢启动算法，并将ssthresh更新为点b时窗口值的一半，即13。接下来，当窗口值增加到13时，即点c，再次启动拥塞避免算法。以此类推，调整窗口大小。