粘包問題詳情

1、只有TCP有粘包現象，UDP永遠不會粘包

你的程序實際上無權直接操作網卡的，你操作網卡都是通過操作系統給用戶程序暴露出來的接口，那每次你的程序要給遠程發數據時，其實是先把數據從用戶態copy到內核態，這樣的操作是耗資源和時間的，頻繁的在內核態和用戶態之前交換數據勢必會導致發送效率降低，因此socket為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一次數據給對方。若連續幾次需要send的數據都很少，通常TCPsocket會根據優化算法把這些數據合成一個TCP段后一次發送出去，這樣接收方就收到了粘包數據。

2、首先需要掌握一個socket收發消息的原理

發送端可以是1k，1k的發送數據而接受端的應用程序可以2k，2k的提取數據，當然也有可能

是3k或者多k提取數據，也就是說，應用程序是不可見的，因此TCP協議是面來那個流的協議，

這也是容易出現粘包的原因而UDP是面向無連接的協議，每個UDP段都是一條消息，應用程序必

須以消息為單位提取數據，不能一次提取任一字節的數據，這一點和TCP是很同的。怎樣定義

消息呢?認為對方一次性write/send的數據為一個消息，需要命的是當對方send一條信息的

時候，無論鼎城怎么樣分段分片，TCP協議層會把構成整條消息的數據段排序完成后才呈現在內核緩沖區。

例如基于TCP的套接字客戶端往服務器端上傳文件，發送時文件內容是按照一段一段的字節流發送的，

在接收方看來更笨不知道文件的字節流從何初開始，在何處結束。

3、粘包的原因

3-1直接原因

所謂粘包問題主要還是因為接收方不知道消息之間的界限，不知道一次性提取多少字節的數據所造成的

3-2根本原因

發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一個TCP段。若連續幾次需要send的數據都很少，通常TCP會根據優化算法把這些數據合成一個TCP段后一次發送出去，這樣接收方就收到了粘包數據。

3-3總結

TCP(transportcontrolprotocol，傳輸控制協議)是面向連接的，面向流的，提供高可靠性服務。收發兩端(客戶端和服務器端)都要有一一成對的socket，因此，發送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法(Nagle算法)，將多次間隔較小且數據量小的數據，合并成一個大的數據塊，然后進行封包。這樣，接收端，就難于分辨出來了，必須提供科學的拆包機制。即面向流的通信是無消息保護邊界的。

UDP(userdatagramprotocol，用戶數據報協議)是無連接的，面向消息的，提供高效率服務。不會使用塊的合并優化算法，,由于UDP支持的是一對多的模式，所以接收端的skbuff(套接字緩沖區)采用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了消息頭(消息來源地址，端口等信息)，這樣，對于接收端來說，就容易進行區分處理了。即面向消息的通信是有消息保護邊界的。

tcp是基于數據流的，于是收發的消息不能為空，這就需要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基于數據報的，即便是你輸入的是空內容(直接回車)，那也不是空消息，udp協議會幫你封裝上消息頭，實驗略

udp的recvfrom是阻塞的，一個recvfrom(x)必須對唯一一個sendinto(y),收完了x個字節的數據就算完成,若是y>x數據就丟失，這意味著udp根本不會粘包，但是會丟數據，不可靠

tcp的協議數據不會丟，沒有收完包，下次接收，會繼續上次繼續接收，己端總是在收到ack時才會清除緩沖區內容。數據是可靠的，但是會粘包。

以上內容為大家介紹了pythonsocket網絡編程之粘包問題詳解，希望對大家有所幫助，如果想要了解更多Python相關知識，請關注IT培訓機構:千鋒教育。