Why is ACK = 1 and not 2 in the first TCP request after establishing a connection?

Question

I am confused about the ACK and SEQ numbers in TCP packets right after a three-way handshake. I thought the ACK was the next expected SEQ. So when I analyze the 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 that the sender expects SEQ = 2, so should it be ACK = 2? There was already a packet with SEQ = 1 from the server, why does the sender want another?

Can someone explain this to me?

Answer 1

Well, in a 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 the packet with SEQ = 1 now." You got this right.

Now, in the last part of the handshake, the client sends SEQ = 1 and ACK = 1, which basically means the same as on the server: "I'm waiting for your package with SEQ = 1 now"

But: after the TCP connection is established, the client usually does not wait until this packet is disconnected, but rather sends the first data packets (in fact, the data may already be contained in the last handshake packet - I assume this is the case in your example, because the HTTP request has same SEQ as the last acknowledgment packet). So any next packet again has ACK = 1. But why? He again says: "I am waiting for the package with SEQ = 1 from you." And that makes sense: the last packet received by the client from the server had SEQ = 0 (in a handshake). Also keep in mind that both the client and server have independent SEQs. This means that the client could send 100 packets. Until the server sends it, the client will still wait for ACK = 1, because the last packet it received from the server hat is SEQ = 0

Other Editing: To really understand what is happening, you can choose an example with different initial SEQs (I already wrote it, the server and client SEQs 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 

Answer 2

Confirmation number (32 bits) - if the ACK flag is set, the value of this field will be the next sequence number that the receiver expects. This confirms the receipt of all previous bytes (if any). The first ACK sent by each end confirms the number of the initial initial sequence itself, but does not contain data .

So they just confirm where to start.

TCP on Wikipedia