Linux tcp_timestamp

看到DK大寫 Juniper NAT 後跑 Plurk 很慢的問題, 想到某公司曾經發生的問題.

Linux tcp_timestamp 的機制是 RFC1323, 大致上是講在 TCP header 增加一個 option 欄位 timestamp 後,
可以得到更精確的 RTT (Round Trip Time). 達到更快的傳輸速度.

在 Linux 可以用這二個指令開關
[BASH]
# echo 0 > /proc/sys/net/ipv4/tcp_timestamp
# echo 1 > /proc/sys/net/ipv4/tcp_timestamp
[/BASH]

But, 人生最 G8 的就是這個 but .
大家 IPv4 都讀得非常熟悉, header 20Bytes, 有 Option 另外算, IPv6 就採固定 header… blah blah .
加上了這個 timestamp, 整個 tcp 的 header 就長大了

這是 tcp_timestamp=1 的 tcp 封包(非 syn)

可以看到 option = 12 bytes, header = 32 bytes.

這是 tcp_timestamp=0 的 tcp 封包(非 syn). 我選了一樣的 packet 截圖

可以看到沒有 option 封包, header = 20 bytes.

有一些網站會將這個 option disable 掉, 增加最大可同時處理的 user 數.
所以就不會看到這個問題了.

不過如果是在做硬體設計, 這就要非常小心了, 大家都知道 ASIC 很難處理這種各種不同變化的狀況, 除非要做一個小 uP 在 block 內,
所以如果系統做死了, 可能也會有很多問題.

猜想可能 Juniper 也是用硬體去設計這樣的東西, 但是 syn 沒有針對這樣的 packet 特別處理, 或是封包內還是有帶有 option 的封包, 所以就不會做 NAT 了.
或是 drop 在內, 或是丟給 software 去處理.

其他還有可能影響的有 Large Segment Offload, Large Receive Offload 和 TCP Offload Engine .
IP/TCP/UDP checksum 及 Hardware NAT, 和其他的 offload engine .

提外話, 最近 Google 提出來的 TCP Fast Open 也是這種對硬體很 G8 的設計, 等 Linux kernel 3.7.x 出來之後, 可以截圖說故事再來寫一篇好了

ASIC 和 Software 共舞沒有這麼簡單的 :-/