gaojl0728 发表于 2015-01-09 13:30

回复 9# lims_xlh


    我刚注意到一个问题，截图的第二个包， 并不是SYN/ACK,而只是一个普通ACK, 这个ACK很可能是在ACK前面的一个数据包， 所以他带的ACK号跟第一个SYN报文的sequence不匹配。

如果这样，那客户端就不应该通过同一个四元组发送新的SYN报文啊，客户端的应用程序是不是强制绑定端口号？

lims_xlh 发表于 2015-01-09 13:52

应该不是，从服务端判断，出现这种包的端口很随机

lims_xlh 发表于 2015-01-09 13:52

应该不是，从服务端判断，出现这种包的端口很随机

gaojl0728 发表于 2015-01-09 14:15

根源应该处在客户端上， 他不应该在前一个四元组还没有关闭的情况下重新发起连接。
抓的包还有吗，传上来一起研究研究。

lims_xlh 发表于 2015-01-09 15:13

这个端口的只有这些

lims_xlh 发表于 2015-01-15 10:11

我感觉是内核参数配置的问题，有时间看看源码

Godbach 发表于 2015-01-15 10:40

本帖最后由 Godbach 于 2015-01-15 10:44 编辑

回复 1# lims_xlh

有一种可能，就是之前你的 client 曾经用过这个源端口向 server 发送过请求。因为某些原因异常断开了，网络中还残留着 server 发送的报文。现在收到了。

不过感觉概率比较小。

   

lims_xlh 发表于 2015-01-15 13:10

回复 17# Godbach

我之前也是这样认为的，但是发现应该不是这样。
我是用1000个并发不停的connect 到某个端口A，然后close，并用tcpdump抓所有的包，客户端这个端口B到A的所有的包都抓到了，就是上面的截图
之前没发现有发包

Godbach 发表于 2015-01-15 13:15

回复 18# lims_xlh

server 和 client 之间是什么链路，是LAN，还是 WAN 啊。



   

lims_xlh 发表于 2015-01-15 15:07

同一台机器上面的部署的
页: 1 [2] 3
查看完整版本: 奇怪的抓包，请教内核牛人