那TCP難道是不可靠的?其實不然。理解的誤區就在網絡協議和行軍打仗的差異上。
具體理解一下，網絡協議中，客戶端和服務器在發送數據時並不要求兩端要同時發送數據，甚至兩端發送的數據內容也不存在必然的聯繫。不像兩軍進攻，要講究目的相同，出發時間相同。細細分析，TCP在發送數據時，都只關心對端是否已經收到自己發送的數據，即只要收到對方對自己發送的數據確認就可以了。換句話說，每一端（客戶端或者服務器）都很“自私”，只保證對方已經收到自己發送的數據就OK了。
按照上面的說法，分析一下TCP交互的過程。客戶要進入ESTABLISHED，因此，客戶端發送SYN告訴服務器要打開鏈路，收到ACK後，表示服務器已經同意了，OK，客戶進入ESTABLISHED狀態。只是客戶建立連接不行啊，服務器還沒進入ESTABLISHED狀態呢，所以服務器在應答時一併發送了自己的SYN，收到客戶端的ACK後，自己才進入ESTABLISHED狀態，然後纔可以接受客戶端發過來的數據。
回顧一下，網絡書籍裏面有一個很著名的問題，“紅軍和藍軍通信聯合進攻山下的敵軍的例子，第一天紅軍發了條信息要藍軍第二天一起進攻，藍軍收到之後，發一條確認信息，但是藍軍擔心的是‘確認信息’如果也不可靠而沒有成功到達紅軍那裏，那自己不是很危險？於是紅軍再發一條‘對確認的確認信息’，但同樣的問題還是不能解決，紅軍仍然不敢貿然行動。”這個問題簡直就是故意在諷刺“三次握手”。
根據這個故事回到“三次握手”，客戶在第三次ACK後，他想，“萬一服務器沒有收到怎麼辦呢？”這個問題只能讓服務器再發一個應答來解決，然後服務器就會遇到同樣的一個問題，如此不斷地糾結下去……而事實上，TCP連接建立時只到客戶第三次ACK就結束了，這能說是“可靠”的協議嗎？
如果按照“紅軍藍軍問題”的思路想下去，那就沒出路了。就該問題目前的條件而言，是永遠沒有結果的，因爲信息發送方在對方不應答的前提之下，永遠不能保證對方是否已經收到，不管信息發送多少次。實際打仗時，最終就只能演變成“默契”問題了，“默契”有沒有辦法用邏輯來解釋，不管大家知不知道，反正我是不知道的。
最後回到最根本的問題，TCP是否是個可靠的協議，答案是肯定的。TCP保證的是自己的行爲被別人確認，而不是確認別人的應答。這裏所謂的行爲便是“我要SYN”、“我要發送數據”、“我要FIN”……在網絡編程中，時刻存在着“主-從”關係，這兩者的地位不是固定的，誰發生了行爲誰就是“主”，誰接受了行爲就是“從”，“主”在乎的是“從”之後的應答，而“從”在乎的是“主”實際的行爲。對於正常的行爲與應答，他們就可取所需，完成一次正常的交互和狀態變遷；對於異常的行爲，“從”不給出“主”最在乎的應答，給出相應的錯誤提示；對於異常的應答，“主”做出相應的反應（比如通知應用進程關閉套接字）。