在《深入解析常见三次握手异常》 这一文中,我们讨论到如果发生连接队列溢出而丢包的话,会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢?
很简单呀,因为我做了实验和看了 TCP 协议栈的内核源码,发现要增大这两个队列长度,不是简简单单增大某一个参数就可以的。
周末的时候,有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样?
今天有个小伙伴跑过来告诉我有个奇怪的问题需要协助下,问题确实也很奇怪。客户端调用RT比较高并伴随着间歇性异常Connection reset出现,而服务端CPU 、线程栈等看起来貌似都很正常,而且服务端的RT很短。
2、服务端收到客户端的SYN请求后,服务端进入 SYN_RECV 状态,此时内核会将连接存储到半连接队列(SYN Queue),并向 客户端回复 SYN+ACK
收到个读者的问题,他在面试鹅厂的时候,被搞懵了,因为面试官问了他这么一个网络问题:
服务器收到客户端SYN数据包后,Linux内核会把该连接存储到半连接队列中,并响应SYN+ACK报文给客户端。
TCP有限状态机 TCP服务 创建TCP服务的四个基本步骤: socket – 创建socket套接字。 bind – 绑定要监听的IP地址。 listen – 开始监听客户端连接请求。 accept
在Linux上做网络应用的性能优化时,一般都会对TCP相关的内核参数进行调节,特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数,但我们经常是知其然而不知其所以然,每次照抄过来后,可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数,从协议栈的角度梳理它们,希望可以更容易的理解和记忆。注意,本文内容均来源于参考文档,没有去读相关的内核源码做验证,不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
前两天看到一群里在讨论 Tomcat 参数调优,看到不止一个人说通过 accept-count 来配置线程池大小,我笑了笑,看来其实很多人并不太了解我们用的最多的 WebServer Tomcat,这篇文章就来聊下 Tomcat 调优,重点介绍下线程池调优及 TCP 半连接、全连接队列调优。
Nginx 的机器,一般都是独立的机器,因此不建议采用默认 irqbalance 的自动绑定,而是要设置 smp_affinity、smp_affinity_list 的值来自动绑定。
大家对于 TCP 的三次握手应该都比较熟悉了,对于服务端,收到 SYN 包后该怎么处理,收到 Establish 之后又该怎么处理,或者说这些连接放在哪里,其实这也是之前面试问过的问题
TCP是一种面向连接的单播协议,在发送数据前,通信双方必须在彼此间建立一条连接。所谓的“连接”,其实是客户端和服务器的内存里保存的一份关于对方的信息,如ip地址、端口号等。
1. rx-checksumming:校验接收报文的checksum。
TCP 性能的提升不仅考察 TCP 的理论知识,还考察了对于操作系统提供的内核参数的理解与应用。
前文《使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT(一)》通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端,模拟演示了一个TCP通信的CLOSE_WAIT状态,这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。
性能优化,反复被提起,想要做到性能优化,先要理解性能优化,知其然才知其所以然,所谓的高性能就是合理的运用服务器的硬件资源,主要是Cpu和内存,硬盘,用大量的测试和计算,合理的计算使用服务器的资源,提升响应速度,提高吞吐率,就是性能优化的知识点。
之前有个读者在秋招面试的时候,被问了这么一个问题:SYN 报文什么时候情况下会被丢弃?
最近遇到多台CVM中客户端访问服务器端超时的异常,当时查看了netstat -as信息,凭经验判断可能是tcp overflowed导致的。网卡队列满了,可能会造成子机网络包重传现象
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好,一般来说是几毫秒,或者是几十毫秒。如果响应时间一旦过长,比如超过了 1 秒,在用户侧就能感觉到非常明显的卡顿。如果长此以往,用户可能就直接用脚投票,卸载我们的 App 了。
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。
SYN Flood 是互联网上最原始、最经典的 DDoS(Distributed Denial of Service)攻击之一。
刚才下班回家路上,无意中听到大街上放的歌,歌词有这么一句:“毡房外又有驼铃声声响起,我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望,如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
现在很多人都在诟病Linux内核协议栈收包效率低,不管他们是真的懂还是一点都不懂只是听别人说的,反正就是在一味地怼Linux内核协议栈,他们的武器貌似只有DPDK。
TCP三次握手是建立一个可靠的连接的基础。在这个过程中,有两个重要的队列:半连接队列(SYN queue)和全连接队列(ACCEPT queue)。
数据可用性是一种以使用者为中心的设计概念,易用性设计的重点在于让产品的设计能够符合使用者的习惯与需求。以互联网网站的设计为例,希望让使用者在浏览的过程中不会产生压力或感到挫折,并能让使用者在使用网站功能时,能用最少的努力发挥最大的效能。基于这个原因,任何有违信息的“可用性”都算是违反信息安全的规定。因此,世上不少国家,不论是美国还是中国都有要求保持信息可以不受规限地流通的运动举行。
对于基于互联网的通信应用(比如IM聊天、推送系统),数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中,TCP协议具备可靠的连接、错误重传、拥塞控制等优点,所以目前在应用场景上比UDP更广泛一些。
之前有个小伙伴在技术交流群里咨询过一个问题,我当时还给提供了点排查思路,是个典型的八股文转实战分析的案例,我觉得挺有意思,趁着中午休息简单整理出来和大家分享下,有不严谨的地方欢迎大家指出。
这篇文章我打算从一个初学者的角度开始聊起,让大家了解下我眼里的socket是什么以及socket的原理和内核实现。
首先我们来看如何标识一个TCP连接?系统是通过一个四元组来识别,(src_ip,src_port,dst_ip,dst_port)即源IP、源端口、目标IP、目标端口。比如我们有一台服务192.168.0.1,开启端口80.那么所有的客户端都会连接到这台服务的80端口上面。有一种误解,就是我们常说一台机器有65536个端口,那么承载的连接数就是65536个,这个说法是极其错误的,这就混淆了源端口和访问目标端口。我们做压测的时候,利用压测客户端,这个客户端的连接数是受到端口数的限制,但是服务器上面的连接数可以达到成千上万个,一般可以达到百万(4C8G配置),至于上限是多少,需要看优化的程度。具体做法如下:
从上面的解释来看,就是定义了一个队列,并设置了队列长度,那么这个队列是做什么的,接着往下看
TCP断开连接,需要经历四次挥手,通信的双方都可主动断开连接,断开连接通信的双方占用的资源将会被释放。
这篇文章主要是从tcp连接建立的角度来分析客户端程序如何利用connect函数和服务端程序建立tcp连接的,了解connect函数在建立连接的过程中底层协议栈做了哪些事情。
建议直接看参考的原版报告,这篇为我大致记录的一些配置,部分还为理解,后续进行修改补充。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核),当然由于listen的backlog参数和半连接hash表以及全连接队列都相关,在这一篇博客里也一块讲了。
我相信大家刚开始学网络编程中socket的时候,都跟我一样对书上所讲的socket概念云里雾里的、似懂非懂,很是困扰。
最近碰到一个client端连接异常问题,然后定位分析并查阅各种资料文章,对TCP连接队列有个深入的理解 查资料过程中发现没有文章把这两个队列以及怎么观察他们的指标说清楚,希望通过这篇文章能把他们说清楚一点 问题描述 JAVA的client和server,使用socket通信。server使用NIO。 间歇性的出现client向server建立连接三次握手已经完成,但server的selector没有响应到这连接。 出问题的时间点,会同时有很多连接出现这个问题。 selector没有销毁重建,一直用的都是一
strace会追踪程序运行时的整个生命周期, 输出每一个系统调用的名字、参数、返回值和执行所消耗的时间等,是高级运维和开发人员排查问题的杀手铜。https://www.cnblogs.com/fadewalk/p/10847068.html
大概在一年半之前的时候,我们的应用的某个业务开始间歇报SocketTimeoutException, 不是前端调用我们发生SocketTimeoutException,而是我们用 HTTP Client中台拉取数据的时候,会偶尔报SocketTimeException, 这个偶尔可能是一个月报一次,也可能是两个月报一次,可能一个星期报两次,频率不固定,次数也不固定,当我第一次看到这个异常的时候,我的第一个反应就是用这个异常信息去搜索引擎上搜索解决方案,我并不理解这个异常说明了什么,但是按照我以往的经验来说,一般都有解决方案,对搜索引擎的方案一般都是延长超时时间,于是我延长了超时时间,但这并没有根本上解决问题,还是会出问题。延长超时时间不管用之后,我就扩容,但是扩容依然也不管用,我当时在尝试复现这个异常的时候,也忽略了一些东西,然后导致我在测试无法复现,能够复现的问题都是好问题,我之前面试的时候也背过三次握手,也学过Java 的原生Socket 编程,Netty,我背过Tomcat的acceptCount参数,但是碰到这个问题,这些知识仍然没有帮我解决问题,原因当时我网络的知识没有连接起来,他们孤零零的,向孤零零的神经元一样,没建立起来连接,最后这个问题开始让这些知识开始建立连接,成体系的发展。连接才是有价值的。
Cannot send, channel has already failed: tcp://ip:61616 Javax.jms.JMSException: Cannot send, channel has already failed: tcp://ip:61616
接下来cillianplatform项目的更新频率保持一周一次,等稳定了到公开测试版本,会告知大家。
不管面试 Java 、C/C++、Python 等开发岗位, TCP 的知识点可以说是的必问的了。
BBR对TCP性能的提升是巨大的,它能更有效的使用当下网络环境,Youtube应用后在吞吐量上有平均4%提升(对于日本这样的网络环境有14%以上的提升):
本文将从上层介绍Linux上的TCP/IP栈是如何工作的,特别是socket系统调用和内核数据结构的交互、内核和实际网络的交互。写这篇文章的部分原因是解释监听队列溢出(listen queue overflow)是如何工作的,因为它与我工作中一直在研究的一个问题相关。
wrk是一个基于C语言编写的HTTP性能测试工具,由GitHub用户wg/wrk开发。它能够通过生成大量的HTTP请求,对服务器进行压力测试,并实时输出测试结果,包括请求速率、传输速率、连接数等关键性能指标。wrk的设计初衷是为了提供一个简单易用的性能测试工具,同时保证测试结果的准确性和可靠性。
之前一直有博主要求整理下 VPS 主机优化方法,那么如果你是 VPS 主机(Linux),可以尝试一下了,尤其是 linux 系统的内核参数优化。 一、增加 SWAP 分区 VPS(Virtual Private Server 虚拟专用服务器)技术,将一部服务器分割成多个虚拟专享服务器的优质服务。每个 VPS 都可分配独立公网 IP 地址、独立操作系统、独立超大空间、独立内存、独立执行程序和独立系统配置等。 下面是配置过程中的一些笔记: VPS 只有一个根分区,没有 swap 交换分区。VPS 内存不大,于
领取专属 10元无门槛券
手把手带您无忧上云