iT邦幫忙

DAY 3
1

30 天學會 Web 前端效能優化系列 第 3

[30 天學會 Web 前端效能優化] 3. TCP 的確認機制

上一篇提到傳輸層,這一篇讓我們提一下 TCP 的確認機制。

TCP 有一項特點,也就是發送端在傳送下一個封包前,會先等待接受端的「確認」回應,而不是一直傳送封包,發生什麼事都不管。

TCP 的確認機制是這樣運作的:發送端送出封包後,會設定一個計時器(timer),假設接收端沒有在預估時間內傳送確認(Acknowledgement)訊息給發送端的話,發送端便會認為此封包可能於傳送途中遺失而重新發送封包並且重設 timer 。

假設接收端有收到封包且在預估時間內將確認訊息傳送到發送端的話,發送端就會繼續傳送下一個封包。

聰明的你或許會想到:「每次都要等接收到確認訊息才能繼續往下傳封包,這樣不是很浪費時間嗎?」沒錯,「滑動視窗」(Sliding Window)這個概念就是用來解決這個困境的。

TCP 傳送資料的最小單位為 Byte ,在將資料傳送到目的端之前,會先將資料編碼成一個一個 Byte ,我們將這些 Byte 構成的集合稱作 Byte Stream,TCP 會將產生的 Byte Stream 放入 Output Buffer 中,再從這個 Buffer 送資料出去,而接收端也有 Input Buffer 負責接收送來的資料。

至於一次要送出幾個封包,就是透過「滑動視窗」這個概念來控制的,假設視窗大小(Window Size)為3,那麼傳送端就會一次送出三個封包(實際上用封包作為單位是不正確的,以 Byte 大小為單位才正確,不過為了方便說明,就將就一下吧),假設接收端收到了前兩個封包,它就會往下移動二格並且傳送確認訊息告知傳送端前兩個封包已收到,發送端收到確認訊息後便會將滑動視窗也往下移動兩格並繼續將接下來的兩個封包送出去。

透過上述步驟的循環,TCP 便達到了所謂的「可靠性」,這項特性增進了資料傳送的安全,確保收到的資料不是破碎的,不過連帶也犧牲了許多時間。


上一篇
[30 天學會 Web 前端效能優化] 2. 傳輸層簡述
下一篇
[30 天學會 Web 前端效能優化] 4. TCP 三向交握
系列文
30 天學會 Web 前端效能優化30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
卡斯
iT邦研究生 1 級 ‧ 2014-09-18 13:17:59

ACK 確認機制

我要留言

立即登入留言