了解 Web 及網絡基礎
對端傳輸
發送端在層與層間傳輸數據時，沒經過一層都會被加上首部信息，接收端每經過一層都會刪除一條首部
多種協議作用
IP 協議，TCP 協議和 DNS 服務在使用 HTTP 協議過程中發揮的作用
簡單的 HTTP 協議
請求報文和響應報文
客戶端像服務器發起請求時會生成一段請求報文，請求報文是由請求方法，URL，協議版本，可選的請求首部字段和內容實體構成。
請求報文
接收到請求的服務器，會將請求內容的處理結構以響應的形式返回。響應報文基本上由協議版本，狀態碼，用以解釋狀態的原因短語，可選的響應首部字段以及實體主體構成。
響應報文
HTTP 是不保存狀態的協議和 Cookie 的簡單介紹
HTTP 協議對于發送的請求和響應不做持久化處理。這時候引入了 Cookie 技術用于狀態管理。Cookie 對用與登錄的狀態管理，沒有 Cookie 這個技術的話，因為 HTTP 不保存狀態，每次打開新網頁都必須再次登錄。
Cookie 會根據響應報文中的 Set-Cookie 字段來通知客戶端自動保存 Cookie。下次請求時會自動發送 Cookie，服務器會比對數據得到狀態結果。
先引入副作用和冪等的概念。
副作用指對服務器上的資源做改變，搜索是無副作用的，注冊是副作用的。
冪等指發送 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 的幾次握手和加密解密的運算處理，但是加密解密的運算處理已經可以通過特有的硬件來加速處理。
