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