Linux ssh连接不上，能ping通，登录界面报错提示 audit: backlog limit exceeded
很简单呀，因为我做了实验和看了 TCP 协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。
前两天看到一群里在讨论 Tomcat 参数调优，看到不止一个人说通过 accept-count 来配置线程池大小，我笑了笑，看来其实很多人并不太了解我们用的最多的 WebServer Tomcat，这篇文章就来聊下 Tomcat 调优，重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)，当然由于listen的backlog参数和半连接hash表以及全连接队列都相关，在这一篇博客里也一块讲了。
云主机无法ssh及ping通，端口开启。VNC中有大量“backlog limit exceeded”的提示
最近遇到多台CVM中客户端访问服务器端超时的异常，当时查看了netstat -as信息，凭经验判断可能是tcp overflowed导致的。网卡队列满了，可能会造成子机网络包重传现象
大家对于 TCP 的三次握手应该都比较熟悉了，对于服务端，收到 SYN 包后该怎么处理，收到 Establish 之后又该怎么处理，或者说这些连接放在哪里，其实这也是之前面试问过的问题
今天有个小伙伴跑过来告诉我有个奇怪的问题需要协助下，问题确实也很奇怪。客户端调用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。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
网络数据传输：数据帧传输，由网卡读取并放入设备缓冲区ring buffer，当网络数据包到达的速率快于内核处理的速率时，ring buffer很快会被填满，新来的数据包将被丢弃。
在正式部署前，你可以先阅读前置准备，对部署过程中用到的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
【1】ulimit 与 TCP backlog：1）、修改 ulimit：通过 ulimit 修改 open files 参数，redis 建议把 open files 至少设置成 10032，因为 maxclients 是10000 [客户端的数据是以文件的形式进行保存的] ，另外 redis 内部最多会使用 32 个文件描述符。
服务器收到客户端SYN数据包后，Linux内核会把该连接存储到半连接队列中，并响应SYN+ACK报文给客户端。
TCP是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。
刚才下班回家路上，无意中听到大街上放的歌，歌词有这么一句：“毡房外又有驼铃声声响起，我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望，如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
TCP自从1974年被发明出来之后，历经30多年发展，目前成为最重要的互联网基础协议，但TCP协议中也存在一些缺陷。
配置关闭：主节点产生的数据无论大小都会及时的发送给从节点。redis默认关闭此配置，以保障较小的主从延迟。当然，这需要主从间保持较好的网络状况。
无论哪种中间件的搭建，正常主从模式搭建需要搭建在两台不同的服务器上才是正规的主从搭建模式。因为由于资源的限制，今天来演示一下在同一台服务器上，基于端口不一致搭建Redis的单机主从模式。
每次一发版导致服务A调用B服务超时, B没有任何请求记录日志, 初次定位到为网络问题
大概在一年半之前的时候，我们的应用的某个业务开始间歇报SocketTimeoutException, 不是前端调用我们发生SocketTimeoutException，而是我们用 HTTP Client中台拉取数据的时候，会偶尔报SocketTimeException, 这个偶尔可能是一个月报一次，也可能是两个月报一次，可能一个星期报两次，频率不固定，次数也不固定，当我第一次看到这个异常的时候，我的第一个反应就是用这个异常信息去搜索引擎上搜索解决方案，我并不理解这个异常说明了什么，但是按照我以往的经验来说，一般都有解决方案，对搜索引擎的方案一般都是延长超时时间，于是我延长了超时时间，但这并没有根本上解决问题，还是会出问题。延长超时时间不管用之后，我就扩容，但是扩容依然也不管用，我当时在尝试复现这个异常的时候，也忽略了一些东西，然后导致我在测试无法复现，能够复现的问题都是好问题，我之前面试的时候也背过三次握手，也学过Java 的原生Socket 编程，Netty，我背过Tomcat的acceptCount参数，但是碰到这个问题，这些知识仍然没有帮我解决问题，原因当时我网络的知识没有连接起来，他们孤零零的，向孤零零的神经元一样，没建立起来连接，最后这个问题开始让这些知识开始建立连接，成体系的发展。连接才是有价值的。
某日线上登录出现故障,排查日志发现HttpClient请求时随机分配到的端口被占用,导致第三方登录拉取信息时无法拉取成功,错误如下:
在 Linux 系统中，常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
TCP 有很多连接状态，每一个都够聊十块钱儿的，比如我们以前讨论过 TIME_WAIT 和 FIN_WAIT1，最近时不时听人提起 CLOSE_WAIT，感觉有必要梳理一下。
backlog 参数定义了 sockfd 的挂起连接队列可能增长到的最大长度。如果连接请求在队列已满时到达，则客户端可能会收到指示 ECONNREFUSED 的错误，或者，如果基础协议支持重新传输，则可能会忽略该请求，以便以后的重新尝试连接成功。
下一篇标题是《深入理解MQ生产端的底层通信过程》，建议文章读完之前、或者读完之后，再读一遍我之前写的《RabbitMQ设计原理解析》，结合理解一下。
关于三次握手，还有很多细节之前的文章没有详细介绍，这篇文章我们以 backlog 参数来深入研究一下建连的过程。通过阅读这篇文章，你会了解到下面这些知识：
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 即上述已完成队列的大小, 这个设置是个参考值,不是精确值. 内核会做些调整
如果有人问redis 到底跑的有多快,简单的回答,纳秒等级, 可如果再要细问,估计只能进行测试了,每台机器的物理硬件标准不同,所以就需要基准测试. 另外redis到底需要不需要进行调优,可能大部分场景不需要,但不需要不意味这你可以欣然接受你不会.
Redis是一个开源键值数据存储，使用内存存储模型和可选的磁盘写入来实现持久性。它具有事务，发布/订阅和自动故障转移等功能。建议将Redis与Linux一起用于生产环境，但开发人员还将OS X作为他们开发和测试的平台。Redis的客户使用大多数语言编写，其网站上有推荐的语言。
于是出现了对于握手过程进行的攻击。攻击者发送大量的SYN包，服务器回应(SYN+ACK)包，但是攻击者不回应ACK包，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。
在Linux上做网络应用的性能优化时，一般都会对TCP相关的内核参数进行调节，特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数，但我们经常是知其然而不知其所以然，每次照抄过来后，可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数，从协议栈的角度梳理它们，希望可以更容易的理解和记忆。注意，本文内容均来源于参考文档，没有去读相关的内核源码做验证，不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
我们拆解完了 Linux 网络包的接收过程，也搞定了网络包的发送过程。内核收发网络包整体流程就算是摸清楚了。
周末的时候，有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样？
1、Sentinel 哨兵 Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主
自从上次学习了TCP/IP的拥塞控制算法后，我越发想要更加深入的了解TCP/IP的一些底层原理，搜索了很多网络上的资料，看到了陶辉大神关于高性能网络编程的专栏，收益颇多。今天就总结一下，并且加上自己的一些思考。
PS：在服务器硬件资源额定有限的情况下，最大的压榨服务器的性能，提高服务器的并发处理能力，是很多运维技术人员思考的问题。要提高Linux系统下的负载能力，可以使用nginx等原生并发处理能力就很强的web服务器，如果使用Apache的可以启用其Worker模式，来提高其并发处理能力。除此之外，在考虑节省成本的情况下，可以修改Linux的内核相关TCP参数，来最大的提高服务器性能。当然，最基础的提高负载问题，还是升级服务器硬件了，这是最根本的。 Linux系统下，TCP连接断开后，会以TIME_WAIT状态保
1、Sentinel 哨兵 ---- Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
