tcp是乙個可靠的協議。有時人們會說："tcp能夠保證它所傳送資料的可靠傳輸。"這種說法儘管很常見，但卻非常不恰當。
首先，只要稍微想一下就會知道這不可能是對的。比如，假設在資料傳輸的過程中將一台主機從網路上斷開，tcp這側不管做出何種努力，都無法獲取其餘 的資料。網路確實會中斷，主機確實會崩潰，使用者確實會在tcp連線仍然活躍的時候關機。這些事件或其他類似的事件都使得tcp無法將它從應用程式收到的數 據傳送出去。
但更重要的是，tcp"確保可靠傳輸"這種說法會對不夠謹慎的網路程式設計師產生微妙的影響。當然，沒人真的會相信tcp有某種魔法總是可以將資料安全 地傳送到其目的地。但是，相信tcp能夠保證可靠傳輸會讓人覺得沒必要進行防禦性程式設計，也沒必要考慮對故障模式的處理，還是那句話，畢竟tcp可以確保可 靠傳輸。
可靠性--是什麼，不是什麼
在考慮tcp中可能出現的各種故障模式之前，要弄清楚tcp的可靠性意味著什麼。如果tcp不能保證將提交給它的所有資料都傳送出去，它又能保證什 麼呢？第乙個問題是向誰保證？圖2-41顯示，資料流從應用程式a通過它所在主機的tcp/ip棧向下傳輸，經過幾台中間路由器，通過應用程式b所在主機 的tcp/ip棧向上傳輸，最後抵達應用程式b。乙個tcp段離開應用程式a所在主機的tcp層時，會被封裝到乙個ip資料報中，傳送給其對等實體主機。 它所走的路由可能要經過很多路由器，但如圖2-41所示，這些路由器都沒有tcp層，它們只是**了ip資料報。
實際上，有些"路由器"可能是擁有完整tcp/ip協議棧的通用計算機，但在這種情況下，它們的路由功能也不涉及tcp或應用層。
我們知道ip是個不可靠的協議，那就應該很清楚，在資料傳輸路徑上，第乙個可以討論確保可靠傳輸問題的地方就是應用程式b所在主機的tcp層。當一 個段抵達應用程式b所在主機的tcp層時，唯一可以確定的就是這個段已經到達了，但它可能損壞了，可能是重複的資料，可能是錯序的，或者是由於其他一些原 因無法接受的。注意，傳送端tcp無法對這些抵達接收端tcp的段做出任何保證。
但接收端tcp要向傳送端tcp確認，也就是說它ack的資料以及在此資料之前到達的所有資料在tcp層都已經正確收到了，傳送端tcp可以安全地 刪除這些資料的副本了。這並不意味著已經將資料傳送，或者總是可以將資料傳送給應用程式。比如，接收端主機可能在剛剛對資料進行了ack，但應用程式還沒 有將其讀走之前，就崩潰了。這個問題值得進一步討論：tcp向傳送端提供的唯一乙個資料接收通知就是這個ack。傳送端應用程式無法從tcp自身判斷對等 實體應用程式是否真的收到資料了。稍後我們會說明，這是應用程式編寫者要弄清楚的一種tcp故障模式。
另乙個可以討論確保可靠傳輸問題的地方是應用程式b。我們知道，無法保證應用程式a傳送的所有資料都會到達。tcp能夠向應用程式b保證的是所有到達的資料都是按序且未受損的。
前面已經提到過一種tcp故障模式了：tcp已經ack了的資料實際上可能不會抵達目的應用程式。這是相當罕見的事情，即使發生這種事情，影響也不會太嚴重。重要的是網路程式設計師要知道這種可能性的存在，要對這種或其他所有故障模式可能帶來的不良後果有所預防。要避免這樣一種看法：tcp會做好一切準備，我們不需要為應用程式協議的健壯性操心。
前面討論的故障模式有很明確的解決方案。對應用程式來說，明確地知道對等實體收到了某個特定的報文是非常重要的，其對等實體就必須將收到報文的資訊
通知傳送端。通常，這種確認資訊都是隱式的。比如，如果客戶端向伺服器請求一些資料，伺服器進行了響應，那麼，這個響應就隱式地確認收到了原始請求。
乙個更難解決的問題是如果伺服器沒有對收到的報文進行確認，客戶端會怎麼做？當然，這與特定的應用程式有很大的關係，很可能沒有乙個統一的解決方
案。但我們應該注意到，僅僅重發請求很可能無法解決問題：我們不想請求銀行進行兩次轉賬。資料庫系統使用三階段提交協議來處理這種型別的問
題，某些應用程式可能會使用類似的策略來確保操作"最多執行一次"。
tcp是乙個端對端協議，也就是說它自己要在對等實體之間提供可靠的傳輸機制。但是，認識到"端點"位於對等的tcp層，而不是對等的應用程式中是非常重要的。要求進行端到端確認的應用程式必須自身提供此項功能（比如wcf實現的ws-rm）。
看看其他一些"常見的"故障模式。只要兩個對等實體仍然連著，tcp就能保證將資料按序、無損壞地傳送。只有連線中斷時才會出現故障。什麼型別的事件會造成這種中斷呢？有三種情況可能引發這類問題：
(1) 永久或臨時的網路中斷；
(2) 對等的應用程式崩潰；
(3) 執行對等應用程式的主機崩潰。
我們會看到，在傳送端應用程式中，這些事件會以不同的方式顯現出來。
tcp是乙個可靠的協議。有時人們會說："tcp能夠保證它所傳送資料的可靠傳輸。"這種說法儘管很常見，但卻非常不恰當。
首先，只要稍微想一下就會知道這不可能是對的。比如，假設在資料傳輸的過程中將一台主機從網路上斷開，tcp這側不管做出何種努力，都無法獲取其餘 的資料。網路確實會中斷，主機確實會崩潰，使用者確實會在tcp連線仍然活躍的時候關機。這些事件或其他類似的事件都使得tcp無法將它從應用程式收到的數 據傳送出去。
但更重要的是，tcp"確保可靠傳輸"這種說法會對不夠謹慎的網路程式設計師產生微妙的影響。當然，沒人真的會相信tcp有某種魔法總是可以將資料安全 地傳送到其目的地。但是，相信tcp能夠保證可靠傳輸會讓人覺得沒必要進行防禦性程式設計，也沒必要考慮對故障模式的處理，還是那句話，畢竟tcp可以確保可 靠傳輸。
可靠性--是什麼，不是什麼
在考慮tcp中可能出現的各種故障模式之前，要弄清楚tcp的可靠性意味著什麼。如果tcp不能保證將提交給它的所有資料都傳送出去，它又能保證什 麼呢？第乙個問題是向誰保證？圖2-41顯示，資料流從應用程式a通過它所在主機的tcp/ip棧向下傳輸，經過幾台中間路由器，通過應用程式b所在主機 的tcp/ip棧向上傳輸，最後抵達應用程式b。乙個tcp段離開應用程式a所在主機的tcp層時，會被封裝到乙個ip資料報中，傳送給其對等實體主機。 它所走的路由可能要經過很多路由器，但如圖2-41所示，這些路由器都沒有tcp層，它們只是**了ip資料報。
實際上，有些"路由器"可能是擁有完整tcp/ip協議棧的通用計算機，但在這種情況下，它們的路由功能也不涉及tcp或應用層。
我們知道ip是個不可靠的協議，那就應該很清楚，在資料傳輸路徑上，第乙個可以討論確保可靠傳輸問題的地方就是應用程式b所在主機的tcp層。當一 個段抵達應用程式b所在主機的tcp層時，唯一可以確定的就是這個段已經到達了，但它可能損壞了，可能是重複的資料，可能是錯序的，或者是由於其他一些原 因無法接受的。注意，傳送端tcp無法對這些抵達接收端tcp的段做出任何保證。
但接收端tcp要向傳送端tcp確認，也就是說它ack的資料以及在此資料之前到達的所有資料在tcp層都已經正確收到了，傳送端tcp可以安全地 刪除這些資料的副本了。這並不意味著已經將資料傳送，或者總是可以將資料傳送給應用程式。比如，接收端主機可能在剛剛對資料進行了ack，但應用程式還沒 有將其讀走之前，就崩潰了。這個問題值得進一步討論：tcp向傳送端提供的唯一乙個資料接收通知就是這個ack。傳送端應用程式無法從tcp自身判斷對等 實體應用程式是否真的收到資料了。稍後我們會說明，這是應用程式編寫者要弄清楚的一種tcp故障模式。
另乙個可以討論確保可靠傳輸問題的地方是應用程式b。我們知道，無法保證應用程式a傳送的所有資料都會到達。tcp能夠向應用程式b保證的是所有到達的資料都是按序且未受損的。
前面已經提到過一種tcp故障模式了：tcp已經ack了的資料實際上可能不會抵達目的應用程式。這是相當罕見的事情，即使發生這種事情，影響也不會太嚴重。重要的是網路程式設計師要知道這種可能性的存在，要對這種或其他所有故障模式可能帶來的不良後果有所預防。要避免這樣一種看法：tcp會做好一切準備，我們不需要為應用程式協議的健壯性操心。
前面討論的故障模式有很明確的解決方案。對應用程式來說，明確地知道對等實體收到了某個特定的報文是非常重要的，其對等實體就必須將收到報文的資訊
通知傳送端。通常，這種確認資訊都是隱式的。比如，如果客戶端向伺服器請求一些資料，伺服器進行了響應，那麼，這個響應就隱式地確認收到了原始請求。
乙個更難解決的問題是如果伺服器沒有對收到的報文進行確認，客戶端會怎麼做？當然，這與特定的應用程式有很大的關係，很可能沒有乙個統一的解決方
案。但我們應該注意到，僅僅重發請求很可能無法解決問題：我們不想請求銀行進行兩次轉賬。資料庫系統使用三階段提交協議來處理這種型別的問
題，某些應用程式可能會使用類似的策略來確保操作"最多執行一次"。
tcp是乙個端對端協議，也就是說它自己要在對等實體之間提供可靠的傳輸機制。但是，認識到"端點"位於對等的tcp層，而不是對等的應用程式中是非常重要的。要求進行端到端確認的應用程式必須自身提供此項功能（比如wcf實現的ws-rm）。
看看其他一些"常見的"故障模式。只要兩個對等實體仍然連著，tcp就能保證將資料按序、無損壞地傳送。只有連線中斷時才會出現故障。什麼型別的事件會造成這種中斷呢？有三種情況可能引發這類問題：
(1) 永久或臨時的網路中斷；
(2) 對等的應用程式崩潰；
(3) 執行對等應用程式的主機崩潰。
我們會看到，在傳送端應用程式中，這些事件會以不同的方式顯現出來。
關於TCP的可靠性
tcp是乙個可靠的協議。有時人們會說 tcp能夠保證它所傳送資料的可靠傳輸。這種說法儘管很常見，但卻非常不恰當。首先，只要稍微想一下就會知道這不可能是對的。比如，假設在資料傳輸的過程中將一台主機從網路上斷開，tcp這側不管做出何種努力，都無法獲取其餘 的資料。網路確實會中斷，主機確實會崩潰，使用者確...
TCP如何實現可靠性
tcp傳輸控制協議 tcp 協議是一種面向連線的，為不同主機程序間提供可靠資料傳輸的協議。tcp 協議假定其所使用的網路棧下層協議 如ip 協議 是非可靠的，其自身提供機制保證資料的可靠性傳輸。在目前的網路棧協議族中，在需要提供可靠性資料傳輸的應用中，tcp 協議是首選的，有時也是唯一的選擇。tcp...
TCP如何實現可靠性
一 綜述 1 確認和重傳 接收方收到報文就會確認，傳送方傳送一段時間後沒有收到確認就重傳。2 資料校驗 3 資料合理分片和排序 udp ip資料報大於1500位元組,大於mtu.這個時候傳送方ip層就需要分片 fragmentation 把資料報分成若干片,使每一片都小於mtu.而接收方ip層則需要...