HTTP應知應會知識點複習手冊（上）

image

前言

本文快速回顧了常考的的知識點，用做面試複習，事半功倍。

上篇主要內容： 狀態碼、Http1.0/1.1/2.0、Https、GET和POST

下篇主要內容： Web***技術、HTTP基礎概念、HTTP Header詳解、HTTP應用

面試知識點複習手冊

全複習手冊文章導航

點擊公衆號下方：技術推文——面試衝刺

已發佈知識點複習手冊

• Java基礎知識點面試手冊（上）

• Java基礎知識點面試手冊（下）

• Java容器（List、Set、Map）知識點快速複習手冊（上）

• Java容器（List、Set、Map）知識點快速複習手冊（中）

• Java容器（List、Set、Map）知識點快速複習手冊（下）

• Redis基礎知識點快速複習手冊（上）

• Redis基礎知識點快速複習手冊（下）

• Java併發知識點快速複習手冊（上）

• Java併發知識點快速複習手冊（下）

• Java虛擬機知識點快速複習手冊（上）

• Java虛擬機知識點快速複習手冊（下）

• 阿里巴巴Java開發手冊閱讀筆記

• 雙非碩士的春招秋招經驗總結——對校招，複習以及面試心態的理解

• ......等（請查看全複習手冊導航）

本文參考

本文內容主要參考來自CyC2018的Github倉庫：CS-Notes

有刪減，修改，補充額外增長內容

本做品採用知識共享署名-非商業性使用 4.0 國際許可協議進行許可。

狀態碼

有拓展參考：

https://zhuanlan.zhihu.com/p/34648453

1XX 信息

• 100 Continue ：代表到目前爲止都很正常，客戶端能夠繼續發送請求或者忽略這個響應。

• 101 Switching Protocols 協議升級：請求者要求服務器切換協議，服務器確認並準備切換

主要用於websocket：表示服務端接受 WebSocket 協議的客戶端鏈接
也能夠用於http2的升級。

2XX 成功

• 200 OK

• 204 No Content ：請求已經成功處理，可是返回的響應報文不包含實體的主體部分。通常在只須要從客戶端往服務器發送信息，而不須要返回數據時使用。

• 206 Partial Content ：表示客戶端進行了範圍請求。響應報文包含由 Content-Range 指定範圍的實體內容。

3XX 重定向

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時性重定向

• 303 See Other ：和 302 有着相同的功能，可是 303 明確要求客戶端應該採用 GET 方法獲取資源。

• 注：雖然 HTTP 協議規定 30一、302 狀態下重定向時不容許把 POST 方法改爲 GET 方法，可是大多數瀏覽器都會在 30一、302 和 303 狀態下的重定向把 POST 方法改爲 GET 方法。

• 304 Not Modified ：若是請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，若是不知足條件，則服務器會返回 304 狀態碼。

瀏覽器緩存分爲強制緩存和協商緩存，優先讀取強制緩存。

強制緩存分爲expires和cache-control：

協商緩存包括etag和last-modified：

若是 Last-Modified 和 ETag 同時被使用，則要求它們的驗證都必須經過纔會返回304，若其中某個驗證沒經過，則服務器會按常規返回資源實體及200狀態碼。

協商緩存與強制緩存的區別在於強制緩存不須要訪問服務器，返回結果是200，協商緩存須要訪問服務器，命中協商緩存的話，返回結果是304。

步驟：客戶端發送附帶條件的請求時（if-matched,if-modified-since,if-none-match,if-range,if-unmodified-since任一個）服務器端容許請求訪問資源，但因發生請求未知足條件的狀況後，直接返回304Modified（服務器端資源未改變，可直接使用客戶端未過時的緩存）。

補充網頁：expires/cache-control/last-modified/etag詳解以及解釋爲什麼應chrome該顯示304卻顯示200：
http://www.cnblogs.com/vajoy/p/5341664.html

• last-modified的設置標準是資源的上次修改時間

• etag是爲了應對資源修改時間可能很頻繁的狀況出現的，是基於資源的內容計算出來的值，所以優先級也較高。

• expires是一個特定的時間，是比較舊的標準。

• cache-control一般是一個具體的時間長度，比較新，優先級也比較高。

• 307 Temporary Redirect ：臨時重定向，與 302 的含義相似，可是 307 要求瀏覽器不容許把重定向請求的 POST 方法改爲 GET 方法。

關於303和307：https://blog.csdn.net/liuxingen/article/details/51511034

30三、307其實就是把原來30一、302不」合法」的處理動做給」合法化」，由於發現你們都不太遵照，因此乾脆就增長一條規定。

額外功能：也用於hsts跳轉。hsts全稱HTTP嚴格傳輸安全（HTTP Strict Transport Security，縮寫：HSTS）

• 功能是要求瀏覽器下次訪問該站點時使用https來訪問，而再也不須要先是http再轉https。這樣能夠避免ssl剝離：即者在用戶使用http訪問的過程當中進行，對服務器冒充本身是用戶，在者和服務器中使用https訪問，在用戶和服務器中使用http訪問。具體使用方法是在服務器響應頭中添加Strict-Transport-Security，能夠設置 max-age。

4XX 客戶端錯誤

• 400 Bad Request ：請求報文中存在語法錯誤。提交json時，若是json格式有問題，接收端接收json，也會出現400 bad request。好比常見的json串，數組不該該有",可是有"了。

• 401 Unauthorized ：該狀態碼錶示發送的請求須要有認證信息（BASIC 認證、DIGEST 認證）。若是以前已進行過一次請求，則表示用戶認證失敗。

• 403 Forbidden ：請求被拒絕，服務器端沒有必要給出拒絕的詳細理由。

• 404 Not Found

• 405 method not allowed
  問題緣由：請求的方式（get、post、delete）方法與後臺規定的方式不符合。好比： 後臺方法規定的請求方式只接受get，若是用post請求，就會出現 405 method not allowed的提示

• 408 請求超時

5XX 服務器錯誤

• 500： Internal Server Error ：服務器正在執行請求時發生錯誤。

• 502：Bad Gateway：進程響應的內容是nginx沒法理解的響應

• 503 Service Unavilable ：服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。（瞬時請求量過大）

• 504：Gateway Time-out：進程阻塞超過nginx的時間閾值返回504

• 505：不支持該http版本

Http1.0/1.1/2.0

參考：

1. https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A

2. https://github.com/CyC2018/Interview-Notebook/blob/master/notes/HTTP.md

1.1相比1.0

長鏈接和流水線（Pipelining）處理

HTTP 1.1支持長鏈接（PersistentConnection）和管線化（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。

若是要斷開 TCP 鏈接，須要由客戶端或者服務器端提出斷開，使用 Connection : close

在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

Host頭處理/虛擬主機

在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。（Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。）

• 在http 1.1中不能缺失host字段,若是缺失, 服務器返回400 bad request，http1.1中不能缺失host字段，但host字段能夠是空值。

• 在http 1.0中能夠缺失host字段。

支持分塊傳輸編碼

HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

另外一種解釋：能夠把數據分割成多塊，讓瀏覽器逐步顯示頁面。

錯誤通知的管理/新增狀態碼

在HTTP1.1中新增了24個錯誤狀態響應碼，如：

• 409（Conflict）表示請求的資源與資源的當前狀態發生衝突；
• 410（Gone）表示服務器上的某個資源被永久性的刪除。

緩存處理（協商緩存）

在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準。

HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

新增緩存處理指令 max-age

支持同時打開多個 TCP 鏈接

新增狀態碼 100

2.0相比1.1

https://mp.weixin.qq.com/s/NMhNVDP47npMqx5ruVy43w

HTTP/1.x 缺陷

HTTP/1.x 實現簡單是以犧牲性能爲代價的：

• 客戶端須要使用多個鏈接才能實現併發和縮短延遲；
• 不會壓縮請求和響應首部，從而致使沒必要要的網絡流量；
• 不支持有效的資源優先級，導致底層 TCP 鏈接的利用率低下。

二進制分幀層

HTTP/2.0 將報文分紅 HEADERS 幀和 DATA 幀，它們都是二進制格式的。

在通訊過程當中，只會有一個 TCP 鏈接存在，它承載了任意數量的雙向數據流（Stream）。

• 一個數據流（Stream）都有一個惟一標識符和可選的優先級信息，用於承載雙向信息。
• 消息（Message）是與邏輯請求或響應對應的完整的一系列幀。

• 幀（Frame）是最小的通訊單位，來自不一樣數據流的幀能夠交錯發送，而後再根據每一個幀頭的數據流標識符從新組裝。
  
  在這裏插入圖片描述
  和1.1區別在於：

• HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少

• 二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
  
  在這裏插入圖片描述
  
  在這裏插入圖片描述
  二進制分幀：多路複用（MultiPlexing）

即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的 id將request再歸屬到各自不一樣的服務端請求裏面。

• 單鏈接多資源的方式，減小服務端的連接壓力,內存佔用更少,鏈接吞吐量更大；

• 因爲減小TCP 慢啓動時間，提升傳輸的速度。

HTTP2.0的多路複用和HTTP1.X中的長鏈接複用有什麼區別？

關鍵點：一個是串行，一個是並行，一個阻塞不影響其餘request。

header壓縮

如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

在這裏插入圖片描述

在這裏插入圖片描述

服務端推送（server push）

同SPDY同樣，HTTP2.0也具備server push功能。

在這裏插入圖片描述

在這裏插入圖片描述

SPYD相比1.1

多路複用

針對HTTP高延遲的問題，SPDY優雅的採起了多路複用（multiplexing）。多路複用經過多個請求stream共享一個tcp鏈接的方式，解決了HOL blocking的問題，下降了延遲同時提升了帶寬的利用率。

請求優先級（request prioritization）

多路複用帶來一個新的問題是，在鏈接共享的基礎之上有可能會致使關鍵請求被阻塞。SPDY容許給每一個request設置優先級，這樣重要的請求就會優先獲得響應。好比瀏覽器加載首頁，首頁的html內容應該優先展現，以後纔是各類靜態資源文件，腳本文件等加載，這樣能夠保證用戶能第一時間看到網頁內容。

header壓縮

前面提到HTTP1.x的header不少時候都是重複多餘的。選擇合適的壓縮算法能夠減少包的大小和數量。

服務端推送（server push）

採用了SPDY的網頁，例如個人網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就能夠直接從緩存中獲取到，不用再發請求了。

基於HTTPS的加密協議傳輸

大大提升了傳輸數據的可靠性。

HTTP2.0和SPDY的區別

• HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS

• HTTP2.0 消息頭的壓縮算法採用 HPACK

• http://http2.github.io/http2-spec/compression.html

• SPDY 消息頭的壓縮算法採用 DEFLATE

• http://zh.wikipedia.org/wiki/DEFLATE

HTTPs

HTTPS和HTTP的區別主要以下：

一、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。

二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

三、用的端口也不同，前者是80，後者是443。

四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證、完整性保護的網絡協議，比http協議安全。
　　
　　

HTTP 有如下安全性問題：

內容可能會被竊聽；
通訊方的身份有可能遭遇假裝；
報文有可能遭篡改。
HTTPs 並非新協議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通訊，再由 SSL 和 TCP 通訊。也就是說 HTTPs 使用了隧道進行通訊。

隧道：它是將原始IP包（其報頭包含原始發送者和最終目的地）封裝在另外一個數據包（稱爲封裝的IP包）的數據淨荷中進行傳輸。使用隧道的緣由是在不兼容的網絡上傳輸數據，或在不安全網絡上提供一個安全路徑。

經過使用 SSL，HTTPs 具備了：

加密（防竊聽）、認證（防假裝）和完整性保護（防篡改）

在這裏插入圖片描述

HTTPs認證

請看下面加黑字體是重點：

在這裏插入圖片描述

• 服務方 S 向第三方機構CA提交公鑰、組織信息、我的信息(域名)等信息並申請認證；

• CA 經過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的全部權等；

• 如信息審覈經過，CA 會向申請者簽發認證文件-證書。
  簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，而後，採用 CA 的私鑰對信息摘要進行簽名；

客戶端：

• 客戶端 C 向服務器 S 發出請求時，S 返回證書文件；

• 客戶端 C 讀取證書中的相關的明文信息，採用相同的散列函數計算獲得信息摘要，而後，利用對應 CA 的公鑰解密簽名數據，

• 對比證書的信息摘要（明文的信息摘要和簽名解密後的一致），若是一致，則能夠確認證書的合法性，即公鑰合法；

• 客戶端而後驗證證書相關的域名信息、有效時間等信息；

• 客戶端會內置信任 CA 的證書信息(包含公鑰)，若是CA不被信任，則找不到對應 CA 的證書，證書也會被斷定非法。

在這個過程注意幾點：

• 1.申請證書不須要提供私鑰，確保私鑰永遠只能服務器掌握；

• 2.證書的合法性仍然依賴於非對稱加密算法，證書主要是增長了服務器信息以及簽名；

• 3.內置 CA 對應的證書稱爲根證書，頒發者和使用者相同，本身爲本身簽名，即自簽名證書；

• 4.證書=網站公鑰+申請者與頒發者信息+簽名；

HTTPs認證後的傳輸

HTTPs 採用混合的加密機制，使用公開密鑰加密用於傳輸對稱密鑰來保證安全性，以後使用對稱密鑰加密進行通訊來保證效率。（下圖中的 Session Key 就是對稱密鑰）

在這裏插入圖片描述

完整性保護

SSL 提供報文摘要功能來進行完整性保護。

HTTP 也提供了 MD5 報文摘要功能，可是卻不是安全的。例如報文內容被篡改以後，同時從新計算 MD5 的值，通訊接收方是沒法
意識到發生篡改。

HTTPs 的報文摘要功能之因此安全，是由於它結合了加密和認證這兩個操做。試想一下，加密以後的報文，遭到篡改以後，也很難從新計算報文摘要，由於沒法輕易獲取明文。

HTTPs 的缺點

• 由於須要進行加密解密等過程，所以速度會更慢；
• 須要支付證書受權的高費用。

GET 和 POST 的區別

做用

GET 用於獲取資源，而 POST 用於傳輸實體主體。

參數

• GET 的傳參方式相比於 POST 安全性較差，由於 GET 傳的參數在 URL 中是可見的，可能會泄露私密信息。

• 而且 GET 只支持 ASCII 字符，所以 GET 的參數中若是存在中文等字符就須要先進行編碼，例如中文會轉換爲%E4%B8%AD%E6%96%87，而空格會轉換爲%20。POST 支持標準字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

• 不能由於 POST 參數存儲在實體主體中就認爲它的安全性更高，由於照樣能夠經過一些抓包工具（Fiddler）查看。

安全

安全的 HTTP 方法不會改變服務器狀態，也就是說它只是可讀的。GET 方法是安全的，而 POST 卻不是

由於 POST 的目的是傳送實體主體內容，這個內容多是用戶上傳的表單數據，上傳成功以後，服務器可能把這個數據存儲到數據庫中，所以狀態也就發生了改變。

安全的方法除了 GET 以外還有：HEAD、OPTIONS。

不安全的方法除了 POST 以外還有 PUT、DELETE。

冪等性

冪等的 HTTP 方法，一樣的請求被執行一次與連續執行屢次的效果是同樣的，服務器的狀態也是同樣的。

GET，HEAD，PUT 和 DELETE 等方法都是冪等的，

而POST 方法不是。全部的安全方法也都是冪等的。

可緩存

• 請求報文的 HTTP 方法自己是可緩存的，包括 GET 和 HEAD

• 可是 PUT 和 DELETE 不可緩存，POST 在多數狀況下不可緩存的。

XMLHttpRequest

爲了闡述 POST 和 GET 的另外一個區別，須要先了解 XMLHttpRequest：

XMLHttpRequest 是一個 API，它爲客戶端提供了在客戶端和服務器之間傳輸數據的功能。它提供了一個經過 URL 來獲取數據的簡單方式，而且不會使整個頁面刷新。這使得網頁只更新一部分頁面而不會打擾到用戶。XMLHttpRequest 在 AJAX 中被大量使用。

在使用 XMLHttpRequest 的 POST 方法時，瀏覽器會先發送 Header 再發送 Data。

但並非全部瀏覽器會這麼作，例如火狐就不會。而 GET 方法 Header 和 Data 會一塊兒發送。

關注我

我是蠻三刀把刀，目前爲後臺開發工程師。主要關注後臺開發，網絡安全，Python爬蟲等技術。

來微信和我聊聊：yangzd1102

Github：https://github.com/qqxx6661

原創博客主要內容

• 筆試面試複習知識點手冊
• Leetcode算法題解析（前150題）
• 劍指offer算法題解析
• Python爬蟲相關技術分析和實戰
• 後臺開發相關技術分析和實戰
  同步更新如下博客

1. Csdn

http://blog.csdn.net/qqxx6661

擁有專欄：Leetcode題解（Java/Python）、Python爬蟲開發、面試助攻手冊

2. 知乎

https://www.zhihu.com/people/yang-zhen-dong-1/

擁有專欄：碼農面試助攻手冊

3. 掘金

https://juejin.im/user/5b48015ce51d45191462ba55

4. 簡書

https://www.jianshu.com/u/b5f225ca2376

我的公衆號：Rude3Knife

我的公衆號：Rude3Knife

若是文章對你有幫助，不妨收藏起來並轉發給您的朋友們~