TCP 协议中的定时器与时间问题.docVIP

TCP协议里的时间  HYPERLINK /tag-tcp.html \t _blank tcp,  HYPERLINK /tag-D-òé.html \t _blank 协议,  HYPERLINK /tag-3?ê±.html \t _blank 超时,  HYPERLINK /tag-?¨ê±?÷.html \t _blank 定时器 一、建立连接 在发送SYN报文段后，如果在75秒没有收到相应相应，连接建立将中止。这个时间也就是阻塞connect系统调用的超时时间。 二、保活 SO_KEEPALIVE选项保持连接检测对方主机是否崩溃，避免（服务器）永远阻塞于TCP连接的输入。设置该选项后，如果2小时内在此套接口的任一方向都没有数据交换，TCP就自动给对方 发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况：对方接收一切正常：以期望的ACK响应。2小时后，TCP将发出另一个探测分节。对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET，套接口本身则被关闭。对方无任何响应：源自berkeley 的TCP发送另外8个探测分节，相隔75秒一个，试图得到一个响应。在发出第一个探测分节11分钟 15秒后若仍无响应就放弃。套接口的待处理错误被置为ETIMEOUT，套接口本身则被关闭。如ICMP错误是“host unreachable(主机不可达)”，说明对方主机并没有崩溃，但是不可达，这种情况下待处理错误被置为 EHOSTUNREACH。 注意这里面有三个数字： 1.开始首次KeepAlive探测前的TCP空闭时间，2小时2.两次KeepAlive探测间的时间间隔，75秒3.判定断开前的KeepAlive探测次数，10次 也就是说，总共需要2小时+75秒*10次 = 7950秒 三、重传 重传定时器在发送数据时设定，超时值是计算出来的，取决于RTT和报文已被重传次数(并没有包括在以下公式内，但是BSD的实现确实用到了这个数据)。 RTT估计其，R是RTT，M是测量到的RTT，a推荐值为0.9 R = a * R + (1-a) * M 重传超时时间RTO, b推荐值为2 RTO = R * b 例外：快速重传，收到3个重复的ACK会立即重传 四、延时确认，捎带确认 TCP协议栈收到数据后并不立即发送ACK，而是等待200ms（推荐值，但是这个值不能高于500ms），如果在这段时间有用户数据需要发送则一同随着这个ACK发送。 五、FIN_WAIT_2定时器 某个连接准备关闭连接时，调用close函数，发送FIN报文，状态从SYN_RCVD迁移到FIN_WAIT_1，收到这个FIN的ACK后，迁移到FIN_WAIT_2状态。 为了防止对端一直不发送FIN，在等待10分钟后再等待75秒（定时器确实被设置了两次，所以分开说），超时，连接关闭。 六、2MSL定时器 MSL是最大报文段生存时间，RFC1122建议是2分钟，但BSD传统实现采用了30秒。当连接转移到TIME_WAIT状态时，即连接主动关闭时，定时器启动，为两倍的MSL。定时器超时，这时才能重新使用之前连接使用的端口号。这也是为了避免一些意想不到的边界情况，TCPIP详解第一卷的18.6.1给出了一个极端的例子。 七、平静时间 对于来自某个连接的较早替身的迟到报文段， 2 M S L等待可防止将它解释成使用相同插口对的新连接的一部分。但这只有在处于2 M S L等待连接中的主机处于正常工作状态时才有效。 如果使用处于2 M S L等待端口的主机出现故障，它会在M S L秒内重新启动，并立即使用故障前仍处于2 M S L的插口对来建立一个新的连接吗？如果是这样，在故障前从这个连接发出而迟到的报文段会被错误地当作属于重启后新连接的报文段。无论如何选择重启后新连接的初始序号，都会发生这种情况。 为了防止这种情况，RFC 793指出TCP在重启动后的MSL秒内不能建立任何连接。这就称为平静时间(quiet time)。 八、SO_LINGER的时间 这个选项会影响close的行为。如果linger结构中的l_onoff域设为非零，并设置了零超时间隔，则close不被阻塞立即执行，不论是否有排队数据未发送或未被确认。这种关闭方式会发送RST报文段，且丢失了未发送的数据。在远端的读调用将以ECONNRESET出错。 若设置了SO_LINGER并确定了非零的超时间隔，则closes调用阻塞进程，直到所剩数据发送完毕或超时。这种关闭称为“优雅的”关闭。如果套接口置为非阻塞且