■tcp認識的誤區
應用開發人員常常遇到這樣的困惑：為什么用tcp寫的應用還會出現數據丟失呢？很多人都以為tcp 協議可以確保數據的傳輸，但事實上沒有任何一種協議可以做到這一點。tcp所能做只是傳輸數據，如果失敗了，它會通知你，但它無法告訴你有多少數據沒有被正確傳送。
tcp 協議中的應答機制使得發送方的tcp棧確保接收方tcp棧收到了數據。
tcp包頭包括32位的順序碼和應答碼，順序碼是在連接建立時隨機產生的，并隨著傳輸的字節數遞增。當數據被接收時，接收方的tcp棧會給發送方發送應答碼， 如果發送方沒收到應答碼, 它就會重發該數據。發方和收方的順序碼是各自獨立的。
■tcp是一個窗口式的協議
tcp是一個窗口式的協議。tcp包頭數據中也包含窗口的大小，它告訴遠端再傳多少數據后就必須停止。窗口大小實際上就是緩存區的大小，當緩沖區滿的 時候，窗口就會關閉。當發送方收到的應答中窗口大小為零時，它會自動停止發送。發送方會記住自己發送了多少數據，即使沒有收到窗口大小為零的應答，它也不 會發送大于緩沖區的數據。
通常接收方應答這些數據時，應用會不斷讀數據，這樣窗口就經常處于開放狀態。
導致窗口關閉的最常見原因是i/o阻塞。這通常是臨時性的，一般i/o通暢后，緩存（窗口）會自動開放。第二個原因就是應用代碼中的bug使得接收應用程序忽略了連接，重要的不在于接收方讀沒讀數據，而在于發送方在收到應答后是否正確地發送了數據。
■tcp的緩存機制
發送tcp棧在收到應答前必須對數據進行緩存，而應用程序在調用tcp棧發送數據時并不知道數據已經在緩存區了。只要發送tcp棧還有空間，它就會接收來自應用的數據并進行緩存。一旦緩存滿了導致應用程序無法繼續發送，它就會認為有問題了。
如果問題是發送tcp棧沒有收到應答，那么它會重發，等待應答的時間會越來越長，直至最終放棄并重新建立連接。重新連接后本地緩存會清空，并通知應用 程序。但是至于有多少數據在緩存區沒有收到應答仍不得而知。本地tcp棧無法知道遠端是否收到了數據，也不知道是否收到了遠端應答。
如果問題是窗口關閉了，那么發送tcp棧會定期發送窗口探針來探測接收方窗口是否開放。接收tcp棧必須應答窗口探針包。應答包含當前窗口大小。在收到探針應答前，發送tcp棧只能等待。
■路在何方
也許有人會說：既然如此，為何還要用tcp協議？如果應用中必須包括數據標識和應答，為什么不用udp協議？tcp的優勢在于你不必擔心數據傳輸機 制，如果數據包在傳輸過程中由于路由的關系，其到達順序被打亂，接收tcp棧會將這些數據包按其順序碼重新排列，從而保證了數據的正確性。而如果采用 udp的話，則應用中必須設法提供所有這些機制。
如果發生了傳輸線路中斷，僅有應用層的應答是不夠的。按照應用層應答機制，在重建連接后，發送方會重發那些沒有收到應答的數據包，但是有可能雖然這些 應答丟了，可數據卻到達了，并已用于應用程序。為了防止這種情況，發送應用方需保存沒被接收應用應答的數據段的標識 ，接收應用方也應保存自己已接收和處理過的數據段的標識。當重建連接時，發送方將發送第一個沒有收到應答的數據段，或者詢問接收方最后發出的應答進行確 認。為了確保數據傳輸的無誤, 應該保證接收應用方保存的數據段標識在應用重啟或系統癱瘓時仍能安然無恙。
盡管tcp協議十分優秀，但它并不能確保數據數據傳輸萬無一失。