《網路是怎麼樣連線的》讀書筆記 - 認識網路基礎概念（一）

lazytimes發表於2022-06-19
筆記

《網路是怎麼樣連線的》讀書筆記 - 認識網路基礎概念（一）

講講歷史

1991年8月6日，在瑞士日內瓦的核子研究中心（CERN）工作的英國物理學家蒂姆·伯納斯·李（Tim Berners-Lee），正式提出了World Wide Web，也就是如今我們非常熟悉的www。

www是什麼？全球資訊網WWW是World Wide Web的簡稱，也稱為Web、3W等。WWW是基於客戶機/伺服器方式的資訊發現技術和超文字的綜合技術。

這裡個人比較好奇我們天天都在說3w，3w，但是網際網路是怎麼出現的的書中並沒有解釋？

這裡查了下網上資料根據個人理解解釋一波：

實際上網路最開始苗頭出現在美蘇冷戰的時期美國建立的APRA科研部門，被突然扯出來的科研部門一盤散沙不知道幹嘛，對付蘇聯的科研工作也沒什麼進展，直到一個叫做羅伯特·泰勒的哥們出現，他的突破口是發現小型的通訊網路不能相容不同型號的計算機，我們都知道技術的頂峰就是定規則，毫無疑問他選擇構建一套協議讓所有的計算機都能遵守這一套規則幹活。

於是他找來了幾個牛逼的大佬開始搗鼓，中間巴拉巴拉做了很多事繞了很多彎，目的其實就是為了實現上面說的東西，最終在一次失敗的“LOGIN”驗證中雖然僅僅傳輸了“LO”兩個字母就斷開了，但是這次失敗是歷史性的進步，因為兩個不同的裝置實實在在的通訊了，最終修復之後完成了這五個字母的正常傳輸。

隨後捯飭出的ARPANET（阿帕網） 這個專案，也就是正式的網際網路雛形。

課外知識到此結束，現在我們看看第一章主要看點：

  1. 如何解析網址？
  2. DNS 伺服器如何查詢域名對應的 IP 地址？
  3. DNS伺服器如何接力？
  4. 瀏覽器如何將訊息委託給作業系統傳送給 Web 伺服器？

核心是理解DNS的角色地位和作用，以及瀏覽器如何跟DNS互動完成網址（域名）解析為IP這一個操作的，本章最後的委託流程是整個第二章的重點內容，筆記順其自然的放到了第二章筆記當中，為了方便理解把筆記歸納到第二部分。

如何解析網址

我們從URL開始，什麼是URL，URL是Uniform Resource Locator的簡稱，專業解釋叫做統一資源定位符，除開我們常見的http、https協議之外，瀏覽器還可以進行ftp檔案上傳，下載檔案，傳送電子郵件，瀏覽新文化等操作。

我們把這些行為看作是資源互動，雖然不同的資源互動會存在不同的URL組合，但是不管URL的組合形式如何變化，最終是開頭決定一切，開頭部分決定對待資源方式。

解析網址我們可以看下面的例子：

img

碰到省略檔名的情況，通常下面幾種：

  • http://xxxx/dir/表示 /dir/ 之後的內容被省略，這時候通常情況下會設定對應這個目錄的真實訪問路徑進行補全。
  • 對於web中最為經典的http://localhost:8080/訪問路徑，通常情況下Web伺服器會訪問到/index.html這個檔案，如果沒有就會返回404的頁面。
  • 如果只有域名，比如www.baidu.com，那就會直接訪問web伺服器設定的根路徑對應的資源和相關檔案。
  • 含混不清的路徑比如http://localhost:8080/wishlist，則會根據先判斷是否為檔名，然後判斷是否為目錄的情況處理，或者看作一個請求對映到另一處資源，或者做一次重定向。

上面的內容不必深究，只需要明白瀏覽器的第一步工作就是對 URL 進行解析。

Http請求

http請求簡單來說可以簡單概括為一句話：對什麼做了什麼樣的操作，所謂對什麼指的是URL，表示標識了的目標物件，做什麼樣的操作就是所謂的方法，方法主要是分為兩個POST和GET方法，其他方法基本沒啥用處，個人只在偶爾幾個對接文件中遇到過PUT和HEAD方法。

img

GET方法：通常用於一些可見資源的訪問，或者開放資源的訪問，通常情況下不需要過多的限制就可以直接向具體的目錄尋找需要的資源。

POST方法：比較常見的是使用表單或者 AJAX的方式訪問，並且通常會指向一個WEB的應用程式，獲取應用程式的資料需要傳遞伺服器需要的一些有效引數，否則服務端會根據具體情況通知客戶端無權訪問。

AJAX即“Asynchronous JavaScript and XML”（非同步的JavaScript與XML技術），指的是一套綜合了多項技術的瀏覽器端網頁開發技術。Ajax的概念由傑西·詹姆士·賈瑞特所提出[1]。

Http請求訊息

知道了 對什麼做了什麼樣的操作，現在來看看Http 具體是怎麼做這件事情的。

Http請求訊息主要分為下面組織結構：

  • 第一行最開頭的部分提取URL的內容，原封不動解析，末尾為HTTP版本號主要標記當前HTTP請求版本。
例如：GET /cgi/sample.cgi?Field1=ABCDEFG&SendButton=SEND HTTP/1.1

  • 第二行為訊息頭，這裡列舉一些簡單的內容：

    • Data：請求響應生成日期。
    • Pragma：資料是否允許快取。
    • Transfer-Encoding：訊息主體編碼格式（重要）。
    • Via：經過的代理和閘道器。
  • 訊息頭後面存在一行 完美沒有內容的空行。
  • 第四行為訊息體，但是實驗用的是GET方法所以通常內容為空。

img

我們以訪問谷歌為例，下面的內容訪問谷歌搜尋頁面的一次請求參考，這裡的內容直接通過谷歌瀏覽器的F12拷貝，可以看到基本包含了請求行，訊息頭和訊息行（GET通常沒有所以下面沒有體現）三種。

常規

1.  請求網址:https://www.google.com/
2.  請求方法:GET
3.  狀態程式碼:200
4.  遠端地址:127.0.0.1:7890
5.  引薦來源網址政策:origin

請求標頭

1.  :authority:www.google.com
2.  :method:GET
3.  :path:/
4.  :scheme:https
5.  accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
6.  accept-encoding:gzip, deflate, br
7.  accept-language:zh,zh-TW;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6
8.  cache-control:no-cache
9.  cookie:SID=KQi0QVpC_wxTynb6H6HjGmVq-9mYvCuIDOMx9EmEUJ8ii7dJzN_1F-ho69FdK6AN9ekOkA.; __Secure-1PSID=KQi0QVpC_wxTynb6H6HjGmVq-9mYvCuIDOMx9EmEUJ8ii7dJaTdIpqSfRfNb-BvF0haitA.; __Secure-3PSID=KQi0QVpC_wxTynb6H6HjGmVq-9mYvCuIDOMx9EmEUJ8ii7dJ6_WQQeEF09oAZ9MQfe21sA.; HSID=AOdmIhuBCutDeMwVS; APISID=ckyVXTB27QMaC2gQ/AVulr1cMnMbpD0e1x; SSID=AL0-0R0Ofsj3zaqrr; SAPISID=dqpTwJeh7bnii2Ki/AfsaDUfE8uMVR1aqv; __Secure-1PAPISID=dqpTwJeh7bnii2Ki/AfsaDUfE8uMVR1aqv; __Secure-3PAPISID=dqpTwJeh7bnii2Ki/AfsaDUfE8uMVR1aqv; SEARCH_SAMESITE=CgQIvJUB; 1P_JAR=2022-05-24-23; AEC=AakniGOKhznRpAD797X4u508i2XHJjEVYQQHANlqaJC2JSZ1F7mAe-vX_rg; NID=511=K-qt_LW-4ad1IYdJgfPLZjJw772wez2L3_FK9hwrrHAaksdhT8bTqz4icJEnJviOb92zcnyfS4h7P8HB_Is0f_FebYTe_5DR3qFEclHS1R9N1P7r9pv7Z4p12341S72RZRfzIlQ3-CVZUqQKBm1Xy1i9fKwejMGHTPMY2hk02sA--ey8nAEyt1_A7SVMe0RvrEkPnVm88fBnyyyFMMSCeSG1oqYKeC2x7iHJ0GwdbEpeGojpMQyQxAn1jAdxyXbC0oko0rCFjYn7eUREz2A9KA; SIDCC=AJi4QfGQeW0y_3pnzuBs7KI-WabF5XR_-dQchpcoNUN_bRVICBknb39qNQhP4IklnPn6kW4M3d8; __Secure-3PSIDCC=AJi4QfFOaoqiWv0mqmOskkIKVYy_-QNOATkPOyhNt9B8BBTMnRqnv-0zdgVgBNmIJRwlzBS4x6U
10.  pragma:no-cache
11.  sec-ch-dpr:2
12.  sec-ch-ua:" Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"
13.  sec-ch-ua-arch:"arm"
14.  sec-ch-ua-bitness:"64"
15.  sec-ch-ua-full-version:"101.0.4951.64"
16.  sec-ch-ua-full-version-list:" Not A;Brand";v="99.0.0.0", "Chromium";v="101.0.4951.64", "Google Chrome";v="101.0.4951.64"
17.  sec-ch-ua-mobile:?0
18.  sec-ch-ua-model:""
19.  sec-ch-ua-platform:"macOS"
20.  sec-ch-ua-platform-version:"12.3.1"
21.  sec-ch-ua-wow64:?0
22.  sec-ch-viewport-width:1440
23.  sec-fetch-dest:document
24.  sec-fetch-mode:navigate
25.  sec-fetch-site:same-origin
26.  sec-fetch-user:?1
27.  upgrade-insecure-requests:1
28.  user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36
29.  x-client-data:CLG1yQEIkrbJAQijtskBCMS2yQEIqZ3KAQjYjMsBCJShywEI2+/LAQjmhMwBCNupzAEI/qrMAQjDrMwBCKSvzAEYqKnKARirqcoB
30. 已解碼：message ClientVariations { // Active client experiment variation IDs. repeated int32 variation_id = [3300017, 3300114, 3300131, 3300164, 3313321, 3327576, 3330196, 3340251, 3342950, 3347675, 3347838, 3348035, 3348388]; // Active client experiment variation IDs that trigger server-side behavior. repeated int32 trigger_variation_id = [3314856, 3314859]; }

響應內容

響應頁面也是類似的需要回應請求行需要的內容資訊，同時告知自己允許接受什麼樣的請求，如果目標IP找不到通常會變為404結果。

響應標頭

1.  accept-ch: Sec-CH-Viewport-Width  
2.  accept-ch: Sec-CH-Viewport-Height
3.  accept-ch: Sec-CH-DPR
4.  accept-ch: Sec-CH-UA-Platform
5.  accept-ch: Sec-CH-UA-Platform-Version
6.  accept-ch: Sec-CH-UA-Full-Version
7.  accept-ch: Sec-CH-UA-Arch
8.  accept-ch: Sec-CH-UA-Model
9.  accept-ch: Sec-CH-UA-Bitness
10.  accept-ch: Sec-CH-UA-Full-Version-List
11.  accept-ch: Sec-CH-UA-WoW64
12.  alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
13.  bfcache-opt-in: unload
14.  cache-control: private, max-age=0
15.  content-encoding: br
16.  content-length: 43734
17.  content-type: text/html; charset=UTF-8
18.  date: Tue, 24 May 2022 23:24:59 GMT
19.  expires: -1
20.  server: gws
21.  set-cookie: 1P_JAR=2022-05-24-23; expires=Thu, 23-Jun-2022 23:24:59 GMT; path=/; domain=.google.com; Secure; SameSite=none
22.  set-cookie: AEC=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com
23.  set-cookie: AEC=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com
24.  set-cookie: AEC=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com
25.  set-cookie: AEC=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com
26.  set-cookie: SIDCC=AJi4QfEXTiPm1BcAx1gfQzXOs-hmdcHylOVoSbbpy8cUIlP7hNwwfnfo_E8ZdTY1JZli8AqYYWk; expires=Wed, 24-May-2023 23:24:59 GMT; path=/; domain=.google.com; priority=high
27.  set-cookie: __Secure-3PSIDCC=AJi4QfFdxOIbJrwDKltt2sBRVFIcLOCyqQmgTSfYjXTYwqbhh0GPLcR9cxsgyaIh1j_GITbGeHc; expires=Wed, 24-May-2023 23:24:59 GMT; path=/; domain=.google.com; Secure; HttpOnly; priority=high; SameSite=none
28.  strict-transport-security: max-age=31536000
29.  x-frame-options: SAMEORIGIN
30.  x-xss-protection: 0

響應內容相對比較簡單，主要關注重點為第一行內容中的狀態碼和響應短語，請求執行結果是成功還是失敗。上面的互動內容需要注意Http請求嚴格遵循一個請求對應一個響應內容。

注意：1 條請求訊息中只能寫 1 個 URI。如果需要獲取多個檔案，必須對每個檔案單獨傳送 1 條請求。

“如何解析網址？”這個問題從頭到尾的介紹到這裡就完成的，接下來來看看下一個問題"DNS 伺服器如何查詢域名對應的 IP 地址？"。

IP 和 DNS

首先我們看看IP和DNS是啥，解析網址（域名）和傳送請求和響應內容看似是瀏覽器完成的，實際上它並不具備這些功能， 瀏覽器收發網路請求實際上需要依託作業系統完成 ，而現代網路基本是TCP/IP 的天下，所以IP發揮關鍵作用，而DNS儲存IP和域名對映的倉庫。

  • IP：可以類比做我們現實的具體位置，比如XX路XX號，XX路（網路號）對應的的是分配給整個子網的號碼，而XX號（IP地址）的號碼則分配給子網中的計算機，獲得到IP地址之後就相當於鎖定了當前計算機所在的具體位置，自然也可以可以找到了。
  • DNS：直白來講就是儲存了域名和IP對映的記錄的站點，瀏覽器要獲取真實安排需要找DNS才能知道，因為域名放任使用者自由定義將會出現同一個域名對映多個IP。

下面我們先觀察XX路XX號的號也就是IP地址是如何被找到的。

傳送網路的一方通過子網首先需要經過集線器，把內容轉發到最近的路由器上，然後路由器會不斷跨越找到離接受者更近的下一個路由器，最後再找到集線器然後在轉發到接收者的路由器上，路由器在這裡是方向盤的角色，而DNS定址就像是導航。

img

集線器和路由器是什麼？ A　路由器：一種對包進行轉發的裝置。 B　集線器：一種對包進行轉發的裝置， 分為中繼式集線器和交換式集線器兩種.

IP地址的組成

IP地址是一個32位的Bit數，通過8個bit為一組分為4組，每一組用十進位制表示並且使用小圓點斷開。

但是僅憑這32個bit是無法定位IP地址和網路號的，所以需要給IP地址附加資訊。

通常IP地址的組合有下面的方法：

a）IP地址主體：11.22.33.44

b）IP和子網掩碼：11.22.33.44/255.255.255.0

c）網路號的位元數作為子網掩碼錶示：11.22.33.44/24

d）子網地址：11.22.33.0/24，此時代表了整個子網

e）子網廣播地址：11.22.33.255/24

首先整個IP分為32位固定長度，每四個為一組用圓點分隔，通過 0 - 255的十進位制表示，比如0就是8個0，255就是8個1，但是僅僅憑藉32個位數是沒法辨別這32位那一部分是網路號，那一部分是主機號的，所以下面是IP的基本組成：

  • 11.22.33.44：表示基本的IP。
  • 11.22.33.44/255.255.255.0：前面部分是基本IP，後面的部分表示子網掩碼，表示方式和IP地址一致，注意最後的8位全部為0表示整個子網。
  • 11.22.33.44/24： 這個24也是子網掩碼，但是表示子網的方式是使用位元數。
  • 11.22.33.0/24： 子網掩碼沒有變，IP地址變了，最後的8位0也是表示整個子網。
  • 11.22.33.255/24： 子網掩碼沒有變，IP地址變了，最後的8位全部位1表示廣播 整個子網。

什麼是子網掩碼？

初學者可能比較難以理解的概念，這裡如果看不懂建議多找找資料挑一個看得懂的解釋（關鍵是自己理解並且能自己複述）。

下面是從書中原圖，個人看完感覺並不是特別直觀也不知道幹嘛，所以做了一個補充說明。

實際上下面圖中網路號用了AND（位操作 &）計算出網路號碼，計算之後確認出網路號是10.1.2，而後面省略的部分其實是8個0的掩碼掩蓋主機，這裡的子網就是 10.1.2.0，對應的主機IP是10.1.2.3。

如果看不懂上面說的是啥，這裡補充解釋一下：

首先我們需要清楚子網掩碼這東西是幹嘛的，說白了就是劃分網路號和主機號的，網路號可以看作一棟樓，主機是裡面的小房間，但是房間編號可能是101，也可能是0101，更有可能是00101，具體得看掩蓋的房間號從0000到1111有多少個，決定能分配給多少主機，而計算機0又很特殊，所以網路號的部分+ 子網掩碼掩蓋的位數部分（表現全為0）組成一個子網，只有在同一個子網的主機才能互相通訊。

所以子網掩碼不能單獨存在，它必須結合IP地址一起使用，子網掩碼主要分為兩個部分：全為1表示網路號，全為0表示的是主機號。

那麼我們隨便設定一個子網掩碼比如255.255.255.111行不行？

答案是不行，不行，不行。因為子網掩碼 必須是 連續的 1和0 組成，上面的掩碼255.255.255.0 才是正確的用法，再舉例比如255.255.255.244也是合格的子網掩碼。

我們舉例說明一下：

1100 0000.1010 1000.0000 0001.1000 0001 -- 192.168.1.129
1111 1111.1111 1111.1111 1111.0000 0000 -- 255.255.255.0
———————————————————— 
1100 0000.1010 1000.0000 0001.0000 0000 -- 劃分出最終子網網段：192.168.1.0
注：確認最終的網路號和主機網段使用了位操作 & （1 & 1 = 1，1 & 0 = 0）

從最終的結果來看192.168.1.0 的前面24位都為1是暴露的，而後面8位被子網掩碼給遮掩住，所以他的另一種寫法是192.168.1.0/24，表示24位是1代表網路號，剩餘的8位用於表示主機號但是因為被掩蓋了所以全部為0。

雖然被掩蓋了，但是主機號位置是0是1不需要關心的，主機號如果落在192.168.1.0到192.168.1.255表示同在一個網段內子網一視同仁，比如192.168.1.129表示其中的129位，包含在這個網段之內。

小結

  1. 子網掩碼 必須是 連續的 1和0 組成，簡單記憶為1的部分來分割網路號，為0的部分用於掩蓋主機號，同一個子網內的主機可以互相通訊。
  2. 子網掩碼有兩種寫入方式一種是使用和I P 地址一樣的32位完全表示方式，另一種是使用數字計算1位元數進行替換，比如24就是下面圖中的24個1。
  3. IP 地址的主機號，全 0表示整個子網，全 1表示向子網上所有裝置傳送包。這裡補充一下全為1的情況 - “廣播”。
廣播是什麼意思？廣播地址是專門用於同時向該網路中所有主機進行廣播的一個地址，只要是在同一個網段的主機都可以收聽到廣播。（例如192.168.211.32/24的廣播地址為：192.168.211.255）

DNS

DNS： Domain Name System 域名服務系統，最常見的用法是將伺服器名稱和 IP 地址進行關聯，當然只是它的主業，他有一些副業也挺重要但是不是關鍵感興趣瞭解即可。

IP是難以記憶的，而簡短域名更容易被人記住。你可能會覺得域名長了也難記憶啊，雖然解析IP的速度要比解析域名來的快的很多，但是顯然網民為了訪問一個網站要記住一串數字顯然是不可能的，同時域名實際上對於當時的網際網路發展來說也是有意義的。

所以誰來告訴主機域名的真實IP是多少？這時候DNS就上場了，DNS的作用是說白了就是用來對映IP和域名的一個東西。

DNS是如何完成對映的？對於使用者主機來說一定存在一個用於解析DNS的客戶端，這個客戶端通常被稱為解析器，通過域名解析出IP地址的過程也被稱為域名解析。

呼叫解析器

那麼如何呼叫解析器？解析器實際上就是一段程式程式碼，這一段程式程式碼包含在底層作業系統的Socket庫當中，通過Socket庫呼叫解析器，然後解析器會向 DNS 伺服器傳送查詢訊息， DNS 服 務器根據請求查詢IP然後返回響應訊息。

Socket 解析域名的過程非常簡單，只需要一行程式碼就可以完成：gethostbyname("www.lab.glasscom.com");。

庫：指的是通用程式元件的集合，用於規範程式程式碼的規範組建。以解析器為例，Socket 庫是用於呼叫網路功能的程式元件集合。

解析器內部又是如何工作的？

在應用程式呼叫解析器的時候，此時控制權會轉移到解析器，當控制權轉為解析器之後解析器會生成要傳送給 DNS 伺服器的查詢訊息，生成過程類似構建一條“請告訴XXX的IP地址”的訊息，並且發給DNS伺服器完成解析。

特別注意注意傳送請求不是由解析器完成，而是需要再次委託給作業系統的協議棧完成，所以此時許可權會再次轉移到協議棧，協議棧最終通過網路卡把訊息發給DNS，然後DNS查到IP返回訊息，至此一次DNS解析請求就完成了。

值得注意的是 解析器會將取出的 IP 地址寫入應用程式指定的記憶體地址中，此外還需要注意請求DNS伺服器本身IP也是需要配置的，只不過這個 IP 地址是作為 TCP/IP 的專案事先設定好的，不需要再去查詢直接就可以獲取。

最後在不同的作業系統中獲取DNS伺服器的地址方式會有差別。

根據上面的描述，總結DNS解析流程：

  1. WEB瀏覽器傳送域名解析請求，通過Socket向解析器進行請求解析，此時應用程式將會掛起。
  2. 解析器負責“翻譯”應用程式的DNS解析請求，但是把具體的請求操作委託給系統棧。
  3. 系統棧負責將請求通過網路卡傳送給DNS伺服器，等待DNS反饋結果。
  4. DNS獲取真實IP之後將結果通過鏈路反向回送到應用程式。

DNS工作

接下來我們看看dns要如何工作，dns需要查詢使用者訊息包含下面幾個部分：

  • 域名：用來替代IP方便記憶。
  • class：考慮到網際網路之外的情況，當然外部網路現在只有標識為in的網際網路。
  • type：表示記錄型別用於區分dns的解析方式，不同型別結果不同。

需要注意的是所有a型別的記錄在DNS上註冊了，再比如所有郵件型別都是MX的型別，整個DNS工作其實就簡單的根據型別和域名進行查表，找到匹配的就回傳，否則就會找不到。

域名層次：所謂域名層次就是DNS不可能是一臺伺服器，而是需要多臺伺服器配合，各自管理自己範圍的內容，而對於域名來說越靠右邊的部分在域名的層次裡面越高。

這樣看來是不是有點意思，以日常生活舉例並不是我們認為的www是最高，其實他是最低的等級，.com才是最高的。

DNS查詢步驟

首先將負責管理下級域的 DNS 伺服器的 IP 地址註冊到它們的上級 DNS 伺服器中，然後上級 DNS 伺服器的 IP 地址再註冊到更上一級的 DNS 伺服器中，以此類推。

舉個例子，需要解析等域名為www.baidu.com，DNS需要事先把整個www.baidu.com整個域名註冊到baidu.com，再把baidu.com註冊到com域名，再把com註冊到根域，這樣就可以通過上級找下級。

這裡提到DNS有一個根域，根域名指的是就是一個句點 . ，和Linux的根路徑意義表現形式上類似。

根據根域可以解釋為什麼任何奇怪等域名都可以被訪問到，原因是所有的下級都會註冊到上級中，最後都有一個共同的 ，如果所有下級要找到根域，自然需要註冊根域這個句點。

DNS查詢的過程是自下而上找最近的DNS然後自上而下找根域向下查詢的的，也就是先找最近的dns找，沒有找到就需要直接從根域進行查詢，一路通過層級下探找到最終的ip，這也是為什麼訪問國外ip慢的原因，因為路由鏈路實在是很長，可能需要幾十次dns搜尋查詢。

DNS快取

如果每個主機每次請求總是要通過DNS獲取域名對應的IP資訊，是不可能每次都DNS讓找一遍的，實際上解析到的真實IP會預先快取起來下次訪問重複的資料直接返回即可。

另外雖然前面介紹的是查詢自上而下從根域向下查詢，實際上DNS還可以利用快取特性通過多個層級的共享域名加快訪問速度跨級查詢，比如www.baidu.com和www.baidu 可以共享快取直接跳兩個層級快速找到（當然這裡其實找最近的一個DNS就能找到，這裡僅僅是舉例）。

但是快取有個副作用，就是不存在的ip地址訊息也會快取，不過為了防止這種情況一般會有過期時間，過期之後依然需要再次走一遍DNS查詢流程。

問題引導：問題

表示的是HTTP 協議

  • 下面兩個網址有什麼不同？

a. http://www.nikkeibp.co.jp/sample

b. http://www.nikkeibp.co.jp/sam...

區別點在於sample 可能被解析出和預期不符合的結果。

用來識別連線在網際網路上的計算機和伺服器的地址叫什麼？

IP地址

根據 Web 伺服器的域名來查詢 IP 地址時所使用的伺服器叫什麼？

DNHS伺服器

向 DNS 伺服器傳送請求訊息的程式叫什麼？

解析器。

相關文章