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