昨天在小組的技術分享上，組長教我們怎樣去調試一個服務器程序，收穫很大。
1:ping 典型的 80或者23 這些端口，看看機器還活着麼
2:telnet 看看我們的程序端口開着麼(當然前提是TCP)
3:tcpdump 抓包，可以看看網絡包的接受和發送速度，對於文本協議的調試更方便了。
啊。扯遠了，主要還是在抓包的時候，應該四次揮手的TCP我們看到了3次，其中被動關閉方和FIN和對主動關閉方的ACK合併成了一個包。
我第一感覺很正常啊，因爲右Nagle算法的存在。
我是這樣理解的（我理解的是錯的）
所謂Nagle算法，就是當我收到一個包的時候，並不立即發送對這個包的ACK確認，而是至多等待200ms(因爲這是一個全局定時器)，把內核模塊的ack確認和應用程序的數據組成一個包發出去。當被動關閉方收到主動關閉方的關閉FIN時，TCP內核模塊並沒有立即回覆ACK確認，而是等待（至多200ms）應用程序調用了close之後，把被動關閉方的FIN和對主動關閉方的ACK確認一起發送了。
組長說我沒有理解Nagle算法，結果和組長爭執了半天。
回家後，自己動手測試，如果真是我所說的那樣，當我關閉掉Nagle算法的時候，那應該能看到揮手的是4個包而不是3個包。
09:39:13.538063 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [S], seq 1375217039, win 32792, options [mss 16396,sackOK,TS val 773817 ecr 0,nop,wscale 7], length 0
09:39:13.538098 IP 127.0.0.1.5757 > 127.0.0.1.38963: Flags [S.], seq 3591125878, ack 1375217040, win 32768, options [mss 16396,sackOK,TS val 773817 ecr 773817,nop,wscale 7], length 0
09:39:13.538127 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [.], ack 1, win 257, options [nop,nop,TS val 773817 ecr 773817], length 0
09:39:19.117919 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [F.], seq 1, ack 1, win 257, options [nop,nop,TS val 775212 ecr 773817], length 0
09:39:19.118006 IP 127.0.0.1.5757 > 127.0.0.1.38963: Flags [F.], seq 1, ack 2, win 256, options [nop,nop,TS val 775212 ecr 775212], length 0
09:39:19.118040 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [.], ack 2, win 257, options [nop,nop,TS val 775212 ecr 775212], length 0上面是我關閉掉Nagle算法之後抓包的包，前3個是握手，後3個是揮手。事實證明我錯了。
趕緊查證《unix網絡編程》和《TCP/IP詳解1》，書上面明顯的寫着“Nagle算法指出：如果某個給定連接上有待確認數據，那麼原本應該作爲用戶寫操作之響應的在該連接上立即發送相應小分組的行爲就不會發生，直到現有數據被確認爲止".
讀起來很拗口，我就用河南話說一下：
A---B：在麼
A---B：我想你了
A---B：今晚有空麼
B---A：在
B---A：我也想你了
B---A：今晚木有空。。。看看，追女神不應該是這樣子，連着給女神發3條信息，女神也思考不過來啊，對女神也造成了精神損失。
試試下面的：
A---B：在麼
B---A：嗯，在的
A---B：我想你了，今晚有空麼
B---A：我在XXX等你。這就是開啓Nagle算法的好處，手到禽來。Nagle算法就是說女神沒有確認你的信息時候，就別在死纏爛打了，等女神回覆的這段時候內，準備好接下來要說的話，別蘿莉羅嗦的，把要說的一次說明白。
這下好了，不僅追到了女神，發的信息條數也少了，一條可是一毛錢啊，這在帝都的IT狗眼裏也是很寶貴的。。。
不過呢，事物都有兩面性，如果女神沒看手機，或者過了10分鐘才恢復，那這段時間自己動手就解決需求了。
所以，實際開發中，對於C/S的遊戲，如果客戶端每次收到對本次請求的迴應之後，再發下一個包，我了個去，這卡的，玩家不罵死人才怪。這個時候就要關閉Nagle算法了，讓客戶端可以嘩嘩譁不停的發包去騷擾服務器。不過這可能會帶來網絡風暴，客戶端本可以把兩次的包合在一起的（當然是TCP內核模塊乾的事）。
我擦，怎麼寫不下去了，原來扯到女神身上了。
把當前大腦上下文切到tcpdump上，爲什麼揮手4次變3次呢。
因爲ACK延遲算法。
A---B：今晚有空麼
B---A：嗯
B---A：我在XXX等你
變成了下面這樣
A---B：今晚有空麼
B---A：有空，我在XXX等你ACK延遲算法，就是女神收到我的信息之後，不是立馬回覆一個“嗯，知道了”這中草蛋的話，而是在通知我她已經知道了的時候還一併把房間號告訴了我。
但是女神打字也是需要時間的啊，所以回覆的ACK也要慢個200ms吧，等女神把“有空，我在XXX等你”打好之後，一併把“嗯”發過來。