【开端】记一次诡异的接口排查过程

一、绪论

     最近碰到这么一个情况，接口请求超时。前提是两台服务器间的网络是畅通的，端口也是通，应用代码也是通。意思是在应用上，接口没有任何报错，能正常返回数据。客户端到服务端接口也能通，但是接收不到服务的数据。比较诡异的，如果报文比较短，客户端是可以收到返回数据。

现象：

本地windows系统网络去请求接口可以通

linux服务器网络去请求接口

前提是telnet是可以通

于是就开始抓包分析

linux 抓包命令：  sudo tcpdump -i eth0 port 19999

这个过程展示了两个IP地址（10.22.33.22 和 10.200.33.229）之间通过TCP协议在端口dnp-sec（非标准端口，可能是某个特定应用的自定义端口）上建立连接、交换数据、然后关闭连接的过程。不过，最后出现了RST（重置）包，这通常表示连接被异常终止。下面是对这个过程的详细解释：

连接建立（三次握手）：
SYN包（16:06:28.412328）：10.22.33.22的40778端口向10.200.33.229的dnp-sec端口发送SYN包，请求建立连接。SYN包中包含了序列号（seq）3884995505，窗口大小（win）29200，以及其他TCP选项（如MSS、SACK支持、时间戳等）。
SYN-ACK包（16:06:28.420340）：10.200.33.229的dnp-sec端口回应SYN-ACK包，确认收到SYN包，并发送自己的序列号（seq）325552826，同时确认对方的序列号（ack）为3884995506（即SYN包的序列号+1）。SYN-ACK包中也包含了窗口大小、TCP选项等信息。
ACK包（16:06:28.420359）：10.22.33.22的40778端口发送ACK包，确认收到SYN-ACK包，完成三次握手，连接建立。
数据传输：
PSH包（16:06:28.420400）：10.22.33.22的40778端口发送PSH包（尽管这里也使用了PUSH标志，但通常数据包的类型是通过长度和内容来判断的，而不是仅仅依赖标志位），携带了389字节的数据。
ACK包（16:06:28.428450）：10.200.33.229的dnp-sec端口发送ACK包，确认收到数据。
PSH包（16:06:28.453221）：10.200.33.229的dnp-sec端口也发送了数据（11字节），尽管这里也使用了PUSH标志，但实际上是普通的数据包。
ACK包（16:06:28.453229）：10.22.33.22的40778端口发送ACK包，确认收到数据，并使用SACK选项确认接收到的数据段（尽管这里SACK的范围与确认的序列号不匹配，可能是个错误或特殊情况）。
连接保持：
在数据传输之后，双方继续发送ACK包以保持连接活跃，但没有新的数据传输。这些ACK包中包含了SACK选项，表明接收方已经确认接收到的数据段。
连接关闭：
FIN包（16:07:43.452938）：10.200.33.229的dnp-sec端口发送FIN包，表示它已完成数据传输，准备关闭连接。
ACK包（16:07:43.452959）：10.22.33.22的40778端口发送ACK包，确认收到FIN包，但此时它可能还在等待应用层完成某些操作，因此没有立即发送自己的FIN包。
连接异常终止：
在一段时间后（1分钟后），10.200.33.229的dnp-sec端口发送RST包（16:08:43.475557），异常终止连接。这可能是因为它认为连接已经超时或不再需要，或者是因为它接收到了无法识别的序列号等。RST包的发送通常会导致TCP连接立即关闭，且不会进行正常的四次挥手过程。
总结：这个过程展示了TCP连接的建立、数据传输、保持和异常终止。尽管在大多数情况下，TCP连接会通过正常的四次挥手过程来关闭，但在这个例子中，连接被RST包异常终止了。

发现tcp 第三次握手发送消息失败

这个过程展示了两个IP地址（10.22.33.22 和 10.200.33.229）之间通过TCP协议在端口dnp-sec（非标准端口，可能是某个特定应用的自定义端口）上建立连接、交换数据、然后关闭连接的过程。不过，最后出现了RST（重置）包，这通常表示连接被异常终止。下面是对这个过程的详细解释：

连接建立（三次握手）：
SYN包（16:06:28.412328）：10.22.33.22的40778端口向10.200.33.229的dnp-sec端口发送SYN包，请求建立连接。SYN包中包含了序列号（seq）3884995505，窗口大小（win）29200，以及其他TCP选项（如MSS、SACK支持、时间戳等）。
SYN-ACK包（16:06:28.420340）：10.200.33.229的dnp-sec端口回应SYN-ACK包，确认收到SYN包，并发送自己的序列号（seq）325552826，同时确认对方的序列号（ack）为3884995506（即SYN包的序列号+1）。SYN-ACK包中也包含了窗口大小、TCP选项等信息。
ACK包（16:06:28.420359）：10.22.33.22的40778端口发送ACK包，确认收到SYN-ACK包，完成三次握手，连接建立。
数据传输：
PSH包（16:06:28.420400）：10.22.33.22的40778端口发送PSH包（尽管这里也使用了PUSH标志，但通常数据包的类型是通过长度和内容来判断的，而不是仅仅依赖标志位），携带了389字节的数据。
ACK包（16:06:28.428450）：10.200.33.229的dnp-sec端口发送ACK包，确认收到数据。
PSH包（16:06:28.453221）：10.200.33.229的dnp-sec端口也发送了数据（11字节），尽管这里也使用了PUSH标志，但实际上是普通的数据包。
ACK包（16:06:28.453229）：10.22.33.22的40778端口发送ACK包，确认收到数据，并使用SACK选项确认接收到的数据段（尽管这里SACK的范围与确认的序列号不匹配，可能是个错误或特殊情况）。
连接保持：
在数据传输之后，双方继续发送ACK包以保持连接活跃，但没有新的数据传输。这些ACK包中包含了SACK选项，表明接收方已经确认接收到的数据段。
连接关闭：
FIN包（16:07:43.452938）：10.200.33.229的dnp-sec端口发送FIN包，表示它已完成数据传输，准备关闭连接。
ACK包（16:07:43.452959）：10.22.33.22的40778端口发送ACK包，确认收到FIN包，但此时它可能还在等待应用层完成某些操作，因此没有立即发送自己的FIN包。
连接异常终止：
在一段时间后（1分钟后），10.200.33.229的dnp-sec端口发送RST包（16:08:43.475557），异常终止连接。这可能是因为它认为连接已经超时或不再需要，或者是因为它接收到了无法识别的序列号等。RST包的发送通常会导致TCP连接立即关闭，且不会进行正常的四次挥手过程。
总结：这个过程展示了TCP连接的建立、数据传输、保持和异常终止。尽管在大多数情况下，TCP连接会通过正常的四次挥手过程来关闭，但在这个例子中，连接被RST包异常终止了。

既然是终止了，网上百度一大堆：说什么的都有，但是最终没有解决问题

 比较诡异的 同一个服务器 去请求同一个接口，数据报文短的能返回了

这就很诡异了，所以我猜测，长报文无法返回，需要网络排查哪里限制了第三次握手，服务端终止了客户端发送报文，并终端了链接