[转帖]高性能网络 | 你所不知道的 TIME_WAIT 和 CLOSE_WAIT

高性能,网络,知道,time,wait,close · 浏览次数 : 0

小编点评

1. 请问我们说连接池可以复用连接,是不是意味着,需要等到上个连接 time wait 结束后才能再次使用?所谓连接池复用,复用的一定是活跃的连接,所谓活跃,第一表明连接池里的连接都是 ESTABLISHED 的,第二,连接池做为上层应用,会有定时的心跳去保持连接的活跃性。既然连接都是活跃的,那就不存在有 TIME_WAIT 的概念了,在上篇里也有提到,TIME_WAIT 是在主动关闭连接的一方,在关闭连接后才进入的状态。既然已经关闭了,那么这条连接肯定已经不在连接池里面了,即被连接池释放了。 2. 想请问下,作为负载均衡的机器随机端口使用完的情况下大量 time_wait,不调整你文字里说的那三个参数,有其他的更好的方案吗?第一,随机端口使用完,你可以通过调整 /etc/sysctl.conf 下的 net.ipv4.ip_local_port_range 配置,至少修改成 &net.ipv4.ip_local_port_range=1024 65535,保证你的负载均衡服务器至少可以使用 6 万个随机端口,也即可以有 6 万的反向代理到后端的连接,可以支持每秒 1000 的并发(想一想,因为 TIME_WAIT 状态会持续 1 分钟后消失,所以一分钟最多有 6 万,每秒 1000)。 第三,如果真的量很大,上万上万 Și,可以考虑,让后端的服务器主动关闭连接,如果后端服务器没有外网的连接只有负载均衡服务器的连接(主要是没有 NAT 网络的连接),可以在后端服务器上配置 tw_recycle,然后同时,在负载均衡服务器上,配置 tw_reuse。 4. 如果你想深入的学习一下网络方面的知识,有什么推荐的?学习网络比学一门编程语言 “难”很多。所谓难,其实,是因为需要花很多的时间投入。我自己不算精通,只能说入门和理解。基本书可以推荐:《TCP/IP 协议详解》,必读;《TCP/IP 高效编程:改善网络程序的 44 个技巧》,必读;《Unix 环境高级编程》,必读;《Unix 网络编程:卷一》,我只读过卷一;另外,还需要熟悉一下网络工具,tcpdump 以及 wireshark,我的 notes 里有一个一站式学习 Wireshark:https://github.com/dafang/notebook/issues/114,也值得一读。有了这些积累,可能就是一些实践以及碎片化的学习和积累了。

正文

高性能网络 | 你所不知道的 TIME_WAIT 和 CLOSE_WAIT
https://my.oschina.net/fdhay/blog/638631

 

本文是我将最近两篇文章,重新整理成一篇,方便收藏。如果你已经阅读过前两篇,并且已经做了收藏,可以重新收藏本文即可。

 

你有收藏和整理文章的习惯吗?好好利用 Evernote 或者印象笔记,不要吝啬那点年费,你值得购买,并养成收藏和整理的习惯!

 

 

本文源于大家在公众号里面的留言,既然很多人都搞不清楚 TIME_WAIT 和 CLOSE_WAIT,那么小胖哥今天还是抽个时间,统一帮大家理理概念吧。

 

你遇到过 TIME_WAIT 的问题吗?

 

我相信很多都遇到过这个问题。一旦有用户在喊:网络变慢了。第一件事情就是,netstat -a | grep TIME_WAIT | wc -l 一下。哎呀妈呀,几千个 TIME_WAIT.

 

然后,做的第一件事情就是:打开 Google 或者 Bing,输入关键词:too many time wait。一定能找到解决方案,而排在最前面或者被很多人到处转载的解决方案一定是:

 

打开 sysctl.conf 文件,修改以下几个参数:

 

  • net.ipv4.tcp_tw_recycle = 1

  • net.ipv4.tcp_tw_reuse = 1

  • net.ipv4.tcp_timestamps = 1

 

你也会被告知,开启 tw_recylce 和 tw_reuse 一定需要 timestamps 的支持,而且这些配置一般不建议开启,但是对解决 TIME_WAIT 很多的问题,有很好的用处。

 

接下来,你就直接修改了这几个参数,reload 一下,发现,咦,没几分钟,TIME_WAIT 的数量真的降低了,也没发现哪个用户说有问题,然后就没有然后了。

 

做到这一步,相信 50% 或者更高比例的开发就已经止步了。问题好像解决了,但是,要彻底理解并解决这个问题,可能就没这么简单,或者说,还有很长的路要走!

 

什么是 TIME-WAIT 和 CLOSE-WAIT?

 

所谓,要解决问题,就要先理解问题。随便改两行代码,发现 bug “没有了”,也不是 bug 真的没有了,只是隐藏在更深的地方,你没有发现,或者以你的知识水平,你无法发现而已。

 

大家知道,由于 socket 是全双工的工作模式,一个 socket 的关闭,是需要四次握手来完成的。

 

  • 主动关闭连接的一方,调用 close ();协议层发送 FIN 包

  • 被动关闭的一方收到 FIN 包后,协议层回复 ACK;然后被动关闭的一方,进入 CLOSE_WAIT 状态,主动关闭的一方等待对方关闭,则进入 FIN_WAIT_2 状态;此时,主动关闭的一方 等待 被动关闭一方的应用程序,调用 close 操作

  • 被动关闭的一方在完成所有数据发送后,调用 close () 操作;此时,协议层发送 FIN 包给主动关闭的一方,等待对方的 ACK,被动关闭的一方进入 LAST_ACK 状态;

  • 主动关闭的一方收到 FIN 包,协议层回复 ACK;此时,主动关闭连接的一方,进入 TIME_WAIT 状态;而被动关闭的一方,进入 CLOSED 状态

  • 等待 2MSL 时间,主动关闭的一方,结束 TIME_WAIT,进入 CLOSED 状态

 

通过上面的一次 socket 关闭操作,你可以得出以下几点:

 

  1. 主动关闭连接的一方 - 也就是主动调用 socket 的 close 操作的一方,最终会进入 TIME_WAIT 状态

  2. 被动关闭连接的一方,有一个中间状态,即 CLOSE_WAIT,因为协议层在等待上层的应用程序,主动调用 close 操作后才主动关闭这条连接

  3. TIME_WAIT 会默认等待 2MSL 时间后,才最终进入 CLOSED 状态;

  4. 在一个连接没有进入 CLOSED 状态之前,这个连接是不能被重用的!

 

所以,这里凭你的直觉,TIME_WAIT 并不可怕(not really,后面讲),CLOSE_WAIT 才可怕,因为 CLOSE_WAIT 很多,表示说要么是你的应用程序写的有问题,没有合适的关闭 socket;要么是说,你的服务器 CPU 处理不过来(CPU 太忙)或者你的应用程序一直睡眠到其它地方 (锁,或者文件 I/O 等等),你的应用程序获得不到合适的调度时间,造成你的程序没法真正的执行 close 操作。

 

这里又出现两个问题:

 

  1. 上文提到的连接重用,那连接到底是个什么概念?

  2. 协议层为什么要设计一个 TIME_WAIT 状态?这个状态为什么默认等待 2MSL 时间才会进入 CLOSED

 

先解释清楚这两个问题,我们再来看,开头提到的几个网络配置究竟有什么用,以及 TIME_WAIT 的后遗症问题。

 

Socket 连接到底是个什么概念?

 

大家经常提 socket,那么,到底什么是一个 socket?其实,socket 就是一个 五元组,包括:

 

  1. 源 IP

  2. 源端口

  3. 目的 IP

  4. 目的端口

  5. 类型:TCP or UDP

 

这个五元组,即标识了一条可用的连接。注意,有很多人把一个 socket 定义成四元组,也就是 源 IP: 源端口 + 目的 IP: 目的端口,这个定义是不正确的。

 

例如,如果你的本地出口 IP 是 180.172.35.150,那么你的浏览器在连接某一个 Web 服务器,例如百度的时候,这条 socket 连接的四元组可能就是:

 

[180.172.35.150:45678, tcp, 180.97.33.108:80]

 

源 IP 为你的出口 IP 地址 180.172.35.150,源端口为随机端口 45678,目的 IP 为百度的某一个负载均衡服务器 IP 180.97.33.108,端口为 HTTP 标准的 80 端口。

 

如果这个时候,你再开一个浏览器,访问百度,将会产生一条新的连接:

 

[180.172.35.150:43678, tcp, 180.97.33.108:80]

 

这条新的连接的源端口为一个新的随机端口 43678。

 

如此来看,如果你的本机需要压测百度,那么,你最多可以创建多少个连接呢?我在文章《云思路 | 轻松构建千万级投票系统》里也稍微提过这个问题,没有阅读过本文的,可以发送 “投票系统” 阅读。

 

第二个问题,TIME_WAIT 有什么用?

 

如果我们来做个类比的话,TIME_WAIT 的出现,对应的是你的程序里的异常处理,它的出现,就是为了解决网络的丢包和网络不稳定所带来的其他问题:

 

第一,防止前一个连接【五元组,我们继续以 180.172.35.150:45678, tcp, 180.97.33.108:80 为例】上延迟的数据包或者丢失重传的数据包,被后面复用的连接【前一个连接关闭后,此时你再次访问百度,新的连接可能还是由 180.172.35.150:45678, tcp, 180.97.33.108:80 这个五元组来表示,也就是源端口凑巧还是 45678】错误的接收(异常:数据丢了,或者传输太慢了),参见下图:

 

  • SEQ=3 的数据包丢失,重传第一次,没有得到 ACK 确认

  • 如果没有 TIME_WAIT,或者 TIME_WAIT 时间非常端,那么关闭的连接【180.172.35.150:45678, tcp, 180.97.33.108:80 的状态变为了 CLOSED,源端口可被再次利用】,马上被重用【对 180.97.33.108:80 新建的连接,复用了之前的随机端口 45678】,并连续发送 SEQ=1,2 的数据包

  • 此时,前面的连接上的 SEQ=3 的数据包再次重传,同时,seq 的序号刚好也是 3(这个很重要,不然,SEQ 的序号对不上,就会 RST 掉),此时,前面一个连接上的数据被后面的一个连接错误的接收

 

第二,确保连接方能在时间范围内,关闭自己的连接。其实,也是因为丢包造成的,参见下图:

 

  • 主动关闭方关闭了连接,发送了 FIN;

  • 被动关闭方回复 ACK 同时也执行关闭动作,发送 FIN 包;此时,被动关闭的一方进入 LAST_ACK 状态

  • 主动关闭的一方回去了 ACK,主动关闭一方进入 TIME_WAIT 状态;

  • 但是最后的 ACK 丢失,被动关闭的一方还继续停留在 LAST_ACK 状态

  • 此时,如果没有 TIME_WAIT 的存在,或者说,停留在 TIME_WAIT 上的时间很短,则主动关闭的一方很快就进入了 CLOSED 状态,也即是说,如果此时新建一个连接,源随机端口如果被复用,在 connect 发送 SYN 包后,由于被动方仍认为这条连接【五元组】还在等待 ACK,但是却收到了 SYN,则被动方会回复 RST

  • 造成主动创建连接的一方,由于收到了 RST,则连接无法成功

 

所以,你看到了,TIME_WAIT 的存在是很重要的,如果强制忽略 TIME_WAIT,还是有很高的机率,造成数据粗乱,或者短暂性的连接失败。

 

那么,为什么说,TIME_WAIT 状态会是持续 2MSL(2 倍的 max segment lifetime)呢?这个时间可以通过修改内核参数调整吗?第一,这个 2MSL,是 RFC 793 里定义的,参见 RFC 的截图标红的部分:


这个定义,更多的是一种保障(IP 数据包里的 TTL,即数据最多存活的跳数,真正反应的才是数据在网络上的存活时间),确保最后丢失了 ACK,被动关闭的一方再次重发 FIN 并等待回复的 ACK,一来一去两个来回。内核里,写死了这个 MSL 的时间为:30 秒(有读者提醒,RFC 里建议的 MSL 其实是 2 分钟,但是很多实现都是 30 秒),所以 TIME_WAIT 的即为 1 分钟:

 

所以,再次回想一下前面的问题,如果一条连接,即使在四次握手关闭了,由于 TIME_WAIT 的存在,这个连接,在 1 分钟之内,也无法再次被复用,那么,如果你用一台机器做压测的客户端,你一分钟能发送多少并发连接请求?如果这台是一个负载均衡服务器,一台负载均衡服务器,一分钟可以有多少个连接同时访问后端的服务器呢?

 

TIME_WAIT 很多,可怕吗?

 

如果你通过 ss -tan state time-wait | wc -l 发现,系统中有很多 TIME_WAIT,很多人都会紧张。多少算多呢?几百几千?如果是这个量级,其实真的没必要紧张。第一,这个量级,因为 TIME_WAIT 所占用的内存很少很少;因为记录和寻找可用的 local port 所消耗的 CPU 也基本可以忽略。

 

会占用内存吗?当然!任何你可以看到的数据,内核里都需要有相关的数据结构来保存这个数据啊。一条 Socket 处于 TIME_WAIT 状态,它也是一条 “存在” 的 socket,内核里也需要有保持它的数据:

  1. 内核里有保存所有连接的一个 hash table,这个 hash table 里面既包含 TIME_WAIT 状态的连接,也包含其他状态的连接。主要用于有新的数据到来的时候,从这个 hash table 里快速找到这条连接。不同的内核对这个 hash table 的大小设置不同,你可以通过 dmesg 命令去找到你的内核设置的大小:

     

  2. 还有一个 hash table 用来保存所有的 bound ports,主要用于可以快速的找到一个可用的端口或者随机端口:

     

 

由于内核需要保存这些数据,必然,会占用一定的内存。

 

会消耗 CPU 吗?当然!每次找到一个随机端口,还是需要遍历一遍 bound ports 的吧,这必然需要一些 CPU 时间。

 

TIME_WAIT 很多,既占内存又消耗 CPU,这也是为什么很多人,看到 TIME_WAIT 很多,就蠢蠢欲动的想去干掉他们。其实,如果你再进一步去研究,1 万条 TIME_WAIT 的连接,也就多消耗 1M 左右的内存,对现代的很多服务器,已经不算什么了。至于 CPU,能减少它当然更好,但是不至于因为 1 万多个 hash item 就担忧。

 

如果,你真的想去调优,还是需要搞清楚别人的调优建议,以及调优参数背后的意义!

 

TIME_WAIT 调优,你必须理解的几个调优参数

 

在具体的图例之前,我们还是先解析一下相关的几个参数存在的意义。

 

net.ipv4.tcp_timestamps

 

RFC 1323 在 TCP Reliability 一节里,引入了 timestamp 的 TCP option,两个 4 字节的时间戳字段,其中第一个 4 字节字段用来保存发送该数据包的时间,第二个 4 字节字段用来保存最近一次接收对方发送到数据的时间。有了这两个时间字段,也就有了后续优化的余地。

 

tcp_tw_reuse 和 tcp_tw_recycle 就依赖这些时间字段。

 

net.ipv4.tcp_tw_reuse

 

字面意思,reuse TIME_WAIT 状态的连接。

 

时刻记住一条 socket 连接,就是那个五元组,出现 TIME_WAIT 状态的连接,一定出现在主动关闭连接的一方。所以,当主动关闭连接的一方,再次向对方发起连接请求的时候(例如,客户端关闭连接,客户端再次连接服务端,此时可以复用了;负载均衡服务器,主动关闭后端的连接,当有新的 HTTP 请求,负载均衡服务器再次连接后端服务器,此时也可以复用),可以复用 TIME_WAIT 状态的连接。

 

通过字面解释,以及例子说明,你看到了,tcp_tw_reuse 应用的场景:某一方,需要不断的通过 “短连接” 连接其他服务器,总是自己先关闭连接 (TIME_WAIT 在自己这方),关闭后又不断的重新连接对方。

 

那么,当连接被复用了之后,延迟或者重发的数据包到达,新的连接怎么判断,到达的数据是属于复用后的连接,还是复用前的连接呢?那就需要依赖前面提到的两个时间字段了。复用连接后,这条连接的时间被更新为当前的时间,当延迟的数据达到,延迟数据的时间是小于新连接的时间,所以,内核可以通过时间判断出,延迟的数据可以安全的丢弃掉了。

 

这个配置,依赖于连接双方,同时对 timestamps 的支持。同时,这个配置,仅仅影响 outbound 连接,即做为客户端的角色,连接服务端 [connect(dest_ip, dest_port)] 时复用 TIME_WAIT 的 socket。

 

net.ipv4.tcp_tw_recycle

 

字面意思,销毁掉 TIME_WAIT。

 

当开启了这个配置后,内核会快速的回收处于 TIME_WAIT 状态的 socket 连接。多快?不再是 2MSL,而是一个 RTO(retransmission timeout,数据包重传的 timeout 时间)的时间,这个时间根据 RTT 动态计算出来,但是远小于 2MSL。

 

有了这个配置,还是需要保障 丢失重传或者延迟的数据包,不会被新的连接 (注意,这里不再是复用了,而是之前处于 TIME_WAIT 状态的连接已经被 destroy 掉了,新的连接,刚好是和某一个被 destroy 掉的连接使用了相同的五元组而已) 所错误的接收。在启用该配置,当一个 socket 连接进入 TIME_WAIT 状态后,内核里会记录包括该 socket 连接对应的五元组中的对方 IP 等在内的一些统计数据,当然也包括从该对方 IP 所接收到的最近的一次数据包时间。当有新的数据包到达,只要时间晚于内核记录的这个时间,数据包都会被统统的丢掉。

 

这个配置,依赖于连接双方对 timestamps 的支持。同时,这个配置,主要影响到了 inbound 的连接(对 outbound 的连接也有影响,但是不是复用),即做为服务端角色,客户端连进来,服务端主动关闭了连接,TIME_WAIT 状态的 socket 处于服务端,服务端快速的回收该状态的连接。

 

由此,如果客户端处于 NAT 的网络 (多个客户端,同一个 IP 出口的网络环境),如果配置了 tw_recycle,就可能在一个 RTO 的时间内,只能有一个客户端和自己连接成功 (不同的客户端发包的时间不一致,造成服务端直接把数据包丢弃掉)。

 

我尽量尝试用文字解释清楚,但是,来点案例和图示,应该有助于我们彻底理解。

 

我们来看这样一个网络情况:

 

  1. 客户端 IP 地址为:180.172.35.150,我们可以认为是浏览器

  2. 负载均衡有两个 IP,外网 IP 地址为 115.29.253.156,内网地址为 10.162.74.10;外网地址监听 80 端口

  3. 负载均衡背后有两台 Web 服务器,一台 IP 地址为 10.162.74.43,监听 80 端口;另一台为 10.162.74.44,监听 80 端口

  4. Web 服务器会连接数据服务器,IP 地址为 10.162.74.45,监听 3306 端口

 

这种简单的架构下,我们来看看,在不同的情况下,我们今天谈论的 tw_reuse/tw_recycle 对网络连接的影响。

 

先做个假定:

  1. 客户端通过 HTTP/1.1 连接负载均衡,也就是说,HTTP 协议投 Connection 为 keep-alive,所以我们假定,客户端 对 负载均衡服务器 的 socket 连接,客户端会断开连接,所以,TIME_WAIT 出现在客户端

  2. Web 服务器和 MySQL 服务器的连接,我们假定,Web 服务器上的程序在连接结束的时候,调用 close 操作关闭 socket 资源连接,所以,TIME_WAIT 出现在 Web 服务器端。

 

那么,在这种假定下:

  1. Web 服务器上,肯定可以配置开启的配置:tcp_tw_reuse;如果 Web 服务器有很多连向 DB 服务器的连接,可以保证 socket 连接的复用。

  2. 那么,负载均衡服务器和 Web 服务器,谁先关闭连接,则决定了我们怎么配置 tcp_tw_reuse/tcp_tw_recycle 了

 

方案一:负载均衡服务器 首先关闭连接 

 

在这种情况下,因为负载均衡服务器对 Web 服务器的连接,TIME_WAIT 大都出现在负载均衡服务器上,所以,在负载均衡服务器上的配置:

  • net.ipv4.tcp_tw_reuse = 1 // 尽量复用连接

  • net.ipv4.tcp_tw_recycle = 0 // 不能保证客户端不在 NAT 的网络啊

 

在 Web 服务器上的配置为:

  • net.ipv4.tcp_tw_reuse = 1 // 这个配置主要影响的是 Web 服务器到 DB 服务器的连接复用

  • net.ipv4.tcp_tw_recycle: 设置成 1 和 0 都没有任何意义。想一想,在负载均衡和它的连接中,它是服务端,但是 TIME_WAIT 出现在负载均衡服务器上;它和 DB 的连接,它是客户端,recycle 对它并没有什么影响,关键是 reuse

 

 

方案二:Web 服务器首先关闭来自负载均衡服务器的连接

 

在这种情况下,Web 服务器变成 TIME_WAIT 的重灾区。负载均衡对 Web 服务器的连接,由 Web 服务器首先关闭连接,TIME_WAIT 出现在 Web 服务器上;Web 服务器对 DB 服务器的连接,由 Web 服务器关闭连接,TIME_WAIT 也出现在它身上,此时,负载均衡服务器上的配置:

  • net.ipv4.tcp_tw_reuse:0 或者 1 都行,都没有实际意义

  • net.ipv4.tcp_tw_recycle=0 // 一定是关闭 recycle

 

在 Web 服务器上的配置:

 

  • net.ipv4.tcp_tw_reuse = 1 // 这个配置主要影响的是 Web 服务器到 DB 服务器的连接复用

  • net.ipv4.tcp_tw_recycle=1 // 由于在负载均衡和 Web 服务器之间并没有 NAT 的网络,可以考虑开启 recycle,加速由于负载均衡和 Web 服务器之间的连接造成的大量 TIME_WAIT

 

 

回答几个大家提到的几个问题

 

1. 请问我们所说连接池可以复用连接,是不是意味着,需要等到上个连接 time wait 结束后才能再次使用?

所谓连接池复用,复用的一定是活跃的连接,所谓活跃,第一表明连接池里的连接都是 ESTABLISHED 的,第二,连接池做为上层应用,会有定时的心跳去保持连接的活跃性。既然连接都是活跃的,那就不存在有 TIME_WAIT 的概念了,在上篇里也有提到,TIME_WAIT 是在主动关闭连接的一方,在关闭连接后才进入的状态。既然已经关闭了,那么这条连接肯定已经不在连接池里面了,即被连接池释放了。

 

2. 想请问下,作为负载均衡的机器随机端口使用完的情况下大量 time_wait,不调整你文字里说的那三个参数,有其他的更好的方案吗?

第一,随机端口使用完,你可以通过调整 /etc/sysctl.conf 下的 net.ipv4.ip_local_port_range 配置,至少修改成 net.ipv4.ip_local_port_range=1024 65535,保证你的负载均衡服务器至少可以使用 6 万个随机端口,也即可以有 6 万的反向代理到后端的连接,可以支持每秒 1000 的并发(想一想,因为 TIME_WAIT 状态会持续 1 分钟后消失,所以一分钟最多有 6 万,每秒 1000);如果这么多端口都使用完了,也证明你应该加服务器了,或者,你的负载均衡服务器需要配置多个 IP 地址,或者,你的后端服务器需要监听更多的端口和配置更多的 IP(想一下 socket 的五元组)

第二,大量的 TIME_WAIT,多大量?如果是几千个,其实不用担心,因为这个内存和 CPU 的消耗有一些,但是是可以忽略的。

第三,如果真的量很大,上万上万的那种,可以考虑,让后端的服务器主动关闭连接,如果后端服务器没有外网的连接只有负载均衡服务器的连接(主要是没有 NAT 网络的连接),可以在后端服务器上配置 tw_recycle,然后同时,在负载均衡服务器上,配置 tw_reuse。

 

3. 如果想深入的学习一下网络方面的知识,有什么推荐的?

学习网络比学一门编程语言 “难” 很多。所谓难,其实,是因为需要花很多的时间投入。我自己不算精通,只能说入门和理解。基本书可以推荐:《TCP/IP 协议详解》,必读;《TCP/IP 高效编程:改善网络程序的 44 个技巧》,必读;《Unix 环境高级编程》,必读;《Unix 网络编程:卷一》,我只读过卷一;另外,还需要熟悉一下网络工具,tcpdump 以及 wireshark,我的 notes 里有一个一站式学习 Wireshark:https://github.com/dafang/notebook/issues/114,也值得一读。有了这些积累,可能就是一些实践以及碎片化的学习和积累了。

 

写在最后

 

这篇文章我断断续续写了两天,内容找了多个地方去验证,包括看到 Vincent Bernat 的一篇文章以及 Vincent 在多个地方和别人的讨论。期间,我也花了一些时间和 Vincent 探讨了几个我没在 tcp 源码里翻找到的有疑问的地方。

 

我力求比散布在网上的文章做到准确并尽量整理的清晰一些。但是,也难免会

有疏漏或者有错误的地方,高手看到可以随时指正,并和我讨论,大家一起研究!

与[转帖]高性能网络 | 你所不知道的 TIME_WAIT 和 CLOSE_WAIT相似的内容:

[转帖]高性能网络 | 你所不知道的 TIME_WAIT 和 CLOSE_WAIT

高性能网络 | 你所不知道的 TIME_WAIT 和 CLOSE_WAIThttps://my.oschina.net/fdhay/blog/638631 本文是我将最近两篇文章,重新整理成一篇,方便收藏。如果你已经阅读过前两篇,并且已经做了收藏,可以重新收藏本文即可。 你有收藏和整理文章的习惯吗?

[转帖]高性能网络 | 你所不知道的TIME_WAIT和CLOSE_WAIT

https://zhuanlan.zhihu.com/p/528747315 你遇到过TIME_WAIT的问题吗? 我相信很多都遇到过这个问题。一旦有用户在喊:网络变慢了。第一件事情就是,netstat -a | grep TIME_WAIT | wc -l 一下。哎呀妈呀,几千个TIME_WAIT

[转帖]eBPF 技术实践:加速容器网络转发,耗时降低60%+

https://new.qq.com/rain/a/20221103A03ZHE00 作者 | 王栋栋 背 景 Linux 具有功能丰富的网络协议栈,并且兼顾了非常优秀的性能。但是,这是相对的。单纯从网络协议栈各个子系统的角度来说,确实做到了功能与性能的平衡。不过,当把多个子系统组合起来,去满足实际

[转帖]QPS 最高提升 91% | 腾讯云 TKE 基于 Cilium eBPF 提升 k8s Service 性能

https://my.oschina.net/cncf/blog/5121393 朱瑜坚,腾讯云后台工程师,主要负责腾讯云 TKE 容器网络的构建和相关网络组件的设计、开发和维护工作。张浩,腾讯云高级工程师,主要负责容器网络多个组件的开发和维护,也关注调度、服务网格等领域。 前言 Kubernete

【转帖】【ethtool】ethtool 网卡诊断、调整工具、网卡性能优化| 解决丢包严重

目录 即看即用 详细信息 软件简介 安装 ethtool的使用 输出详解 其他指令 将 ethtool 设置永久保存 如何使用 ethtool 优化 Linux 虚拟机网卡性能 ethtool 解决网卡丢包严重和网卡原理 即看即用 查看: ethtool ethx 查看eth0网卡的基本设置 内容包

[转帖]高性能网络实战:借助 eBPF 来优化负载均衡的性能

https://zhuanlan.zhihu.com/p/592981662 网络性能优化,eBPF 是如何发挥作用的呢? 本篇文章,我就以最常用的负载均衡器为例,带你一起来看看如何借助 eBPF 来优化网络的性能。 1 Nginx 负载均衡器 既然要优化负载均衡器的网络性能,那么首先就需要有一个优

[转帖]高性能IO模型:为什么单线程Redis能那么快?

https://zhuanlan.zhihu.com/p/596170085 你好,我是蒋德钧。 今天,我们来探讨一个很多人都很关心的问题:“为什么单线程的Redis能那么快?” 首先,我要和你厘清一个事实,我们通常说,Redis是单线程,主要是指Redis的网络IO和键值对读写是由一个线程来完成的

[转帖]【dperf系列-5】使用dperf进行性能测试(初级)

https://zhuanlan.zhihu.com/p/451341132 dperf是一款高性能的开源网络压力测试仪,是Linux基金会旗下的DPDK官方生态项目。本文介绍如利用dperf在两台物理服务器之间互打http流量进行基本性能测试:每秒新建连接数、并发连接数、带宽、PPS。本次测试示例

【转帖】io_uring vs epoll ,谁在网络编程领域更胜一筹?

简介:从定量分析的角度,通过量化 io_uring 和 epoll 两种编程框架下的相关操作的耗时,来分析二者的性能差异。 本文作者:王小光,「高性能存储技术SIG」核心成员。 背景 io_uring 在传统存储 io 场景已经证明其价值,但 io_uring 不仅支持传统存储 io,也支持网络 i

【转帖】io_uring vs epoll ,谁在网络编程领域更胜一筹?

io_uring vs epoll ,谁在网络编程领域更胜一筹? 2021-12-16 1473举报 简介: 从定量分析的角度,通过量化 io_uring 和 epoll 两种编程框架下的相关操作的耗时,来分析二者的性能差异。 3.jpg 本文作者:王小光,「高性能存储技术SIG」核心成员。 背景