作者:谢代斌 研究测试TCP断开和异常的各种情况,以便于分析网络应用(比如tconnd)断网的原因和场景,帮组分析和定位连接异常掉线的问题,并提供给TCP相关的开发测试人员作为参考。 各个游戏接入都
这一下,大家总算停止了灌水(这群人都不用上班的,天天划水摸鱼),开始讨论起这个问题来。
Linux内核是高并发服务的关键组件之一。以下是一些可用于优化Linux内核的配置。
前文《使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT(一)》通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端,模拟演示了一个TCP通信的CLOSE_WAIT状态,这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。
周末的时候,有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样?
在开发 socket 应用程序时,首要任务通常是确保可靠性并满足一些特定的需求。利用本文中给出的 4 个提示,您就可以从头开始为实现最佳性能来设计并开发 socket 程序。本文内容包括对于 Sockets API 的使用、两个可以提高性能的 socket 选项以及 GNU/Linux 优化。
之前已经分析过了keep-alive,最近在使用nodejs的keep-alive的时候发现了遗漏了一个内容。本文进行一个补充说明。我们先看一下nodejs中keep-alive的使用。
根据用户提供的文章内容进行摘要总结
TCP 性能的提升不仅考察 TCP 的理论知识,还考察了对于操作系统提供的内核参数的理解与应用。
此前的文章中,我们介绍了 tcp 协议的基本概念和连接的建立与终止 最后,我们介绍了“经受时延的确认”,这是一种将 ACK 包与下一条数据包合并发送的策略,这样可以尽量减少发往网络的报文,以提高传输的效率,节省网络资源。 除此之外,TCP 还有很多其他算法和策略用来优化网络的使用。
在前文中讲述了Linux服务端TCP的某个链路变成CLOSE_WAIT状态,然后由于客户端已经关闭了(发送了RST标志的报文),那么服务端如果继续向这个链路中写入数据的话就会收到SIGPIPE信号而终止,这篇文章主要通过客户端进入CLOSE_WAIT后由于收到服务端产生的RST标志报文进入死循环的情况。注:RST表示复位,用来关闭异常的连接。
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。
当时有些地方写的比较笼统,然后我「把 Linux 接收+发送网络包的流程」这部分内容完善了下,现在重新分享给大家。
性能优化,反复被提起,想要做到性能优化,先要理解性能优化,知其然才知其所以然,所谓的高性能就是合理的运用服务器的硬件资源,主要是Cpu和内存,硬盘,用大量的测试和计算,合理的计算使用服务器的资源,提升响应速度,提高吞吐率,就是性能优化的知识点。
之前文章《Linux服务器性能评估与优化(一)》太长,阅读不方便,因此拆分成系列博文:
这时求职者紧张的心终于平静了,因为面试官没有深入下去的意思,继续问下去可能也不懂,皆大欢喜!当然本次面试基本上也就 game over了。
TCP是一个巨复杂的协议,因为他要解决很多问题,而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程,但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节,我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1:协议》(当然,你也可以去读一下RFC793以及后面N多的RFC)。另外,本文我会使用英文术语,这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章,目的有三个, 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
为了让大家更容易「看得见」 TCP,我搭建不少测试环境,并且数据包抓很多次,花费了不少时间,才抓到比较容易分析的数据包。
滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报,那么发送方将停止发送数据,等到接受方发送窗口大小不为0的数据报的到来。 关于滑动窗口协议,还有三个术语,分别是: 窗口合拢:当窗口从左边向右边靠近的时候,这种现象发生在数据被发送和确认的时候。 窗口张开:当窗口的右边沿向右边移动的时候,这种现象发生在接受端处理了数据以后。 窗口收缩:当窗口的右边沿向左边移动的时候,这种现象不常发生。
收到一位读者的私信,说字节面试有这么一个问题:服务端挂了,客户端的 TCP 连接会发生什么?
TCP是一个有状态通讯协议,所谓的有状态是指通信过程中通信的双方各自维护连接的状态。
在上篇网络篇中,我们已经介绍了几个 Linux 网络方向的性能分析工具,本文再补充几个。总结下来,余下的工具包括但不限于以下几个:
作者:Hcamael@知道创宇 404 实验室 时间:2019 年 6 月 26 日 英文版本:https://paper.seebug.org/967/
Cannot send, channel has already failed: tcp://ip:61616 Javax.jms.JMSException: Cannot send, channel has already failed: tcp://ip:61616
有时候我们要控制套接字的行为(如修改缓冲区的大小),这个时候我们就要控制套接字的选项了. 以下资料均从网上收集得到 getsockopt 和 setsockopt 获得套接口选项:
上周Linux内核修复了4个CVE漏洞[1],其中的CVE-2019-11477感觉是一个很厉害的Dos漏洞,不过因为有其他事打断,所以进展的速度比较慢,这期间网上已经有相关的分析文章了。[2][3]
TCP是一种面向连接的单播协议,在发送数据前,通信双方必须在彼此间建立一条连接。所谓的“连接”,其实是客户端和服务器的内存里保存的一份关于对方的信息,如ip地址、端口号等。
traceroute路由跟踪是利用IP数据包的TTL值来实现的,Linux 下 traceroute 首先发出 TTL = 1 的UDP 数据包,第一个路由器将 TTL 减 1 得 0 后就不再继续转发此数据包,而是返回一个 ICMP 超时报文,traceroute 从超时报文中即可提取出数据包所经过的第一个网关的 IP 地址。然后又发送了一个 TTL = 2 的 UDP 数据包,由此可获得第二个网关的 IP 地址。依次递增 TTL 便获得了沿途所有网关的 IP 地址。
1 以下是3天的 squid access.log,平均每天的access.log 为1.4GB
我本来只想写一个篇幅的文章的,但是TCP真TMD的复杂,比C++复杂多了,这30多年来,各种优化变种争论和修改。所以,写着写着就发现只有砍成两篇。
当 close 一个 TCP 连接时,如果还有没发送完的数据在缓冲区中,内核会怎么处理?
TCP断开连接,需要经历四次挥手,通信的双方都可主动断开连接,断开连接通信的双方占用的资源将会被释放。
大家对于 TCP 的三次握手应该都比较熟悉了,对于服务端,收到 SYN 包后该怎么处理,收到 Establish 之后又该怎么处理,或者说这些连接放在哪里,其实这也是之前面试问过的问题
作者Liam,海外老码农,对应用密码学、CPU微架构、高速网络通信等领域都有所涉猎。
而且,这个超时时间在不同的网络的情况下,根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置,TCP引入了RTT——Round Trip Time,也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间,从而可以方便地设置Timeout——RTO(Retransmission TimeOut),以让我们的重传机制更高效。 听起来似乎很简单,好像就是在发送端发包时记下t0,然后接收端再把这个ack回来时再记一个t1,于是RTT = t1 – t0。没那么简单,这只是一个采样,不能代表普遍情况。
1. rx-checksumming:校验接收报文的checksum。
TCP重传机制主要是为了防止网路包丢弃,重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传,重传的触发方式主要由以下几种:
为了使得多种设备能通过网络相互通信,和为了解决各种不同设备在网络互联中的兼容性问题,国际标标准化组织制定了开放式系统互联通信参考模型(open System Interconnection Reference Model),也就是 OSI 网络模型,该模型主要有 7 层,分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。
在Linux后端服务网络通信开发中,可能会遇到CLOSE_WAIT的状况。引起TCP CLOSE_WAIT状态的情况很多,归根结底还是由于被动关闭的一方没有关闭socket链路导致的。这篇文章主要是通过用一个简单的例子通过TCPDUMP和Wireshark这两个工具来模拟产生CLOSE_WAIT的情况,下一篇主要是对这个问题的原理解释。
最近,有小伙伴在群里提问:Linux系统怎么设置tcp_nodelay参数?也有小伙伴说问我。那今天,我们就来根据这个问题来聊聊在高并发场景下如何优化服务器的性能这个话题。
在前文中讲述了Linux服务端TCP通信出现CLOSE_WAIT状态的原因,这篇文章主要通过一个实例演示它个一个“恶劣”影响:直接使服务端进程Down掉。
3.每个TCP首部都包含源端和目的端的端口号,用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。
在Linux上做网络应用的性能优化时,一般都会对TCP相关的内核参数进行调节,特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数,但我们经常是知其然而不知其所以然,每次照抄过来后,可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数,从协议栈的角度梳理它们,希望可以更容易的理解和记忆。注意,本文内容均来源于参考文档,没有去读相关的内核源码做验证,不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
当Linux服务器的TIME_WAIT过多时, 通常会想到去修改参数降低TIME_WAIT时长, 以减少TIME_WAIT数量,但Linux并没有提供这样的接口, 除非重新编译内核。 Linux默认的TIME_WAIT时长一般是60秒, 定义在内核的include/net/tcp.h文件中: #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, * about 60 seconds */ #define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN /* BSD style FIN_WAIT2 deadlock breaker. * It used to be 3min, new value is 60sec, * to combine FIN-WAIT-2 timeout with * TIME-WAIT timer. */ 注意tcp_fin_timeout不是TIME_WAIT时间: # cat /proc/sys/net/ipv4/tcp_fin_timeout 60 tcp_fin_timeout实为FIN_WAIT_2状态的时长, Linux没有提供修改TIME_WAIT时长接口,除非修改宏的定义重新编译内核。 但Windows可以修改注册表中的TcpTimedWaitDelay值来控制TIME_WAIT时长。 RTO:超时重传(Retransmission Timeout) TIME_WAIT是一个常见经常的问题,相关内容(/etc/sysctl.conf或/proc/sys/net/ipv4): 1) net.ipv4.tcp_timestamps 为1表示开启TCP时间戳,用来计算往返时间RTT(Round-Trip Time)和防止序列号回绕 2) net.ipv4.tcp_tw_reuse 为1表示允许将TIME-WAIT的句柄重新用于新的TCP连接 3) net.ipv4.tcp_tw_recycle 为1表示开启TCP连接中TIME-WAIT的快速回收,NAT环境可能导致DROP掉SYN包(回复RST) 4) net.ipv4.tcp_fin_timeout FIN_WAIT_2状态的超时时长 5) net.ipv4.tcp_syncookies 为1时SYN Cookies,当SYN等待队列溢出时启用cookies来处理,可防范少量SYN攻击 6) net.ipv4.tcp_max_tw_buckets 保持TIME_WAIT套接字的最大个数,超过这个数字TIME_WAIT套接字将立刻被清除并打印警告信息 7) net.ipv4.ip_local_port_range 8) net.ipv4.tcp_max_syn_backlog 端口最大backlog内核限制,防止占用过大内核内存 9) net.ipv4.tcp_syn_retries 对一个新建连接,内核要发送多少个SYN连接请求才决定放弃,不应该大于255 10) net.ipv4.tcp_retries1 放弃回应一个TCP连接请求前﹐需要进行多少次重试,RFC规定最低的数值是3,这也是默认值 11) net.ipv4.tcp_retries2 在丢弃激活(已建立通讯状况)的TCP连接之前﹐需要进行多少次重试,默认值为15 12) net.ipv4.tcp_synack_retries TCP三次握手的SYN/ACK阶段重试次数,缺省5 13) net.ipv4.tcp_max_orphans 不属于任何进程(已经从进程上下文中删除)的sockets最大个数,超过这个值会被立即RESET,并同时显示警告信息 14) net.ipv4.tcp_orphan_retries 孤儿sockets废弃前重试的次数,缺省值是7 15) net.ipv4.tcp_mem 内核分配给TCP连接的内存,单位是page: 第一个数字表示TCP使用的page少于此值时,内核不进行任何处理(干预), 第二个数字表示TCP使用的page超过此值时,内核进入“memory pressure”压力模式, 第三个数字表示TCP使用的page超过些值时,报“Out of socket memory”错误,TCP 连接将被拒绝 16) net.ipv4.tcp_rmem 为每个TCP连接分配的读缓冲区内存大小,单位是byte 17) net.ipv4.tcp_wmem 为每个TCP
为什么要性能调优? 大部分的linux发行版是为了完全兼容市场中大部分计算机而设计的。这是一个相当混杂的硬件集合(硬盘,显卡,网卡,等等)。所以Red Hat, Suse,Mandriva和其他的一些发行版厂商选择了一些保守的设置来确保安装成功。 简单地说:你的发行版运行的很好,但是它可以运行地更好! 比如,可能有一个具体一些特殊特性的高级硬盘,而这些特性在标准配置的情况下可能就没被启用。 磁盘子系统的调优 对于Linux的Ext3/4来说,几乎在所有情况下都有所帮助的一个参数是关闭文件系统访问时间,在/
由于在Windows下经常使用NetAssist.exe这款网络调试工具进行TCP、UDP的服务端、客户端的监听,对于需要编写各种通信协议的TCP服务端、客户端以及UDP通信程序来说是很方便的。 NetAssist的下载地址为:NetAssist.exe 下载之后无需安装即可使用,是一款绿色软件,其软件界面如下图所示:
领取专属 10元无门槛券
手把手带您无忧上云