fopen为什么慢之后继---用tcpdump抓包看看慢在哪里

本文背景：

外国友人用Wireshark监听数据包的方式分析出来了为什么fopen打开部分url很慢的原因。于是我也动手实践了一遍，有收获，以后查很多网络问题又多了一种思路。

抓包命令：

tcpdump -i eth1 host 101.227.160.54 and port 80 -Ap -v -s10000

命令解释参考：http://www.tcpdump.org/tcpdump_man.html

下面的字段理解参考：http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm

关于TCP握手的知识，我已经还给老师了，也不是本文重点。有兴趣的同学可以去百度“TCP连接 握手"。

根据TCP协议，当服务器A（172.92.54.111）去请求服务器B（101.227.160.54）上的图片资源时，会出现下面的对话：

>>>>>>>>> 网络连接时，会出现下面的3次握手 <<<<<<<<<<

20:56:59.261486 IP (tos 0x0, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 44)
101.227.160.54.http > 172.92.54.111.50017: Flags [S.], cksum 0x5a5d (correct), seq 2948196447, ack 2639574296, win 14400, options [mss 1440], length 0
E..,..@.1..we..6.\...P.a..._.T..`.8@Z]......
20:56:59.261519 IP (tos 0x0, ttl 64, id 41118, offset 0, flags [DF], proto TCP (6), length 40)
172.92.54.111.50017 > 101.227.160.54.http: Flags [.], cksum 0x713e (correct), ack 1, win 14600, length 0
E..(..@.@.B..\..e..6.a.P.T.....`P.9.q>..
20:56:59.261731 IP (tos 0x0, ttl 64, id 41119, offset 0, flags [DF], proto TCP (6), length 291)
172.92.54.111.50017 > 101.227.160.54.http: Flags [P.], cksum 0x586a (incorrect -> 0xf6e7), seq 1:252, ack 1, win 14600, length 251

>>>>>>>>>>> 握手成功后，进入HTTP协议层，下面是HTTP GET <<<<<<<<<<<

E..#..@.@.A..\..e..6.a.P.T.....`P.9.Xj..GET /mmopen/vkcbK8GuuPv0s3mHJdIoWg7lZk6NwpldyibBVmlMp9f0SyBnFnmgDxQ0RZjUPSmaoiagsV2eRdibulfY907NCLic8WBfFQu4cYSE/64 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Host: 101.227.160.54
Accept: */*

<pre name="code" class="plain">>>>> 40个字节的ack，表示GET收到 <<<<<<

20:56:59.294030 IP (tos 0x0, ttl 49, id 53433, offset 0, flags [DF], proto TCP (6), length 40)
101.227.160.54.http > 172.92.54.111.50017: Flags [.], cksum 0x6c93 (correct), ack 252, win 15544, length 0
E..(..@.1.!.e..6.\...P.a...`.T..P.<.l...

>>>>>>>>>>> HTTP GET的应答内容 <<<<<<<<<<<<<<<

>>>> 由于应答内容比较大，超过了MTU（1480字节），所以应答数据是分了两个包发过来的。 <<<<<

20:56:59.294138 IP (tos 0x0, ttl 49, id 53434, offset 0, flags [DF], proto TCP (6), length 1480)
101.227.160.54.http > 172.92.54.111.50017: Flags [.], cksum 0x0a51 (correct), seq 1:1441, ack 252, win 15544, length 1440
E.....@.1..!e..6.\...P.a...`.T..P.<.
Q..HTTP/1.1 200 OK
Server: ImgHttp3.0.0
Connection: keep-alive
Content-Type: image/jpeg
Content-Length: 2205
Last-Modified: Mon, 21 Jul 2014 23:23:29 GMT
Cache-Control: max-age=2592000
X-Delay: 1043 us
X-Info: real data
X-Cpt: filename=0
User-ReturnCode:0
Size: 2205
chid: 0
fid: 0
X-RtFlag: 1

......JFIF..............Exif.....C......................
.....
...
........................................................@.@..".............................	.....
...7..........................!..1AQ.."a.2q..	B.#$br...................................*........................!1A..Qaq.."$................?.[K...O.....P.*..AA.%n8G.......>.3....1...`...-..T......Sd..Ds..r=FG..,...O
.`........x.......:|..5.J...i.V.%.)...~.......s~m=.j..wfQd....Qy.........l...rr...o`U.'$...0[<..5i.*.`I..q.Mn9.-z......&#.......6....,.[R[...]j..G.qS!	,..J......8..O.8...pGJ5.c...&...
B...fK...]!g...w...pq..L.*T...$...;C.,.X.A...^....;b...!..D8.]..Ok..`6..$.$s...,q.w..Z.t...e.{i....ow][.en...,..6.eR......	.;I....."...[.L..2!Anc.u..*....F;......)...4[Tzn..H.Bn..c.-.ZZ.....[.k.......2|zk.....Wm.em..Z.%.!A%..O.A..S.@.....yP.>ptZM.S......J..H..K.........A.cugu.t..k..PU&[-?).-..*q...N/8...<...

>>>> ack, 第一个包已经收到，请发第二个包 <<<<<<
20:56:59.294151 IP (tos 0x0, ttl 64, id 41120, offset 0, flags [DF], proto TCP (6), length 40)
172.92.54.111.50017 > 101.227.160.54.http: Flags [.], cksum 0x602b (correct), ack 1441, win 17280, length 0
E..(..@.@.B..\..e..6.a.P.T......P.C.`+..

>>>> 第二个回复包 <<<<
20:56:59.294164 IP (tos 0x0, ttl 49, id 53435, offset 0, flags [DF], proto TCP (6), length 1113) 101.227.160.54.http > 172.92.54.111.50017: Flags [P.], cksum 0x9fa1 (correct), seq 1441:2514, ack 252, win 15544, length 1073E..Y..@.1...e..6.\...P.a.....T..P.<......Hw.6.n..x. .Kc..s..v.....Di.....)h..XxVo..Zl...G5......c..n......._.]........<.B-.....=....*............K.....f...?..".....YN<.$x.s.....u....K.A..r...T.....r3... ..{...nh......Xp.].NO...........M1...24..N..R...I..l(.;.s.G.H.#......+sI+.l.N...._..k..l:.u.+.#=..*S...P.e$.`g?.t5..^...O...?.&s4Q...NO.t..S..3.D.............M&.P.....%..F;.x.......... =fP..Y..k...:.MA.....}...4 d8.....Rx......"...........G.$i.>....W..*.x... .J..w.t.y..?.G.."..;.U."...?..8./..}...4.4...iO.J...$8{],.ox.Z.K..I.D..e%e_.8Bp........A../.U.F...3u..5'o(...o&B...&:..Pe.'....R.........P.}..7..M[h.....~.!m....F^B..v..iQo..?...j.....u..'..........w5V.*4 ..B.$.......i..u.&....=...0..3.<.j.u.(.'3{.....<.n.....R.<...P..=3.e......4n.._..

就是在这，挂了很久很久！！！！
>>>>>>>> 客户端主动断开链接，网络断开后，会进入TCP断开时的4次握手 <<<<<<<<

20:56:59.294168 IP (tos 0x0, ttl 64, id 41121, offset 0, flags [DF], proto TCP (6), length 40) 172.92.54.111.50017 > 101.227.160.54.http: Flags [.], cksum 0x50ba (correct), ack 2514, win 20160, length 0E..(..@.@.B..\..e..6.a.P.T.....1P.N.P...
20:56:59.296012 IP (tos 0x0, ttl 64, id 41122, offset 0, flags [DF], proto TCP (6), length 40) 172.92.54.111.50017 > 101.227.160.54.http: Flags [F.], cksum 0x50b9 (correct), seq 252, ack 2514, win 20160, length 0E..(..@.@.B..\..e..6.a.P.T.....1P.N.P...
20:56:59.328827 IP (tos 0x0, ttl 49, id 53436, offset 0, flags [DF], proto TCP (6), length 40) 101.227.160.54.http > 172.92.54.111.50017: Flags [F.], cksum 0x62c0 (correct), seq 2514, ack 253, win 15544, length 0E..(..@.1.!.e..6.\...P.a...1.T..P.<.b...
20:56:59.328865 IP (tos 0x0, ttl 64, id 41123, offset 0, flags [DF], proto TCP (6), length 40) 172.92.54.111.50017 > 101.227.160.54.http: Flags [.], cksum 0x50b8 (correct), ack 2515, win 20160, length 0E..(..@.@.B..\..e..6.a.P.T.....2P.N.P...

结论：

上一篇文章中，fopen打开URL慢，根据抓包的情况看，就是慢在收到所有图片数据包后，系统卡住十来秒，然后才进入主动断开链接的阶段。说明这个时候客户端（fopen）似乎在等待点什么，然而却并没有等到，等了好久，就恋恋不舍主动断开了。这一等，就把程序卡住了10秒。真相大白。