TCP FAQ

什么是MSS(Maximum Segment Size)?

TCP用MSS选项允许接收方指定它可以接收的最大段长度。传输的双方通过这个选项协 商出一个上方都接受的最大段长。这个值太大或太小都不好。太小使得每次传输的净 荷数据太少，带宽使用率不高。太大会使得IP帧太大。这样的帧碰到具有较小的MTU的 网络时不得不分片。这些片段中只要有一个超时都会导致整个帧重传。重传的概率随 片段的增加而增加。MSS最好等于路径MTU（path MTU）。

初始序列号（ISN）如何选择？

The protocol places no restriction on a particular connection being used over and over again. A connection is defined by a pair of sockets. New instances of a connection will be referred to as incarnations of the connection. The problem that arises from this is -- "how does the TCP identify duplicate segments from previous incarnations of the connection?" This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.

To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique.

See p. 26 of [RFC793].

为什么要有TIME_WAIT状态？

有两个原因：

1. 可靠地关闭TCP连接。
   考虑一下，若最后一个ACK帧丢失了，B会超时重传。A必须记住这个状态信息，以重传最后的ACK。若A没有这个状态信息，它会传送RST。这会被B解释为一个错误。若TCP要干净地关闭连接，它就必须正确地处理最后四个帧中任意一个帧的丢失。
2. 使老的重复帧消失在网络中。
   TIME_WAIT状态的持续时间是MSL的2倍。TIME_WAIT状态过后会保证最后2个帧从网络中消失。这样若重新建立这个连接，可以保证上一次连接的老数据不会冒出来干扰这次连接。 

见[UNPv13e]的44页。

如何处理拥塞？

TCP维护2个窗口：接收方允许的窗口和拥塞窗口。最终允许发送的大小是这两个窗口 的较小值。拥塞窗口的大小由慢启动算法计算。它还用了第三个参数，阈值。当新建 立一个连接时，拥塞窗口初始化为MSS。每次成功传输成功后，拥塞窗口加MSS。第一 次传输一个数据段，成功后拥塞窗口增加为2个MSS。然后发送两个数据段，若这两个 都成功了，拥塞窗口增加为4个MSS。实际上，每批被确认的数据都使拥塞窗口加倍。 不过，当增加到阈值时便停止。从这个点开始仅线性增加，每一批确认只增加一个MSS。 每当有超时时将阈值设为原来的一半，并将拥塞窗口重新设为MSS，重新开始慢启动算 法。

见[Tanenbaum]的6.5.9节。

什么是带外数据（Out of band data）？

有时候用户需要发送紧急信息给对方，即使对方还没有处理完缓存中的数据或对方的 接收允许窗口为0（advertised window of 0）时。例如在远程登录会话中，用户可能 会发送中断信号以关闭程序，而这时程序也许正等待输入。该中断信号必须马上发送 而不是等待程序执行完毕。这就需要用到带外数据。带外数据主要是用于这种远程交 互式程序中，如telnet，ssh等。

当需要发送紧急数据时，TCP可以让发送者将数据标记为紧急的，设置URG code bit和 URGENT POINTER。URGENT POINTER指向紧急数据结束的地方，也就是说该点之前的数 据为紧急数据。URGENT POINTER前一个字节称为带外字节（Out of band byte，OOB)。接收方一旦收到标有URG的数据段时便通知应用程序进入紧急模式，并 在收完紧急数据后通知应用程序进入常规模式。至于如何通知的具体细节取决于操作 系统。详情见[UNPv13e]第24章。

何谓愚笨窗口综合症（Silly Window Syndrome）及如何解决？

愚笨窗口综合症有2种变现形式：接收方愚笨窗口综合症和发送方愚笨窗口综合症。

考虑以下情形。当接收方的接收缓存满时，它会通知对方它的接收允许窗口为0，使发送方不要再继续发送数据。这时接收应用程序从接收缓存中读入一个字节，那么就空出了一个字节的空间。接收TCP马上告知对方它的接收允许窗口为1。发送方因此发送1字节的数据给接收方。这样，每当接收应用程序读取1字节数据时都会触发发送方发送1字节数据。显然每一个数据段仅携带如此少的用户数据是相当低效的。这就是接收方愚笨窗口综合症。

和接收方一样，发送方也会产生这个问题。如果发送方每次只生成少量的数据，发送TCP就会传输一个携带少量用户数据的数据段。这就是发送方愚笨窗口综合症。

要避免这个问题可以采用很简单的启发式方法。当接收方有少量的可用缓存时，不要急着增加接收允许窗口。同样，当发送方有少量的数据要发送时，也不要急着发送，等到数据足够多时再发送。

Receive-side Silly Window Avoidance: Before sending an updated window advertisement after advertising a zero window, wait for space to become available that is either at least 50% of the total buffer size or equal to a maximum sized segment.

 

Send-side Silly Window Avoidance: When a sending application generates additional data to be sent over a connection for which previous data has been transmitted but not acknowledged, place the new data in the output buffer as usual, but do not send additional segments until there is sufficient data to fill a maximum-sized segment.  If still waiting to send when an acknowledgement arrives, send all data that has accumulated in the buffer.  Apply the rule even when the user requests a push operation.

发送方愚笨窗口综合症避免算法又称为Nagle算法。它非常优美简洁，而且是自适应的。它延迟发送的时间取决于网络的当前性能，因此能自适应于慢速的和快速的网络。另见[Comer]的12.32，12.33。

 

当然有时候这个算法是我们所不希望的。在远程交互式程序中，用户希望每敲入一个字符都能立即发送到服务器上去，而不是等待这个字符被确认后才能发送下一个字符。可以通过一个TCP选项仅用Nagle算法。详情见[UNPv13e]的7.9节。

参考文献

• [RFC793] Transmission Control Protocol.
• [Comer] Douglas E. Comer.  Internetworking with TCP/IP, Vol. 1, Fifth Edition.
• [UNPv13e] Richard Stevens, Bill Fenner and Andrew M. Rudoff. UNIX Network Programming, Vol. 1, Third Edition.
• [Tanenbaum] Andrew S. Tanenbaum.  Compuer Networks, Fourth Edition.

本文来自CSDN博客：http://blog.csdn.net/tigerscorpio/archive/2010/10/04/5921600.aspx