Linux Kernel
英文原文：
Diagnosing networking issues in the Linux Kernel
几周前，我们Start留意位于华盛顿的追踪API的Server收集流量有很大的变更。从一个相当波动的平常形式下，我们Start看到300-400 Mbps尖峰流量，但我们的正当的流量（事情和报酬更新）是稳定的。
忽然，我们的收集流量Start飙升像疯了似的。
找到虚伪的流量起源是燃眉之急，由于这些尖峰流量正触发我们的上游路由器启动DDOS减灾形式来禁止流量。
其它翻译版本 (1)
加载中
有一些很好的内置的LinuxTools协助诊断收集问题。
ifconfig 会显示你的收集接口和几多数据包经过他们
ethtool -S 会显示你的数据包流的一些更具体的信息，象在NIC级抛弃的数据包的数目。
iptables -L -v -n 将显示你的各类防火墙规矩处置数据包数。
netstat -s 会通知由内核收集协议栈保护的一大堆的计数器值，例如ACK的数目，重发的数目等。
sysctl -a | grep net.ip 将显示你一切kernel中收集相干的设置。
tcpdump 将显示收支包的内容。
处理问题的线索是运用netstat -s号令的输出。 不幸的是，当你反省这个号令的输出的时分，还很难通知这些数字意味着甚么，应当是甚么，和它们是怎么改动的。为了反省他们是怎么变更的，我们创立了一个小顺序来显示延续运转号令的输出，这让我们了解各类计数器变更的快慢。一个输出线看起来特殊使人担心。
此计数器的凡是速度在未受影响的Server上通常为 30-40 /秒，所以我们晓得一定是那里出问题了。计数器标明我们正回绝大量的包，由于这些包括有没有效的 TCP 工夫戳。暂时的疾速处理计划是用下面的号令封闭 TCP 工夫戳：
sysctl -w net.ipv4.tcp_timestamps=0
这立刻招致了包风暴中止。可是这不是一个永世性的处理计划，由于 TCP 工夫戳是用于丈量往复工夫和分派数据包流中的延迟包到准确地位。在高速衔接的时分这将成为一个问题，TCP 序列号可能在数秒距离内环绕纠缠。关于 TCP 的工夫戳和功能的具体信息，请看 RFC 1323。
在 Mixpanel，每当我们看到异常流量形式的时分，我们普通也运转 tcpdump，如许我们可以剖析流量，然后试图断定基本缘由。我们发明大量的 TCP ACK 数据包在我们的 API Server和一个特定的 IP 地址之间往返发送。后果我们的Server堕入到向另外一台Server来往返回发送 TCP ACK 包的无限轮回外面。一个主机不断地收回 TCP 工夫戳，可是另外一主机却不克不及辨认这是有效的工夫戳。
这时候，我们意想到我们正在处置一个只能在 Linux 内核的 TCP 协议栈才干处理问题。所以我们的 CTO乞助于 linux-netdev 看看能否能找到一个处理计划。值得光荣的是我们发明这个问题曾经碰到过的，而且有一个处理计划。本来，这类类型的包风暴可以由一些硬件毛病或第三方改动 TCP SEQ，ACK，或衔接中的主机以为对方发送过时的数据包所触发。防止让这类状况酿成一个包风暴的办法是限制速度，设置 Linux 发送反复的 ACK 数据包速度为每秒一个或两个。这里有一个十分好的说明。
我们将承受这个补钉并且将之移植到以后正在运用的Ubuntu（Trusty）内核傍边。感激Ubuntu让这一切变得十分容易，从头编译修补过的内核仅仅只需求运转下面的号令，装置生成的.deb包偏重启系统。
# Get the kernel source and build dependencies
apt-get build-dep linux-image-3.13.0-45-generic
apt-get source linux-image-3.13.0-45-generic
# Apply the patch file.
cd linux-lts-trusty-3.13.0/
patch -p1 < Mitigate-TCP-ACK-Loops.patch
# Build the kernel
fakeroot ./debian/rules clean
fakeroot ./debian/rules binary-headers binary-generic
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
