Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is ACK = 1 and not 2 in first TCP request after connection establishment?

I'm confused about the ACK and SEQ numbers in TCP packets right after the 3-way-handshake. I thought the ACK number is the next expected SEQ number. So when I analyse a TCP connection in Wireshark it says

TCP SYN with SEQ=0  
TCP SYN ACK with SEQ 0, ACK=1 (clear, server expects SEQ 1 in next packet)  
TCP ACK with SEQ 1, ACK=1 (clear, sender expects SEQ 1 in next packet)  

HTTP Request: TCP PSH ACK with SEQ 1, ACK=1

The last line is unclear. I would say the sender expects SEQ=2 next, so it should be ACK=2? There was already a packet with SEQ=1 from the server, why does the sender want another one?

Can someone explain this to me?

like image 424
cronor Avatar asked Apr 05 '11 12:04

cronor


2 Answers

Well, in the handshake the client receives only one packet from the server: SEQ=0 and ACK=1. With this information, the server tells the client 'I am waiting for a packet with SEQ=1 now'. You got this right.

Now, in the last part of the handshake the client sends a SEQ=1 and ACK=1, what basically means the same thing as from the server: 'I am waiting for your packet with SEQ=1 now'

But: After a TCP handshake, the client will usually not wait for this packet to be acked, but rather send the first data packets already (in fact, data may already be contained within the last packet of the handshake - I assume this is the case in your example, because the HTTP request has the same SEQ as the last handshake packet). So any next packet again has ACK=1. But why? It again says 'I am waiting for a packet with SEQ=1 from you'. And this completely makes sense: The last packet the client received from the server had SEQ=0 (in the handshake). Also keep in mind, that both client and server have independent SEQs. That means, that the client could send 100 packets. As long as the server did not send one, the client would still be waiting for ACK=1, because the last packet he received from the server hat SEQ=0

Another Edit: To really understand what is going on, you might want to choose an example with different beginning SEQs (I already wrote it, SEQs of server and client are independent):

Client -> SYN, SEQ=100
Client <- SYN, ACK, SEQ=700, ACK=101 <- Server
Client -> ACK = 701, SEQ=101 [50 Bytes of data]
Client -> ACK = 701 [Again, didn't receive sth from server yet], SEQ = 151
like image 69
Chris Avatar answered Oct 14 '22 21:10

Chris


Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.

So they just acknowledge where they should start from.

TCP on Wikipedia

like image 42
bogdan.mustiata Avatar answered Oct 14 '22 20:10

bogdan.mustiata