開(kāi)始

網(wǎng)絡(luò)中的 Socket 和 Socket API 是用來(lái)跨網(wǎng)絡(luò)的消息傳送的，它提供了 進(jìn)程間通信(IPC) 的一種形式。網(wǎng)絡(luò)可以是邏輯的、本地的電腦網(wǎng)絡(luò)，或者是可以物理連接到外網(wǎng)的網(wǎng)絡(luò)，并且可以連接到其它網(wǎng)絡(luò)。英特網(wǎng)就是一個(gè)明顯的例子，就是那個(gè)你通過(guò) ISP 連接到的網(wǎng)絡(luò)

本篇教程有三個(gè)不同的迭代階段，來(lái)展示如何使用 Python 構(gòu)建一個(gè) Socket 服務(wù)器和客戶端

我們將以一個(gè)簡(jiǎn)單的 Socket 服務(wù)器和客戶端程序來(lái)開(kāi)始本教程

當(dāng)你看完 API 了解例子是怎么運(yùn)行起來(lái)以后，我們將會(huì)看到一個(gè)具有同時(shí)處理多個(gè)連接能力的例子的改進(jìn)版

最后，我們將會(huì)開(kāi)發(fā)出一個(gè)更加完善且具有完整的自定義頭信息和內(nèi)容的 Socket 應(yīng)用

教程結(jié)束后，你將學(xué)會(huì)如何使用 Python 中的 socket 模塊 來(lái)寫(xiě)一個(gè)自己的客戶端/服務(wù)器應(yīng)用。以及向你展示如何在你的應(yīng)用中使用自定義類(lèi)在不同的端之間發(fā)送消息和數(shù)據(jù)

所有的例子程序都使用 Python 3.6 編寫(xiě)，你可以在 Github 上找到 源代碼

網(wǎng)絡(luò)和 Socket 是個(gè)很大的話題。網(wǎng)上已經(jīng)有了關(guān)于它們的字面解釋，如果你還不是很了解 Socket 和網(wǎng)絡(luò)。當(dāng)你你讀到那些解釋的時(shí)候會(huì)感到不知所措，這是非常正常的。因?yàn)槲乙彩沁@樣過(guò)來(lái)的

盡管如此也不要?dú)怵H。 我已經(jīng)為你寫(xiě)了這個(gè)教程。 就像學(xué)習(xí) Python 一樣，我們可以一次學(xué)習(xí)一點(diǎn)。用你的瀏覽器保存本頁(yè)面到書(shū)簽，以便你學(xué)習(xí)下一部分時(shí)能找到

讓我們開(kāi)始吧！

背景

Socket 有一段很長(zhǎng)的歷史，最初是在 1971 年被用于 ARPANET，隨后就成了 1983 年發(fā)布的 Berkeley Software Distribution (BSD) 操作系統(tǒng)的 API，并且被命名為 Berkeleysocket

當(dāng)互聯(lián)網(wǎng)在 20 世紀(jì) 90 年代隨萬(wàn)維網(wǎng)興起時(shí)，網(wǎng)絡(luò)編程也火了起來(lái)。Web 服務(wù)和瀏覽器并不是唯一使用新的連接網(wǎng)絡(luò)和 Socket 的應(yīng)用程序。各種類(lèi)型不同規(guī)模的客戶端/服務(wù)器應(yīng)用都廣泛地使用著它們

時(shí)至今日，盡管 Socket API 使用的底層協(xié)議已經(jīng)進(jìn)化了很多年，也出現(xiàn)了許多新的協(xié)議，但是底層的 API 仍然保持不變

Socket 應(yīng)用最常見(jiàn)的類(lèi)型就是?客戶端/服務(wù)器?應(yīng)用，服務(wù)器用來(lái)等待客戶端的鏈接。我們教程中涉及到的就是這類(lèi)應(yīng)用。更明確地說(shuō)，我們將看到用于 InternetSocket 的 Socket API，有時(shí)稱(chēng)為 Berkeley 或 BSD Socket。當(dāng)然也有 Unix domain sockets —— 一種用于?同一主機(jī)?進(jìn)程間的通信

Socket API 概覽

Python 的 socket 模塊提供了使用 Berkeley sockets API 的接口。這將會(huì)在我們這個(gè)教程里使用和討論到

主要的用到的 Socket API 函數(shù)和方法有下面這些：

• socket()
• bind()
• listen()
• accept()
• connect()
• connect_ex()
• send()
• recv()
• close()

Python 提供了和 C 語(yǔ)言一致且方便的 API。我們將在下面一節(jié)中用到它們

作為標(biāo)準(zhǔn)庫(kù)的一部分，Python 也有一些類(lèi)可以讓我們方便的調(diào)用這些底層 Socket 函數(shù)。盡管這個(gè)教程中并沒(méi)有涉及這部分內(nèi)容，你也可以通過(guò)socketserver 模塊 中找到文檔。當(dāng)然還有很多實(shí)現(xiàn)了高層網(wǎng)絡(luò)協(xié)議（比如：HTTP, SMTP）的的模塊，可以在下面的鏈接中查到 Internet Protocols and Support

TCP Sockets

就如你馬上要看到的，我們將使用 socket.socket() 創(chuàng)建一個(gè)類(lèi)型為 socket.SOCK_STREAM 的 socket 對(duì)象，默認(rèn)將使用 Transmission Control Protocol(TCP) 協(xié)議，這基本上就是你想使用的默認(rèn)值

為什么應(yīng)該使用 TCP 協(xié)議？

• 可靠的：網(wǎng)絡(luò)傳輸中丟失的數(shù)據(jù)包會(huì)被檢測(cè)到并重新發(fā)送
• 有序傳送：數(shù)據(jù)按發(fā)送者寫(xiě)入的順序被讀取

相反，使用 socket.SOCK_DGRAM 創(chuàng)建的 用戶數(shù)據(jù)報(bào)協(xié)議(UDP) Socket 是?不可靠?的，而且數(shù)據(jù)的讀取寫(xiě)發(fā)送可以是?無(wú)序的

為什么這個(gè)很重要？網(wǎng)絡(luò)總是會(huì)盡最大的努力去傳輸完整數(shù)據(jù)（往往不盡人意）。沒(méi)法保證你的數(shù)據(jù)一定被送到目的地或者一定能接收到別人發(fā)送給你的數(shù)據(jù)

網(wǎng)絡(luò)設(shè)備（比如：路由器、交換機(jī)）都有帶寬限制，或者系統(tǒng)本身的極限。它們也有 CPU、內(nèi)存、總線和接口包緩沖區(qū)，就像我們的客戶端和服務(wù)器。TCP 消除了你對(duì)于丟包、亂序以及其它網(wǎng)絡(luò)通信中通常出現(xiàn)的問(wèn)題的顧慮

下面的示意圖中，我們將看到 Socket API 的調(diào)用順序和 TCP 的數(shù)據(jù)流：

?

?

左邊表示服務(wù)器，右邊則是客戶端

左上方開(kāi)始，注意服務(wù)器創(chuàng)建「監(jiān)聽(tīng)」Socket 的 API 調(diào)用：

• socket()
• bind()
• listen()
• accept()

「監(jiān)聽(tīng)」Socket 做的事情就像它的名字一樣。它會(huì)監(jiān)聽(tīng)客戶端的連接，當(dāng)一個(gè)客戶端連接進(jìn)來(lái)的時(shí)候，服務(wù)器將調(diào)用 accept() 來(lái)「接受」或者「完成」此連接

客戶端調(diào)用 connect() 方法來(lái)建立與服務(wù)器的鏈接，并開(kāi)始三次握手。握手很重要是因?yàn)樗ＷC了網(wǎng)絡(luò)的通信的雙方可以到達(dá)，也就是說(shuō)客戶端可以正常連接到服務(wù)器，反之亦然

上圖中間部分往返部分表示客戶端和服務(wù)器的數(shù)據(jù)交換過(guò)程，調(diào)用了 send() 和 recv()方法

下面部分，客戶端和服務(wù)器調(diào)用 close() 方法來(lái)關(guān)閉各自的 socket

打印客戶端和服務(wù)端

現(xiàn)在已經(jīng)了解了基本的 socket API 以及客戶端和服務(wù)器是如何通信的，讓我們來(lái)創(chuàng)建一個(gè)客戶端和服務(wù)器。我們將會(huì)以一個(gè)簡(jiǎn)單的實(shí)現(xiàn)開(kāi)始。服務(wù)器將打印客戶端發(fā)送回來(lái)的內(nèi)容

打印程序服務(wù)端

下面就是服務(wù)器代碼，echo-server.py：

?

注意：上面的代碼你可能還沒(méi)法完全理解，但是不用擔(dān)心。這幾行代碼做了很多事情，這只是一個(gè)起點(diǎn)，幫你看見(jiàn)這個(gè)簡(jiǎn)單的服務(wù)器是如何運(yùn)行的教程后面有引用部分，里面有很多額外的引用資源鏈接，這個(gè)教程中我將把鏈接放在那兒

讓我們一起來(lái)看一下 API 調(diào)用以及發(fā)生了什么

socket.socket() 創(chuàng)建了一個(gè) socket 對(duì)象，并且支持 context manager type，你可以使用 with 語(yǔ)句，這樣你就不用再手動(dòng)調(diào)用 s.close() 來(lái)關(guān)閉 socket 了

?

調(diào)用 socket() 時(shí)傳入的 socket 地址族參數(shù) socket.AF_INET 表示因特網(wǎng) IPv4 地址族，SOCK_STREAM 表示使用 TCP 的 socket 類(lèi)型，協(xié)議將被用來(lái)在網(wǎng)絡(luò)中傳輸消息

bind() 用來(lái)關(guān)聯(lián) socket 到指定的網(wǎng)絡(luò)接口（IP 地址）和端口號(hào)：

?

bind() 方法的入?yún)⑷Q于 socket 的地址族，在這個(gè)例子中我們使用了 socket.AF_INET (IPv4)，它將返回兩個(gè)元素的元組：(host, port)

host 可以是主機(jī)名稱(chēng)、IP 地址、空字符串，如果使用 IP 地址，host 就應(yīng)該是 IPv4 格式的字符串，127.0.0.1 是標(biāo)準(zhǔn)的 IPv4 回環(huán)地址，只有主機(jī)上的進(jìn)程可以連接到服務(wù)器，如果你傳了空字符串，服務(wù)器將接受本機(jī)所有可用的 IPv4 地址

端口號(hào)應(yīng)該是 1-65535 之間的整數(shù)（0是保留的），這個(gè)整數(shù)就是用來(lái)接受客戶端鏈接的 TCP 端口號(hào)，如果端口號(hào)小于 1024，有的操作系統(tǒng)會(huì)要求管理員權(quán)限

使用 bind() 傳參為主機(jī)名稱(chēng)的時(shí)候需要注意：

如果你在 host 部分?主機(jī)名稱(chēng)?作為 IPv4/v6 socket 的地址，程序可能會(huì)產(chǎn)生非確定性的行為，因?yàn)?Python 會(huì)使用 DNS 解析后的?第一個(gè)?地址，根據(jù) DNS 解析的結(jié)果或者 host 配置 socket 地址將會(huì)以不同方式解析為實(shí)際的 IPv4/v6 地址。如果想得到確定的結(jié)果傳入的 host 參數(shù)建議使用數(shù)字格式的地址 引用

我稍后將在 使用主機(jī)名 部分討論這個(gè)問(wèn)題，但是現(xiàn)在也值得一提。目前來(lái)說(shuō)你只需要知道當(dāng)使用主機(jī)名時(shí)，你將會(huì)因?yàn)?DNS 解析的原因得到不同的結(jié)果

可能是任何地址。比如第一次運(yùn)行程序時(shí)是 10.1.2.3，第二次是 192.168.0.1，第三次是 172.16.7.8 等等

繼續(xù)看上面的服務(wù)器代碼示例，listen() 方法調(diào)用使服務(wù)器可以接受連接請(qǐng)求，這使它成為一個(gè)「監(jiān)聽(tīng)中」的 socket

?

listen() 方法有一個(gè) backlog 參數(shù)。它指定在拒絕新的連接之前系統(tǒng)將允許使用的?未接受的連接?數(shù)量。從 Python 3.5 開(kāi)始，這是可選參數(shù)。如果不指定，Python 將取一個(gè)默認(rèn)值

如果你的服務(wù)器需要同時(shí)接收很多連接請(qǐng)求，增加 backlog 參數(shù)的值可以加大等待鏈接請(qǐng)求隊(duì)列的長(zhǎng)度，最大長(zhǎng)度取決于操作系統(tǒng)。比如在 Linux 下，參考 /proc/sys/net/core/somaxconn

accept() 方法阻塞并等待傳入連接。當(dāng)一個(gè)客戶端連接時(shí)，它將返回一個(gè)新的 socket 對(duì)象，對(duì)象中有表示當(dāng)前連接的 conn 和一個(gè)由主機(jī)、端口號(hào)組成的 IPv4/v6 連接的元組，更多關(guān)于元組值的內(nèi)容可以查看 socket 地址族 一節(jié)中的詳情

這里必須要明白我們通過(guò)調(diào)用 accept() 方法擁有了一個(gè)新的 socket 對(duì)象。這非常重要，因?yàn)槟銓⒂眠@個(gè) socket 對(duì)象和客戶端進(jìn)行通信。和監(jiān)聽(tīng)一個(gè) socket 不同的是后者只用來(lái)授受新的連接請(qǐng)求

?

從 accept() 獲取客戶端 socket 連接對(duì)象 conn 后，使用一個(gè)無(wú)限 while 循環(huán)來(lái)阻塞調(diào)用 conn.recv()，無(wú)論客戶端傳過(guò)來(lái)什么數(shù)據(jù)都會(huì)使用 conn.sendall() 打印出來(lái)

如果 conn.recv() 方法返回一個(gè)空 byte 對(duì)象（b''），然后客戶端關(guān)閉連接，循環(huán)結(jié)束，with 語(yǔ)句和 conn 一起使用時(shí)，通信結(jié)束的時(shí)候會(huì)自動(dòng)關(guān)閉 socket 鏈接

打印程序客戶端

現(xiàn)在我們來(lái)看下客戶端的程序， echo-client.py：

?

與服務(wù)器程序相比，客戶端程序簡(jiǎn)單很多。它創(chuàng)建了一個(gè) socket 對(duì)象，連接到服務(wù)器并且調(diào)用 s.sendall() 方法發(fā)送消息，然后再調(diào)用 s.recv() 方法讀取服務(wù)器返回的內(nèi)容并打印出來(lái)

運(yùn)行打印程序的客戶端和服務(wù)端

讓我們運(yùn)行打印程序的客戶端和服務(wù)端，觀察他們的表現(xiàn)，看看發(fā)生了什么事情

如果你在運(yùn)行示例代碼時(shí)遇到了問(wèn)題，可以閱讀 如何使用 Python 開(kāi)發(fā)命令行命令，如果你使用的是 windows 操作系統(tǒng)，請(qǐng)查看 Python Windows FAQ

打開(kāi)命令行程序，進(jìn)入你的代碼所在的目錄，運(yùn)行打印程序的服務(wù)端：

$ ./echo-server.py

你的命令行將被掛起，因?yàn)槌绦蛴幸粋€(gè)阻塞調(diào)用

conn, addr = s.accept()

它將等待客戶端的連接，現(xiàn)在再打開(kāi)一個(gè)命令行窗口運(yùn)行打印程序的客戶端：

?

在服務(wù)端的窗口你將看見(jiàn)：

?

上面的輸出中，服務(wù)端打印出了 s.accept() 返回的 addr 元組，這就是客戶端的 IP 地址和 TCP 端口號(hào)。示例中的端口號(hào)是 64623 這很可能是和你機(jī)器上運(yùn)行的結(jié)果不同

查看 socket 狀態(tài)

想查找你主機(jī)上 socket 的當(dāng)前狀態(tài)，可以使用 netstat 命令。這個(gè)命令在 macOS, Window, Linux 系統(tǒng)上默認(rèn)可用

下面這個(gè)就是啟動(dòng)服務(wù)后 netstat 命令的輸出結(jié)果：

?

注意本地地址是 127.0.0.1.65432，如果 echo-server.py 文件中 HOST 設(shè)置成空字符串 '' 的話，netstat 命令將顯示如下：

?

本地地址是 *.65432，這表示所有主機(jī)支持的 IP 地址族都可以接受傳入連接，在我們的例子里面調(diào)用 socket() 時(shí)傳入的參數(shù) socket.AF_INET 表示使用了 IPv4 的 TCP socket，你可以在輸出結(jié)果中的 Proto 列中看到(tcp4)

上面的輸出是我截取的只顯示了咱們的打印程序服務(wù)端進(jìn)程，你可能會(huì)看到更多輸出，具體取決于你運(yùn)行的系統(tǒng)。需要注意的是 Proto, Local Address 和 state 列。分別表示 TCP socket 類(lèi)型、本地地址端口、當(dāng)前狀態(tài)

另外一個(gè)查看這些信息的方法是使用 lsof 命令，這個(gè)命令在 macOS 上是默認(rèn)安裝的，Linux 上需要你手動(dòng)安裝

?

isof 命令使用 -i 參數(shù)可以查看打開(kāi)的 socket 連接的 COMMAND, PID(process id) 和 USER(user id)，上面的輸出就是打印程序服務(wù)端

netstat 和 isof 命令有許多可用的參數(shù)，這取決于你使用的操作系統(tǒng)。可以使用 man page 來(lái)查看他們的使用文檔，這些文檔絕對(duì)值得花一點(diǎn)時(shí)間去了解，你將受益匪淺，macOS 和 Linux 中使用命令 man netstat 或者 man lsof 命令，windows 下使用 netstat /? 來(lái)查看幫助文檔

一個(gè)通常會(huì)犯的錯(cuò)誤是在沒(méi)有監(jiān)聽(tīng) socket 端口的情況下嘗試連接：

?

也可能是端口號(hào)出錯(cuò)、服務(wù)端沒(méi)啟動(dòng)或者有防火墻阻止了連接，這些原因可能很難記住，或許你也會(huì)碰到 Connection timed out 的錯(cuò)誤，記得給你的防火墻添加允許我們使用的端口規(guī)則

引用部分有一些常見(jiàn)的 錯(cuò)誤

通信的流程分解

讓我們?cè)僮屑?xì)的觀察下客戶端是如何與服務(wù)端進(jìn)行通信的：

?

?

?

當(dāng)使用回環(huán)地址時(shí)，數(shù)據(jù)將不會(huì)接觸到外部網(wǎng)絡(luò)，上圖中，回環(huán)地址包含在了 host 里面。這就是回環(huán)地址的本質(zhì)，連接數(shù)據(jù)傳輸是從本地到主機(jī)，這就是為什么你會(huì)聽(tīng)到有回環(huán)地址或者 127.0.0.1、::1 的 IP 地址和表示本地主機(jī)

應(yīng)用程序使用回環(huán)地址來(lái)與主機(jī)上的其它進(jìn)程通信，這使得它與外部網(wǎng)絡(luò)安全隔離。由于它是內(nèi)部的，只能從主機(jī)內(nèi)訪問(wèn)，所以它不會(huì)被暴露出去

如果你的應(yīng)用程序服務(wù)器使用自己的專(zhuān)用數(shù)據(jù)庫(kù)（非公用的），則可以配置服務(wù)器僅監(jiān)聽(tīng)回環(huán)地址，這樣的話網(wǎng)絡(luò)上的其它主機(jī)就無(wú)法連接到你的數(shù)據(jù)庫(kù)

如果你的應(yīng)用程序中使用的 IP 地址不是 127.0.0.1 或者 ::1，那就可能會(huì)綁定到連接到外部網(wǎng)絡(luò)的以太網(wǎng)上。這就是你通往 localhost 王國(guó)之外的其他主機(jī)的大門(mén)

?

?

?

這里需要小心，并且可能讓你感到難受甚至懷疑全世界。在你探索 localhost 的安全限制之前，確認(rèn)讀過(guò) 使用主機(jī)名 一節(jié)。 一個(gè)安全注意事項(xiàng)是 **不要使用主機(jī)名，要使用

IP 地址**

處理多個(gè)連接

打印程序的服務(wù)端肯定有它自己的一些局限。這個(gè)程序只能服務(wù)于一個(gè)客戶端然后結(jié)束。打印程序的客戶端也有它自己的局限，但是還有一個(gè)問(wèn)題，如果客戶端調(diào)用了下面的方法s.recv() 方法將返回 b'Hello, world' 中的一個(gè)字節(jié) b'H'

data = s.recv(1024)

1024 是緩沖區(qū)數(shù)據(jù)大小限制最大值參數(shù) bufsize，并不是說(shuō) recv() 方法只返回 1024個(gè)字節(jié)的內(nèi)容

send() 方法也是這個(gè)原理，它返回發(fā)送內(nèi)容的字節(jié)數(shù)，結(jié)果可能小于傳入的發(fā)送內(nèi)容，你得處理這處情況，按需多次調(diào)用 send() 方法來(lái)發(fā)送完整的數(shù)據(jù)

應(yīng)用程序負(fù)責(zé)檢查是否已發(fā)送所有數(shù)據(jù)；如果僅傳輸了一些數(shù)據(jù)，則應(yīng)用程序需要嘗試傳遞剩余數(shù)據(jù) 引用

我們可以使用 sendall() 方法來(lái)回避這個(gè)過(guò)程

和 send() 方法不一樣的是，sendall() 方法會(huì)一直發(fā)送字節(jié)，只到所有的數(shù)據(jù)傳輸完成或者中途出現(xiàn)錯(cuò)誤。成功的話會(huì)返回 None 引用

到目前為止，我們有兩個(gè)問(wèn)題：

• 如何同時(shí)處理多個(gè)連接請(qǐng)求
• 我們需要一直調(diào)用 send() 或者 recv() 直到所有數(shù)據(jù)傳輸完成

應(yīng)該怎么做呢，有很多方式可以實(shí)現(xiàn)并發(fā)。最近，有一個(gè)非常流程的庫(kù)叫做 Asynchronous I/O 可以實(shí)現(xiàn)，asyncio 庫(kù)在 Python 3.4 后默認(rèn)添加到了標(biāo)準(zhǔn)庫(kù)里面。傳統(tǒng)的方法是使用線程

并發(fā)的問(wèn)題是很難做到正確，有許多細(xì)微之處需要考慮和防范。可能其中一個(gè)細(xì)節(jié)的問(wèn)題都會(huì)導(dǎo)致整個(gè)程序崩潰

我說(shuō)這些并不是想嚇跑你或者讓你遠(yuǎn)離學(xué)習(xí)和使用并發(fā)編程。如果你想讓程序支持大規(guī)模使用，使用多處理器、多核是很有必要的。然而在這個(gè)教程中我們將使用比線程更傳統(tǒng)的方法使得邏輯更容易推理。我們將使用一個(gè)非常古老的系統(tǒng)調(diào)用：select()

select() 允許你檢查多個(gè) socket 的 I/O 完成情況，所以你可以使用它來(lái)檢測(cè)哪個(gè) socket I/O 是就緒狀態(tài)從而執(zhí)行讀取或?qū)懭氩僮?#xff0c;但是這是 Python，總會(huì)有更多其它的選擇，我們將使用標(biāo)準(zhǔn)庫(kù)中的selectors 模塊，所以我們使用了最有效的實(shí)現(xiàn)，不用在意你使用的操作系統(tǒng)：

這個(gè)模塊提供了高層且高效的 I/O 多路復(fù)用，基于原始的 select 模塊構(gòu)建，推薦用戶使用這個(gè)模塊，除非他們需要精確到操作系統(tǒng)層面的使用控制 [引用](https://docs.python.org/3/lib...

盡管如此，使用 select() 也無(wú)法并發(fā)執(zhí)行。這取決于您的工作負(fù)載，這種實(shí)現(xiàn)仍然會(huì)很快。這也取決于你的應(yīng)用程序?qū)B接所做的具體事情或者它需要支持的客戶端數(shù)量

asyncio 使用單線程來(lái)處理多任務(wù)，使用事件循環(huán)來(lái)管理任務(wù)。通過(guò)使用 select()，我們可以創(chuàng)建自己的事件循環(huán)，更簡(jiǎn)單且同步化。當(dāng)使用多線程時(shí)，即使要處理并發(fā)的情況，我們也不得不面臨使用 CPython 或者 PyPy 中的「全局解析器鎖 GIL」，這有效地限制了我們可以并行完成的工作量

說(shuō)這些是為了解析為什么使用 select() 可能是個(gè)更好的選擇，不要覺(jué)得你必須使用 asyncio、線程或最新的異步庫(kù)。通常，在網(wǎng)絡(luò)應(yīng)用程序中，你的應(yīng)用程序就是 I/O 綁定：它可以在本地網(wǎng)絡(luò)上，網(wǎng)絡(luò)另一端的端，磁盤(pán)上等待

如果你從客戶端收到啟動(dòng) CPU 綁定工作的請(qǐng)求，查看 concurrent.futures模塊，它包含一個(gè) ProcessPoolExecutor 類(lèi)，用來(lái)異步執(zhí)行進(jìn)程池中的調(diào)用

如果你使用多進(jìn)程，你的 Python 代碼將被操作系統(tǒng)并行地在不同處理器或者核心上調(diào)度運(yùn)行，并且沒(méi)有全局解析器鎖。你可以通過(guò)

Python 大會(huì)上的演講 John Reese - Thinking Outside the GIL with AsyncIO and Multiprocessing - PyCon 2018 來(lái)了解更多的想法

在下一節(jié)中，我們將介紹解決這些問(wèn)題的服務(wù)器和客戶端的示例。他們使用 select() 來(lái)同時(shí)處理多連接請(qǐng)求，按需多次調(diào)用 send() 和 recv()

多連接的客戶端和服務(wù)端

下面兩節(jié)中，我們將使用 selectors 模塊中的 selector 對(duì)象來(lái)創(chuàng)建一個(gè)可以同時(shí)處理多個(gè)請(qǐng)求的客戶端和服務(wù)端

多連接的服務(wù)端

首頁(yè)，我們來(lái)看眼多連接服務(wù)端程序的代碼，multiconn-server.py。這是開(kāi)始建立監(jiān)聽(tīng) socket 部分

?

這個(gè)程序和之前打印程序服務(wù)端最大的不同是使用了 lsock.setblocking(False) 配置 socket 為非阻塞模式，這個(gè) socket 的調(diào)用將不在是阻塞的。當(dāng)它和 sel.select() 一起使用的時(shí)候（下面會(huì)提到），我們就可以等待 socket 就緒事件，然后執(zhí)行讀寫(xiě)操作

sel.register() 使用 sel.select() 為你感興趣的事件注冊(cè) socket 監(jiān)控，對(duì)于監(jiān)聽(tīng) socket，我們希望使用 selectors.EVENT_READ 讀取到事件

data 用來(lái)存儲(chǔ)任何你 socket 中想存的數(shù)據(jù)，當(dāng) select() 返回的時(shí)候它也會(huì)返回。我們將使用 data 來(lái)跟蹤 socket 上發(fā)送或者接收的東西

下面就是事件循環(huán)：

?

sel.select(timeout=None) 調(diào)用會(huì)阻塞直到 socket I/O 就緒。它返回一個(gè)(key, events) 元組，每個(gè) socket 一個(gè)。key 就是一個(gè)包含 fileobj 屬性的具名元組。key.fileobj 是一個(gè) socket 對(duì)象，mask 表示一個(gè)操作就緒的事件掩碼

如果 key.data 為空，我們就可以知道它來(lái)自于監(jiān)聽(tīng) socket，我們需要調(diào)用 accept() 方法來(lái)授受連接請(qǐng)求。我們將使用一個(gè) accept() 包裝函數(shù)來(lái)獲取新的 socket 對(duì)象并注冊(cè)到 selector 上，我們馬上就會(huì)看到

如果 key.data 不為空，我們就可以知道它是一個(gè)被接受的客戶端 socket，我們需要為它服務(wù)，接著 service_connection() 會(huì)傳入 key 和 mask 參數(shù)并調(diào)用，這包含了所有我們需要在 socket 上操作的東西

讓我們一起來(lái)看看 accept_wrapper() 方法做了什么：

?

由于監(jiān)聽(tīng) socket 被注冊(cè)到了 selectors.EVENT_READ 上，它現(xiàn)在就能被讀取，我們調(diào)用 sock.accept() 后立即再立即調(diào) conn.setblocking(False) 來(lái)讓 socket 進(jìn)入非阻塞模式

請(qǐng)記住，這是這個(gè)版本服務(wù)器程序的主要目標(biāo)，因?yàn)槲覀儾幌Ｍ蛔枞Ｈ绻蛔枞?#xff0c;那么整個(gè)服務(wù)器在返回前都處于掛起狀態(tài)。這意味著其它 socket 處于等待狀態(tài)，這是一種?非常嚴(yán)重的?誰(shuí)都不想見(jiàn)到的服務(wù)被掛起的狀態(tài)

接著我們使用了 types.SimpleNamespace 類(lèi)創(chuàng)建了一個(gè)對(duì)象用來(lái)保存我們想要的 socket 和數(shù)據(jù)，由于我們得知道客戶端連接什么時(shí)候可以寫(xiě)入或者讀取，下面兩個(gè)事件都會(huì)被用到：

events = selectors.EVENT_READ | selectors.EVENT_WRITE

事件掩碼、socket 和數(shù)據(jù)對(duì)象都會(huì)被傳入 sel.register()

現(xiàn)在讓我們來(lái)看下，當(dāng)客戶端 socket 就緒的時(shí)候連接請(qǐng)求是如何使用 service_connection() 來(lái)處理的

?

這就是多連接服務(wù)端的核心部分，key 就是從調(diào)用 select() 方法返回的一個(gè)具名元組，它包含了 socket 對(duì)象「fileobj」和數(shù)據(jù)對(duì)象。mask 包含了就緒的事件

如果 socket 就緒而且可以被讀取， mask & selectors.EVENT_READ 就為真，sock.recv() 會(huì)被調(diào)用。所有讀取到的數(shù)據(jù)都會(huì)被追加到 data.outb 里面。隨后被發(fā)送出去

注意 else: 語(yǔ)句，如果沒(méi)有收到任何數(shù)據(jù)：

?

這表示客戶端關(guān)閉了它的 socket 連接，這時(shí)服務(wù)端也應(yīng)該關(guān)閉自己的連接。不過(guò)別忘了先調(diào)用 sel.unregister() 來(lái)撤銷(xiāo) select() 的監(jiān)控

當(dāng) socket 就緒而且可以被讀取的時(shí)候，對(duì)于正常的 socket 應(yīng)該一直是這種狀態(tài)，任何接收并被 data.outb 存儲(chǔ)的數(shù)據(jù)都將使用 sock.send() 方法打印出來(lái)。發(fā)送出去的字節(jié)隨后就會(huì)被從緩沖中刪除

data.outb = data.outb[sent:]

多連接的客戶端

現(xiàn)在讓我們一起來(lái)看看多連接的客戶端程序，multiconn-client.py，它和服務(wù)端很相似，不一樣的是它沒(méi)有監(jiān)聽(tīng)連接請(qǐng)求，它以調(diào)用 start_connections() 開(kāi)始初始化連接：

?

num_conns 參數(shù)是從命令行讀取的，表示為服務(wù)器建立多少個(gè)鏈接。就像服務(wù)端程序一樣，每個(gè) socket 都設(shè)置成了非阻塞模式

由于 connect() 方法會(huì)立即觸發(fā)一個(gè) BlockingIOError 異常，所以我們使用 connect_ex() 方法取代它。connect_ex()會(huì)返回一個(gè)錯(cuò)誤指示 errno.EINPROGRESS，不像 connect() 方法直接在進(jìn)程中返回異常。一旦連接結(jié)束，socket 就可以進(jìn)行讀寫(xiě)并且通過(guò) select() 方法返回

socket 建立完成后，我們將使用 types.SimpleNamespace 類(lèi)創(chuàng)建想會(huì)傳送的數(shù)據(jù)。由于每個(gè)連接請(qǐng)求都會(huì)調(diào)用 socket.send()，發(fā)送到服務(wù)端的消息得使用 list(messages) 方法轉(zhuǎn)換成列表結(jié)構(gòu)。所有你想了解的東西，包括客戶端將要發(fā)送的、已發(fā)送的、已接收的消息以及消息的總字節(jié)數(shù)都存儲(chǔ)在 data 對(duì)象中

讓我們?cè)賮?lái)看看 service_connection()。基本上和服務(wù)端一樣：

?

有一個(gè)不同的地方，客戶端會(huì)跟蹤從服務(wù)器接收的字節(jié)數(shù)，根據(jù)結(jié)果來(lái)決定是否關(guān)閉 socket 連接，服務(wù)端檢測(cè)到客戶端關(guān)閉則會(huì)同樣的關(guān)閉服務(wù)端的連接

運(yùn)行多連接的客戶端和服務(wù)端

現(xiàn)在讓我們把 multiconn-server.py 和 multiconn-client.py 兩個(gè)程序跑起來(lái)。他們都使用了命令行參數(shù)，如果不指定參數(shù)可以看到參數(shù)調(diào)用的方法：

服務(wù)端程序，傳入主機(jī)和端口號(hào)

?

客戶端程序，傳入啟動(dòng)服務(wù)端程序時(shí)同樣的主機(jī)和端口號(hào)以及連接數(shù)量

?

下面就是服務(wù)端程序運(yùn)行起來(lái)在 65432 端口上監(jiān)聽(tīng)回環(huán)地址的輸出：

?

下面是客戶端，它創(chuàng)建了兩個(gè)連接請(qǐng)求到上面的服務(wù)端：

?

應(yīng)用程序客戶端和服務(wù)端

多連接的客戶端和服務(wù)端程序版本與最早的原始版本相比肯定有了很大的改善，但是讓我們?cè)龠M(jìn)一步地解決上面「多連接」版本中的不足，然后完成最終版的實(shí)現(xiàn)：客戶端/服務(wù)器應(yīng)用程序

我們希望有個(gè)客戶端和服務(wù)端在不影響其它連接的情況下做好錯(cuò)誤處理，顯然，如果沒(méi)有發(fā)生異常，我們的客戶端和服務(wù)端不能崩潰的一團(tuán)糟。這也是到現(xiàn)在為止我們還沒(méi)討論的東西，我故意沒(méi)有引入錯(cuò)誤處理機(jī)制因?yàn)檫@樣可以使之前的程序容易理解

現(xiàn)在你對(duì)基本的 API，非阻塞 socket、select() 等概念已經(jīng)有所了解了。我們可以繼續(xù)添加一些錯(cuò)誤處理同時(shí)討論下「房間里面的大象」的問(wèn)題，我把一些東西隱藏在了幕后。你應(yīng)該還記得，我在介紹中討論到的自定義類(lèi)

首先，讓我們先解決錯(cuò)誤：

所有的錯(cuò)誤都會(huì)觸發(fā)異常，像無(wú)效參數(shù)類(lèi)型和內(nèi)存不足的常見(jiàn)異常可以被拋出；從 Python3.3 開(kāi)始，與 socket 或地址語(yǔ)義相關(guān)的錯(cuò)誤會(huì)引發(fā) OSError 或其子類(lèi)之一的異常 引用

我們需要捕獲 OSError 異常。另外一個(gè)我沒(méi)提及的的問(wèn)題是延遲，你將在文檔的很多地方看見(jiàn)關(guān)于延遲的討論，延遲會(huì)發(fā)生而且屬于「正常」錯(cuò)誤。主機(jī)或者路由器重啟、交換機(jī)端口出錯(cuò)、電纜出問(wèn)題或者被拔出，你應(yīng)該在你的代碼中處理好各種各樣的錯(cuò)誤

剛才說(shuō)的「房間里面的大象」問(wèn)題是怎么回事呢。就像 socket.SOCK_STREAM 這個(gè)參數(shù)的字面意思一樣，當(dāng)使用 TCP 連接時(shí)，你會(huì)從一個(gè)連續(xù)的字節(jié)流讀取的數(shù)據(jù)，好比從磁盤(pán)上讀取數(shù)據(jù)，不同的是你是從網(wǎng)絡(luò)讀取字節(jié)流

然而，和使用 f.seek() 讀文件不同，換句話說(shuō)，沒(méi)法定位 socket 的數(shù)據(jù)流的位置，如果可以像文件一樣定位數(shù)據(jù)流的位置（使用下標(biāo)），那你就可以隨意的讀取你想要的數(shù)據(jù)

當(dāng)字節(jié)流入你的 socket 時(shí)，會(huì)需要有不同的網(wǎng)絡(luò)緩沖區(qū)，如果想讀取他們就必須先保存到其它地方，使用 recv() 方法持續(xù)的從 socket 上讀取可用的字節(jié)流

相當(dāng)于你從 socket 中讀取的是一塊一塊的數(shù)據(jù)，你必須使用 recv() 方法不斷的從緩沖區(qū)中讀取數(shù)據(jù)，直到你的應(yīng)用確定讀取到了足夠的數(shù)據(jù)

什么時(shí)候算「足夠」這取決于你的定義，就 TCP socket 而言，它只通過(guò)網(wǎng)絡(luò)發(fā)送或接收原始字節(jié)。它并不了解這些原始字節(jié)的含義

這可以讓我們定義一個(gè)應(yīng)用層協(xié)議，什么是應(yīng)用層協(xié)議？簡(jiǎn)單來(lái)說(shuō)，你的應(yīng)用會(huì)發(fā)送或者接收消息，這些消息其實(shí)就是你的應(yīng)用程序的協(xié)議

換句話說(shuō)，這些消息的長(zhǎng)度、格式可以定義應(yīng)用程序的語(yǔ)義和行為，這和我們之前說(shuō)的從socket 中讀取字節(jié)部分內(nèi)容相關(guān)，當(dāng)你使用 recv() 來(lái)讀取字節(jié)的時(shí)候，你需要知道讀的字節(jié)數(shù)，并且決定什么時(shí)候算讀取完成

這些都是怎么完成的呢？一個(gè)方法是只讀取固定長(zhǎng)度的消息，如果它們的長(zhǎng)度總是一樣的話，這樣做很容易。當(dāng)你收到固定長(zhǎng)度字節(jié)消息的時(shí)候，就能確定它是個(gè)完整的消息

然而，如果你使用定長(zhǎng)模式來(lái)發(fā)送比較短的消息會(huì)比較低效，因?yàn)槟氵€得處理填充剩余的部分，此外，你還得處理數(shù)據(jù)不適合放在一個(gè)定長(zhǎng)消息里面的情況

在這個(gè)教程里面，我們將使用一個(gè)通用的方案，很多協(xié)議都會(huì)用到它，包括 HTTP。我們將在每條消息前面追加一個(gè)頭信息，頭信息中包括消息的長(zhǎng)度和其它我們需要的字段。這樣做的話我們只需要追蹤頭信息，當(dāng)我們讀到頭信息時(shí)，就可以查到消息的長(zhǎng)度并且讀出所有字節(jié)然后消費(fèi)它

我們將通過(guò)使用一個(gè)自定義類(lèi)來(lái)實(shí)現(xiàn)接收文本/二進(jìn)制數(shù)據(jù)。你可以在此基礎(chǔ)上做出改進(jìn)或者通過(guò)繼承這個(gè)類(lèi)來(lái)擴(kuò)展你的應(yīng)用程序。重要的是你將看到一個(gè)例子實(shí)現(xiàn)它的過(guò)程

我將會(huì)提到一些關(guān)于 socket 和字節(jié)相關(guān)的東西，就像之前討論過(guò)的。當(dāng)你通過(guò) socket 來(lái)發(fā)送或者接收數(shù)據(jù)時(shí)，其實(shí)你發(fā)送或者接收到的是原始字節(jié)

如果你收到數(shù)據(jù)并且想讓它在一個(gè)多字節(jié)解釋的上下文中使用，比如說(shuō) 4-byte 的整形，你需要考慮它可能是一種不是你機(jī)器 CPU 本機(jī)的格式。客戶端或者服務(wù)器的另外一頭可能是另外一種使用了不同的字節(jié)序列的 CPU，這樣的話，你就得把它們轉(zhuǎn)換成你主機(jī)的本地字節(jié)序列來(lái)使用

上面所說(shuō)的字節(jié)順序就是 CPU 的 字節(jié)序，在引用部分的字節(jié)序 一節(jié)可以查看更多。我們將會(huì)利用 Unicode 字符集的優(yōu)點(diǎn)來(lái)規(guī)避這個(gè)問(wèn)題，并使用UTF-8 的方式編碼，由于 UTF-8 使用了 8字節(jié) 編碼方式，所以就不會(huì)有字節(jié)序列的問(wèn)題

你可以查看 Python 關(guān)于編碼與 Unicode 的 文檔，注意我們只會(huì)編碼消息的頭部。我們將使用嚴(yán)格的類(lèi)型，發(fā)送的消息編碼格式會(huì)在頭信息中定義。這將讓我們可以傳輸我們覺(jué)得有用的任意類(lèi)型/格式數(shù)據(jù)

你可以通過(guò)調(diào)用 sys.byteorder 來(lái)決定你的機(jī)器的字節(jié)序列，比如在我的英特爾筆記本上，運(yùn)行下面的代碼就可以：

$ python3 -c 'import sys; print(repr(sys.byteorder))'
'little'

如果我把這段代碼跑在可以模擬大字節(jié)序 CPU「PowerPC」的虛擬機(jī)上的話，應(yīng)該是下面的結(jié)果：

$ python3 -c 'import sys; print(repr(sys.byteorder))'
'big'

?

在我們的例子程序中，應(yīng)用層的協(xié)議定義了使用 UTF-8 方式編碼的 Unicode 字符。對(duì)于真正傳輸消息來(lái)說(shuō)，如果需要的話你還是得手動(dòng)交換字節(jié)序列

這取決于你的應(yīng)用，是否需要它來(lái)處理不同終端間的多字節(jié)二進(jìn)制數(shù)據(jù)，你可以通過(guò)添加額外的頭信息來(lái)讓你的客戶端或者服務(wù)端支持二進(jìn)制，像 HTTP 一樣，把頭信息做為參數(shù)傳進(jìn)去

不用擔(dān)心自己還沒(méi)搞懂上面的東西，下面一節(jié)我們看到是如果實(shí)現(xiàn)的

應(yīng)用的協(xié)議頭

讓我們來(lái)定義一個(gè)完整的協(xié)議頭：

• 可變長(zhǎng)度的文本
• 基于 UTF-8 編碼的 Unicode 字符集
• 使用 JSON 序列化的一個(gè) Python 字典

其中必須具有的頭應(yīng)該有以下幾個(gè)：

?

這些頭信息告訴接收者消息數(shù)據(jù)，這樣的話你就可以通過(guò)提供給接收者足夠的信息讓他接收到數(shù)據(jù)的時(shí)候正確的解碼的方式向它發(fā)送任何數(shù)據(jù)，由于頭信息是字典格式，你可以隨意向頭信息中添加鍵值對(duì)

發(fā)送應(yīng)用程序消息

不過(guò)還有一個(gè)問(wèn)題，由于我們使用了變長(zhǎng)的頭信息，雖然方便擴(kuò)展但是當(dāng)你使用 recv() 方法讀取消息的時(shí)候怎么知道頭信息的長(zhǎng)度呢

我們前面講到過(guò)使用 recv() 接收數(shù)據(jù)和如何確定是否接收完成，我說(shuō)過(guò)定長(zhǎng)的頭可能會(huì)很低效，的確如此。但是我們將使用一個(gè)比較小的 2 字節(jié)定長(zhǎng)的頭信息前綴來(lái)表示頭信息的長(zhǎng)度

你可以認(rèn)為這是一種混合的發(fā)送消息的實(shí)現(xiàn)方法，我們通過(guò)發(fā)送頭信息長(zhǎng)度來(lái)引導(dǎo)接收者，方便他們解析消息體

為了給你更好地解釋消息格式，讓我們來(lái)看看消息的全貌：

?

?

?

消息以 2字節(jié)的固定長(zhǎng)度的頭開(kāi)始，這兩個(gè)字節(jié)是整型的網(wǎng)絡(luò)字節(jié)序列，表示下面的變長(zhǎng) JSON 頭信息的長(zhǎng)度，當(dāng)我們從 recv() 方法讀取到 2 個(gè)字節(jié)時(shí)就知道它表示的是頭信息長(zhǎng)度的整形數(shù)字，然后在解碼 JSON 頭之前讀取這么多的字節(jié)

JSON 頭包含了頭信息的字典。其中一個(gè)就是 content-length，這表示消息內(nèi)容的數(shù)量（不是JSON頭），當(dāng)我們使用 recv() 方法讀取到了 content-length 個(gè)字節(jié)的數(shù)據(jù)時(shí)，就表示接收完成并且讀取到了完整的消息

應(yīng)用程序類(lèi)

最后讓我們來(lái)看下成果，我們使用了一個(gè)消息類(lèi)。來(lái)看看它是如何在 socket 發(fā)生讀寫(xiě)事件時(shí)與 select() 配合使用的

對(duì)于這個(gè)示例應(yīng)用程序而言，我必須想出客戶端和服務(wù)器將使用什么類(lèi)型的消息，從這一點(diǎn)來(lái)講這遠(yuǎn)遠(yuǎn)超過(guò)了最早時(shí)候我們寫(xiě)的那個(gè)玩具一樣的打印程序

為了保證程序簡(jiǎn)單而且仍然能夠演示出它是如何在一個(gè)真正的程序中工作的，我創(chuàng)建了一個(gè)應(yīng)用程序協(xié)議用來(lái)實(shí)現(xiàn)基本的搜索功能。客戶端發(fā)送一個(gè)搜索請(qǐng)求，服務(wù)器做一次匹配的查找，如果客戶端的請(qǐng)求沒(méi)法被識(shí)別成搜索請(qǐng)求，服務(wù)器就會(huì)假定這個(gè)是二進(jìn)制請(qǐng)求，對(duì)應(yīng)的返回二進(jìn)制響應(yīng)

跟著下面一節(jié)，運(yùn)行示例、用代碼做實(shí)驗(yàn)后你將會(huì)知道他是如何工作的，然后你就可以以這個(gè)消息類(lèi)為起點(diǎn)把他修改成適合自己使用的

就像我們之前討論的，你將在下面看到，處理 socket 時(shí)需要保存狀態(tài)。通過(guò)使用類(lèi)，我們可以將所有的狀態(tài)、數(shù)據(jù)和代碼打包到一個(gè)地方。當(dāng)連接開(kāi)始或者接受的時(shí)候消息類(lèi)就會(huì)為每個(gè) socket 創(chuàng)建一個(gè)實(shí)例

類(lèi)中的很多包裝方法、工具方法在客戶端和服務(wù)端上都是差不多的。它們以下劃線開(kāi)頭，就像 Message._json_encode() 一樣，這些方法通過(guò)類(lèi)使用起來(lái)很簡(jiǎn)單。這使得它們?cè)谄渌椒ㄖ姓{(diào)用時(shí)更短，而且符合 DRY 原則

消息類(lèi)的服務(wù)端程序本質(zhì)上和客戶端一樣。不同的是客戶端初始化連接并發(fā)送請(qǐng)求消息，隨后要處理服務(wù)端返回的內(nèi)容。而服務(wù)端則是等待連接請(qǐng)求，處理客戶端的請(qǐng)求消息，隨后發(fā)送響應(yīng)消息

看起來(lái)就像這樣：

?

下面是代碼的結(jié)構(gòu)：

?

消息入口點(diǎn)

我想通過(guò)首先提到它的設(shè)計(jì)方面來(lái)討論 Message 類(lèi)的工作方式，不過(guò)這對(duì)我來(lái)說(shuō)并不是立馬就能解釋清楚的，只有在重構(gòu)它至少五次之后我才能達(dá)到它目前的狀態(tài)。為什么呢？因?yàn)橐芾頎顟B(tài)

當(dāng)消息對(duì)象創(chuàng)建的時(shí)候，它就被一個(gè)使用 selector.register() 事件監(jiān)控起來(lái)的 socket 關(guān)聯(lián)起來(lái)了

?

注意，這一節(jié)中的一些代碼來(lái)自服務(wù)端主程序與消息類(lèi)，但是這部分內(nèi)容的討論在客戶端也是一樣的，我將在他們之間存在不同點(diǎn)的時(shí)候來(lái)解釋客戶端的版本

當(dāng) socket 上的事件就緒的時(shí)候，它就會(huì)被 selector.select() 方法返回。對(duì)過(guò) key 對(duì)象的 data 屬性獲取到 message 的引用，然后在消息用調(diào)用一個(gè)方法：

?

觀察上面的事件循環(huán)，可以看見(jiàn) sel.select() 位于「司機(jī)位置」，它是阻塞的，在循環(huán)的上面等待。當(dāng) socket 上的讀寫(xiě)事件就緒時(shí)，它就會(huì)為其服務(wù)。這表示間接的它也要負(fù)責(zé)調(diào)用 process_events() 方法。這就是我說(shuō) process_events() 方法是入口的原因

讓我們來(lái)看下 process_events() 方法做了什么

?

這樣做很好，因?yàn)?process_events() 方法很簡(jiǎn)潔，它只可以做兩件事情：調(diào)用 read() 和 write() 方法

這又把我們帶回了狀態(tài)管理的問(wèn)題。在幾次重構(gòu)后，我決定如果別的方法依賴于狀態(tài)變量里面的某個(gè)確定值，那么它們就只應(yīng)該從 read() 和 write() 方法中調(diào)用，這將使處理socket 事件的邏輯盡量的簡(jiǎn)單

可能說(shuō)起來(lái)很簡(jiǎn)單，但是經(jīng)歷了前面幾次類(lèi)的迭代：混合了一些方法，檢查當(dāng)前狀態(tài)、依賴于其它值、在 read() 或者 write() 方法外面調(diào)用處理數(shù)據(jù)的方法，最后這證明了這樣管理起來(lái)很復(fù)雜

當(dāng)然，你肯定需要把類(lèi)按你自己的需求修改使它能夠符合你的預(yù)期，但是我建議你盡可能把狀態(tài)檢查、依賴狀態(tài)的調(diào)用的邏輯放在 read() 和 write() 方法里面

讓我們來(lái)看看 read() 方法，這是服務(wù)端版本，但是客戶端也是一樣的。不同之處在于方法名稱(chēng)，一個(gè)（客戶端）是 process_response() 另一個(gè)（服務(wù)端）是 process_request()

?

_read() 方法首頁(yè)被調(diào)用，然后調(diào)用 socket.recv() 從 socket 讀取數(shù)據(jù)并存入到接收緩沖區(qū)

記住，當(dāng)調(diào)用 socket.recv() 方法時(shí)，組成消息的所有數(shù)據(jù)并沒(méi)有一次性全部到達(dá)。socket.recv() 方法可能需要調(diào)用很多次，這就是為什么在調(diào)用相關(guān)方法處理數(shù)據(jù)前每次都要檢查狀態(tài)

當(dāng)一個(gè)方法開(kāi)始處理消息時(shí)，首頁(yè)要檢查的就是接受緩沖區(qū)保存了足夠的多讀取的數(shù)據(jù)，如果確定，它們將繼續(xù)處理各自的數(shù)據(jù)，然后把數(shù)據(jù)存到其它流程可能會(huì)用到的變量上，并且清空自己的緩沖區(qū)。由于一個(gè)消息有三個(gè)組件，所以會(huì)有三個(gè)狀態(tài)檢查和處理方法的調(diào)用：

?

接下來(lái)，讓我們一起看看 write() 方法，這是服務(wù)端的版本：

?

write() 方法會(huì)首先檢測(cè)是否有請(qǐng)求，如果有而且響應(yīng)還沒(méi)被創(chuàng)建的話 create_response() 方法就會(huì)被調(diào)用，它會(huì)設(shè)置狀態(tài)變量 response_created，然后為發(fā)送緩沖區(qū)寫(xiě)入響應(yīng)

如果發(fā)送緩沖區(qū)有數(shù)據(jù)，write() 方法會(huì)調(diào)用 socket.send() 方法

記住，當(dāng) socket.send() 被調(diào)用時(shí)，所有發(fā)送緩沖區(qū)的數(shù)據(jù)可能還沒(méi)進(jìn)入到發(fā)送隊(duì)列，socket 的網(wǎng)絡(luò)緩沖區(qū)可能滿了，socket.send() 可能需要重新調(diào)用，這就是為什么需要檢查狀態(tài)的原因，create_response() 應(yīng)該只被調(diào)用一次，但是 _write() 方法需要調(diào)用多次

客戶端的 write() 版大體與服務(wù)端一致：

?

因?yàn)榭蛻舳耸醉?yè)初始化了一個(gè)連接請(qǐng)求到服務(wù)端，狀態(tài)變量_request_queued被檢查。如果請(qǐng)求還沒(méi)加入到隊(duì)列，就調(diào)用 queue_request() 方法創(chuàng)建一個(gè)請(qǐng)求寫(xiě)入到發(fā)送緩沖區(qū)中，同時(shí)也會(huì)使用變量 _request_queued 記錄狀態(tài)值防止多次調(diào)用

就像服務(wù)端一樣，如果發(fā)送緩沖區(qū)有數(shù)據(jù) _write() 方法會(huì)調(diào)用 socket.send() 方法

需要注意客戶端版本的 write() 方法與服務(wù)端不同之處在于最后的請(qǐng)求是否加入到隊(duì)列中的檢查，這個(gè)我們將在客戶端主程序中詳細(xì)解釋，原因是要告訴 selector.select()停止監(jiān)控 socket 的寫(xiě)入事件而且我們只對(duì)讀取事件感興趣，沒(méi)有辦法通知套接字是可寫(xiě)的

我將在這一節(jié)中留下一個(gè)懸念，這一節(jié)的主要目的是解釋 selector.select() 方法是如何通過(guò) process_events() 方法調(diào)用消息類(lèi)以及它是如何工作的

這一點(diǎn)很重要，因?yàn)?process_events() 方法在連接的生命周期中將被調(diào)用很多次，因此，要確保那些只能被調(diào)用一次的方法正常工作，這些方法中要么需要檢查自己的狀態(tài)變量，要么需要檢查調(diào)用者的方法中的狀態(tài)變量

服務(wù)端主程序

在服務(wù)端主程序 app-server.py 中，主機(jī)、端口參數(shù)是通過(guò)命令行傳遞給程序的：

?

例如需求監(jiān)聽(tīng)本地回環(huán)地址上面的 65432 端口，需要執(zhí)行：

?

<host> 參數(shù)為空的話就可以監(jiān)聽(tīng)主機(jī)上的所有 IP 地址

創(chuàng)建完 socket 后，一個(gè)傳入?yún)?shù) socket.SO_REUSEADDR 的方法 `to

socket.setsockopt()` 將被調(diào)用

?

設(shè)置這個(gè)參數(shù)是為了避免 端口被占用 的錯(cuò)誤發(fā)生，如果當(dāng)前程序使用的端口和之前的程序使用的一樣，你就會(huì)發(fā)現(xiàn)連接處于 TIME_WAIT 狀態(tài)

比如說(shuō)，如果服務(wù)器主動(dòng)關(guān)閉連接，服務(wù)器會(huì)保持為大概兩分鐘的 TIME_WAIT 狀態(tài)，具體時(shí)長(zhǎng)取決于你的操作系統(tǒng)。如果你想在兩分鐘內(nèi)再開(kāi)啟一個(gè)服務(wù)，你將得到一個(gè)OSError 表示 端口被戰(zhàn)勝，這樣做是為了確保一些在途的數(shù)據(jù)包正確的被處理

事件循環(huán)會(huì)捕捉所有錯(cuò)誤，以保證服務(wù)器正常運(yùn)行：

?

當(dāng)服務(wù)器接受到一個(gè)客戶端連接時(shí)，消息對(duì)象就會(huì)被創(chuàng)建：

?

消息對(duì)象會(huì)通過(guò) sel.register() 方法關(guān)聯(lián)到 socket 上，而且它初始化就被設(shè)置成了只監(jiān)控讀事件。當(dāng)請(qǐng)求被讀取時(shí)，我們將通過(guò)監(jiān)聽(tīng)到的寫(xiě)事件修改它

在服務(wù)器端采用這種方法的一個(gè)優(yōu)點(diǎn)是，大多數(shù)情況下，當(dāng) socket 正常并且沒(méi)有網(wǎng)絡(luò)問(wèn)題時(shí)，它始終是可寫(xiě)的

如果我們告訴 sel.register() 方法監(jiān)控 EVENT_WRITE 寫(xiě)入事件，事件循環(huán)將會(huì)立即喚醒并通知我們這種情況，然而此時(shí) socket 并不用喚醒調(diào)用 send() 方法。由于請(qǐng)求還沒(méi)被處理，所以不需要發(fā)回響應(yīng)。這將消耗并浪費(fèi)寶貴的 CPU 周期

服務(wù)端消息類(lèi)

在消息切入點(diǎn)一節(jié)中，當(dāng)通過(guò) process_events() 知道 socket 事件就緒時(shí)我們可以看到消息對(duì)象是如何發(fā)出動(dòng)作的。現(xiàn)在讓我們來(lái)看看當(dāng)數(shù)據(jù)在 socket 上被讀取是會(huì)發(fā)生些什么，以及為服務(wù)器就緒的消息的組件片段發(fā)生了什么

libserver.py 文件中的服務(wù)端消息類(lèi)，可以在 Github 上找到 源代碼

這些方法按照消息處理順序出現(xiàn)在類(lèi)中

當(dāng)服務(wù)器讀取到至少兩個(gè)字節(jié)時(shí)，定長(zhǎng)頭的邏輯就可以開(kāi)始了

?

網(wǎng)絡(luò)字節(jié)序列中的定長(zhǎng)整型兩字節(jié)包含了 JSON 頭的長(zhǎng)度，struct.unpack() 方法用來(lái)讀取并解碼，然后保存在 self._jsonheader_len 中，當(dāng)這部分消息被處理完成后，就要調(diào)用 process_protoheader() 方法來(lái)刪除接收緩沖區(qū)中處理過(guò)的消息

就像上面的定長(zhǎng)頭的邏輯一樣，當(dāng)接收緩沖區(qū)有足夠的 JSON 頭數(shù)據(jù)時(shí)，它也需要被處理：

?

self._json_decode() 方法用來(lái)解碼并反序列化 JSON 頭成一個(gè)字典。由于我們定義的 JSON 頭是 utf-8 格式的，所以解碼方法調(diào)用時(shí)我們寫(xiě)死了這個(gè)參數(shù)，結(jié)果將被存放在 self.jsonheader 中，process_jsonheader 方法做完他應(yīng)該做的事情后，同樣需要?jiǎng)h除接收緩沖區(qū)中處理過(guò)的消息

接下來(lái)就是真正的消息內(nèi)容，當(dāng)接收緩沖區(qū)有 JSON 頭中定義的 content-length 值的數(shù)量個(gè)字節(jié)時(shí)，請(qǐng)求就應(yīng)該被處理了：

?

把消息保存到 data 變量中后，process_request() 又會(huì)刪除接收緩沖區(qū)中處理過(guò)的數(shù)據(jù)。接著，如果 content type 是 JSON 的話，它將解碼并反序列化數(shù)據(jù)。否則（在我們的例子中）數(shù)據(jù)將被視 做二進(jìn)制數(shù)據(jù)并打印出來(lái)

最后 process_request() 方法會(huì)修改 selector 為只監(jiān)控寫(xiě)入事件。在服務(wù)端的程序 app-server.py 中，socket 初始化被設(shè)置成僅監(jiān)控讀事件。現(xiàn)在請(qǐng)求已經(jīng)被全部處理完了，我們對(duì)讀取事件就不感興趣了

現(xiàn)在就可以創(chuàng)建一個(gè)響應(yīng)寫(xiě)入到 socket 中。當(dāng) socket 可寫(xiě)時(shí) create_response() 將被從 write() 方法中調(diào)用：

?

響應(yīng)會(huì)根據(jù)不同的 content type 的不同而調(diào)用不同的方法創(chuàng)建。在這個(gè)例子中，當(dāng) action == 'search' 的時(shí)候會(huì)執(zhí)行一個(gè)簡(jiǎn)單的字典查找。你可以在這個(gè)地方添加你自己的處理方法并調(diào)用

一個(gè)不好處理的問(wèn)題是響應(yīng)寫(xiě)入完成時(shí)如何關(guān)閉連接，我會(huì)在 _write() 方法中調(diào)用 close()

?

雖然close() 方法的調(diào)用有點(diǎn)隱蔽，但是我認(rèn)為這是一種權(quán)衡。因?yàn)橄㈩?lèi)一個(gè)連接只處理一條消息。寫(xiě)入響應(yīng)后，服務(wù)器無(wú)需執(zhí)行任何操作。它的任務(wù)就完成了

客戶端主程序

客戶端主程序 app-client.py 中，參數(shù)從命令行中讀取，用來(lái)創(chuàng)建請(qǐng)求并連接到服務(wù)端

?

來(lái)個(gè)示例演示一下：

$ ./app-client.py 127.0.0.1 65432 search needle

當(dāng)從命令行參數(shù)創(chuàng)建完一個(gè)字典來(lái)表示請(qǐng)求后，主機(jī)、端口、請(qǐng)求字典一起被傳給 start_connection()

?

對(duì)服務(wù)器的 socket 連接被創(chuàng)建，消息對(duì)象被傳入請(qǐng)求字典并創(chuàng)建

和服務(wù)端一樣，消息對(duì)象在 sel.register() 方法中被關(guān)聯(lián)到 socket 上。然而，客戶端不同的是，socket 初始化的時(shí)候會(huì)監(jiān)控讀寫(xiě)事件，一旦請(qǐng)求被寫(xiě)入，我們將會(huì)修改為只監(jiān)控讀取事件

這種實(shí)現(xiàn)和服務(wù)端一樣有好處：不浪費(fèi) CPU 生命周期。請(qǐng)求發(fā)送完成后，我們就不關(guān)注寫(xiě)入事件了，所以不用保持狀態(tài)等待處理

客戶端消息類(lèi)

在 消息入口點(diǎn) 一節(jié)中，我們看到過(guò)，當(dāng) socket 使用準(zhǔn)備就緒時(shí)，消息對(duì)象是如何調(diào)用具體動(dòng)作的。現(xiàn)在讓我們來(lái)看看 socket 上的數(shù)據(jù)是如何被讀寫(xiě)的，以及消息準(zhǔn)備好被加工的時(shí)候發(fā)生了什么

客戶端消息類(lèi)在 libclient.py 文件中，可以在 Github 上找到 源代碼

這些方法按照消息處理順序出現(xiàn)在類(lèi)中

客戶端的第一個(gè)任務(wù)就是讓請(qǐng)求入隊(duì)列：

?

用來(lái)創(chuàng)建請(qǐng)求的字典，取決于客戶端程序 app-client.py 中傳入的命令行參數(shù)，當(dāng)消息對(duì)象創(chuàng)建的時(shí)候，請(qǐng)求字典被當(dāng)做參數(shù)傳入

請(qǐng)求消息被創(chuàng)建并追加到發(fā)送緩沖區(qū)中，消息將被 _write() 方法發(fā)送，狀態(tài)參數(shù) self._request_queued 被設(shè)置，這使 queue_request() 方法不會(huì)被重復(fù)調(diào)用

請(qǐng)求發(fā)送完成后，客戶端就等待服務(wù)器的響應(yīng)

客戶端讀取和處理消息的方法和服務(wù)端一致，由于響應(yīng)數(shù)據(jù)是從 socket 上讀取的，所以處理 header 的方法會(huì)被調(diào)用：process_protoheader() 和 process_jsonheader()

最終處理方法名字的不同在于處理一個(gè)響應(yīng)，而不是創(chuàng)建：process_response(),_process_response_json_content() 和 _process_response_binary_content()

最后，但肯定不是最不重要的 —— 最終的 process_response() 調(diào)用：

?

消息類(lèi)的包裝

我將通過(guò)提及一些方法的重要注意點(diǎn)來(lái)結(jié)束消息類(lèi)的討論

主程序中任意的類(lèi)觸發(fā)異常都由 except 字句來(lái)處理：

?

注意最后一行的方法 message.close()

這一行很重要的原因有很多，不僅僅是保證 socket 被關(guān)閉，而且通過(guò)調(diào)用 message.close() 方法刪除使用 select() 監(jiān)控的 socket，這是類(lèi)中的一段非常簡(jiǎn)潔的代碼，它能減小復(fù)雜度。如果一個(gè)異常發(fā)生或者我們自己主動(dòng)拋出，我們很清楚 close() 方法將處理善后

Message._read() 和 Message._write() 方法都包含一些有趣的東西：

?

注意 except 行：except BlockingIOError：

_write() 方法也有，這幾行很重要是因?yàn)樗鼈儾东@臨時(shí)錯(cuò)誤并通過(guò)使用 pass 跳過(guò)。臨時(shí)錯(cuò)誤是 socket 阻塞的時(shí)候發(fā)生的，比如等待網(wǎng)絡(luò)響應(yīng)或者連接的其它端

通過(guò)使用 pass 跳過(guò)異常，select() 方法將再次調(diào)用，我們將有機(jī)會(huì)重新讀寫(xiě)數(shù)據(jù)

運(yùn)行應(yīng)用程序的客戶端和服務(wù)端

經(jīng)過(guò)所有這些艱苦的工作后，讓我們把程序運(yùn)行起來(lái)并找到一些樂(lè)趣！

在這個(gè)救命中，我們將傳一個(gè)空的字符串做為 host 參數(shù)的值，用來(lái)監(jiān)聽(tīng)服務(wù)器端的所有IP 地址。這樣的話我就可以從其它網(wǎng)絡(luò)上的虛擬機(jī)運(yùn)行客戶端程序，我將模擬一個(gè) PowerPC 的機(jī)器

首頁(yè)，把服務(wù)端程序運(yùn)行進(jìn)來(lái)：

?

現(xiàn)在讓我們運(yùn)行客戶端，傳入搜索內(nèi)容，看看是否能看他（墨菲斯-黑客帝國(guó)中的角色）：

?

我的命令行 shell 使用了 utf-8 編碼，所以上面的輸出可以是 emojis

再試試看能不能搜索到小狗：

?

注意請(qǐng)求發(fā)送行的 byte string，很容易看出來(lái)你發(fā)送的小狗 emoji 表情被打印成了十六進(jìn)制的字符串 \xf0\x9f\x90\xb6，我可以使用 emoji 表情來(lái)搜索是因?yàn)槲业拿钚兄С謚tf-8 格式的編碼

這個(gè)示例中我們發(fā)送給網(wǎng)絡(luò)原始的 bytes，這些 bytes 需要被接受者正確的解釋。這就是為什么之前需要給消息附加頭信息并且包含編碼類(lèi)型字段的原因

下面這個(gè)是服務(wù)器對(duì)應(yīng)上面兩個(gè)客戶端連接的輸出：

?

注意請(qǐng)求發(fā)送行的 byte string，很容易看出來(lái)你發(fā)送的小狗 emoji 表情被打印成了十六進(jìn)制的字符串 \xf0\x9f\x90\xb6，我可以使用 emoji 表情來(lái)搜索是因?yàn)槲业拿钚兄С謚tf-8 格式的編碼

這個(gè)示例中我們發(fā)送給網(wǎng)絡(luò)原始的 bytes，這些 bytes 需要被接受者正確的解釋。這就是為什么之前需要給消息附加頭信息并且包含編碼類(lèi)型字段的原因

下面這個(gè)是服務(wù)器對(duì)應(yīng)上面兩個(gè)客戶端連接的輸出：

?

注意發(fā)送行中寫(xiě)到客戶端的 bytes，這就是服務(wù)端的響應(yīng)消息

如果 action 參數(shù)不是搜索，你也可以試試給服務(wù)器發(fā)送二進(jìn)制請(qǐng)求

?

由于請(qǐng)求的 content-type 不是 text/json，服務(wù)器會(huì)把內(nèi)容當(dāng)成二進(jìn)制類(lèi)型并且不會(huì)解碼 JSON，它只會(huì)打印 content-type 和返回的前 10 個(gè) bytes 給客戶端

?

故障排除

某些東西運(yùn)行不了是很常見(jiàn)的，你可能不知道應(yīng)該怎么做，不用擔(dān)心，所有人都會(huì)遇到這種問(wèn)題，希望你借助本教程、調(diào)試器和萬(wàn)能的搜索引擎解決問(wèn)題并且繼續(xù)下去

如果還是解決不了，你的第一站應(yīng)該是 python 的 socket 模塊文檔，確保你讀過(guò)文檔中每個(gè)我們使用到的方法、函數(shù)。同樣的可以從引用一節(jié)中找到一些辦法，尤其是錯(cuò)誤一節(jié)中的內(nèi)容

有的時(shí)候問(wèn)題并不是由你的源代碼引起的，源代碼可能是正確的。有可能是不同的主機(jī)、客戶端和服務(wù)器。也可能是網(wǎng)絡(luò)原因，比如路由器、防火墻或者是其它網(wǎng)絡(luò)設(shè)備扮演了中間人的角色

對(duì)于這些類(lèi)型的問(wèn)題，額外的一些工具是必要的。下面這些工具或者集可能會(huì)幫到你或者至少提供一些線索

pin

ping 命令通過(guò)發(fā)送一個(gè) ICMP 報(bào)文來(lái)檢測(cè)主機(jī)是否連接到了網(wǎng)絡(luò)，它直接與操作系統(tǒng)上的 TCP/IP 協(xié)議棧通信，所以它在主機(jī)上是獨(dú)立于任何應(yīng)用程序運(yùn)行的

下面是一段在 macOS 上執(zhí)行 ping 命令的結(jié)果

?

注意后面的統(tǒng)計(jì)輸出，這對(duì)你排查間歇性的連接問(wèn)題很有幫助。比如說(shuō)，是否有數(shù)據(jù)包丟失？網(wǎng)絡(luò)延遲怎么樣（查看消息的往返時(shí)間）

如果你與主機(jī)之間有防火墻的話，ping 發(fā)送的請(qǐng)求可能會(huì)被阻止。防火墻管理員定義了一些規(guī)則強(qiáng)制阻止一些請(qǐng)求，主要的原因就是他們不想自己的主機(jī)是可以被發(fā)現(xiàn)的。如果你的機(jī)器也出現(xiàn)這種情況的話，請(qǐng)確保在規(guī)則中添加了允許 ICMP 包的發(fā)送

ICMP 是 ping 命令使用的協(xié)議，但它也是 TCP 和其他底層用于傳遞錯(cuò)誤消息的協(xié)議，如果你遇到奇怪的行為或緩慢的連接，可能就是這個(gè)原因

ICMP 消息通過(guò)類(lèi)型和代號(hào)來(lái)定義。下面有一些重要的信息可以參考：

?

查看 Path MTU Discovery 更多關(guān)于分片和 ICMP 消息的內(nèi)容，里面遇到的問(wèn)題就是我前面提及的一些奇怪行為

netstat

在 查看 socket 狀態(tài) 一節(jié)中我們已經(jīng)知道如何使用 netstat 來(lái)查看 socket 及其狀態(tài)的信息。這個(gè)命令在 macOS, Linux, Windows 上都可以使用

在之前的示例中我并沒(méi)有提及 Recv-Q 和 Send-Q 列。這些列表示發(fā)送或者接收隊(duì)列中網(wǎng)絡(luò)緩沖區(qū)數(shù)據(jù)的字節(jié)數(shù)，但是由于某些原因這些字節(jié)還沒(méi)被遠(yuǎn)程或者本地應(yīng)用讀寫(xiě)

換句話說(shuō)，這些網(wǎng)絡(luò)中的字節(jié)還在操作系統(tǒng)的隊(duì)列中。一個(gè)原因可能是應(yīng)用程序受 CPU 限制或者無(wú)法調(diào)用 socket.recv()、socket.send() 方法處理，或者因?yàn)槠渌恍┚W(wǎng)絡(luò)原因?qū)е碌?#xff0c;比如說(shuō)網(wǎng)絡(luò)的擁堵、失敗、硬件及電纜的問(wèn)題

為了復(fù)現(xiàn)這個(gè)問(wèn)題，看看到底在錯(cuò)誤發(fā)生前我應(yīng)該發(fā)送多少數(shù)據(jù)。我寫(xiě)了一個(gè)測(cè)試客戶端可以連接到測(cè)試服務(wù)器，并且重復(fù)的調(diào)用 socket.send() 方法。測(cè)試服務(wù)端永遠(yuǎn)不調(diào)用 socket.recv() 或者 socket.send() 方法來(lái)處理客戶端發(fā)送的數(shù)據(jù)，它只接受連接請(qǐng)求。這會(huì)導(dǎo)致服務(wù)器上的網(wǎng)絡(luò)緩沖區(qū)被填滿，最終會(huì)在客戶端上報(bào)錯(cuò)

首先運(yùn)行服務(wù)端：

$ ./app-server-test.py 127.0.0.1 65432 listening on ('127.0.0.1', 65432)

然后運(yùn)行客戶端，看看發(fā)生了什么：

?

下面是用 netstat 命令在錯(cuò)誤發(fā)生時(shí)執(zhí)行的結(jié)果：

?

第一行就表示服務(wù)端（本地端口是 65432）

?

注意 Recv-Q: 408300

第二行表示客戶端（遠(yuǎn)程端口是 65432）

?

注意 Send-Q: 269868

顯然，客戶端試著寫(xiě)入字節(jié)，但是服務(wù)端并沒(méi)有讀取他們。這導(dǎo)致服務(wù)端網(wǎng)絡(luò)緩沖隊(duì)列中應(yīng)該保存的數(shù)據(jù)被積壓在接收端，客戶端的網(wǎng)絡(luò)緩沖隊(duì)列積壓到發(fā)送端

windows

如果你使用的是 windows 電腦，有一個(gè)工具套件絕對(duì)值得安裝 Windows Sysinternals

里面有個(gè)工具叫 TCPView.exe，它是 windows 下的一個(gè)可視化的 netstat 工具。除了地址、端口號(hào)和 socket 狀態(tài)之外，它還會(huì)顯示發(fā)送和接收的數(shù)據(jù)包以及字節(jié)數(shù)。就像 Unix 工具集 lsof 命令一樣，你也可以看見(jiàn)進(jìn)程名和 ID，可以在菜單中查看更多選項(xiàng)

?

?

Wireshark

有時(shí)候你可能想查看網(wǎng)絡(luò)底層發(fā)生了什么，忽略應(yīng)用程序的輸出或者外部庫(kù)調(diào)用，想看看網(wǎng)絡(luò)層面到底收發(fā)了什么內(nèi)容，就像調(diào)試器一樣，當(dāng)你需要看清這些的時(shí)候，沒(méi)有別的辦法

Wireshark 是一款可以運(yùn)行在 macOS, Linux, Windows 以及其它系統(tǒng)上的網(wǎng)絡(luò)協(xié)議分析、流量捕獲工具，GUI 版本的程序叫做

wireshark，命令 行的程序叫做 tshark

流量捕獲是一個(gè)非常好用的方法，它可以讓你看到網(wǎng)絡(luò)上應(yīng)用程序的行為，收集到關(guān)于收發(fā)消息多少、頻率等信息，你也可以看到客戶端或者服務(wù)端如何關(guān)閉/取消連接，或者停止響應(yīng)，當(dāng)你需要排除故障的時(shí)候這些信息非常的有用

網(wǎng)上還有很多關(guān)于 wireshark 和 TShark 的基礎(chǔ)使用教程

這有一個(gè)使用 wireshark 捕獲本地網(wǎng)絡(luò)數(shù)據(jù)的例子：

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/wrxblog/p/9777700.html

總結(jié)

以上是生活随笔為你收集整理的「Python」socket指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。