帶你在網路世界裡飛-瀏覽器
在上一篇文章（帶你在網路世界裡飛-模型及協議）中，從系統的層面說了計算機是如何傳輸電信號的，各種協議在每一層又是如何起作用的。這篇文章，我將站在用戶的角度從頭捋一遍，數據是如何傳輸的，域名又是如何解析的。。。
首先我們拿到一台電腦，現在大多都是直接連接wifi就能實現上網，當然也有通過插網線撥號連接實現聯網。但不管哪種方式，都離不開這幾個配置項：ip地址，子網掩碼，默認網關，dns伺服器。。。
上一篇提到ip地址是由集成在路由器中的DHCP服務自動分配的，那這個DHCP服務是如何工作的呢？這裡需要先對DHCP服務有個清醒的認識。
首先DHCP（Dynamic Host Configuration Protocol）是基於UDP協議的動態主機配置協議，主要用途是給接入網路的主機分配ip地址，而運行DHCP服務的網路設備就叫做DHCP伺服器。現在的路由器都具備DHCP服務還不用單獨設置，同時還具有DNS（Domain Name System）服務，NAT（Network Address Translation）服務等。另外大家還需要注意，同一個區域網內一般只會存在一個DHCP服務，多個會造成ip衝突。
由於DHCP是基於UDP協議，因此數據包如下圖：
假如一台新的電腦，通過wifi連接上網，則會自動發生以下一系列的事情，也就是DHCP服務具體的工作流程：
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埠。（注意這裡的埠號就小於1024，因此它是系統級別的）
4，這個數據包構造完成後，就可以發出了。乙太網是在子網內是廣播傳輸，同一個子網路的每台計算機都收到了這個包。因為接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是發給誰的，所以每台收到這個數據包的計算機，還必須分析這個包的IP地址，才能確定是不是發給自己的。當看到發出方IP地址是0.0.0.0，接收方是255.255.255.255，於是DHCP伺服器知道這個包是發給自己的，而其他計算機就可以丟棄這個包。
5，DHCP伺服器讀出這個包的數據內容，分配好IP地址，發送回去一個"DHCP響應"數據包。這個響應包的結構也是類似的，乙太網標頭的MAC地址是雙方的網卡地址，IP標頭的IP地址是DHCP伺服器的IP地址（發出方）和255.255.255.255（接收方），UDP標頭的埠是67（發出方）和68（接收方），分配給請求端的IP地址和本網路的具體參數則包含在Data部分。
6，新加入的計算機收到這個響應包，就知道了自己的ip地址，子網掩碼，網關地址，dns伺服器地址等等。
1，當輸入網址，敲擊回車後，意味著瀏覽器要給百度伺服器發送一個網頁請求的數據包。這個數據包的內容就是告知百度伺服器，我要請求你首頁的相關數據。
2，但是由於發送數據包需要知道對方主機的ip地址，但是我們現在只知道百度的域名，不知道百度的ip怎麼辦？於是dns協議出場了，它可以根據域名信息解析出其對應的ip地址。假設本地dns伺服器（連上網後會自動獲得）為114.114.114.114，於是瀏覽器向這個本地dns伺服器發送一個DNS數據包（53埠），由於dns協議也是基於UDP協議（所謂基於UDP，只是數據是通過UDP協議傳輸的而已），因此數據包樣式如下：
（詳細的dns解析過程在文章底部）
3，經過上一步已經有了ip地址了，因此子網掩碼就開始起作用了，並分別與本機的ip和百度的ip進行AND運算，發現結果不一致。則斷定本地電腦和百度的主機不在同一個子網內，因此數據包只能發送給路由器中的網關，然後通過網關向外轉發數據包，因此數據包的接收方mac地址變為網關地址。
4，到這裡我們就知道了數據包的mac地址和ip地址，這一步開始處理基於http協議的數據包，即http數據包，瀏覽器網頁用的協議就是http協議，且http協議是基於TCP協議，因此http數據包嵌入到TCP數據包內，此時的數據包為下圖:
而具體的http數據如下圖但不局限下圖：
5，既然http數據包嵌入到了TCP數據包里，那TCP數據包為了區分是不同的應用程序，還必須在數據包里添加埠信息，接收方（baidu）的默認埠為80，而本機作為發送方，埠隨機產生一個在1025~65535之間的都可以。
6，上一步生成的TCP數據包再嵌入到IP數據包內，ip數據包需要設置雙方的ip地址，這是已知的，在第二步已獲得baidu的ip地址，而本機則已知。
我們知道乙太網數據包的數據部分的長度限制為1500位元組，因此當整個ip數據包嵌入後，很容易超過，因此此時需要將ip數據包分割，每個分割後的包都有自己的ip標頭序號，且ip數據包的長度都為1500位元組，不足的除外。如下：
8，經過前面七步的處理，數據包經過多個網關轉發，最終被百度的伺服器收到，而且收到的是多個乙太網數據包。然後根據ip標頭序號，百度將多個數據包拼接起來，取出完整的TCP數據包，然後讀出裡面的http請求，接著做出http響應，再用TCP協議發回來。
本機收到http響應後，就可以將網頁顯示出來，便完成一次網路通信。可以在再結合下圖，回顧一下上面的過程：
---DNS解析---
我們知道dns（Domain Name System，域名系統）主要作用是根據域名解析出其對應的ip地址的。但還需要知道一些這個解析過程以及需要用到哪些服務？
其實當我們在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智能的匹配你可能要輸入的url了，瀏覽器會從歷史記錄，書籤等地方，找到已經輸入的字元串可能對應的url，然後會給出智能提示，讓你可以補全url地址。對於chrome瀏覽器，甚至可以直接從緩存中把網頁顯示出來，也就是還沒等到你按下enter，頁面就顯示出來了。。。
在了解具體的解析過程之前，首先了解一下dns伺服器是怎麼回事？
所謂dns伺服器不過是安裝了dns服務端軟體的計算機罷了，服務端軟體可以基於linux系統，也可以基於windows系統。安裝好dns服務端軟體後，就可以在指定的位置創建區域文件了，這個區域文件就包含了該域中域名與ip地址的映射關係，其實有點類似按名字解析的分層結構資料庫。
在早期的時候由於計算機和域名數量都很少，人們又記不住複雜的數字組合，這才有了hosts文件的存在，裡面記錄域名與ip地址的對應關係。但隨著全世界域名數量的爆炸式增長，hosts已無法滿足需求，所以才出來的這個dns服務架構：
然後敲擊回車後，瀏覽器才開始查找域名的ip地址，分以下幾步：
1，一旦敲擊回車，就發送了請求，瀏覽器開始解析這個域名，一般瀏覽器會首先查看本地硬碟的hosts文件，看看其中有沒有和這個域名對應的規則，如果有則直接使用hosts文件里的ip地址。
因此有時候如果hosts文件設置錯誤，就會出現訪問某個域名打不開頁面的情況。這裡再說說什麼時候配置hosts，一般發生在公司內部，比如公司有些域名必須通過公司內網或vpn才能打開，這時候如果想在公司外辦公，則需要連上vpn然後再把hosts文件配置成公司給的對應規則才可以。至於為什麼需要配置，因為公司內部的域名與ip對應規則在公共的dns伺服器上沒有，如果想訪問則必須配置。除非公網域名才可以不用配置
2，如果在本地的 hosts 文件沒有找到域名對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS伺服器 。本地DNS伺服器一般都是電腦聯網自動生成的那個，當然也可以自己添加其他dns伺服器。
3，請求到達本地dns伺服器，本地dns伺服器會首先查詢它的緩存記錄，如果緩存記錄中有此條記錄，就可以直接返回結果，如果沒有則本地dns伺服器還需要向根dns伺服器查詢。
4，根dns伺服器沒有記錄具體的域名和ip地址的對應關係，而是告訴本地dns伺服器，你可以到域dns伺服器上繼續查詢，並給出了域dns伺服器的地址。然後本地dns伺服器再向域dns伺服器發起請求。
5，本地dns伺服器向域dns伺服器發請求，到這一步就可以找到域名和ip的對應關係了，但是域dns伺服器並不是直接把域名和ip對應關係返回給本地dns伺服器，而是告訴本地dns伺服器，域名的解析伺服器的地址，你去那要吧。
6，最後本地dns伺服器再向域名解析伺服器（即註冊的域名在哪個平台解析的，常用阿里雲等）發出請求，這時本地dns伺服器就能收到域名和ip的對應關係，本地dns伺服器不但要把對應關係返回給瀏覽器客戶端，還要緩存這個對應關係以備下次使用，加快訪問效率。
注意：在第3步，當本地dns伺服器沒有域名和ip地址的對應關係時，本地dns伺服器會再去根dns伺服器請求，這個過程是遞歸查詢的方式，也是大多數dns伺服器採用的方式。但還有另外一種方式，也就是本地dns伺服器把根dns伺服器的地址返回瀏覽器客戶端，由瀏覽器客戶端再次向根dns伺服器電腦發送請求，這個過程是迭代查詢的方式。
遞歸和迭代查詢的發起方不同，前者是本地dns伺服器，後者是瀏覽器客戶端，在效率上遞歸更高，因此多採用遞歸，而且也是dns伺服器默認的查詢的方式。
如下圖：
---NAT服務---
如果你夠仔細，或許還看到NAT服務，那它到底是個神馬呢？
1，NAT(Network Address Translation 網路地址轉換)，也叫網路掩蔽或ip掩蔽，作用就是將區域網內要訪問外網的主機ip和埠換成路由器申請的外網ip和埠，這樣就可以讓外部的網路認為請求是路由器發出去的。當數據從外網響應回來時，再反向換成內網主機的ip和埠即可，這樣就實現了區域網內部的主機上網的需求。
但是。。。NAT有一個問題，就是區域網內的主機訪問外網時，需要路由器主動分配ip和埠，這樣的話，使用電驢這種p2p軟體就不好使了，因為使用p2p軟體時區域網內的主機相當於一個伺服器，既然是伺服器，按理說是可以被外網訪問的，但是別忘了，區域網內的主機地址是路由器分配的，是一個內網地址，外網肯定訪問不了。。。因此為了解決這個問題，就出現了UPnP協議，如下：
2，UPnP(Universal Plug and Play 通用即插即用)
我們知道P2P（peer to peer 網路中的機器地位是相同的）對等式網路,又稱點對點技術，是無中心伺服器，依靠用戶群交換信息的互聯網體系，作用是減少以往網路傳輸的節點，降低數據丟失的風險。比如常用的電驢，uTorrent，迅雷等，當下載一個大文件的時候，就可以從很多安裝對應軟體的客戶端分塊下載，而不是僅僅從一個伺服器上下載，因此速度會快很多，人越多，速度越快。
原理其實就是區域網內部的主機根據自己的ip（假如編號A）地址，映射到另外的一個ip（假如編號B）上，但這個B地址需要經過路由器同意，這樣的話，區域網內部的主機就可以對外宣稱，你們要是下載我的資源，都去訪問我的B地址啊，它是外網的。當路由器接收到外來的請求B介面的數據，路由器都轉發給區域網內主機對應的B介面，因此數據的發送和接收還是要經過路由器的。。。
這篇文章糅合了多篇文章，但我感覺還算說得通，大家耐心讀讀，相信會對這個流程有個清醒的認識了。。。當然如有說的不到位的，還望大家可以留言，我會及時更正，謝謝大家的時間。。。
