Hello all, I would some assistance to understand a strange behavior. I did a network capture during a FTP transfer between a client and a server client = 10.212.44.10 Server = 131.97.141.59 The transfer of data is from the client to the server. During the capture I see some packets from the client with the information "TCP window full". I understand what means this message, but I don't understand why I see it since the Windows size of server doesn't seems full. Here you can see a part of my network capture ==> http://cloudshark.org/captures/8c7b896a2978 Could you explain me the reason of this behavior ? Best regards asked 03 Feb '14, 09:48  any-one edited 03 Feb '14, 10:05  grahamb ♦ |
One Answer:
The capture shows that the server 131.... is getting further and further behind. Note that the acks eventually lag 64K (65792) bytes behind the sender sequence number and thus the pipeline is full. Since the advertised window from 131... is 64 K(65792) at this point the sender will only send bytes as acks are received to "open the window". What I do find a bit interesting is that the window size in the acks from 131... always say 64K. Also: re "Freqequent acks": that's the way tcp works: Normally every other frame is ack'd. So: bottom line: your server has some kind of a performance problem. [Update] Or: maybe not the server but the network somehow. If the network (firewall, etc) is buffering the frames before they reach the server, then that might explain why the advertised window from the server never shrinks. answered 03 Feb '14, 10:38  Bill Meier ♦♦ edited 03 Feb '14, 11:07 How do you see that ? I don't really understand. Could you explain a little bit more ? ((I converted your answer to a comment in keeping with the way this site works. Please see the FAQ). (03 Feb '14, 11:08) any-one I'm not sure what you are referring to in "how do you see that ?"
Note that the sequence numbers are equivalent to "byte number" since every byte sent increases the sequence number by 1.
So: the bytes must be in the pipeline since they apparently haven't yet reached the server. [Update] A way to see the amount of data in the pipeline is to create a 'custom column' showing the field 'tcp.analysis.bytes_in_flight'. (03 Feb '14, 11:34) Bill Meier ♦♦ Maybe your upload to .... is being speed limited ?? :) (03 Feb '14, 11:56) Bill Meier ♦♦ Yes the wan is limited to 5Mbps (03 Feb '14, 12:08) any-one Something a bit less than 5 Mbps is, in fact, the final steady state throughput seen in the capture. Do "Statistics ! TCP Stream Graph ! Throughput Graph" to see a graph. (03 Feb '14, 12:21) Bill Meier ♦♦ If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information. (03 Feb '14, 12:23) Bill Meier ♦♦ I'm used to use the "IO graph" function. There you can display traffic client to server or server to client or what ever you want. this is more useful. (04 Feb '14, 00:03) any-one If you look on packet 119 (from the client to the server) we can see the message "TCP windows full". seq nbr = 130 313 Len = 1352 Then the in flight data is equal to the difference between the last ACK (from the server) and the sum of the current seq nbr and the Lenght seq nbr + Len = 131 665 previous ACK (packet 116) is 65873 131655 - 65873 = 65 792 which is exactly the Server's windows size This is why Wireshark display the message "TCP windows size full". Now I understand why the message is displayed. But I still don't understand why the server is facing this behavior. The next ACK (packet 120) is the acknowledgement of the packet 64 sent from the Client. This packet was sent 78ms before. This laps time is close to the RTT. (04 Feb '14, 01:07) any-one Is there an easy whay (using Wireshark) to calculate elapsed time between packet sent by the Client and Acknoledgement sent by the Server ? it seams the server is facing some slowness cause I see often more than RTT between packet sent to the server and the acknowledgement. For instance RTT = 50 - 70ms but I see sometimes more than 100ms between packet sent to the server and the acknowledgement. Thanks for your help Edit : I found something. In the ACK packet (from the server)in the "SEQ/ACK analysis" we can display the "RTT to ACK the segment". (04 Feb '14, 02:41) any-one Think of it this way: The WAN is limited to 5 Mbps; So: the server will only receive data at that rate and will send acks only as the data is received. After steady state is reached (with a constant 65K bytes queued [buffered in the WAN router or whatever] waiting to be sent over the WAN), the RTT from sent to ack will be approximately the time it takes the data (65Kbytes) to get through the queue before being sent over the WAN. So: the steady state RTT will be on the order of 100ms: (65K bytes * 8 bits/byte) / 5 MBits [Updte: Actually: this doesn't seem quite right since the actual RTT (other than the queue time) doesn't seem to be accounted for]. The "Statistics ! TCP Stream Graph ! Round Trip Time Graph" shows this quite clearly. The server itself is doing fine. (04 Feb '14, 07:54) Bill Meier ♦♦ showing 5 of 10 show 5 more comments |
moreover, I don't really understand why the server is sending so frequent acknowledgement. This is a FTP transfer, so the server should wait lot of packets before send a new acknowledgement.