实战！一次网络问题排查( 五 ) _网络问题

2 keepalive_timeout 60s; #连接保持的超时时间
3
4 upstream servers {
5 keepalive 10;
6 }
7
8 server {
9 listener 20004 so_keepalive=on #这个是支持长连接的配置
10 }
11}

代码问题修复客户端连接方式从长连接改成短连接，设置连接不复用就可以了，如下：image-20200525203700284

番外从现象上看因为长连接的连接复用，导致了 Broken Pipe 异常，但是从实际业务角度，业务测试成功率没有明显变化。因为连接池设置了异常重试策略，如果发生Broken Pipe 异常，会再从连接池获取连接重试，重试的成功率非常高，因为大多数时候是新建的连接来重试。这点从wireshark 网络包中可以看出。因为每一笔业务都有流水号，因为可以使用Wireshark 过滤器过滤网络包的数据内容，如下所示：过滤器输入业务日志中的请求的流水号，过滤器过滤包的命令如下：1tcp.segment_data contains "TCP包中业务流水号"image-20200525205104904如上图所示，可以看到有二笔TCP 数据包中数据包含有这个业务流水号，这个就是因为第一次TCP 失败后重试造成的，可以看到一笔是从4528端口发出，一笔是4542端口发出的，我们可以把这二笔单独拉出来看一下，使用过滤器的命令如下，4542端口失败后新建一个连接（端口为4528）发送数据：1tcp.port == 4542 or tcp.port == 4528过滤后的数据包如下图所示：wireshark过滤数据包

6. 扩展阅读：其他网络知识及面试题6.1 为什么需要三次握手来建立TCP 连接？答：第一次握手客户端发送报文给服务端，收到服务端的应答表明客户端发送数据的能力ok；第二次握手服务端发送数据给客户端表示服务端接收数据能力ok（我正常收到你的数据了，告诉你一声）；第三次客户端发报文给服务端表明服务端的发送数据的能力也ok，客户端接收数据能力也ok（我能正常收到你的数据，代表你发的数据没问题，我的接收能力也没问题，所以告知你一声）。所以要验证客户端和服务端发送&接收数据的能力都ok至少需要三次握手才能达到。举个实际的例子，比如你投递简历，相当于第一次握手，HR回复你简历已收到，相当于第二次握手，你回复HR已收到批准通知了，这相当于三次握手，HR可以给你安排面试了。因为每一次握手都有消息丢失的风险，所以需要往返至少三次才能保证连接的建立。
6.2 TIME_WAIT 和 CLOSE_WAIT 有什么区别？答：这二个状态是四次挥手中的状态，TIME_WAIT 是主动关闭的一方发出 FIN 包会经过的状态，CLOSE_WAIT 是被动关闭连接的一端会经过的状态。TIME_WAIT 经过2个MSL(最大报文段生存时间)才能到CLOSE状态，CLOSE_WAIT 如果不发送FIN 报文会一直处在CLOSE_WAIT 状态。所以一般在看机器连接状态，几千个TIME_WAIT 一般是正常的（过2MSL自动关闭），处于CLOSE_WAIT 状态的连接很多，证明有问题。
6.3 处于CLOSE_WAIT 状态的连接很多，怎么办？答：处于CLOSE_WAIT 状态的连接很多，证明有问题，有几种可能：

代码问题：短连接模式，忘记 close 连接，就不会发出 FIN 包，导致连接处于 CLOSE_WAIT状态；或者程序在close 连接之前陷入死循环或者执行时间过长；
backlog太大：backlog太大这里指的accept 的连接队列设置的太大，这个参数是在服务端创建ServerSocket作为参数传入的，默认为50，支持自定义，设置的太少容易出现连接reset或者拒绝，太大如果服务端处理连接不及时会放到accept队列等待太长时间。accept队列以及socket 连接建立流程如下图：image-20200527234141069

上图所示，这里有两个队列：syns queue(半连接队列）；accept queue（全连接队列）。我们很多时候排查网络问题时也需要考虑到accept queue，很多场景需要对accept queue 大小做些调整。
6.4 如何判断是否需要调整 accept queue（全连接队列）大小？答：例如我们机器并发量很高，accept queue（全连接队列）可能会出现不够用的情况，会出现类似connection reset 和 connection timeout 异常，这个取决于机器上tcp_abort_on_overflow 的设置，不同值服务端不同处理机制：
tcp_abort_on_overflow为0：连接建立过程中三次握手第三步时，发生全连接队列满了，server扔掉client 发过来的ack，那么client 会重新发送ack，直到超时，所以客户端会出现连接超时（connection timeout ）；
tcp_abort_on_overflow为1：遇到全连接队列满了，server会发一个reset包给client，表示废掉这个这个连接，这个握手过程无效，客户端会看到很多connection reset by peer的错误；
查看服务器处理accept queue 队列满时的处理机制：