1

In the three-way handshaking, only from the ACK packet we can send data. Why cannot the server send data with SYN-ACK packet? I understated why a client cannot send data to a server (preventing, for example, SYN flooding, of a malicious client), but why the server cannot send data, for example, a certification of the server?

From what I understand, it won't be problematic for both client and server.

From the client view, in the three way handshaking already knows the server ISN using the SYN-ACK packet, and it can create its connection without no problem (which, already happens in three-way handshaking).

From the server view, we don't need to create a receiving buffer on its kernel space. The sending buffer, can also be reduced effectively, if, for example, the second data is constant for all sockets (for example, a certification and a public key of the server).

  • What you seem to experience is a host OS implementation restriction, and that is actually off-topic here. The answer below explains the on-topic protocol theory, but what a host actually does is off-topic here. – Ron Maupin Jun 2 at 5:28
  • 1
    By the way, TCP does not have clients or servers. TCP establishes connections between peers. The client server concept is an application concept, which is off-topic here. – Ron Maupin Jun 2 at 6:56
5

Data can in theory be send together with SYN but should not be delivered to the application until the state of the connection is ESTABLISHED. To cite from 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).

This means both client and server can in theory send data within the SYN. But the clients data should only be delivered to the server app once the final ACK is received and thus ESTABLISHED is reached on the server side. Whereas data from the server within a SYN+ACK can be delivered immediately to the client since the clients state is ESTABLISHED once the SYN+ACK is received as can be seen from the example taken from the RFC:

      TCP A                                                TCP B

  1.  CLOSED                                               LISTEN
  2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
  3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED   
  4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED    
  5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

With TCP Fast Open even the restrictions on the client side can be removed in some cases.

But usually no data are included in the TCP handshake since the default socket API does not support this use case: there is only a connect which does the handshake on the client side and an accept on the server side and both cannot take any data to be delivered inside the handshake.

  • Are the problems of capturing old or duplicate SYNs might occur in the above scenario? I understand these problems if the client the one sending the data, but not the server.. – user3563894 Jun 2 at 6:02
  • I mean, why does the client application does not allows the data to be delivered? – user3563894 Jun 2 at 6:21
  • @user3563894: I've changed the answer to hopefully address this point, i.e. a payload inside a SYN+ACK from the server can actually be delivered to the application immediately. – Steffen Ullrich Jun 2 at 6:46
  • Thanks! This is very interesting that a SYN+ACK packet can carry data... – user3563894 Jun 2 at 6:54

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.