tcp協議傳輸的特點主要就是面向位元組流、傳輸可靠、面向連線。這篇部落格，我們就重點討論一下tcp協議如何確保傳輸的可靠性的。
確保傳輸可靠性的方式
tcp協議保證資料傳輸可靠性的方式主要有：
校驗和序列號
確認應答
超時重傳
連線管理
流量控制
擁塞控制
計算方式：在資料傳輸的過程中，將傳送的資料段都當做乙個16位的整數。將這些整數加起來。並且前面的進製不能丟棄，補在後面，最後取反，得到校驗和。
傳送方：在傳送資料之前計算檢驗和，並進行校驗和的填充。
接收方：收到資料後，對資料以同樣的方式進行計算，求出校驗和，與傳送方的進行比對。
注意：如果接收方比對校驗和與傳送方不一致，那麼資料一定傳輸有誤。但是如果接收方比對校驗和與傳送方一致，資料不一定傳輸成功。
確認應答與序列號
序列號：tcp傳輸時將每個位元組的資料都進行了編號，這就是序列號。
確認應答：tcp傳輸的過程中，每次接收方收到資料後，都會對傳輸方進行確認應答。也就是傳送ack報文。這個ack報文當中帶有對應的確認序列號，告訴傳送方，接收到了哪些資料，下一次的資料從**發。
序列號的作用不僅僅是應答的作用，有了序列號能夠將接收到的資料根據序列號排序，並且去掉重複序列號的資料。這也是tcp傳輸可靠性的保證之一。
在進行tcp傳輸時，由於確認應答與序列號機制，也就是說傳送方傳送一部分資料後，都會等待接收方傳送的ack報文，並解析ack報文，判斷資料是否傳輸成功。如果傳送方傳送完資料後，遲遲沒有等到接收方的ack報文，這該怎麼辦呢？而沒有收到ack報文的原因可能是什麼呢？
首先，傳送方沒有介紹到響應的ack報文原因可能有兩點：
資料在傳輸過程中由於網路原因等直接全體丟包，接收方根本沒有接收到。
接收方接收到了響應的資料，但是傳送的ack報文響應卻由於網路原因丟包了。
tcp在解決這個問題的時候引入了乙個新的機制，叫做超時重傳機制。簡單理解就是傳送方在傳送完資料後等待乙個時間，時間到達沒有接收到ack報文，那麼對剛才傳送的資料進行重新傳送。如果是剛才第乙個原因，接收方收到二次重發的資料後，便進行ack應答。
那麼傳送方傳送完畢後等待的時間是多少呢？如果這個等待的時間過長，那麼會影響tcp傳輸的整體效率，如果等待時間過短，又會導致頻繁的傳送重複的包。如何權衡？
由於tcp傳輸時保證能夠在任何環境下都有乙個高效能的通訊，因此這個最大超時時間（也就是等待的時間）是動態計算的。
在linux中（bsd unix和windows下也是這樣）超時以500ms為乙個單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍。重發一次後，仍未響應，那麼等待2*500ms的時間後，再次重傳。等待4*500ms的時間繼續重傳。以乙個指數的形式增長。累計到一定的重傳次數，tcp就認為網路或者對端出現異常，強制關閉連線。
連線管理就是三次握手與四次揮手的過程，在前面詳細講過這個過程，這裡不再贅述。保證可靠的連線，是保證可靠性的前提。
接收端在接收到資料後，對其進行處理。如果傳送端的傳送速度太快，導致接收端的結束緩衝區很快的填充滿了。此時如果傳送端仍舊傳送資料，那麼接下來傳送的資料都會丟包，繼而導致丟包的一系列連鎖反應，超時重傳呀什麼的。而tcp根據接收端對資料的處理能力，決定傳送端的傳送速度，這個機制就是流量控制。
在tcp協議的報頭資訊當中，有乙個16位字段的視窗大小。在介紹這個視窗大小時我們知道，視窗大小的內容實際上是接收端接收資料緩衝區的剩餘大小。這個數字越大，證明接收端接收緩衝區的剩餘空間越大，網路的吞吐量越大。接收端會在確認應答傳送ack報文時，將自己的即時視窗大小填入，並跟隨ack報文一起傳送過去。而傳送方根據ack報文裡的視窗大小的值的改變進而改變自己的傳送速度。如果接收到視窗大小的值為0，那麼傳送方將停止傳送資料。並定期的向接收端傳送視窗探測資料段，讓接收端把視窗大小告訴傳送端。
注：16位的視窗大小最大能表示65535個位元組（64k），但是tcp的視窗大小最大並不是64k。在tcp首部中40個位元組的選項中還包含了乙個視窗擴大因子m，實際的視窗大小就是16為視窗欄位的值左移m位。每移一位，擴大兩倍。
tcp傳輸的過程中，傳送端開始傳送資料的時候，如果剛開始就傳送大量的資料，那麼就可能造成一些問題。網路可能在開始的時候就很擁堵，如果給網路中在扔出大量資料，那麼這個擁堵就會加劇。擁堵的加劇就會產生大量的丟包，就對大量的超時重傳，嚴重影響傳輸。
所以tcp引入了慢啟動的機制，在開始傳送資料時，先傳送少量的資料探路。探清當前的網路狀態如何，再決定多大的速度進行傳輸。這時候就引入乙個叫做擁塞視窗的概念。傳送剛開始定義擁塞視窗為 1，每次收到ack應答，擁塞視窗加 1。在傳送資料之前，首先將擁塞視窗與接收端反饋的視窗大小比對，取較小的值作為實際傳送的視窗。
擁塞視窗的增長是指數級別的。慢啟動的機制只是說明在開始的時候傳送的少，傳送的慢，但是增長的速度是非常快的。為了控制擁塞視窗的增長，不能使擁塞視窗單純的加倍，設定乙個擁塞視窗的閾值，當擁塞視窗大小超過閾值時，不能再按照指數來增長，而是線性的增長。在慢啟動開始的時候，慢啟動的閾值等於視窗的最大值，一旦造成網路擁塞，發生超時重傳時，慢啟動的閾值會為原來的一半（這裡的原來指的是發生網路擁塞時擁塞視窗的大小），同時擁塞視窗重置為 1。
擁塞控制是tcp在傳輸時盡可能快的將資料傳輸，並且避免擁塞造成的一系列問題。是可靠性的保證，同時也是維護了傳輸的高效性。
網路基礎 TCP協議 如何保證傳輸可靠性
tcp協議傳輸的特點主要就是面向位元組流 傳輸可靠 面向連線。這篇部落格，我們就重點討論一下tcp協議如何確保傳輸的可靠性的。tcp協議保證資料傳輸可靠性的方式主要有 計算方式 在資料傳輸的過程中，將傳送的資料段都當做乙個16位的整數。將這些整數加起來。並且前面的進製不能丟棄，補在後面，最後取反，得...
TCP 協議如何保證可靠傳輸
一 綜述 1 確認和重傳 接收方收到報文就會確認，傳送方傳送一段時間後沒有收到確認就重傳。2 資料校驗 3 資料合理分片和排序 udp ip資料報大於1500位元組,大於mtu.這個時候傳送方ip層就需要分片 fragmentation 把資料報分成若干片,使每一片都小於mtu.而接收方ip層則需要...
TCP協議如何保證可靠傳輸
一 可靠傳輸的要求 可靠的傳輸應該滿足下面兩個要求 1 傳輸的通道不產生差錯 2 保證傳輸資料的正確性，無差錯 不丟失 不重複 並且按序到達。這裡有兩層意思，一是能夠正確地傳輸資料，二是接收方能夠及時處理傳送方傳送的資料。二 可靠傳輸的工作原理 tcp為了提供可靠傳輸 1 首先，採用三次握手來建立t...