看懂「www.google.com」背後的邏輯

在前兩篇文章中，咱們完整的描述了計算機網絡 OSI 五層模型的相關內容。那麼，本篇將會從一個實踐案例開始，帶你從總體上從新認識咱們的計算機網絡。

咱們以訪問 Google 爲例，當咱們在瀏覽器地址欄中敲下回車鍵以後，整個計算機網絡將會發生什麼呢？

本機的網絡相關參數以下：

首先咱們應用層的瀏覽器決定向 DNS 服務器請求解析域名「www.google.com」，那麼就要遵循 DNS 協議。

DNS 運行在 53 號端口，因而瀏覽器會建立一個 UDP 套接字，標識該套接字的二元組分別是『目的 IP 地址』和『目的端口』。而套接字本質上就是爲了惟一標識應用層進程，就是爲了讓響應報文可以找到目的地。

那麼這裏會建立一個 UDP 套接字，二元組爲「本機 IP 地址 192.168.43.138」和「隨機產生一個未使用的端口號」。

接着，瀏覽器將 DNS 請求報文封裝好推入套接字，開始咱們的 DNS 解析過程。

有關 DNS 的相關細節，這裏再也不贅述了，能夠參考前面的文章，拿到 DNS 服務器的響應報文，運輸層拆開數據報，獲得該報文的目的 IP 地址和目的端口號，因而對應着去找套接字交付報文便可。

最終咱們會從『本地 DNS 服務器』獲得 Google 的 IP 地址爲：172.194.72.105。

整個 HTTP 請求能夠說纔剛剛開始：

應用層

瀏覽器封裝 HTTP 請求報文，而後建立一個 TCP 套接字，採用四元組標識，具體爲「源 IP 地址：192.168.43.138」+「源端口號：隨機的，這裏假設爲 1234」+「目的 IP 地址：172.194.72.105」+「目的端口號：80」。

HTTP 報文也就是咱們的應用層數據報，大體是這樣的：

指定了一些請求參數與動做，以及一些要求響應報文的返回格式要求，具體的咱們不細說了。

緊接着，這個報文會被推動 TCP 套接字中，等待運輸層來收取。

運輸層

運輸層收取了報文，並判斷與目的主機是否創建了 TCP 鏈接，這裏假設沒有。

那麼，運輸層將不急着發送應用層數據，得先判斷與目的主機之間可以正常通信，也就是須要『握手』打招呼。

『三次握手』的相關細節，咱們這裏也再也不贅述了，上篇文章描述的很詳細了，經過『三次握手』，發送端和接收端確認過發送與確認序號，分配了相應的緩存資源等。

一切準備就緒以後，運輸層將應用層發過來的數據報又一層封裝，添加進『源端口號』和『目的端口號』以及相關差錯檢驗字段。

最後將 TCP 數據報向下傳遞到網絡層。

網絡層

網絡層其實很簡單，拿到數據報並封裝成 IP 數據報，即在原 TCP 報文的前提之上添加『源 IP 地址』和『目的 IP 地址』等字段信息。

而後交由數據鏈路層。

鏈路層

數據鏈路層拿到 IP 數據報，它須要封裝成以太網幀才能在網絡中傳輸，也就是它須要目的主機的 Mac 地址，然而咱們只知道目的主機的 IP 地址。

因此，鏈路層有一個 ARP 協議，直接或間接的可以根據目的 IP 地址得到使用該 IP 地址的主機 Mac 地址。

固然，ARP 協議運行的前提是，目的 IP 地址和當前發送方主機處於同一子網絡中。若是否則，發送方將目的 Mac 地址填本身網關路由的 Mac 地址，而後經過物理層發送出去。

網關路由因爲具備轉發表和路由選擇算法，因此它知道目的網絡該怎麼到達，因此一路轉發，最終會發送到目的網絡的網關路由上。

最後，目的網絡的網關路由一樣會經由 ARP 協議，取得目的主機的 Mac 地址，而後廣播發送，最後被目的主機接受。

這樣谷歌的服務器就接受到一個 HTTP 請求，因而它解析這個請求，肯定該請求的動做是什麼，也就是它須要什麼東西，並構建響應報文，以一樣的方式從網絡到達源主機。

最後你將看到你想要的谷歌搜索頁面：

總體上咱們自頂而下的描述了一個請求到達目的地的完整過程，旨在宏觀上創建完整的框架體系，相關細節之處能夠參照前兩篇文章。

---

文章中的全部代碼、圖片、文件都雲存儲在個人 GitHub 上：

(https://github.com/SingleYam/overview_java)

歡迎關注微信公衆號：撲在代碼上的高爾基，全部文章都將同步在公衆號上。