Python基礎-網絡編程

時間 2019-11-19

原文原文鏈接

一網絡基礎

1.1 一個程序如何在網絡上找到另外一個程序

　　首先，程序必需要啓動，其次，必須有這臺機器的地址，咱們都知道咱們人的地址大概就是國家\省\市\區\街道\樓\門牌號這樣字。那麼每一臺聯網的機器在網絡上也有本身的地址，它的地址叫作IP地址。html

IP地址是指互聯網協議地址（英語：Internet Protocol Address，又譯爲網際協議地址），是IP Address的縮寫。IP地址是IP協議提供的一種統一的地址格式，它爲互聯網上的每個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差別。

IP地址是一個32位的二進制數，一般被分割爲4個「8位二進制數」（也就是4個字節）。IP地址一般用「點分十進制」表示成（a.b.c.d）的形式，其中，a,b,c,d都是0~255之間的十進制整數。例：點分十進IP地址（100.4.5.6），其實是32位二進制數（01100100.00000100.00000101.00000110）。

什麼是IP

"端口"是英文port的意譯，能夠認爲是設備與外界通信交流的出口。

什麼是端口

所以ip地址精確到具體的一臺電腦，而端口精確到具體的程序。python

1.2 OSI七層模型

　　一個完整的計算機系統是由硬件、操做系統、應用軟件三者組成,具有了這三個條件，一臺計算機系統就能夠本身跟本身玩了（打個單機遊戲，玩個掃雷啥的）　　算法

　　若是你要跟別人一塊兒玩，那你就須要上網了，什麼是互聯網？shell

　　互聯網的核心就是由一堆協議組成，協議就是標準，好比全世界人通訊的標準是英語，若是把計算機比做人，互聯網協議就是計算機界的英語。全部的計算機都學會了互聯網協議，那全部的計算機都就能夠按照統一的標準去收發信息從而完成通訊了。編程

1.2.1 osi七層模型

人們按照分工不一樣把互聯網協議從邏輯上劃分了層級：json

1.2.2 socket 概念

socket層windows

理解socket設計模式

　　socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。瀏覽器

　　其實站在你的角度上看，socket就是一個模塊。咱們經過調用模塊中已經實現的方法創建兩個進程之間的鏈接和通訊。也有人將socket說成ip+port，由於ip是用來標識互聯網中的一臺主機的位置，而port是用來標識這臺機器上的一個應用程序。因此咱們只要確立了ip和port就能找到一個應用程序，而且使用socket模塊來與之通訊。緩存

1.2.3 套接字(socket)的發展史

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

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

套接字家族的名字：AF_UNIX

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

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

套接字家族的名字：AF_INET

(還有AF_INET6被用於ipv6，還有一些其餘的地址家族，不過，他們要麼是隻用於某個平臺，要麼就是已經被廢棄，或者是不多被使用，或者是根本沒有實現，全部地址家族中，AF_INET是使用最普遍的一個，python支持不少種地址家族，可是因爲咱們只關心網絡編程，因此大部分時候我麼只使用AF_INET)

1.2.4 tcp協議和udp協議

TCP（Transmission Control Protocol）可靠的、面向鏈接的協議（eg:打電話）、傳輸效率低全雙工通訊（發送緩存&接收緩存）、面向字節流。使用TCP的應用：Web瀏覽器；電子郵件、文件傳輸程序。

UDP（User Datagram Protocol）不可靠的、無鏈接的服務，傳輸效率高（發送前時延小），一對1、一對多、多對1、多對多、面向報文，盡最大努力服務，無擁塞控制。使用UDP的應用：域名系統 (DNS)；視頻流；IP語音(VoIP)。

二套接字(socket)初使用

2.1 基於TCP協議的socket

tcp是基於連接的，必須先啓動服務端，而後再啓動客戶端去連接服務端

server端

import socket
sk = socket.socket()
sk.bind(('127.0.0.1',8898))  #把地址綁定到套接字
sk.listen()          #監聽連接
conn,addr = sk.accept() #接受客戶端連接
ret = conn.recv(1024)  #接收客戶端信息
print(ret)       #打印客戶端信息
conn.send(b'hi')        #向客戶端發送信息
conn.close()       #關閉客戶端套接字
sk.close()        #關閉服務器套接字(可選)

client端

import socket
sk = socket.socket()           # 建立客戶套接字
sk.connect(('127.0.0.1',8898))    # 嘗試鏈接服務器
sk.send(b'hello!')
ret = sk.recv(1024)         # 對話(發送/接收)
print(ret)
sk.close()            # 關閉客戶套接字

問題解決：個別windows電腦會遇到以下問題：

解決方式：

#加入一條socket配置，重用ip和端口
import socket
from socket import SOL_SOCKET,SO_REUSEADDR
sk = socket.socket()
sk.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #就是它，在bind前加
sk.bind(('127.0.0.1',8898))  #把地址綁定到套接字
sk.listen()          #監聽連接
conn,addr = sk.accept() #接受客戶端連接
ret = conn.recv(1024)   #接收客戶端信息
print(ret)              #打印客戶端信息
conn.send(b'hi')        #向客戶端發送信息
conn.close()       #關閉客戶端套接字
sk.close()        #關閉服務器套接字(可選)

2.2 基於UDP協議的socket

udp是無連接的，啓動服務以後能夠直接接受消息，不須要提早創建連接

2.2.1 簡單使用

server端

import socket
udp_sk = socket.socket(type=socket.SOCK_DGRAM)   #建立一個服務器的套接字
udp_sk.bind(('127.0.0.1',9000))        #綁定服務器套接字
msg,addr = udp_sk.recvfrom(1024)
print(msg)
udp_sk.sendto(b'hi',addr)                 # 對話(接收與發送)
udp_sk.close()                         # 關閉服務器套接字

client端

import socket
ip_port=('127.0.0.1',9000)
udp_sk=socket.socket(type=socket.SOCK_DGRAM)
udp_sk.sendto(b'hello',ip_port)
back_msg,addr=udp_sk.recvfrom(1024)
print(back_msg.decode('utf-8'),addr)

2.3 socket參數的詳解

socket.socket(family=AF_INET,type=SOCK_STREAM,proto=0,fileno=None)

建立socket對象的參數說明：

family	地址系列應爲AF_INET(默認值),AF_INET6,AF_UNIX,AF_CAN或AF_RDS。（AF_UNIX 域其實是使用本地 socket 文件來通訊）
type	套接字類型應爲SOCK_STREAM(默認值),SOCK_DGRAM,SOCK_RAW或其餘SOCK_常量之一。 SOCK_STREAM 是基於TCP的，有保障的（即能保證數據正確傳送到對方）面向鏈接的SOCKET，多用於資料傳送。 SOCK_DGRAM 是基於UDP的，無保障的面向消息的socket，多用於在網絡上發廣播信息。
proto	協議號一般爲零,能夠省略,或者在地址族爲AF_CAN的狀況下,協議應爲CAN_RAW或CAN_BCM之一。
fileno	若是指定了fileno,則其餘參數將被忽略,致使帶有指定文件描述符的套接字返回。與socket.fromfd()不一樣,fileno將返回相同的套接字,而不是重複的。這可能有助於使用socket.close()關閉一個獨立的插座。

三粘包

3.1 粘包現象

　　同時執行多條命令以後，獲得的結果極可能只有一部分，在執行其餘命令的時候又接收到以前執行的另一部分結果，這種顯現就是黏包。

3.2 粘包成因

3.2.1 TCP協議中的數據傳遞

tcp協議的拆包機制

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

MTU是Maximum Transmission Unit的縮寫。意思是網絡上傳送的最大數據包。MTU的單位是字節。 大部分網絡設備的MTU都是1500。若是本機的MTU比網關的MTU大，大的數據包就會被拆開來傳送，這樣會產生不少數據包碎片，增長丟包率，下降網絡速度。

面向流的通訊特色和Nagle算法

TCP（transport control protocol，傳輸控制協議）是面向鏈接的，面向流的，提供高可靠性服務。
收發兩端（客戶端和服務器端）都要有一一成對的socket，所以，發送端爲了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將屢次間隔較小且數據量小的數據，合併成一個大的數據塊，而後進行封包。
這樣，接收端，就難於分辨出來了，必須提供科學的拆包機制。即面向流的通訊是無消息保護邊界的。
對於空消息：tcp是基於數據流的，因而收發的消息不能爲空，這就須要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基於數據報的，即使是你輸入的是空內容（直接回車），也能夠被髮送，udp協議會幫你封裝上消息頭髮送過去。
可靠黏包的tcp協議：tcp的協議數據不會丟，沒有收完包，下次接收，會繼續上次繼續接收，己端老是在收到ack時纔會清除緩衝區內容。數據是可靠的，可是會粘包。

基於tcp協議特色的黏包現象成因

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

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

此外，發送方引發的粘包是由TCP協議自己形成的，TCP爲提升傳輸效率，發送方每每要收集到足夠多的數據後才發送一個TCP段。若連續幾回須要send的數據都不多，一般TCP會根據優化算法把這些數據合成一個TCP段後一次發送出去，這樣接收方就收到了粘包數據。

3.2.2 UDP不會發生黏包

UDP（user datagram protocol，用戶數據報協議）是無鏈接的，面向消息的，提供高效率服務。 
不會使用塊的合併優化算法，, 因爲UDP支持的是一對多的模式，因此接收端的skbuff(套接字緩衝區）採用了鏈式結構來記錄每個到達的UDP包，在每一個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對於接收端來講，就容易進行區分處理了。 即面向消息的通訊是有消息保護邊界的。 
對於空消息：tcp是基於數據流的，因而收發的消息不能爲空，這就須要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基於數據報的，即使是你輸入的是空內容（直接回車），也能夠被髮送，udp協議會幫你封裝上消息頭髮送過去。 
不可靠不黏包的udp協議：udp的recvfrom是阻塞的，一個recvfrom(x)必須對惟一一個sendinto(y),收完了x個字節的數據就算完成,如果y;x數據就丟失，這意味着udp根本不會粘包，可是會丟數據，不可靠。

3.2.3 總結

黏包現象只發生在tcp協議中：

1.從表面上看，黏包問題主要是由於發送方和接收方的緩存機制、tcp協議面向流通訊的特色。

2.實際上，主要仍是由於接收方不知道消息之間的界限，不知道一次性提取多少字節的數據所形成的

3.3 粘包的解決方案

3.3.1 解決方案一

問題的根源在於，接收端不知道發送端將要傳送的字節流的長度，因此解決粘包的方法就是圍繞，如何讓發送端在發送數據前，把本身將要發送的字節流總大小讓接收端知曉，而後接收端來一個死循環接收完全部數據。

#_*_coding:utf-8_*_
import socket,subprocess
ip_port=('127.0.0.1',8080)
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

s.bind(ip_port)
s.listen(5)

while True:
    conn,addr=s.accept()
    print('客戶端',addr)
    while True:
        msg=conn.recv(1024)
        if not msg:break
        res=subprocess.Popen(msg.decode('utf-8'),shell=True,\
                            stdin=subprocess.PIPE,\
                         stderr=subprocess.PIPE,\
                         stdout=subprocess.PIPE)
        err=res.stderr.read()
        if err:
            ret=err
        else:
            ret=res.stdout.read()
        data_length=len(ret)
        conn.send(str(data_length).encode('utf-8'))
        data=conn.recv(1024).decode('utf-8')
        if data == 'recv_ready':
            conn.sendall(ret)
    conn.close()

Server端

#_*_coding:utf-8_*_
import socket,time
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
res=s.connect_ex(('127.0.0.1',8080))

while True:
    msg=input('>>: ').strip()
    if len(msg) == 0:continue
    if msg == 'quit':break

    s.send(msg.encode('utf-8'))
    length=int(s.recv(1024).decode('utf-8'))
    s.send('recv_ready'.encode('utf-8'))
    send_size=0
    recv_size=0
    data=b''
    while recv_size < length:
        data+=s.recv(1024)
        recv_size+=len(data)


    print(data.decode('utf-8'))

客戶端

Client端

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

3.3.2 解決方案二--進階

剛剛的方法，問題在於咱們咱們在發送消息大小的時候，一樣不知道要發送的數據長度。

咱們能夠藉助一個模塊，這個模塊能夠把要發送的數據長度轉換成固定長度的字節。這樣客戶端每次接收消息以前只要先接受這個固定長度字節的內容看一看接下來要接收的信息大小，那麼最終接受的數據只要達到這個值就中止，就能恰好很少很多的接收完整的數據了。

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)

使用stuct解決粘包

藉助struct模塊，咱們知道長度數字能夠被轉換成一個標準大小的4字節數字。所以能夠利用這個特色來預先發送數據長度。

發送時	接收時
先發送struct轉換好的數據長度4字節	先接受4個字節使用struct轉換成數字來獲取要接收的數據長度
再發送數據	再按照長度接收數據

咱們還能夠把報頭作成字典，字典裏包含將要發送的真實數據的詳細信息，而後json序列化，而後用struck將序列化後的數據長度打包成4個字節（4個本身足夠用了）

發送時	接收時
先發報頭長度	先收報頭長度，用struct取出來
再編碼報頭內容而後發送	根據取出的長度收取報頭內容，而後解碼，反序列化

四 socketserver

上面用socker啓的服務端，在同一時刻只能接受一個客戶端的連接。

想要一個server端同時爲多個client端服務，該如何處理呢？

import socketserver
import time

class Myserver(socketserver.BaseRequestHandler):  # 必須繼承這個類 socketserver.BaseRequestHandler
    def handle(self):        # 必須重寫這個方法 handle 必須叫這個名字
        conn = self.request
        print(conn)
        time.sleep(3)
        conn.send(b'hello')
        time.sleep(5)
        conn.send(b'hello2')

myserver = socketserver.ThreadingTCPServer(('127.0.0.1', 9000), Myserver)    #實例化，須要把ip,端口和上面寫的類做爲參數傳遞進去
myserver.serve_forever()  ## 啓動server端