Can be used in field

[TCP ZeroWindow], [TCP Window Update], [TCP Window Full] displayed on Wireshark – cause & countermeasure

I summarized the display related to "TCP Window" which is frequently observed with Wireshark.

What is TCP Window

The TCP Window associated with these displays is an implementation of TCP flow control.

To put it briefly, from the standpoint of receiving data , it is reasonable to control the problem of "It is inefficient even if a small amount of information is sent even though a large amount of data can be handled even though it can be handed off" It's a way to send it to your opponent with speed.Please refer to this page for details.

The situation indicated by [TCP ZeroWindow]

[TCP ZeroWindow] will be transmitted because the data receiver side informs the sender that "Since it can not be processed anymore, wait for it to be sent once".Specifically, it is displayed when a packet with TCP "Window field" set to 0 is observed along with Ack with the other party.

The situation indicated by [TCP Window Update]

On the other hand, the transmission of [TCP Window Update] tells the sender that "You can process the buffer, so please resume transmission!"Specifically, it is displayed when packets with the same ACK number as ZeroWindow and the numerical value of its own receive buffer is set in TCP "Window field".

Even within normal TCP exchanges, Window's update is done, but this is displayed when updating when there is no business to send to the other party (Ack for the last received data has also been sent) I will.

The situation indicated by [TCP Window Full]

Finally, [TCP Window Full] , this is the situation that the sending side "has sent off to the limit of the receiving buffer on the receiving side".This is because Wireshark calculates Window and transmission volume, it grasps the situation and displays it bothers me.Expert Info will show " tcp window specified by the receiver is now completely full".

What are the situations where these three indications occur frequently

There are two possibilities.

Processing on the receiving side is merely slow

One is simply that "the buffer on the data receiving side overflows, tells the sender to stop sending data (ZeroWindow), when the buffer is created it tells its capacity (Window Update) and before the client side handles it The sending side sends it to the limit of buffer capacity."

In other words, it is the case that the processing capacity of the data receiving side is very slow compared to the network speed.

In this case, there is no other way to raise specs on the data receiving side.

The data receiving side is controlling the bandwidth

The other is the possibility that the client intentionally created such a condition for bandwidth control.

Specifically, this depends on how to create the application's TCP / IP socket API. For example, if you add the "--limit - rate" option with curl or wget command, or "--bwlimit" with the rsync command, When downloading a certain amount , etc., the client repeats these series of operations to control the speed.

The following is an example of limiting the speed to 100 kbps with curl command.

curl --limit - rate 100k http://www.yahoo.co.jp
In this example, it is easy to understand because it is explicitly executed with the command option, but depending on the application this may not be explicit, so if it seems to occur frequently it is necessary to contact the application development vendor.

コメント

タイトルとURLをコピーしました