網路編程協議 1.osi七層模型 應用層 表示層 會話層 傳輸層 網路層 數據鏈路層 物理層 2.套接字 socket 有兩類,一種基於文件類型,一種基於網路類型 3.Tcp和udp協議 Tcp協議:面向連接,數據可靠,傳輸效率低,面向位元組流 建立連接與斷開連接的過程(三次握手,四次揮手) 建立連接 ...
網路編程協議
1.osi七層模型
應用層 表示層 會話層 傳輸層 網路層 數據鏈路層 物理層
2.套接字 socket
有兩類,一種基於文件類型,一種基於網路類型
3.Tcp和udp協議
Tcp協議:面向連接,數據可靠,傳輸效率低,面向位元組流
建立連接與斷開連接的過程(三次握手,四次揮手)
建立連接:1.客戶端先發出消息到服務端,請求連接
2.服務端收到信息後,給客戶端反饋一個信息,等待客戶端回覆
3.客戶端收到服務端的反饋信息後,再像服務端發出收到消息,連接建立
斷開連接:1.客戶端先發出消息到服務端,請求斷開連接
2.服務端先發送一個信息,讓客戶端進行等待服務端處理通道中的數據
3.服務端處理完通道中的數據,給客戶端發送一個信息,表示已經處理完數據,等待客戶端回覆
4.客戶端收到消息後,給服務端發送一個回覆信息,服務端收到後,斷開連接
Udp協議:面向無連接,數據不可靠,傳輸效率高,面向報文
Tcp和udp協議下的socket
Tcp長連接的一些問題
會出現粘包現象,這種現象是由緩衝區引起的
緩衝區: 將程式和網路解耦
輸入緩衝區
輸出緩衝區
Import Subprocess
sub_obj = subprocess.Popen(
‘dir’,
shell=True,
stdout=subprocess.PIPE, #正確結果的存放位置
stderr=subprocess.PIPE #錯誤結果的存放位置
)
兩種粘包現象:
1 連續的小包可能會被優化演算法給組合到一起進行發送
2 第一次如果發送的數據大小2000B,接收端一次性接受大小為1024B,這就導致剩下的內容會被下一次recv接收到,導致結果錯亂
解決粘包的方法:
方案一:由於雙方不知道對方發送數據的長度,導致接收的時候,可能接收不全,或者多接收另外一次發送的信息內容,所以在發送真實數據之前,要先發送數據的長度,接收端根據長度來接收後面的真實數據,但是雙方有一個交互確認的過程
方案二:
使用Struct模塊,在發送前,把文件的大小打包,做成報頭,把報頭放在文件真實內容之前;在接收時,對發送過來的文件進行解包,然後列印文件真實內容.
打包:struct.pack(‘i’,長度)
解包:struct.unpack(‘i’,位元組)
