小故事
瀏覽器里面輸入 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 的包，會像來的時候一樣，經過千難萬險到達你的個人電腦，最終進入瀏覽器，顯示支付成功，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/60975.html
標籤：其他
上一篇：IDEA2020.1使用LeetCode插件運行并除錯本地樣例
下一篇：ifconfig講解（ip地址）