問題的根源在于，接收端不知道發(fā)送端將要傳送的字節(jié)流的長度，所以解決粘包的方法就是圍繞，如何讓發(fā)送端在發(fā)送數(shù)據(jù)前，把自己將要發(fā)送的字節(jié)流總大小讓接收端知曉，然后接收端來一個(gè)死循環(huán)接收完所有數(shù)據(jù)。

簡單的解決方法

這種方法的缺陷是程序的運(yùn)行速度遠(yuǎn)快于網(wǎng)絡(luò)傳輸速度，所以在發(fā)送一段字節(jié)前，先用send去發(fā)送該字節(jié)流長度，這種方式會(huì)放大網(wǎng)絡(luò)延遲帶來的性能損耗。

高級一點(diǎn)的解決方法

為字節(jié)流加上自定義固定長度報(bào)頭，報(bào)頭中包含字節(jié)流長度，然后一次send到對端，對端在接收時(shí)，先從緩存中取出定長的報(bào)頭，然后再取真實(shí)數(shù)據(jù)

struct模塊

該模塊可以把一個(gè)類型，如數(shù)字，轉(zhuǎn)成固定長度的bytes

importjson,struct

#假設(shè)通過客戶端上傳1T:1073741824000的文件a.txt

#為避免粘包,必須自定制報(bào)頭

header={'file_size':1073741824000,'file_name':'/a/b/c/d/e/a.txt','md5':'8f6fbf8347faa4924a76856701edb0f3'}#1T數(shù)據(jù),文件路徑和md5值

#為了該報(bào)頭能傳送,需要序列化并且轉(zhuǎn)為bytes

head_bytes=bytes(json.dumps(header),encoding='utf-8')#序列化并轉(zhuǎn)成bytes,用于傳輸

#為了讓客戶端知道報(bào)頭的長度,用struck將報(bào)頭長度這個(gè)數(shù)字轉(zhuǎn)成固定長度:4個(gè)字節(jié)

head_len_bytes=struct.pack('i',len(head_bytes))#這4個(gè)字節(jié)里只包含了一個(gè)數(shù)字,該數(shù)字是報(bào)頭的長度

#客戶端開始發(fā)送

conn.send(head_len_bytes)#先發(fā)報(bào)頭的長度,4個(gè)bytes

conn.send(head_bytes)#再發(fā)報(bào)頭的字節(jié)格式

conn.sendall(文件內(nèi)容)#然后發(fā)真實(shí)內(nèi)容的字節(jié)格式

#服務(wù)端開始接收

head_len_bytes=s.recv(4)#先收報(bào)頭4個(gè)bytes,得到報(bào)頭長度的字節(jié)格式

x=struct.unpack('i',head_len_bytes)[0]#提取報(bào)頭的長度

head_bytes=s.recv(x)#按照報(bào)頭長度x,收取報(bào)頭的bytes格式

header=json.loads(json.dumps(header))#提取報(bào)頭

#最后根據(jù)報(bào)頭的內(nèi)容提取真實(shí)的數(shù)據(jù),比如

real_data_len=s.recv(header['file_size'])

s.recv(real_data_len)

我們可以把報(bào)頭做成字典，字典里包含將要發(fā)送的真實(shí)數(shù)據(jù)的詳細(xì)信息，然后json序列化，然后用struck將序列化后的數(shù)據(jù)長度打包成4個(gè)字節(jié)(4個(gè)字節(jié)足夠用了)

發(fā)送時(shí)：

先發(fā)報(bào)頭長度

再編碼報(bào)頭內(nèi)容然后發(fā)送

最后發(fā)真實(shí)內(nèi)容

接收時(shí)：

先收報(bào)頭長度，用struct取出來

根據(jù)取出的長度收取報(bào)頭內(nèi)容，然后解碼，反序列化

從反序列化的結(jié)果中取出待取數(shù)據(jù)的詳細(xì)信息，然后去取真實(shí)的數(shù)據(jù)內(nèi)容

以上內(nèi)容為大家介紹了python粘包解決方法，希望對大家有所幫助，如果想要了解更多Python相關(guān)知識，請關(guān)注IT培訓(xùn)機(jī)構(gòu):千鋒教育。