寫在前面
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位代表網路卡的生產廠商。後面的位數是裝置號。
尾聲
這是這些天我對《計算機網路》學習的一次筆記。大部分內容是基於前輩們總結，我又記錄了一遍。算是對自己學習結果的一次確認吧，希望可以對各位看官有些幫助。
我是一名Android開發，和一幫網際網路各行各業的童靴一同維護了一個公眾號：IT面試填坑小分隊。裡邊的內容以我們在面試過程中踩過的坑為主。