tcp超时重传计时器的计算(tcp和udp都使用超时计时器作为重的依据)

数据传输举例 TCP数据传输发送方首先发送第一个包含序列号为1（可变化）和1460字节数据的TCP报文段给接收方。接收方以一个没有数据的TCP报文段来回复（只含报头）...

即使端口处于2MSL状态，使用该选项，仍然能够在该端口建立连接。服务器常会设置该选项，以防服务器重启。如果在TIME_WAIT时间内，收到了对端发送来的数据报（不是重置报文段都行），那么该状态将被破坏，称为时间等待错误。原因是，当收到报文段以后，通常Seq是旧的，所以本端就会发送ACK，对端已经关闭或者是别的连接，就会发送RST，导致TIME_WAIT状态被破坏。但是许多系统规定，TIME_WAIT状态是不对重置报文段做出反应。两端同时发送FIN，两端又同时ACK。又同时进入TIME_WAIT当处于TIME_WAIT的主机崩溃以后，重启，然后需要等待相当与一个MSL的时间才能建立新的连接。这段时间成为静默时间。当一段发现到达的报文段对相关连接（也就是进程，套接字对）而言不正确的时候，TCP就会发送一个重置报文段，从而导致对端的连接快速拆卸（也就是结束吧！）。重置报文段的ACK位必须有，而且ACK的值必须在正确的窗口范围内，这样可以防止被攻击。FIN正常关闭一条连接成为有序释放，通常不会出现丢失数据的情况。重置报文段终止一条连接成为终止释放。重置报文段在任何时候都可以发送，代替FIN来终止连接，且不学校对端ACK终止报文段特性：当该数值设置为0，那么也意味着，不会再连接终止之前为了确保本端缓存中的数据都发送出去而等待。TCP在发送数据时会设置计时器，如果计时器超时认为受到数据确认信息，就会引发相应的超时，或给予计时器的重传操作，计时器超时时成为重传超时（RTO）。TCP累计确认无法返回新的ACK，或者当ACK包含选择确认信息（SACK）时，表明出现书序数据报，空洞。就会引起快速重传。若RTO短与RTT，那么没分都会重传，反之，整个网络利用率就会随之下降。RTT样本：TCP在收到数据后会返回确认信息ACK，该信息中携带一个字节的数据，测量传输该确认需要的时间，该测量结果成为RTT样本。每个连接的RTT军独立计算。如何根据RTT来设置RTO，有如下的方法公式： SRTT=a*SRTT+(1-a)RTT ，a取 0.8-0.9 。当TCP运行在RTT变化较大的网络中，无法取得期望的结果。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补因为丢失ACK，或者实际RTT显著增长，可能出现伪超时的现象。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补每个包可以选择各自的传送路径。某些高级路由器的采用多个并行数据链路，不同的处理演示也会导致包的离开顺序和到达顺序不匹配包的失序会造成重传，很近单嘛，前面一个小号的Seq没到达，后面的先到达，那么ACK就会 重复当TCP超时重发是，循序执行重新租宝，发送送一个更大的报文段提高性能，不超过MSS和MTU。出现在每次传送的包较小，又丢包的情况每个交互键通常会生成一个单独的数据报，也就是每个按键是独立传输的。ssh调用一个shell，对客户端输入的字符做出辉县，因此，每个字符生成4个tcp数据段，客户端的交互按键输入，服务器对按键的ACK，服务器生成的辉县，客户端对回显的ACK。通常第二段和第三段合并，成为捎带延时确认。PSH位设置，意味着发送端的缓存为空，也就是没什么可以发送了。许多情况下，TCP并不是对每个到来的包都单独的ACK，利用累计ACK可以确认之前的ACK。累计确认可以允许TCP延时一段时间发送ACK，以便将ACK和相同方向上需要传输的数据结合发。这种捎带传输的方法常用于批量数据传输。不能任意的延迟ACK，会造成重传。同时当失序发生时，必须立刻传送ACK。系统可以设置，一般延时为200-600毫秒。该算法要求，当TCP连接中有在传数据（那些已发送，但是未确认的数据）时，小的报文段就不能被发送，知道所有的数据都受到ACK。并且受到ACK后，TCP收集这些小的数据，整合到一个报文段中发送。这种方法破事TCP遵循等停规程，只有收到所有传送数据的ACK后才能继续发送新数据。该算法的不同之处在于他实现了自时钟控制，ACK返回越快，传输也越快。在相对高延迟的广域网中，更需要减小小报文的数目，该算法使得单位时间内发送的报文数目更少，RTT控制发包速率。该算法减少小包数目的同时，也增大了传输时延，也就是总的发送时间。窗口大小表明本端可用缓存大小，对端传送的数据不应该超过改大小。也表明对端发送的数据的最大大小为TCP头部ACK号和窗口大小字段之和。也就是Seq = ACK+MSSTCP活动的两端都维护一个发送窗口结构和接受窗口结构。TCP以字节为单位维护窗口结构。每个TCP报文段都包含ACK号和窗口通告信息，TCP发送端可以据此调节窗口结构。窗口左边界不能左移。窗口的动作分为，关闭（收到ACK，左边右移），打开（MSS扩大，右边右移），收缩（MSS减小，右边左移）当收到ACK号增大，而MSS不变时窗口向前滑动当当左边界与右边界相等时，成为零窗口，此时发送端不能在发送新的数据，这种情况下，TCP开始探测对端窗口，伺机增大窗口。当接受窗口值变为0是，可以邮箱的组织发送端继续发送，知道窗口大小回复为非0值。当接收端窗口得到可用空间是，就会给发送端传输一个窗口更新，告知器可以继续发送数据，这样的这样的窗口更新通常不包含数据，成为纯ACK，因此不能保证传输的可靠性。如果一端的窗口更新ACK丢失，通信双方就会处于等待状态。为避免这种情况发生。发送端会采用一个持续计时器间歇性的查询接收端，看其窗口是否已经增长。持续计时器会触发窗口探测的传输，强制要求对端返回ACK。窗口探测包包含一个字节数据，采用TCP传输，因此可以避免窗口更新丢失导致的死锁。因为包含一个字节数据Seq改变，接受端必须处理，如果接受就会ACK。窗口大小还是0，那么就会丢弃该报，没有响应。这时候发送端会持续的发送窗口探测包。当接收端通告窗口较小，或者发送端发送的数据较小。这样数据报的有效携带率小，耗费网络资源多。避免方法以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补

查看原文图中黑色那条就是因为定时器超时仍没有收到 ACK，所以引起了发送方超时重传。实际上 TCP 有两个阈值来决定如何重传同一个报文段：一是愿意重传的次数 R1、二是应该放弃当前连接的时机 R2。R1 和 R2 的值应分别至少为 3 次和 100 秒，如果超过任何一个但还没能重传成功，会放弃该连接。当然这两个值是可以设置的，在不同系统里默认值也不同。那么如何设定一个合适的超时的值呢？假设 TCP 工作在静态环境中，这很容易，但真实网络环境不断变化，需要根据当前状态来设定合适的值。RTO（retransmission timeout）一般是根据RTT（round trip time）也就是往返时间来设置的。若 RTO 小于 RTT，则会造成很多不必要的重传；若 RTO 远大于 RTT，则会降低整体网络利用率，RTO 是保证 TCP 性能的关键。并且不同连接的RTT不相同，同一个连接不同时间的 RTT 也不相同，所以 RTO 的设置一直都是研究热点。所以凭我们的直觉，RTO 应该比 RTT 稍大：​RTO=RTT+Δt那么，RTT 怎么算呢：​SRTT=(1−α)×SRTT+α×RTTnewSRTT(smooth RTT)，RTTnew 是新测量的值。如上，为了防止 RTT 抖动太大，给了一个权值a，也叫平滑因子。a 的值建议在 10%~20%。举个例子，当前 RTTs=200ms，RTTs=200ms，最新一次测量的 RTT=800ms，RTT=800ms，那么更新后的 RTTs=200×0.875+800×0.125=275ms，RTTs=200×0.875+800×0.125=275ms.Δt如何得到呢？RFC 2988 规定：​RTO=SRTT+4×RTTD因此，按照上面的定义，Δt=4×RTTD. 而 RTTD 计算公式如下：​RTTD=(1−β)×RTTD+β×|SRTT−RTTnew|实际上，RTTD 就是一个均值偏差，它就相当于某个样本到其总体平均值的距离。这就好比你的成绩与你班级平均成绩差了多少。RFC 推荐 β=0.25。根据前面的公式，我们可以得到 RTO。一旦超过 RTO 还没收到 ACK，就会引起发送方重传。但如果重传后还是没有在 RTO 时间内收到 ACK，这时候会认为是网络拥堵，会引发 TCP 拥塞控制行为，使 RTO 翻倍。则第 n 次重传的 RTOn 值为：​RTOn=2^(n−1)×RTO1下图是一个例子：如上，在时间为0.22531时开始第一次重传，此后重传时间开始指数增大，（在尝试了8次后停下，说明其 R2 的值可能为8）。前面说了 RTO 的公式，它和 RTT 有关，那么每一次的 RTT 是如何得到的呢？在之前 TCP 连接管理的时候讲过，TCP有一个 TSOPT (timestamp option) 选项，它包含两个时间戳值。它允许发送者在报文中带上一个32比特的时间戳值（TSV），然后接收方 将收到的值原封不动的填入 ACK 报文段中 TSOPT 选项的第二部分，时间戳回显字段（TSER）。发送方收到 ACK 以后，将当前时间戳减去 TSOPT 选项的 TSER 就可得到精确的RTT值。还有另一个重要的细节，如果测量 RTT 的样本出现了超时重传，但是我们收到了 ACK 时无法分辨是对哪一次的确认，这时候 RTT 的值可能是不正确的。因此，Karn 算法规定：此时不更新 RTTnew 的值。并且如果发生再次重传，则采用退避后的 RTO 的值，直到发送成功，退避指数重新设定为 1 。假设有三个数据包依次发送，1号和3号先到达，2号数据包由于网络因素最后到达。接收方收到3号时，会发送一个1号的冗余 ACK，然后2号到达，此时会发送一个3号的累积 ACK 表明这三个到达。在这个例子里，3号 ACK 并没有立即返回，发送方收到3号的 ACK 后，根据其 TSER 计算此时的 RTT，就会导致发送方过高的估计 RTT，降低重传积极性，使得 RTO 相应增大，当然这在失序时是有好处的，因为过分积极会导致大量的伪重传。如下图，在发送第四个 ACK 后出现延迟高峰，导致发送方在 RTO 时间内没有收到 5 ~ 8 的 ACK，于是发生重传，然后之前的 ACK 到达，于是又依次发送 6 ~ 8，就导致了不必要的重传。可以用 Eifel 算法来解决（略）。从前面可以看出，TCP 可以学习链路特征，如 RTT、SRTT 等，但一旦连接关闭，这些信息就会丢失。即使相同的接收方与发送方建立新的连接，也必须从头开始“学习”。较新的 TCP 实现维护了这些值，在 Linux 中可以通过如下命令查看：在大多数情况下，计时器超时并触发重传是不必要的，也不是期望的，因为 RTO 通常是大于 RTT（约2倍或更大），因此基于计时器的重传会导致网络利用率降低。首先我们要知道，接收方收到失序报文段时，应立即生成确认信息（重复 ACK），以便发送方尽快、高效地填补空缺。而发送方在收到重复 ACK 时，无法判断是由于数据包丢失还是仅仅因为延迟，所以发送方等待一定数目的重复 ACK （重复 ACK 阈值，dupthresh），这时可以认为是数据包丢失，即便还未超时，也立即发送丢失的分组。所以快速重传概括如下：TCP 发送方在观测到至少 dupthresh ( 通常是 3 ) 个重复 ACK，立即重传，而不必得到计时器超时。当然也可以同时发送新的数据。当然快速重传也会造成一些问题。在轻微失序的情况下(左图)，不会有什么影响。但在严重失序时(右图)，4号数据包延迟到达，接收方发送 4 个冗余 ACK ，让发送方认为 4 号分组丢失，造成伪快速重传。尽管可能性较小，但 IP 协议也可能将单个包传输多次。假如 IP 协议将一个包传输了 4 次，然后发送方接收到 3 个冗余 ACK ，也会让发送方以为分组丢失，导致伪快速重传。在上一篇文章中提到过 TCP 的 SACK 选项，它通过若干个 SACK 块来帮助发送方知道接收方有哪些空缺，可以减少不必要的重传。接收端在 TCP 连接建立期间收到 SACK 选项即可生成 SACK。通常来说，当收到失序报文段，接收方就会生成 SACK。第一个 SACK 块包含的应该是最近收到的报文段的序列号范围。由于 SACK 选项空间有限，应尽可能向发送方提供最新信息。其余的 SACK 按先后顺序依次排列，也就是说，该 ACK 报文段除了包含最新接收的序列号信息，还应重复之前的 SACK 信息。这是因为 ACK 报文段是没有重发机制的，可能会丢失，重复提高了其鲁棒性。发送方应该充分利用 SACK 信息来进行重传，称为选择性重传。发送方记录累积 ACK 信息和 SACK 信息，当接收到相应序列号范围内的 ACK 时，在其重传缓存中标记该报文段重传成功。

title: TCP 总结date: 2018-03-25 09:40:24tags:categories:-计算机网络我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。* 可靠传输* 流量控制* 拥塞控制TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认）和单停等协议。用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。下面给出我们所预估的超时时间（TimeOut）公式：很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是RTT+波动值否则直接加倍上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是RFC 5681 文档规定的。好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。比如说我们现在是数据乱序到达的，我们来看一下。第一种乱序情况另外一种乱序丢包情况结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是GBN和SR翻译过来就是拉回重传和选择重传。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。结论:TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制而后者是拥塞控制，那将是我们后面需要讨论的事情。不要把这两个概念混了。其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。还是画个图看的比较直观：拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟好了，今天真的写了不少，主要就是把 TCP 的可靠传输以及连接管理讲清楚了，以及里面的一下细节问题，真的很花时间。然后其他没有涉及到的就是关于 TCP 的头并没有详细的去分析，这个东西其实也不是很难，但是现在篇幅真的已经很大就先这样，头里面的都是固定的不需要太多的理解。

(1)据RFC2988建议，RTO=RTTs+4*RTTd。其中RTTd是RTTs的偏差加权均值。 初次测量时，RTTd(1)= RTT(1)/2;后续测量中，RTTd(i)=(1-Beta)* RTTd(i-1)+Beta*{ RTTs- RTT(i)};Beta=1/4依题意，RTT(1)样本值为1.5秒，则RTTs(1)=RTT(1)=1.5s RTTd(1)=RTT(1)/2=0.75sRTO(1)=RTTs(1)+4RTTd(1)=1.5+4*0.75=4.5(s)(2)RTT(2)=2.5 RTTs(1)=1.5s RTTd(1)=0.75sRTTd(2)=(1-Beta)* RTTd(1)+Beta*{ RTTs(1)- RT(2)}=0.75*3/4+{1.5-2.5}/4=13/16 RTO(2)=RTTs(1)+4RTTd(2)=1.5+4*13/16=4.75s
书后面有答案啊傻孩子
根据RTO(2)=RTTs(1)+4RTTd(2)=1.5+4*13/16=4.75s得出ASDF1(26)=ASRSCHI+ASD1W(81)+4.99*2541/TAN∠²121³ACW.
上FOXY找丫
第一题过后： RTTD = 0.75RTTS = 1.5------------------------第二题：RTTS = (1-0.125) * 1.5 + 0.125 * 2.5 = 1.3125+0.3125 = 1.625RTTD = (1-0.25) * 0.75 + 0.25 * (2.5-1.625) = 0.5625 + 0.21875 = 0.78125 RTO = RTTS + RTTD*4 = 4.75