【轉】關於TCP和UDP協議消息保護邊界的介紹

在 socket網絡程序中，TCP和UDP分別是面向鏈接和非面向鏈接的。所以TCP的socket編程，收發兩端（客戶端和服務器端）都要有一一成對的 socket，所以，發送端爲了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將屢次間隔較小且數據量小的數據，合併成一個大的數據塊，而後進行封包。這樣，接收端，就難於分辨出來了，必須提供科學的拆包機制。
對於UDP，不會使用塊的合併優化算法，這樣，實際上目前認爲，是因爲UDP支持的是一對多的模式，因此接收端的skbuff(套接字緩衝區）採用了鏈式結構來記錄每個到達的UDP包，在每一個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對於接收端來講，就容易進行區分處理了。

保護消息邊界和流

那麼什麼是保護消息邊界和流呢?

保護消息邊界，就是指傳輸協議把數據看成一條獨立的消息在網上傳輸,接收端只能接收獨立的消息.也就是說存在保護消息邊界,接收
端一次只能接收發送端發出的一個數據包.而面向流則是指無保護消息保護邊界的,若是發送端連續發送數據,接收端有可能在一次接收動做中,會接收兩個或者更多的數據包.

咱們舉個例子來講,例如,咱們連續發送三個數據包,大小分別是2k,4k , 8k,這三個數據包,都已經到達了接收端的網絡堆棧中,若是使用UDP協議,無論咱們使用多大的接收緩衝區去接收數據,咱們必須有三次接收動做,纔可以把全部的數據包接收完.而使用TCP協議,咱們只要把接收的緩衝區大小設置在14k以上,咱們就可以一次把全部的數據包接收下來.只須要有一次接收動做.

這就是由於UDP協議的保護消息邊界使得每個消息都是獨立的.而流傳輸,卻把數據看成一串數據流,他不認爲數據是一個一個的消息.

因此有不少人在使用tcp協議通信的時候,並不清楚tcp是基於流的傳輸,當連續發送數據的時候,他們時常會認識tcp會丟包.其實否則,
由於當他們使用的緩衝區足夠大時,他們有可能會一次接收到兩個甚至更多的數據包,而不少人每每會忽視這一點,只解析檢查了第一個
數據包,而已經接收的其餘數據包卻被忽略了.因此你們若是要做這類的網絡編程的時候,必需要注意這一點.

結論：
根據以上所說，能夠這樣理解，TCP爲了保證可靠傳輸，儘可能減小額外開銷（每次發包都要驗證），所以採用了流式傳輸，面向流的傳輸，
相對於面向消息的傳輸，能夠減小發送包的數量。從而減小了額外開銷。可是，對於數據傳輸頻繁的程序來說，使用TCP可能會容易粘包。
固然，對接收端的程序來說，若是機器負荷很重，也會在接收緩衝裏粘包。這樣，就須要接收端額外拆包，增長了工做量。所以，這個特別適合的是數據要求可靠傳輸，可是不須要太頻繁傳輸的場合（兩次操做間隔100ms，具體是由TCP等待發送間隔決定的，取決於內核中的socket的寫法）

而UDP，因爲面向的是消息傳輸，它把全部接收到的消息都掛接到緩衝區的接受隊列中，所以，它對於數據的提取分離就更加方便，可是，
它沒有粘包機制，所以，當發送數據量較小的時候，就會發生數據包有效載荷較小的狀況，也會增長屢次發送的系統發送開銷（系統調用，
寫硬件等）和接收開銷。所以，應該最好設置一個比較合適的數據包的包長，來進行UDP數據的發送。（UDP最大載荷爲1472，所以最好能
每次傳輸接近這個數的數據量，這特別適合於視頻，音頻等大塊數據的發送，同時，經過減小握手來保證流媒體的實時性）