iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 21
0
Software Development

菜雞前端邁入網頁即時通訊(WebRTC)之旅系列 第 21

[知識篇]網路通訊協定 - TCP & UDP

了解日常中,最為常見得兩種傳輸層協議,他們提供了應用間傳遞資料更好的控制,包括建立及取消傳送還有流程控制/錯誤處理...等,借此機會,了解TCP與UDP間的功用及差異。

何謂TCP

Transmission Control Protocol(TCP)為傳輸控制協議,主要目的是可確保資料通訊的正確傳輸,由以下幾點來達到可靠性傳輸:

三向交握

Three-Way Handshake(稱三路握手)是TCP建立傳送的重點機制,將以下面圖示來闡述:

![wiki](https://ithelp.ithome.com.tw/upload/images/20201004/20129521tO4K8jgHck.png

圖片擷取自wiki

client端向server端發送請求前,會先經過幾個程序:

  1. 當client想對server連線時,就必須主動向server傳送一個要求連線的封包。

  2. 當server接收並確認這個封包後,也會回傳一個相對應的封包,給client確認,並且開始等待client的回應。

  3. 當client收到server回應的封包後,就能確認之前主動發送的封包有被正確接收了,如果client也同意與server建立連線,就會再回傳一個確認封包告知server。

  4. 當server接收到也確認過後,即完成三向交握,並進入了連接建立狀態。

其實這樣的動作在日常也很常發生,像是與朋友使用網路電話時:

  1. 你一定會先確認對方是否有聽到你的聲音?
  2. 對方回覆後,也會反問你是否有聽到他的聲音?
  3. 你回覆後,雙方就能確認彼此都有接收到音訊,並開始聊天~~

可靠傳輸

建立連線後,封包再進行傳輸時都會加上序號,透過序號能夠標示出其順序,從而另一端接收資料時可以重建順序,不怕中間有丟包或亂序的問題發生,

  • 完整性:接收端確認封包後會將確認過的封包序號回傳給發送端,確認封包傳送完畢。
  • 逾時/重傳處理: 當發送端發送封包時,就會啟動重傳定時器,在一定時間內如果沒有收到接收端的回應時,就會重傳該封包,並重置這個重傳定時器。
  • 順序性:避免傳輸過程中有丟包或亂序的問題發生,如果發生逾時重傳等現象時,有可能發生重複接收到同樣封包的可能,這時序號也能作為過濾重複封包的機制。

窗口控制

上述說描述的傳輸方式,如果都要等待每次傳輸的回應後才能進行下一次,那傳輸效率肯定很差,
為此,有了窗口的概念,接收端能夠定義窗口大小,也就是一次能接收更多的封包,進行同時多段的封包傳輸/確認,大幅提升傳輸效率。

何謂UDP

User Datagram Protocol(UDP),用戶資料流協議,UDP 與 TCP 不一樣, UDP 不提供可靠的傳輸模式,相較於TCP的三項交握機制,UDP在傳送的過程中,接收端在接收到封包後並不會回覆確認接收給發送端,也因此封包沒有像TCP管理得這麼嚴密。

但也因為如此,少了一些確認機制,不僅表頭資料會較少,傳輸效率也比較好。因此UDP比較適合需要即時反應的應用,如這次主題的即時通訊應用等,換句話說,當不考慮連線要求、連線終止或流量控制等特性,且資料正確性沒有佔很重的情況,適合使用UDP。

總結

兩者都有各自的優缺點,也因此能夠視情況互相搭配使用。

  • TCP: 可靠性傳輸,能夠確保資料傳輸的完整性,但相對的必定會造成傳輸效率不彰。
  • UDP: 不可靠性傳輸,傳輸效率較高,但無法確保資料傳輸的完整性,如果要彌補這項缺點就必須在應用層上加上確認的機制來達到可靠性。

當然這其中還有很多機制在,但這邊不多加闡述,主要在理解其中概念與用途~~

參考

新手入門,如有錯誤,歡迎指正~~~

系列文章同步更新於部落格


上一篇
[知識篇] 網際網路協議 - TCP/IP
下一篇
[知識篇]網路通訊協定 - WebRTC protocol stack
系列文
菜雞前端邁入網頁即時通訊(WebRTC)之旅30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言