TCP粘包问题详解
TCP粘包問題詳解
文章目錄
- TCP粘包問題詳解
- 一、引言
- 二、TCP協議簡介
- 三、保護消息邊界和流
- 1.那么什么是保護消息邊界和流呢?
- 2.TCP和UDP
- 四、粘包問題分析與對策
- 1.引入
- 2.什么時候需要考慮粘包問題
- 3.粘包出現原因
- 4.為了避免粘包現象，可采取以下幾種措施：
- 5.TCP無保護消息邊界的解決
- 6、針對3種方案摸擬實現
- 五、網絡通訊的封包和拆包
- 1.為什么基于TCP的通訊程序需要進行封包和拆包
- 2.怎樣封包和拆包
一、引言
- 在socket網絡程序中，TCP和UDP分別是面向連接和非面向連接的。
- 因此TCP的socket編程，收發兩端（客戶端和服務器端）都要有成對的socket
- 因此，發送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將多次間隔較小、數據量小的數據，合并成一個大的數據塊，然后進行封包。
- 這樣，接收端，就難于分辨出來了，必須提供科學的拆包機制。
- 對于UDP，不會使用塊的合并優化算法，這樣，實際上目前認為，是由于UDP支持的是一對多的模式
- 所以接收端的skbuff(套接字緩沖區）采用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了消息頭（消息來源地址，端口等信息）
- 這樣，對于接收端來說，就容易進行區分處理了。所以UDP不會出現粘包問題。
- 長連接
Client方與Server方先建立通訊連接，連接建立后 不斷開， 然后再進行報文發送和接收。 - 短連接
Client方與Server每進行一次報文收發交易時才進行通訊連接，交易完畢后立即斷開連接。此種方式常用于一點對多點通訊，比如多個Client連接一個Server.
二、TCP協議簡介
- TCP是一個面向連接的傳輸層協議，雖然TCP不屬于ISO制定的協議集，但由于其在商業界和工業界的成功應用，它已成為事實上的網絡標準，廣泛應用于各種網絡主機間的通信。
- 作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證信息有序無誤的傳輸。
- 它除了提供基本的數據傳輸功能外，還為保證可靠性采用了數據編號、校驗和計算、數據確認等一系列措施。
- 它對傳送的每個數據字節都進行編號，并請求接收方回傳確認信息（ACK），發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。
- 數據編號使接收方能夠處理數據的失序和重復問題。
- 數據誤碼問題通過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，并要求發送方重傳。
- 流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網絡擁塞惡性循環。
- TCP采用可變窗口進行流量控制，由接收方控制發送方發送的數據量。
TCP為用戶提供了高可靠性的網絡傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才采用TCP，而普通數據的傳輸一般采用高效率的UDP。
三、保護消息邊界和流
1.那么什么是保護消息邊界和流呢?
- 保護消息邊界，就是指傳輸協議把數據當作一條獨立的消息在網上傳輸，接收端只能接收獨立的消息。 也就是說存在保護消息邊界，接收端一次只能接收發送端發出的一個數據包。
- 而面向流則是指無保護消息保護邊界的，如果發送端連續發送數據，接收端有可能在一次接收動作中，會接收兩個或者更多的數據包。
例如，我們連續發送三個數據包，大小分別是2k，4k ，8k,
這三個數據包，都已經到達了接收端的網絡堆棧中，
如果使用UDP協議，不管我們使用多大的接收緩沖區去接收數據，我們必須有三次接收動作，才能夠把所有的數據包接收完.
而使用TCP協議，我們只要把接收的緩沖區大小設置在14k以上，我們就能夠一次把所有的數據包接收下來，只需要有一次接收動作。
- 這就是因為UDP協議的保護消息邊界使得每一個消息都是獨立的。
- 而流傳輸卻把數據當作一串數據流，他不認為數據是一個一個的消息。
- 所以有很多人在使用tcp協議通訊的時候，并不清楚tcp是基于流的傳輸，當連續發送數據的時候，他們時常會認識tcp會丟包。
- 其實不然，因為當他們使用的緩沖區足夠大時，他們有可能會一次接收到兩個甚至更多的數據包，而很多人往往會忽視這一點，只解析檢查了第一個數據包，而已經接收的其他數據包卻被忽略了。
2.TCP和UDP
（1）TCP：
- TCP為了保證可靠傳輸，盡量減少額外開銷（每次發包都要驗證），因此采用了流式傳輸
- 面向流的傳輸，相對于面向消息的傳輸，可以減少發送包的數量，從而減少了額外開銷。
- 但是，對于數據傳輸頻繁的程序來講，使用TCP可能會容易粘包。當然，對接收端的程序來講，如果機器負荷很重，也會在接收緩沖里粘包。
- 這樣，就需要接收端額外拆包，增加了工作量。因此，這個特別適合的是數據要求可靠傳輸，但是不需要太頻繁傳輸的場合（兩次操作間隔100ms，具體是由TCP等待發送間隔決定的，取決于內核中的socket的寫法）
（2）UDP：
- UDP由于面向的是消息傳輸，它把所有接收到的消息都掛接到緩沖區的接受隊列中，因此，它對于數據的提取分離就更加方便，但是，它沒有粘包機制
- 因此，當發送數據量較小的時候，就會發生數據包有效載荷較小的情況，也會增加多次發送的系統發送開銷（系統調用，寫硬件等）和接收開銷。
- 因此，應該最好設置一個比較合適的數據包的包長，來進行UDP數據的發送。（UDP最大載荷為1472，因此最好能每次傳輸接近這個數的數據量，這特別適合于視頻，音頻等大塊數據的發送，同時，通過減少握手來保證流媒體的實時性）
四、粘包問題分析與對策
1.引入
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。
出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。
2.什么時候需要考慮粘包問題
- 1.如果利用tcp每次發送數據，就與對方建立連接，然后雙方發送完一段數據后，就關閉連接，這樣就不會出現粘包問題（因為只有一種包結構,類似于http協議）。
- 關閉連接主要是要雙方都發送close連接。
如：A需要發送一段字符串給B，那么A與B建立連接，
然后發送雙方都默認好的協議字符如"hello give me sth abouryourself"，
然后B收到報文后，就將緩沖區數據接收，然后關閉連接，
這樣粘包問題不用考慮到，因為大家都知道是發送一段字符。
- 2.如果發送數據無結構，如文件傳輸，這樣發送方只管發送，接收方只管接收存儲就ok，也不用考慮粘包
- 3.如果雙方建立連接，需要在連接后一段時間內發送不同結構數據，就需要考慮粘包問題
如連接后，有好幾種結構：
1)“hellogive me sth abour yourself”
2)“Don’tgive me sth abour yourself”
那這樣的話，如果發送方連續發送這個兩個包出去，接收方一次接收可能會是
“hellogive me sth abour
yourselfDon’t give me sth abour yourself”
這樣接收方就傻了，到底是要干嘛？不知道，因為協議沒有規定這么詭異的字符串
所以要處理把它分包，怎么分也需要雙方組織一個比較好的包結構，所以一般可能會在頭加一個數據長度之類的包，以確保接收。
3.粘包出現原因
- 簡單得說，在流傳輸中出現，UDP不會出現粘包，因為它有消息邊界
- 1.發送端需要等緩沖區滿才發送出去，造成粘包
- 2.接收方不及時接收緩沖區的包，造成多個包接收
具體點： - （1）發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。
- （2）接收方引起的粘包是由于接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據。
- (3)應用層調用write方法，將應用層的緩沖區中的數據拷貝到套接字的發送緩沖區。而發送緩沖區有一個SO_SNDBUF的限制，如果應用層的緩沖區數據大小大于套接字發送緩沖區的大小，則數據需要進行多次的發送。
- (4)TCP所傳輸的報文段有MSS的限制，如果套接字緩沖區的大小大于MSS，也會導致消息的分割發送。
- (5)由于鏈路層最大發送單元MTU，在IP層會進行數據的分片。
粘包情況有兩種，一種是粘在一起的包都是完整的數據包，另一種情況是粘在一起的包有不完整的包。
- 不是所有的粘包現象都需要處理，若傳輸的數據為不帶結構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶結構的數據，這時就需要做分包處理。
- 在處理定長結構數據的粘包問題時，分包算法比較簡單；
- 在處理不定長結構數據的粘包問題時，分包算法就比較復雜。特別是粘在一起的包有不完整的包的粘包情況，由于一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。
4.為了避免粘包現象，可采取以下幾種措施：
- （1）對于發送方引起的粘包現象，用戶可通過編程設置來避免，TCP提供了強制數據立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；
- （2）對于接收方引起的粘包，則可通過優化程序設計、精簡接收進程工作量、提高接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；
- （3）由接收方控制，將一包數據按結構字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。
以上提到的三種措施，都有其不足之處。
- （1）第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網絡發送效率，影響應用程序的性能，一般不建議使用。
- （2）第二種方法只能減少出現粘包的可能性，但并不能完全避免粘包，當發送頻率較高時，或由于網絡突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。
- （3）第三種方法雖然避免了粘包，但應用程序的效率較低，對實時應用的場合不適合。
一種比較周全的對策是：接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。
5.TCP無保護消息邊界的解決
針對這個問題，一般有3種解決方案：
- (1)發送固定長度的消息,如果每個消息的大小都是一樣的，那么在接收對等方只要累計接收數據，直到數據等于一個定長的數值就將它作為一個消息
- (2)把消息的大小長度與消息一塊發送(struct),包頭加上包體長度。包頭是定長的4個字節，說明了包體的長度。接收對等方先接收包體長度，依據包體長度來接收包體。
- (3)使用特殊標記來區分消息間隔(\r\n),FTP協議正是這么做的。但問題在于如果數據正文中也含有\r\n，則會誤判為消息的邊界。
- (4)使用更加復雜的應用層協議
6、針對3種方案摸擬實現
- 粘包解決方案一：使用定長包
這里需要封裝兩個函數：
ssize_t readn(int fd, void *buf, size_t count) ssize_t writen(int fd, void *buf, size_t count)這兩個函數的參數列表和返回值與read、write一致。它們的作用的讀取/寫入count個字節后再返回。其實現如下：
ssize_t readn(int fd, void *buf, size_t count) {int left = count ; //剩下的字節char * ptr = (char*)buf ;while(left>0){int readBytes = read(fd,ptr,left);if(readBytes< 0)//read函數小于0有兩種情況：1中斷 2出錯{if(errno == EINTR)//讀被中斷{continue;}return -1;}if(readBytes == 0)//讀到了EOF{//對方關閉呀printf("peer close\n");return count - left;}left -= readBytes;ptr += readBytes ;}return count ; }/* writen 函數 寫入count字節的數據 */ ssize_t writen(int fd, void *buf, size_t count) {int left = count ;char * ptr = (char *)buf;while(left >0){int writeBytes = write(fd,ptr,left);if(writeBytes<0){if(errno == EINTR)continue;return -1;}else if(writeBytes == 0)continue;left -= writeBytes;ptr += writeBytes;}return count; }有了這兩個函數之后，我們就可以使用定長包來發送數據了，我抽取其關鍵代碼來講訴：
char readbuf[512]; readn(conn,readbuf,sizeof(readbuf)); //每次讀取512個字節 //同理的，寫入的時候也寫入512個字節char writebuf[512];fgets(writebuf,sizeof(writebuf),stdin);writen(conn,writebuf,sizeof(writebuf);-
每個消息都以固定的512字節（或其他數字，看你的應用層的緩沖區大小）來發送，以此區分每一個信息，這便是以固定長度解決粘包問題的思路。
-
定長包解決方案的缺點在于會導致增加網絡的負擔，無論每次發送的有效數據是多大，都得按照定長的數據長度進行發送。
-
粘包解決方案二：使用結構體，顯式說明數據部分的長度
-
在這個方案中，我們需要定義一個‘struct packet’包結構，結構中指明數據部分的長度，用四個字節來表示。
-
發送端的對等方接收報文時，先讀取前四個字節，獲取數據的長度，由長度來進行數據的讀取
定義一個結構體
struct packet {unsigned int msgLen ; //4個字節字段，說明數據部分的大小char data[512] ; //數據部分 }讀寫過程如下所示，這里抽取關鍵代碼進行說明：
//發送數據過程struct packet writebuf;memset(&writebuf,0,sizeof(writebuf));while(fgets(writebuf.data,sizeof(writebuf.data),stdin)!=NULL){ int n = strlen(writebuf.data); //計算要發送的數據的字節數writebuf.msgLen =htonl(n); //將該字節數保存在msgLen字段，注意字節序的轉換writen(conn,&writebuf,4+n); //發送數據，數據長度為4個字節的msgLen 加上data長度memset(&writebuf,0,sizeof(writebuf)); }下面是讀取數據的過程，先讀取msgLen字段，該字段指示了有效數據data的長度。依據該字段再讀出data。
memset(&readbuf,0,sizeof(readbuf));int ret = readn(conn,&readbuf.msgLen,4); //先讀取四個字節，確定后續數據的長度if(ret == -1){err_exit("readn");}else if(ret == 0){printf("peer close\n");break; }int dataBytes = ntohl(readbuf.msgLen); //字節序的轉換int readBytes = readn(conn,readbuf.data,dataBytes); //讀取出后續的數據if(readBytes == 0){printf("peer close\n");break;}if(readBytes<0){err_exit("read"); }- 粘包解決方案三：按行讀取
ftp協議采用/r/n來識別一個消息的邊界，我們在這里實現一個按行讀取的功能，該功能能夠按/n來識別消息的邊界。這里介紹一個函數：
ssize_t recv(int sockfd, void *buf, size_t len, int flags);與read函數相比，recv函數的區別在于兩點：
- recv函數只能夠用于套接口IO。
- recv函數含有flags參數，可以指定一些選項。
- recv函數的flags參數常用的選項是：
| MSG_OOB | 接收帶外數據，即通過緊急指針發送的數據 |
| MSG_PEEK | 從緩沖區中讀取數據，但并不從緩沖區中清除所讀數據，為了實現按行讀取，我們需要使用recv函數的MSG_PEEK選項。PEEK的意思是"偷看"，我們可以理解為窺視，看看socket的緩沖區內是否有某種內容，而清除緩沖區。 |
下面是按行讀取的代碼：
/* *讀取一行內容 * 返回值說明：== 0 ：對端關閉== -1 ： 讀取錯誤其他：一行的字節數，包含\n * **/ ssize_t readLine(int sockfd ,void * buf ,size_t maxline) {int ret ;int nRead = 0;int left = maxline ;char * pbuf = (char *) buf;int count = 0;while(true){//從socket緩沖區中讀取指定長度的內容，但并不刪除ret = read_peek(sockfd,pbuf,left);// ret = recv(sockfd , pbuf , left , MSG_PEEK);if(ret<= 0)return ret;nRead = ret ;for(int i = 0 ;i< nRead ; ++i){if(pbuf[i]=='\n') //探測到有\n{ret = readn (sockfd , pbuf, i+1);if(ret != i+1)exit(EXIT_FAILURE);return ret + returnCount;}}//如果嗅探到沒有\n//那么先將這一段沒有\n的讀取出來ret = readn(sockfd , pbuf , nRead);if(ret != nRead)exit(EXIT_FAILURE);pbuf += nRead ;left -= nRead ;count += nRead;}return -1; }完整代碼：
#ifndef __COMMON__ #define __COMMON__ #include<errno.h> #include<stdlib.h> #include<unistd.h> # define err_exit(m)\do\{\perror(m);\exit(EXIT_FAILURE);\}while(0)void handler(int sig) {printf("recv a sig = %d \n",sig);exit(EXIT_SUCCESS); }struct packet {unsigned int msgLen ;char data [1024]; }; /* readn 函數 讀取count字節數據 */ ssize_t readn(int fd,void *buf, size_t count) {int left = count ; //剩下的字節char * ptr = (char*)buf ;while(left>0){int readBytes = read(fd,ptr,left);if(readBytes< 0)//read函數小于0有兩種情況：1中斷 2出錯{if(errno == EINTR)//讀被中斷{continue;} return -1;}if(readBytes == 0)//讀到了EOF{return count - left;} left -= readBytes;ptr += readBytes ;}return count ; }/* writen 函數 寫入count字節的數據 */ ssize_t writen(int fd, void *buf, size_t count) {int left = count ;char * ptr = (char *)buf; while(left >0){int writeBytes = write(fd,ptr,left);if(writeBytes<0){if(errno == EINTR)continue;return -1;}else if(writeBytes == 0)continue;left -= writeBytes;ptr += writeBytes; }return count; }/* 從緩沖區中讀取指定長度的數據，但不清楚緩沖區內容 */ ssize_t read_peek(int sockfd, void *buf, size_t len ) {while(1){int ret = recv (sockfd , buf ,len ,MSG_PEEK);if(ret == -1){if(errno ==EINTR) //出現中斷continue ;}return ret ;} }/* 按行讀取數據 參數說明：sockfd:套接字buf ：應用層緩沖區，保存讀取到的數據maxline:所規定的一行的長度 返回值說明： */ ssize_t readLine (int sockfd , void *buf ,size_t maxline) {int ret;int nRead = 0;int left = maxline ; //剩下的字節數char * pbuf = (char *) buf ; int count = 0;while(1){ret = read_peek ( sockfd, pbuf, left); //讀取長度為left的socket緩沖區內容if(ret <0){return ret;}nRead = ret;for(int i = 0;i<nRead;++i)//看看讀取出來的數據中是否有換行符\n{if(pbuf[i]=='\n')//如果有換行符{ret = readn(sockfd , pbuf , i+1);//讀取一行if(ret != i+1) //一定會讀到i+1個字符，否則是讀取出錯{exit(EXIT_FAILURE); }return ret + count ;}}//窺探的數據中并沒有換行符//把這段沒有\n的讀出來ret = readn(sockfd , pbuf,nRead); if(ret != nRead ){exit(EXIT_FAILURE); }pbuf += nRead;left -= nRead;count += nRead; }return -1;} #endif //__COMMON__五、網絡通訊的封包和拆包
對于基于TCP開發的通訊程序，有個很重要的問題需要解決，就是封包和拆包。
1.為什么基于TCP的通訊程序需要進行封包和拆包
- TCP是個"流"協議，所謂流，就是沒有界限的一串數據，大家可以想想河里的流水，是連成一片的，其間是沒有分界線的。
- 但一般通訊程序開發是需要定義一個個相互獨立的數據包的，比如用于登陸的數據包，用于注銷的數據包。由于TCP"流"的特性以及網絡狀況，在進行數據傳輸時會出現以下幾種情況。
假設我們連續調用兩次send分別發送兩段數據data1和data2,在接收端有以下幾種接收情況(當然不止這幾種情況,這里只列出了有代表性的情況).
- 對于A這種情況正是我們需要的,不再做討論.
- 對于B,C,D的情況就是大家經常說的"粘包",就需要我們把接收到的數據進行拆包，拆成一個個獨立的數據包，為了拆包就必須在發送端進行封包。
另：對于UDP來說就不存在拆包的問題,因為UDP是個"數據包"協議,也就是兩段數據間是有界限的，在接收端要么接收不到數據要么就是接收一個完整的一段數據，不會少接收也不會多接收。
- 為什么會出現B.C.D的情況
2.怎樣封包和拆包
- 最初遇到"粘包"的問題時,我是通過在兩次send之間調用sleep來休眠一小段時間來解決。這個解決方法的缺點是顯而易見的，使傳輸效率大大降低，而且也并不可靠。
- 后來就是通過應答的方式來解決，盡管在大多數時候是可行的，但是不能解決B的那種情況，而且采用應答方式增加了通訊量,加重了網絡負荷. 再后來就是對數據包進行封包和拆包的操作。
- 封包
封包就是給一段數據加上包頭,這樣一來數據包就分為包頭和包體兩部分內容了(以后講過濾非法包時封包會加入"包尾"內容)。包頭其實上是個大小固定的結構體，其中有個結構體成員變量表示包體的長度，這是個很重要的變量，其他的結構體成員可根據需要自己定義。根據包頭長度固定以及包頭中含有包體長度的變量就能正確的拆分出一個完整的數據包。
- 拆包
對于拆包目前我最常用的是以下兩種方式：
（1）動態緩沖區暫存方式。之所以說緩沖區是動態的是因為當需要緩沖的數據長度超出緩沖區的長度時會增大緩沖區長度。
大概過程描述如下:
- A,為每一個連接動態分配一個緩沖區,同時把此緩沖區和SOCKET關聯,常用的是通過結構體關聯.
- B,當接收到數據時首先把此段數據存放在緩沖區中.
- C,判斷緩存區中的數據長度是否夠一個包頭的長度,如不夠,則不進行拆包操作.
- D,根據包頭數據解析出里面代表包體長度的變量.
- E,判斷緩存區中除包頭外的數據長度是否夠一個包體的長度,如不夠,則不進行拆包操作.
- F,取出整個數據包.這里的"取"的意思是不光從緩沖區中拷貝出數據包,而且要把此數據包從緩存區中刪除掉.刪除的辦法就是把此包后面的數據移動到緩沖區的起始地址.
這種方法有兩個缺點.
- 1） 為每個連接動態分配一個緩沖區增大了內存的使用.
- 2） 有三個地方需要拷貝數據,一個地方是把數據存放在緩沖區,一個地方是把完整的數據包從緩沖區取出來,一個地方是把數據包從緩沖區中刪除.第二種拆包的方法會解決和完善這些缺點.
- 前面提到過這種方法的缺點.下面給出一個改進辦法, 即采用環形緩沖.但是這種改進方法還是不能解決第一個缺點以及第一個數據拷貝,只能解決第三個地方的數據拷貝(這個地方是拷貝數據最多的地方).第2種拆包方式會解決這兩個問題.
環形緩沖實現方案是定義兩個指針,分別指向有效數據的頭和尾.在存放數據和刪除數據時只是進行頭尾指針的移動.
（2）利用底層的緩沖區來進行拆包
對于阻塞SOCKET來說，我們可以利用一個循環來接收包頭長度的數據，然后解析出代表包體長度的那個變量，再用一個循環來接收包體長度的數據。
編程實現見：http://blog.csdn.net/zhangxinrun/article/details/6721495
這個問題產生于編程中遇到的幾個問題：
- 1、使用TCP的Socket發送數據的時候，會出現發送出錯，WSAEWOULDBLOCK，在TCP中不是會保證發送的數據能夠安全的到達接收端的嗎？也有窗口機制去防止發送速度過快，為什么還會出錯呢？
- 2、TCP協議，在使用Socket發送數據的時候，每次發送一個包，接收端是完整的接受到一個包還是怎么樣？如果是每發一個包，就接受一個包，為什么還會出現粘包問題，具體是怎么運行的？
- 3、關于Send，是不是只有在非阻塞狀態下才會出現實際發送的比指定發送的小？在阻塞狀態下會不會出現實際發送的比指定發送的小，就是說只能出現要么全發送，要么不發送？在非阻塞狀態下，如果之發送了一些數據，要怎么處理，調用了Send函數后，發現返回值比指定的要小，具體要怎么做？
- 4、最后一個問題，就是TCP/IP協議和Socket是什么關系？是指具體的實現上，Socket是TCP/IP的實現？那么為什么會出現使用TCP協議的Socket會發送出錯。
這個問題第1個回答：
這個問題第2個回答：
1 . 應該不是緩沖區大小問題，我試過設置緩沖區大小，不過這里有個問題，就是就算我把緩沖區設置成幾G，也返回成功，不過實際上怎么可能設置那么大
3 . 出現沒發送完的時候要手動發送吧，有沒有具體的代碼實現？
4、當選擇TCP的Socket發送數據的時候，TCP中的窗口機制不是能防止發送速度過快的嗎？為什么Socket在出現了WSAEWOULDBLOCK后沒有處理？
這個問題第3個回答：
1.在使用非阻塞模式的情況下，如果系統發送緩沖區已滿，并示及時發送到對端，就會產生該錯誤，繼續重試即可。
3.如果沒有發完就繼續發送后續部分即可。
這個問題第4個回答：
相關鏈接：
- TCP粘包、封包、半包問題：TCP粘包、封包、半包問題
- TCP通訊處理粘包詳解：TCP通訊處理粘包詳解
Google開發專家帶你學 AI：入門到實戰（Keras/Tensorflow）（附源碼）
Python數據分析與挖掘
總結
