当前位置：网站首页>Neutral energy optimization of transport layer triple handshake

Neutral energy optimization of transport layer triple handshake

2022-07-18 21:56:00 【Zhang quandan, Foxconn quality inspector】

Example of the server three-time handshake process

After understanding the state changes in the three handshakes , We can further explore some characteristics of the client and server in the implementation . In this way, we can know how to optimize the performance , And some security attacks in the handshake .

First, take the server as an example , Let's take a look at the process of three handshakes .

First, the client sends syn The packet arrived at the server , Server kernel , That is to say tcp The implementation of the , Will syn Group inserted into syn In the opposite column , At the same time syn+ack, At this time, the connection status is syn-received The state of , When will it come from syn-received The status changes to establish The state of ？ It will send again on the client ack After grouping, you will enter establish Status quo .

But in fact, the operating system kernel will syn from syn Move out of the queue , Insert again accept queue , So our application nginx tomcat Calling accept The method is from accept The queue will take out the previous connection to the relevant methods to use .

So you can see this in the process syn Queue length and accept The queue length is related to our load .

If you are facing a machine with a high load of hundreds of thousands of requests per second , So right. syn Queue and accept The queue also needs to be extended .

Timeout and buffer queue

How is it right syn accept The queue will be extended ？

Client optimization

• application layer connect Timeout adjustment （ The client can also adjust , Client calls connect Method time , There is usually a connect_timeout, Set the timeout ）

Server optimization

• Operating system kernel limit adjustment

• Server side SYN_RCV state

• net.ipv4.tcp_max_syn_backlog：SYN_RCVD The maximum number of state connections （ adjustment sync The size of the queue ）

• net.ipv4.tcp_synack_retries： When passively establishing a connection , Hair SYN/ACK Number of retries （ When we send SYN/ACK after , I haven't got it for a long time ack Respond to , We may have to resend SYN/ACK Number of retries ）

client SYN_SENT state

• net.ipv4.tcp_syn_retries = 6 When actively establishing a connection , Hair SYN Number of retries （ The client has finished sending syn, In fact, I entered syn_sent state , stay syn_sent In state , about linux Load balancing above , Or when establishing a large number of connections to other servers , It can also be done through syn_retries To set retransmission syn Number of retries ）

• net.ipv4.ip_local_port_range = 32768 60999 The available range of the local port when the connection is established （ Delimit a larger range of source ports ）

• ACCEPT Queue settings （ You can also go through backlog Set up ）

Fast Open Reduce delay

Is there room for further optimization in the three handshakes ？

For example, launch http get Request , It takes three handshakes , issue syn Receive a syn+ack, next ack One of them http get request , There are actually two rtt Time for .

tcp A name is provided fast open The function of , What is it doing ？ The first time to establish a connection ,server Will generate a cookie, Sending syn+sck When , take cookie Gave us client,client Will cache this cookie, So the first time you initiate a connection, you still need to provide two rtt Only then get Request to be sent out , And receive the other party's response .

But when sending the request for the second time , We skipped three handshakes , because cookie It maintains the information related to the last connection , Like windows , Time stamp and so on tcp Option parameters for .

Direct will cooki stay syn Middle issue server, And you can put get The request is also sent to server, In this way... Is used tcp fsat open. In fact, three handshakes are eliminated rtt Delay of .