TCP層與UDP層建立在IP之上，以IP層為基礎進行資料傳輸，也就是說TCP與UDP還是通過一個個的IP包來進行傳輸的，雖然IP層只關心一個數據包(基本單位)的傳輸過程，但IP並不能保證資料包能安全的被送達，一旦丟失IP也無能為力，TCP在IP的基礎上加上了對傳輸過程進行流控制，增加了一系列保證傳輸可靠的機制。

1、給每個IP包分配序號sep，同時，保證接收端在接收到序號為seq的IP包時回覆ACK訊息(ACK為其期望收到的下個IP包的序號，即成功收到的序號為seq + 1的包)，如果傳送端在合理的往返延時內未收到回覆的ACK訊息，傳送端將重傳，接收端收到序號一致的包將丟棄，如果傳送端接收到接收端回覆的ACK訊息，將繼續傳送下一IP包，(即超時重傳，捎帶確認機制)這樣就保證了傳輸的有序與可靠

2、TCP提供校驗和函式檢驗資料是否錯誤，傳送接收時都會計算校驗和，同時使用MD5認證對資料加密，以此保證資料正確與合法

3、滑動視窗技術會進行流量控制，不會出現傳送的資料長度大於輸入緩衝的情況，並實現TCP面向流的可靠性

參考部落格：     http://blog.csdn.net/ljlstart/article/details/51340829

TCP套接字內部有I/O緩衝區(每個套接字都有自己獨立的輸入/輸出緩衝)，只要緩衝區不滿，一次全部讀完，或者分幾次讀完是沒有關係的，緩衝區一般大於單個IP包的位元組數，因此會將緩衝區內的資料包分成一個個小包，IP層封裝每一個小包並以IP包的形式向接收方傳送(以接收IP層來說)，接收方IP層解包並將一個個資料包放入接套接字的緩衝區，並組合成一個完整的資料包，一個個的IP包不停的、連續的從傳送方到接收方，就好像流一樣；

以一個個IP包的連續傳送的方式，再加上網路環境複雜，IP包的旅途恐怕不會那麼一帆風順，因此接收端在呼叫read函式讀取緩衝區時可能並不能完全讀取傳送端意圖傳送的所有資料(read函式在讀取套接字緩衝區時預設阻塞，直到接收到資料為止，緩衝中有多少讀多少，將有的讀完則返回，被讀取後的資料將會被清除，正是這些原因，下面使用迴圈的方式呼叫read) (好比你去餐館吃飯，你點了5個菜，一般情況下並不是5盤菜直接就在桌子上等著你吃，而是菜再做好了之後會被一盤一盤的端上來，沒有菜的時候肯定就要等著，而且你也不會吃了一個菜就走吧？肯定要吃夠5個菜才行，不然你幹嘛點5個菜呢？？？)；

也是由於有緩衝區的原因，呼叫write”傳送”(write實際只是寫緩衝區，只要將資料寫入緩衝區便會返回，資料的傳送由TCP保證)一次資料也不意味著資料肯定被立即傳送出去了，有可能後續傳送的資料和之前傳送的資料都在緩衝區後隨後被一起傳送出去了，這就是傳送端的粘包；

同樣也因為緩衝區的原因，如果沒有及時read讀取緩衝區中的資料，後續到達的資料會繼續存放到緩衝區中，也就是兩次傳送端傳送的資料同時存在了接收端的接收緩衝區中，這是接收端的粘包；

還有可能呼叫write向緩衝區填充意圖傳送的資料時，資料填充到一半緩衝區滿了直接傳送了，但實際情況是，這個資料並不是一個完整的資料，剩下的資料只有等下一次傳送的時候再補上，這是不完整的粘包。

這時候應用層協議的作用就凸顯出來了，在多次收發資料時(要是雙方的一次連線就發一次，不管分成幾個IP包，組合後依舊是一個完整的資料包，當傳送完畢後斷開連線時(無論是shutdown或者close，只要觸發EOF)，肯定意味著資料傳輸完成，以EOF為依據迴圈讀取即可，即while(0 != read(客戶端套接字，buf， BUF_SIZE)) )，雙方必須統一口徑，傳送方必須事先明確告訴接收方一個數據是多少位元組，按照約定的長度讀取資料即可；

或採用”資料長度 + 實際資料的”格式傳送資料(每一幀都以此方式傳送資料)，這個”資料長度”的格式是固定寬度的，事先也必須商量好，在讀取資料時，直接讀取固定寬度的”資料長度”獲取資料實際長度，再按照實際長度讀取實際資料即可；

通過這兩種方法，在知道資料長度後，一定要讀取夠資料長度之後再停止讀取，也就是必須以資料長度為判定依據迴圈讀取緩衝區的資料，次數不限，資料個數不多不少，完全讀取，如已經知道了資料長度為N位元組，即應該讀取N個位元組：

Int recvlen = 0, recvcount = 0;
While((N – recvlen) > 0)  
{
         recvcount= read(客戶端套接字, &buf[recvlen], N - recvlen);//讀取到buf[n]元素的位置

//每一次:將緩衝區內有的資料讀取上來，以buf[recvlen]元素為基本位置向後存放
         recvlen+= recvcount;
}

或者。。。。。通過建立多次連線來發送多次資料。。。。。。。

網路環境很複雜，不能避免粘包的情況發生，在接收時按照資料實際寬度拆開即可

個人理解，歡迎大家拍磚

搜了些部落格，掃了一遍，寫得挺好，於是把他們貼上來:

http://www.tuicool.com/articles/vaE3iq

http://blog.csdn.net/zhangxinrun/article/details/6721427

http://www.cnblogs.com/QG-whz/p/5537447.html

http://blog.csdn.net/my_sky2012/article/details/49486539