前言

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

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

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

面試知識點複習手冊

全複習手冊文章導航

Csdn全複習手冊文章導航：

blog.csdn.net/qqxx6661/ar…

已釋出知識點複習手冊

• Java基礎知識點面試手冊
• Java容器（List、Set、Map）知識點快速複習手冊
• Java併發知識點快速複習手冊（上）
• Java併發知識點快速複習手冊（下）
• Java虛擬機器知識點快速複習手冊（上）
• Java虛擬機器知識點快速複習手冊（下）
• 快速梳理23種常用的設計模式
• Redis基礎知識點面試手冊
• Leetcode題解分類彙總（前150題）
• 面試常問的小演算法總結
• 查詢演算法總結及其部分演算法實現Python/Java
• 排序演算法實現與總結Python/Java
• ......等（請檢視全複習手冊導航）

本文參考

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

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

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

--------------------正文-----------------------

狀態碼

圖片資料夾兩張圖

有擴充參考：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： www.cnblogs.com/vajoy/p/534…

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

  關於303和307：blog.csdn.net/liuxingen/a…

  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. mp.weixin.qq.com/s/GICbiyJpI…

2. github.com/CyC2018/Int…

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

mp.weixin.qq.com/s/NMhNVDP47…

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

  • http2.github.io/http2-spec/…

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

  • zh.wikipedia.org/wiki/DEFLAT…

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：github.com/qqxx6661

原創部落格主要內容

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

同步更新以下部落格

1. Csdn

blog.csdn.net/qqxx6661

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

2. 知乎

www.zhihu.com/people/yang…

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

3. 掘金

juejin.im/user/5b4801…

4. 簡書

www.jianshu.com/u/b5f225ca2…

個人公眾號：Rude3Knife

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