HTTP应知应会知识点复习手册（上）
前言
本文快速回顧了常考的的知識點，用作面試復習，事半功倍。
上篇主要內容： 狀態碼、Http1.0/1.1/2.0、Https、GET和POST
下篇主要內容： Web攻擊技術、HTTP基礎概念、HTTP Header詳解、HTTP應用
面試知識點復習手冊
全復習手冊文章導航
Csdn全復習手冊文章導航：
https://blog.csdn.net/qqxx6661/article/details/86775594
已發布知識點復習手冊
- Java基礎知識點面試手冊
- Java容器（List、Set、Map）知識點快速復習手冊
- Java并發知識點快速復習手冊（上）
- Java并發知識點快速復習手冊（下）
- Java虛擬機知識點快速復習手冊（上）
- Java虛擬機知識點快速復習手冊（下）
- 快速梳理23種常用的設計模式
- Redis基礎知識點面試手冊
- Leetcode題解分類匯總（前150題）
- 面試常問的小算法總結
- 查找算法總結及其部分算法實現Python/Java
- 排序算法實現與總結Python/Java
- …等（請查看全復習手冊導航）
本文參考
本文內容主要參考來自CyC2018的Github倉庫：CS-Notes
有刪減，修改，補充額外增加內容
本作品采用知識共享署名-非商業性使用 4.0 國際許可協議進行許可。
--------------------正文-----------------------
狀態碼
圖片文件夾兩張圖
有拓展參考：https://zhuanlan.zhihu.com/p/34648453
| 1XX | Informational（信息性狀態碼） | 接收的請求正在處理 |
| 2XX | Success（成功狀態碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態碼） | 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態碼） | 服務器處理請求出錯 |
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 協議規定 301、302 狀態下重定向時不允許把 POST 方法改成 GET 方法，但是大多數瀏覽器都會在 301、302 和 303 狀態下的重定向把 POST 方法改成 GET 方法。
-
304 Not Modified ：如果請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務器會返回 304 狀態碼。
瀏覽器緩存分為強制緩存和協商緩存，優先讀取強制緩存。
強制緩存分為expires和cache-control：
-
expires是一個特定的時間，是比較舊的標準。
-
cache-control通常是一個具體的時間長度，比較新，優先級也比較高。
協商緩存包括etag和last-modified：
-
last-modified的設置標準是資源的上次修改時間
-
etag是為了應對資源修改時間可能很頻繁的情況出現的，是基于資源的內容計算出來的值，因此優先級也較高。
如果 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 -
-
307 Temporary Redirect ：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不允許把重定向請求的 POST 方法改成 GET 方法。
關于303和307：https://blog.csdn.net/liuxingen/article/details/51511034
303、307其實就是把原來301、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
參考：
https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A
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的區別主要如下：
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、用的端口也不一樣，前者是80，后者是443。
4、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 支持標準字符集。
- 不能因為 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
如果文章對你有幫助，不妨收藏起來并轉發給您的朋友們~
總結
以上是生活随笔為你收集整理的HTTP应知应会知识点复习手册（上）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 西工大计算机学院报名前联系导师的说明
- 下一篇： 文心一言和ChatGPT对比