push
慢啟動
隔乙個報文段確認」的策略實際就是因為 delayed ack，同時接收到兩個待確認的ack包時，就立即傳送確認包。
滑動視窗例項
解決了快的傳送方-》慢的接收方
隨後從接收方傳來另外兩個 ack，它們確認了最後的 4096位元組的資料（從4097到8192位元組）和fin（標號為8192）
滑動視窗協議：
視窗大小起始於確認序號字段。
當接收方確認資料後，這個滑動視窗不時地向右移動。
視窗左右邊沿的運動現象的三個術語
右邊沿向右靠近----視窗張開
右邊沿向左靠近----視窗收縮
如果左邊沿到達右邊沿，則稱其為乙個零視窗，此時傳送方不能夠傳送任何資料
對應上圖的滑動視窗協議的動態性
視窗大小
由接收方提供的視窗的大小通常可以由接收程序控制，這將影響 tcp的效能
push標誌
慢啟動
工作原理
擁塞視窗是傳送方使用的流量控制
通告視窗則是接收方使用的流量控制
capacity(bit) = bandwidth(b/s) * round-trip(s)
容量 = 頻寬 * 延時
**線每193bit 有1個作為 幀同步
因此原始位元率 1544000 b/s --》 實際位元率 1544000/193=8000,1544000-8000=1536000 b/s
計算滑動視窗大小：
有人抱怨說美國和日本之間的乙個 128 ms時延、速率為256 000 b/s的鏈
路吞吐量為120 000 b/s（利用率為47 %），而當鏈路通過衛星時其吞吐量則為33 000 b/s（利用
率為13％）。試問在這兩種情況下視窗大小各為多少（假定衛星鏈路的時延為 500 ms）？衛星
鏈路的視窗大小應該如何調整？
1.吞吐量12000 b/s * 延時128ms =15360 b / 8 =1920 bit
2.鏈路通過衛星
吞吐量33000 b/s * 延時500ms =16500 b /8 = 2062 bit
TCP滑動視窗
目前建立在tcp協議上的網路協議特別多，有telnet，ssh，有ftp，有http等等。這些協議又可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種...
TCP滑動視窗
假設a和b之間新建立了一條tcp連線。裝置a需要傳送一長串資料流，但裝置b無法一次全部接收，所以它限制裝置a每次傳送分段指定數量的位元組數，直到分段中已傳送的位元組數得到確認。之後，裝置a可以繼續傳送更多位元組。每乙個裝置都對傳送，接收及確認資料進行追蹤。tcpbuffer中資料可以分為以下四類 1...
TCP滑動視窗
tcp滑動視窗是用來控制流量的，避免擁塞的發生。滑動視窗又包括接收端滑動視窗和傳送端滑動視窗，下面我們簡單分析一下。上圖顯示的是接收緩衝區，其中接收視窗也在其中。接收視窗的大小是8，即4 12，此時由a可知，接收端下乙個預計接收序列號4，當接收端接收到4 7之後，滑動視窗就會右移，此時接收端預計接收...