本文分析了一起TCP连接故障，客户端发送SYN包后未收到响应，但未进行重传。探讨了Linux系统中TCP SYN包的重传次数设置，包括sysctl配置和socket选项，并解释了可能影响重传的内核bug及RFC规定。通过分析，发现是应用程序的超时设置（2秒）早于操作系统的TCP_TIMEOUT_INIT（3秒），导致在2秒后关闭连接，未触发SYN包重传。
近日，在分析某项业务故障时，抓取到，TCP客户端发送SYN包，对端没有收到，然而客户端也没有进行SYN包重传的现象。具体情况如下图：
可以看到，经过过滤，本次抓包抓取到的tcp连接情况，只有客户端主动发起了TCP连接，发送了建立连接的syn包，之后再无关于该tcp连接的任何数据包传递发生。由此可以推测，该syn包没有被服务器端收到，或者服务器端收到syn包后没有响应。于是，根据tcp源端口，在服务器侧抓取到的数据包中进行过滤。
可见，服务器侧没有收到该SYN包。所以服务器侧，关于该TCP连接没有任何响应是正常的。
然而，我们知道tcp连接，在客户端发送了SYN包后，若没有收到服务器端返回的SYN-ACK，客户端会进行SYN包的重传，然而通过TCP客户端侧的抓包看，在发送了一次SYN包后，没有收到响应后，却没有进行SYN包的重传，导致该TCP连接，在只尝试了一次后，就没有再尝试建立连接。
经过进一步分析TCP-SYN包重传的机制，客户端发送syn包，在没有收到SYN-ACK的情况下，等待RTO时间超时，之后会重新发送SYN包，再有等待了2个RTO时间没有收到响应后，会再一次进行SYN报的重传，
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
