介紹
本文將介紹從瀏覽器輸入URL到伺服器響應資料，中間到底經歷了哪些階段，本文將帶你徹底走進網路的世界，讓我們從瀏覽器出入URL開始，然後一步一步的分析中間的過程。
輸入http://www.xxxx.com
探索之旅從輸入網址開始
我們現在輸入了一個網址，www.xxxx.com, 在介紹瀏覽器的工作方 式之前，讓我們先來介紹一下網址。網址，準確來說應該叫 URL，如果我 說它就是以 http:// 開頭的那一串東西，恐怕大家一下子就明白了，但實際 上除了“http:”，網址還可以以其他一些文字開頭，例如“ftp:”,“file:”,“mailto:” 等。
這裡先說明一下什麼是協議：協議就是一種通訊規則的定義，比如我們傳送了一個使用http協議的資料，那麼接收方也必須使用http協議來解析資料，如果不使用http協議就識別不了該資料。
之所以有各種各樣的 URL，是因為儘管我們通常是使用瀏覽器來訪問Web 伺服器的，但實際上瀏覽器並不只有這一個功能，它也可以用來在 FTP 伺服器上下載和上傳檔案，同時也具備電子郵件客戶端的功能。可以 說，瀏覽器是一個具備多種客戶端功能的綜合性客戶端軟體，因此它需要 一些東西來判斷應該使用其中哪種功能來訪問相應的資料，而各種不同的 URL 就是用來幹這個的，比如訪問 Web 伺服器時用“http:”，而訪問 FTP 伺服器時用“ftp:”。
下面舉例一些網際網路中的一些常見的URL，根據訪問目標的不同，URL的寫法也會不同
瀏覽器先要解析 URL
瀏覽器要做的第一步工作就是對 URL 進行解析，從而生成傳送給 Web 伺服器的請求訊息。剛才我們已經講過，URL 的格式會隨著協議的不同而不同，因此下面我們以訪問 Web 伺服器的情況為例來進行講解。
先分析圖中a這個url，可以看到url是先有一個http，這個就是url使用的伺服器訪問協議，瀏覽器通過分析協議來決定訊息的生成方式，然後就是//，後面跟著的是Web伺服器名，這個web伺服器名就是我們需要訪問的域名，再然後就是我們需要訪問的資料的路徑名，但是路徑名是可以省略的。
省略檔名的情況
上圖是一個以“http:”開頭的典型 URL，但有時候我們也會見到一些不太一樣的 URL，例如下面這個 URL 是以“/”來結尾的
我們可以這樣理解，以“/”結尾代表 /dir/ 後面本來應該有的檔名被 省略了。根據 URL 的規則，檔名可以像前面這樣省略。
不過，沒有檔名，伺服器怎麼知道要訪問哪個檔案呢?其實，我們 會在伺服器上事先設定好檔名省略時要訪問的預設檔名。這個設定根 據伺服器不同而不同，大多數情況下是 index.html 或者 default.htm 之類的 檔名。因此，像前面這樣省略檔名時，伺服器就會訪問 /dir/index.html 或者 /dir/default.htm。
在解析完URL之後，我們就知道應該要訪問的目標在哪裡了。接下來，瀏覽器會使用 http 協議來訪問 Web 伺服器
生成 HTTP 請求訊息
讓我們回到對瀏覽器本身的探索中來，對 URL 進行解析之後，瀏覽器確定了 Web 伺服器和檔名，接下來就是根據這些資訊來生成 HTTP 請求訊息了。實際上，HTTP 訊息在 格式上是有嚴格規定的，因此瀏覽器會按照規定的格式來生成請求訊息。
( 看下圖 ) 首先，請求訊息的第一行稱為請求行。這裡的重點是最開頭的方法，方法可以告訴 Web 伺服器它應該進行怎樣的操作。不過這裡必須先解決一 個問題，那就是方法有很多種，我們必須先判斷應該選用其中的哪一種。
解決這個問題的關鍵在於瀏覽器的工作狀態。這次探索之旅是從在瀏 覽器頂部的位址列中輸入網址開始的，但瀏覽器並非只有在這一種場景下 才會向 Web 伺服器傳送請求訊息。比如點選網頁中的超級連結，或者在表單中填寫資訊後點選“提交”按鈕，這些場景都會觸發瀏覽器的工作，而 選用哪種方法也是根據場景來確定的
我們的場景是在位址列中輸入網址並顯示網頁，因此這裡應該使用 GET 方法。點選超級連結的場景中也是使用 GET 方法。如果是表單，在 HTML 原始碼中會在表單的屬性中指定使用哪種方法來傳送請求，可能是 GET 也 可能是 POST。
HTTP 中主要的頭欄位/通用頭：適用於請求和響應訊息的頭欄位
| 頭欄位型別 | 含義 |
|---|---|
| Date | 表示請求和響應生成的日期 |
| Pragma | 表示資料是否允許快取的通訊選項 |
| Cache-Control | 控制快取的相關資訊 |
| Connection | 設定傳送響應之後 TCP 連線是否繼續保持的通訊選項 |
| Transfer-Encoding | 表示訊息主體的編碼格式 |
| Via | 記錄途中經過的代理和閘道器 |
HTTP 中主要的頭欄位/請求頭：用於表示請求訊息的附加資訊的頭欄位
| 頭欄位型別 | 含義 |
|---|---|
| Authorization | 身份認證資料 |
| From | 請求傳送者的郵件地址 |
| If-Modified-Since | 如果希望僅當資料在某個日期之後有更新時才執 行請求，可以在這個欄位指定希望的日期。一般 來說，這個功能的用途在於判斷客戶端快取的數 據是否已經過期，如果已經過期則獲取新的資料 |
| Referer | 當通過點選超級連結進入下一個頁面時，在這裡 會記錄下上一個頁面的 URI |
| User-Agent | 客戶端軟體的名稱和版本號等相關資訊 |
| Accept | 客戶端可支援的資料型別(Content-Type)，以 MIME 型別來表示 |
| Accept-Charset | 客戶端可支援的字符集 |
| Accept-Encoding | 客戶端可支援的編碼格式(Content-Encoding)， 一般來說表示資料的壓縮格式 |
| Accept-Language | 客戶端可支援的語言，漢語為 zh，英語為 en |
| Host | 接收請求的伺服器 IP 地址和埠號 |
| If-Match | 參見 Etag |
| If-None-Match | 參見 Etag |
| If-Unmodified-Since | 當指定日期之後資料未更新時執行請求 |
| Range | 當需要只獲取部分資料而不是全部資料時，可通 過這個欄位指定要獲取的資料範圍 |
HTTP 中主要的頭欄位/響應頭：用於表示響應訊息的附加資訊的頭欄位
| 頭欄位型別 | 含義 |
|---|---|
| Location | 表示資訊的準確位置。當請求的 URI 為相對路徑 時，這個欄位用來返回絕對路徑 |
| Server | 伺服器程式的名稱和版本號等相關資訊 |
| WWW-Authenticate | 當請求的資訊存在訪問控制時，返回身份認證用 的資料(Challenge) |
| Accept-Ranges | 當希望僅請求部分資料(使用 Range 來指定範圍) 時，伺服器會告知客戶端是否支援這一功能 |
HTTP 中主要的頭欄位/響應頭：用於表示實體(訊息體)的附加資訊的頭欄位
| 頭欄位型別 | 含義 |
|---|---|
| Allow | 表示指定的 URI 支援的方法 |
| Content-Encoding | 當訊息體經過壓縮等編碼處理時，表示其編碼格式 |
| Content-Length | 表示訊息體的長度 |
| Content-Type | 表示訊息體的資料型別，以 MIME 規格定義的數 據型別來表示 |
| Expires | 表示訊息體的有效期 |
| Last-Modified | 資料的最後更新日期 |
| Content-Language | 表示訊息體的語言。漢語為 zh，英語為 en |
| Content-Location | 表示訊息體在伺服器上的位置(URI) |
| Content-Range | 當僅請求部分資料時，表示訊息體包含的資料範圍 |
| Etag | 在更新操作中，有時候需要基於上一次請求的響應 資料來傳送下一次請求。在這種情況下，這個欄位 可以用來提供上次響應與下次請求之間的關聯資訊。 上次響應中，伺服器會通過 Etag 向客戶端傳送一 個唯一標識，在下次請求中客戶端可以通過 If- Match、If-None-Match、If-Range 欄位將這個標識 告知伺服器，這樣伺服器就知道該請求和上次的響 應是相關的。這個欄位的功能和 Cookie 是相同的， 但 Cookie 是網?(Netscape)公司自行開發的規格， 而 Etag 是將其進行標準化後的規格 |
向 DNS 伺服器查詢 Web 伺服器的 IP 地址
IP 地址的基本知識
生成 HTTP 訊息之後，接下來我們需要?託作業系統將訊息傳送給 Web 伺服器。儘管瀏覽器能夠解析網址並生成 HTTP 訊息，但它本身並不具備將訊息傳送到網路中的功能，因此這一功能需要委託作業系統來實現。在進行這一操作時，我們還有一個工作需要完成，那就是查詢網址中伺服器域名對應的 IP 地址。在委託作業系統傳送訊息時，必須要提供的不是通訊物件的域名，而是它的 IP 地址。因此，在生成 HTTP 訊息之後，下 一個步驟就是根據域名查詢 IP 地址。在講解這一操作之前，讓我們先來簡 單瞭解一下 IP 地址。
網際網路和公司內部的區域網都是基於 TCP/IP 的思路來設計的，所以我 們先來了解 TCP/IP 的基本思路。TCP/IP 的結構如下圖所示，就是由一些 小的子網，通過路由器連線起來組成一個大的網路。這裡的子網可以理解 為用集線器連線起來的幾臺計算機，我們將它看作一個單位，稱為子網。 將子網通過路由器連線起來，就形成了一個網路。 在網路中，所有的裝置都會被分配一個地址。這個地址就相當於現實 中某條路上的“×× 號 ×× 室”。其中“號”對應的號碼是分配給整個子 網的，而“室”對應的號碼是分配給子網中的計算機的，這就是網路中的 地址。“號”對應的號碼稱為網路號，“室”對應的號碼稱為主機號，這個 地址的整體稱為 IP 地址。通過 IP 地址我們可以判斷出訪問物件伺服器的 位置，從而將訊息傳送到伺服器。訊息傳送的具體過程在後面的章節有詳 細講解，不過現在我們先簡單瞭解一下。傳送者發出的訊息首先經過子網中的集線器，轉發到距離傳送者最近的路由器上。接下來， 路由器會根據訊息的目的地判斷下一個路由器的位置，然後將訊息傳送 到下一個路由器，即訊息再次經過子網內的集線器被轉發到下一個路由 器(圖 1.8 2)。前面的過程不斷重複，最終訊息就被傳送到了目的地。
前面這些就是 TCP/IP 中 IP 地址的基本思路。瞭解了這些知識之後， 讓我們再來看一下實際的 IP 地址。如下圖所示，實際的 IP 地址是一串 32 位元的數字，按照 8 位元(1 位元組)為一組分成 4 組，分別用十進位制表示 然後再用圓點隔開。這就是我們平常經常見到的 IP 地址格式，但僅憑這一 串數字我們無法區分哪部分是網路號，哪部分是主機號。在 IP 地址的規則 中，網路號和主機號連起來總共是 32 位元，但這兩部分的具體結構是不固 定的。在組建網路時，使用者可以自行決定它們之間的分配關係，因此，我 們還需要另外的附加資訊來表示 IP 地址的內部結構。
這一附加資訊稱為子網掩碼。子網掩碼的格式如下圖所示，是一 串與 IP 地址長度相同的 32 位元數字，其左邊一半都是 1，右邊一半都是0。其中，子網掩碼為 1 的部分表示網路號，子網掩碼為 0 的部分表示主機 號。將子網掩碼按照和 IP 地址一樣的方式以每 8 位元為單位用圓點分組後 寫在 IP 地址的右側，這就是圖下圖的方法。這種寫法太長，我們也可 以把 1 的部分的位元數用十進位制表示並寫在 IP 地址的右側，如圖下圖所示。這兩種方式只是寫法上的區別，含義是完全一樣的。
域名和 IP 地址並用的理由
TCP/IP是通過IP地址來確定通訊物件的，因此不知道IP地址就無法將訊息傳送給對方，這和我們打電話的時候必須要知道對方的電話號 碼是一個道理。因此，在委託作業系統傳送訊息時，必須要先查詢好對方 的IP地址。
可能你會問“既然如此，那麼在網址中不寫伺服器的名字，直接寫 IP 地址不就好了嗎?”實際上，如果用 IP 地址來代替伺服器名稱也是能夠正常工作的。然而，就像你很難記住電話號碼一樣，要記住一串由數字組成 的 IP 地址也非常困難。因此，相比 IP 地址來說，網址中還是使用伺服器名稱比較好。
那麼又有人問了:“既然如此，那乾脆不要用 IP 地址，而是用名稱來確定 通訊物件不就好了嗎?網際網路中使用的是最新的網路技術，和電話那種老古 董可不一樣，這樣的功能應該還是做得到的吧?”這樣的想法其實並不奇怪 。不過從執行效率上來看，這並不能算是一個好主意。網際網路中存在無數的路由器，它們之間相互配合，根據 IP 地址來判斷應該把資料傳送到什麼地方。那麼如果我們不用 IP 地址而是改用名稱會怎麼樣呢? IP 地址的長度 為 32 位元，也就是 4 位元組，相對地，域名最短也要幾十個位元組，最長甚至 可以達到 255 位元組。換句話說，使用 IP 地址只需要處理 4 位元組的數字，而 域名則需要處理幾十個到 255 個位元組的字元，這增加了路由器的負擔，傳送 資料也會花費更長的時間 D。可能有人會說:“那使用高效能路由器不就能解 決這個問題了嗎?”然而，路由器的速度是有極限的，而網際網路內部流動的 資料量已然讓路由器疲於應付了，因此我們不應該再採用效率更低的設計。 隨著技術的發展，路由器的效能也會不斷提升，但與此同時，資料量也在以更快的速度增長，在可預見的未來，這樣的趨勢應該不會發生變化。出於這樣的原因，使用名稱本身來確定通訊物件並不是一個聰明的設計。
於是，現在我們使用的方案是讓人來使用名稱，讓路由器來使用 IP 地 址。為了填補兩者之間的障礙，需要有一個機制能夠通過名稱來查詢 IP 地 址，或者通過 IP 地址來查詢名稱，這樣就能夠在人和機器雙方都不做出犧牲的前提下完美地解決問題。這個機制就是 DNS。
Socket 庫提供查詢 IP 地址的功能
查詢 IP 地址的方法非常簡單，只要詢問最近的 DNS 伺服器“www. lab.glasscom.com 的 IP 地址是什麼”就可以了，DNS 伺服器會回答說“該 伺服器的 IP 地址為 xxx.xxx.xxx.xxx”。這一步非常簡單，很多讀者也都很 熟悉，那麼瀏覽器是如何向 DNS 伺服器發出查詢的呢?讓我們把向 Web 伺服器傳送請求訊息的事情放一放，先來探索一下 DNS。
向 DNS 伺服器發出查詢，也就是向 DNS 伺服器傳送查詢訊息，並接收伺服器返回的響應訊息。換句話說，對於 DNS 伺服器，我們的計算機上 一定有相應的 DNS 客戶端，而相當於 DNS 客戶端的部分稱為 DNS 解析器，或者簡稱解析器。通過 DNS 查詢 IP 地址的操作稱為域名解析，因此負責執行解析(resolution)這一操作的就叫解析器(resolver)了。
解析器實際上是一段程式，它包含在作業系統的 Socket 庫中，在介紹解析器之前，我們先來簡單瞭解一下 Socket 庫。首先，庫到底是什麼東西 呢?庫就是一堆通用程式元件的集合，其他的應用程式都需要使用其中的 元件。庫有很多好處。首先，使用現成的元件搭建應用程式可以節省程式設計 工作量;其次，多個程式使用相同的元件可以實現程式的標準化。除此之 外還有很多其他的好處，因此使用庫來進行軟體開發的思路已經非常普及， 庫的種類和數量也非常之多。Socket 庫也是一種庫，其中包含的程式元件可以讓其他的應用程式呼叫作業系統的網路功能，而解析器就是這個庫中的其中一種程式元件。
通過解析器向 DNS 伺服器發出查詢
解析器的用法非常簡單。Socket 庫中的程式都是標準元件，只要從應用 程式中進行呼叫就可以了。具體來說，在編寫瀏覽器等應用程式的時候，只要像下圖這樣寫上解析器的程式名稱“gethostbyname”以及 Web 伺服器的域名“www.lab.glasscom.com” 就可以了，這樣就完成了對解析器的呼叫 。
呼叫解析器後，解析器會向 DNS 伺服器傳送查詢訊息，然後 DNS 伺服器會返回響應訊息。響應訊息中包含查詢到的 IP 地址，解析器會取出 IP 地址，並將其寫入瀏覽器指定的記憶體地址中。只要執行上圖中的這一行程式，就可以完成前面所有這些工作，我們也就完成了 IP 地址的查詢。接 下來，瀏覽器在向 Web 伺服器傳送訊息時，只要從該記憶體地址取出 IP 地 址，並將它與 HTTP 請求訊息一起交給作業系統就可以了。
順帶一提，向 DNS 伺服器傳送訊息時，我們當然也需要知道 DNS 服 務器的 IP 地址。只不過這個 IP 地址是作為 TCP/IP 的一個設定專案事先設 置好的，不需要再去查詢了。不同的作業系統中 TCP/IP 的設定方法也有差 異，Windows 中的設定如下圖所示，解析器會根據這裡設定的 DNS 服 務器 IP 地址來傳送訊息。
全世界 DNS 伺服器的大接力
DNS 伺服器的基本工作
前文介紹瞭解析器與 DNS 伺服器之間的互動過程，下面來了解一下 DNS 伺服器的工作。DNS 伺服器的基本工作就是接收來自客戶端的查詢訊息，然後根據訊息的內容返回響應。
其中，來自客戶端的查詢訊息包含以下 3 種資訊。
-
域名 伺服器、郵件伺服器(郵件地址中 @ 後面的部分)的名稱
-
Class 在最早設計 DNS 方案時，DNS 在網際網路以外的其他網路中的應用，也被考慮到了，而 Class 就是用來識別網路的資訊。不過，如今除了網際網路並沒有其他的網路了，因此 Class 的值永遠是代表網際網路的 IN
-
記錄型別 表示域名對應何種型別的記錄。例如，當型別為 A 時，表示域名 對應的是 IP 地址;當型別為 MX 時，表示域名對應的是郵件伺服器。對於不同的記錄型別，伺服器向客戶端返回的資訊也會不同
DNS 伺服器上事先儲存有前面這 3 種資訊對應的記錄資料，如下圖所示。DNS 伺服器就是根據這些記錄查詢符合查詢請求的內容並對客戶端 作出響應的。
例如，如果要查詢 www.lab.glasscom.com 這個域名對應的 IP 地址，客 戶端會向 DNS 伺服器傳送包含以下資訊的查詢訊息。
- 域名 = www.lab.glasscom.com
- Class = IN
- 記錄型別=A
然後，DNS 伺服器會從已有的記錄中查詢域名、Class 和記錄型別全部匹配的記錄。假如 DNS 伺服器中的記錄如上圖所示，那麼第一行記錄與查詢訊息中的 3 個專案完全一致。於是，DNS 伺服器會將記錄中的 192.0.2.226 這個值返回給客戶端。然而，Web 伺服器的域名有很多都是像 www.lab.glasscom.com 這樣以 www 開頭的，但這並不是一定之規，只是因為 最早設計 Web 的時候，很多 Web 伺服器都採用了 www 這樣的命名，後來就 形成了一個慣例而已。因此，無論是WebServer1 也好，MySrv 也好，只要是 作為 AA 記錄在 DNS 伺服器上註冊的，都可以作為 Web 伺服器的域名。
在查詢 IP 地址時我們使用 A 這個記錄型別，而查詢郵件伺服器時則 要使用 MXC 型別。這是因為在 DNS 伺服器上，IP 地址是儲存在 A 記錄中 的，而郵件伺服器則是儲存在 MX 記錄中的。例如，對於一個郵件地址 tone@glasscom.com，當需要知道這個地址對應的郵件伺服器時，我們需要提供 @ 後面的那一串名稱。查詢訊息的內容如下。
- 域名 = glasscom.com
- Class = IN
- 記錄型別 = MX
DNS 伺服器會返回 10 和 mail.glasscom.com 這兩條資訊。當記錄型別 為 MX 時，DNS 伺服器會在記錄中儲存兩種資訊，分別是郵件伺服器的域名和優先順序。此外，MX 記錄的返回訊息還包括郵件伺服器 mail.glasscom. com 的 IP 地址。上表的第三行就是 mail.glasscom.com 的 IP 地址，因此只要用 mail.glasscom.com 的域名就可以找到這條記錄。
綜上所述，DNS 伺服器的基本工作就是根據需要查詢的域名和記錄型別查詢相關的記錄，並向客戶端返回響應訊息。
域名的層次結構
在前面的講解中，我們假設要查詢的資訊已經儲存在 DNS 伺服器內部 的記錄中了。如果是在像公司內部網路這樣 Web 和郵件伺服器數量有限的 環境中，所有的資訊都可以儲存在一臺 DNS 伺服器中，其工作方式也就完 全符合我們前面講解的內容。然而，網際網路中存在著不計其數的伺服器，將這些伺服器的資訊全部儲存在一臺 DNS 伺服器中是不可能的，因此一定 會出現在 DNS 伺服器中找不到要查詢的資訊的情況。下面來看一看此時 DNS 伺服器是如何工作的。
直接說答案的話很簡單，就是將資訊分佈儲存在多臺 DNS 伺服器中， 這些 DNS 伺服器相互接力配合，從而查詢出要查詢的資訊。不過，這個機 制其實有點複雜，因此我們先來看一看資訊是如何在 DNS 伺服器上註冊並儲存的。
首先，DNS 伺服器中的所有資訊都是按照域名以分層次的結構來儲存 的。層次結構這個詞聽起來可能有點不容易懂，其實就類似於公司中的事業集團、部門、科室這樣的結構。層次結構能夠幫助我們更好地管理大量的資訊。
DNS 中的域名都是用句點來分隔的，比如 www.lab.glasscom.com，這 裡的句點代表了不同層次之間的界限，就相當於公司裡面的組織結構不用 部、科之類的名稱來劃分，只是用句點來分隔而已。在域名中，越靠右的 位置表示其層級越高，比如 www.lab.glasscom.com 這個域名如果按照公司 裡的組織結構來說，大概就是“com 事業集團 glasscom 部 lab 科的 www” 這樣。其中，相當於一個層級的部分稱為域。因此，com 域的下一層是 glasscom 域，再下一層是 lab 域，再下面才是 www 這個名字。
尋找相應的 DNS 伺服器並獲取 IP 地址
下面再來看一看如何找到 DNS 伺服器中存放的資訊。這裡的關鍵在於 如何找到我們要訪問的 Web 伺服器的資訊歸哪一臺 DNS 伺服器管。
網際網路中有數萬臺 DNS 伺服器，肯定不能一臺一臺挨個去找。我們可 以採用下面的辦法。首先，將負責管理下級域的 DNS 伺服器的 IP 地址注 冊到它們的上級 DNS 伺服器中，然後上級 DNS 伺服器的 IP 地址再註冊到 更上一級的 DNS 伺服器中，以此類推。也就是說，負責管理 lab.glasscom.com 這個域的 DNS 伺服器的 IP 地址需要註冊到 glasscom.com 域的 DNS 伺服器中，而 glasscom.com 域的 DNS 伺服器的 IP 地址又需要註冊到 com 域的 DNS 伺服器中。這樣，我們就可以通過上級 DNS 伺服器查詢出下級 DNS 伺服器的 IP 地址，也就可以向下級 DNS 伺服器傳送查詢請求了。
在前面的講解中，似乎 com、jp 這些域(稱為頂級域)就是最頂層了， 它們各自負責儲存下級 DNS 伺服器的資訊，但實際上並非如此。在網際網路 中，com 和 jp 的上面還有一級域，稱為根域。根域不像 com、jp 那樣有自 己的名字，因此在一般書寫域名時經常被省略，如果要明確表示根域，應該像 www.lab.glasscom.com. 這樣在域名的最後再加上一個句點，而這個最 後的句點就代表根域。不過，一般都不寫最後那個句點，因此根域的存在 往往被忽略，但根域畢竟是真實存在的，根域的 DNS 伺服器中保管著 com、jp 等的 DNS 伺服器的資訊。由於上級 DNS 伺服器保管著所有下級 DNS 伺服器的資訊，所以我們可以從根域開始一路往下順藤摸瓜找到任意 一個域的 DNS 伺服器。
除此之外還需要完成另一項工作，那就是將根域的 DNS 伺服器資訊保 存在網際網路中所有的 DNS 伺服器中。這樣一來，任何 DNS 伺服器就都可 以找到並訪問根域 DNS 伺服器了。因此，客戶端只要能夠找到任意一臺 DNS 伺服器，就可以通過它找到根域 DNS 伺服器，然後再一路順藤摸瓜 找到位於下層的某臺目標 DNS 伺服器(如下圖)。分配給根域 DNS 伺服器 的 IP 地址在全世界僅有 13 個 A，而且這些地址幾乎不發生變化，因此將這 些地址儲存在所有的 DNS 伺服器中也並不是一件難事。實際上，根域 DNS 伺服器的相關資訊已經包含在 DNS 伺服器程式的配置檔案中了，因 此只要安裝了 DNS 伺服器程式，這些資訊也就被自動配置好了。
收到客戶端的查詢訊息之後，DNS 伺服器會按照前面的方法來查詢 IP 地址，並返回給客戶端。這樣，客戶端就知道了 Web 伺服器 的 IP 地址，也就能夠對其進行訪問了。
委託協議棧傳送訊息
資料收發操作概覽
知道了 IP 地址之後，就可以?託作業系統內部的協議棧向這個目標 IP 地址，也就是我們要訪問的 Web 伺服器傳送訊息了。要傳送給 Web 服務 器的HTTP訊息是一種數字資訊(digital data)，因此也可以說是?託協議 棧來傳送數字資訊。收發數字資訊這一操作不僅限於瀏覽器，對於各種使 用網路的應用程式來說都是共通的。因此，這一操作的過程也不僅適用於 Web，而是適用於任何網路應用程式。下面就來一起探索這一操作的過程。
和向 DNS 伺服器查詢 IP 地址的操作一樣，這裡也需要使用 Socket 庫中 的程式元件。不過，查詢 IP 地址只需要呼叫一個程式元件就可以了，而這 裡需要按照指定的順序呼叫多個程式元件，這個過程有點複雜。傳送資料是 一系列操作相結合來實現的，如果不能理解這個操作的全貌，就無法理解其 中每個操作的意義。因此，我們先來介紹一下收發資料操作的整體思路。
使用 Socket 庫來收發資料的操作過程如下圖所示。簡單來說，收發資料的兩臺計算機之間連線了一條資料通道，資料沿著這條通道流動，最終到達目的地。我們可以把資料通道想象成一條管道，將資料從一端送入 管道，資料就會到達管道的另一端然後被取出。資料可以從任何一端被送入管道，資料的流動是雙向的。不過，這並不是說現實中真的有這麼一條管道，只是為了幫助大家理解資料收發操作的全貌。
收發資料的整體思路就是這樣，但還有一點也非常重要。光從圖上來 看，這條管道好像一開始就有，實際上並不是這樣，在進行收發資料操作 之前，雙方需要先建立起這條管道才行。建立管道的關鍵在於管道兩端的 資料出入口，這些出入口稱為套接字。我們需要先建立套接字，然後再將 套接字連線起來形成管道。實際的過程是下面這樣的。首先，伺服器一方 先建立套接字，然後等待客戶端向該套接字連線管道。當伺服器進入等待狀態時，客戶端就可以連線管道了。具體來說，客戶端也會先建立一個套 接字，然後從該套接字延伸出管道，最後管道連線到伺服器端的套接字上。 當雙方的套接字連線起來之後，通訊準備就完成了。接下來，就像我們剛 剛講過的一樣，只要將資料送入套接字就可以收發資料了。