寫在前面
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們有所幫助，水平有限，見諒見諒…
https://github.com/zhiaixinyang/PersonalCollect
這是一個主推面試踩坑的公眾號！
因為身邊的同學從事互聯網相關職業的比較多，并且大家閑時聊天時總會吐槽找工作有很多坑，所以打算把身邊同學找工作的經驗，統統收集起來。提供給想從事這方面同學，希望圈內好友可以共同進步，共同少踩坑。
