tcpdump 捕获的数据包是否可能在 tcp 内核中丢失？答案

【问题标题】：Is it possible that packet captured by tcpdump, but lost in tcp kernel?tcpdump 捕获的数据包是否可能在 tcp 内核中丢失？
【发布时间】：2014-04-11 09:34:26
【问题描述】：

  1 10:59:11.303358 IP CCC > SSS: S 2325818282:2325818282(0) win 14600 <mss 1460,sackOK,timestamp 2358537033 0,nop,wscale 7>
  2 10:59:11.304131 IP SSS > CCC: S 3397574260:3397574260(0) ack 2325818283 win 14440 <mss 1456,sackOK,timestamp 994572340 2358537033,nop,wscale 9>
  3 10:59:11.305182 IP CCC > SSS: . ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
  4 10:59:11.305280 IP CCC > SSS: . 1:1445(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
  5 10:59:11.305288 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572342 2358537035>
  6 10:59:11.305370 IP CCC > SSS: . 1445:2889(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
  7 10:59:11.305418 IP CCC > SSS: . 2889:4333(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
  8 10:59:11.305422 IP CCC > SSS: . 4333:5777(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
  9 10:59:11.305434 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:5777}>
 10 10:59:11.305426 IP CCC > SSS: . 5777:7221(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
 11 10:59:11.305439 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:7221}>
 12 10:59:11.305611 IP CCC > SSS: P 7221:8665(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
 13 10:59:11.305632 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:8665}>
 14 10:59:11.305617 IP CCC > SSS: . 8665:10109(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
 15 10:59:11.305638 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:10109}>
 16 10:59:11.305621 IP CCC > SSS: . 10109:11553(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
 17 10:59:11.305643 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:11553}>
 18 10:59:11.305624 IP CCC > SSS: . 11553:12997(1444) ack 1 win 115 <nop,nop,timestamp 2358537035 994572340>
 19 10:59:11.305648 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572343 2358537035,nop,nop,sack 1 {4333:12997}>
 20 10:59:11.306649 IP CCC > SSS: . 12997:14441(1444) ack 1 win 115 <nop,nop,timestamp 2358537036 994572342>
 21 10:59:11.306652 IP CCC > SSS: . 14441:15885(1444) ack 1 win 115 <nop,nop,timestamp 2358537036 994572342>
 22 10:59:11.306655 IP CCC > SSS: . 15885:17329(1444) ack 1 win 115 <nop,nop,timestamp 2358537036 994572342>
 23 10:59:11.306722 IP CCC > SSS: P 17329:18773(1444) ack 1 win 115 <nop,nop,timestamp 2358537036 994572343>
 24 10:59:11.306735 IP SSS > CCC: . ack 1445 win 34 <nop,nop,timestamp 994572344 2358537035,nop,nop,sack 2 {17329:18773}{4333:12997}>
 25 10:59:11.306725 IP CCC > SSS: . 1445:2889(1444) ack 1 win 115 <nop,nop,timestamp 2358537036 994572343>
 26 10:59:11.306743 IP SSS > CCC: . ack 2889 win 40 <nop,nop,timestamp 994572344 2358537036,nop,nop,sack 2 {17329:18773}{4333:12997}>
 27 10:59:11.306731 IP CCC > SSS: . 2889:4333(1444) ack 1 win 115 <nop,nop,timestamp 2358537037 994572343>
 28 10:59:11.306808 IP SSS > CCC: . ack 12997 win 46 <nop,nop,timestamp 994572344 2358537037,nop,nop,sack 1 {17329:18773}>
 29 10:59:11.307932 IP CCC > SSS: . 12997:14441(1444) ack 1 win 115 <nop,nop,timestamp 2358537038 994572344>
 30 10:59:11.307942 IP SSS > CCC: . ack 14441 win 51 <nop,nop,timestamp 994572345 2358537038,nop,nop,sack 1 {17329:18773}>
 31 10:59:11.308121 IP CCC > SSS: . 18773:20217(1444) ack 1 win 115 <nop,nop,timestamp 2358537038 994572344>
 32 10:59:11.308127 IP CCC > SSS: . 20217:21661(1444) ack 1 win 115 <nop,nop,timestamp 2358537038 994572344>

从第6、7、8行tcpdump抓到数据1445~5777，但它仍然在第 9 行与 1445 确认。我建议内核没有及时收到该数据。但是就在第 25 行之后，它 ack 2889，这使得第 6 行中的数据包似乎丢失了。那么，第 6 行的数据包去哪了呢？

我在传输前后比较了从“netstat -s”生成的两个文件。结果表明收到了坏段。这是我问题的关键吗？

<     4637068 segments received
<     3972086 segments send out
<     118982 segments retransmited
<     40245 bad segments received.
---
>     4637506 segments received
>     3972383 segments send out
>     118989 segments retransmited
>     40402 bad segments received.
29,30c29,30

【问题讨论】：

为什么投反对票？当我遇到这件事时，我正要问同样的问题。它可能与您无关，但与某些人有关。

标签： linux tcp kernel tcpdump

【解决方案1】：

如果tcpdump 直接从网络中提取数据，那么它可以捕获内核可能丢失的数据报。内核和tcpdump 都将有不同的数据缓冲区来读取它们，如果内核的缓冲区已满，我会假设它可能会丢弃数据包。

如果tcpdump 正在与实际接收数据的机器不同的机器上运行，则更有可能发生这种情况。

【讨论】：

这确实是正常的行为，所以它甚至是“意志”，而不是“可能”。丢包是拥塞控制算法的一部分。
我希望如此，但由于我不熟悉 linux 内核的内部结构，所以我决定有点模糊。感谢您的澄清。
@Damon 收到的丢包是什么原因，这似乎对拥塞控制没有好处。
@hello.co：TCP 必须做某事，因为并非所有主机（也不是相同主机之间的所有路由）都具有相同的带宽和缓冲区大小。除了丢弃数据包，TCP 还有什么其他方法？没有办法知道您可以发送多少个数据包（或多大的数据包）。除非您设置了不分段位并收到 ICMP 错误（对于“多大”），或者如果数据包在没有被确认的情况下消失（对于“多少”）。