許久不查TCP相關的問題，今天下班前被一同事攔下要幫忙，說他碰到了奇怪的問題。
拿下wireshark抓到的包一看，半天才明白他所說的疑惑是指他每次發(fā)送一個數(shù)據(jù)包，通信對端就回了一個ACK包，由此就直接懷疑是否對方關閉連接或者建立新的連接了。
花了半天功夫，總算解釋清楚ACK包其實是很正常的數(shù)據(jù)包（帶數(shù)據(jù)的包也有ACK標志的，wireshark只不過是把不帶數(shù)據(jù)的純協(xié)議ACK包在描述信息里邊直接標出來了而已），同事也算是個很老練的Java高手了，對這點基本的小問題有一些疑義，起初是讓我有點疑惑的。
不過總算討論清楚了這個ACK沒有任何問題，本以為他遇到的根本不是問題，豈料他又拋出了一個問題：
既然ACK不是造成問題的癥結，為什么我要發(fā)送三個數(shù)據(jù)包，只有前一個的ACK收到之后，下一個包才能發(fā)的出去？每個數(shù)據(jù)包的發(fā)送和受到ACK的時間間隔大于15ms，而他們的系統(tǒng)需求規(guī)定那個間隔必須小于15ms。
這個問題算是有點深入一點了，即使認為15ms的延遲是正常的TCP協(xié)議棧行為，那么他的三個包只能順序發(fā)出去就有些詫異了，而且據(jù)說是上千個設備都是如此規(guī)律，那么這種規(guī)律本身就不正常了。
首先的懷疑當然是TCP的buffer滿了，導致send發(fā)送阻塞，不過TCP的數(shù)據(jù)內(nèi)容倒是顯示沒有那個問題，因為他發(fā)送的三個包每個都只有幾十個字節(jié)。
剩下的情況大概只有一種，就是應用程序手工設置了buffer大小，甚至是設置了SND_BUF為0（其實只要小于他的最小PDU長度），導致他的協(xié)議交互變成了“停等協(xié)議”了；因為每一次發(fā)送的時候，buffer緩沖都不夠用，所以send調(diào)用必然是被阻塞，直到收到前一個包的ACK數(shù)據(jù)然后才能繼續(xù)；不熟悉TCP協(xié)議棧的，看到這種現(xiàn)象，就懷疑是那個ACK回復的有問題了。
最后他又提出了一個問題，為什么有時候他一次發(fā)送了三個包，抓包的時候只有兩個？恰巧這又是一個TCP控制選項的問題，鼎鼎大名的“Nagle算法“在底下運作的結果了。
為了確認猜測不是問題，讓他Show了一下代碼，確認兩種現(xiàn)象對應的是不同的socket，可惜的是后一個socket的創(chuàng)建代碼是無法看到了。
這些小選項引起都是非常基本的TCP協(xié)議棧原理性知識，為何習慣了Java抽象和自帶類庫的人會被這種問題產(chǎn)生的表面現(xiàn)象所疑惑？