很简单呀，因为我做了实验和看了 TCP 协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。
服务器收到客户端SYN数据包后，Linux内核会把该连接存储到半连接队列中，并响应SYN+ACK报文给客户端。
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好，一般来说是几毫秒，或者是几十毫秒。如果响应时间一旦过长，比如超过了 1 秒，在用户侧就能感觉到非常明显的卡顿。如果长此以往，用户可能就直接用脚投票，卸载我们的 App 了。
TCP三次握手是建立一个可靠的连接的基础。在这个过程中，有两个重要的队列：半连接队列（SYN queue）和全连接队列（ACCEPT queue）。
今天有个小伙伴跑过来告诉我有个奇怪的问题需要协助下，问题确实也很奇怪。客户端调用RT比较高并伴随着间歇性异常Connection reset出现，而服务端CPU 、线程栈等看起来貌似都很正常，而且服务端的RT很短。
前两天看到一群里在讨论 Tomcat 参数调优，看到不止一个人说通过 accept-count 来配置线程池大小，我笑了笑，看来其实很多人并不太了解我们用的最多的 WebServer Tomcat，这篇文章就来聊下 Tomcat 调优，重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
最近遇到多台CVM中客户端访问服务器端超时的异常，当时查看了netstat -as信息，凭经验判断可能是tcp overflowed导致的。网卡队列满了，可能会造成子机网络包重传现象
SYN Flood 是互联网上最原始、最经典的 DDoS（Distributed Denial of Service）攻击之一。
在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？
hping3是一个基于C语言编写的网络性能测试工具，由Salvatore Sanfilippo开发。它能够模拟各种类型的网络包，对服务器进行压力测试，并提供丰富的选项来定制测试。hping3不仅适用于HTTP协议，还支持TCP、UDP、ICMP等多种协议，使其成为一个多功能的网络性能测试工具。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)，当然由于listen的backlog参数和半连接hash表以及全连接队列都相关，在这一篇博客里也一块讲了。
大家对于 TCP 的三次握手应该都比较熟悉了，对于服务端，收到 SYN 包后该怎么处理，收到 Establish 之后又该怎么处理，或者说这些连接放在哪里，其实这也是之前面试问过的问题
之前有个小伙伴在技术交流群里咨询过一个问题，我当时还给提供了点排查思路，是个典型的八股文转实战分析的案例，我觉得挺有意思，趁着中午休息简单整理出来和大家分享下，有不严谨的地方欢迎大家指出。
TCP是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。
周末的时候，有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样？
刚才下班回家路上，无意中听到大街上放的歌，歌词有这么一句：“毡房外又有驼铃声声响起，我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望，如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
TCP 性能的提升不仅考察 TCP 的理论知识，还考察了对于操作系统提供的内核参数的理解与应用。
2、服务端收到客户端的SYN请求后，服务端进入 SYN_RECV 状态，此时内核会将连接存储到半连接队列(SYN Queue)，并向 客户端回复 SYN+ACK
wrk是一个基于C语言编写的HTTP性能测试工具，由GitHub用户wg/wrk开发。它能够通过生成大量的HTTP请求，对服务器进行压力测试，并实时输出测试结果，包括请求速率、传输速率、连接数等关键性能指标。wrk的设计初衷是为了提供一个简单易用的性能测试工具，同时保证测试结果的准确性和可靠性。
数据可用性是一种以使用者为中心的设计概念，易用性设计的重点在于让产品的设计能够符合使用者的习惯与需求。以互联网网站的设计为例，希望让使用者在浏览的过程中不会产生压力或感到挫折，并能让使用者在使用网站功能时，能用最少的努力发挥最大的效能。基于这个原因，任何有违信息的“可用性”都算是违反信息安全的规定。因此，世上不少国家，不论是美国还是中国都有要求保持信息可以不受规限地流通的运动举行。
在后端相关岗位的入职面试中，三次握手的出场频率非常的高，甚至说它是必考题也不为过。一般的答案都是说客户端如何发起 SYN 握手进入 SYN_SENT 状态，服务器响应 SYN 并回复 SYNACK，然后进入 SYN_RECV，...... , 吧啦吧啦诸如此类。
后台业务一般都是通过TCP协议提供服务。服务难免需要版本升级，需要经历旧进程的退出和新进程的启动。为保证用户链接不异常中断，需要旧进程继续运行，直至处理完用户请求后再退出。这样才不会打断用户请求，这就是所谓的Graceful Shutdown：优雅退出。如果不做优雅退出，用户交互过程中任何一个步骤可能被升级打断，往小了有些不重要的业务，中断一下可以忍受，但如支付的基础服务，升级服务如果不支持优雅退出，造成大量用户掉线，进而造成恶劣的影响。所以对服务实现，不论对什么业务来说都是很有必要的。这也是为什么Go从1.8版本开始，标准库net/http对HTTPServer就添加了一个新的方法GracefulShutdown，使得进程可以把现有请求都处理完了再退出。
如果出现 SYN 丢包，那么将导致严重的性能问题，如果没有严重到完全连不上，那么在延迟时间上会表现出明显的时间特征，比如：1秒，3秒，7秒，15秒，31秒，具体可以参考：「SYN和RTO」，本文不说这个，就说说哪些情况会出现 SYN 丢包。
在Linux上做网络应用的性能优化时，一般都会对TCP相关的内核参数进行调节，特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数，但我们经常是知其然而不知其所以然，每次照抄过来后，可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数，从协议栈的角度梳理它们，希望可以更容易的理解和记忆。注意，本文内容均来源于参考文档，没有去读相关的内核源码做验证，不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
关于三次握手，还有很多细节之前的文章没有详细介绍，这篇文章我们以 backlog 参数来深入研究一下建连的过程。通过阅读这篇文章，你会了解到下面这些知识：
客户端在建立连接时会首先发送SYN报文，但是假设此时你没有收到服务端SYN+ACK的响应报文，客户端此时会重传SYN报文，此时你需要根据实际情况来调整SYN报文的重传次数，以便客户端能够及时得到反馈。
性能优化，反复被提起，想要做到性能优化，先要理解性能优化，知其然才知其所以然，所谓的高性能就是合理的运用服务器的硬件资源，主要是Cpu和内存，硬盘，用大量的测试和计算，合理的计算使用服务器的资源，提升响应速度，提高吞吐率，就是性能优化的知识点。
最近碰到一个client端连接异常问题，然后定位分析并查阅各种资料文章，对TCP连接队列有个深入的理解 查资料过程中发现没有文章把这两个队列以及怎么观察他们的指标说清楚，希望通过这篇文章能把他们说清楚一点 问题描述 JAVA的client和server，使用socket通信。server使用NIO。 间歇性的出现client向server建立连接三次握手已经完成，但server的selector没有响应到这连接。 出问题的时间点，会同时有很多连接出现这个问题。 selector没有销毁重建，一直用的都是一
其实只要在执行accept() 之前执行一个 sleep(20)，然后立刻执行客户端相关的方法，同时抓个包，就能得出结论。
之前有个读者在秋招面试的时候，被问了这么一个问题：SYN 报文什么时候情况下会被丢弃？
对于基于互联网的通信应用（比如IM聊天、推送系统），数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中，TCP协议具备可靠的连接、错误重传、拥塞控制等优点，所以目前在应用场景上比UDP更广泛一些。
简单来说，服务端收到客户端的SYN包之后，将连接放到半连接队列中，当服务端再次收到客户端的ACK包之后，会将连接从半连接队列移到全连接队列中，这样服务端的程序调用accept()方法的时候，就可以从全连接队列中获取到连接了.
在互联网后端日常开发接口的时候中，不管你使用的是C、Java、PHP还是Golang，都避免不了需要调用mysql、redis等组件来获取数据，可能还需要执行一些rpc远程调用，或者再调用一些其它restful api。 在这些调用的底层，基本都是在使用TCP协议进行传输。这是因为在传输层协议中，TCP协议具备可靠的连接，错误重传，拥塞控制等优点，所以目前应用比UDP更广泛一些。 相信你也一定听闻过TCP也存在一些缺点，那就是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小，而少见不给出具体的量化分析。不客气一点，这都是营养不大的废话。经过日常工作的思考之后，我更想弄明白的是，开销到底多大。一条TCP连接的建立需要耗时延迟多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化估计？当然影响TCP耗时的因素有很多，比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。
张翔 腾讯云高级工程师。前端性能监控（RUM）产品核心开发，主要负责前端性能监控系统中的上报服务层模块的设计与实现。 | 导语ReadinessProbe（就绪探针） 和 LivenessProbe （存活探针）为 K8s 中的健康检查探针，如果设置不当，可能会给服务带来反作用，甚至会短时间内让服务宕机。RUM 是如何设置，减少超高突发流量带来的不必要麻烦。 前言 腾讯云可观测—前端性能监控的接入层服务目前部署在腾讯云容器服务（TKE）之上，随着业务的增长，在超高突发流量面前出现了几次服务级联故障，在复盘
TCP三次握手后有个accept队列，进到这个队列才能从Listen变成accept，默认backlog 值是50。
大概在一年半之前的时候，我们的应用的某个业务开始间歇报SocketTimeoutException, 不是前端调用我们发生SocketTimeoutException，而是我们用 HTTP Client中台拉取数据的时候，会偶尔报SocketTimeException, 这个偶尔可能是一个月报一次，也可能是两个月报一次，可能一个星期报两次，频率不固定，次数也不固定，当我第一次看到这个异常的时候，我的第一个反应就是用这个异常信息去搜索引擎上搜索解决方案，我并不理解这个异常说明了什么，但是按照我以往的经验来说，一般都有解决方案，对搜索引擎的方案一般都是延长超时时间，于是我延长了超时时间，但这并没有根本上解决问题，还是会出问题。延长超时时间不管用之后，我就扩容，但是扩容依然也不管用，我当时在尝试复现这个异常的时候，也忽略了一些东西，然后导致我在测试无法复现，能够复现的问题都是好问题，我之前面试的时候也背过三次握手，也学过Java 的原生Socket 编程，Netty，我背过Tomcat的acceptCount参数，但是碰到这个问题，这些知识仍然没有帮我解决问题，原因当时我网络的知识没有连接起来，他们孤零零的，向孤零零的神经元一样，没建立起来连接，最后这个问题开始让这些知识开始建立连接，成体系的发展。连接才是有价值的。
网络编程几乎是每一门编程语言都会涉及的内容，虽然各种语言调用的方式可能不一样，但它们背后的原理支持都是一样的。因此本文将从TCP的连接的建立说起。在此之前，假设你已经对计算机网络有了最基本的认识。
记得刚毕业找工作面试的时候，经常会被问到：你知道“3次握手，4次挥手”吗？这时候我会“胸有成竹”地“背诵”前期准备好的“答案”，第一次怎么怎么，第二次……答完就没有下文了，面试官貌似也没有深入下去的意思，深入下去我也不懂，皆大欢喜！
网络数据传输：数据帧传输，由网卡读取并放入设备缓冲区ring buffer，当网络数据包到达的速率快于内核处理的速率时，ring buffer很快会被填满，新来的数据包将被丢弃。
大家好，我是飞哥。飞哥在北京摇号 9 年多，最近终于算是搞下来个北京的电动车牌，其中的艰难过程写个一万字估计都写不完。不管咋说，新能源也是车，总算是有车能开了。这几天买车卖车（外地牌）忙的团团转。不过无论多忙，硬核文章仍然不能停！
TCP断开连接，需要经历四次挥手，通信的双方都可主动断开连接，断开连接通信的双方占用的资源将会被释放。
SYN攻击利用的是TCP的三次握手机制，攻击端利用伪造的IP地址向被攻击端发出请求，而被攻击端发出的响应 报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。
自从上次学习了TCP/IP的拥塞控制算法后，我越发想要更加深入的了解TCP/IP的一些底层原理，搜索了很多网络上的资料，看到了陶辉大神关于高性能网络编程的专栏，收益颇多。今天就总结一下，并且加上自己的一些思考。
来源:高效运维 ID:greatops 问题描述 监控系统发现电商网站主页及其它页面间歇性的无法访问； 查看安全防护和网络流量、应用系统负载均正常； 系统重启后，能够暂时解决，但持续一段时间后间歇性问题再次出现。 此时问题已影响到整个网站的正常业务，我那个心惊呀，最主要是报警系统没有任何报警，服务运行一切正常，瞬时背上的汗已经出来了。但还是要静心，来仔细寻找蛛丝马迹，来一步一步找问题。 问题初步判断 检查dev 和 网卡设备层，是否有error和drop ，分析在硬件和系统层是否异常 ----- 命令
此时问题已经影响到整个网站的正常业务，我的那个心惊的呀，最主要报警系统没有任何报警，服务运行一切正常，瞬时背上的汗已经出来了。但还是要静心，来仔细寻找蛛丝马迹，来一步一步找问题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
