滑動視窗和流量控制
- 滑動視窗
-
- 沒有滑動視窗
- 帶滑動視窗
- 滑動視窗下三種丢包情況
- 擁塞控制
- 流量控制
-
- 總結
這三種機制是在可靠性的前提下，進一步的提高傳輸效率
滑動視窗
沒有滑動視窗
傳輸過程，發一個收到一個，是串行過程，每次傳輸資料都要對應一個等待時間
傳輸N份資料就要等待N次應答時間
總的傳輸時間=N份資料傳輸時間+N份應答傳輸時間
帶滑動視窗
滑動視窗是發送方的概念.接收方隻有一一個接受緩沖區,沒有"滑動視窗大小"這樣的概念.
發送方的視窗大小太大,是可能導緻問題的.但是這個事情不是由連接配接管理協商出來的而是靠擁塞控制+流量控制确定的
像上述一發一收的方式性能較低，那麼我們一次發送多條資料，就可以大大的提高性能 （其實本質是将多個段的等待時間重疊在一起了）
滑動視窗是批量傳輸資料
總的傳輸時間=N份資料傳輸時間重疊成了1份時間，N份應答傳輸時間，重疊成了一份時間
每個視窗具體是怎麼滑動工作的呢？
視窗隻有一個，是一格一格往後滑的，每當資料進入到視窗裡面就立刻被發送了
視窗:不等待ACK的情況下，批量發送的最大資料量,就叫“視窗大小"
滑動：視窗範圍就是表示目前哪些資料在等待ACK，随着一個ACK到達就立刻發送下一個資料，等待的資料包的範圍就在逐漸滑動
滑動視窗下三種丢包情況
1、資料包抵達，ACK丢了
比如上圖的視窗大小就是6000，如果主機B一直收不到1001的ACK是以視窗就一直不動等待最後一個資料的ACK，直到最後收到了6001的ACK，視窗就會預設之前的資料都已經收到，然後發送方就會立刻傳輸6001-12001的資料，這就相當于一下子就往後話滑了好幾步。
我們上面展示的是1-6000，就算最後6001這個資料的ACK丢了，那6001後面還有其他的資料可以參考，即使到了最後一個資料發完了，還有一個FIN作為接收響應
2、資料包丢了/主機B接收順序反了
如果一直發送不出去，就會逾時連接配接，重置連接配接。
如果資料包丢了就會進行重傳，此處重傳隻是重傳丢了的資料,其他資料不需要額外重傳這種叫做"快速重傳" (搭配滑動視窗下的逾時重傳)
如果中間兩次丢包
滑動視窗是發送方的概念，接受緩沖區就是一一個固定大小的記憶體空間(空間大小是固定,可以通過核心的參數配置)如果接受緩沖區滿了就不會繼續傳輸了(流量控制機制)
如果是主機接收順序反了，後發先至
擁塞控制和流量控制共同決定發送方的視窗大小的.
擁塞控制
擁塞控制是考慮網絡傳輸路徑上的擁堵程度，網際網路類似一個交通網，可能某個環節就會擁堵。
就算接收方處理能力很強，但是如果傳輸路徑.上擁堵了,此時發送方發的快也沒用，接收方的處理能力，是好衡量. (接受緩沖區空餘空間大小)但是傳輸路徑太複雜,不好衡量。
擁塞控制由于不好衡量傳輸路徑的擁堵情況隻能通過"反複試探"的方式，逐漸試探出應該用多大的視窗大小。
為啥要動态變化?
網絡的擁堵情況也是瞬息萬變的.要随時根據網絡的實際情況進行動态調整.
為啥曲線設定成這樣,都是從數學角度求出的一個最優解
流量控制
視窗大小不能無限大，如果視窗過大，傳輸的速率快，那樣接收方就可能處理不過來，接收方收到資料後是需要一定的時間處理的。
流量控制就是根據接收方的處理能力（通過接收緩沖區的“剩餘空間大小”來決定發送方的速率）來反向制衡發送方的發送速率（視窗大小）
流量控制可以用生産者消費者模型
如果中間有缺漏
總結
流量控制本質上,是根據接收方的處理能力來制約發送方的發送速率，根據接受緩沖區的剩餘空間大小，來制約發送方的滑動視窗大小，通過TCP報頭中的"視窗大小字段"來反映給發送方的。流量控制會影響到發送方的視窗大小,但是不是決定因素
可以通過生産者消費者模型了解，發送方是生産者,接收方的應用程式是消費者.
滑動視窗大小就和消費者應用程式的消費速度也是有關系的，如果剩餘空間大,說明消費速度就挺快的，發送速率就可以高一些，反之就發送速率低一些就行了.
如果視窗大小為0,發送方會暫停發送,但是會定時發送一個探測封包. 如果發送方有空間了,就會立刻繼續傳輸.