redis.conf中的“ tcp-backlog”是什么

Question

我对tcp-backlogredis.conf 感到困惑：

# TCP listen() backlog.
#
# In high requests-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
# in order to get the desired effect.
tcp-backlog 511

是tcp- backlog“完整的连接队列”（三次握手完成，所描述的内容的大小，位置）或“不完全连接队列”？

如果它表示“完整连接队列”，那我为什么要提高tcp_max_syn_backlog它来限制不完整连接队列的大小？

Answer 1

tcp-backlog是“完整连接队列”（三向握手完成，此处描述什么）的大小还是“不完整连接队列”的大小？

tcp-backlog是 完整连接队列 的大小。实际上，Redis将此配置作为listen(int s, int backlog)呼叫的第二个参数传递。

@GuangshengZuo已经很好地回答了这个问题。因此，我将专注于另一个。

如果它表示“完整连接队列”，那为什么我应该提高tcp_max_syn_backlog来限制不完整连接队列的大小？

引用您提到的文档：

该实现使用两个队列，一个SYN队列（或不完整的连接队列）和一个接受队列（或完整的连接队列）。将状态为SYN
RECEIVED的连接添加到SYN队列中，然后在状态变为ESTABLISHED时（即，在收到3次握手中的ACK数据包时）将其移至接受队列。顾名思义，然后简单地实现accept调用以消耗来自accept队列的连接。在这种情况下，listen
syscall的backlog参数确定接受队列的大小。

我们可以看到中的 项目complete connection queue已从中移出incomplete connection queue。

如果您有一个somaxconn带有小号的大号tcp_max_syn_backlog，则可能没有足够的项目移动到complete connection queue，并且complete connection queue可能永远不会满。许多请求可能已经从第一个队列中删除，然后才有机会被移至第二个队列。

因此，仅提高的价值somaxconn可能行不通。你必须两个都养。