很简单呀，因为我做了实验和看了 TCP 协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。
在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？
今天有个小伙伴跑过来告诉我有个奇怪的问题需要协助下，问题确实也很奇怪。客户端调用RT比较高并伴随着间歇性异常Connection reset出现，而服务端CPU 、线程栈等看起来貌似都很正常，而且服务端的RT很短。
服务器收到客户端SYN数据包后，Linux内核会把该连接存储到半连接队列中，并响应SYN+ACK报文给客户端。
周末的时候，有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样？
在Linux上做网络应用的性能优化时，一般都会对TCP相关的内核参数进行调节，特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数，但我们经常是知其然而不知其所以然，每次照抄过来后，可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数，从协议栈的角度梳理它们，希望可以更容易的理解和记忆。注意，本文内容均来源于参考文档，没有去读相关的内核源码做验证，不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
TCP三次握手是建立一个可靠的连接的基础。在这个过程中，有两个重要的队列：半连接队列（SYN queue）和全连接队列（ACCEPT queue）。
Nginx 的机器，一般都是独立的机器，因此不建议采用默认 irqbalance 的自动绑定，而是要设置 smp_affinity、smp_affinity_list 的值来自动绑定。
从上面的解释来看，就是定义了一个队列，并设置了队列长度，那么这个队列是做什么的，接着往下看
前两天看到一群里在讨论 Tomcat 参数调优，看到不止一个人说通过 accept-count 来配置线程池大小，我笑了笑，看来其实很多人并不太了解我们用的最多的 WebServer Tomcat，这篇文章就来聊下 Tomcat 调优，重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
TCP是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。
1. rx-checksumming：校验接收报文的checksum。
之前有个小伙伴在技术交流群里咨询过一个问题，我当时还给提供了点排查思路，是个典型的八股文转实战分析的案例，我觉得挺有意思，趁着中午休息简单整理出来和大家分享下，有不严谨的地方欢迎大家指出。
最近遇到多台CVM中客户端访问服务器端超时的异常，当时查看了netstat -as信息，凭经验判断可能是tcp overflowed导致的。网卡队列满了，可能会造成子机网络包重传现象
wrk是一个基于C语言编写的HTTP性能测试工具，由GitHub用户wg/wrk开发。它能够通过生成大量的HTTP请求，对服务器进行压力测试，并实时输出测试结果，包括请求速率、传输速率、连接数等关键性能指标。wrk的设计初衷是为了提供一个简单易用的性能测试工具，同时保证测试结果的准确性和可靠性。
TCP 性能的提升不仅考察 TCP 的理论知识，还考察了对于操作系统提供的内核参数的理解与应用。
客户端在建立连接时会首先发送SYN报文，但是假设此时你没有收到服务端SYN+ACK的响应报文，客户端此时会重传SYN报文，此时你需要根据实际情况来调整SYN报文的重传次数，以便客户端能够及时得到反馈。
前文《使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT（一）》通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端，模拟演示了一个TCP通信的CLOSE_WAIT状态，这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。
对于基于互联网的通信应用（比如IM聊天、推送系统），数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中，TCP协议具备可靠的连接、错误重传、拥塞控制等优点，所以目前在应用场景上比UDP更广泛一些。
对于TCP的初始接收窗口大小，linux和centos的实现是不一样的，如linux内核3.10版本的初始接收窗口定义为10mss，但centos 3.10内核中的初始窗口大小定义为TCP_INIT_CWND * 2，即20*MSS大小。(看着linux源码在centos7.4系统上测试，纠结了好久。。)
性能优化，反复被提起，想要做到性能优化，先要理解性能优化，知其然才知其所以然，所谓的高性能就是合理的运用服务器的硬件资源，主要是Cpu和内存，硬盘，用大量的测试和计算，合理的计算使用服务器的资源，提升响应速度，提高吞吐率，就是性能优化的知识点。
建议直接看参考的原版报告，这篇为我大致记录的一些配置，部分还为理解，后续进行修改补充。
滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接受方发送窗口大小不为0的数据报的到来。 关于滑动窗口协议，还有三个术语，分别是： 窗口合拢：当窗口从左边向右边靠近的时候，这种现象发生在数据被发送和确认的时候。 窗口张开：当窗口的右边沿向右边移动的时候，这种现象发生在接受端处理了数据以后。 窗口收缩：当窗口的右边沿向左边移动的时候，这种现象不常发生。
最近，负责基础设施的同事，要对一批测试环境机器进行回收，回收就涉及到应用迁移，问题是整个过程一团乱。比如服务器A上一堆应用要调用服务器B上一堆服务，结果服务器B被回收了，然后服务器A上一堆应用报错。
网络数据传输：数据帧传输，由网卡读取并放入设备缓冲区ring buffer，当网络数据包到达的速率快于内核处理的速率时，ring buffer很快会被填满，新来的数据包将被丢弃。
本期分享一个比较常见的⽹络问题--丢包。例如我们去ping⼀个⽹站，如果能ping通，且⽹站返回信息全⾯，则说明与⽹站服务器的通信是畅通的，如果ping不通，或者⽹站返回的信息不全等，则很可能是数据被丢包了，类似情况想必⼤家都不陌⽣。针对⽹络丢包，本⽂提供⼀些常见的丢包故障定位⽅法，希望能够帮助⼤家对⽹络丢包有更多的认识，遇到丢包莫要慌，且跟着⼀起来涨姿(知)势(识)···
还真有，最近有 C++ 同学被百度从简历池捞起来面试了，目前经历了一二面，我把比较通用的面试问题抽离出来跟大家分享一波。
收到研发反馈，TCP重传严重。主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失
最近碰到一个client端连接异常问题，然后定位分析并查阅各种资料文章，对TCP连接队列有个深入的理解 查资料过程中发现没有文章把这两个队列以及怎么观察他们的指标说清楚，希望通过这篇文章能把他们说清楚一点 问题描述 JAVA的client和server，使用socket通信。server使用NIO。 间歇性的出现client向server建立连接三次握手已经完成，但server的selector没有响应到这连接。 出问题的时间点，会同时有很多连接出现这个问题。 selector没有销毁重建，一直用的都是一
在互联网后端日常开发接口的时候中，不管你使用的是C、Java、PHP还是Golang，都避免不了需要调用mysql、redis等组件来获取数据，可能还需要执行一些rpc远程调用，或者再调用一些其它restful api。 在这些调用的底层，基本都是在使用TCP协议进行传输。这是因为在传输层协议中，TCP协议具备可靠的连接，错误重传，拥塞控制等优点，所以目前应用比UDP更广泛一些。 相信你也一定听闻过TCP也存在一些缺点，那就是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小，而少见不给出具体的量化分析。不客气一点，这都是营养不大的废话。经过日常工作的思考之后，我更想弄明白的是，开销到底多大。一条TCP连接的建立需要耗时延迟多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化估计？当然影响TCP耗时的因素有很多，比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。
Cannot send, channel has already failed: tcp://ip:61616 Javax.jms.JMSException: Cannot send, channel has already failed: tcp://ip:61616
基于 TCP 的网络编程开发分为服务器端和客户端两部分，常见的核心步骤和流程如下：
首先我们来看如何标识一个TCP连接？系统是通过一个四元组来识别，(src_ip,src_port,dst_ip,dst_port)即源IP、源端口、目标IP、目标端口。比如我们有一台服务192.168.0.1，开启端口80.那么所有的客户端都会连接到这台服务的80端口上面。有一种误解，就是我们常说一台机器有65536个端口，那么承载的连接数就是65536个，这个说法是极其错误的，这就混淆了源端口和访问目标端口。我们做压测的时候，利用压测客户端，这个客户端的连接数是受到端口数的限制，但是服务器上面的连接数可以达到成千上万个，一般可以达到百万（4C8G配置），至于上限是多少，需要看优化的程度。具体做法如下：
来源：https://www.cnblogs.com/txlsz/p/13683892.html
当你在 Linux 服务器上运行 dmesg -T 命令，看到下面输出，可能会猜测遭受到 SYN 洪水攻击。
Linux 网络协议栈是根据 TCP/IP 模型来实现的，TCP/IP 模型由应用层、传输层、网络层和网络接口层，共四层组成，每一层都有各自的职责。
每次一发版导致服务A调用B服务超时, B没有任何请求记录日志, 初次定位到为网络问题
如非必须，关掉或卸载iptables防火墙，并阻止kernel加载iptables模块。这些模块会影响并发性能。
Linux服务器在运营过程中可能会受到黑客攻击，常见的攻击方式有SYN，DDOS等。通过更换IP，查找被攻击的站点可能避开攻击，但是中断服务的时间比较长。比较彻底的解决方法是添置硬件防火墙。不过，硬件防火墙价格比较昂贵。可以考虑利用Linux 系统本身提供的防火墙功能来防御。
最近就有个读者加了我的绿皮聊天软件，女生，头像挺好看的，就在我以为她要我拉她进群发成人专升本广告的时候。
hping3是一个基于C语言编写的网络性能测试工具，由Salvatore Sanfilippo开发。它能够模拟各种类型的网络包，对服务器进行压力测试，并提供丰富的选项来定制测试。hping3不仅适用于HTTP协议，还支持TCP、UDP、ICMP等多种协议，使其成为一个多功能的网络性能测试工具。
为了让系统能够支持更大的并发，除了必须安装event扩展之外，优化linux内核也是重中之重。
利用 Wireshark 抓包 VMware Network Adapter VMnet8 网卡，来分析 虚拟机 上的流量。
我第一次写 TCP 文章是这篇：硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
RabbitMQ是一款在全球范围内使用非常广泛的开源消息队列中间件。它轻量级、易部署、并支持多种协议。它基于Erlang开发，天生拥有高并发的能力。
Nginx TCP backlog 配置，如果是同一个 listen 端口，设置一次就好；比如有多个 server， 每个 server 都是监听 80 端口，只需要给一个 80 端口设置 backlog 就好，一般我们会有一个 default server，在default server 的 80 端口上设置 backlog 的值就可以了；设置好了之后，可以通过 ss -lnt 查看。
有监控的情况下，首先去看看监控大盘，看看有没有异常报警，如果初期还没有监控的情况我会按照下面步骤去看看系统层面有没有异常
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
