17网站一起做网店档口出租,购物平台官网,wordpress链接关系,网站权重提升一、绪论 最近碰到这么一个情况#xff0c;接口请求超时。前提是两台服务器间的网络是畅通的#xff0c;端口也是通#xff0c;应用代码也是通。意思是在应用上#xff0c;接口没有任何报错#xff0c;能正常返回数据。客户端到服务端接口也能通#xff0c;但是接收不到服…一、绪论 最近碰到这么一个情况接口请求超时。前提是两台服务器间的网络是畅通的端口也是通应用代码也是通。意思是在应用上接口没有任何报错能正常返回数据。客户端到服务端接口也能通但是接收不到服务的数据。比较诡异的如果报文比较短客户端是可以收到返回数据。
现象
本地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.41232810.22.33.22的40778端口向10.200.33.229的dnp-sec端口发送SYN包请求建立连接。SYN包中包含了序列号seq3884995505窗口大小win29200以及其他TCP选项如MSS、SACK支持、时间戳等。
SYN-ACK包16:06:28.42034010.200.33.229的dnp-sec端口回应SYN-ACK包确认收到SYN包并发送自己的序列号seq325552826同时确认对方的序列号ack为3884995506即SYN包的序列号1。SYN-ACK包中也包含了窗口大小、TCP选项等信息。
ACK包16:06:28.42035910.22.33.22的40778端口发送ACK包确认收到SYN-ACK包完成三次握手连接建立。
数据传输
PSH包16:06:28.42040010.22.33.22的40778端口发送PSH包尽管这里也使用了PUSH标志但通常数据包的类型是通过长度和内容来判断的而不是仅仅依赖标志位携带了389字节的数据。
ACK包16:06:28.42845010.200.33.229的dnp-sec端口发送ACK包确认收到数据。
PSH包16:06:28.45322110.200.33.229的dnp-sec端口也发送了数据11字节尽管这里也使用了PUSH标志但实际上是普通的数据包。
ACK包16:06:28.45322910.22.33.22的40778端口发送ACK包确认收到数据并使用SACK选项确认接收到的数据段尽管这里SACK的范围与确认的序列号不匹配可能是个错误或特殊情况。
连接保持
在数据传输之后双方继续发送ACK包以保持连接活跃但没有新的数据传输。这些ACK包中包含了SACK选项表明接收方已经确认接收到的数据段。
连接关闭
FIN包16:07:43.45293810.200.33.229的dnp-sec端口发送FIN包表示它已完成数据传输准备关闭连接。
ACK包16:07:43.45295910.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.41232810.22.33.22的40778端口向10.200.33.229的dnp-sec端口发送SYN包请求建立连接。SYN包中包含了序列号seq3884995505窗口大小win29200以及其他TCP选项如MSS、SACK支持、时间戳等。 SYN-ACK包16:06:28.42034010.200.33.229的dnp-sec端口回应SYN-ACK包确认收到SYN包并发送自己的序列号seq325552826同时确认对方的序列号ack为3884995506即SYN包的序列号1。SYN-ACK包中也包含了窗口大小、TCP选项等信息。 ACK包16:06:28.42035910.22.33.22的40778端口发送ACK包确认收到SYN-ACK包完成三次握手连接建立。 数据传输 PSH包16:06:28.42040010.22.33.22的40778端口发送PSH包尽管这里也使用了PUSH标志但通常数据包的类型是通过长度和内容来判断的而不是仅仅依赖标志位携带了389字节的数据。 ACK包16:06:28.42845010.200.33.229的dnp-sec端口发送ACK包确认收到数据。 PSH包16:06:28.45322110.200.33.229的dnp-sec端口也发送了数据11字节尽管这里也使用了PUSH标志但实际上是普通的数据包。 ACK包16:06:28.45322910.22.33.22的40778端口发送ACK包确认收到数据并使用SACK选项确认接收到的数据段尽管这里SACK的范围与确认的序列号不匹配可能是个错误或特殊情况。 连接保持 在数据传输之后双方继续发送ACK包以保持连接活跃但没有新的数据传输。这些ACK包中包含了SACK选项表明接收方已经确认接收到的数据段。 连接关闭 FIN包16:07:43.45293810.200.33.229的dnp-sec端口发送FIN包表示它已完成数据传输准备关闭连接。 ACK包16:07:43.45295910.22.33.22的40778端口发送ACK包确认收到FIN包但此时它可能还在等待应用层完成某些操作因此没有立即发送自己的FIN包。 连接异常终止 在一段时间后1分钟后10.200.33.229的dnp-sec端口发送RST包16:08:43.475557异常终止连接。这可能是因为它认为连接已经超时或不再需要或者是因为它接收到了无法识别的序列号等。RST包的发送通常会导致TCP连接立即关闭且不会进行正常的四次挥手过程。 总结这个过程展示了TCP连接的建立、数据传输、保持和异常终止。尽管在大多数情况下TCP连接会通过正常的四次挥手过程来关闭但在这个例子中连接被RST包异常终止了。 既然是终止了网上百度一大堆说什么的都有但是最终没有解决问题 比较诡异的 同一个服务器 去请求同一个接口数据报文短的能返回了 这就很诡异了所以我猜测长报文无法返回需要网络排查哪里限制了第三次握手服务端终止了客户端发送报文并终端了链接
