使用tcp传送数据，如果有一个确认报文丢失了，也不一定会引起与该确认报文段对应的数据重传。为什么_百度知道
使用tcp传送数据，如果有一个确认报文丢失了，也不一定会引起与该确认报文段对应的数据重传。为什么
数据传输举例 TCP数据传输发送方首先发送第一个包含序列号为1（可变化）和1460字节数据的TCP报文段给接收方。接收方以一个没有数据的TCP报文段来回复（只含报头），用确认号1461来表示已完全收到并请求下一个报文段。 发送方然后发送第二个包含序列号为字节数据的TCP报文段给接收方。正常情况下，接收方以一个没有数据的TCP报文段来回复，用确认号2921来表示已完全收到并请求下一个报文段。发送接收这样继续下去。 然而当这些数据包都是相连的情况下，接收方没有必要每一次都回应。比如，他收到第1到5条TCP报文段，只需回应第五条就行了。在例子中第3条TCP报文段被丢失了，所以尽管他收到了第4和5条，然而他只能回应第2条。 发送方在发送了第三条以后，没能收到回应，因此当时钟（timer）过时（expire）时，他重发第三条。（每次发送者发送一条TCP报文段后，都会重启动一次时钟:RTT）。 这次第三条被成功接收，接收方可以直接确认第5条，因为4，5两条已收到。 这是一个例子，希望LZ先通过这个例子了解TCP是如何传输的。然后所说的情况，比如传送方发送了5条TCP报文段，而接收方在接收到第3条报文段的时候发送出的确认报文丢失了，但是之后接收完全部5条报文段的时候又发出了一个对第5条的确认报文，那么发送方收到后就能够知道接收方已经成功收到了全部的5条TCP报文段，因此不会再去重传。
其他类似问题
为您推荐：
采用TCP进行数据传输时，更高序号已经到达的现象（还未重传就收到了对更高序号的确认）。因为有时会出现在低序号到达之前，同时告诉发送端自己欲接收的下一个报文段序号值，接收端发送的确认报文段是对前面收到的正确无误数据的确认
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁11644人阅读
网络（31）
TCP-IP详解卷1-21：TCP的超时与重传（Timeout and Retransmission）
1： 与数据链路层的ARQ协议相类似，TCP使用超时重发的重传机制。
&&& 即：TCP每发送一个报文段，就对此报文段设置一个超时重传计时器。
&&& 此计时器设置的超时重传时间RTO（Retransmission Time－Out）应当略大于TCP报文段的平均往返时延RTT，一般可取RTO＝2RTT。
&&& 但是，也可以根据具体情况人为调整RTO的值，例如可以设置此超时重传时间RTO＝90秒。
&&& 当超过了规定的超时重传时间还未收到对此TCP报文段的预期确认信息，则必须重新传输此TCP报文段。
二：四种定时器
&&& 1： 重传计时器（retransmission timer）：当TCP发送报文段时，就创建该特定报文段的重传计时器。可能发生两种情况：
&&&&&&& A： 若在计时器截止时间到（通常是60秒）之前收到了对此特定报文段的确认，则撤销此计时器。
&&&&&&& B： 若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。
&&& 2： 坚持计时器（persist timer ） ：为了对付零窗口大小通知，TCP需要另一个计时器。
&&&&&&& 假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段，直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。
&&&&&&& 我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP并不知道，而是会认为它已经完成任务了，并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。
&&&&&&& 要打开这种死锁，TCP为每一个连接使用一个坚持计时器。当发送TCP收到一个窗口大小为零的确认时，就启动坚持计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文段。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对端：确认已丢失，必须重传。
&&&&&&& 坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。
&&& 3： 保活计时器（keepalive timer ） ：保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时期的空闲。
&&&&&&& 假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远地处理打开状态。
&&&&&&& 要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。
&&&&&&& 保活计时器通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。
&&&&&&& 若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。
&&& 4： 时间等待计时器（2MSL timer ）：时间等待计时器是在连接终止期间使用的。
&&&&&&& 当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。
&&&&&&& 在时间等待期间中，连接还处于一种中间过渡状态。
&&&&&&& 这就可以使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。
&&&&&&& 这个计时器的值通常设置为一个报文段的寿命期待值的两倍。
三：拥塞控制用到的术语
&&& 数据段：一个数据段就是任意的TCP/IP数据或确认包（或两者兼备）。
&&& 发送端最大数据段尺寸（SMSS）:SMSS是发送端能发送的最大数据段的尺寸。这个值是以网络最大传送单元（MTU），MTU路径发现算法，RMSS(见下一项)，或其它因素为基础的。该尺寸不包括TCP/IP头和选项。
&&& 接收端最大数据段尺寸（RMSS）:RMSS是接收端愿意接收的最大数据段的尺寸。这个值在连接开始时接收端发送的MSS选项中说明。又或者，如果MSS选项没有使用，就是536字节[Bra89].该尺寸不包括TCP/IP头和选项。
&&& 满尺寸数据段：一个包括允许最大数目数据的数据段（也就是说，一个包括SMSS字节数据的数据段）。
&&& 接收端窗口（rwnd）：最近通知的接收端窗口。
&&& 拥塞窗口（cwnd）：一个TCP状态参量，代表着一个TCP允许发送的最大数据量。在任意
&&& 一个给定的时刻，TCP不会发送序号大于最大确认序号和cwnd、rwnd中较小者的数据。
&&& 初始窗口（iw）：初始窗口是三次握手完成后发送端的拥塞窗口的尺寸。
&&& 丢失窗口（lw）：丢失窗口是在一个TCP根据它的重传定时器检测到了数据丢失之后，拥塞窗口的尺寸。
&&& 重启窗口（rw）：重启窗口是TCP在一段闲置期之后重新开始传送后拥塞窗口的尺寸（如果使用慢启动算法；参见4.1节以获取更多的讨论）。
&&& 传送尺寸：已经被发送但还没有确认的数据的总量。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：170447次
积分：2990
积分：2990
排名：第7414名
原创：129篇
转载：14篇
评论：14条
(7)(13)(19)(31)(14)(3)(1)(4)(17)(1)(4)(3)(11)(15)计算机网络_第6章习题答案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
计算机网络_第6章习题答案
上传于||暂无简介
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
下载文档到电脑，查找使用更方便
还剩2页未读，继续阅读
你可能喜欢TCP（协议号6）的方方面面
第一：TCP连接的建立（也就是所谓的三次握手）过程。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
为什么A还要发送一次确认呢（即为什么是三次握手而不是两次,公司常考），这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来A收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。
现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，误以为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。
由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
采用三次握手的方法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。
第二：TCP连接释放过程。
TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。
简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。
详细过程：
第一阶段 客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；
1.服务器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭服务器读通道；
2.客户机收到ACK(i+1)后，关闭客户机写通道；
（此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）
第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；
3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；
4.服务器收到ACK(j+1)后，关闭服务器写通道。
这是标准的TCP关闭两个阶段，服务器和客户机都可以发起关闭，完全对称。
FIN标识是通过发送最后一块数据时设置的，标准的例子中，服务器还在发送数据，所以要等到发送完的时候，设置FIN（此时可称为TCP连接处于半关闭状态，因为数据仍可从被动关闭一方向主动关闭方传送）。如果在服务器收到FIN(i)时，已经没有数据需要发送，可以在返回ACK(i+1)的时候就设置FIN(j)标识，这样就相当于可以合并第二步和第三步。
第三：TCP流量控制过程（主要是根据接收方的窗口大小确定发送放的发送速率）。
滑动窗口的概念由此诞生。由于数据的发送方和接收方并不一定有相同的数据处理能力，为了避免数据发送过快而超过对方的接收能力，TCP采用了流量控制机制，接收方在TCP的包头里面通告了发送方自己的接收窗口，也就是还能够接收的最多的数据包，这样TCP就不会过度发包而超过对方的接收能力。
第四：TCP拥塞控制过程。
1986年10月，一件事情的发生使得TCP开启了一个新领域，从美国LBL到UC
Berkeley的数据吞吐量从32Kbps下降到40bps。是什么原因导致了数据吞吐量如此严重的下降呢？原来在TCP的控制机制里面只考虑到了接收端的接受能力，而忽略了一个很重要的方面，那就是没有考虑到网络自己的传输能力，从而造成了整个网络崩溃的发生。从这以后，TCP的研究课题就开始多了一个方向，那就是拥塞控制。
与上面介绍的TCP的流控比较下就可以发现，流控主要是考虑接收端，不要发送过快，超过对方的接收能力，而拥塞控制则是要考虑到整个网络环境，使其负载不能超过网络的最大承受能力。
为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V.
Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion
avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast
retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP
NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective
acknowledgement,SACK)算法。
由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的发送窗口=min(rwnd,
cwnd)。但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。关于cwnd的单位，在TCP中是以字节来做单位的，我们假设TCP每次传输都是按照MSS大小来发送数据的，因此你可以认为cwnd按照数据包个数来做单位也可以理解，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。
慢启动：最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round
Time,RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下：
开始 ---& cwnd
经过1个RTT后 ---&
cwnd = 2*1 = 2
经过2个RTT后 ---&
cwnd = 2*2= 4
经过3个RTT后 ---&
cwnd = 4*2 = 8
如果带宽为W，那么经过RTT*log2W时间就可以占满带宽。
拥塞避免：从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。
上面讨论的两个机制都是没有检测到拥塞的情况下的行为，那么当发现拥塞了cwnd又该怎样去调整呢？
首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：
1.把ssthresh降低为cwnd值的一半
2.把cwnd重新设置为1
3.重新进入慢启动过程。
快重传：其实TCP还有一种情况会进行重传：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：
1.把ssthresh设置为cwnd的一半
2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
3.重新进入拥塞避免阶段。
后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。快速重传和快速恢复算法一般同时使用。快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网络中发送一个“新”的数据包，如果发送方收到一个重复的ACK，那么根据TCP的ACK机制就表明有一个数据包离开了网络，于是cwnd加1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。
快恢复：具体来说快速恢复的主要步骤是：
1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络。
2.再收到重复的ACK时，拥塞窗口增加1。
3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。
第五：TCP超时重传算法。
重传定时器：TCP 必须维护一个重传定时器，以进行超时重传
问题：如何设置超时时间间隔 RTO？
时间间隔太短则可能导致大量不必要的重传；太长则导致性能下降；
TCP 采用了一个高度动态的算法，来不断的调整时间间隔，这个算法就是 Jacobson 1988
在此算法中， TCP 需要维护几个变量：
1）、RTT：对往返时间的当前最佳估计值
当一个数据段被发送出去后，TCP 启动定时器，如果在定时器过期之前确认数据段回来的话，则 TCP
测量一下这次确认所花的时间 M，然后根据如下公式更新 RTT。
&&&&&&&&&&&&&&&&&&&&&&&&&&
平均往返时延RTT = a(旧的RTT） + (1-a)M
其中 a 是平滑因子，典型的值是 7/8
这个公式的意思就是说，旧的 RTT 占有 7/8 的权重，新的往返时间占有 1/8
2)显然，计时器设置的超时重传时间RTO应略大于上面得出的平均往返时延RTTI，即：
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&RTO = b*RTTI
这里的b是个大于1的系数。实际上，系数b是很难确定的。若取b很接近于1，发送端可以很及时地重传丢失的报文段，因此效率得到提高。但若报文段并未丢失而仅仅是增加了一点时延，那么过早地重传未收到确认的报文段，反而会加重网络的负担。因此TCP原先的标准推荐b值取为2.
3) Karn 算法：
Jacobson 算法只用于处理正常的情况，但是当发生重传后，如果收到一个确认，这时候就不用这个算法来调整 RTO
值了。因为你无法判断这个确认是针对第一次传输，还是后来的重传。在这种情况下，采用 Karn 算法来调整 RTO 的值
Karn 算法很简单：
1）、 对于发生重传的数据段，在收到确认后，不更新
RTT。但是，报文段每重传一次，就将重传时间增大一些（不然重传时间就得不到更新）：
&&&&&&&&&&&&&&&&&&&&&&&&&
&新的重传时间 = c *
旧的重传时间
系数c的典型值是2。当不再发生报文段的重传时，才根据报文段的往返时间更新平均往返时延RTTI和重传时间的数值。即：
2）、在重传的时候，RTO 是倍增的，直到达到最大值的限制。如果重传超过一定的次数，TCP 连接会断开
3）、在重传并收到确认后，如果下一次的数据段没有发生重传（即一次性收到确认），则又恢复 Jacobson
参考文献：
（1）计算机网络（第四版）；谢希仁
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。&&&&&&&&&&&&&&&&&&&&&&&&&当前位置:测试练习 →
第七章课后练习
问题7-1：端口(port)和插口(socket)的区别是什么？
&&&&答：从本书经常使用的插口定义来看，插口包含了端口，因为插口 = (IP地址，端口号)。插口是TCP连接的端点。
&&&&但我们已经讲过，插口(socket)有多种意思。当使用API时，插口往往被看成是操作系统的一种抽象，这时，插口和一个文件描述符是很相似的，并且是应用编程接口API的一部分。插口由应用程序产生，并指明它将由客户还是服务器来使用。当应用进程创建一个插口时，要指明该插口使用的端口号。
&&&&端口则是应用层服务的的一种代号，它用来标志应用层的进程。端口是一个16 bit的整数。各种服务器使用的端口号都是保留端口号，以便使客户能够找到服务器。例如万维网服务器使用的端口号是80。
&&&&在发送数据时，应用层的数据通过端口向下交付到运输层。在接收数据时，运输层的数据通过适当的端口向上交付到应用层的某个应用程序。
问题7-2：一个插口能否同时与远地的两个插口相连？
&&&&答：不行。一个插口只能和另一个远地插口相连。
&&&&如果许多个客户同时访问同一个服务器，那么对于这种情况，请参考教材的第8章的图8-30和图8-31以及相应的文字解释。
问题7-3：数据链路层的HDLC协议和运输层的TCP协议都使用滑动窗口技术。从这方面来进行比较，数据链路层协议和运输层协议的主要区别是什么？
&&&&答：运输层的TCP协议是端到端（进程到进程）的协议，而数据链路层的HDLC协议则是仅在一段链路上的结点到结点的协议。此外，TCP的窗口机制和HDLC的也有许多具体的区别（见教材）。需要注意的是，现在使用得最多的PPP链路层协议是不使用确认机制和窗口机制的。因此像PPP协议这样的链路层协议就和运输层协议有相当大的区别。
问题7-4：TCP协议能够实现可靠的端到端传输。在数据链路层和网络层的传输还有没有必要来保证可靠传输呢？
&&&&答：在旧的OSI体系中，在数据链路层使用HDLC协议而在网络层使用X.25协议，这些协议都有确认机制和窗口机制，因而能够保证可靠传输。但是技术的进步使得链路的传输已经相当可靠了，因此在数据链路层和网络层重复地保证可靠传输就显得多余了。现在因特网在链路层使用的PPP协议和在网络层使用的IP协议都没有确认机制和窗口机制。如果出现差错就由运输层的TCP来处理（若使用UDP协议则运输层也不处理出错的问题）。
问题7-5：在TCP报文段的首部中只有端口号而没有IP地址。当TCP将其报文段交给IP层时，IP协议怎样知道目的IP地址呢？
&&&&答：显然，仅从TCP报文段的首部是无法得知目的IP地址。因此，TCP必须告诉IP层此报文段要发送给哪一个目的主机（给出其IP地址）。
问题7-6：在TCP传送数据时，有没有规定一个最大重传次数？
&&&&答：我们知道以太网规定重传16次就认为传输失败，然后报告上层。但TCP没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题。
问题7-7：是否TCP和UDP都需要计算往返时延RTT？
&&&&答：往返时延RTT只是对运输层的TCP协议才很重要，因为TCP要根据平均往返时延RTT的值来设置超时计时器的超时时间。
&&&&UDP没有确认和重传机制，因此RTT对UDP没有什么意义。
&&&&因此，不要笼统地说“往返时延RTT对运输层来说很重要”，因为只有TCP才需要计算RTT，而UDP不需要计算RTT。
问题7-8：假定TCP开始进行连接建立。当TCP发送第一个SYN报文段时，显然无法利用课中所介绍的方法计算往返时延RTT。那么这时TCP又怎样设置重传计时器呢？
&&&&答：这时TCP显然无法利用已有的公式算出往返时延RTT。实际上TCP是选择（也就是猜测）一个很长的时间作为初始的往返时延RTT。等到收到至少一个确认报文段时才能利用公式计算出比较合理的往返时延RTT。
问题7-9：糊涂窗口综合症产生的条件是什么？是否只有在接收方才产生这种症状？
&&&&答：糊涂窗口综合症产生的条件是：当发送应用程序产生数据很慢，或者接收应用程序吸收数据很慢，或者两者都有。因此发送方和接收方都可能产生这种症状。
&&&&不管是上述情况中的哪一种，都使得发送数据的报文段很小，这就引起操作效率的降低。例如，若TCP发送的报文段只包括一个字节的数据，则意味着我们发送41字节的数据报（20字节的TCP首部和20字节的IP首部）才传送1字节的数据。数据的传送效率是1/41，它表示我们非常低效率地使用网络的容量。
问题7-10：假定在一个互连网中，所有的链路的传输都不出现差错，所有的结点也都不会发生故障。试问在这种情况下，TCP的“可靠交付”的功能是否就是多余的？
&&&&答：不是多余的。TCP的“可靠交付”功能在互连网中起着至关重要的作用。
&&&&至少在以下所列举的情况下，TCP的“可靠交付”功能是必不可少的。
&&&&(1)每个IP数据报独立地选择路由，因此在到达目的主机时有可能出现失序。
&&&&(2)由于路由选择的计算出现错误，导致IP数据报在互连网中兜圈子。最后数据报首部中的生存时间TTL的数值下降到零。这个数据报在中途就被丢弃了。
&&&&(3)在某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报。因此有的数据报被丢弃。
&&&&以上列举的问题表明了：必须依靠TCP的“可靠交付”功能才能保证在目的主机的目的进程接收到正确的报文。
问题7-11：进行TCP通信的一方A收到了确认号为4001的报文段。这是否表示对方B已经收到了4000个字节的数据，而期望接收编号为4001的数据字节？还是否表示对方B已经收到了4001个字节的数据，而期望接收编号为4001的数据字节？
&&&&答： 对方B“期望接收编号为4001的数据字节”肯定是正确的。
&&&&但“对方B已经收到了4000个字节的数据”或“对方B已经收到了4001个字节的数据”则这里无法确定。这是因为这里并没有说明在TCP连接建立时，A选择什么样的数值作为自己的初始序号。
&&&&当A选择初始序号为1时，A收到了确认号为4001的报文段，就表示对方B已经收到了4000个字节的数据。
&&&&但当A选择初始序号为0时，A收到了确认号为4001的报文段，就表示对方B已经收到了4001个字节的数据。