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

Question

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?

Solution 1

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

Solution 2

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

Comments

[Highland Mark]

Why does line 4 use SEQ 1 again?

[Chris]

Usually, this should be not be 1 again, if it is a new packet. But I assume that the HTTP request is in fact the last packet of the handshake. This is a little unclear in my answer, I'll edit it

[cronor]

Line 4 uses SEQ 1 because ACK packets don't increase the SEQ counter and line 3 is just an ACK.

[cronor]

I don't think it's right now. The ACK in the 3-way-handshake does not contain any data. It is a plain ACK. And that does not increase the sequence number.

[Chris]

In my example it does :) I have a links from my course, but it is in German, but maybe you will understand the important part: www7.informatik.uni-erlangen.de/~eckert/teaching/… (page 131) The 3rd handshake packet contains ACK = SQN_ofServer + 1