1. 程式人生 > >運輸層—滑動視窗協議

運輸層—滑動視窗協議

滑動視窗協議是TCP協議的精髓所在,本文將要對滑動視窗協議進行詳細說明

上面的圖(A的傳送視窗)中可以看見,該圖大致分為了三個部分,已經發送並且收到了確認的序號,傳送視窗,不允許傳送的這三個部分。傳送視窗還可以細分為傳送了還沒有收到確認的以及允許傳送但是還未傳送的。在這幾個部分中,傳送視窗通常又稱為通知視窗,允許傳送但是還未傳送的可以稱為可用視窗或者是有效視窗。
從上面的圖(B的接受視窗)中可以看見,該圖也可以像傳送視窗一樣分為三個部分,在B的接受視窗中,我們可以發現31號沒有接收到,但是32和33號已經接收到了,這時候如果需要向A傳送確認分組的話,那麼序號只能是31(即期望收到的序號),而不能是32或者是33,而對於沒有按序號收到的32和33,將要暫時存在接收視窗中,直到按序號的位元組都收到了之後,才進行一個確認。如果A的傳送視窗部分全部變成了已經發送還未收到確認的狀態,那麼這時就不能再發送新的分組了,A在經過一段時間之後就重傳資料(通過超時計時器),直到收到了B的確認為止。
介紹完傳送視窗和接收視窗之後,我們需要了解視窗和快取之間的關係。 1、傳送方的快取是用來存放: (1)允許傳送還未傳送的資料 (2)已經發送但是還沒有收到確認的資料 2、接收方的快取是用來存放: (1)按序到達,但是還沒有被接受的資料 (2)未按序到達的資料 同時,我們應該明確的是傳送視窗是通過接收視窗進行設定的,但是在同一時刻,傳送視窗的大小和接收視窗的大小不一定是一樣大的。可能是網路延遲,或者是傳送視窗經過了擁塞控制。滑動視窗協議將沒有按序號的資料的處理一般是先存在接受視窗中,到缺少的位元組收到之後,再進行下一步正常操作。接收方可以在合適的時候進行傳送確認操作,例如接收方要傳送資料的時候就可以將確認分組順帶捎上。但是實際上捎帶這種操作並不經常發生。