我們知道tcp有確認應答機制，對每乙個傳送的資料段，都要給乙個ack確認應答，收到ack後再傳送ack中攜帶的序列號。這樣保證了可靠傳輸。但是有時資料往返的時間比較長時，效能就比較差了。
既然這樣一發一收的方式效能較低，那麼我們一次傳送多條資料，就可以大大提公升效能。
tcp中提出了滑動視窗這個機制。這個機制是什麼？我們看看…
視窗大小是指無需等待確認而可以繼續傳送資料的最大值，上面的圖的視窗大小是 4000 位元組（4個段）
傳送前4個段時，無需ack，直接傳送
收到第一ack後，滑動視窗向後移動，繼續傳送第五個段的資料
作業系統核心為了維護這個滑動視窗，需要開闢 傳送快取區來記錄當前還有哪些資料沒有應答，只有應答了才會把該資料從緩衝區中刪除掉
視窗越大，則網路的吞吐率就越高
我們知道在複雜的網路環境下，有可能會有丟包的情況：
tcp中有兩種情況：
上面的圖中，接受方傳送的ack（下乙個是2001）丟失了。但是傳送方還接受到了ack（下乙個是3001），說明1001 - 2000 該段資料報已經接收到了。資料已經傳輸到，不用理會。
2.如果資料報丟失，會怎麼辦？（快速重傳）
當某一段報文丟失了，圖中（1001 - 2000）資料段丟失了，接受方沒有接收到該資料段，則會一直的給傳送方傳送ack（下乙個是1001），如果傳送端主機連續收到同樣乙個（下乙個1001），就會將對應的資料（1001 - 2000）重新傳送。
這時候如果接收端收到1001之後，再次返回的就是ack（8001）了。之前的（2001 - 8000）都接收到了接受快取區。
這種機制被稱為「高速重發機制」（快速重傳）
TCP協議滑動視窗與確認重傳機制？
位元組流傳輸狀態分類與滑動視窗的概念 tcp協議使用以位元組為單位的滑動視窗協議，來控制位元組流的傳送 接收 確認與重傳過程。接收視窗的大小由接收端根據快取剩餘空間的大小，以及應用程序讀取資料的速度來決定。傳送視窗的大小取決於接收視窗的大小。傳送視窗和接收視窗 傳送視窗等於第二類和第三類的位元組數之...
TCP滑動視窗機制
tcp協議在能夠傳送資料之前就建立起了 連線 要實現這個連線，啟動tcp連線的那一方首先將傳送乙個syn資料報。這只是乙個不包含資料的資料報，然後，開啟syn標記。如果另一方同時在它收到syn標記的埠通話，它將發回乙個syn ack syn和ack標誌位都被開啟，並將ack 確認 編 號字段設定為剛...
TCP滑動視窗機制
tcp協議在能夠傳送資料之前就建立起了 連線 要實現這個連線，啟動tcp連線的那一方首先將傳送乙個syn資料報。這只是乙個不包含資料的資料報，然後，開啟syn標記。如果另一方同時在它收到syn標記的埠通話，它將發回乙個syn ack syn和ack標誌位都被開啟，並將ack 確認 編 號字段設定為剛...