第8章传输控制协议祥解.pptVIP

为了平滑地完成TCP的功能，它使用了下图所示的四种计时器。 计时器 重传 持续 保活 时间等待 TCP的计时器 8.10 定时器管理 重传定时器 为了控制丢失的或丢弃的报文段，TCP使用处理重传时间的重传计时器。当TCP发送报文段时，它就创建该特定报文段的重传计时器。可能发生两种情况： 1. 若在计时器截止时间到之前收到了对此特定报文段的确认，则撤销此计时器。 2. 若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。 问题：超时重传，如何设置定时器的时限？ 两个概念： ① RTT：往返时间，报文段发出到收到确认信息间的时间段。 ② 自适应重传算法：记录一个报文段发出的时间，以及收到相应的确认的时间。由此推算出合适的定时时限。当连接的性能变化时，随时修改定时时限。 重传定时器 重传时间和RTT的计算 　　　选择固定时间引起的问题(对同一个连接或不同的连接)。 TCP使用动态重传超时，即对每一个连接，其重传超时是不同的，而在同一个连接上，这个时间也是会改变的。 　　　以往返时间(RTT)为基础的重传超时可成为动态的。最常用的是令重传时间为RTT的两倍： 　　　重传时间 = 2 * RTT 　　　RTT也要动态的计算，方法如下： 　　　由TCP发送一个报文段，启动计时器，然后等待其确认。测量从发送报文段到收到确认的时间，每一个报文段有一个往返时间。用在计算重传时间的RTT值是RTT的更新值，它按以下公式计算： 　　RTT = α* 前面的RTT＋(1－ α)*当前的RTT 　　　 α的值通常是90%。这就表示，新的RTT是90%的前面的RTT值加上10%的当前RTT值。 Karn 算法 　确认二义性：假定有一个报文段在重传期间未被确认，因而又被重传。当发送端的TCP收到对此报文段的确认时，它无法知道该确认是对原来的报文段的确认，还是对重传的报文段的确认。 结果：RTT样本值无法使用 ； 新的RTT值要根据报文段离开的时间来计算。但是，如果原始的报文段丢了而确认是对重传的报文段的确认，则当前的RTT的计算就必须从重传的报文段离开的时间算起。 Karn解决方法：报文段每重传一次，就把超时重传时间增大一些，典型的做法是取重传时间的2倍。当不再发生报文段的重传时，才恢复计算超时重传时间。 持续定时器 　 解决问题：对付零窗口大小通知。 　 使用：当发送端的TCP收到一个窗口大小为零的确认时，就启动持续定时器。当持续定时器期限到时，发送端的TCP就发送一个特殊的报文段，称为探测报文段。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认，甚至在计算对其他数据确认时该序号也被忽略。探测报文段提醒接收端的TCP：确认已丢失，必须重传。 　 时间设置：持续定时器的值设置为重传时间的值。若仍没收到确认，则发下一个探测报文段时，值加倍。直到这个值增大到门限值(通常是60秒)为止。以后，每隔60秒发送下一个探测报文段，直至窗口打开。 保活定时器 　 解决问题：用来防止在两个TCP之间的连接处于长时间空闲。 使用：通常在服务器端设置保活计时器。每当服务器收到客户的信息，就将计时器复位。 　 时间设置：超时通常设置为2小时。 　 若服务器过了2小时还没有收到客户的信息，就发送探测报文段。若发送了10个探测报文段(每个相隔75秒)还没有响应，就假定客户出了故障，因而就终止该连接。 时间等待定时器 　时间等待定时器是在连接终止期间使用的。当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。在时间等待期间中，连接还处于一种中间过渡状态。以使重复的FIN报文段(若有的话)在到达目的站后被丢弃，这个计时器的值通常设置为一个报文段预计的最大生存时间的两倍。 时间等待定时器 TCP是一种面向连接的、可靠的、字节流的协议； TCP使用滑动窗口机制实现流量控制； TCP使用检验和、确认和超时机制实现差错控制； TCP软件在两个设备之间传输的数据单元成为报文段，包含20-60B的首部和来自应用进程的数据； 被损坏和丢失的报文段被重发，重复的报文段被丢弃； TCP建立连接需要3次握手；释放连接需要4次握手； TCP管理4个不同的定时器:重传、持续、保活和时间等待。 8.11 本章小结 将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。 * 只要建立TCP连接，就能支持双向的数据流。即数据可在同一时间在两个方向上独立地进行传输。每一端都有自己的发送缓存和接收缓存。 关于初始序号 三次握手协议完成的两个重要功能 使双方统一了初始序号。在握手期间传输初始序号并获得确