【計網】圖解HTTP常見知識點總結

時間 2021-01-15

標籤 html web 面試瀏覽器緩存安全服務器網絡 tcp 工具欄目 HTTP/TCP 简体版

原文原文鏈接

初識TCP/IP

瞭解HTTP以前咱們得了解一下TCP/IP協議族。咱們一般所說得TCP/IP協議族是互聯網相關的各種協議族的總稱，而HTTP屬於它內部的一個子集。還有一種說法認爲TCP/IP是指TCP和IP這兩種協議。html

TCP/IP協議族裏重要的一點就是分層。從上到下依次分爲如下4層：應用層、傳輸層、網絡層和數據鏈路層。web

TCP/IP協議族4層模型

應用層面試

應用層的任務是經過應用進程間的交互來完成特定的網絡應用。TPC/IP協議族內預存了各種通用的應用服務。好比，FTP（文本傳輸協議）和DNS（域名系統）。HTTP協議也位於該層。瀏覽器

傳輸層緩存

傳輸層主要爲兩臺計算機進程以前的通訊提供數據傳輸服務，也就是傳輸應用層的報文。該層的協議有：TCP協議和UDP協議。安全

網絡層服務器

網絡層用來處理網絡上流動的數據包。數據包是網絡傳輸的最小數據單。該層規定經過怎樣的路徑到達對方的計算機，並把數據包傳送給對方。在計算機網絡中進行通訊，之間可能會通過不少網絡設備或者計算機，網絡層就是要選擇合適的傳輸路線。網絡層會把上一層的報文封裝成數據包。該層使用的是IP協議。網絡

鏈路層tcp

用來處理鏈接網絡的硬件部分。包括操做系統、硬件設備的驅動、網卡和光纖等物理設備。硬件上的範疇均在鏈路層的做用範圍以內。工具

發送端在層與層之間傳輸數據時，沒通過一層必需要加上該層的首部信息。反之，接收端在層與層傳輸時必須把首部去掉。這種把數據信息包裝起來的作法叫作封裝。

下面會講一講和HTTP密不可分的三個協議：IP、TCP、DNS

負責傳輸的IP協議

IP協議的做用就是把各種數據包傳送給對方。爲了確保傳送的準確，則須要知足各種條件。其中兩個重要的條件就是IP地址和MAC地址。IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址是可變換的，而MAC地址基本上不會改變。

網絡通訊的雙方在同一局域網的狀況不多，一般須要多臺網絡設備的中轉才能鏈接到對方。在中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時，會採用ARP協議，ARP是一種解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。在這個中轉的過程當中，那些計算機、路由器等網絡設備只能獲悉很粗略的傳輸路線，這種機制稱爲路由選擇。

確保可靠性的TCP協議

TCP位於傳輸層，提供可靠的字節流服務。所謂字節流服務，就是爲了方便傳輸，TCP會將大數據分割成以報文段爲單位的數據包進行管理。而可靠性涉及到的東西就不少了，好比三次握手、超時重傳、流量控制等等。這一塊會放到TCP/UDP的總結博客裏面講，暫時只須要知道TCP創建鏈接會通過三次握手，斷開鏈接會通過四次揮手。

負責域名解析的DNS服務

DNS和HTTP同樣位於應用層。它提供域名到IP地址之間的解析服務。所謂域名就是相似於www.baidu.com這種字符串。爲了方便記憶，計算機也能夠被賦予域名。這樣咱們就能夠直接經過域名訪問，而不是毫無字面意義的IP地址。可是要讓計算機去理解域名，就有些困難了。爲了解決這個問題，就須要用到DNS服務了。DNS提供域名查IP和IP查域名的服務。

在瀏覽器上輸入一個域名會發生什麼？

最後，咱們以一個常見的面試題，來總結一下在使用HTTP協議進行通訊的過程當中，IP協議、TCP協議和DNS服務發揮了哪些做用。

URI和URL

URL就是咱們使用瀏覽器訪問WEB網頁時輸入的網頁地址，好比：https://www.baidu.com/。URL的全稱是統一資源定位符。

而URI是統一資源標識符。URI用字符串標識某一互聯網資源，而URL標識資源的地點，因此URL是URI的子集。爲了讓你更直觀的認識URI，能夠了解如下URI的格式：

登陸信息爲指定用戶名和密碼，做爲訪問服務器資源的登陸信息，此項是可選項。服務器地址就是域名，也能夠是IP。端口號也是可選項，不填的就會使用默認端口號。文件路徑就是服務器上該資源的路徑。查詢字符串就是傳入到服務器的參數。片斷標識符也是可選項，它一般能夠標記出已獲取資源中的某個位置。

初識HTTP

請求和響應

HTTP協議的做用是用於客戶端和服務器端之間的通訊。經過請求和響應的交互達成通訊。HTTP協議規定，請求從客戶端發出，最後服務端響應請求並返回。

下面來看看請求報文的構成

方法就是請求的類型，URI上一節講過。協議版本就是HTTP的版本號，其餘的部分待會再說。下面再看看響應報文的構成

狀態碼能反應該次請求的結果如何，圖中的200就表明請求成功。

HTTP是一種無狀態的協議，即HTTP協議自己不對請求和響應之間的通訊狀態進行保存。雖然其自己不能保存，可是爲了實現保持狀態的功能，因而引入了Cookie技術。關於Cookie後面再說。

接下來詳細說說前面提到的請求類型，也就是方法的意義。下面介紹如下HTTP/1.1中可以使用的部分方法。

GET：獲取資源

GET方法用來請求訪問被URI識別的資源，若是請求的是文本圖片這些資源，那就保持原樣返回。若是請求的是接口，那麼就返回程序執行的返回結果。

POST：傳輸數據

雖然咱們也能夠利用GET方法的參數來傳輸資源，可是通常仍是用POST方法。雖然它們功能很類似，可是最主要的一個區別就是：GET方法的參數會顯示在URI上，也就是以？號開頭的。而POST方法的參數會放在主體裏面。這樣對於傳輸數據來講，顯然會安全一點。

PUT：傳輸文件

要求在請求報文的主體中包含文件內容，而後保存到URI指定的位置。

HEAD：得到報文首部

HEAD方法和GET方法同樣，只是不返回報文主體部分。用於確認URI的有效性以及資源更新的日期時間等。

DELETE：刪除文件

與PUT方法相反，DELETE請求刪除URI指定的資源。可是和PUT同樣，它們都不帶驗證機制，因此通常的話也不會使用PUT或者DELETE，均可以用POST替代，而後配合程序代碼來驗證刪除。

OPTIONS：查詢支持的方法

用以查詢URI指定資源支持的方法。

接着再說說前面提到的Cookie

Cookie

Cookie能夠解決HTTP無狀態的問題。Cookie會根據從服務端返回的響應報文中的一個叫Set-Cookie的首部字段信息，來通知客戶端保存Cookie。當下次客戶端再次請求該服務端時就會在請求報文中加入Cookie值。常見的場景就是登陸。首先客戶端發送登陸請求，登陸成功後服務端返回用戶信息，而後客戶端把用戶信息存入Cookie，這樣用戶的登陸狀態就保持住了。固然，通常不會直接把用戶信息存入Cookie，畢竟Cookie是存在客戶端的，很不安全，通常會配合Session來使用。好比把用戶信息存到服務端的Session中，給客戶端返回SessionID，這樣同樣能夠查詢出用戶信息。

下面展現Cookie在請求響應中的樣子

HTTP報文

請求和響應之間交換的信息就被稱爲HTTP報文。請求方的叫作請求報文，響應方的叫作響應報文。HTTP報文大體可分爲首部和主體兩部分。詳細的可見下圖

其中，請求行包含請求的方法，請求的URI和HTTP的版本。狀態行包含響應結果的狀態碼和HTTP版本，狀態碼就好比前面提到的200，它表明請求成功，更多的狀態碼和各類首部字段待會再詳說。其餘則包含Cookie等信息。

HTTP狀態碼

狀態碼的職責是客戶端發送請求後，描述返回的請求結果。藉助狀態碼咱們就能夠知道該次請求在服務端是否正常處理了。狀態碼以開頭的數字主要分爲5大類：

咱們只要遵循狀態碼類別的定義，即便在服務端建立本身的狀態碼都沒問題。若是要列舉每個狀態碼，數量很是繁多，下面就介紹一下具備表明性的十幾個狀態碼。

2XX：表明成功

200 OK：表示客戶端發送的請求在服務端被正常處理。

204 No Content：表示請求已被成功處理，但在返回的響應報文中沒用返回資源。

206 Partial Content：表示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。這裏說一下，此處的範圍請求不是咱們業務代碼上的範圍查詢，而是HTTP的範圍請求。在之前網速不是很快的狀況下下載一個資源，可能會發生網絡中斷，若是網絡恢復的話就須要從頭下載。這時候就會想要從上次斷開的地方接着下載，那麼就必須有一種請求能夠支持範圍請求。好比對一份10000字節大小的資源進行範圍請求，能夠只請求5001~10000字節內的資源。請求、響應報文的內容以下圖：

3XX：表明重定向

301 Moved Permanently：永久性重定向，表示請求的資源已被分配到新的URI，之後應該使用資源如今所指的URI。

302 Found：臨時性重定向，表示請求的資源已被分配到新的URI，本次請求應該使用新的URI。

303 See Other：該狀態碼功能上和302相同，可是303明確表示客戶端應該採用GET方法獲取資源。

304 Not Modified：表示資源已找到，可是不符合請求的條件。

4XX：表明客戶端錯誤

400 Bad Request：表示請求報文中存在語法錯誤，須要修改請求內容後再次發送請求。

401 Unauthorized：表示發送的請求須要經過HTTP認證。當瀏覽器初次接收到401響應時，會彈出認證用的對話窗口。

403 Forbidden：表示請求的資源被服務器拒絕了。拒絕的理由能夠在主體部分進行說明。通常是沒用訪問權限纔會出現這個問題。

404 Not Found：表示服務器上沒法找到請求的資源。

5XX：表明服務端錯誤

500 Internal Server Error：表示服務端執行請求時發生錯誤，通常是服務端代碼出現了問題。

503 Service Unavailable：表示服務器暫時處於超負載或者正在進行停機維護。

HTTP報文首部

前面說到過，HTTP報文主要分爲報文首部和主體。首部內容爲客戶端和服務端分別處理請求和響應提供所需的信息。具體的信息能夠往上翻一點，看看那個截圖。

HTTP首部字段是由首部字段名稱和字段值構成，中間用冒號分隔。例如：

Content-Type:text/html

Keep-Alive:timeout,max=100 (多個字段值用夠好分開)

首部字段主要分爲4種類型：

通用首部字段，請求報文和響應報文兩方都會使用的首部

請求首部字段，請求報文使用的首部字段，補充了請求的附加內容、客戶端信息等信息

響應首部字段，響應報文使用的首部字段

實體首部字段，針對請求和響應報文的實體部分使用的首部字段

以上只是HTTP/1.1規範定義的47種首部字段，並不表明所有。好比經常使用的Cookie、Set-Cookie均未出如今其中。下面詳細說說幾個很差理解的字段。

Cache-Contro

該字段能夠根據後面的字段值控制緩存行爲，如上面的報文結構圖中的no-cache表明不要緩存的資源，須要源服務器的資源。該字段還有不少其餘的值可供選擇，詳細的你們能夠另行查詢。

Connection

該字段主要有兩個做用：控制再也不轉發給代理的首部字段和管理長鏈接。

HTTP/1.1版本默認的鏈接就是長鏈接，以前的版本默認都是短連接。長鏈接的好處就是提升請求的效率。若是是短連接的話，咱們每次請求資源都要進行一次TCP鏈接(HTTP基於TCP)，也就是三次握手。請求完後斷開鏈接，等下次請求資源再次握手。而長鏈接就是創建TCP鏈接後短期內不斷開，期間能夠進行屢次HTTP請求。

Via

該字段是爲了追蹤客戶端與服務端之間的請求和響應報文的傳輸路徑。報文通過代理服務器或網關時，會如今Via字段中附加該服務器的信息，而後再進行轉發。

If-Match

帶有形如If-xxx這種形式的首部字段的請求均可稱爲條件請求。服務器收到帶有附加條件的請求首先會判斷條件爲真時纔會執行請求。

只有當If-Match的值和Etag值一致時，服務器纔會接收請求。

ETag

該字段能告訴客戶端資源的惟一標識，當資源更新時這個標識也會改變。

其餘的首部字段

Set-Cookie和Cookie

下圖列舉了Set-Cookie的字段值

Cookie的使用是很是常見的，你們能夠隨便打開一個網站，按F12打開調試，找到一個接口的請求，在響應首部裏面應該能看到Set-Cookie字段，在請求首部應該能看到Cookie字段。Set-Cookie字段值的第一部分通常是一個字符串=另外一個字符串，這就是上面的NAME=VALUE，name和value都是自定義的，而後請求時，Cookie就會帶上NAME=VALUE。

DNT

該字段屬於請求首部字段，DNT是Do Not Track的簡稱，意爲拒絕我的信息被收集，是表示拒絕被精準廣告追蹤的一種方法。它的值只有0和1，0表明贊成，1表明拒絕。

確保WEB安全的HTTPS

到此爲止，咱們瞭解到了HTTP優秀和方便的一面，它也有一些不足之處。以下：

通訊沒有加密，內容可能被竊聽。
不驗證通訊方的身份，所以有可能遭遇假裝
沒法證實報文的完整性，因此有可能被篡改

內容被竊聽

因爲HTTP自己不具有加密（HTTP報文使用的是明文）的功能，因此也沒法做到對通訊總體的加密。

因爲互聯網的特色，不管世界上哪一個角落的服務器和客戶端進行通訊，在此通訊線路上的某些網絡設備都不多是私有的，因此不排除在某個環節會遭到惡意的監聽。

而這個竊聽也並非什麼難事，好比被普遍使用的抓包工具Wireshark就能夠實現。它能夠獲取HTTP協議的請求和響應的內容，並對其進行解析。這個軟件我想應該有不少人知道，不過想要用好，仍是得先學好TCP協議。

雖然HTTP協議中沒有加密機制，可是能夠經過和SSL或TLS的組合使用，加密HTTP的通訊內容。用SSL創建安全通訊線路以後，就能夠在這條線路上進行HTTP通訊了。與SSL組合使用的HTTP就被稱爲HTTPS。

身份遭遇假裝

HTTP協議的請求和響應不會對通訊方進行確認，也就是說返回響應的並不必定是咱們請求的服務器。並且任何人均可以向服務器發起請求。雖然使用HTTP協議沒法肯定通訊方，但若是使用SSL則能夠。SSL不只提供加密，並且還使用了證書這種方法，來確認身份。證書通常由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。這些所謂的值得信任的第三機構通常是社會承認的企業或者組織機構。並且僞造證書這是一件很是困難的事情。

內容被篡改

因爲HTTP協議沒法證實通訊報文的完整性，因此在請求或響應到達對方以前，報文的內容可能會被篡改。HTTPS又是如何發現內容被篡改的，下面就會仔細說說HTTPS的工做原理。

HTTPS工做原理

前面已經說過，HTTPS實際上是一個披着SSL外殼的HTTP。而另外提到的TLS能夠看做是SSL的最新版本或者升級版。

在對SSL進行講解以前，咱們先了解一下加密方法。SSL採用的是非對稱加密的方式。也就是說，加密是使用的是公鑰，而解密是使用的是私鑰。與之對應的是對稱加密，也就是加密和解密都是同一個密鑰，這種加密方式，我想不用說，都應該知道，運用在HTTP中依舊不安全，由於你須要把這個密鑰發送給客戶端，這個期間有可能被其餘人竊聽到密鑰。

而非對稱加密，公鑰是任何人均可以知道的，而私鑰則只有服務器本身知道，這樣客戶端經過公鑰加密信息，服務端經過私鑰解密。看似很安全了，可是別忘了HTTP的一個缺點，就是內容可能會被篡改。客戶端訪問HTTPS服務器時，服務器會先把公鑰發送給客戶端，在這個過程當中，若是有其餘人篡改公鑰，把公鑰換成本身的，那麼就失去了加密的意義。反而是服務端沒法解密信息了。對於公鑰被篡改這個問題，咱們待會再說，先說說HTTPS究竟是怎麼實現加密的。

HTTPS加密方式

HTTPS採用的是對稱和非對稱混合式的加密機制。簡單地說就是客戶端獲得公鑰後，會生成一個簡單的共享密鑰，而後把共享密碼用公鑰加密發送給服務端，服務端解密後獲得這個共享密鑰，以後的通訊就基於這個共享密鑰進行加密通訊。此時只有客戶端和服務端知道這個共享密碼，由於中途傳輸的是加密後的共享密鑰，即便被竊取了，沒有私鑰也解不開。

再接着說前面提到的，HTTPS是如何知道服務端給客戶端發送公鑰時，公鑰有沒有被篡改。前面提到了證書，是由一些機構頒發的，通常稱爲CA機構。這些機構通常會有本身的私有密鑰，它會對咱們服務器的公開密鑰作數字簽名，而後將這個已簽名的公開密鑰放入公鑰證書綁定在一塊兒。到時候服務端往客戶端發送公開密鑰時，會把密鑰和數字簽名一塊兒發送給客戶端。而後客戶端會根據CA機構的公鑰對這個數字簽名進行驗證，以確保公鑰沒有被篡改。可是你會發現，CA機構的公鑰是什麼鬼，期間並無發送這個東西。通常這些CA機構的公鑰會內置在操做系統或者瀏覽器裏，因此不須要傳輸，這樣也確保了安全性。