?

一? socket 套接字

二? 粘包問題

?

一? socket 套接字

1.1 為何學習socket一定要先學習互聯網協議：

1.首先：網絡編程目標就是教會你如何基于socket編程，來開發一款自己的C/S架構軟件

2.其次：C/S架構的軟件（軟件屬于應用層）是基于網絡進行通信的

3.然后：網絡的核心即一堆協議，協議即標準，你想開發一款基于網絡通信的軟件，就必須遵循這些標準。

4.最后：從這些標準開始研究，開啟socket編程

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

1.2 socket層

在上圖中，我們沒有看到Socket,我們用下圖來繼續說明.?

?

1.3 socket是什么

Socket是應用層與TCP/IP協議通信的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把復雜的TCP/IP協議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數據，以符合指定的協議。

所以，我們無需深入理解tcp/udp協議，socket已經為我們封裝好了，我們只需要遵循socket的規定去編程，寫出的程序自然就是遵循tcp/udp標準的。

1.4? 套接字發展史及分類

套接字起源于 20 世紀 70 年代加利福尼亞大學伯克利分校版本的 Unix,即人們所說的 BSD Unix。 因此,有時人們也把套接字稱為“伯克利套接字”或“BSD 套接字”。一開始,套接字被設計用在同 一臺主機上多個應用程序之間的通訊。這也被稱進程間通訊,或 IPC。套接字有兩種（或者稱為有兩個種族）,分別是基于文件型的和基于網絡型的。?

基于文件類型的套接字家族

套接字家族的名字：AF_UNIX

unix一切皆文件，基于文件的套接字調用的就是底層的文件系統來取數據，兩個套接字進程運行在同一機器，可以通過訪問同一個文件系統間接完成通信

基于網絡類型的套接字家族

套接字家族的名字：AF_INET

(還有AF_INET6被用于ipv6，還有一些其他的地址家族，不過，他們要么是只用于某個平臺，要么就是已經被廢棄，或者是很少被使用，或者是根本沒有實現，所有地址家族中，AF_INET是使用最廣泛的一個，python支持很多種地址家族，但是由于我們只關心網絡編程，所以大部分時候我么只使用AF_INET)

1.5 套接字工作流程

???????一個生活中的場景。你要打電話給一個朋友，先撥號，朋友聽到電話鈴聲后提起電話，這時你和你的朋友就建立起了連接，就可以講話了。等交流結束，掛斷電話結束此次交談。?生活中的場景就解釋了這工作原理。

? ? ??

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖3 ? ? ??

先從服務器端說起。服務器端先初始化Socket，然后與端口綁定(bind)，對端口進行監聽(listen)，調用accept阻塞，等待客戶端連接。在這時如果有個客戶端初始化一個Socket，然后連接服務器(connect)，如果連接成功，這時客戶端與服務器端的連接就建立了。客戶端發送數據請求，服務器端接收請求并處理請求，然后把回應數據發送給客戶端，客戶端讀取數據，最后關閉連接，一次交互結束

socket()模塊函數用法

1 import socket2 socket.socket(socket_family,socket_type,protocal=0)3 socket_family 可以是 AF_UNIX 或 AF_INET。socket_type 可以是 SOCK_STREAM 或 SOCK_DGRAM。protocol 一般不填,默認值為 0。4 5 獲取tcp/ip套接字6 tcpSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)7 8 獲取udp/ip套接字9 udpSock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) 10 11 由于 socket 模塊中有太多的屬性。我們在這里破例使用了'from module import *'語句。使用 'from socket import *',我們就把 socket 模塊里的所有屬性都帶到我們的命名空間里了,這樣能 大幅減短我們的代碼。 12 例如tcpSock = socket(AF_INET, SOCK_STREAM)

?

服務端套接字函數
s.bind() 綁定(主機,端口號)到套接字
s.listen() 開始TCP監聽
s.accept() 被動接受TCP客戶的連接,(阻塞式)等待連接的到來

客戶端套接字函數
s.connect() 主動初始化TCP服務器連接
s.connect_ex() connect()函數的擴展版本,出錯時返回出錯碼,而不是拋出異常

公共用途的套接字函數
s.recv() 接收TCP數據
s.send() 發送TCP數據(send在待發送數據量大于己端緩存區剩余空間時,數據丟失,不會發完)
s.sendall() 發送完整的TCP數據(本質就是循環調用send,sendall在待發送數據量大于己端緩存區剩余空間時,數據不丟失,循環調用send直到發完)
s.recvfrom() 接收UDP數據
s.sendto() 發送UDP數據
s.getpeername() 連接到當前套接字的遠端的地址
s.getsockname() 當前套接字的地址
s.getsockopt() 返回指定套接字的參數
s.setsockopt() 設置指定套接字的參數
s.close() 關閉套接字

面向鎖的套接字方法
s.setblocking() 設置套接字的阻塞與非阻塞模式
s.settimeout() 設置阻塞套接字操作的超時時間
s.gettimeout() 得到阻塞套接字操作的超時時間

面向文件的套接字的函數
s.fileno() 套接字的文件描述符
s.makefile() 創建一個與該套接字相關的文件

?讀者勿看：socket實驗推演流程

1.6 基于TCP的套接字

tcp是基于鏈接的，必須先啟動服務端，然后再啟動客戶端去鏈接服務端

tcp服務端

1 ss = socket() #創建服務器套接字 2 ss.bind() #把地址綁定到套接字 3 ss.listen() #監聽鏈接 4 inf_loop: #服務器無限循環 5 cs = ss.accept() #接受客戶端鏈接 6 comm_loop: #通訊循環 7 cs.recv()/cs.send() #對話(接收與發送) 8 cs.close() #關閉客戶端套接字 9 ss.close() #關閉服務器套接字(可選)

?

tcp客戶端

1 cs = socket() # 創建客戶套接字 2 cs.connect() # 嘗試連接服務器 3 comm_loop: # 通訊循環 4 cs.send()/cs.recv() # 對話(發送/接收) 5 cs.close() # 關閉客戶套接字

?

?

socket通信流程與打電話流程類似，我們就以打電話為例來實現一個low版的套接字通信

?服務端 ?客戶端

加上鏈接循環與通信循環

#_*_coding:utf-8_*_ __author__ = 'Linhaifeng' import socket ip_port=('127.0.0.1',8081)#電話卡 BUFSIZE=1024 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) #買手機 s.bind(ip_port) #手機插卡 s.listen(5) #手機待機while True: #新增接收鏈接循環,可以不停的接電話conn,addr=s.accept() #手機接電話# print(conn)# print(addr)print('接到來自%s的電話' %addr[0])while True: #新增通信循環,可以不斷的通信,收發消息msg=conn.recv(BUFSIZE) #聽消息,聽話# if len(msg) == 0:break #如果不加,那么正在鏈接的客戶端突然斷開,recv便不再阻塞,死循環發生print(msg,type(msg))conn.send(msg.upper()) #發消息,說話conn.close() #掛電話s.close() #手機關機 ?客戶端改進版

?

問題：在重啟服務端時可能會遇到

這個是由于你的服務端仍然存在四次揮手的time_wait狀態在占用地址（如果不懂，請深入研究1.tcp三次握手，四次揮手 2.syn洪水攻擊 3.服務器高并發情況下會有大量的time_wait狀態的優化方法）

解決方法：

?方法一 ?方法二 1.7?基于UDP的套接字

udp是無鏈接的，先啟動哪一端都不會報錯

udp服務端

1 ss = socket() #創建一個服務器的套接字 2 ss.bind() #綁定服務器套接字 3 inf_loop: #服務器無限循環 4 cs = ss.recvfrom()/ss.sendto() # 對話(接收與發送) 5 ss.close() # 關閉服務器套接字

?

udp客戶端

cs = socket() # 創建客戶套接字 comm_loop: # 通訊循環cs.sendto()/cs.recvfrom() # 對話(發送/接收) cs.close() # 關閉客戶套接字

?

udp套接字簡單示例

?udp服務端 ?udp客戶端

qq聊天(由于udp無連接，所以可以同時多個客戶端去跟服務端通信)

?udp服務端 ?udp客戶端1 ?udp客戶端2

服務端運行結果

客戶端1運行結果

客戶端2運行結果

時間服務器

?ntp服務端 ?ntp客戶端

九 粘包現象

讓我們基于tcp先制作一個遠程執行命令的程序（1：執行錯誤命令 2：執行ls 3：執行ifconfig）

注意注意注意：

res=subprocess.Popen(cmd.decode('utf-8'),
shell=True,
stderr=subprocess.PIPE,
stdout=subprocess.PIPE)

的結果的編碼是以當前所在的系統為準的，如果是windows，那么res.stdout.read()讀出的就是GBK編碼的，在接收端需要用GBK解碼

且只能從管道里讀一次結果

注意：命令ls -l ; lllllll ; pwd 的結果是既有正確stdout結果，又有錯誤stderr結果

?服務端 ?客戶端

上述程序是基于tcp的socket，在運行時會發生粘包

?

讓我們再基于udp制作一個遠程執行命令的程序

?服務端 ?客戶端

上述程序是基于udp的socket，在運行時永遠不會發生粘包

十 什么是粘包

須知：只有TCP有粘包現象，UDP永遠不會粘包，為何，且聽我娓娓道來

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

?

發送端可以是一K一K地發送數據，而接收端的應用程序可以兩K兩K地提走數據，當然也有可能一次提走3K或6K數據，或者一次只提走幾個字節的數據，也就是說，應用程序所看到的數據是一個整體，或說是一個流（stream），一條消息有多少字節對應用程序是不可見的，因此TCP協議是面向流的協議，這也是容易出現粘包問題的原因。而UDP是面向消息的協議，每個UDP段都是一條消息，應用程序必須以消息為單位提取數據，不能一次提取任意字節的數據，這一點和TCP是很不同的。怎樣定義消息呢？可以認為對方一次性write/send的數據為一個消息，需要明白的是當對方send一條信息的時候，無論底層怎樣分段分片，TCP協議層會把構成整條消息的數據段排序完成后才呈現在內核緩沖區。

例如基于tcp的套接字客戶端往服務端上傳文件，發送時文件內容是按照一段一段的字節流發送的，在接收方看了，根本不知道該文件的字節流從何處開始，在何處結束

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

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

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

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

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

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

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

兩種情況下會發生粘包。

發送端需要等緩沖區滿才發送出去，造成粘包（發送數據時間間隔很短，數據了很小，會合到一起，產生粘包）

?服務端 ?客戶端

接收方不及時接收緩沖區的包，造成多個包接收（客戶端發送了一段數據，服務端只收了一小部分，服務端下次再收的時候還是從緩沖區拿上次遺留的數據，產生粘包）?

?服務端 ?客戶端

?

拆包的發生情況

當發送端緩沖區的長度大于網卡的MTU時，tcp會將這次發送的數據拆成幾個數據包發送出去。

補充問題一：為何tcp是可靠傳輸，udp是不可靠傳輸

基于tcp的數據傳輸請參考我的另一篇文章http://www.cnblogs.com/linhaifeng/articles/5937962.html，tcp在數據傳輸時，發送端先把數據發送到自己的緩存中，然后協議控制將緩存中的數據發往對端，對端返回一個ack=1，發送端則清理緩存中的數據，對端返回ack=0，則重新發送數據，所以tcp是可靠的

而udp發送數據，對端是不會返回確認信息的，因此不可靠

補充問題二：send(字節流)和recv(1024)及sendall

recv里指定的1024意思是從緩存里一次拿出1024個字節的數據

send的字節流是先放入己端緩存，然后由協議控制將緩存內容發往對端，如果待發送的字節流大小大于緩存剩余空間，那么數據丟失，用sendall就會循環調用send，數據不會丟失

十一 解決粘包的low比處理方法

問題的根源在于，接收端不知道發送端將要傳送的字節流的長度，所以解決粘包的方法就是圍繞，如何讓發送端在發送數據前，把自己將要發送的字節流總大小讓接收端知曉，然后接收端來一個死循環接收完所有數據

low版本的解決方法

?服務端 ?客戶端

為何low：

程序的運行速度遠快于網絡傳輸速度，所以在發送一段字節前，先用send去發送該字節流長度，這種方式會放大網絡延遲帶來的性能損耗

十二 峰哥解決粘包的方法

為字節流加上自定義固定長度報頭，報頭中包含字節流長度，然后一次send到對端，對端在接收時，先從緩存中取出定長的報頭，然后再取真實數據

struct模塊?

該模塊可以把一個類型，如數字，轉成固定長度的bytes

>>> struct.pack('i',1111111111111)

。。。。。。。。。

struct.error: 'i' format requires -2147483648 <= number <= 2147483647 #這個是范圍

?

import json,struct #假設通過客戶端上傳1T:1073741824000的文件a.txt#為避免粘包,必須自定制報頭 header={'file_size':1073741824000,'file_name':'/a/b/c/d/e/a.txt','md5':'8f6fbf8347faa4924a76856701edb0f3'} #1T數據,文件路徑和md5值#為了該報頭能傳送,需要序列化并且轉為bytes head_bytes=bytes(json.dumps(header),encoding='utf-8') #序列化并轉成bytes,用于傳輸#為了讓客戶端知道報頭的長度,用struck將報頭長度這個數字轉成固定長度:4個字節 head_len_bytes=struct.pack('i',len(head_bytes)) #這4個字節里只包含了一個數字,該數字是報頭的長度#客戶端開始發送 conn.send(head_len_bytes) #先發報頭的長度,4個bytes conn.send(head_bytes) #再發報頭的字節格式 conn.sendall(文件內容) #然后發真實內容的字節格式#服務端開始接收 head_len_bytes=s.recv(4) #先收報頭4個bytes,得到報頭長度的字節格式 x=struct.unpack('i',head_len_bytes)[0] #提取報頭的長度head_bytes=s.recv(x) #按照報頭長度x,收取報頭的bytes格式 header=json.loads(json.dumps(header)) #提取報頭#最后根據報頭的內容提取真實的數據,比如 real_data_len=s.recv(header['file_size']) s.recv(real_data_len) ?關于struct的詳細用法

?

?服務端（自定制報頭） ?客戶端（自定制報頭）

我們可以把報頭做成字典，字典里包含將要發送的真實數據的詳細信息，然后json序列化，然后用struck將序列化后的數據長度打包成4個字節（4個自己足夠用了）

發送時：

先發報頭長度

再編碼報頭內容然后發送

最后發真實內容

?

接收時：

先手報頭長度，用struct取出來

根據取出的長度收取報頭內容，然后解碼，反序列化

從反序列化的結果中取出待取數據的詳細信息，然后去取真實的數據內容

?服務端：定制稍微復雜一點的報頭 ?客戶端

?

?

FTP作業：上傳下載文件

?服務端 import socket import struct import json import osclass MYTCPClient:address_family = socket.AF_INETsocket_type = socket.SOCK_STREAMallow_reuse_address = Falsemax_packet_size = 8192coding='utf-8'request_queue_size = 5def __init__(self, server_address, connect=True):self.server_address=server_addressself.socket = socket.socket(self.address_family,self.socket_type)if connect:try:self.client_connect()except:self.client_close()raisedef client_connect(self):self.socket.connect(self.server_address)def client_close(self):self.socket.close()def run(self):while True:inp=input(">>: ").strip()if not inp:continuel=inp.split()cmd=l[0]if hasattr(self,cmd):func=getattr(self,cmd)func(l)def put(self,args):cmd=args[0]filename=args[1]if not os.path.isfile(filename):print('file:%s is not exists' %filename)returnelse:filesize=os.path.getsize(filename)head_dic={'cmd':cmd,'filename':os.path.basename(filename),'filesize':filesize}print(head_dic)head_json=json.dumps(head_dic)head_json_bytes=bytes(head_json,encoding=self.coding)head_struct=struct.pack('i',len(head_json_bytes))self.socket.send(head_struct)self.socket.send(head_json_bytes)send_size=0with open(filename,'rb') as f:for line in f:self.socket.send(line)send_size+=len(line)print(send_size)else:print('upload successful')client=MYTCPClient(('127.0.0.1',8080))client.run()

Socket(套接字)

127.0.0.1本機回還地址
只能自己識別自己 其他人無法訪問

send與recv對應
不要出現兩邊都是相同的情況

recv是跟內存要數據
至于數據的來源 你無需考慮

TCP特點
會將數據量比較小的并且時間間隔比較短的數據
一次性打包發送給對方

socket最簡單版本

解決粘包問題的最復雜版本

from socket import SOL_SOCKET,SO_REUSEADDR
sk.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #就是它，在bind前加

解決粘包問題
服務端
1.先制作一個發送給客戶端的字典
2.制作字典的報頭
3.發送字典的報頭
4.發送字典
5.再發真實數據

客戶端
1.先接受字典的報頭
2.解析拿到字典的數據長度
3.接受字典
4.從字典中獲取真實數據的長度
5.接受真實數據

寫一個上傳電影的功能
1.循環打印某一個文件夾下面的所有的文件
2.用戶選取想要上傳的文件
3.將用戶選擇的文件上傳到服務端
4.服務端保存該文件




1.直接獲取數據1024
2.制作一個數據的報頭
3.先發個字典 然后再發真實數據

?

轉載于:https://www.cnblogs.com/Ryan-Yuan/p/11317724.html

總結

以上是生活随笔為你收集整理的day28 socket网络编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。