Why server cannot send data in TCP three-way handshaking?

Question

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).

Answer 1

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.