网络缓冲区调优：`tcp-backlog`, `tcp-keepalive` 与 `client-output-buffer-limit`

各位观众老爷，各位技术大咖，以及各位正在被网络调优折磨得头皮发麻的程序员兄弟姐妹们，晚上好！

我是今天的主讲人，江湖人称“Bug终结者”，当然，更多时候我更喜欢别人叫我“优化小王子”。今天，咱们不谈情怀，不聊人生，就来聊聊咱们程序员的“老朋友”——网络缓冲区调优！

相信大家或多或少都遇到过这样的情况：

服务器并发一高，CPU呼呼喘气，内存蹭蹭上涨，客户端请求排队到天荒地老。
明明带宽足够，服务器硬件配置也不差，但数据传输就是慢吞吞，像老牛拉破车。
好不容易建立的TCP连接，动不动就断掉，搞得用户体验稀烂。

这些问题，很多时候都跟咱们的网络缓冲区设置不合理有关。所以，今天咱们就来好好“盘”一下tcp-backlog, tcp-keepalive 和 client-output-buffer-limit 这三个关键参数，让你的服务器瞬间“满血复活”！💪

第一幕：舞台剧开场——什么是网络缓冲区？

在开始“调优之旅”之前，咱们先来简单回顾一下网络缓冲区是个啥玩意儿。想象一下，你的服务器是一个餐厅，而客户端是络绎不绝的食客。

网络缓冲区，就是餐厅的“缓冲区域”。 食客（客户端请求）来了，不可能立刻就被服务员（服务器程序）处理，需要先在等候区排队，这个等候区就是网络缓冲区。
tcp-backlog，就是餐厅的“最大等候区容量”。 它决定了餐厅最多能容纳多少食客同时排队。如果食客超过了这个数量，餐厅就会拒客，也就是服务器拒绝新的连接请求。
client-output-buffer-limit，就是每个食客的“点餐缓冲区”。 当服务员开始处理某个食客的请求时，需要记录下他点的菜（要发送的数据）。这个“点餐缓冲区”决定了每个食客最多能点多少菜，如果超过了这个限制，服务器可能会强制断开连接。
tcp-keepalive，就是餐厅的“防赖账机制”。 有些食客点了菜，结果人却不见了（TCP连接空闲），餐厅总不能一直等着吧？tcp-keepalive就像是定期检查食客是否还在，如果一段时间没动静，就判定为“赖账”，直接清理掉。

所以，网络缓冲区的大小、超时时间等参数设置，直接影响了服务器的并发处理能力、数据传输效率和连接稳定性。

第二幕：tcp-backlog——餐厅的“等候区容量”

tcp-backlog 是一个非常重要的参数，它控制着TCP连接的“半连接队列”的大小。当服务器接收到客户端的SYN包（TCP连接建立的第一步）时，会将这个连接放入半连接队列。如果服务器程序（比如Nginx、Redis）还没有调用accept()函数来接受这个连接，这个连接就会一直待在半连接队列中。

tcp-backlog 太小： 餐厅等候区太小，导致大量食客被拒之门外，服务器无法处理更多的并发连接请求。就好比演唱会门口，人山人海，但入口太窄，很多人挤不进去，只能在外面干瞪眼。
tcp-backlog 太大： 餐厅等候区太大，会占用大量的系统资源。如果服务器资源有限，可能会导致性能下降。就好比一个小型餐厅，弄了一个能容纳几百人的等候区，结果平时根本用不上，白白浪费空间。

如何调优 tcp-backlog？

查看系统默认值： 在Linux系统中，可以使用cat /proc/sys/net/core/somaxconn 命令查看系统默认的tcp-backlog 值。通常，这个值是128。
修改系统级别的值： 可以使用sysctl命令修改系统级别的tcp-backlog值。例如：
```
sysctl -w net.core.somaxconn=2048
```
或者修改 /etc/sysctl.conf 文件，添加或修改以下行：
```
net.core.somaxconn = 2048
```
然后执行sysctl -p 使配置生效。
应用程序级别的值： 许多应用程序（例如Nginx、Redis）都有自己的tcp-backlog 配置项。应用程序的配置会覆盖系统级别的配置。
监控： 使用netstat -s | grep "SYNs to LISTEN" 命令可以监控SYN flood攻击，以及tcp-backlog 是否溢出。如果看到SYNs to LISTEN drops 的数量持续增加，说明tcp-backlog 可能太小，需要适当增加。

小贴士：

tcp-backlog 的值需要根据服务器的实际情况进行调整。一般来说，对于高并发的Web服务器，可以将tcp-backlog 设置为1024或2048。
tcp-backlog 的值不能无限增大，它受到系统资源和应用程序的限制。
除了调整tcp-backlog 的值，还需要优化服务器程序的代码，提高accept() 函数的调用效率。

第三幕：tcp-keepalive——餐厅的“防赖账机制”

tcp-keepalive 是一种TCP连接保活机制。当TCP连接长时间处于空闲状态时，tcp-keepalive 会定期发送探测包，检测连接是否仍然有效。如果连接已经断开，tcp-keepalive 就可以及时发现，并关闭这个连接，释放资源。

tcp-keepalive 作用：
- 检测死连接： 及时发现并关闭已经断开的TCP连接，防止资源浪费。
- 防止中间设备断开连接： 有些网络设备（例如防火墙）会主动断开长时间空闲的TCP连接。tcp-keepalive 可以保持连接活跃，避免被中间设备断开。
tcp-keepalive 相关参数：
- tcp_keepalive_time： TCP连接在空闲多长时间后开始发送keepalive探测包。单位是秒。
- tcp_keepalive_intvl： keepalive探测包的发送间隔。单位是秒。
- tcp_keepalive_probes： 在判定连接失效之前，keepalive探测包发送的次数。
tcp-keepalive 太激进： 频繁发送keepalive探测包，会增加网络流量，消耗服务器资源。就好比餐厅的服务员，每隔几分钟就问一下食客是否还在，会影响食客的用餐体验。
tcp-keepalive 太保守： 长时间不发送keepalive探测包，会导致死连接长时间占用资源，浪费服务器资源。就好比餐厅的服务员，很久才来一次，导致有些食客走了很久都没被发现，白白浪费座位。

如何调优 tcp-keepalive？

查看系统默认值： 在Linux系统中，可以使用以下命令查看系统默认的tcp-keepalive 值：

cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes

修改系统级别的值： 可以使用sysctl命令修改系统级别的tcp-keepalive 值。例如：

sysctl -w net.ipv4.tcp_keepalive_time=7200  # 2 hours
sysctl -w net.ipv4.tcp_keepalive_intvl=75    # 75 seconds
sysctl -w net.ipv4.tcp_keepalive_probes=9     # 9 probes

或者修改 /etc/sysctl.conf 文件，添加或修改以下行：

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9

然后执行sysctl -p 使配置生效。

应用程序级别的值： 许多应用程序（例如Nginx、Redis）也提供了tcp-keepalive 配置项，允许你为特定的连接设置不同的keepalive参数。

小贴士：

tcp-keepalive 的值需要根据应用程序的特点和网络环境进行调整。一般来说，对于需要保持长时间连接的应用程序（例如SSH、数据库连接），可以适当调整tcp_keepalive_time 的值，使其更短。
如果网络环境不稳定，容易出现连接断开的情况，可以适当调整tcp_keepalive_intvl 和tcp_keepalive_probes 的值，使其更加敏感。
需要注意的是，tcp-keepalive 并不是万能的。它只能检测到连接的物理断开，无法检测到应用程序级别的故障。

第四幕：client-output-buffer-limit——餐厅的“点餐缓冲区”

client-output-buffer-limit 用于限制每个客户端连接的输出缓冲区大小。当服务器向客户端发送数据时，数据会先被放入输出缓冲区。如果客户端接收数据的速度慢于服务器发送数据的速度，输出缓冲区就会被填满。

client-output-buffer-limit 作用：
- 防止恶意攻击： 限制客户端的输出缓冲区大小，可以防止恶意客户端占用过多的服务器资源，导致拒绝服务攻击。
- 控制内存使用： 限制客户端的输出缓冲区大小，可以控制服务器的内存使用，防止内存溢出。
- 提高服务质量： 当客户端接收数据的速度过慢时，服务器可以主动断开连接，避免影响其他客户端的体验。
client-output-buffer-limit 太小： 服务器可能会频繁断开连接，导致客户端请求失败。就好比餐厅的服务员，因为食客点的菜太多，就直接把食客赶走，影响用户体验。
client-output-buffer-limit 太大： 恶意客户端可能会占用大量的服务器内存，导致服务器性能下降。就好比餐厅允许食客无限点菜，结果有些食客点了大量的菜，但根本吃不完，浪费资源。

如何调优 client-output-buffer-limit？

client-output-buffer-limit 通常是在应用程序级别进行配置的。例如，在Nginx中，可以使用client_body_buffer_size 指令来配置客户端请求体的缓冲区大小。在Redis中，可以使用client-output-buffer-limit 指令来配置客户端输出缓冲区的大小。

Nginx 配置示例：

http {
    client_body_buffer_size  10k;
    client_max_body_size     10m;
}

Redis 配置示例：

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

参数解释：

normal: 用于普通客户端连接。
slave: 用于Redis主从复制连接。
pubsub: 用于发布/订阅连接。
hard limit: 硬性限制，超过这个限制，服务器会立即断开连接。
soft limit: 软性限制，超过这个限制，并且持续一段时间（soft seconds），服务器才会断开连接。
soft seconds: 软性限制持续的时间。

小贴士：

client-output-buffer-limit 的值需要根据应用程序的特点和客户端的类型进行调整。
对于普通客户端连接，可以设置一个较小的client-output-buffer-limit 值，以防止恶意攻击。
对于需要发送大量数据的连接（例如Redis主从复制），可以适当增加client-output-buffer-limit 的值。
在调整client-output-buffer-limit 的值时，需要密切关注服务器的内存使用情况，避免内存溢出。

第五幕：总结与展望——调优的艺术

好了，各位，经过一番“庖丁解牛”式的讲解，相信大家对tcp-backlog, tcp-keepalive 和 client-output-buffer-limit 这三个参数有了更深入的了解。

但是，请记住，调优是一门艺术，而不是一门科学。 没有万能的配置，只有最适合你的配置。你需要根据你的应用程序的特点、网络环境和服务器资源，进行不断的尝试和调整。

不要盲目照搬别人的配置： 别人的经验可能并不适合你。
监控是关键： 密切关注服务器的各项指标，例如CPU使用率、内存使用率、网络流量等。
逐步调整： 每次只调整一个参数，观察调整后的效果。
持续优化： 调优是一个持续的过程，需要不断地学习和实践。

最后，希望今天的分享能够帮助大家更好地理解和使用网络缓冲区，让你的服务器跑得更快、更稳！ 🚀

感谢大家的聆听！如果大家还有什么问题，欢迎在评论区留言，我会尽力解答。祝大家编程愉快，Bug远离！ 🙏

发表回复 取消回复

发表回复取消回复