承接上文
TCP網(wǎng)絡(luò )包傳輸的整個(gè)過(guò)程
網(wǎng)絡(luò )基礎二
網(wǎng)絡(luò )基礎一
對于開(kāi)發(fā)者來(lái)講，只使用標準庫進(jìn)行網(wǎng)絡(luò )開(kāi)發(fā)，那是見(jiàn)自己；如果你了解背后的原理再進(jìn)行開(kāi)發(fā)，那是見(jiàn)天地；如果你了解原理并進(jìn)行了創(chuàng )新，比如說(shuō)開(kāi)發(fā)出來(lái)自己的網(wǎng)絡(luò )通信協(xié)議 ，那是見(jiàn)眾生。
http狀態(tài)碼的含義
200-300之間的狀態(tài)碼代表一切正常；
300-400的狀態(tài)碼代表轉向了別的地方，例如301是永久重定向，302是臨時(shí)重定向，304是帶參數重定向（如果參數不滿(mǎn)足，則從緩存中拿已有的結果）；
400-500之間代表你的錯，比如404，表示你輸入錯的網(wǎng)址；
500-600代表是網(wǎng)站的錯，網(wǎng)站服務(wù)器內部出現了問(wèn)題。
耗時(shí)2.5秒表示從點(diǎn)擊回車(chē)鍵開(kāi)始到網(wǎng)站打開(kāi)需要的所有時(shí)間，時(shí)間線(xiàn)以4種顏色區分網(wǎng)站打開(kāi)過(guò)程中的每個(gè)階段，第一個(gè)階段是初始連接階段，
因為發(fā)生在瞬間，導致只能看到三個(gè)顏色的標記；
第二個(gè)紫色表示SSL加密協(xié)議密鑰的階段；
第三個(gè)綠色是服務(wù)器準備內容的階段；
第四個(gè)藍色代表下載內容階段；
從域名開(kāi)始了解具體發(fā)生了什么
域名組成部分中，域名的末尾從斜桿開(kāi)始，代表著(zhù)要訪(fǎng)問(wèn)網(wǎng)站其他地方的路徑；
斜桿代表要訪(fǎng)問(wèn)網(wǎng)站的默認索引頁(yè)，比如網(wǎng)站首頁(yè)；
斜桿?字母、數字等組成的路徑表示網(wǎng)站的其他地方；
域名的主題部分，好比存儲在通信錄中的人名，每個(gè)聯(lián)系人都對應著(zhù)自己的電話(huà)號碼，域名也一樣，它對應的有相應服務(wù)器的ip，這樣任何人訪(fǎng)問(wèn)網(wǎng)站，就可以知道去哪個(gè)服務(wù)器里要我們想看到的東西。
通常驗證是否和服務(wù)器互通使用ping命令
除了服務(wù)器禁ping的情況，ping不超時(shí)就說(shuō)明可以和服務(wù)器相互交互，命令中參數-c 4表示和服務(wù)器交互了4次。
ping域名的后面，出現了ip地址，相當于在地址欄輸入網(wǎng)址按下回車(chē)，第一件事就是去找域名對應的服務(wù)器地址，這個(gè)ip地址是從DNS服務(wù)器里存儲的地址本里找出來(lái)的，如果你訪(fǎng)問(wèn)過(guò)該網(wǎng)站，就從本機緩存的數據里找，如果找不到就從路由器設置的電信服務(wù)商提供的DNS服務(wù)器中找，
如果還找不到，就從網(wǎng)站域名服務(wù)商提供的DNS服務(wù)器中找，所以DNS域名服務(wù)器存儲的地址本是分布式的，可以用nslookup命令驗證下。
如何從DNS查詢(xún)域名對應的ip
使用nslookup得到應答，可以看到給b站域名響應了4、5個(gè)地址，大概率是因為b站的流量巨大，使用了CDN做了資源加速，讓你從最近的服務(wù)器中提取資源。
將DNS服務(wù)器的設置為8.8.8.8
b站的響應結果是一樣的，那起初DNS的域名是誰(shuí)操作綁定在一起的，當然是b站所屬的公司，注冊了bilibili的域名，指定好域名的DNS，做好A記錄解析來(lái)對應好服務(wù)器的ip地址，這樣就可以通過(guò)域名訪(fǎng)問(wèn)b站了。
查看域名的注冊信息
whoisbilibili
這是域名的注冊信息，可以反映出域名注冊的過(guò)期日期、服務(wù)商是阿里云DNS服務(wù)器。
域名前的https是超文本傳輸協(xié)議，https代表超文本內容是加密傳輸的以保證傳輸的安全。
服務(wù)器和客戶(hù)端的加密協(xié)議的協(xié)商就對應網(wǎng)絡(luò )時(shí)間軸的紫色部分，
地址欄的小鎖圖標代表信任的安全認證的加密證書(shū)，
證書(shū)的使用人、頒發(fā)人和證書(shū)的有效期以及指紋信息、傳輸內容的加密是非對稱(chēng)加密、服務(wù)器持有密鑰、客戶(hù)端持有公鑰、在證書(shū)的詳細信息標簽中可以看到更詳細的證書(shū)信息，例如證書(shū)的簽名算法和公鑰的路徑信息等。
http2協(xié)議必須使用加密證書(shū)，它保證一個(gè)客戶(hù)端與服務(wù)器保持一個(gè)連接，比http1.1更高效。
https加密傳輸每次都是要有協(xié)商時(shí)間的，說(shuō)明它比http非加密的方式訪(fǎng)問(wèn)網(wǎng)站要慢。
如果瀏覽器的要求必須使用加密的方式傳輸，如果證書(shū)過(guò)期或者沒(méi)有使用證書(shū)，會(huì )將小鎖換成不安全警告。
模擬不加密訪(fǎng)問(wèn)
使用的是http1.1非加密協(xié)議，請求的是80端口，返回301的狀態(tài)碼，表示b站將域名永久重定向到帶www的域名上。
模擬https協(xié)議的域名
訪(fǎng)問(wèn)的是443端口，
這里出現了協(xié)商密鑰交互的握手部分，協(xié)商成功之后將使用TLS證書(shū)進(jìn)行加密鏈接，使用http2的協(xié)議進(jìn)行傳輸；
這里特別說(shuō)明下http2協(xié)議是http1.1協(xié)議的升級版，http2協(xié)議必須使用加密證書(shū)，它保證一個(gè)客戶(hù)端與服務(wù)器只保持一個(gè)連接，比http1.1更高效。
互聯(lián)網(wǎng)之所以互聯(lián)，是因為它們都是基于TCP/IP協(xié)議族進(jìn)行傳輸，客戶(hù)端與服務(wù)器的每一次交互都要通過(guò)2*7=14到關(guān)卡。
OSI七層模型
TCP/IP的OSI 7層模型，雖然它不能代表現實(shí)中實(shí)際的網(wǎng)絡(luò )模型但足具代表性。
按照客戶(hù)端數據流向的方向，從7層模型的最高層講起：
第7層應用層是由應用程序負責的協(xié)議層，比如HTTP/SMTP/POP協(xié)議等；
第6層表示層是負責數據的加解密，數據的轉換和壓縮，例如http協(xié)議數據傳輸中的gzip數據壓縮，縮小數據大小以節約網(wǎng)絡(luò )傳輸數據的流量；
第5層會(huì )話(huà)層，例如開(kāi)發(fā)者工具窗口中時(shí)間線(xiàn)的紫色部分負責的就是數據加密協(xié)議的協(xié)商工作，就是在這一層完成的；
第5、6、7層可以統稱(chēng)為應用程序層，在數據向下傳輸的階段，在數據段前加入http標頭，表示請求的方法是get還是post請求；
第4層就是經(jīng)典的傳輸層，負責數據是按照TCP的方式還是按照UDP的方式傳輸，比如HTTP是按照TCP方式傳輸的。
這一層會(huì )為數據追加20個(gè)字節的TCP標頭，例如源端口、目標端口、請求序列號。
第三層網(wǎng)絡(luò )層，負責數據路由的選擇和數據分組的傳輸，典型的IP和IPv6協(xié)議就在這一層，這一層會(huì )為數據段追加來(lái)源IP和目標IP地址，
路由選擇，當你輸入網(wǎng)址按下回車(chē)，找到IP后進(jìn)入網(wǎng)絡(luò )層，路由選擇是按照你訪(fǎng)問(wèn)的目標服務(wù)器的物理距離來(lái)決定第二層數據先到哪里，比如你做的是TCP火車(chē)還是UDP飛機，從上海到北京你都必須經(jīng)過(guò)江蘇安徽河北才能到達是一樣的。
模擬路由的選擇
下一跳次數越多，說(shuō)明經(jīng)停站越多，達到目的地的時(shí)間就越長(cháng)。
這就是為什么使用nslookup查找b站域名ip的時(shí)候，會(huì )有多個(gè)ip，是因為b站為了讓用戶(hù)更快的訪(fǎng)問(wèn)網(wǎng)站使用了CDN技術(shù)，選擇離你最近的服務(wù)器中快速的打開(kāi)b站。
第二層數據鏈路層，這一層確保物理層傳輸的數據幀按需傳輸，并在這一層加入了來(lái)源MAC地址和目標MAC地址標頭即網(wǎng)卡，每個(gè)網(wǎng)卡都有自己全球唯一的MAC地址確保傳輸的數據找不錯設備，這里的MAC地址不一定是起初訪(fǎng)問(wèn)的設備MAC地址和真正的目的地的服務(wù)器的MAC地址，這是由第三層路由選擇的下一跳地址決定的。
第一層就是物理層，例如網(wǎng)線(xiàn)、Wi-Fi等方式將你的二進(jìn)制比特流的數據送出去。
當輸入網(wǎng)址按下回車(chē)每一次從客戶(hù)端發(fā)送出的請求數據，都會(huì )從第7層逐漸處理，加入不同的標頭，然后達到目標地址，到達目標地址再反向，從第1層逐層去掉標頭，直到網(wǎng)絡(luò )的第7層，最終服務(wù)器拿到干凈的請求數據。
知道了數據是怎么流向的，客戶(hù)端和服務(wù)器還要確保數據鏈路的通暢，它倆必須要建立可靠的鏈接通道。
三次握手
開(kāi)發(fā)者工具窗口中網(wǎng)絡(luò )時(shí)間軸中瞬間發(fā)生的第一個(gè)階段：初始鏈接階段，第一次握手是客戶(hù)端帶上序列號x，給服務(wù)器打招呼：b站美女你好靚，可以認識下不？
客戶(hù)端進(jìn)入SYN-SEND的同步發(fā)送狀態(tài)；
第二次握手服務(wù)器監聽(tīng)相關(guān)的端口，開(kāi)通http協(xié)議請求端口，類(lèi)似80和443端口，服務(wù)器監聽(tīng)端口收到了消息之后，帶上自己的序列號y并帶上ack確認碼（客戶(hù)端帶來(lái)了序列號+1），然后回復：hi，你也好帥哦。
服務(wù)器進(jìn)入SYN_RCVD狀態(tài)。
第三次握手，客戶(hù)端收到服務(wù)器的回復，帶上服務(wù)器回復的序列號+1的確認碼發(fā)送給服務(wù)器建立連接成功，就可以愉快的傳遞數據了。
四次分手
當客戶(hù)端打算關(guān)上連接，會(huì )主動(dòng)帶上握手時(shí)客戶(hù)端確認碼作為序列號發(fā)送給服務(wù)器斷開(kāi)連接，客戶(hù)端進(jìn)入FIN-WAIT-1狀態(tài)，發(fā)生了一次揮手，服務(wù)器收到了分手的消息，會(huì )帶上自己的序列號v即客戶(hù)端帶來(lái)的序列號+1作為確認碼回復給客戶(hù)端。
服務(wù)端：分手消息我收到了，我想想，服務(wù)端進(jìn)入CLOSE_WAIT等待關(guān)閉的狀態(tài)，客戶(hù)端進(jìn)入繼續等待FIN-WAIT-2的狀態(tài)；然后發(fā)生第二次揮手，服務(wù)器想了想沒(méi)有更多的話(huà)要給客戶(hù)端說(shuō)的，于是帶上了序列號w和序列號+1的確認碼給客戶(hù)端發(fā)送了分手請求：分手就分手沒(méi)有什么好說(shuō)的了，然后服務(wù)器進(jìn)入LAST-ACK最后確認狀態(tài)；發(fā)生了第三次揮手，客戶(hù)端收到了服務(wù)器的分手請求之后，帶上+1的序列號和+1的確認碼回復給服務(wù)器，于是服務(wù)器關(guān)閉了連接，客戶(hù)端進(jìn)入了定時(shí)等待時(shí)間，這兩個(gè)報文的最大生存周期，不同的操作系統不一樣，大約是1-4分鐘即俗稱(chēng)的冷靜期，冷靜期后客戶(hù)端才真正的斷開(kāi)。
小結
瀏覽器輸入域名網(wǎng)址首先通過(guò)DNS找域名對應的ip地址，然后是三次握手進(jìn)入初始鏈接階段，每次鏈接都要經(jīng)過(guò)TCP/IP七層模型， 鏈接初始成功后進(jìn)入第二階段SSL的加密協(xié)議的證書(shū)協(xié)商階段，接下來(lái)是服務(wù)器準備我們需要的內容，準備好內容之后就是客戶(hù)端下載內容的階段。