【轉】關于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，是以最好能

每次傳輸接近這個數的資料量，這特别适合于視訊，音頻等大塊資料的發送，同時，通過減少握手來保證流媒體的實時性）