platinum 发表于 2005-06-30 18:39

tcp_max_syn_backlog 的疑问

网上随处可以找到下面这些资料

tcp_max_syn_backlog 参数类型：整型
对于那些依然还未获得客户端确认的连接请求﹐需要保存在队列中最大数目。
对于超过 128Mb 内存的系统﹐默认值是 1024 ﹐低于 128Mb 的则为 128。
如果服务器经常出现过载﹐可以尝试增加这个数字。
警告﹗假如您将此值设为大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE ﹐以保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且编进核心之内。

默认是 1024，没错，我改为 2048，还要保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog
为此，我特意看了一下内核里面 include/net/tcp.h
不过，让我很疑惑的是，TCP_SYNQ_HSIZE 的初始设置是 512，如果按照上面的理论，1024 本身就是不对的啊？
为什么？是网上所有的资料都说错了？还是 kernel.org 就这样设计的，故意弄成这样？

gig2600 发表于 2005-06-30 21:12

tcp_max_syn_backlog 的疑问

资料过时了吧

platinum 发表于 2005-06-30 21:26

tcp_max_syn_backlog 的疑问

不会吧？！
就算过时，也不能相互违背啊，难道新内核都是 TCP_SYNQ_HSIZE*16 >; tcp_max_syn_backlog ？？？

20040925 发表于 2012-02-21 21:35

回复 3# platinum


    老大，这个问题有结论了吗？

higkoo 发表于 2012-10-08 12:05

楼主描述的问题确实存在，我也遇到了。

SYN_RECV 最高512个。

大量： kernel: possible SYN flooding on port 80. Sending cookies.

net.ipv4.tcp_max_syn_backlog = 8192

瀚海书香 发表于 2012-10-08 15:23

回复 5# higkoo
内核虽然会抱怨，但是不会影响正常的connect。

   

higkoo 发表于 2012-11-02 11:02

回复 6# 瀚海书香


    问题解决了，实际上并不是内核的问题。服务本身在监听端口时都会指定自身backlog的大小。像常用的Nginxy默认是511，Redis是512。在不指定的情况下才会使用操作系统配置的值。

zj47596731 发表于 2012-11-02 11:15

学习学习啊

ever027 发表于 2012-11-26 15:28

本帖最后由 ever027 于 2012-11-26 15:33 编辑

但是那位能说说
struct tcp_listen_opt
{
        u8                        max_qlen_log;        /* log_2 of maximal queued SYNs */
        int                        qlen;
        int                        qlen_young;
        int                        clock_hand;
        u32                        hash_rnd;
        struct open_request        *syn_table;
}

TCP_SYNQ_HSIZE和tcp_max_syn_backlog到底是什么关系。

ever027 发表于 2012-12-03 11:36

明白了，TCP_SYNQ_HSIZE是512个单向链表，最多tcp_max_syn_backlog个半链接分布在这些单向链表里面。
页: [1] 2
查看完整版本: tcp_max_syn_backlog 的疑问