theme: smartblue

什麼是HTTP、其基本特點

輸入開啟一個網址後發生了什麼

主要學習發起請求→讀取響應這一階段

主要學習應用層

什麼是HTTP協議

1. Hyper Text Transfer Protocol 超文字傳輸協議

HTTP協議能承載很多型別的文字：HTML CSS JS Web APIs

2. 應用層協議，基於TCP協議

HTTP是應用層的協議，基於傳輸層的TCP協議，TCP是一個可靠的協議

3. 請求-響應

HTTP是一個C/S模型的協議

4. 簡單可擴充套件

協議頭舉例：

在協議頭裡可以增加一些內容，可擴充套件

5. 無狀態

協議對於互動性場景沒有記憶能力。在新請求來的時候，伺服器是無法記住上一個請求來自哪裡的

協議分析（報文結構、發展歷程）

發展

| 協議 | 關鍵點 | 特點 | | --- | --- | --- | | HTTP/0.9 |單行協議| ✔ 請求GET/mypage.html
✔ 響應只有HTML文件| | HTTP/1.0 | 構建可擴充套件性 |✔ 增加了Header
✔ 有了狀態碼
✔ 支援多種文件型別 | | HTTP/1.1 | 標準化協議 | ✔ 連結複用
✔ 快取
✔ 內容協商
| | HTTPS | | | | HTTP/2 | 更優異的表現（資料傳輸、功能增強） | ✔ 二進位制協議
✔ 壓縮header
✔ 伺服器推送 | | HTTP/3 | 草案 | |

HTTP/1.1報文解析

1. 案例

請求和響應的結構一致

案例1：

案例2：

構成： - 起始行（請求/響應行）：Request：Method Path Version | Responses: Version StatusCode StatusMessage - headers（請求/響應頭）資訊協議頭 - 空行分割 - 實體資料部分（請求/響應體）（瀏覽器提交上去的資訊/服務端返回的資訊）

2. HTTP報文Method方法

| Method | 描述 | | --- | --- | |GET|從伺服器中請求一個指定資源，該method只被用於獲取資料| |HEAD|請求一個與GET請求的響應相同的響應，但只從伺服器獲取文件的響應首部| |POST|將實體提交到指定的資源（向伺服器輸入資料），通常導致在伺服器上的狀態變化或副作用| |PUT|用請求有效載荷替換目標資源的所有當前表示（將請求的主體部分儲存在伺服器中，如上傳檔案）| |DELETE|請求刪除伺服器上指定的資源| |TRACE|沿著到目標資源的路徑執行一個訊息環回測試（追蹤請求到達伺服器中間經過的代理伺服器）| |OPTIONS|用於描述目標資源的通訊選項（請求伺服器返回對指定資源支援使用的請求方法）| |CONNECT|建立一個到由目標資源標識的伺服器的隧道| |PATCH|用於對資源應用部分修改|

Methond - Safe（安全的）： GET HEAD OPTIONS
不會修改伺服器的資料的方法 - Idempotent（冪等）：GET HEAD OPTIONS PUT DELETE
同樣的請求被執行一次與被執行多次的效果是一樣的，伺服器的狀態也是一樣的， - 所有safe的方法都是Idempotent的，所有安全的請求都不會修改伺服器的資料，因此所有安全的請求都是冪等的。

3. 狀態碼

注： 301表示永久重定向，302表示暫時重定向，304表示資源沒有修改

4. RESTful API

RESTful API： 一種API設計風格；REST-Representational State Transfer - 每個URI代表一種資源； - 客戶端和伺服器之間，傳遞這種資源的某種表現層； - 客戶端通過HTTP method，對伺服器端資源進行操作，實現“表現層狀態轉化”。 案例：

5. 常用請求頭

| 請求頭 | 描述 | | --- | --- | |Accept|接收型別，表示瀏覽器支援的MIME型別（對標服務端返回的Content-Type）| |Content-Type|客戶端傳送出去實體內容的型別| |Cache-control|指定請求和響應遵循的快取機制，如no-cache| |If-Modified-Since |對應服務端的last-midified，用來匹配看檔案是否變動，只能精確到1s之內| |Expires|快取控制，在這個時間內不會請求，直接使用快取，服務端時間| |Max-age|代表資源在本地快取多少秒，有效時間內不會請求，而是使用快取| |If-None-Match|對應服務端的Etag，用來匹配檔案內容是否改變（非常精確）| |Cookie|有cookie並且同域訪問時會自動帶上| |Referer|該頁面的來源URL（適用於所以型別的請求，會精確到詳細頁面地址，csrf攔截常用到這個欄位）| |Origin|最初的請求是從哪裡發起的（只會精確到埠），Origin比Referer更尊重隱私| |Uer-Agent|使用者客戶端的一些必要資訊，如UA頭部|

快取相關

6. 常用響應頭

| 響應頭 | 描述 | | --- | --- | |Content-Type|服務端返回的實體內容的型別（WEB伺服器告訴瀏覽器自己響應的物件的型別和字符集）| |Cache-Control| 指定請求和響應遵循的快取機制，如no-cache| |Last-Modified|請求資源的最後修改時間| |Expires| 應該在什麼時候認為文件已經過期，從而不再快取它，重新從伺服器獲取，會更新快取 | |Max-age| 客戶端的本地資源應該快取多少秒，開啟了Cache-Control後有效 | |ETag| 根據文件實體資訊內容生成的，是資源的特定版本的識別符號，類似於指紋，和If-None-Match 配合使用 | |Set-Cookie| 設定和頁面關聯的cookie，伺服器通過這個頭部把cookie傳給客戶端| |Server| HTTP伺服器的相關資訊。例如：Server: Microsoft-IIS/7.5、Server：Apache-Coyote/1.1。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。| |Access-Control-Allow-Origin|伺服器端允許的請求Origin頭部（譬如為*）指定哪些網站可以跨域源資源共享|

快取相關

7. 快取

快取相關頭部：

| 強快取 | 協商快取 | | --- | --- | |在快取有效期內，一定要使用本地資源|每個請求都有一個請求-響應的過程，快取每次都需要C/S彼此認證商量一下，有個溝通的過程。協商快取相關頭部成對出現。| | Expires： 時間不準
Cache-Control：
1. max-age：快取時間計算的方式是距離發起時間的秒數，超過間隔的秒數快取失效。
2. no-cache：不使用強快取，需要與伺服器驗證快取是否新鮮。
3. no-store：禁止使用快取（包括協商快取），每次都向伺服器請求最新的資源。
4. must-revalidate：在快取過期前可以使用，過期後必須向伺服器驗證。 |ETag/if-None-Match，hash碼，代表的是一個資源的識別符號。
Last-Modified/If-Modified-Since，檔案的最後修改時間。|

瀏覽器判斷快取的過程：

注：請求狀態碼為200，不一定會發起一個真實的請求，有可能是一個本地的強快取。

8.cookie

Cookie幫助實現了http無狀態的協議，也增強了一些與狀態相關的特性。 - HTTP請求報文通過cookie欄位通知服務端當前頁面的域生效中的cookie - HTTP響應報文通過Set-cookie通知客戶端需要儲存哪些的cookie。響應頭裡set-cookie設定哪些資訊： | 鍵值對 | 描述 | | --- | --- | | Name=value | 各種cookie的名稱和值 | | Expire=Date | Cookie的有效期，預設Cookie僅在瀏覽器關閉前有效（控制相關） | | Path=Path | 限制指定Cookie的傳送範圍的檔案目錄，預設為當前（生效的目錄範圍） | | Domain=Domain | 限制cookie生效的域名，預設為建立cookie的服務域名（域名） | | secure | 僅在安全連線時，才可以傳送Cookie | | HttpOnly | js指令碼有相關API操作cookie，可能會導致一些cookie洩露風險，設定HttpOnly使得js指令碼無法獲得Cookie（安全相關）| | SameSite[None|Strict|Lax(預設)|] | None同站、跨站請求都可以傳送
Strict僅在同站傳送
允許與頂級導航一起傳送，並將與第三方網站發起的GET請求一起傳送 |

發展-HTTP/2與HTTPS

HTTP/2:更快、更穩定、更簡單

新特性1：

幀：HTTP/2通訊的最小單位，每個幀都包含幀頭，至少也會標識出當前幀所屬的資料流。
二進位制傳輸，資料壓縮，降低包體積。

新特性2：

訊息：（與邏輯請求或響應訊息對應的完整的）一系列幀的聚合。
資料流：已建立的連線內的雙向位元組流，可以承載一條或多條訊息。
交錯傳送，接受方重組織。

新特性3：

HTTP/2連線都是永久的，而且僅需要每個來源一個連線。
流控制：阻止傳送方向接收方傳送大量資料的機制。
伺服器推送：

HTTPS

###### HTTPS：Hypertext Transfer Protocol Secure - 經過TSL/SSL加密

##### 加密： - 對稱加密：加密和解密都是使用同一個金鑰 - 非對稱加密：加密和解密需要使用兩個不同的金鑰（公鑰（public key）和私鑰（private key））

場景分析

靜態資源

1. 案例：

2. 靜態資源方案：快取+CDN+檔名hash

快取：通過協議頭的設定，使得資源優先從本地讀取，響應時間很快。
CDN：Content Delivery Network 內容分發網路，通過使用者就近性和伺服器負載的判斷，CDN確保內容以一種極為高效的方式請求提供服務。

登陸

Request Headers: c++ :authority:sso.toutiao.com//地址 :method:POST//動作：POST :path:/quick_login/v2/?aid=24&account_sdk_source=sso&language=zh :scheme:https accept:application/json, text/javascript//想收到的是json格式 accept-encoding:gzip, deflate, br accept-language:zh-CN,zh;q=0.9 content-length:117 content-type:application/x-www-form-urlencoded//攜帶實體資訊型別：form 關聯form data cookie:_S_DPR=1; _S_IPAD=0; _S_WIN_WH=1366_625; ttwid=1%7CvYS_NyRV1Ai9vQseqGzuvE1tZC9HRh0FJIkopl7L_bw%7C1630417245%7C13945c885fd479252cc9b7b0a8db451fc0accedd0ed9a70a3ab599e3f3aa3fa0; passport_csrf_token_default=1b574667f3040e78ca76c4c30363806f; passport_csrf_token=1b574667f3040e78ca76c4c30363806f; MONITOR_WEB_ID=74dbd20c-75a9-4373-b1eb-79d08315118f; s_v_web_id=verify_kt05zmwq_0ZZp9KvV_Cklo_4Rpt_8SvP_C9rXaRkL4LSF origin: http://sso.toutiao.com//請求來源 referer:http://sso.toutiao.com/login/ //請求來源 sec-ch-ua:"Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92" sec-ch-ua-mobile:?0 sec-fetch-dest:empty sec-fetch-mode:cors sec-fetch-site: same-origin user-agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 //Chrome瀏覽器 x-tt-passport-csrf-token: 1b574667f3040e78ca76c4c30363806f //新增的自定義協議，防止csrf攻擊http是可擴充套件的協議 1630420618(1).jpg

Response Headers：有很多set-cookie: c++ content-encoding: gzip content-length:198 content-type: application/json //資料格式為json set-cookie:passport_auth_status=2c38778eef31cd8c6efdddebef79ba1f%2C; Path=/; Domain=toutiao.com; Max-Age=2592000; HttpOnly//種在toutiao.com根域名下有效期2592000s 禁止js去獲取 set-cookie: passport_auth_status_ss=2c38778eef31cd8c6efdddebef79ba1f%2C; Path=/; Domain=toutiao.com; Max-Age=2592000; HttpOnly; Secure; SameSite=None set-cookie: sso_auth_status=d892c172d477b9d8f53e3a6229285dd8; Path=/; Domain=toutiao.com; Max-Age=2592000; HttpOnly set-cookie:sso_auth_status_ss=d892c172d477b9d8f53e3a6229285dd8; Path=/; Domain=toutiao.com; Max-Age=2592000; HttpOnly; Secure; SameSite=None set-cookie: sso_uid_tt=b2ab94b926277554cef74291a1e23935; Path=/; Domain=toutiao.com; Max-Age=5184000; HttpOnly set-cookie:sso_uid_tt_ss=b2ab94b926277554cef74291a1e23935; Path=/; Domain=toutiao.com; Max-Age=5184000; HttpOnly; Secure; SameSite=None set-cookie:toutiao_sso_user=893aaca56a87090a729ad0eede82e55c; Path=/; Domain=toutiao.com; Max-Age=5184000; HttpOnly set-cookie:toutiao_sso_user_ss=893aaca56a87090a729ad0eede82e55c; Path=/;Domain=toutiao.com; Max-Age=5184000; HttpOnly; Secure; SameSite=None set-cookie:n_mh=BeOyQzO-cLr1SIXI014bhcrMEP81myfFv6SWp805Fpc; Path=/; Domain=toutiao.com; Max-Age=10368000; HttpOnly timing-allow-origin: * vary:Accept-Encoding via:vcache6.cn2586[317,0] x-janus-mini-api-forward:Janus-Mini(fast) x-tt-logid: 202108312229170102121380514845D63E

1. 向什麼地址做了什麼動作？ - 使用POST方法 - 目標域名：http://sso.toutiao.com - 目標：path:/quick_login/v2 2. 攜帶了哪些資訊，返回了哪些資訊？ - 攜帶資訊 - Post body，資料格式為form。 - 希望獲取的資料格式為json。 - 已有的cookie - 返回資訊 - 資料格式json - 多種cookie的資訊

3. 下一次進入頁面為什麼能記住登入態呢？(cookie與token) - Session+cookie - Session是服務端生成的使用者的唯一標記，服務端解析後即可知是哪個使用者，進而返回使用者相關資訊。 - JWT（JSON web token） - token沒有儲存在cookie裡，客戶端發起GET請求時不能自動帶上，需要操作請求本身把token放到合適位置，進而傳送給服務端。 - 場景：三方認證

富媒體

1. 影片播放

- 狀態碼：206代表Partial Content，返回的是部分的資源，播放暫停和拖動影片進度條的過程中，會一直髮起請求，這些請求都是整個影片資源的一部分。 - 如何決定當前返回的影片資源是整個資源的哪一部分？： Request Headers: range；Response: Content-Range - 漸進式播放 - 影片直播協議

2. 檔案上傳

如果你的頁面需要支援圖片上傳該怎麼做？→ Form表單提交
如果你的頁面需要支援影片上傳該怎麼做？ → 資源大，上傳時間可能很長，利用一個請求，一旦失敗需要重頭開始 → web檔案上傳的解決方案

實際應用（瀏覽器、node中的使用）

參考

http://www.cnblogs.com/lauhp/p/8979393.html

http://www.cnblogs.com/brxHqs/p/11671968.html

【青訓營】- 前端開發HTTP實用指南