有關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，因此最好能 每次傳輸接近這個數的數據量，這特別適合於視頻，音頻等大塊數據 的發送，同時，通過減少握手來保證流媒體的實時性