TCP窗口调节

TCP的窗口机制是接收段的数据流控

Q：
有人抱怨说美国和日本之间的一个128ms时延、速率为256 000b/s的链路吞吐量为120 000b/s(利用率47%）
而当链路通过卫星时其吞吐量则为33 000 b/s（利用率为13％）。
试问在这两种情况下窗口大小各为多少（假定卫星链路的时延为500 ms）？
卫星链路的窗口大小应该如何调整？
 
A：
TCP的窗口大小值跟 时延 * 带宽 乘积有关
首先美国和日本的线路带宽时延乘积为 256 000b/s * 0.128 s = 32 000 b(线路容量)
美国日本线路容量为 32 000b。（即4000字节）

在一个ACK确认应答到来之前（需要128ms），线路可以发送4000字节的数据。
但是现在只发送了1900字节的数据。（4000 * 47% = 1900）
说明对方设置了窗口大小为1900字节。

为了充分利用线路，应该将对方的窗口大小设置为4000字节以上。

--------------------------------- 华丽的分割线 --------------------------------

Linux下，通过proc调整TCP和UDP协议的全局发送/接收窗口大小

/proc/sys/net/core/rmem_default       #接收的窗口尺寸
/proc/sys/net/core/rmem_max               #接收的窗口尺寸最大值
/proc/sys/net/core/wmem_default       #发送的窗口尺寸
/proc/sys/net/core/wmem_max               #发送的窗口尺寸最大值

TCP动态改变窗口大小以避免网络拥挤，它使用rmem_default和wmem_default的值初始化窗口大小，并且窗口永远不会大于rmem_max和wmem_max。

而UDP不会改变它的窗口尺寸，它使用rmem_default和wmem_default作为它的窗口尺寸大小。

--------------------------------- 华丽的分割线 --------------------------------

糊涂窗口综合症
产生原因：
当发送端应用进程产生数据很慢（如Telnet）、或接收端应用进程处理接收缓冲区数据很慢，就会使应用进程间传送的报文段很小，特别是有效载荷很小。
极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头)，这种现象就叫糊涂窗口综合症。

接收端避免方法：
1.当接收方收到报文段后立即进行确认，但是要等到缓冲区可用空间至少达到总空间的一半或达到最大报文段长度之后才发送更新的窗口通告。
2.推迟确认技术。在窗口大小不足以避免低效率的传输时，则推迟发送确认。这种方法的优点是可以降低通信量，提高吞吐率。但是其缺点是如果推迟时间太长，会导致报文段重传。反而浪费网络带宽，降低吞吐率。

发送端避免方法：
在已经传输出去的数据还没有得到确认之前，允许发送应用程序多次调用写数据操作.此时并不将数据立即发送出去，而是等数据收集形成一个较长的报文段或者之前发送数据的确认到达时才发送
这项技术称为组块技术(Nagle算法)
但是这种方法会影响实时交互的网络应用，例如X-Window应用
Algorithm

if there is new data to send
    if the window size >= MSS and available data is >= MSS
        send complete MSS segment now
    else    if there is unconfirmed data still in the pipe
                enqueue data in the buffer until an acknowledge is received
            else
                send data immediately
            end if
    end if
end if

where MSS = Maximum segment size.

socket编程中关于Nagle算法的选项有：TCP_NODELAY、TCP_CORK

1. TCP_NODELAY: (制定传输数据时立即发送，而不是汇聚到一定大小后才发送）
If set, disable the Nagle algorithm. This means that segments are always sent as soon as possible, even if there is only a small amount of data. When not set, data is buffered until there is a sufficient amount to send out, thereby avoiding the frequent sending of small packets, which results in poor utilization of the network. This option is overridden by TCP_CORK; however, setting this option forces an explicit flush of pending output, even if TCP_CORK is currently set.
  
2. TCP_CORK: （使数据缓冲后再发送）
If set, don't send out partial frames. All queued partial frames are sent when the option is cleared again. This is useful for prepending headers before calling sendfile(2), or for throughput optimization. As currently implemented, there is a 200 millisecond ceiling on the time for which output is corked by TCP_CORK. If this ceiling is reached, then queued data is automatically transmitted. This option can be combined with TCP_NODELAY only since Linux 2.5.71. This option should not be used in code intended to be portable.