讀薄《圖解HTTP》第一回：網路基礎
有一定網路知識的同學都知道，網路通訊模型分為四層（但學校課本一般以七層講解，為細分的情形），四層自上而下分別是應用層、傳輸層、網路層、資料鏈路層。
雖然《圖解HTTP》一書主要講的是應用層協議即HTTP協議相關的內容。但是在該書第一章，作者稍微鋪墊了一些Web發展的歷史，而後著重地將下層協議的內容、分層的意義、上下層的關係進行了系統的概述。頭腦中有大致的分層概念有助於我們更好地理解HTTP協議。
四層模型
從圖中可以直觀看出，客戶端在傳送資料的時候，除了我們需要傳遞的資訊本身之外，還需經重重打包、新增一些輔助傳遞的內容。這個過程就像我們上課傳小紙條時，需要將之摺疊起來，並註明傳給誰一樣。
在網際網路的“蠻荒”時代，各種各樣的協議層出不窮，人們大都為了解決某一特定需求而定製一套通訊協議。沒有一個大家都接受的方案使得人們各自為政，難通有無，極大地阻礙了網際網路的發展。
後來，人們根據大致的應用場景分類，抽象出通訊四層模型。四層之間的資料傳遞的介面是固定的。也就是說，相鄰的任意兩層之間的資料傳輸並不需要關心對方內部具體採用什麼協議來實現，而只是關心自己給出的資料能不能對接得上介面，也就是兩層之間資料傳輸的格式。
這樣有一個十分明顯的好處就是人們設計協議的時候不再是蒙著頭幹自己的，而是面向介面來做設計，只要自己設計的協議能滿足層級間的格式要求，那麼就能做到協議滿足自己需求的情形下還能保證協議的通用性，分層的概念提出後，網際網路發展迎來了一個飛速發展期。
人們也在網際網路生產中有了以下的經典實踐：
應用層
應用層決定了向用戶提供應用服務時通訊的活動。
對於訪問網頁這種資料傳輸量小、內容少、但是併發量又要求大的應用場景，我們就有了HTTP（Hyper Text Transfer Protocol，超文字傳輸協議）協議（1.0）。該協議被設計成通訊雙方不保持連線且不儲存雙方資訊的形式，使得網站伺服器能夠為儘可能多的客戶端服務。此處特指了HTTP1.0協議是因為它雖然適應“古代”網站內容形式多為文字，圖片都較少的情形，但是顯然不適用於如今內容豐富的網際網路情形了，此為後話。
傳輸檔案，我們有FTP（檔案傳輸協議，File Transfer Protocol）協議，不過這個協議提供的種種功能都能被HTTP協議所替換，因此，FTP協議被用在公司內部搭建檔案伺服器的場景很多，其餘的應用場景倒是越來越少了。
傳輸層
傳輸層主要處理兩臺主機間的資料傳輸方式，是傳一個數據包裹吆喝一聲，還是隻負責傳出包裹，而不去管包裹是否到達由其中該層的協議自己定義。打遊戲、聽音樂，對資料完整性要求極高。注意這裡的完整是由於資料在實際傳輸過程中是切分後編好順序分次傳輸的，這樣做的實際意義是提高傳輸效率與最小代價地重傳（本書原文是“更好地傳輸”），但它是怎麼做到的此處限於篇幅不再展開，此處只需要明白一個較大資料是拆分傳輸的。
那麼這就要求一個協議來做資料完整性控制，它就是TCP（傳輸控制協議，Transmission Control Protocol）協議。它建立連線需要三次握手，斷開連線需要四次揮手，到達一個數據包裹要求到達確認（吆喝一聲）、包裹丟失又會要求重傳、為了適應網路的不穩定情形又要有擁塞控制、同時伺服器又需要維護連線 ...，這些都耗費珍貴的CPU資源。
不僅如此，“後發先至”（由下層IP協議的分組轉發與路由導致的）這種暫時無法處理的資料以及資料量輸送過多而無法及時處理的資料不得不先快取而這又得耗費記憶體資源。但正因為TCP如此嚴格的設計，TCP對資料完整性方面的保證是極為優秀的，尤其是在網路情況較為糟糕的情況下TCP協議就更能發揮它的作用。
而視訊通話、視訊直播，對即時性要求極高，不要求資料完整性的，我們又有UDP（User Datagram Protocol，使用者資料報協議）協議提升效能，這就對應只負責傳出包裹而不理會是否到達。
它乾脆就拋棄TCP協議採用的較為複雜的擁塞控制、快取設計，拋棄TCP協議中強調的對資料是否完整到達的嚴格校驗。它不對資料完整性做保證，這就使得為了傳輸資料而額外發送的資料包裹大大減少、也就不需要向TCP協議那樣呼叫太多CPU資源與記憶體資源，甚至還節約了時間，達到提高效能的目的。
而且對於這個協議，大家在進行視訊通話的時候可以直觀的感受：假如某個時刻網路狀態不好畫面卡住了，在過了三四秒後網路狀態轉好時，一般應用處理的方式都是直接跳過這中間三四秒傳送過來的內容（不論殘缺與否）不予顯示，直接顯示對方當前這一刻傳送過來的畫面。
值得一提的是，隨著現如今寬頻硬體水平的不斷提升，網路丟包情況越來越少見，TCP協議做的資料完整性校驗由於太過複雜而被越來越多的人質疑是否是進一步提升效率的阻礙。
網路層
此層主要做的工作是在龐大的網路中，找到源主機與目標主機的傳送資料的線路。由於IP（Internet Protocol，網際網路協議）協議出色的定址、路由的能力，在網際網路高度發展的今天，在這一層反而出現了一統河山的情形，更何況IP協議的全名就叫“Internet protocol（網際網路協議）”。
資料鏈路層
對於資料鏈路層，基於現在廣泛使用的組網方式，則是乙太網、令牌環網等區域網為主要情形，其中乙太網甚至成了區域網的代名詞，除此之外，所有與底層硬體相關的包括網絡卡、光纖等都屬於資料鏈路層的範疇。
到這裡為止，四層的大致內容就介紹完畢，由於水平實在有限，本文肯定是做不到原文那麼言簡意賅的，但是，我也在試圖用一些通俗的例子講明白一些概念。希望能使你得到一些好的啟發，如果能幫助你在腦海中搭建出一個數據流轉的大致形態那就再好不過了。
除了上述的分層網路，還有一些與這個分層網路密切相關的概念，就比如TCP協議是怎麼來適應網路狀態的，又是怎麼來控制擁塞的，拆分傳輸的資料包裹傳丟了接收方是怎麼判定要求重傳的，重傳後之前判定丟失的包裹也到達了怎麼辦，由於IP路由選路不同導致的“後發先至”的情形又該如何是好 ... 諸如此類，實在是拉住了一條知識點的藤蔓能把整個一串地瓜給牽出來，這些都需要你帶著疑問一一去書中找答案了。
書中沒有費太多的筆墨在這些與HTTP協議不太相關的部分（畢竟此書是講HTTP的嘛），而是著重介紹了ARP協議是怎麼完成IP地址到MAC地址的對映的（我的另一篇文章有介紹喲）、IP協議是怎麼選路的、TCP協議的三次握手與DNS域名解析服務。
除DNS以外，其他三個不在應用層，本文也不展開講。此處僅稍微一提DNS域名服務。
DNS（Domain Name System），域名系統，它負責完成IP地址與字元的對映，類似於39.106.56.xx 對映為 ofollow,noindex">www.abc.com ，這麼做是為了人類記憶的便捷。畢竟記住後面有規律的網址比記住簽名的IP容易得多了。但是計算機恰恰相反，計算機它理解前面的IP地址反而更簡單，所以每當我們人類使用網址訪問目標網站的時候，都會先一步地查詢域名解析伺服器，得到該網址的IP地址，而後的通訊實際上是基於這個IP地址來的。
需要說明的是，實際上的域名解析比上述更為複雜，它有一個優先順序，首先計算機會查本地硬碟的HOSTS資料夾，本地硬碟查不到才會將查詢請求提交本地區域名伺服器否則返回，本地區在它的伺服器中找，找得到返回，找不到就將請求轉發到更高階的伺服器中，返回最終結果。
該書第一章最後一節講了URI與URL的內容
URI（Uniform Resource Identifier）統一資源識別符號，它用來標識網際網路上的所有資源，包括文件、音視訊、文字等單一或多個的集合。
URI結構
URL（Uniform Resource Locator）統一資源定位符，它僅僅用於記錄網路資源的位置。
URI是用來標記資源的，URL是用來找到資源的，URL是URI的子集，他們二者十分相像，但我們不必過分糾結於二者的區別，理解他們的作用與應用場景即可。
本文到這裡就結束了，如果想了解其他的內容，可以檢視我的其他文件，感謝閱讀。