3

Question is not a duplicate of this link. As that asks why we need a 3 way hand shake and I know why! my question is why cannot the ACK packet be accommodated by the following protocol packet(PSH ACK).

I get why is there a need of an handshake, but do we need the ACK in the end from the initater? Lets take an example of an http query which was followed by a TCP handshake.

CLIENT:23434 SN 0 -----> SERVER:80 -- SYN
CLIENT:23434 <----- SERVER:80 SN 0, AN 1 -- SYN ACK
CLIENT:23434 SN 1 AN 1 -----> SERVER:80 -- ACK
CLIENT:23434 SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)

Now if there was to be a protocol(data) packet followed by the ACK of three way handshake with the same sequence number and acknowledgement number, Why have the ACK packet why not use the protocol packet only to synchronize?

  • The question you have tagged is not the same as this. As that asks why we need a 3 way hand shake and I know why! my question why cannot the ACK packet be accommodated by the following protocol packet. Please read the question carefully. – Anirudh Malhotra Oct 31 '16 at 18:30
  • ACKs often contain data, too. You may be really confusing yourself with client/server since TCP has no such idea. – Ron Maupin Oct 31 '16 at 18:37
  • Yes I know that they contain data but they have the same sequence and acknowledgement numbers as the ACK packet of TCP. So why can't they be considered as part of syncing(acknowledgements) of sequence number and acknowledgement number? by client server I only meant initiator and respondent! – Anirudh Malhotra Oct 31 '16 at 18:43
  • Normally, the first ACK will contain the data. It really depends on the TCP implementation, and that varies by OS, or even different OS versions. I haven't seen an sequence such as you have in your answer. RFC 793 details how it all works, but there are variations. – Ron Maupin Oct 31 '16 at 18:50
  • " I haven't seen an sequence such as you have in your answer. " -- These are relative sequence and ack numbers. A wireshark capture will show you numbers like these only. Or you can see the examples. The original question: if the ack number is same on TCP handshake ACK packet and subsequent protocol(data) ACK packets. If you may please un-duplicate it, others may answer. Thanks! – Anirudh Malhotra Oct 31 '16 at 19:01
2

It sounds like you're asking why, if the client sends data first, the client cannot combine the bare handshake ack with that data.

But I think it can - it just generally doesn't do so. Operating system APIs are the typical reason.. a socket won't normally accept data to be write()n when it isn't in the established state and the kernel, upon seeing syn/ack, isn't going to wait to see if userspace sends along some data before sending the ack. (as the kernel doesn't know which end of this bidi connection is going to write first - and the other end can't write until it gets the completed handshake).

If a system did send data on the 3rd part of the handshake at this point, against such tradition, they might very well find they had interop problems in doing so.. so there is a disincentive in trying to push the envelope.

| improve this answer | |
2

Great question. I agree that this is not a duplicate of the other.

The goal of the three-way handshake is to establish a bidirectional communication channel. The communication that happens within that channel is outside the scope of TCP.

Sometimes, a connection is established for the Client to send something to the Server. Other times a connection is established for the Server to send something to the Client. TCP must account for both of these cases.

Re-quoting your communication illustration for simplicity and adding line numbers:

#1   SN 0 -----> SERVER:80 -- SYN
#2   <----- SERVER:80 SN 0, AN 1 -- SYN ACK
#3   SN 1 AN 1 -----> SERVER:80 -- ACK
#4   SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)

If the protocol using TCP behaves like HTTP, where the first data transmission after the connection establishes is the Client sending data to the Server, then you're right to say the lone ACK (line #3) seems superfluous. The packet immediate following (line #4) would suffice tell the Server that the Client received their ISN (from line #2).

However not all protocols behave like HTTP -- some protocols mean for the Server to send the data immediately after the connection establishes. In those cases, the server must wait for the client to send the empty acknowledgement packet before it comes to acquire positive confirmation that the bidirectional communication channel is successfully established and data transfer can begin.

This is more rare in the Internet, but it does exist. Offhand, I can think of Passive FTP, where the client initiates the data connection (aka, sends the initial SYN) but the purpose of the connection is for the server to send the initial data packet -- which starts as soon as the data connection is established.

TCP can not behave one way for certain protocols and another way for other protocols. Hence, the empty acknowledgement must be sent so that both scenarios are accounted for.

| improve this answer | |
  • 1
    there is no such specification to consider that who send data first , you can read the rfc 793 section 3.4 , saying synchronization using data-carrying segments, this is perfectly legitimate . the only condition is the data will not be delivered to the application , it will be buffered – Arjun sharma Nov 1 '16 at 12:34
  • you can also consider the TFO (tcp fast open option) which allows to send data even with tcp syn – Arjun sharma Nov 1 '16 at 12:35
1

Yes , There is a need of empty ack to acknowledge the syn sent from other end

(closed) A <syn>----------> B (listen) 
(syn-sent) A <------------<syn><ack> B (listen) 
(established) A               B (syn-sent)

As after these steps B is waiting for an ACK from A for the SYN, to reach a Connection established state.

But the interesting case you discussed here is the possibility of minimizing the next step

  (established) A <ack>-----------> B (syn-sent)
  (established) A [data>]<ack>-----------> B (established)

with

 (established) A [<data>]<ack>-----------> B (syn-sent)

But as seems to , B is in non established state it don't seems to entertain the payload

In RFC 793 ( section 3.4. Establishing a connection )

Several examples of connection initiation follow. Although these examples do not show connection synchronization using data-carrying segments, this is perfectly legitimate, so long as the receiving TCP doesn't deliver the data to the user until it is clear the data is valid (i.e., the data must be buffered at the receiver until the connection reaches the ESTABLISHED state)

so from rfc it seems

4 SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)

will be buffered and will be delivered to the application only after an empty ack following it

Your solution may work for a implementation called delayed ack

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.