HTTPS提出背景
超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。
爲了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通信加密。
HTTP和HTTPS的基本概念
HTTP：是互聯網上應用最爲廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。
HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTPS協議的主要作用可以分爲兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
HTTP協議和HTTPS協議區別如下：
1）HTTP協議是以明文的方式在網絡中傳輸數據，而HTTPS協議傳輸的數據則是經過TLS加密後的，HTTPS具有更高的安全性
2）HTTPS在TCP三次握手階段之後，還需要進行SSL 的handshake，協商加密使用的對稱加密密鑰
3）HTTPS協議需要服務端申請證書，瀏覽器端安裝對應的根證書
4）HTTP協議端口是80，HTTPS協議端口是443
HTTPS優點：
HTTPS傳輸數據過程中使用密鑰進行加密，所以安全性更高
HTTPS協議可以認證用戶和服務器，確保數據發送到正確的用戶和服務器
HTTPS缺點：
HTTPS握手階段延時較高：由於在進行HTTP會話之前還需要進行SSL握手，因此HTTPS協議握手階段延時增加
HTTPS連接緩存不如HTTP高效，會增加數據開銷和功耗，甚至已有的安全措施也會因此而受到影響；
HTTPS部署成本高：一方面HTTPS協議需要使用證書來驗證自身的安全性，所以需要購買CA證書；另一方面由於採用HTTPS協議需要進行加解密的計算，佔用CPU資源較多，需要的服務器配置或數目高
HTTP返回碼
HTTP協議的響應報文由狀態行、響應頭部和響應包體組成，其響應狀態碼總體描述如下：
1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求。
常見狀態代碼、狀態描述的詳細說明如下。
200 OK：客戶端請求成功。
206 partial content服務器已經正確處理部分GET請求，實現斷點續傳或同時分片下載，該請求必須包含Range請求頭來指示客戶端期望得到的範圍
300 multiple choices（可選重定向）:被請求的資源有一系列可供選擇的反饋信息，由瀏覽器/用戶自行選擇其中一個。
301 moved permanently（永久重定向）：該資源已被永久移動到新位置，將來任何對該資源的訪問都要使用本響應返回的若干個URI之一。
302 move temporarily(臨時重定向)：請求的資源現在臨時從不同的URI中獲得，
304：not modified :如果客戶端發送一個待條件的GET請求並且該請求以經被允許，而文檔內容未被改變，則返回304,該響應不包含包體（即可直接使用緩存）。
403 Forbidden：服務器收到請求，但是拒絕提供服務。
t Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
具體：
200 服務器成功返回網頁
404 請求的網頁不存在
503 服務不可用
1xx（臨時響應）
表示臨時響應並需要請求者繼續執行操作的狀態代碼。
100（繼續）請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其餘部分。
101（切換協議）請求者已要求服務器切換協議，服務器已確認並準備切換。
2xx （成功）
表示成功處理了請求的狀態代碼。
200（成功）服務器已成功處理了請求。通常，這表示服務器提供了請求的網頁。
201（已創建）請求成功並且服務器創建了新的資源。
202（已接受） 服務器已接受請求，但尚未處理。
203（非授權信息）服務器已成功處理了請求，但返回的信息可能來自另一來源。
204（無內容）服務器成功處理了請求，但沒有返回任何內容。
205（重置內容）服務器成功處理了請求，但沒有返回任何內容。
206（部分內容）服務器成功處理了部分 GET 請求。
3xx （重定向）
表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向。
300（多種選擇）針對請求，服務器可執行多種操作。 服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301（永久移動）請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302（臨時移動）服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
303（查看其他位置）請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304（未修改）自從上次請求後，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
305（使用代理）請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。
307（臨時重定向）服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
4xx（請求錯誤）
這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
400（錯誤請求）服務器不理解請求的語法。
401（未授權）請求要求身份驗證。 對於需要登錄的網頁，服務器可能返回此響應。
403（禁止）服務器拒絕請求。
404（未找到）服務器找不到請求的網頁。
405（方法禁用）禁用請求中指定的方法。
406（不接受）無法使用請求的內容特性響應請求的網頁。
407（需要代理授權）此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408（請求超時）服務器等候請求時發生超時。
409（衝突）服務器在完成請求時發生衝突。 服務器必須在響應中包含有關衝突的信息。
410（已刪除）如果請求的資源已永久刪除，服務器就會返回此響應。
411（需要有效長度）服務器不接受不含有效內容長度標頭字段的請求。
412（未滿足前提條件）服務器未滿足請求者在請求中設置的其中一個前提條件。
413（請求實體過大）服務器無法處理請求，因爲請求實體過大，超出服務器的處理能力。
414（請求的 URI 過長）請求的 URI（通常爲網址）過長，服務器無法處理。
415（不支持的媒體類型）請求的格式不受請求頁面的支持。
416（請求範圍不符合要求）如果頁面無法提供請求的範圍，則服務器會返回此狀態代碼。
417（未滿足期望值）服務器未滿足”期望”請求標頭字段的要求。
5xx（服務器錯誤）
這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
500（服務器內部錯誤）服務器遇到錯誤，無法完成請求。
501（尚未實施）服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。
502（錯誤網關）服務器作爲網關或代理，從上游服務器收到無效響應。
503（服務不可用）服務器目前無法使用（由於超載或停機維護）。 通常，這只是暫時狀態。
504（網關超時）服務器作爲網關或代理，但是沒有及時從上游服務器收到請求。
505（HTTP 版本不受支持）服務器不支持請求中所用的 HTTP 協議版本。
428 Precondition Required (要求先決條件)
先決條件是客戶端發送 HTTP 請求時，如果想要請求能成功必須滿足一些預設的條件。
一個好的例子就是 If-None-Match 頭，經常在 GET 請求中使用，如果指定了 If-None-Match ，那麼客戶端只在響應中的 ETag 改變後纔會重新接收回應。
先決條件的另外一個例子就是 If-Match 頭，這個一般用在 PUT 請求上用於指示只更新沒被改變的資源，這在多個客戶端使用 HTTP 服務時用來防止彼此間不會覆蓋相同內容。
當服務器端使用 428 Precondition Required 狀態碼時，表示客戶端必鬚髮送上述的請求頭才能執行請求，這個方法爲服務器提供一種有效的方法來阻止 'lost update' 問題。
429 Too Many Requests (太多請求)
當你需要限制客戶端請求某個服務數量時，該狀態碼就很有用，也就是請求速度限制。
在此之前，有一些類似的狀態碼，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （這不是HTTP定義的狀態碼）
如果你希望限制客戶端對服務的請求數，可使用 429 狀態碼，同時包含一個 Retry-After 響應頭用於告訴客戶端多長時間後可以再次請求服務。
431 Request Header Fields Too Large (請求頭字段太大)
某些情況下，客戶端發送 HTTP 請求頭會變得很大，那麼服務器可發送 431 Request Header Fields Too Large 來指明該問題。
511 Network Authentication Required (要求網絡認證)
對我來說這個狀態碼很有趣，如果你在開發一個 HTTP 服務器，你不一定需要處理該狀態碼，但如果你在編寫 HTTP 客戶端，那這個狀態碼就非常重要。
如果你頻繁使用筆記本和智能手機，你可能會注意到大量的公用 WIFI 服務要求你必須接受一些協議或者必須登錄後才能使用。這是通過攔截HTTP流量，當用戶試圖訪問網絡返回一個重定向和登錄，這很討厭，但是實際情況就是這樣的。使用這些“攔截”客戶端，會有一些討厭的副作用。在 RFC 中有提到這兩個的例子：
如果你在登錄WIFI前訪問某個網站，網絡設備將會攔截首個請求，這些設備往往也有自己的網站圖標 ‘favicon.ico'。登錄後您會發現，有一段時間內你訪問的網站圖標一直是WIFI登錄網站的圖標。
如果客戶端使用HTTP請求來查找文檔（可能是JSON），網絡將會響應一個登錄頁，這樣你的客戶端就會解析錯誤並導致客戶端運行異常，在現實中這種問題非常常見。
因此 511 狀態碼的提出就是爲了解決這個問題。
如果你正在編寫 HTTP 的客戶端，你最好還是檢查 511 狀態碼以確認是否需要認證後才能訪問。
參考：https://www.cnblogs.com/wqhwe/p/5407468.html
參考：https://blog.csdn.net/kongxianglei5313/article/details/80636167