tcp:算法
TCP 是面向鏈接的,而且是一種可靠的協議,在基於 TCP 進行通訊時,通訊雙方須要先創建一個 TCP 鏈接,創建鏈接須要通過三次握手,握手成功才能夠進行通訊tcp
一、基於鏈接的,可靠性高優化
二、有鏈接過程(3次握手過程),會有延時,實時性較差,.net
三、傳輸相同的數據時,TCP首部開銷20字節;UDP的首部開銷小,只有8個字節,TCP報頭比UDP複雜,故實際包含的用戶數據較少。TCP無丟包,而UDP有丟包,故TCP的開銷大,UDP開銷較小。cdn
四、每一條TCP鏈接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通訊視頻
udp:blog
是一種面向無鏈接,且不可靠的協議,在通訊過程當中,它並不像 TCP 那樣須要先創建一個鏈接,只要(目的地址,端口號,源地址,端口號)肯定了,就能夠直接發送信息報文,而且不須要確保服務端必定能收到或收到完整的數據。它僅僅提供了校驗和機制來保障一個報文是否完整,若校驗失敗,則直接丟棄報文,不作任何處理。排序
應用場景:進程
協議對比:get
粘包的緣由:
(1)發送方引發的粘包是由TCP協議自己形成的,TCP爲提升傳輸效率,發送方每每要收集到足夠多的數據後才發送一包數據。若連續幾回發送的數據都不多,一般TCP會根據優化算法把這些數據合成一包後一次發送出去,這樣接收方就收到了粘包數據。
(2)接收方引發的粘包是因爲接收方用戶進程不及時接收數據,從而致使粘包現象。這是由於接收方先把收到的數據放在系統接收緩衝區,用戶進程從該緩衝區取數據,若下一包數據到達時前一包數據還沒有被用戶進程取走,則下一包數據放到系統接收緩衝區時就接到前一包數據以後,而用戶進程根據預先設定的緩衝區大小從系統接收緩衝區取數據,這樣就一次取到了多包數據。
粘包的解決辦法————封包:
封包就是給一段數據加上包頭,這樣一來數據包就分爲包頭和包體兩部份內容了。包頭其實上是個大小固定的結構體,其中有個結構體成員變量表示包體的長度,這是個很重要的變量,其餘的結構體成員可根據須要本身定義。根據包頭長度固定以及包頭中含有包體長度的變量就能正確的拆分出一個完整的數據包。
拆包: 根據封包的包頭規則解析出每個完整的數據包,而後作相應的業務處理。
分包: 分包發送(封裝包的首部,包括包的大小、類型、序號、數量等)
一、在客戶端將你要發送的內容(文件什麼的均可以)分塊,每塊內容進行編號,而後發送;
二、服務端在接收到你的分塊數據之後,根據你的客戶端數據類容的編號從新組裝;
三、通常咱們在發送數據的時候,儘可能採用比較小的數據塊的方式(個人都沒有超過1024的),數據塊太大的話容易出現發送和接收的數據時間長,匹配出問題。
組包:
假設一個端口只接收固定一個對方數據源,這樣,收到一個數據包放到緩衝裏,而後在緩衝里根據幀的序號排序(每一幀的大序號是相同的,本身能夠給每個小片加上小序號,包頭裏能夠加上本次數據幀一共分多少片,收到一片就統計一下,判斷是否收齊)。 當收齊後,這個幀去掉包頭回調給上層。當在必定時間內該幀數據尚未收齊,就說明傳輸過程有丟包了,把已收到的都丟掉就能夠。 當上層的應該收到回調的數據後,能夠進行解碼播放。不過在解碼以前,先判斷一下幀序列是否連續。作爲視頻數據,
若是中間有缺乏的,就把這一序列都丟掉,直到下一個I幀。每一個幀的序號,最好收發之間協商好,在發送的時候帶上。