三次握手的过程在一个 HTTP 请求的平均时间占比 10% 以上,所以要正确使用三次握手的中参数,需要先用netstat命令查看是哪个握手阶段出了问题,主动发起连接的客户端优化相对简单些,而服务端需要监听端口,属于被动连接方,其间保持许多的中间状态,优化方法相对复杂一些。
三次握手建立连接的首要目的是「同步序列号」。只有同步序列号才有可靠传输,SYN 的全称就叫 Synchronize Sequence Numbers(同步序列号)。
客户端作为主动发起连接方,首先发送SYN包,于是客户端连接会处于SYN_SENT状态,客户端没有收到服务端传过来的ACK+SYN就会重传SYN,重发的次数由 tcp_syn_retries 参数控制,默认是 5 次;每次超时时间是上一次的2倍。可以根据网络的稳定性和目标服务器的繁忙程度修改 SYN 的重传次数,调整客户端的三次握手时间上限。
要想增大半连接队列,不能只单纯增大 tcp_max_syn_backlog 的值,还需一同增大 somaxconn 和 backlog,也就是增大 accept 队列。否则,只单纯增大 tcp_max_syn_backlog 是无效的。
开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接。
客户端收到服务端的ACK+SYN后恢复ACK给服务器,同时客户端连接状态由SYN-SENT变为ESTABLELISHED,表示连接建立成功,服务端需要接收到客户端的ACK才会变成ESTABLELISHED,如果没收到客户端的ACK就会重传ACK+SYN同时一直处于 SYN_RCV 状态。
当网络繁忙、不稳定时,报文丢失就会变严重,此时应该调大重发次数。反之则可以调小重发次数。修改重发次数的方法是,调整 tcp_synack_retries 参数。
服务器收到ACK后建立连接成功,此时内核会把连接从半连接队列中移除,然后创建新的完全连接,并将其添加到accept队列,等待进程调用accept函数时把连接取出来。
如果进程不能及时地调用 accept 函数,就会造成 accept 队列(也称全连接队列)溢出,最终导致建立好的 TCP 连接被丢弃。
netstat -s 可以隔几秒钟执行下,如果这个数字一直在增加的话,说明 accept 连接队列偶尔满了。
TCP Fast Open 功能需要客户端和服务端同时支持,才有效果,使得 HTTP 请求减少了 1 个 RTT 的时间
主动方优化,关闭连接的方式通常有两种,分别是 RST 报文关闭和 FIN 报文关闭。
调用了 close 函数意味着完全断开连接,完全断开不仅指无法传输数据,而且也不能发送数据。 此时,调用了 close 函数的一方的连接叫做「孤儿连接」,如果你用 netstat -p 命令,会发现连接对应的进程名为空。
使用 close 函数关闭连接是不优雅的。于是,就出现了一种优雅关闭连接的 shutdown
函数,它可以控制只关闭一个方向的连接:
第一次挥手 ,调整tcp_orphan_retries参数,降低
主动方收到ACK后进入FIN—WAIT2状态,表示主动方的发送通道已经关闭,接下来将等待对方发送FIN报文,关闭对方的发送通道。
如果此时连接使用shutdown函数关闭的,连接可以一直处于FIN—WAIT2状态,因为还可以继续发送或接收数据。但是对于close函数关闭的孤儿连接,由于无法再发送和接收数据,所以这个状态不可持续太久,,而 tcp_fin_timeout 控制了这个状态下连接的持续时长,默认值是 60 秒:
当进程调用了close函数关闭连接,此时连接就会是孤儿连接,因为无法再发送和接收数据,有个tcp_max_orphans孤儿连接数量参数,大于他就不再走tcp四次挥手直接RST复位报文关闭。
①:防止历史连接的数据,被后面相同四元组的连接错误接收:2MSL这个时间足以让两个方向上的历史数据包都被丢弃,使得原来连接的数据包在网路中都自然消失,再出现数据一定都是新建立连接所产生的。
②:保证被动关闭连接的一方,能被正确关闭 :等待足够长的时间使得ACK能让被动关闭方接收,从而帮助其正确关闭。
tcp_max_tw_buckets 参数,当 TIME_WAIT 的连接数量超过该参数时,新关闭的连接就不再经历 TIME_WAIT 而直接关闭,并发增多,可以适当增大这个数量,也不是越大越好,资源有限。
tcp_tw_reuse 和 tcp_timestamps 设置为1,只作用在 connect 函数,也就是客户端,将TIME_WAIT状态的端口复用作为客户端的新连接,只适用于客户端。
被动方收到FIN就开始进入close_wait状态,等待进程调用close函数关闭连接。因此,出现大量CLOSE_WAIT状态的连接。
TCP提供一种可以让发送方数据根据接收方的实际接收能力控制发送的数据量-滑动窗口
内核接收到报文,必须使用缓冲区存放他们,这样剩余缓冲区空间变小,接收窗口也变小;
进程调用read函数,报文被读入内存空间,内核缓存被清空,主机可以接收更多的报文,窗口大。
接收方把报文大小放到TCP报文头部的窗口字段中
默认的滑动窗口最大值只有 64 KB,不满足当今的高速网络的要求,要想提升发送速度必须提升滑动窗口的上限,在 Linux 下是通过设置 tcp_window_scaling
为 1 做到的,此时最大值可高达 1GB。
发送缓冲区是自行调节的,当发送方发送的数据被确认后,并且没有新的数据要发送,就会把发送缓冲区的内存释放掉。
接收缓冲区可以根据系统空闲内存的大小来调节接收窗口:
发送缓冲区的调节功能是自动开启的,而接收缓冲区则需要配置 tcp_moderate_rcvbuf 为 1 来开启调节功能
,我们应该把缓冲区的上限设置为带宽时延积。发送缓冲区的调节功能是自动打开的,而接收缓冲区需要把 tcp_moderate_rcvbuf 设置为 1 来开启。其中,调节的依据是 TCP 内存范围 tcp_mem。
通过 tcp_mem 配置完成一般情况下这些值是在系统启动时根据系统内存数量计算得到的