大牛深入淺出幫你落地網路 HTTP
瞭解 Web 及網路基礎
對端傳輸
傳送端在層與層間傳輸資料時，沒經過一層都會被加上首部資訊，接收端每經過一層都會刪除一條首部
多種協議作用
IP 協議，TCP 協議和 DNS 服務在使用 HTTP 協議過程中發揮的作用
簡單的 HTTP 協議
請求報文和響應報文
客戶端像伺服器發起請求時會生成一段請求報文，請求報文是由請求方法，URL，協議版本，可選的請求首部欄位和內容實體構成。
請求報文
接收到請求的伺服器，會將請求內容的處理結構以響應的形式返回。響應報文基本上由協議版本，狀態碼，用以解釋狀態的原因短語，可選的響應首部欄位以及實體主體構成。
響應報文
HTTP 是不儲存狀態的協議和 Cookie 的簡單介紹
HTTP 協議對於傳送的請求和響應不做持久化處理。這時候引入了 Cookie 技術用於狀態管理。Cookie 對用與登入的狀態管理，沒有 Cookie 這個技術的話，因為 HTTP 不儲存狀態，每次開啟新網頁都必須再次登入。
Cookie 會根據響應報文中的 Set-Cookie 欄位來通知客戶端自動儲存 Cookie。下次請求時會自動傳送 Cookie，伺服器會比對資料得到狀態結果。
Cookie
Post 和 Get 的區別
先引入副作用和冪等的概念。
副作用指對伺服器上的資源做改變，搜尋是無副作用的，註冊是副作用的。
冪等指傳送 M 和 N 次請求（兩者不相同且都大於1），伺服器上資源的狀態一致。註冊10個和11個帳號是不冪等的，對文章進行更改10次和11次是冪等的。
在規範的應用場景上說，Get 多用於無副作用，冪等的場景，例如搜尋關鍵字。Post 多用於副作用，不冪等的場景，例如註冊。
在技術上說：
-
Get 請求能快取，Post 不能
-
Post 相對 Get 安全一點點，因為Get 請求都包含在 URL 裡，且會被瀏覽器儲存歷史紀錄，Post 不會，但是在抓包的情況下都是一樣的。
-
Post 可以通過 request body來傳輸比 Get 更多的資料，Get 沒有這個技術
-
URL有長度限制，會影響 Get 請求，但是這個長度限制是瀏覽器規定的，不是 RFC 規定的
-
Post 支援更多的編碼型別且不對資料型別限制
常見狀態碼
常見狀態碼
2XX 成功
-
200 OK，表示從客戶端發來的請求在伺服器端被正確處理
-
204 No content，表示請求成功，但響應報文不含實體的主體部分
-
206 Partial Content，進行範圍請求
3XX 重定向
-
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
-
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
-
303 see other，表示資源存在著另一個 URL，應使用 GET 方法丁香獲取資源
-
304 not modified，表示伺服器允許訪問資源，但因發生請求未滿足條件的情況
-
307 temporary redirect，臨時重定向，和302含義相同
4XX 客戶端錯誤
-
400 bad request，請求報文存在語法錯誤
-
401 unauthorized，表示傳送的請求需要有通過 HTTP 認證的認證資訊
-
403 forbidden，表示對請求資源的訪問被伺服器拒絕
-
404 not found，表示在伺服器上沒有找到請求的資源
5XX 伺服器錯誤
-
500 internal sever error，表示伺服器端在執行請求時發生了錯誤
-
503 service unavailable，表明伺服器暫時處於超負載或正在停機維護，無法處理請求
HTTP 首部
通用首部
指請求報文和響應報文都可以使用的欄位
-
Cache-Control
-
no-cache 指客戶端不快取過期資源
-
no-store 指不進行快取
-
max-age 指快取資源的快取時間比指定的值小，那麼客戶端就接受快取資源，且快取伺服器不對資源有效性進行再次確認
-
-
Connection 指控制不再轉發給代理的首部欄位（Hop-by-hop），管理持久連線
-
close 指伺服器像明確斷開連線
-
Keep-Alive 指儲存持久連線，HTTP/1.1前預設連線是非永續性的，如需要儲存持久連線，需要增加此欄位
-
-
Upgrade 可以用來指定一個完全不同的通訊協議，對於這個欄位，伺服器可以返回101狀態碼
請求首部欄位
-
Accept 指使用者代理能夠處理的媒體型別及媒體型別的相對優先順序
-
Accept-Encoding 指用來告知伺服器使用者代理支援的內容編碼及內容編碼的優先順序順序
-
Authorization 指用來告知伺服器，使用者代理的認證資訊
-
Host 當一個 IP 下存在多個域名時，幫助伺服器知道要請求的具體主機
-
User-Agent 會講建立請求的瀏覽器和使用者代理名稱等資訊傳達給伺服器
HTTPS
HTTPS 是 HTTP 建立在 SSL/TLS 安全協議上的。
在 iOS 中，客戶端本地會存放著 CA 證書，在HTTPS 請求時，會首先像伺服器索要公鑰，獲得公鑰後會使用本地 CA 證書驗證公鑰的正確性，然後通過正確的公鑰加密資訊傳送給伺服器，伺服器會使用私鑰解密資訊。
SSL/TLS握手階段分為五步：
以下引自 阮一峰的網路日誌
第一步，愛麗絲給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支援的加密方法。
第二步，鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個伺服器生成的隨機數（Server random）。
第三步，愛麗絲確認數字證書有效，然後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。
第四步，鮑勃使用自己的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。
第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成"對話金鑰"（session key），用來加密接下來的整個對話過程。
HTTPS 相對於 HTTP 效能上差點，因為多了 SSL/TLS 的幾次握手和加密解密的運算處理，但是加密解密的運算處理已經可以通過特有的硬體來加速處理。
如果需要Python方面的入門知識可以點選這個連結獲取入門資料
掃碼關注不迷路
專注分享乾貨一百年不動搖
