Series 06- TCP connection management -5, TCP fastopen (TFO)

====================================================||

Welcome to the discussion of technology can add another micro letter: windgs (please note csdn + xx occupation)

====================================================||

table of Contents

A, TFO background

Two, TFO process

Three, SYN packet duplicate data submitted


A, TFO background

        Current web and web-like applications are generally in the three-way handshake after the start of data transmission, compared to the UDP, a plurality of the RTT delay, even if the current application using many long connection to handle this situation, but still a certain percentage the short connection, which is an additional RTT still have a very big impact on latency applications. TFO is in this context that the following initiative.

        TFO (TCP fast open) is an experimental TCP protocol update, which allows the server and client to establish the connection to exchange data handshake phase, so that the application saves a RTT delay. But TFO will cause some problems, so the protocol requires TCP implementation must be disabled by default TFO. TFO function needs to be enabled on a service port when needed application displays enabled.

Two, TFO process

1. Before using TFO, client first need to pass an ordinary three-way handshake connections to obtain FOC (Fast Open Cookie)

  • 1.client sends a SYN packet with a Fast Open option, while carrying a cookie field empty to request a cookie

  • 2.server generates a cookie, and then back to the client by Fast Open option SYN-ACK packet

  • 3.client this cookie cache for future use when using TFO connection

2. Implementation of TFO

  • 1.client sending a SYN packet with data, while carrying cookie previously acquired through the normal connection options Fast Open

  • 2.server verify this cookie. If this cookie is valid, server will return SYN-ACK packet, then the server sends the received data to the application layer. If the cookie is not valid, server will lose data SYN packet, and returns a SYN-ACK packet to confirm the serial number of SYN packets

  • 3. If a valid cookie, server may send a response to the client before the data connection is completed, limiting the amount of data carried by TCP congestion control (RFC5681, congestion control will be introduced later in the article).

  • 4.client acknowledgment ACK packet is transmitted to the server and data SYN, SYN packet data if the client terminal has not been confirmed in the server, client retransmits the data corresponding to the ACK packet

  • 4. The remaining connections on a similar deal with the normal TCP connection, client once to get FOC, Fast Open can be repeated until the cookie expires.

 

       Through the entire process, we can see the core TFO is a secure cookie, the server uses this cookie to authenticate to the client. In general this cookie should be able to authenticate the source IP address of the SYN packet, and can not be forged by a third party. To ensure safety, after some time, server should expire cookie before, and regenerate the cookie. By cookie validation, server when sending the SYN-ACK, if the data to be transmitted can also carry data.

      client cookie cache when the cache is also recommended protocol Maximum Segment Size (MSS), MSS represent the largest segment of TCP end to receive, so that client in the implementation of TFO, SYN packets can carry amounts of data will have a reference. Even cached MSS, also suggested that the SYN packet client should not exceed a typical MSS, namely IPV4 and IPV6 of 1460bytes of 1440bytes. If no cache MSS, this can SYN packet data size limit in the default MSS, IPV4 is 536bytes (RFC1122), IPV6 is 1220bytes (RFC2460).

     When data is received before the client server but no ACK SYN packet sent by itself, or ICMP error or no response is received when the SYN-ACK, the client should be at least temporarily disable the corresponding functions on TFO connection path.

        Under TFO scenario, client SYN packet retransmission timeout and retransmission timeout server SYN-ACK packet when Fast Open option should be removed and the corresponding data, so due to incompatibility caused TFO connection fails.

Three, SYN packet duplicate data submitted

        As the data in the TFO SYN send could be submitted to repeated application layer. For example, when unreliable transport layer is IP, the sender of a packet to be transmitted into two SYN SYN packet, at the receiving side, after receiving the first SYN packet, the receiving end with the transfer of data to the application layer SYN , followed by the connection end of the closing operation is initiated by sending a TCP connection, the receiving end will not enter the protected TIME_WAIT state (described later in TIME_WAIT), and then continued to receive the second repeat data packet with the SYN transmission might again pass to the application layer. Therefore, if the application layer packet can not tolerate such a repetition can not turn TFO characteristics.

Four, wireshark capture

In the following wireshark capture in limited space, only a brief introduction to several related packages, detailed message content after download wireshark packet capture file to open its own view

No1: the first client to initiate a common connection with a FOC option in the SYN packet to the server request cookie (No1 represent wireshark screenshot packets No1 number of subsequent articles using similar representation)

No2: server side replies SYN-ACK packet, which carries a FOC option, Cookie domain 0x1a39d8e2100b247e

Immediately after the client sends a "hello" message to close the connection

No7: client re-initiate a connection, you can see this SYN packet Len = 5, I actually sent a "world", is just 5bytes, as the syn packet is sent to the server, pay attention to this port is 57522 and cilent a connection port 57520 and different, but can still be used for the first time acquired FOC send data, and client port FOC is irrelevant.

 

Supplement

1.TFO introduction  https://www.ietf.org/proceedings/80/slides/tcpm-3.pdf

2.RFC7413  Https://datatracker.ietf.org/doc/rfc7413/?include_text=1

3. The original RFC793 protocol also allows the transfer of data in the TCP handshake process, but can not be submitted before the connection is established to the application layer, the linux implementation does not support carrying data in a non-TFO scene handshake.

Guess you like

Origin blog.csdn.net/Windgs_YF/article/details/94741944