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

語言: CN / TW / HK

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,不一定會發起一個真實的請求,有可能是一個本地的強快取。 image.png

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. 影片播放

image.png

image.png

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

2. 檔案上傳

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

實際應用(瀏覽器、node中的使用)

參考

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

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