互聯網協議入門（二）
七、一個小結
先對前面的內容，做一個小結。
我們已經知道，網絡通信就是交換數據包。電腦A向電腦B發送一個數據包，后者收到了，回復一個數據包，從而實現兩臺電腦之間的通信。數據包的結構，基本上是下面這樣：
發送這個包，需要知道兩個地址：
對方的 MAC 地址
對方的 IP 地址
有了這兩個地址，數據包才能準確送到接收者手中。但是，前面說過，MAC 地址有局限性，如果兩臺電腦不在同一個子網絡，就無法知道對方的 MAC 地址，必須通過網關（gateway）轉發。
上圖中，1號電腦要向 4 號電腦發送一個數據包。它先判斷 4 號電腦是否在同一個子網絡，結果發現不是（后文介紹判斷方法），于是就把這個數據包發到網關A。網關A通過路由協議，發現 4 號電腦位于子網絡B，又把數據包發給網關B，網關B再轉發到 4 號電腦。
1號電腦把數據包發到網關A，必須知道網關A的 MAC 地址。所以，數據包的目標地址，實際上分成兩種情況：
| 場景 | 數據包地址 |
| 同一個子網絡 | 對方的 MAC 地址，對方的 IP 地址 |
| 非同一個子網絡 | 網關的 MAC 地址，對方的 IP 地址 |
發送數據包之前，電腦必須判斷對方是否在同一個子網絡，然后選擇相應的 MAC 地址。接下來，我們就來看，實際使用中，這個過程是怎么完成的。
八、用戶的上網設置
8. 1 靜態 IP 地址
你買了一臺新電腦，插上網線，開機，這時電腦能夠上網嗎？
通常你必須做一些設置。有時，管理員（或者 ISP）會告訴你下面四個參數，你把它們填入操作系統，計算機就能連上網了：
本機的 IP 地址
子網掩碼
網關的 IP 地址
DNS 的 IP 地址
下圖是 Windows 系統的設置窗口。
這四個參數缺一不可，后文會解釋為什么需要知道它們才能上網。由于它們是給定的，計算機每次開機，都會分到同樣的 IP 地址，所以這種情況被稱作"靜態 IP 地址上網"。
但是，這樣的設置很專業，普通用戶望而生畏，而且如果一臺電腦的 IP 地址保持不變，其他電腦就不能使用這個地址，不夠靈活。出于這兩個原因，大多數用戶使用"動態 IP 地址上網"。
8. 2 動態 IP 地址
所謂"動態 IP 地址"，指計算機開機后，會自動分配到一個 IP 地址，不用人為設定。它使用的協議叫做 DHCP 協議。
這個協議規定，每一個子網絡中，有一臺計算機負責管理本網絡的所有 IP 地址，它叫做"DHCP 服務器"。新的計算機加入網絡，必須向"DHCP 服務器"發送一個"DHCP 請求"數據包，申請 IP 地址和相關的網絡參數。
前面說過，如果兩臺計算機在同一個子網絡，必須知道對方的 MAC 地址和 IP 地址，才能發送數據包。但是，新加入的計算機不知道這兩個地址，怎么發送數據包呢？
DHCP 協議做了一些巧妙的規定。
8. 3 DHCP 協議
首先，它是一種應用層協議，建立在 UDP 協議之上，所以整個數據包是這樣的：
（1）最前面的"以太網標頭"，設置發出方（本機）的 MAC 地址和接收方（DHCP 服務器）的 MAC 地址。前者就是本機網卡的 MAC 地址，后者這時不知道，就填入一個廣播地址：FF-FF-FF-FF-FF-FF。
（2）后面的"IP 標頭"，設置發出方的 IP 地址和接收方的 IP 地址。這時，對于這兩者，本機都不知道。于是，發出方的 IP 地址就設為0.0.0.0，接收方的 IP 地址設為 255.255.255.255。
（3）最后的"UDP 標頭"，設置發出方的端口和接收方的端口。這一部分是 DHCP 協議規定好的，發出方是 68 端口，接收方是 67 端口。
這個數據包構造完成后，就可以發出了。以太網是廣播發送，同一個子網絡的每臺計算機都收到了這個包。因為接收方的 MAC 地址是 FF-FF-FF-FF-FF-FF，看不出是發給誰的，所以每臺收到這個包的計算機，還必須分析這個包的 IP 地址，才能確定是不是發過自己的。當看到發出方 IP 地址是0.0.0.0，接收方是 255.255.255.255，于是 DHCP 服務器知道"這個包是發過我的"，而其他計算機就可以丟棄這個包。
接下來，DHCP 服務器讀出這個包的數據內容，分配好 IP 地址，發送回去一個"DHCP 響應"數據包。這個響應包的結構也是類似的，以太網標頭的 MAC 地址是雙方的網卡地址，IP 標頭的 IP 地址是 DHCP 服務器的 IP 地址（發出方）和 255.255.255.255（接收方），UDP 標頭的端口是 67（發出方）和 68（接收方），分配給請求端的 IP 地址和本網絡的具體參數則包含在 Data 部分。
新加入的計算機收到這個響應包，于是就知道了自己的 IP 地址、子網掩碼、網關地址、DNS 服務器等等參數。
8. 4 上網設置：小結
這個部分，需要記住的就是一點：不管是"靜態 IP 地址"還是"動態 IP 地址"，電腦上網的首要步驟，是確定四個參數。這四個值很重要，值得重復一遍：
本機的 IP 地址
子網掩碼
網關的 IP 地址
DNS 的 IP 地址
有了這幾個數值，電腦就可以上網"沖浪"了。接下來，我們來看一個實例，當用戶訪問網頁的時候，互聯網協議是怎么運作的。
九、一個實例：訪問網頁
9. 1 本機參數
我們假定，經過上一節的步驟，用戶設置好了自己的網絡參數：
本機的 IP 地址：192.168.1.100
子網掩碼：255.255.255.0
網關的 IP 地址：192.168.1.1
DNS 的 IP 地址：8.8.8.8
然后他打開瀏覽器，想要訪問 Google，在地址欄輸入了網址：www.google.com。
這意味著，瀏覽器要向 Google 發送一個網頁請求的數據包。
9. 2 DNS 協議
我們知道，發送數據包，必須要知道對方的 IP 地址。但是，現在，我們只知道網址 www.google.com，不知道它的 IP 地址。
DNS 協議可以幫助我們，將這個網址轉換成 IP 地址。已知 DNS 服務器為8.8.8.8，于是我們向這個地址發送一個 DNS 數據包（53端口）。
然后，DNS 服務器做出響應，告訴我們 Google 的 IP 地址是 172.194.72.105。于是，我們知道了對方的 IP 地址。
9. 3 子網掩碼
接下來，我們要判斷，這個 IP 地址是不是在同一個子網絡，這就要用到子網掩碼。
已知子網掩碼是 255.255.255.0，本機用它對自己的 IP 地址 192.168.1.100，做一個二進制的 AND 運算（兩個數位相同，結果為1，否則為0），計算結果為 192.168.1.0；然后對 Google 的 IP 地址 172.194.72.105 也做一個 AND 運算，計算結果為 172.194.72.0。這兩個結果不相等，所以結論是，Google 與本機不在同一個子網絡。
因此，我們要向 Google 發送數據包，必須通過網關 192.168.1.1 轉發，也就是說，接收方的 MAC 地址將是網關的 MAC 地址。
9. 4 應用層協議
瀏覽網頁用的是 HTTP 協議，它的整個數據包構造是這樣的：
HTTP 部分的內容，類似于下面這樣：
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1) ......
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: ... ...
我們假定這個部分的長度為 4960 字節，它會被嵌在 TCP 數據包之中。
9. 5 TCP 協議
TCP 數據包需要設置端口，接收方（Google）的 HTTP 端口默認是 80，發送方（本機）的端口是一個隨機生成的 1024-65535之間的整數，假定為 51775。
TCP 數據包的標頭長度為 20 字節，加上嵌入 HTTP 的數據包，總長度變為 4980 字節。
9. 6 IP 協議
然后，TCP 數據包再嵌入 IP 數據包。IP 數據包需要設置雙方的 IP 地址，這是已知的，發送方是 192.168.1.100（本機），接收方是 172.194.72.105（Google）。
IP 數據包的標頭長度為 20 字節，加上嵌入的 TCP 數據包，總長度變為 5000 字節。
9. 7 以太網協議
最后，IP 數據包嵌入以太網數據包。以太網數據包需要設置雙方的 MAC 地址，發送方為本機的網卡 MAC 地址，接收方為網關 192.168.1.1 的 MAC 地址（通過 ARP 協議得到）。
以太網數據包的數據部分，最大長度為 1500 字節，而現在的 IP 數據包長度為 5000 字節。因此，IP 數據包必須分割成四個包。因為每個包都有自己的 IP 標頭（20字節），所以四個包的 IP 數據包的長度分別為 1500、1500、1500、560。
9. 8 服務器端響應
經過多個網關的轉發，Google 的服務器 172.194.72.105，收到了這四個以太網數據包。
根據 IP 標頭的序號，Google 將四個包拼起來，取出完整的 TCP 數據包，然后讀出里面的"HTTP 請求"，接著做出"HTTP 響應"，再用 TCP 協議發回來。
本機收到 HTTP 響應以后，就可以將網頁顯示出來，完成一次網絡通信。
這個例子就到此為止，雖然經過了簡化，但它大致上反映了互聯網協議的整個通信過程。