linux中TCP Fast Open測試例子

httping是一個類比ping輸出的http請求用戶端。從1.5開始支援發送fastopen請求，目前版本是2.3.4。

我在 fedora 20 (核心3.13版) 上編譯了 nginx 1.5.13，yum 安裝了 httping 2.3.3版。

開兩個終端，一個運行tcpdump，然後另一個運行httping如下：

httping -F -g http://www.google.com.hk/url -c 1
這時候看到前一個終端的輸出是這樣的：

[chenlin.rao@com21-100 tfo]$ sudo tcpdump -i p5p1 -vvnxXs 0 tcp port 80 tcpdump: listening on p5p1, link-type EN10MB (Ethernet), capture size 65535 bytes 20:40:15.034486 IP (tos 0x0, ttl 64, id 52862, offset 0, flags [DF], proto TCP (6), length 147) 10.2.5.100.40699 > 74.125.128.199.http: Flags [S], cksum 0xbb34 (correct), seq 3616187260:3616187335, win 29200, options [mss 1460,sackOK,TS val 31091970 ecr 0,nop,wscale 7,exp-tfo cookie 9a8e5a15f1deab96], length 75 0x0000: 4500 0093 ce7e 4000 4006 913c 0a02 0564 E….~@.@..<…d 0x0010: 4a7d 80c7 9efb 0050 d78a a37c 0000 0000 J}…..P…|…. 0x0020: d002 7210 bb34 0000 0204 05b4 0402 080a ..r..4………. 0x0030: 01da 6d02 0000 0000 0103 0307 fe0c f989 ..m…………. 0x0040: 9a8e 5a15 f1de ab96 4845 4144 202f 7572 ..Z…..HEAD./ur 0x0050: 6c20 4854 5450 2f31 2e30 0d0a 486f 7374 l.HTTP/1.0..Host 0x0060: 3a20 7777 772e 676f 6f67 6c65 2e63 6f6d :.www.google.com 0x0070: 2e68 6b0d 0a55 7365 722d 4167 656e 743a .hk..User-Agent: 0x0080: 2048 5454 5069 6e67 2076 322e 332e 330d .HTTPing.v2.3.3. 0x0090: 0a0d 0a … 20:40:15.295644 IP (tos 0x0, ttl 30, id 42640, offset 0, flags [none], proto TCP (6), length 52) 74.125.128.199.http > 10.2.5.100.40699: Flags [S.], cksum 0x71c1 (correct), seq 1878126810, ack 3616187261, win 42900, options [mss 1430,nop,nop,sackOK,nop,wscale 6], length 0 0x0000: 4500 0034 a690 0000 1e06 1b8a 4a7d 80c7 E..4……..J}.. 0x0010: 0a02 0564 0050 9efb 6ff1 f0da d78a a37d …d.P..o……} 0x0020: 8012 a794 71c1 0000 0204 0596 0101 0402 ….q……….. 0x0030: 0103 0306 …. 20:40:15.295694 IP (tos 0x0, ttl 64, id 52863, offset 0, flags [DF], proto TCP (6), length 115) 10.2.5.100.40699 > 74.125.128.199.http: Flags [P.], cksum 0x5bf7 (correct), seq 1:76, ack 1, win 229, length 75 0x0000: 4500 0073 ce7f 4000 4006 915b 0a02 0564 E..s..@.@..[…d 0x0010: 4a7d 80c7 9efb 0050 d78a a37d 6ff1 f0db J}…..P…}o… 0x0020: 5018 00e5 5bf7 0000 4845 4144 202f 7572 P…[…HEAD./ur 0x0030: 6c20 4854 5450 2f31 2e30 0d0a 486f 7374 l.HTTP/1.0..Host 0x0040: 3a20 7777 772e 676f 6f67 6c65 2e63 6f6d :.www.google.com 0x0050: 2e68 6b0d 0a55 7365 722d 4167 656e 743a .hk..User-Agent: 0x0060: 2048 5454 5069 6e67 2076 322e 332e 330d .HTTPing.v2.3.3. 0x0070: 0a0d 0a … 20:40:15.560807 IP (tos 0x0, ttl 30, id 42641, offset 0, flags [none], proto TCP (6), length 40) 74.125.128.199.http > 10.2.5.100.40699: Flags [.], cksum 0x5720 (correct), seq 1, ack 76, win 670, length 0 0x0000: 4500 0028 a691 0000 1e06 1b95 4a7d 80c7 E..(……..J}.. 0x0010: 0a02 0564 0050 9efb 6ff1 f0db d78a a3c8 …d.P..o……. 0x0020: 5010 029e 5720 0000 0000 0000 0000 P…W……… 20:40:15.568068 IP (tos 0x0, ttl 30, id 42642, offset 0, flags [none], proto TCP (6), length 269) 74.125.128.199.http > 10.2.5.100.40699: Flags [P.], cksum 0x85ae (correct), seq 1:230, ack 76, win 670, length 229 0x0000: 4500 010d a692 0000 1e06 1aaf 4a7d 80c7 E………..J}.. 0x0010: 0a02 0564 0050 9efb 6ff1 f0db d78a a3c8 …d.P..o……. 0x0020: 5018 029e 85ae 0000 4854 5450 2f31 2e30 P…….HTTP/1.0 0x0030: 2034 3034 204e 6f74 2046 6f75 6e64 0d0a .404.Not.Found.. 0x0040: 436f 6e74 656e 742d 5479 7065 3a20 7465 Content-Type:.te 0x0050: 7874 2f68 746d 6c3b 2063 6861 7273 6574 xt/html;.charset 0x0060: 3d55 5446 2d38 0d0a 4461 7465 3a20 5765 =UTF-8..Date:.We 0x0070: 642c 2031 3620 4170 7220 3230 3134 2031 d,.16.Apr.2014.1 0x0080: 323a 3430 3a31 3520 474d 540d 0a53 6572 2:40:15.GMT..Ser 0x0090: 7665 723a 2067 7773 0d0a 436f 6e74 656e ver:.gws..Conten 0x00a0: 742d 4c65 6e67 7468 3a20 3134 3238 0d0a t-Length:.1428.. 0x00b0: 582d 5853 532d 5072 6f74 6563 7469 6f6e X-XSS-Protection 0x00c0: 3a20 313b 206d 6f64 653d 626c 6f63 6b0d :.1;.mode=block. 0x00d0: 0a58 2d46 7261 6d65 2d4f 7074 696f 6e73 .X-Frame-Options 0x00e0: 3a20 5341 4d45 4f52 4947 494e 0d0a 416c :.SAMEORIGIN..Al 0x00f0: 7465 726e 6174 652d 5072 6f74 6f63 6f6c ternate-Protocol 0x0100: 3a20 3830 3a71 7569 630d 0a0d 0a :.80:quic….
沒錯，在第一個 SYN 包的時候就把 HEAD 請求帶過去了。

但是發現比較奇怪的是很多時候一模一樣的命令，SYN 包上就沒帶資料。

按我的想法，既然還是第一個 SYN 包，用戶端這邊壓根不知道伺服器端的情況，那麼應該不管伺服器端如何 SYN 裡都帶有 HEAD 請求啊？

另外，用 httping -F 命令測試自己編譯的 nginx 的時候，一直都沒看到正確的抓包結果，HEAD 請求一直都是在三向交握後發送的。

試圖用 systemtap 來追蹤一些問題。

第一步確認我的 nginx 的 socket 是不是真的開了 fastopen：

一個終端運行如下命令：

stap -e 'probe kernel.function("do_tcp_setsockopt") {printf("%dn", $optname)}'
另一個終端啟動nginx，看到前一個終端輸出結果為23，查 tcp.h 可以看到 23 正是 TCP_FASTOPEN 沒錯！

第二步確認 httping 發送的時候是不是開了 fastopen：

一個終端運行如下命令：

stap -e 'probe kernel.function("tcp_sendmsg") {printf("%d %xn",$msg->msg_namelen,$msg->msg_flags)}'
另一個終端運行最開始提到的 httping -F 命令，看到前一個終端輸出結果為 16 20000040，查 tcp.h 可以看到 MSG_FASTOPEN 是 0x20000000，MSG_DONTWAIT 是 0x40，也就是說 httping 也沒問題。

現在比較鬱悶的一點是：在 net/ipv4/tcp.c 裡，tcp_sendmsg() 函數會判斷 if ((flags & MSG_FASTOPEN))，就調用 tcp_sendmsg_fastopen() 函數來處理。但是試圖用 systemtap 來調查這個函數的時候，會報一個錯：

WARNING: probe kernel.function("tcp_sendmsg_fastopen@net/ipv4/tcp.c:1005") (address 0xffffffff815cca08) registration error (rc -22)
原因還未知。

留記，繼續研究。

注1：發現 chrome 即使在 about:flags 裡啟用了 fastopen 好像也不行，必須命令列 google-chrome --enable-tcp-fastopen 這樣開啟才行。

注2：網上看到有人寫server和client的demo示範fastopen，但其實不對，demo代碼裡print的資料是正常三向交握以後socket收到的。這點開tcpdump才能確認到底是什麼時候發送的資料