目錄
前言
TCP如何實作可靠傳輸
停止等待協定
1. 出現差錯或丢失情況
2. 确認丢失和确認遲到情況
優缺點
流水線傳輸實作可靠傳輸（連續ARQ協定）
以位元組為機關的滑動視窗技術
正常不丢包的情況
包丢失的情況
選擇确認情況
TCP協定如何實作流量控制
TCP協定如何避免網絡擁塞
慢開始算法
快重傳和快恢複機制
發送視窗的實際上限值
前言
本文是接着上一篇：https://blog.csdn.net/qq_36652619/article/details/99194290
延續TCP的幾個特點的實作
TCP如何實作可靠傳輸
網絡層隻負責把資料包從一個網段轉移到另一個網段，丢包是不管的，可靠傳輸是由傳輸層負責的。
停止等待協定
停止等待協定（stop-and-wait）是最簡單但也是最基礎的資料鍊路層協定。很多有關協定的基本概念都可以從這個協定中學習到。
停止等待就是每發送完一個分組就停止發送，等待對方的确認。在收到确認後再發送下一個分組。
1. 出現差錯或丢失情況
下圖左邊是正常情況，如果對方沒有收到則逾時重傳。
2. 确認丢失和确認遲到情況
确認丢失：B發的确認的包丢失了，A沒有收到确認，重發M1，這樣B就收到兩個M1，這時候B就會丢棄重複的M1，重傳确認M1
确認遲到：B收到M1，發出确認，但是确認的包在網絡裡可能走了一條比較遠的路，時間較久，A沒有收到确認，重新發M1，然後B丢掉重複的M1，重發确認，然後A收到确認發出M2，發出M2後，第一次遲到的M1的确認來了，但是A收到後什麼也不做。
使用上述的确認和重傳機制，我們就可以在不可靠的傳輸網絡上實作可靠通信。
這種可靠傳輸協定通常被稱為自動重傳請求ARQ
優缺點
停止等待協定的有點是簡單，缺點是信道使用率低（發一個資料包，要等待的時間比發資料包的時間長很多）。
解決信道使用率低：【流水線傳輸】發送方連續發送多個分組，這樣發資料包的時間就增加了，不用一直等着确認，不必每發完一個分組就停頓等到對方确認。
流水線傳輸實作可靠傳輸（連續ARQ協定）
可以看到下圖的a圖，發送視窗是5，那麼1~5的資料包可以連續的發出去，第六個資料包不能發了，因為發送視窗是5。這時候就開始等到确認，第一個資料包收到确認，發送視窗就往後移。
以位元組為機關的滑動視窗技術
圖解滑動視窗：
正常不丢包的情況
（上圖的視窗沒到10，大家了解成10）
包丢失的情況
選擇确認情況
TCP協定如何實作流量控制
圖解：
TCP協定如何避免網絡擁塞
當一個網絡裡面有很多個計算機一起在上網的時候就有可能造成網絡堵塞。
網絡中的計算機隻要發現丢包情況就主動的降低發送資料的速度避免堵死。
出現擁塞的條件：對資源需求的總和 > 可用資源
可以看到，比如我們的帶寬有限，對吧，凡事都有理想狀态，理想的世界是美好的，現實的世界是殘酷的，哦不，是凄慘的。那麼理想狀态，我們的流量沒到帶寬對應的吞吐量上限，那麼來多少我就應該收多少，對吧，是一條45度角的直線上升，然後到了吞吐量上限之後平緩，以最大值一直傳輸。
那麼理想是美好的，現實肯定不能讓你如意，看上圖，沒有擁塞控制的綠色的線，可以看到它的流量還沒有到上限，就開始往下降了，是不是有問題，那麼問題在哪？路由器是一台機器吧，那麼我們吧路由器類比成一個主機，那麼一個主機處理一個應用程式的速度可以達到理想狀态吧，但是處理一萬個應用程式的速度，還能有“按理來說”的那種速度嘛，有人說，那可能就沒速度了。
對吧，随着流量的增多，網絡的處理速度變慢，傳輸速度自然沒有理想狀态那麼多，而且到了綠線的後期，直接堵死了。
實際的擁塞控制就是去避免了堵死的情況，但也達不到理想的情況。
慢開始算法
cwnd可以把它了解成視窗，可以看到一開始的時候試探性的小視窗發少量的包，然後指數型的增長
看上圖，漲到一個ssthresh的初始值就開始加法的方式增大，增大到擁塞的時候，擁塞視窗下降為1，然後重新設定門限值ssthresh，新的門限值為達到擁塞那個點除以2。
快重傳和快恢複機制
傳輸過程中，如果出現丢包，接收方會連續給發送方發送三個确認（網應該還沒堵，堵了就收不到了，有可能快擁塞了），發送方收到後快恢複，擁塞視窗值為新的ssthresh值。
發送視窗的實際上限值
上面流量控制又會變更發送視窗的大小，發送視窗又會由接受視窗的大小來決定，擁塞控制也會調整視窗大小。
發送方的發送視窗的上限值應當取為接收方視窗和擁塞控制視窗這兩個變量中較小的一個，公式：發送視窗上限值 = Min[ rwnd, cwnd ]
以上是對計算機網絡基礎（TCP如何 可靠傳輸 | 流量控制 | 避免網絡擁塞）的粗淺認識
轉載請注明出處：https://blog.csdn.net/qq_36652619