趣談網路協議-筆記（1）

3 人贊了文章

寫在前面

2018年6月20日拿到畢業證，正式結束了自己的學生生涯。

2018年7月2日，自己正式開始了人生中的第一份正式工作，人人車的Android開發工程師。

2018年7月13日，決定要好好督促自己學一學習，所以就打算再一次剛起公眾號之路。逼迫自己有計劃的去學習，有計劃的去輸出。因為最近碰巧趕上了需求大爆發時期，所以這段時間的學習計劃，以不需要大量時間投入的計算機基礎知識為主，重在修鍊自己的內功。前段時間買了一個計算機網路的課程，所以近期打算記錄一下這方面的知識。

筆記正文

這裡是一個關於計算機網路的系列文章，主要是自己對一個收費課程的學習記錄。這裡就不放課程鏈接了，如果對課程感興趣的話，可以後台私聊我。

以下內容和圖片由我整理自《極客時間》付費內容，如有侵權，告知即刪。

HTTP協議相關

當我們在瀏覽器裡面輸入https://www.kaola.com時，毫無疑問這是一個URL。不過瀏覽器只知道這個鏈接的名字是https://www.kaola.com ，但此外不知道任何其他有用的信息，所以接下來的第一步，瀏覽器打開地址簿去查找這個鏈接背後的IP地址。一般可以使用的地址薄協議是DNS，還可以使用另一種更加精準的地址簿查找協議HTTPDNS 。

無論用哪一種方法查找，最終都會得到這個地址：106.114.138.24 。這個是網易考拉的伺服器IP地址，是互聯網世界的「門牌號」。知道了目標地址，瀏覽器就開始打包它的請求。現在我們普遍會使用HTTPS協議。當然無論是什麼協議，裡面都會寫明這次請求所需要攜帶的信息，比如作為一名剁手黨，你所要攜帶的信息是「要買什麼和買多少」。

TCP協議相關

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

TCP協議裡面會有兩個埠，一個是瀏覽器監聽的埠，一個是電商的伺服器所監聽的埠。操作系統往往通過埠來判斷，它得到的包應該給哪個進程。

獲取IP地址

傳輸層封裝完畢後，瀏覽器會將包交給操作系統的網路層。網路層的協議是IP協議。在IP協議裡面會有源IP地址，即瀏覽器所在機器的IP地址和目標IP地址，也即電商網站所在伺服器的IP地址。（也就是我們上文通過DNS協議獲取到的IP地址）

獲取MAC地址

操作系統既然知道了目標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 的包，，會像來的時候一樣，經過千難萬險到達你的個人電腦，最終進入瀏覽器，顯示支付成功。

筆記小結

為什麼有了IP，還要有mac地址？

• 1.區域網內IP地址是動態分配的，假如我是192.168.2.100，如果我下線了，可能IP就分配給了另一台電腦。IP和設備並不總是對應的，這對通信就產生了問題，但是MAC地址不同，MAC地址和設備是一一對應且全球唯一的。所以區域網使用MAC地址通信沒有問題。
• 2.歷史遺留問題：早期的乙太網只有交換機，沒有路由器，乙太網內通過MAC地址通信。後來才有了互聯網，為了兼容原本的模式，採用了IP+MAC地址通信的方式。為啥不推到了重來呢？看看IPv6的處境你就知道了。所以是先有MAC地址後有的IP，IP的提出主要還是因為MAC地址本身的缺陷，這個問題換成有了MAC為何還要IP地址也很有意思。
• 3.MAC地址本身的缺陷：因為MAC地址是硬體提供商寫在網卡中的，MAC地址雖然唯一但是不能表明用戶在整個互聯網中的位置，除非維護一個超級大MAC地址對應表，那定址效率肯定爆炸。但是IP地址解決了這個問題，因為IP地址是網路提供商給你的，所以你在哪裡整個網路都是知道的。

網卡MAC碼是由全球惟一的一個固定組織來分配的，未經認證和授權的廠家無權生產網卡。每塊網卡都有一個固定的卡號，並且任何正規廠家生產的網卡上都直接標明了卡號，一般為一組12位的16進位數。其中前6位代表網卡的生產廠商。後面的位數是設備號。

尾聲

這是這些天我對《計算機網路》學習的一次筆記。大部分內容是基於前輩們總結，我又記錄了一遍。算是對自己學習結果的一次確認吧，希望可以對各位看官有些幫助。

本菜開源的一個自己寫的Demo，這個項目拆解並組合了很多業務。目的在於遇到類似業務，可以快速的ctrl+c/v。希望能給Androider們有所幫助，水平有限，見諒見諒…

[zhiaixinyang/PersonalCollect](zhiaixinyang/PersonalCollect)

2018年7月2號，我正式開始了自己的Android工作，為了能夠讓自己能夠好好完成工作，並且能夠快速得到技術提升。所以打算以公眾號的方式去敦促自己學習，我會把自己日常的學習筆記發布到公眾號上，如果可以，共同進步！~

http://weixin.qq.com/r/Kjnm-tPEqo7VrZed92w4 (二維碼自動識別)

推薦閱讀：