Hi, I'm trying to figure out how TCP works when i.e. sending a single image from server to client. I've setup wireshark on both server and client system, and have a complete trace from SYN to FIN on both systems. The image is send in several frames. Wireshark reassembled it nicely. After every third or forth received frame, the client sends an ACK. Why not on every frame? How does the client and server now every packet is received correctly? On the server, wireshark shows these ACK packages at other times then the client shows them (later in time). Is that normal behaviour? Does that have anything to do with WireShark? The packet from the client who sends the ACK has the tcp Sequence number equal to the acknowledgement number of the servers frame it acknowledge. I believe this is correct TCP behaviour, not? Then the sequence number of the next servers frame equals the acknowledgement number of the clients ACK frame. Also normal TCP behaviour? This is correctly seen on the clients wireshark log. But the servers log shows the ACK frames later. If the server would receive that package really later in time, how does the server know the acknowledgement number of the clients ACK frame in advance? This makes me suspect that wireshark log is not in real time with the TCP stack receiving the frames. Could that be? I really would appreciate any answers and/or links to fine documentation about TCP traffic that I currently cannot find. W. asked 04 Feb '11, 05:54  woomla edited 04 Feb '11, 11:03  SYN-bit ♦♦ |
One Answer:
You are doing a nice job in reverse engineering TCP from a packet trace. However, nothing beats a good book on the pretty complicated ins and outs of TCP. Have a look at the following:
As for the time-shift, that is caused by the fact that a packet is traveling across the network which takes time (even if it's only milliseconds). The server does not know in advance what the next ACK number is, it knows which segments it has already sent and will continue with the next blocks. The ACKs from the client just tell the server up till which point the client has received the data. answered 04 Feb '11, 06:12 SYN-bit ♦♦ edited 04 Feb '11, 06:15 |
Wow, thanks for this fast answer. I'll look into the links asap.
In the mean time, I've noticed that the TCP log shows a next sequence number between [ and ]. How does wireshark know this number? Does the server or the client determine this?
Well anyway, thanks again. Have some reading the do!
All fields that wireshark shows between square brackets are fields that don't have corresponding data in the packet, but are generated by Wireshark's knowledge of the protocol.
In case of the next sequence number, it is calculated by adding the length of the TCP payload (Length field taken from IP header minus the IP header length minus the TCP header length) to the sequence number (taken from the TCP header).
Also, usually every other packet is ack'ed, which is easy to see when capturing close to the receiver side. I recommend TCP/IP Illustrated Vol 1, too, got to have that one on the bookshelf ;-)
The receiver will only send out ACKs when it needs to. It will ACK if it had real data to send back, but otherwise it waits until the delayed ACK timer expires. As long as the sender doesn't assume the packet is lost and it has to retransmit then we are good. (Not sure what this timer is but it seems to be by default 200ms in Windows, and as low as 40ms in Linux). Of course the sender cannot send more unACKnowledged segments than the negotiated TCP window allows.
Thanks for all the information. I'm struggling through piles of documentation.
I now have all information for all my questions. This regards transmission that succeeds. Now up to where things go wrong!
@martyvis: thanks for the last bit of missing information. And you've raised a new question for me in your very last line. I'll try to figure this out myself