Linux ssh连接不上,能ping通,登录界面报错提示 audit: backlog limit exceeded
很简单呀,因为我做了实验和看了 TCP 协议栈的内核源码,发现要增大这两个队列长度,不是简简单单增大某一个参数就可以的。
前两天看到一群里在讨论 Tomcat 参数调优,看到不止一个人说通过 accept-count 来配置线程池大小,我笑了笑,看来其实很多人并不太了解我们用的最多的 WebServer Tomcat,这篇文章就来聊下 Tomcat 调优,重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
最近遇到多台CVM中客户端访问服务器端超时的异常,当时查看了netstat -as信息,凭经验判断可能是tcp overflowed导致的。网卡队列满了,可能会造成子机网络包重传现象
大家对于 TCP 的三次握手应该都比较熟悉了,对于服务端,收到 SYN 包后该怎么处理,收到 Establish 之后又该怎么处理,或者说这些连接放在哪里,其实这也是之前面试问过的问题
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核),当然由于listen的backlog参数和半连接hash表以及全连接队列都相关,在这一篇博客里也一块讲了。
云主机无法ssh及ping通,端口开启。VNC中有大量“backlog limit exceeded”的提示
今天有个小伙伴跑过来告诉我有个奇怪的问题需要协助下,问题确实也很奇怪。客户端调用RT比较高并伴随着间歇性异常Connection reset出现,而服务端CPU 、线程栈等看起来貌似都很正常,而且服务端的RT很短。
从上面的解释来看,就是定义了一个队列,并设置了队列长度,那么这个队列是做什么的,接着往下看
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。
现在很多人都在诟病Linux内核协议栈收包效率低,不管他们是真的懂还是一点都不懂只是听别人说的,反正就是在一味地怼Linux内核协议栈,他们的武器貌似只有DPDK。
TCP有限状态机 TCP服务 创建TCP服务的四个基本步骤: socket – 创建socket套接字。 bind – 绑定要监听的IP地址。 listen – 开始监听客户端连接请求。 accept
Nginx TCP backlog 配置,如果是同一个 listen 端口,设置一次就好;比如有多个 server, 每个 server 都是监听 80 端口,只需要给一个 80 端口设置 backlog 就好,一般我们会有一个 default server,在default server 的 80 端口上设置 backlog 的值就可以了;设置好了之后,可以通过 ss -lnt 查看。
图片下载走的 k8s ingress,这个 ingress 路径对应后端 service 是一个代理静态图片文件的 nginx deployment,这个 deployment 只有一个副本,静态文件存储在 nfs 上,nginx 通过挂载 nfs 来读取静态文件来提供图片下载服务,所以调用链是:client --> k8s ingress --> nginx --> nfs。
Nginx 的机器,一般都是独立的机器,因此不建议采用默认 irqbalance 的自动绑定,而是要设置 smp_affinity、smp_affinity_list 的值来自动绑定。
(1)interactive_timeout : 服务器在关闭它前在一个交互连接上等待行动的秒数。一个交互的客户被定义为对 mysql_real_connect()使用 CLIENT_INTERACTIVE 选项的客户。 默认数值是28800,我把它改为7200。
在正式部署前,你可以先阅读前置准备,对部署过程中用到的docker、redis操作和配置有一个理解,以防在自己电脑上复现时出错。 我们将在一台windows10机器上运行多个docker容器,配置Redis主从集群。
案发现场的日志: 缓存集群redis重启错误报错: 29808:M 07 Jun 09:46:32.209 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 29808:M 07 Jun 09:46:32.209 # Server started, Redis version 3.0.4 2
hping3是一个基于C语言编写的网络性能测试工具,由Salvatore Sanfilippo开发。它能够模拟各种类型的网络包,对服务器进行压力测试,并提供丰富的选项来定制测试。hping3不仅适用于HTTP协议,还支持TCP、UDP、ICMP等多种协议,使其成为一个多功能的网络性能测试工具。
服务器收到客户端SYN数据包后,Linux内核会把该连接存储到半连接队列中,并响应SYN+ACK报文给客户端。
【1】ulimit 与 TCP backlog:1)、修改 ulimit:通过 ulimit 修改 open files 参数,redis 建议把 open files 至少设置成 10032,因为 maxclients 是10000 [客户端的数据是以文件的形式进行保存的] ,另外 redis 内部最多会使用 32 个文件描述符。
TCP是一种面向连接的单播协议,在发送数据前,通信双方必须在彼此间建立一条连接。所谓的“连接”,其实是客户端和服务器的内存里保存的一份关于对方的信息,如ip地址、端口号等。
配置关闭:主节点产生的数据无论大小都会及时的发送给从节点。redis默认关闭此配置,以保障较小的主从延迟。当然,这需要主从间保持较好的网络状况。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
网络数据传输:数据帧传输,由网卡读取并放入设备缓冲区ring buffer,当网络数据包到达的速率快于内核处理的速率时,ring buffer很快会被填满,新来的数据包将被丢弃。
每次一发版导致服务A调用B服务超时, B没有任何请求记录日志, 初次定位到为网络问题
TCP自从1974年被发明出来之后,历经30多年发展,目前成为最重要的互联网基础协议,但TCP协议中也存在一些缺陷。
wrk是一个基于C语言编写的HTTP性能测试工具,由GitHub用户wg/wrk开发。它能够通过生成大量的HTTP请求,对服务器进行压力测试,并实时输出测试结果,包括请求速率、传输速率、连接数等关键性能指标。wrk的设计初衷是为了提供一个简单易用的性能测试工具,同时保证测试结果的准确性和可靠性。
在 Linux 系统中,常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
大概在一年半之前的时候,我们的应用的某个业务开始间歇报SocketTimeoutException, 不是前端调用我们发生SocketTimeoutException,而是我们用 HTTP Client中台拉取数据的时候,会偶尔报SocketTimeException, 这个偶尔可能是一个月报一次,也可能是两个月报一次,可能一个星期报两次,频率不固定,次数也不固定,当我第一次看到这个异常的时候,我的第一个反应就是用这个异常信息去搜索引擎上搜索解决方案,我并不理解这个异常说明了什么,但是按照我以往的经验来说,一般都有解决方案,对搜索引擎的方案一般都是延长超时时间,于是我延长了超时时间,但这并没有根本上解决问题,还是会出问题。延长超时时间不管用之后,我就扩容,但是扩容依然也不管用,我当时在尝试复现这个异常的时候,也忽略了一些东西,然后导致我在测试无法复现,能够复现的问题都是好问题,我之前面试的时候也背过三次握手,也学过Java 的原生Socket 编程,Netty,我背过Tomcat的acceptCount参数,但是碰到这个问题,这些知识仍然没有帮我解决问题,原因当时我网络的知识没有连接起来,他们孤零零的,向孤零零的神经元一样,没建立起来连接,最后这个问题开始让这些知识开始建立连接,成体系的发展。连接才是有价值的。
如果有人问redis 到底跑的有多快,简单的回答,纳秒等级, 可如果再要细问,估计只能进行测试了,每台机器的物理硬件标准不同,所以就需要基准测试. 另外redis到底需要不需要进行调优,可能大部分场景不需要,但不需要不意味这你可以欣然接受你不会.
关于三次握手,还有很多细节之前的文章没有详细介绍,这篇文章我们以 backlog 参数来深入研究一下建连的过程。通过阅读这篇文章,你会了解到下面这些知识:
某日线上登录出现故障,排查日志发现HttpClient请求时随机分配到的端口被占用,导致第三方登录拉取信息时无法拉取成功,错误如下:
刚才下班回家路上,无意中听到大街上放的歌,歌词有这么一句:“毡房外又有驼铃声声响起,我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望,如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
我们拆解完了 Linux 网络包的接收过程,也搞定了网络包的发送过程。内核收发网络包整体流程就算是摸清楚了。
下一篇标题是《深入理解MQ生产端的底层通信过程》,建议文章读完之前、或者读完之后,再读一遍我之前写的《RabbitMQ设计原理解析》,结合理解一下。
TCP 有很多连接状态,每一个都够聊十块钱儿的,比如我们以前讨论过 TIME_WAIT 和 FIN_WAIT1,最近时不时听人提起 CLOSE_WAIT,感觉有必要梳理一下。
linux内核中会维护两个队列: 1)未完成队列:接收到一个SYN建立连接请求,处于SYN_RCVD状态 2)已完成队列:已完成TCP三次握手过程,处于ESTABLISHED状态 3)当有一个SYN到来请求建立连接时,就在未完成队列中新建一项。当三次握手过程完成后,就将套接口从未完成队列移动到已完成队列。 4)backlog曾被定义为两个队列的总和的最大值,Berkely实现中的backlog值为上面两队列之和再乘以1.5。 5)如果当客户端SYN到达的时候队列已满,TCP将会忽略后续到达的SYN,但是不会给客户端发送RST信息,因为此时允许客户端重传SYN分节。如果启用syncookies (net.ipv4.tcp_syncookies = 1),新的连接不进入未完成队列,不受影响 6)backlog 即上述已完成队列的大小, 这个设置是个参考值,不是精确值. 内核会做些调整
周末的时候,有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样?
自从上次学习了TCP/IP的拥塞控制算法后,我越发想要更加深入的了解TCP/IP的一些底层原理,搜索了很多网络上的资料,看到了陶辉大神关于高性能网络编程的专栏,收益颇多。今天就总结一下,并且加上自己的一些思考。
在Linux上做网络应用的性能优化时,一般都会对TCP相关的内核参数进行调节,特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数,但我们经常是知其然而不知其所以然,每次照抄过来后,可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数,从协议栈的角度梳理它们,希望可以更容易的理解和记忆。注意,本文内容均来源于参考文档,没有去读相关的内核源码做验证,不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
最近碰到一个client端连接异常问题,然后定位分析并查阅各种资料文章,对TCP连接队列有个深入的理解 查资料过程中发现没有文章把这两个队列以及怎么观察他们的指标说清楚,希望通过这篇文章能把他们说清楚一点 问题描述 JAVA的client和server,使用socket通信。server使用NIO。 间歇性的出现client向server建立连接三次握手已经完成,但server的selector没有响应到这连接。 出问题的时间点,会同时有很多连接出现这个问题。 selector没有销毁重建,一直用的都是一
1、Sentinel 哨兵 Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器,以及这些主
Redis是一个开源键值数据存储,使用内存存储模型和可选的磁盘写入来实现持久性。它具有事务,发布/订阅和自动故障转移等功能。建议将Redis与Linux一起用于生产环境,但开发人员还将OS X作为他们开发和测试的平台。Redis的客户使用大多数语言编写,其网站上有推荐的语言。
于是出现了对于握手过程进行的攻击。攻击者发送大量的SYN包,服务器回应(SYN+ACK)包,但是攻击者不回应ACK包,这样的话,服务器不知道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。
本文作者张彦飞,原题“127.0.0.1 之本机网络通信过程知多少 ”,首次发布于“开发内功修炼”,转载请联系作者。本次有改动。
领取专属 10元无门槛券
手把手带您无忧上云