当前位置：首页 > news >正文

计算机网络第五章（运输层）【下】

news 来源：原创 2024/5/13 7:19:44

参考教程：5.6 TCP超时重传时间的选择_哔哩哔哩_bilibili

六、TCP超时重传时间的选择

1、根据RTT样本计算超时重传时间

（1）如下图所示，假设主机A和B是因特网上的两台主机，它们之间已经建立了TCP连接，纵坐标为时间。

（2）主机A给主机B发送TCP数据报文段0，并记录下当前的时间。主机B收到后给主机A发送相应的确认报文段。主机A收到确认报文段后记录下当前的时间。主机A记录的两个时间的差值就是报文段的往返时间RTT。

（3）如果将超时重传时间RTO的值设置得比RTT0（报文段0的往返时间）小，将会引起报文段不必要的重传，使网络负荷增大；如果将超时重传时间RTO的值设置得远大于RTT0，将会使重传推迟的时间过长，使网络的空闲时间增加，降低了传输效率。

（4）超时重传时间RTO的值应该设置为略大于报文段往返时间RTT的值，但是TCP下层是复杂的互联网环境，主机A所发送的报文段可能只经过一个高速率的局域网，也有可能经过多个低速率的网络，并且每个IP数据报的转发路由还可能不同。

（5）如下图所示，现在主机A给主机B发送TCP数据报文段1，主机B收到后给主机A发送相应的确认报文段，主机A这次测得的报文段往返时间为RTT1，显然，RTT1远大于RTT0，如果超时重传时间RTO还是之前所确定的略大于RTT0的话，这对于数据报文段1是不合适的，会造成该报文段不必要的重传。

（6）由此可见，不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO，但是可以利用每次测量得到的RTT样本计算加权平均往返时间 $RTT_{S}$ （又称为平滑的往返时间）。

①当测量到第一个RTT样本时， $RTT_{S}$ 的值直接取为第一个RTT样本的值，以后每测量到一个RTT样本时，都按下图所示公式计算新的 $RTT_{S}$ 值。

②用这种方法得出的加权平均往返时间RTTS比测量出的RTT值更加平滑。

③显然，超时重传时间RTO应略大于加权平均往返时间 $RTT_{S}$ 。

（7）RFC6298建议使用下式计算超时重传时间RTO：

2、往返时间RTT的测量比较复杂

（1）如下图所示，主机A给主机B发送TCP数据报文段，但该报文段在传输过程中丢失了，当超时重传计时器超时后，主机A就重传该报文段。主机B收到数据报文段后给主机A发送确认报文段。

①主机A收到该确认报文段后无法判断是对原报文段的确认还是对重传报文段的确认。

②该报文段实际上是对重传报文段的确认，但是如果主机A误将该确认当作是对原报文段的确认，则所计算出的RTTS和RTO就会偏大，降低了传输效率。

（2）如下图所示，主机A给主机B发送TCP数据报文段，主机B收到数据报文段后给主机A发送确认报文段，但由于某种原因，该确认报文段没有在正常时间内到达主机A，这必然会导致主机A对之前所发送的数据报文段的超时重传。

①主机A收到迟到的确认报文段后无法判断该报文段是对原报文段的确认还是对重传报文段的确认。

②该报文段实际上是对原报文段的确认，但是如果主机A误将该确认当作是对重传报文段的确认，则所计算出的RTTS和RTO就会偏小，这会引发报文段没有必要的重传，增大网络负荷。

（3）当发送方出现超时重传后，收到确认报文段时将无法判断该报文段是对原报文段的确认还是对重传报文段的确认，也就是无法准确测量出RTT，进而无法正确计算超时重传时间RTO。

（4）针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本，也就是出现重传时，不重新计算RTT，进而超时重传时间RTO也不会重新计算。

①但是Karn提出的算法又引起了新的问题：如果报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延，因此在原来得出的重传时间内，不会收到确认报文段，于是就重传报文段，但根据Karn算法，不考虑重传的报文段的往返时间样本，这样，超时重传时间就无法更新，这会导致报文段反复被重传。

②因此，要对Karn算法进行修正：报文段每重传一次，就把超时重传时间RTO增大一些，典型的做法是将新RTO的值取为旧RTO值的2倍。

3、TCP超时重传时间的计算例子

七、TCP可靠传输的实现

1、TCP实现可靠传输的例子

（1）下图所示是因特网上的两台主机，它们之间已经建立了一个TCP连接，假定数据传输只在一个方向进行，假定网络不存在拥塞问题。

（2）TCP的滑动窗口是以字节为单位的，下图所示的是发送方待发送数据字节的序号。

（3）假设发送方收到了一个来自接收方的确认报文段：

①在报文段首部中的窗口字段rwnd的值为20，也就是接收方表明自己的接收窗口的尺寸为20字节；确认号字段ack的值为31，这表明接收方希望收到下一个数据的序号是31，而序号30为止的数据已经全部正确接收了。

②发送方根据这两个字段的值构造出自己的发送窗口，将自己的发送窗口尺寸设置为20，移动至序号31~50。

（4）发送方在没有收到接收方确认的情况下，可以把发送窗口内的数据依次全部发送出去，凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

①发送窗口后沿的后面部分是已发送并已收到确认的数据字节的序号，这些数据字节显然不需要再保存在发送缓存中了，可以将它们删除。发送窗口后沿的移动情况有两种可能：

[1]没有收到新的确认，发送窗口后沿不移动。

[2]收到了新的确认，发送窗口后沿向前移动。

②发送窗口前沿的前面部分是当前不允许发送的数据字节的序号。发送窗口前沿的移动情况有四种可能：

[1]通常情况下，发送窗口的前沿是不断向前移动的。

[2]如果没有收到新的确认，对方通知的窗口大小也没有改变，前沿不向前移动。

[3]收到新确认，但对方通知的窗口缩小，正好使发送窗口前沿不动。

[4]对方通知的窗口缩小，发送窗口的前沿还可能向后收缩。（TCP标准强烈不支持这种情况）

（5）现在假定发送方将发送窗口内序号31~41的数据封装在几个不同的报文段中发送出去，此时发送窗口的位置并没有改变，发送窗口内序号31~41的数据已经发送但未收到确认，而序号42~50的数据是允许发送但还未发送的。

（6）如果要编程实现滑动窗口机制，对于发送窗口的状态的标记和维护，可以使用三个指针P1、P2、P3分别指向相应的字节序号：

①小于P1的就是已发送并已收到确认的部分。

②大于等于P3的是不允许发送的部分。

③P3- P1就是发送窗口的尺寸。

④P2-P1可以得出已发送但尚未收到确认的字节数量。

⑤P3-P2可以得出允许发送但当前尚未发送的字节数量。

（7）接收方窗口的尺寸目前为20，在接收窗口外面到30号为止的数据是已经发送过相应确认并已交付给应用进程的数据，因此无需再保留这些数据，可将它们从接收缓存中删除了；接收窗口内31~50号数据是允许接收的数据；接收窗口外51号及其后续数据，目前不允许接收。

（8）接着发送方之前发送的封装有32号和33号数据的报文段到达了接收方，由于数据序号落在接收窗口内，所以接收方接收它们，并将它们存入接收缓存，但是它们是未按序到达的数据，因为31号数据还没有到达（31号数据可能丢失，也可能还滞留在其它网络中）。

（9）由于接收方只能对按序收到的数据中的最高序号给出确认，因此接收方发出的确认报文段中的确认序号仍然是31，也就是希望收到31号数据；窗口字段的值仍是20，表明接收方没有改变自己接收窗口的大小。

（10）发送方收到该确认报文段后，发现这是一个针对31号数据的重复确认，就知道接收方收到了未按序到达的数据。由于这是针对31号数据的第一个重复确认，因此这并不会引起发送方针对该数据的快重传。另外，接收方通知的窗口尺寸仍是20，因此发送方仍保持自己的发送窗口尺寸为20。

（11）现在假设封装有31号数据的报文段到达了接收方，接收方接收该报文段，将其封装的31号数据存入接收缓存，接收方现在可将接收到的31~33号数据交付给应用进程，然后将接收窗口向前移动3个序号，并给发送方发送确认报文段。

（12）接收方发送确认报文段，其中确认序号是34，这表明接收方已经收到了序号33为止的全部数据，现在希望收到34号数据；窗口字段的值仍是20，表明接收方没有改变自己接收窗口的大小。

（13）现在假设又有几个数据报文段到达了接收方，它们封装有37、38以及40号数据，这些数据的序号虽然落在接收窗口内，但它们都是未按序到达的数据，只能先暂存在接收缓存中。

（14）接着接收方先前发送的确认报文段（ack=34）到达了发送方，发送方接收后将发送窗口向前滑动3个序号，发送窗口的尺寸保持不变，这样就有新序号51~53落入发送窗口中，而序号31~33移出了发送窗口，现在可将31~33号数据从发送缓存中删除了，因为已经收到了接收方针对它们的确认。

（15）发送方继续将发送窗口内序号42~53的数据封装在几个不同的报文段中发送出去，现在发送窗口内的序号已经用完了，发送方在未收到接收方发来确认的情况下，不能再发送新的数据；序号落在发送窗口内的已发送数据，如果迟迟收不到接收方的确认，则会产生超时重传。

2、TCP实现可靠传输的注意事项

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

①这是因为网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。

②另外，发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

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

①如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。

②TCP通常把不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

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

①接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。TCP标准规定，确认推迟的时间不应超过0.5秒，若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 11221]。

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

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

八、TCP的运输连接管理

1、TCP的运输连接管理概述

（1）TCP是面向连接的协议，它基于运输连接来传送TCP报文段。

（2）TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

（3）TCP运输连接有以下三个阶段：

①建立TCP连接，也就是通过“三报文握手”来建立TCP连接。（将TCP建立连接的过程比喻为“握手”）

②数据传送，也就是基于已建立的TCP连接进行可靠的数据传输。

③释放连接，也就是在数据传输结束后通过“四报文挥手”来释放TCP连接。（将TCP释放连接的过程比喻为“挥手”）

（4）TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

2、TCP的连接建立

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

①使TCP双方能够确知对方的存在。

②使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间截选项以及服务质量等）。

③使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

（2）TCP使用“三报文握手”建立连接的具体过程：

①下图所示是两台要基于TCP进行通信的主机，其中一台主机中的某个应用进程主动发起TCP连接建立，该进程称为TCP客户，另一台主机中被动等待TCP连接建立的应用进程称为TCP服务器。“握手”（即建立TCP连接）需要在TCP客户和TCP服务器之间交换三个TCP报文段。

②最初，两端的TCP进程都处于关闭状态。一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息，例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前发送和接收序号等。之后，TCP服务器进程就进入监听状态，等待TCP客户进程的连接请求。TCP服务器进程是被动等待来自TCP客户进程的连接请求，而不是主动发起，因此称为被动打开连接。

③TCP客户进程也是首先创建传输控制块，然后，在打算建立TCP连接时向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。TCP连接请求报文段首部中的同步位SYN被设置为1，表明这是一个TCP连接请求报文段；序号字段seq被设置了一个初始值x，作为TCP客户进程所选择的初始序号（TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号）。由于TCP连接建立是由TCP客户主动发起的，因此称为主动打开连接。

④TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。TCP连接请求确认报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段；序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号；确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号的确认（由于SYN被设置为1，所以该报文段也不能携带数据，同时消耗掉一个序号）。

⑤TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。TCP确认报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段；序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x+1；确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认（TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号，在这种情况下，所发送的下一个数据报文段的序号仍是x+1）。

⑥TCP服务器进程收到普通的TCP确认报文段后也进入连接已建立状态。现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接进行可靠的数据传输了。

（3）TCP客户进程收到TCP连接请求确认报文段后向TCP服务器进程发送的普通TCP确认报文段并不多余，下面举例说明这一点。

①TCP客户进程发出一个TCP连接请求报文段，但该报文段在某些网络结点长时间滞留了，这必然会造成该报文段的超时重传。

②假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。

③如果采取“两报文握手”，也就是TCP客户进程不需要发送普通的TCP确认报文段，那么TCP服务器进程发送完TCP连接请求确认报文段后就进入连接已建立状态。

④TCP客户进程收到TCP连接请求确认报文段后，进入TCP连接已建立状态，但不会给TCP服务器进程发送针对该报文段的普通确认报文段。

⑤现在，TCP双方都处于连接已建立状态，它们可以相互传输数据，之后可以通过“四报文挥手”来释放连接，双方TCP将进入关闭状态。

⑥一段时间后，之前滞留在网络中的那个失效的TCP连接请求报文段到达了TCP服务器进程，TCP服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求，于是给TCP客户进程发送TCP连接请求确认报文段，并进入连接已建立状态。

⑦该报文段到达TCP客户进程，由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段，但TCP服务器进程已进入连接已建立状态，它认为新的TCP连接已建立好了，并一直等待TCP客户进程发来数据，这将白白浪费TCP服务器进程所在主机的很多资源。

3、TCP的连接释放

（1）TCP通过“四报文挥手”来释放连接。数据传输结束后，TCP通信双方都可以释放连接。

（2）TCP使用“四报文挥手”释放连接的具体过程：

①假定现在TCP客户进程和TCP服务器进程都处于连接已建立状态，这时使用TCP客户进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认；序号字段seq的值设置为u，它等于TCP客户进程之前已传送过的、数据的最后一个字节的序号加1；确认号字段ack的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1。（TCP规定终止位PIN等于1的报文段即使不携带数据也要消耗掉一个序号）。

②TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段；序号字段seq的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配；确认号字段ack的值设置为u+1，这是对TCP连接释放报文段的确认。

③TCP服务器进程这时应通知高层应用进程，TCP客户进程要断开与自己的TCP连接，此时从TCP客户进程到TCP服务器进程这个方向的连接就释放了，这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了，但TCP服务器进程如果还有数据要发送，TCP客户进程仍要接收，也就是说，从TCP服务器进程到TCP客户进程这个方向的连接并未关闭，这个状态可能会持续一段时间。

④TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段。若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接。

⑤TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认；现在假定序号字段seq的值为w，这是因为在TCP连接半关闭状态下，TCP服务器进程可能又发送了一些数据（w等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1）；确认号字段ack的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

⑥TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段；序号字段seq的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号；确认号字段ack的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。

⑦TCP服务器进程收到普通的TCP确认报文段后就进入关闭状态，而TCP客户进程还要经过2MSL后才能进入关闭状态。MSL的意思是最长报文段寿命，RFC793文档建议为2分钟（TCP允许不同的实现可根据具体情况使用更小的MSL值），也就是说TCP客户进程进入时间等待状态后还要经过4分钟才能进入关闭状态。

（3）TCP客户进程在发送完最后一个确认报文段后不能直接进入关闭状态，必须要先进入时间等待状态，下面举例说明这一点。

①TCP服务器进程发送TCP连接释放报文段后进入最后确认状态，TCP客户进程收到该报文段后，发送普通的TCP确认报文段，并进入关闭状态而不是时间等待状态，然而，该TCP确认报文段丢失了，这必然会造成TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传，且TCP服务器进程仍处于最后确认状态。

②重传的TCP连接释放报文段到达TCP客户进程，由于TCP客户进程属于关闭状态，因此不理睬该报文段，这必然会造成TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进入关闭状态。

③可见，时间等待状态以及处于该状态2MSL时长可以确保TCP服务器进程收到最后一个TCP确认报文段并进入关闭状态。另外，TCP客户进程在发送完最后一个TCP确认报文段后再经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段。

（4）TCP中的保活计时器：

①假定TCP双方已经建立了连接，后来TCP客户进程所在的主机突然出现了故障，显然TCP服务器进程以后就不能再收到TCP客户进程发来的数据，因此应当有措施使TCP服务器进程不要再白白等待下去，该措施就是保活计时器。

②TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器，若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

九、TCP报文段的首部格式

1、TCP对应用报文的处理

（1）为了实现可靠传输，TCP采用了面向字节流的方式，TCP将应用进程交付下来的应用报文看作是字节流，存入TCP发送缓存中。但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。

（2）一个TCP报文段由首部和数据载荷两部分构成，TCP的全部功能都体现在它首部中各字段的作用。

2、TCP报文段首部各字段的作用

（1）TCP报文段的首部格式与IP数据报的首部格式类似，都是由20字节的固定首部和最大40字节的扩展首部构成。

（2）源端口字段占16比特，用来写入源端口号，而源端口号用来标识发送该TCP报文段的应用进程。

（3）目的端口字段占16比特，用来写入目的端口号，而目的端口号用来标识接收该TCP报文段的应用进程。

（4）序号字段占32比特，与TCP实现可靠传输相关，当序号增加到最后一个后，下一个序号从0开始。序号字段的值用来指出本TCP报文段数据载荷的第一个字节的序号。

（5）确认号字段占32比特，与TCP实现可靠传输相关，当确认号增加到最后一个后，下一个确认号从0开始。确认号字段的值用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认（若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据）。

（6）确认标志位ACK占1比特，取值为1时确认号字段才有效，取值为0时确认号字段无效。（TCP规定在连接建立后所有传送的TCP报文段都必须把ACK置1）

（7）数据偏移字段占4比特，以4字节为单位，用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远，该字段实际上是指出了TCP报文段的首部长度。首部固定长度为20字节，因此数据偏移字段的最小值为二进制的0101；加上最大40字节的扩展首部，首部最大长度为60字节，因此数据偏移字段的最大值为二进制的1111。