網絡協議小故事（簡述）

小故事

瀏覽器裏面輸入 https://www.kaola.com ，這是一個 URL。瀏覽器只知道名字是「www.kaola.com」，可是不知道具體的地點，因此不知道應該如何訪問。因而，它打開地址簿去查找。可使用通常的地址簿協議 DNS 去查找，還可使用另外一種更加精準的地址簿查找協議 HTTPDNS。

不管用哪種方法查找，最終都會獲得這個地址：106.114.138.24。這個是 IP 地址，是互聯網世界的「門牌號」。

知道了目標地址，瀏覽器就開始打包它的請求。對於普通的瀏覽請求，每每會使用 HTTP 協議；可是對於購物的請求，每每須要進行加密傳輸，於是會使用 HTTPS 協議。不管是什麼協議，裏面都會寫明「你要買什麼和買多少」。

 

 

 

DNS、HTTP、HTTPS 所在的層咱們稱爲應用層。通過應用層封裝後，瀏覽器會將應用層的包交給下一層去完成，經過 socket 編程來實現。下一層是傳輸層。傳輸層有兩種協議，一種是無鏈接的協議 UDP，一種是面向鏈接的協議 TCP。對於支付來說，每每使用 TCP 協議。所謂的面向鏈接就是，TCP 會保證這個包可以到達目的地。若是不能到達，就會從新發送，直至到達。

TCP 協議裏面會有兩個端口，一個是瀏覽器監聽的端口，一個是電商的服務器監聽的端口。操做系統每每經過端口來判斷，它獲得的包應該給哪一個進程。

 

 

 

傳輸層封裝完畢後，瀏覽器會將包交給操做系統的網絡層。網絡層的協議是 IP 協議。在 IP 協議裏面會有源 IP 地址，即瀏覽器所在機器的 IP 地址和目標 IP 地址，也即電商網站所在服務器的 IP 地址。

 

 

 

操做系統既然知道了目標 IP 地址，就開始想如何根據這個門牌號找到目標機器。操做系統每每會判斷，這個目標 IP 地址是本地人，仍是外地人。若是是本地人，從門牌號就能看出來，可是顯然電商網站不在本地，而在遙遠的地方。

操做系統知道要離開本地去遠方。雖然不知道遠方在何處，可是能夠這樣類比一下：若是去國外要去海關，去外地就要去網關。而操做系統啓動的時候，就會被 DHCP 協議配置 IP 地址，以及默認的網關的 IP 地址 192.168.1.1。

操做系統如何將 IP 地址發給網關呢？在本地通訊基本靠吼，因而操做系統大吼一聲，誰是 192.168.1.1 啊？網關會回答它，我就是，個人本地地址在村東頭。這個本地地址就是 MAC 地址，而大吼的那一聲是ARP 協議。

 

 因而操做系統將 IP 包交給了下一層，也就是 MAC 層。網卡再將包發出去。因爲這個包裏面是有 MAC 地址的，於是它可以到達網關。

網關收到包以後，會根據本身的知識，判斷下一步應該怎麼走。網關每每是一個路由器，到某個 IP 地址應該怎麼走，這個叫做路由表。

路由器有點像玄奘西行路過的一個個國家的一個個城關。每一個城關都連着兩個國家，每一個國家至關於一個局域網，在每一個國家內部，均可以使用本地的地址 MAC 進行通訊。

一旦跨越城關，就須要拿出 IP 頭來，裏面寫着貧僧來自東土大唐（就是源 IP 地址），欲往西天拜佛求經（指的是目標 IP 地址）。路過寶地，借宿一晚，明日啓程，請問接下來該怎麼走啊？

 

 城關每每是知道這些「知識」的，由於城關和臨近的城關也會常常溝通。到哪裏應該怎麼走，這種溝通的協議稱爲路由協議，經常使用的有 OSPF 和 BGP。

 

 城關與城關之間是一個國家，當網絡包知道了下一步去哪一個城關，仍是要使用國家內部的 MAC 地址，經過下一個城關的 MAC 地址，找到下一個城關，而後再問下一步的路怎麼走，一直到走出最後一個城關。

最後一個城關知道這個網絡包要去的地方。因而，對着這個國家吼一聲，誰是目標 IP 啊？目標服務器就會回覆一個 MAC 地址。網絡包過關後，經過這個 MAC 地址就能找到目標服務器。

目標服務器發現 MAC 地址對上了，取下 MAC 頭來，發送給操做系統的網絡層。發現 IP 也對上了，就取下 IP 頭。IP 頭裏會寫上一層封裝的是 TCP 協議，而後將其交給傳輸層，即 TCP 層。

在這一層裏，對於收到的每一個包，都會有一個回覆的包說明收到了。這個回覆的包絕非此次下單請求的結果，例如購物是否成功，扣了多少錢等，而僅僅是 TCP 層的一個說明，即收到以後的回覆。固然這個回覆，會沿着剛纔來的方向走回去，報個平安。

由於一旦出了國門，西行路上千難萬險，若是在這個過程當中，網絡包走丟了，例如進了大沙漠，或者被強盜搶劫殺害怎麼辦呢？於是到了要報個平安。

若是過一段時間仍是沒到，發送端的 TCP 層會從新發送這個包，仍是上面的過程，直到有一天收到平安到達的回覆。這個重試絕非你的瀏覽器從新將下單這個動做從新請求一次。對於瀏覽器來說，就發送了一次下單請求，TCP 層不斷本身悶頭重試。除非 TCP 這一層出了問題，例如鏈接斷了，才輪到瀏覽器的應用層從新發送下單請求。

當網絡包平安到達 TCP 層以後，TCP 頭中有目標端口號，經過這個端口號，能夠找到電商網站的進程正在監聽這個端口號，假設一個 Tomcat，將這個包發給電商網站

 

 電商網站的進程獲得 HTTP 請求的內容，知道了要買東西，買多少。每每一個電商網站最初接待請求的這個 Tomcat 只是個接待員，負責統籌處理這個請求，而不是全部的事情都本身作。例如，這個接待員要告訴專門管理訂單的進程，登記要買某個商品，買多少，要告訴管理庫存的進程，庫存要減小多少，要告訴支付的進程，應該付多少錢，等等。

如何告訴相關的進程呢？每每經過 RPC 調用，即遠程過程調用的方式來實現。遠程過程調用就是當告訴管理訂單進程的時候，接待員不用關心中間的網絡互連問題，會由 RPC 框架統一處理。RPC 框架有不少種，有基於 HTTP 協議放在 HTTP 的報文裏面的，有直接封裝在 TCP 報文裏面的。

當接待員發現相應的部門都處理完畢，就回復一個 HTTPS 的包，告知下單成功。這個 HTTPS 的包，會像來的時候同樣，通過千難萬險到達你的我的電腦，最終進入瀏覽器，顯示支付成功。