Open In App

What is TCP Fast Open?

Improve
Improve
Like Article
Like
Save
Share
Report

TCP handshake takes one full RTT(round trip time). RTT is the time taken by a packet to reach from sender to receiver and back. One RTT is a large amount of time for ‘short-lived’ and ‘time-sensitive’ traffic such as web traffic; web browsing on the browser like visiting a website. The performance degrades further if the propagation delay is very high (e.g., a link between a ground station and a satellite) or if the mobile network is very slow. One RTT does not (significantly) degrade the performance of ‘elastic traffic’ (such as file transfers) because the overhead of one RTT is fairly small relative to the duration of the entire connection.

Lets assume that 1 RTT = 86 ms. this means if a user is visiting www.xyz.com and 86 ms is used in just establishing the connection to XYZ’s server. Every time the user wants to visit the same server 86 ms will get wasted in the same manner. This one RTT is not a big deal when there is file transfer or app updates because these process generally takes minutes or hours of time, a few milliseconds are nothing in front of minutes.

What is TFO?

TFO stands for TCP Fast Open. It is a transport layer solution for avoiding one full RTT between client and server. It avoids TCP-3 way handshake for repeated connections. TFO is proposed by a team from Google and described in RFC 7413.

In a normal TCP connection, one RTT wastes in connection establishments then from the third packet onwards the real communication starts. TFO says that the client can send GET requests in the first packet itself without wasting 1 RTT. But there are some conditions for doing that:

1. It must not be a ‘new’ connection

TFO works only for repeat connections because of the requirement of a cryptographic cookie. For the first time when the client interacts with the server then it has to perform 3 way handshake. In that handshake, the server shares a cryptographic cookie with the client. For the next connection onwards, the client just piggybacks the GET request and cookie in the SYN packet itself. Then server authenticates the client using a cookie accepts the connection request and sends the data in the ACK packet.

2. The total amount of data piggybacked with the SYN packet must be within specified limits.

What is the specified limit? A total of 1460 bytes can be piggybacked into the packet for IPv4. Therefore, the size of one segment becomes 1460 B.

3. Only certain types of HTTP requests can be sent using TFO

GET request is supported. TFO does not support POST requests because if it allows writing operations on the server then hackers can perform malicious activities which can cause severe harm to the server.

Working of TFO:

TCP Client and Server both must support TFO in order to use it. Now the question arises how do the client and server let each other know that they support TFO? The answer lies in the TCP header. 

The ‘Options’ field in the TCP header is used for TFO.

  • TCP Client uses it for requesting a TFO Cookie
  • TCP Server uses it for sending a TFO Cookie

In the options field, the Kind variable stores a value of 34 for the cookie. The length of the cookie is 16 bytes. When a client sends the SYN packet to the server then it sets the Kind = 34 in the options field. When the server sees the kind value equal to 34 it understands that client supports TFO and requests for cookies. The server generates a unique cookie and encrypts it using the IP address of the client so that each client has a unique cookie. In the options filed server sends the cookie to the client. 

So, using the options field client and server let each other know that they support TFO and share cookies.

Look at the diagram carefully and observe the connection establishment with and without TFO.

gfg

Does TFO support conditional GET requests?

It should support conditional GET. GET requests are basically read-only operations. So, they should be permitted by TFO. It should not be seen in terms of the time delay. Conditional GET requests are basically sent from the local server to the central server when the data at the local server is stale and couldn’t be served to the client. In that case, fresh data is fetched from the central server and cached into the local server to serve the local clients. 

Linux command line: 

Playing around with TFO in the Linux Kernel by using some commands:

Checking the default setting of TFO in the Linux Kernel

$ sysctl net.ipv4.tcp_fastopen

Expected Output (it means that TFO is enabled on the Client):

$ net.ipv4.tcp_fastopen = 1

Enabling TFO if your machine is a Server

$ sudo sysctl -w net.ipv4.tcp_fastopen=2

Expected Output:

$ net.ipv4.tcp_fastopen = 2

Enabling TFO if your machine is a Client as well as a Server

$ sudo sysctl -w net.ipv4.tcp_fastopen=3

Expected Output

$ net.ipv4.tcp_fastopen = 3

Disabling TFO

$ sudo sysctl -w net.ipv4.tcp_fastopen=0

Expected Output

$ net.ipv4.tcp_fastopen = 0

Last Updated : 01 Mar, 2024
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads