tcp的窗口和ack - rfc813

rfc813

1. ack的时机

The protocol contains only a general assertion that data should be acknowledged promptly, but gives no more specific indication as to how quickly an acknowledgement must be sent, or how much data should be acknowledged in each separate acknowledgement.

2. SILLY WINDOW SYNDROM (呆逼窗口综合症）

描述：由于发送方的小片数据或者接收窗口小，导致发送的数据很小，分片碎块，传输效率低！

The network between the sender and the receiver becomes clogged with many small segments, and an equal number of acknowledgements, which in turn causes lost segments, which triggers massive retransmission. Bad cases of SWS have been seen in which the average segment size was one-tenth of the size the sender and receiver were prepared to deal with, and the average number of retransmission per successful segments sent was five.

解决sws的方法

接收方的处理方法，把通知窗口减少，发送窗口不在发数据；如果窗口为整体的一半或者到达一个合理的分片大小（1mss），可以重新通知窗口。

The receiver of data can take a very simple step to eliminate SWS.
When it disposes of a small amount of data, it can artificially reduce
the offered window in subsequent acknowledgements, so that the useable
window computed by the sender does not permit the sending of any further
data.
For a simple implementation, a rule
of thumb that seems to work in practice is to artificially reduce the
offered window until the reduction constitutes one half of the available
space, at which point increase the window to advertise the entire space
again. In any event, one ought to make the chunk by which the window is
opened at least permit one reasonably large segment.

发送方解决方法和接收方类似！

改进ack算法

ack快速响应的好处

• 减少重传
• 提高发送者速度

ack的问题

• 太多导致性能下降

改进ack的方法

不可取的方法，定时器！

The peril of this approach is that on many large operating systems it is extremely costly to respond to a timer event, almost as costly as to respond to an incoming segment

delay 的ack，200ms～300ms

The receiver of data will refrain from sending an acknowledgement under certain circumstances, in which case it must set a timer which will cause the
acknowledgement to be sent later. However, the receiver should do this only where it is a reasonable guess that some other event will intervene and prevent the necessity of the timer interrupt.

If the receipt of every segment causes a new window value to be returned, then of necessity an acknowledgement will be sent for every data segment.
For the Arpanet, a reasonable interval seems to be 200 to 300 milliseconds