TCP fastopen is used inside the origin server to quickly return to the source

background

The threshold for each live broadcast platform anchor to start broadcasting is very low , There are a lot of unpopular anchors , There are also very few anchors that produce quality content . The main flow is concentrated in the head 5%～10% Our live room , Therefore, there are a large proportion of unpopular rooms , The number of visitors is very small .

A lot of cdn Or origin station , It's all multilayer , Most of the data transmission before the layer is through the external network . In order to reduce the loss of internal data transmission , Without an audience , Both the edge and the middle layer will stop pulling , Only the central node has live stream data . When an audience comes to watch , It will go back to the source step by step . Each level will recreate a new back to source connection .tcp The connection establishment phase is at least 1+RTT, Multi level connection establishment , Add up , The time spent will be more objective .

Solution

In order to reduce the time of returning to the source , It is suggested that tcp When the connection is established , Turn on tcp fastopen.

The following figure shows the normal connection establishment , And launch http get Request . stay ack When , launch http get request , Time consuming 1RTT+.

The following figure shows the opening tcp FastOpen, It can be done 0RTT. Greatly reduce the time to establish a connection .

The process when the client first establishes a connection ：

1、 The client sends SYN message , The message contains Fast Open Options , And this option is Cookie It's empty , This indicates that the client requests Fast Open Cookie;

2、 Support TCP Fast Open The server generated Cookie, And put it in SYN-ACK In the packet Fast Open Option to send back to the client ;

Client received SYN-ACK after , Local cache Fast Open Options Cookie.

therefore , First launch HTTP GET On request , Still need the normal three times handshake process .

after , If the client establishes a connection to the server again ：

1、 The client sends SYN message , The message contains 「 data 」（ For non TFO Ordinary TCP Handshake process ,SYN The message does not contain 「 data 」） And what was recorded before Cookie;

2、 Support TCP Fast Open The server will receive Cookie check ： If Cookie It works , The server will be SYN-ACK In the message SYN and 「 data 」 Confirm , The server will then 「 data 」 Delivery to the appropriate application ; If Cookie Invalid , The server will discard SYN The message contains 「 data 」, And then it sent out SYN-ACK The message will only confirm SYN The corresponding serial number of ;

3、 If the server accepts SYN In the message 「 data 」, The server can send 「 data 」, This reduces the amount of handshake 1 individual RTT Time consumption of ;

4、 The client will send ACK Confirm that the server sent back SYN as well as 「 data 」, But if the client is in the initial SYN Sent in a message 「 data 」 Not confirmed , The client will resend 「 data 」;

5、 After that TCP Connect the data transfer process and non TFO The normal situation is consistent with .

therefore , And then it started HTTP GET On request , You can bypass three handshakes , This reduces the amount of handshake 1 individual RTT Time consumption of .

tcp fastopen be relative to quic, No additional development and adaptation is required , Reuse existing architecture , Can be realized 0RTT.

The optimization effect

according to 3 Layer back to source , Between servers RTT about 20ms, In the cold flow scenario , Can be reduced by about 40ms Delay . Server clusters are generally cross regional , The optimization effect will be more obvious .