在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
TCP和UDP的 保護訊息邊界」
在socket網路程式中，tcp和udp分別是面向連線和非面向連線的。因此tcp的socket程式設計，收發兩端 客戶端和伺服器端 都要有一一成對的socket，因此，傳送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法 nagle演算法 將多次間隔較小且資料量小的資料，合併成乙個大的資...
TCP協議的無訊息邊界問題
使用tcp協議編寫應用程式時，需要考慮乙個問題 tcp協議是無訊息邊界的，即不能保證來自單個send方法的資料能被單個receive方法讀取。eg 第一次傳送 abcdefg 第二次傳送 123456 接收方接收資料時,可能會出現以下情況 第一次接收 abcdefg123456 也可能出現 第一次接...
TCP和UDP的區別
tcp transimission control protocol 傳輸控制協議 和udp user datagram protocol 是傳輸層的兩種實現版本！它們之間提供基本的服務又各有所長。因此，根據對特定服務質量的要求，應用層軟體單元可以選擇通過傳輸層的tcp版本或者udp版本來傳輸資料。...