前言

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

知乎閱讀體驗較差，請移步CSDN，見下方鏈接。

上篇主要內容： 狀態碼、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 信息

• 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

參考：

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的區別主要如下：

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 支持標準字符集。

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

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

推薦閱讀：

相关文章