Home/ Questions/Q 4242656
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T03:28:19+00:00

I’m confused about the ACK and SEQ numbers in TCP packets right after the

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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
    • 0