tcp的连接数量受synqueue限制吗

Posted 2023-04-02

tcp的连接数量受synqueue限制吗：
在实际工作中经常碰到一种情况，流量上涨的时候，服务端会出现大量的超时。此时的处理办法一般是扩容。

实际上就算没有流量上涨，当某个接口速度变慢时，调用该接口的服务也会出现超时。

不管是流量上涨(qps增加)还是接口变慢，导致超时的直接原因都是系统吞吐量不足(系统吞吐量 = qps / 响应时间)。

当系统吞吐量不足时，大量请求就会在接口上堆积得不到及时的处理，表现出来就是连接超时或接口超时。

TCP半连接队列和全连接队列
创建tcp连接时需要三次握手。

首先客户端向服务端发送一个连接请求，包含一个SYN包，客户端进入SYN_SEND状态。
服务端收到客户端的请求后将返回一个SYN+ACK,此时服务端进入SYN_RECV状态。服务端内核会将该连接存储到半连接队列(SYN队列)。
客户端收到服务端的确认后，发送一个ACK包，此时客户端进入ESTABLISHED状态。
服务端收到客户端发来的ACK包之后，进入ESTABLISHED状态，并将半连接队列中的连接取出来放到全连接队列里(ACCEPT队列)。等待进程调用accept函数时将连接取出来。
整体流程如下图所示：

不管是半连接队列(syn queue)还是全连接队列(accept queue),都是有长度限制的，超过长度限制时，内核会直接丢弃或者返回RST包。

查看全连接队列
可以使用ss(比netstat更快)命令查看tcp全连接队列的情况。

# -l 显示处于listen状态的socket
# -n 不解析服务名称
# -t 只显示tcp socket
ss -lnt
1
2
3
4
1
2
3
4
结果如下：

其中，Recv-Q表示全连接队列的大小，也就是已完成三次握手并等待服务端accept()的tcp连接个数。Send-Q表示全连接最大队列长度，默认是128。

注意在非Listen状态下(不使用-l参数)，Recv-Q/Send-Q表示的含义是不同的。

其中Recv-Q表示已收到但未被应用进程读取的字节数。Send-Q表示已发送到未收到确认的字节数。

打开CSDN APP，看更多技术内容

TCP 全连接队列满了会发生什么?又该如何应对?_YY小记的博客_t...
如果服务器上的进程只是短暂的繁忙造成 accept 队列满,那么当 TCP 全连接队列有空位时,再次接收到的请求报文由于含有 ACK,仍然会触发服务器端成功建立连接。 所以,tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率,只有你非常肯...
继续访问
最大TCP连接数量问题总结_星期二的风的博客_tcp连接数
TCP连接数过大可能会出现: ERROR: out of memory ,即内存溢出。 原因:每个TCP连接本身,以及这个连接所用到的缓冲区,都是需要占用一定内存的,现在内存已经被占满了,不够用了就会报这个错。 5、CPU的限制 每个TCP连接都是需要占用CPU...
继续访问
服务器远程超出最大连接数的原因及解决
服务器远程超出最大连接数的原因是没有注销退出有可能导致远程连接的进程死掉，重启服务器即可
热门推荐 解决TCP连接数过多的问题
1、建立连接协议（三次握手） （1）客户 端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 （2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标 志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通 讯。 （3） 客户必须再次回应服务段一个ACK报文，这是报文段3。 2、连接终止
继续访问
记一次线上环境tcp链接爆满导致服务响应慢的问题_徐波_bobch的博客...
记一次线上环境tcp链接爆满导致服务响应慢的问题 事件还原: 20200407凌晨接到运维人员电话,说app启动充电响应很慢,无法正常的开启充电; 20200407凌晨,跟踪日志排查服务负载情况,但是过了一段时间自动恢复; ...
继续访问
服务器tcp连接占满_服务器出现大量TIME_WAIT解决方案
一 、故障原因： 服务器突然出现大量time_wait(因为大量连接资源被占用后不释放的话，会导致网站正常访问不能响应)。如何应对？我这边先检查了监控和服务器当前的状态(time_wait连接确实异常):1、监控2、登录服务器检查二、排查思路：1、猜测是否因为程序打开大量文件句柄，没有关闭导致。(问了研发同事，排查过后没有这种情况)2、调大当前文件句柄 3、调优sysctl.conf文件4、检查n...
继续访问
性能分析之压测中 TCP 全连接队列占满问题分析及优化案例
文章目录一、前言二、知识预备三、压测及分析过程1、第一次压测2、调大 backlog 值为 5000 后，再次压测3、调整日志级别为 ERROR，再次压测四、小结 一、前言 在对一个挡板系统进行测试时，遇到一个由于 TCP 全连接队列被占满而影响系统性能的问题，这里记录下如何进行分析及解决的。 二、知识预备 理解下 TCP 建立连接过程与队列： 从图中明显可以看出建立 TCP 连接的时候，有两个队列：syns queue（半连接队列）和accept queue（全连接队列），分别在第一次握手和第三次握手。
继续访问

TCP全连接队列和半连接队列已满之后的连接建立过程抓包分析
在进行client不断的对server端进行connect的过程中发现下面这个状态，而且循环6w次的链接只进行了2W多次就出错了。 于是去查找了下原因： Linux内核协议栈为一个tcp连接管理使用两个队列，一个是半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求），一个是全连接队列（accpetd队列）（用来保存处
继续访问
最大TCP连接数量问题总结
TCP连接限制问题总结最大TCP连接数量问题总结1、可用端口号限制2、文件描述符限制3、线程的限制4、内存的限制5、CPU的限制总结参考文献： 最大TCP连接数量问题总结 直接上答案 最大TCP连接数量限制有：可用端口号数量、文件描述符数量、线程、内存、CPU 1、可用端口号限制 Q：一台主机可以有多少端口号？端口号与TCP连接？是否能修改？端口号限制因素？ 第一：端口号是16位的，所以总共有65535个，即可创建65535个TCP连接 第二：端口分为知名端口(0~1023)、注册端口(1024~4951
继续访问

关于TCP连接的一些细节问题
Q: 半连接队列与全连接队列 A: 半连接队列：由tcp_max_syn_backlog决定，开户syncookies时，没有上限 全连接队列：由somaxconn（系统级）与backlog（listen函数参数）共同决定，取两者中的较小值 Q: 半连接队列满了如何处理？ A: 丢弃请求 Q: 全连接队列满了如何处理？ tcp_abort_on_overflow==1 发送reset包 tcp_abort_on_overflow==0 过一段时间重发syn ack包（次数由tcp_synack_ret
继续访问
linux下tcp服务器并发连接数限制
1、修改用户进程可打开文件数限制 在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。可使用ulimit命令查看系统允许当前用户进程打开的文件数限制： [speng@as4 ~]$ ulimit -n 1024 这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的
继续访问
linux syn 队列,TCP SYN队列与Accept队列详解
李乐尽信书，不如无书。纸上得来终觉浅，绝知此事要躬行。实验现象依赖于系统(如下)以及内核参数(附录)；一切以实验结果为准。cat /proc/versionLinux version 3.10.0-693.el7.x86_64引子线上服务(Golang)调用内网API服务(经由内网网关/nginx转发)时，偶尔会出现"connection reset by peer"报警；为此梳理TCP RST包...
继续访问
最新发布 计算机网络之TCP最大连接限制
计算机网络之TCP最大连接限制
继续访问

TCP半连接队列要是满了会怎么样?
一般是丢弃，但这个行为可以通过tcp_syncookies参数去控制。但比起这个，更重要的是先了解下半连接队列为什么会被打满。 首先我们需要明白，一般情况下，半连接的"生存"时间其实很短，只有在第一次和第三次握手间，如果半连接都满了，说明服务端疯狂收到第一次握手请求，如果是线上游戏应用，能有这么多请求进来，那说明你可能要富了。但现实往往比较骨感，你可能遇到了SYN Flood攻击。 所谓SYN Flood攻击，可以简单理解为，攻击方模拟客户端疯狂发第一次握手请求过来，在服务端憨憨地回复第二次握手过去..
继续访问

TCP 全连接队列满了会发生什么？又该如何应对？
什么是 TCP 半连接队列和全连接队列？ .半连接队列，也称 SYN 队列； .全连接队列，也称 accepet 队列； 服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。 不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回
继续访问

tcp连接大量time_wait
time_wait过多的后果 http://blog.51cto.com/benpaozhe/1767612 tcp基础：http://blog.sciencenet.cn/blog-1225851-830338.html 连接不上的问题：http://www.cnxct.com/something-about-phpfpm-s-backlog/ http://maoyidao.iteye.
继续访问
TCP accept返回的socket，服务端TCP连接数限制
http://www.cppblog.com/aa19870406/archive/2012/07/15/183595.html socket accept()返回的socket描述符的端口和listen描述符端口是一样的吗？ as you know,一个socket是由一个五元组来唯一标示的，即(协议，server_ip, server_port, client_ip, client
继续访问
syn重发_TCP 网络传输协议中的全队列和半队列说明和半连接队列的SYN洪水攻击 | IT工程师的生活足迹...
一、TCP 维护队列TCP协议在数据传输过程中会维护两个队列:半连接队列(SYN queue)和全连接队列(accept queue)。1.1、半连接队列(SYN Queue)服务器端监听TCP端口后，会创建一个request_sock结构，用于存储半连接队列。在TCP三次握手中，当服务器接受到客户端的SYN包后，就将此连接保存到SYN Queue中，并向客户端发送SYN-ACK包;等待客户端发送...
继续访问
linux tcp连接满了,[TimLinux] TCP全连接队列满
0. TCP三次握手syns queue: 半连接队列accept queue: 全连接队列控制参数存放在文件：/proc/sys/net/ipv4/tcp_abort_on_overflow中，0：表示如果三次握手第三步的时候全连接队列满了，那么server扔掉client发过来的ack(在server端因为全连接队列满了，认为连接还没有建立起来)，1：表示第三步的时候如果全连接队列满了，ser...
继续访问
TCP全链接队列满的问题分析之net.core.somaxconn详解
背景​参考：TCP全链接队列满的问题分析之net.core.somaxconn详解_运维_PHP面试网 最近控制台查看腾讯云服务器状态时，发现一个异常情况提示如下： 该实例最近12小时内在2022-01-18 14:48出现过TCP全链接队列满的情况，为避免成为业务瓶颈，建议您检查业务健康情况。可参考文档：点击查看 TCP 全连接队列满 TCP 全连接队列的长度取net.core.somaxconn及业务进程调用 listen 时传入的 backlog 参数，两者中的较小值。若您的实..
继续访 参考技术A Tcp的连接数量受synqueue限制，因为如果不受限制的话，那么它就是这个Tcp的连接数量不受限，那么会直接把服务器进行申报，所以是一定要限制数量的。 参考技术B 受。
synqueue系统对tcp连接数进行了限制（默认是10个连接数）。当带宽足够时，下载工具就可以使用较多的线程来加快下载速度。10个线程数反而限... 参考技术C 所以，xp系统对tcp连接数进行了限制（默认是10个）。当带宽足够时，下载工具就可以使用较多的线程来加快下载速度。10个线程数反而限制了下载软件的应用，所以需要适当放宽对下载工具线程数的限制来提高下载速度。

一台服务器最大能支持多少条TCP连接？

一、一台服务器最大能打开的文件数

1、限制参数

我们知道在Linux中一切皆文件，那么一台服务器最大能打开多少个文件呢？Linux上能打开的最大文件数量受三个参数影响，分别是：

• fs.file-max （系统级别参数）：该参数描述了整个系统可以打开的最大文件数量。但是root用户不会受该参数限制（比如：现在整个系统打开的文件描述符数量已达到fs.file-max ，此时root用户仍然可以使用ps、kill等命令或打开其他文件描述符）
• soft nofile（进程级别参数）：限制单个进程上可以打开的最大文件数。只能在Linux上配置一次，不能针对不同用户配置不同的值
• fs.nr_open（进程级别参数）：限制单个进程上可以打开的最大文件数。可以针对不同用户配置不同的值

这三个参数之间还有耦合关系，所以配置值的时候还需要注意以下三点：

1. 如果想加大soft nofile，那么hard nofile参数值也需要一起调整。如果因为hard nofile参数值设置的低，那么soft nofile参数的值设置的再高也没有用，实际生效的值会按照二者最低的来。
2. 如果增大了hard nofile，那么fs.nr_open也都需要跟着一起调整（fs.nr_open参数值一定要大于hard nofile参数值）。如果不小心把hard nofile的值设置的比fs.nr_open还大，那么后果比较严重。会导致该用户无法登录，如果设置的是*，那么所有用户都无法登录
3. 如果加大了fs.nr_open，但是是用的echo "xxx" > ../fs/nr_open命令来修改的fs.nr_open的值，那么刚改完可能不会有问题，但是只要机器一重启，那么之前通过echo命令设置的fs.nr_open值便会失效，用户还是无法登录。所以非常不建议使用echo的方式修改内核参数！！！

2、调整服务器能打开的最大文件数示例

假设想让进程可以打开100万个文件描述符，这里用修改conf文件的方式给出一个建议。如果日后工作里有类似的需求可以作为参考。

• vim /etc/sysctl.conf

fs.file-max=1100000 // 系统级别设置成110万，多留点buffer
fs.nr_open=1100000 // 进程级别也设置成110万，因为要保证比 hard nofile大

• 使上面的配置生效sysctl -p
• vim /etc/security/limits.conf

// 用户进程级别都设置成100完
soft nofile 1000000
hard nofile 1000000

二、一台服务器最大能支持多少连接

我们知道TCP连接，从根本上看其实就是client和server端在内存中维护的一组【socket内核对象】（这里也对应着TCP四元组：源IP、源端口、目标IP、目标端口），他们只要能够找到对方，那么就算是一条连接。那么一台服务器最大能建立多少条连接呢？

• 由于TCP连接本质上可以理解为是client-server端的一对socket内核对象，那么从理论上将应该是【2^32 (ip数) * 2^16 (端口数)】条连接（约等于两百多万亿）
• 但是实际上由于受其他软硬件的影响，我们一台服务器不可能能建立这么多连接（主要是受CPU和内存限制）。

如果只以ESTABLISH状态的连接来算（这些连接只是建立，但是不收发数据也不处理相关的业务逻辑）那么一台服务器最大能建立多少连接呢？以一台4GB内存的服务器为例！

• 这种情况下，那么能建立的连接数量主要取决于【内存的大小】（因为如果是）ESTABLISH状态的空闲连接，不会消耗CPU（虽然有TCP保活包传输，但这个影响非常小，可以忽略不计）
• 我们知道一条ESTABLISH状态的连接大约消耗【3.3KB内存】，那么通过计算得知一台4GB内存的服务器，【可以建立100w+的TCP连接】（当然这里只是计算所有的连接都只建立连接但不发送和处理数据的情况，如果真实场景中有数据往来和处理（数据接收和发送都需要申请内存，数据处理便需要CPU），那便会消耗更高的内存以及占用更多的CPU，并发不可能达到100w+）

上面讨论的都是进建立连接的理想情况，在现实中如果有频繁的数据收发和处理（比如：压缩、加密等），那么一台服务器能支撑1000连接都算好的了，所以一台服务器能支撑多少连接还要结合具体的场景去分析，不能光靠理论值去算。抛开业务逻辑单纯的谈并发没有太大的实际意义。

服务器的开销大头往往并不是连接本身，而是每条连接上的数据收发，以及请求业务逻辑处理！！！

三、一台客户端机器最多能发起多少条连接

我们知道客户端每和服务端建立一个连接便会消耗掉client端一个端口。一台机器的端口范围是【0 ~ 65535】，那么是不是说一台client机器最多和一台服务端机器建立65535个连接呢（这65535个端口里还有很多保留端口，可用端口可能只有64000个左右）？

由TCP连接的四元组特性可知，只要四元组里某一个元素不同，那么就认为这是不同的TCP连接。所以需要分情况讨论：

• 【情况一】、如果一台client仅有一个IP，server端也仅有一个IP并且仅启动一个程序，监听一个端口的情况下，client端和这台server端最大可建立的连接条数就是 65535 个。

因为源IP固定，目标IP和端口固定，四元组中唯一可变化的就是【源端口】，【源端口】的可用范围又是【0 ~ 65535】，所以一台client机器最大能建立65535个连接

• 【情况二】、如果一台client有多个IP（假设客户端有 n 个IP），server端仅有一个IP并且仅启动一个程序，监听一个端口的情况下，一台client机器最大能建立的连接条数是：n * 65535 个

因为目标IP和端口固定，有 n 个源IP，四元组中可变化的就是【源端口】+ 【源IP】，【源端口】的可用范围又是【0 ~ 65535】，所以一个IP最大能建立65535个连接，那么n个IP最大就能建立 n * 65535个连接了

以现在的技术，给一个client分配多个IP是非常容易的事情，只需要去联系你们网管就可以做到。

• 【情况三】、如果一台client仅有一个IP，server端也仅有一个IP但是server端启动多个程序，每个程序监听一个端口的情况下（比如server端启动了m个程序，监听了m个不同端口），一台client机器最大能建立的连接数量为：65535 * m

源IP固定，目标IP固定，目标端口数量为m个，可变化的是源端口，而源端口变化范围是【0 ~ 65535】，所以一台client机器最大能建立的TCP连接数量是 65535 * m个

• 其余情况类推，但是客户端的可用端口范围一般达不到65535个，受内核参数net.ipv4.ip_local_port_range限制，如果要修改client所能使用的端口范围，可以修改这个内核参数的值。
• 所以，不光是一台server端可以接收100w+个TCP连接，一台client照样能发出100w+个连接

四、其他

• 三次握手里socket的全连接队列长度由参数net.core.somaxconn来控制，默认大小是128，当两台机器离的非常近，但是建立连接的并发又非常高时，可能会导致半连接队列或全连接队列溢出，进而导致server端丢弃握手包。然后造成client超时重传握手包（至少1s以后才会重传），导致三次握手连接建立耗时过长。我们可以调整参数net.core.somaxconn来增加去按连接队列的长度，进而减小丢包的影响
• 有时候我们通过 ctrl + c方式来终止了某个进程，但是当重启该进程的时候发现报错端口被占用，这种问题是因为【操作系统还没有来得及回收该端口，等一会儿重启应用就好了】
• client程序在和server端建立连接时，如果client没有调用bind方法传入指定的端口，那么client在和server端建立连接的时候便会自己随机选择一个端口来建立连接。一旦我们client程序调用了bind方法传入了指定的端口，那么client将会使用我们bind里指定的端口来和server建立连接。所以不建议client调用bind方法，bind函数会改变内核选择端口的策略

public static void main(String[] args) throws IOException 
    SocketChannel sc = SocketChannel.open();
   // 客户端还可以调用bind方法
    sc.bind(new InetSocketAddress("localhost", 9999));
    sc.connect(new InetSocketAddress("localhost", 8080));
    System.out.println("waiting..........");

• 在Linux一切皆文件，当然也包括之前TCP连接中说的socket。进程打开一个socket的时候需要创建好几个内核对象，换一句直白的话说就是打开文件对象吃内存，所以Linux系统基于安全角度考虑（比如：有用户进程恶意的打开无数的文件描述符，那不得把系统搞奔溃了），在多个位置都限制了可打开的文件描述符的数量。
• 内核是通过【hash表】的方式来管理所有已经建立好连接的socket，以便于有请求到达时快速的通过【TCP四元组】查找到内核中对应的socket对象

在epoll模型中，通过红黑树来管理epoll对象所管理的所有socket，用红黑树结构来平衡快速删除、插入、查找socket的效率

五、相关实际问题

在网络开发中，很多人对一个基础问题始终没有彻底搞明白，那就是一台机器最多能支撑多少条TCP连接。不过由于客户端和服务端对端口使用方式不同，这个问题拆开来理解要容易一些。

注意，这里说的是客户端和服务端都只是角色，并不是指某一台具体的机器。例如对于我们自己开发的应用程序来说，当他响应客户端请求的时候，他就是服务端。当他向MySQL请求数据的时候，他又变成了客户端。

1、"too many open files" 报错是怎么回事，该如何解决

你在线上可能遇到过too many open files这个错误，那么你理解这个报错发生的原理吗？如果让你修复这个错误，应该如何处理呢？

• 因为每打开一个文件（包括socket），都需要消耗一定的内存资源。为了避免个别进程不受控制的打开了过多文件而让整个服务器奔溃，Linux对打开的文件描述符数量有限制。如果你的进程触发到内核的限制，那么"too many open files" 报错就产生了
• 可以通过修改fs.file-max 、soft nofile、fs.nr_open这三个参数的值来修改进程能打开的最大文件描述符数量

需要注意这三个参数之间的耦合关系！

2、一台服务端机器最大究竟能支持多少条连接

因为这里要考虑的是最大数，因此先不考虑连接上的数据收发和处理，仅考虑ESTABLISH状态的空连接。那么一台服务端机器上最大可以支持多少条TCP连接？这个连接数会受哪些因素的影响？

• 在不考虑连接上数据的收发和处理的情况下，仅考虑ESTABLISH状态下的空连接情况下，一台服务器上最大可支持的TCP连接数量基本上可以说是由内存大小来决定的。
• 四元组唯一确定一条连接，但服务端可以接收来自任意客户端的请求，所以根据这个理论计算出来的数字太大，没有实际意义。另外文件描述符限制其实也是内核为了防止某些应用程序不受限制的打开【文件句柄】而添加的限制。这个限制只要修改几个内核参数就可以加大。
• 一个socket大约消耗3kb左右的内存，这样真正制约服务端机器最大并发数的就是内存，拿一台4GB内存的服务器来说，可以支持的TCP连接数量大约是100w+

3、一条客户端机器最大究竟能支持多少条连接

和服务端不同的是，客户端每次建立一条连接都需要消耗一个端口。在TCP协议中，端口是一个2字节的整数，因此范围只能是0~65535。那么客户单最大只能支持65535条连接吗？有没有办法突破这个限制，有的话有哪些办法？

• 客户度每次建立一条连接都需要消耗一个端口。从数字上来看，似乎最多只能建立65535条连接。但实际上我们有两种办法破除65535这个限制

方式一，为客户端配置多IP 方式二，分别连接不同的服务端

• 所以一台client发起百万条连接是没有任何问题的

4、做一个长连接推送产品，支持1亿用户需要多少台机器

假设你是系统架构师，现在老板给你一个需求，让你做一个类似友盟upush这样的产品。要在服务端机器上保持一个和客户端的长连接，绝大部分情况下连接都是空闲的，每天也就顶多推送两三次左右。总用户规模预计是1亿。那么现在请你来评估一下需要多少台服务器可以支撑这1亿条长连接。

• 对于长连接推送模块这种服务来说，给客户端发送数据只是偶尔的，一般一天也就顶多一两次。绝大部分情况下TCP连接都是空闲的，CPU开销可以忽略
• 再基于内存来考虑，假设服务器内存是128G的，那么一台服务器可以考虑支持500w条并发。这样会消耗掉大约不到20GB内存用来保存这500w条连接对应的socket。还剩下100GB以上的内存来应对接收、发送缓冲区等其他的开销足够了。所以，一亿用户，仅仅需要20台服务器就差不多够用了！