一、绪论
最近碰到这么一个情况,接口请求超时。前提是两台服务器间的网络是畅通的,端口也是通,应用代码也是通。意思是在应用上,接口没有任何报错,能正常返回数据。客户端到服务端接口也能通,但是接收不到服务的数据。比较诡异的,如果报文比较短,客户端是可以收到返回数据。
现象:
本地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包异常终止了。
既然是终止了,网上百度一大堆:说什么的都有,但是最终没有解决问题
比较诡异的 同一个服务器 去请求同一个接口,数据报文短的能返回了
这就很诡异了,所以我猜测,长报文无法返回,需要网络排查哪里限制了第三次握手,服务端终止了客户端发送报文,并终端了链接