一、传输控制协议 TCP 概述

由于 TCP协议比较复杂，因此本节先对TCP协议进行一般的介绍，然后再逐步深入讨论 TCP的可靠传输、流量控制和拥塞控制等问题。

1、TCP最主要的特点

TCP是TCP/IP体系中非常复杂的一个协议。下面介绍TCP最主要的特点。

• TCP是面向连接的运输层协议。这就是说，应用程序在使用TCP协议之前，必须先建立 TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。也就是说，应用进程之间的通信好像在“打电话”:通话前要先拨号建立连接，通话结束后要挂机释放连接。
• 每一条 TCP连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的(一对一)。这个问题后面还要进一步讨论。
• TCP提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复并且按序到达。
• TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给 TCP的缓存后，就可以做自己的事，而 TCR 在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
• 面向字节流。TCP 中的“流”(stream)指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和 TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方的 TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。下图是上述概念的示意图
  
  为了突出示意图的要点，我们只画出了一个方向的数据流。但请注意，在实际的网络中，一个 TCP报文段包含上千个字节是很常见的，而图中的各部分都只画出了几个字节，这仅仅是为了更方便地说明“面向字节流”的概念。另一点很重要的是:上图中的TCP连接是一条虚连接(也就是逻辑连接)，而不是一条真正的物理连接。TCP报文段先要传送到IP层，加上IP首部后，再传送到数据链路层;再加上数据链路层的首部和尾部后，才离开主机发送到物理链路。

从上图可看出，TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度(后面还将深入讨论)，来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)。如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分为短一些的数据块再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累足够多的字节后再构成报文段发送出去。关于TCP报文段的长度问题，在后面还要进行讨论。

2、TCP的连接

TCP把连接作为最基本的抽象。TCP的许多特性都与TCP是面向连接的这个基本特性有关。因此我们对TCP连接需要有更清楚的了解。

前面已经讲过，每一条TCP连接有两个端点。那么，TCP连接的端点是什么呢?不是主机，不是主机的I地址，不是应用进程，也不是运输层的协议端口。TCP连接的端点叫作套接字(socket)或插口。根据 RFC 793 的定义:端口号拼接到(concatenated with)IP 地址即构成了套接字。因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。例如，若地址是192.3.4.5而端口号是80，那么得到的套接字就是(192.3.4.5:80)。总之，我们有

每一条 TCP 连接唯一地被通信两端的两个端点(即套接字对 socket pair)所确定。即:

这里 IP,和 IP2分别是两个端点主机的IP 地址，而 port, 和 portz分别是两个端点主机中的端口号。因此，TCP连接就是两个套接字socket和socket,之间的连接。套接字 socket 是个很抽象的概念，在下一章还要对套接字进行更多的介绍。

总之，TCP连接就是由协议软件所提供的一种抽象。虽然有时为了方便，我们也可以说，在一个应用进程和另一个应用进程之间建立了一条TCP连接，但一定要记住:TCP连接的端点是个很抽象的套接字，即(IP地址:端口号)。也还应记住:同一个IP地址可以有多个不同的 TCP连接，而同一个端口号也可以出现在多个不同的 TCP 连接中。

本来 socket 的意思就是插座(或插口)。选用socket 这个名词是相当准确的。其实一条TCP连接就像一条电缆线，其两端都各带有一个插头。把每一端的插头插入位于主机的应用层和运输层之间的插座(socket)后，两个主机之间的进程就可以通过这条电缆线进行可靠通信了。但插座这个名词很容易让人想起来是个硬件，而socket是个软件名词，这样“套接字”就成为socket的标准译名了。

请注意，socket这个名词有时容易使人把一些概念弄混淆，因为随着互联网的不断发展以及网络技术的进步，同一个名词 socket却可表示多种不同的意思。例如：

• 允许应用程序访问连网协议的应用编程接口API(Application Programming Interface)即运输层和应用层之间的一种接口，称为socketAPI,并简称为 socket。
• 在 socketAPI 中使用的一个函数名也叫作 socket。
• 调用socket 函数的端点称为 socket，如“创建一个数据报 socket”
• 调用 socket函数时，其返回值称为 socket 描述符，可简称为 socket。
• 在操作系统内核中连网协议的 Berkeley 实现，称为 socket 实现。

二、可靠传输的工作原理

我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。

理想的传输条件有以下两个特点：

• 传输信道不产生差错。
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速率。这样一来，本来不可靠的传输信道就能够实现可靠传输了。下面从最简单的停止等待协议讲起。

1、停止等待协议

全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便，我们仅考虑A发送数据而 B接收数据并发送确认。因此A叫作发送方，而B叫作接收方。因为这里是讨论可靠传输的原理，因此把传送的数据单元都称为分组，而并不考虑数据是在哪一个层次上传送的@。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1）无差错情况

停止等待协议可用下图来说明。图(a)是最简单的无差错情况。A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对 M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。

2）出现差错

图(b)是分组在传输过程中出现差错的情况。B接收M1时检测出了差错，就丢弃 M1其他什么也不做(不通知 A收到有差错的分组)。也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这样设计的:A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫作超时重传。

要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。其实在图(a)中，A 为每一个已发送的分组都设置了一个超时计时器。但 A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。为简单起见，这些细节在图(a)中都省略了。

这里应注意以下三点：

• A在发送完一个分组后，必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
• 分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
• 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。图(b)中的一段虚线表示如果M,正确到达 B同时A也正确收到确认的过程。可见重传时间应设定为比平均往返时间更长一些。显然，如果重传时间设定得很长，那么通信的效率就会很低。但如果重传时间设定得太短，以致产生不必要的重传，就浪费了网络资源。然而，在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络以及这些网络将会产生多大的时延(这取决于这些网络当时的拥塞情况)，这些都是不确定因素。下图中把往返时间当作固定的(这显然不符合网络的实际情况)，只是为了讲述原理的方便。关于重传时间应如何选择，在后面的5.6.3节还要进一步讨论。

3）确认丢失和确认迟到

图(a)说明的是另一种情况。B所发送的对M,的确认丢失了。A 在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M。现在应注意B的动作。假定B又收到了重传的分组M。这时应采取两个行动。

• 第一，丢弃这个重复的分组M，不向上层重复交付。
• 第二，向A 发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M就表示 A 没有收到对 M1的确认。
  
  图 (b)也是一种可能出现的情况。传输过程中没有出现差错，但B对分组M的确认迟到了。A 会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃，但什么也不做，B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。

通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。

像上述的这种可靠传输协议常称为自动重传请求 ARQ(Automatic Repeat reQuest)。意思是重传的请求是自动进行的，因此也可见到自动请求重传这样的译名。接收方不需要请求发送方重传某个出错的分组。

4）信道利用率

停止等待协议的优点是简单，但缺点是信道利用率太低。我们可以用下图来说明这个问题。为简单起见，假定在A和B之间有一条直通的信道来传送分组。

假定 A发送分组需要的时间是 $T_D$。显然，$T_D$等于分组长度除以数据率。再假定分组正确到达 B后，B处理分组的时间可以忽略不计，同时立即发回确认。假定B发送确认分组需要时间 $T_A$。如果A处理确认分组的时间也可以忽略不计，那么A在经过时间($T_D$+RTT+$T_A$)后就可以再发送下一个分组，这里的RTT是往返时间。因为仅仅是在时间T内才用来传送有用的数据(包括分组的首部)，因此信道的利用率U可用下式计算:

请注意，更细致的计算还可以在上式分子的时间7内扣除传送控制信息(如首部)所花费的时间。但在进行粗略计算时，用近似的式就可以了。

我们知道，式中的往返时间 RTT 取决于所使用的信道。例如，假定 1200km 的信道的往返时间RTT=20ms，分组长度是1200bit，发送速率是1Mbit/s。若忽略处理时间和$T_A$($T_A$ 一般都远小于 $T_B$)，则可算出信道的利用率U=5.66%。但若把发送速率提高到 10Mbit/s，则U=5.96x$10^{-3}$。信道在绝大多数时间内都是空闲的。

从上图还可看出，当往返时间RTT远大于分组发送时间时，信道的利用率就会非常低。还应注意的是，上图并没有考虑出现差错后的分组重传。若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输(如下图所示)。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据在不间断地传送。显然，这种传输方式可以获得很高的信道利用率。

当使用流水线传输时，就要使用下面介绍的连续 ARO 协议和滑动窗口协议。

2、连续 ARQ协议

滑动窗口协议比较复杂，是 TCP协议的精髓所在。这里先给出连续ARQ协议最基本的概念，但不涉及许多细节问题。详细的滑动窗口协议将在后面的5.6节中讨论。

图(a)表示发送方维持的发送窗口，它的意义是:位于发送窗口内的5个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

在讨论滑动窗口时，我们应当注意到，图中还有一个时间坐标(但以后往往省略这样的时间坐标)。按照习惯,“向前”是指“向着时间增大的方向”，而“向后”则是“向着时间减少的方向”。分组发送是按照分组序号从小到大发送的。

连续 ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置图(b)表示发送方收到了对第1个分组的确认，于是把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。

接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示:到这个分组为止的所有分组都已正确收到了。

累积确认有优点也有缺点。优点是容易实现，即使确认丢失也不必重传;但缺点是不能向发送方及时反映接收方已经正确收到所有分组的信息。

例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫作 Go-back-N(回退N)，表示需要再退回来重传已发送过的N个分组可见当通信线路质量不好时，连续ARO协议会带来负面的影响。

在深入讨论 TCP的可靠传输问题之前，必须先了解TCP的报文段首部的格式。

三、TCP 报文段的首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。因此，只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。下面讨论TCP报文段的首部格式。

TCP报文段首部的前 20个字节是固定的(如下图所示)，后面有 4n 字节是根据需要而增加的选项(”是整数)。因此TCP首部的最小长度是20字节。

首部固定部分各字段的意义如下:

• 源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。和前面的 UDP 的分用相似，TCP 的分用功能也是通过端口实现的。
• 序号：占4字节。序号范围是[0,$2^{32}-1$]，共$2^{32}$(即4294967296)个序号。序号增加到 $2^{32}$-1后，下一个序号就又回到 0。也就是说，序号使用mod $2^{32}$运算。TCP是面向字节流的。在一个 TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是301，而携带的数据共有100字节。这就表明:本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400显然，下一个报文段(如果还有的话)的数据序号应当从401开始，即下一个报文段的序号字段值应为 401。这个字段的名称也叫作“报文段序号”
• 确认号：占 4字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如，B正确收到了A发送过来的一个报文段，其序号字段值是501，而数据长度是 200字节(序号501~ 700)，这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是 701，于是B在发送给A的确认报文段中把确认号置为701。请注意，现在的确认号不是501，也不是700，而是701。
  总之，应当记住：若确认号=N，则表明:到序号-1为止的所有数据都已正确收到。
  由于序号字段有32位长，可对4GB(即4千兆字节)的数据进行编号。在一般情况下可保证当序号重复使用时，旧序号的数据早已通过网络到达终点了。
• 数据偏移：占4位，它指出TCP报文段的数据起始处距离 TCP 报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。但应注意,“数据偏移”的单位是 32位字(即以4字节长的字为计算单位)。由于4位二进制数能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节，这也是TCP首部的最大长度(即选项长度不能超过 40字节)。
• 保留占6位，保留为今后使用，但目前应置为0。下面有6个控制位，用来说明本报文段的性质，它们的意义见下面
• 紧急URG(URGent)：当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)，而不要按原来的排队顺序传送。例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行。因此用户从键盘发出中断命令(Control-C)。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了许多时间。
• 确认ACK(ACKnowledgment)：仅当ACK=1时确认号字段才有效。当ACK0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
• 推送PSH(PuSH)：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送(push)操作。这时，发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地(即“推送”向前)交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
• 复位RST(ReSeT)：当RST=1时，表明TCP连接中出现严重差错(如主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。将RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重建位或重置位。
• 同步SYN(SYNchronization)：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受报文。关于连接的建立和释放，在后面的5.9节还要进行详细讨论
• 终止 FIN (FINish，意思是“完了”“终止”)：用来释放一个连接。当FIN=1时表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
• 窗口：占2字节。窗口值是[0,KaTeX parse error: Expected '}', got 'EOF' at end of input: 2^{16-1]之间的整数。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方:从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量(以字节为单位)。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。
  窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化着。
• 检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6(TCP的协议号是6)，把第5字段中的UDP长度改为TCP长度。接收方收到此报文段后仍要加上这个伪首部来计算检验和。若使用IPv6，则相应的伪首部也要改变。
• 紧急指针：占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为零时也可发送紧急数据。
• 选项：长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。最后的填充字段仅仅是为了使整个TCP首部长度是4字节的整数倍。
  
  TCP 最初只规定了一种选项，即最大报文段长度MSS(MaximumSegment Size)[RFC6691]。请注意 MSS这个名词的含义。MSS是每一个TCP报文段中的数据字段的最大长度数据字段加上 TCP首部才等于整个的TCP报文段。所以MSS 并不是整个 TCP 报文段的最大长度，而是“TCP报文段长度减去TCP首部长度”。

为什么要规定一个最大报文段长度MSS呢?这并不是考虑接收方的接收缓存可能放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少要加上40字节的首部(TCP首部20字节和IP首部20字节，这里都还没有考虑首部中的选项部分)，才能组装成一个IP数据报。若选择较小的 MSS 长度，网络的利用率就降低了。设想在极端的情况下，当TCP报文段只含有1字节的数据时，在层传输的数据报的开销至少有40字节(包括TCP报文段的首部和IP 数据报的首部)。这样，对网络的利用率就不会超过 1/41。到了数据链路层还要加上一些开销。但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传。这些也都会使开销增大。

因此，从提高网络传输效率考虑，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。由于IP数据报所经历的路径是动态变化的，因此在某条路径上确定的不需要分片的 MSS，如果改走另一条路径就可能需要进行分片。因此最佳的MSS实际上是很难确定的在连接建立的过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传送数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则 MSS的默认值是536字节(这个数值来自576字节的IP 数据报总长度减去 TCP 和IP 的固定首部)。因此所有互联网上的主机都应能接受的报文段长度是536+20(固定首部长度)=556字节。

随着互联网的发展，又陆续增加了几个选项，如窗口扩大选项、时间戳选项等(见建议标准 RFC 7323)。以后又增加了有关选择确认(SACK)选项(见建议标准RFC 2018)。这些选项的位置都在下图所示的选项字段中。

窗口扩大选项是为了扩大窗口。我们知道，TCP首部中窗口字段长度是16位，因此最大的窗口大小为64KB(见下一节)。虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，其传播时延和带宽都很大，要获得高吞吐率需要更大的窗口大小。

窗口扩大选项占3字节，其中有一个字节表示移位值S。新的窗口值等于 TCP首部中的窗口位数从16增大到(16+S)。移位值允许使用的最大值是14，相当于窗口最大值增大$2^{(16+14)}$-1=$2^{30}$-1。

窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0的选项，使窗口大小回到16。

时间戳选项占10字节，其中最主要的字段是时间戳值字段(4字节)和时间戳回送回答字段(4字节)。时间戳选项有以下两个功能::

• 用来计算往返时间RTT(见后面的5.6.2节)。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出RTT。
• 用于处理TCP序号超过$2^{32}$的情况，这又称为防止序号绕回PAWS(ProtectAgainst Wrapped Sequence numbers)。我们知道，TCP 报文段的序号只有 32 位，而每增加232个序号就会重复使用原来用过的序号。当使用高速网络时，在一次TCP连接的数据传送中序号很可能会被重复使用。例如，当使用15Mbits的速率发送报文段时，序号重复要6小时以上。但若用 2.5Gbits的速率发送报文段，则不到14 秒序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开，可以在报文段中加上这种时间戳。