blog | percy

life

0%

tcp之连接优化

发表于 更新于 分类于

[TOC]

基础

  • RTT（从客户端到服务器一个往返的时间），Round-trip time
  • MSL 是Maximum Segment Lifetime， 最大报文生存时间， 任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
  • TTL是 Time To Live的缩写，该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。

TCP 三次握手的性能提升

linux 在握手过程中 会维护两个队列

  1. 一个存放 SYN 的队列（半连接队列）
  2. 一个存放已经完成连接的队列（全连接队列）

优化方案总结

客户端优化

  • 当客户端发起 SYN 包时，可以通过 tcp_syn_retries 控制其重传的次数。

服务端优化

  • 增大 tcp_max_syn_backlog
  • 开启 syncookies 功能
    • 服务端回复 SYN+ACK 的重传次数由 tcp_synack_retries 参数控制。如果遭受 SYN 攻击，应把 tcp_syncookies 参数设置为 1，表示仅在 SYN 队列满后开启 syncookie 功能，可以保证正常的连接成功建立。
  • 调整 accept 队列长度
  • TCP Fast Open 功能可以绕过三次握手，使得 HTTP 请求减少了 1 个 RTT 的时间，Linux 下可以通过 tcp_fastopen 开启该功能，同时必须保证服务端和客户端同时支持。

服务端优化 && 半连接队列

当服务端收到 SYN 包后，服务端会立马回复 SYN+ACK 包。服务端此时的状态是 SYN_RCV。在这个状态下，Linux 内核就会建立一个「半连接队列」来维护「未完成」的握手信息，当半连接队列溢出后，服务端就无法再建立新的连接。

半连接队列

SYN 攻击，攻击的是就是这个半连接队列。那么如果出现 SYN 攻击时或者其他情况，需要查看半连接队列已满导致的连接失败的情况时，或者优化时，如何操作。

1
2
3
4
5
6
7
8
9
# 1. 如何查看由于 SYN 半连接队列已满，而被丢弃连接的情况
netstat -s | grep "SYNs to LISTEN"

# 70 SYNs to LISTEN sockets dropped

# 上面输出的数值是累计值，表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次，如果有上升的趋势，说明当前存在半连接队列溢出的现象。

# 2. 如何调整 SYN 半连接队列大小？
# 要想增大半连接队列，不能只单纯增大 tcp_max_syn_backlog 的值，还需一同增大 somaxconn 和 backlog，也就是增大 accept 队列。否则，只单纯增大 tcp_max_syn_backlog 是无效的。
关于 backlog 和 somaxconn

对于 Linux 而言，基本上任意语言实现的通信框架或服务器程序在构造 socket server 时，都提供了 backlog 这个参数，因为在监听端口时，都会调用系统底层 API: int listen(int sockfd, int backlog);

全连接队列长度如何计算？

如果 backlog 大于内核参数 net.core.somaxconn，则以 net.core.somaxconn 为准，即全连接队列长度 = min(backlog, 内核参数 net.core.somaxconn)，net.core.somaxconn 默认为 128。这个很好理解，net.core.somaxconn 定义了系统级别的全连接队列最大长度，backlog 只是应用层传入的参数，不可能超过内核参数，所以 backlog 必须小于等于 net.core.somaxconn。

其实，对于 Nginx/Tomcat 等这种 Web 服务器，都提供了 backlog 参数设置入口，当然它们都会有默认值，通常这个默认值都不会太大（包括内核默认的半连接队列和全连接队列长度）。

如何查看服务端进程 accept 队列的长度？
1
ss -ltn
  • Recv-Q：当前 accept 队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接；
  • Send-Q：accept 队列最大长度，上面的输出结果说明监听 8088 端口的 TCP 服务，accept 队列的最大长度为 128；
如何查看由于 accept 连接队列已满，而被丢弃的连接？
1
2
netstat -s | grep overflowed
   70 times the listen queue of a socket overflowed

上面看到的 70 times ，表示 accept 队列溢出的次数，注意这个是累计值。可以隔几秒钟执行下，如果这个数字一直在增加的话，说明 accept 连接队列偶尔满了。

如果持续不断地有连接因为 accept 队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。

关于 tcp_max_syn_backlog

半连接队列的最大长度为以下三个参数 backlog、内核参数 net.core.somaxconn、内核参数 tcp_max_syn_backlog 的最小值。即半连接队列长度 = min(backlog, 内核参数 net.core.somaxconn，内核参数 tcp_max_syn_backlog)。这个公式实际上规定半连接队列长度不能超过全连接队列长度。

syncookies 功能

syncookies 的工作原理：服务器根据当前状态计算出一个值，放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时，取出该值验证，如果合法，就认为连接建立成功，如下图所示。

服务端优化 && TCP Fast Open

略

TCP 四次挥手的性能提升

安全关闭连接的方式必须通过四次挥手，它由进程调用 close 和 shutdown 函数发起 FIN 报文（shutdown 参数须传入 SHUT_WR 或者 SHUT_RDWR 才会发送 FIN）。

调用了 close 函数意味着完全断开连接，完全断开不仅指无法传输数据，而且也不能发送数据。 此时，调用了 close 函数的一方的连接叫做「孤儿连接」，如果你用 netstat -p 命令，会发现连接对应的进程名为空。

使用 close 函数关闭连接是不优雅的。于是，就出现了一种优雅关闭连接的 shutdown 函数，它可以控制只关闭一个方向的连接：

优化方案总结

主动方

  • 调整 Fin 报文重传次数
    • 主动发起 FIN 报文断开连接的一方，如果迟迟没收到对方的 ACK 回复，则会重传 FIN 报文，重传的次数由 tcp_orphan_retries 参数决定。
  • 调整 time_wait 状态的个数上线
    • 当主动方接收到 FIN 报文，并返回 ACK 后，主动方的连接进入 TIME_WAIT 状态。这一状态会持续 1 分钟，为了防止 TIME_WAIT 状态占用太多的资源，tcp_max_tw_buckets 定义了最大数量，超过时连接也会直接释放。
  • 复用time_wait 状态的连接
    • 当 TIME_WAIT 状态过多时，还可以通过设置 tcp_tw_reuse 和 tcp_timestamps 为 1 ，将 TIME_WAIT 状态的端口复用于作为客户端的新连接，注意该参数只适用于客户端。

被动方

TCP 传输数据的性能提升

滑动窗口

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是滑动窗口的由来。

接收方根据它的缓冲区，可以计算出后续能够接收多少字节的报文，这个数字叫做接收窗口。当内核接收到报文时，必须用缓冲区存放它们，这样剩余缓冲区空间变小，接收窗口也就变小了；当进程调用 read 函数后，数据被读入了用户空间，内核缓冲区就被清空，这意味着主机可以接收更多的报文，接收窗口就会变大。

因此，接收窗口并不是恒定不变的，接收方会把当前可接收的大小放在 TCP 报文头部中的窗口字段，这样就可以起到窗口大小通知的作用。

发送方的窗口等价于接收方的窗口吗？如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小，因为窗口通知报文在网络传输是存在时延的，所以是约等于的关系。

这样看来，只要进程能及时地调用 read 函数读取数据，并且接收缓冲区配置得足够大，那么接收窗口就可以无限地放大，发送方也就无限地提升发送速度。

这是不可能的，因为网络的传输能力是有限的，当发送方依据发送窗口，发送超过网络处理能力的报文时，路由器会直接丢弃这些报文。因此，缓冲区的内存并不是越大越好。

带宽时延积

比如最大带宽是 100 MB/s，网络时延（RTT）是 10ms 时，意味着客户端到服务端的网络一共可以存放 100MB/s * 0.01s = 1MB 的字节。

这个 1MB 是带宽和时延的乘积，所以它就叫「带宽时延积」（缩写为 BDP，Bandwidth Delay Product）。同时，这 1MB 也表示「飞行中」的 TCP 报文大小，它们就在网络线路、路由器等网络设备上。如果飞行报文超过了 1 MB，就会导致网络过载，容易丢包。

发送缓冲区与带宽时延积的关系

  • 如果发送缓冲区「超过」带宽时延积，超出的部分就没办法有效的网络传输，同时导致网络过载，容易丢包；
  • 如果发送缓冲区「小于」带宽时延积，就不能很好的发挥出网络的传输效率。

所以，发送缓冲区的大小最好是往带宽时延积靠近。

缓冲区的数值

发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。

接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：

  • 如果系统的空闲内存很多，就可以自动把缓冲区增大一些，这样传给对方的接收窗口也会变大，因而提升发送方发送的传输数据数量；
  • 反之，如果系统的内存很紧张，就会减少缓冲区，这虽然会降低传输效率，可以保证更多的并发连接正常工作；

参考

原文-深度好文

linux内核参数