HTTP協議那些事

HTTP請求模型

上圖描述的http最最最基本的一個概況

• 兩個端：客戶端 和 服務端
• 兩個動做：
  • 客戶端向服務端發起請求(request)
  • 服務端對客戶端進行響應(response)

http協議是一種無狀態協議，它維持不住當前的通訊狀態。 即：客戶端發起請求，服務端響應，這就結束了，這是獨立的一次輪迴，若是想再請求，那麼就會再來一次 請求響應，這兩次輪迴是相互獨立的，互不影響。

瀏覽器行爲與http協議

處理流程：

1. 輸入網址並回車
2. 解析域名
3. 瀏覽器發送http請求
4. 服務器處理請求
5. 服務器返回http響應
6. 瀏覽器處理html頁面
7. 繼續請求其餘資源

總結：

第一步 用戶在瀏覽器輸入網址，對瀏覽器發號指令，帶我去google.com,這樣瀏覽器就接受到了這個指令。

第二步 瀏覽器檢查網絡是否通暢，在局域網中，向防火牆或者家用路由器或者網關，提交密碼，翻出牆外。這裏所說的牆內就是咱們的局域網，牆外則是互聯網。

第三步 google.com這是一個字符串，瀏覽器是不認識這個字符串的 它須要把這個字符串轉化爲 IP地址，這個時候它就去請問 DNS 服務器 ，找到對應的IP地址（Ipv4協議）。google.com至關因而一個名字,除了你本身沒人知道具體地址在哪，而IP地址則是一個具體的門牌號，這樣瀏覽器就知道往哪走了。

第四步 知道了地址，就能夠上路了，這裏並非 直接過去的，它須要多個路由的轉發，相似於快遞的運送

第五步 瀏覽器順着網線 終於到了google的服務器對應的地址。可是這個地址上有不少的服務器。也就是圖4上描述的一棵樹上站了不少只鳥🐦。一隻鳥🐦就表明一個服務器，也就是說這麼多服務器有一個共同的出口，即這個ip地址，這些服務器怎麼公用了一個ip地址這就涉及到了反向代理，後續解釋。反向代理幫你指定到你想要訪問的服務器，到此爲止，request請求就結束了

第六步 服務器處理請求，處理業務邏輯，處理完的數據返回給瀏覽器，這個過程就是response。

最後 瀏覽器將得到的數據 進行一系列的處理 整合渲染以後返回給用戶

什麼是HTTP協議

HTTP是超文本傳輸協議，從www瀏覽器傳輸到本地瀏覽器的一種傳輸協議，網站是基於HTTP協議的，例如網站的圖片、css、js等都是基於http協議進行傳輸的

http協議是由從客戶端到服務器的請求和從服務器到客戶端的響應進行的約束和規範，你們須要遵照的一種規範

http 協議主要是經過 request請求和 response 這兩個動做進行約束的

瞭解TCP/IP協議棧

協議棧是分層的 下圖中 左圖爲 ISO/OSI 協議 這是一種建議規範 右圖爲TCP/IP協議 這是一種事實協議

1. 應用層 爲用戶提供所須要的各類服務，例如：HTTP、FTP、DNS等等
2. 傳輸層 爲應用層實體提供端到端的通訊功能，保證數據包的順序傳送以及數據的完整性 TCP 傳輸控制協議，維持通訊狀態 UDP 用戶數據報協議
3. 網絡層 分配ip地址，PPP協議，創建通訊鏈路
4. 數據鏈路層 物理層上傳輸的信號
5. 物理層 看到見摸得着的硬件，網線，還有一些看不見摸不着的載體 無線電波

http協議屬於應用層，在TCP/IP協議之上，HTTP協議 與HTTPS協議大部分是相同的，區別在於 https 在應用層中多添加了加密協議，若是按照ISO/OSI協議的話，也就是加在了表示層和會話層中。http默認端口是80，https默認端口是443。

HTTP的工做過程

一次HTTP操做稱爲一個事務

事務是由若干個步驟構成的，這些若干個步驟必須嚴格的按照必定的順序去執行，而且其中的一個步驟失敗了，那麼整個事情就失敗了。

http 操做過程分爲四步：

1. 首先客戶機與服務器須要創建連接(在 TCP層次)。只要點擊某個超級連接，http的工做開始。
2. 創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。 這一步是 http層面上的 request
3. 服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。 這一步是http層面上的response
4. 客戶端接受服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開連接，這一步驟分爲兩層 一層是瀏覽器進行渲染，另外一層面是在TCP層面上與服務器斷開連接

請求和響應

• HTTP請求組成：請求行、消息報頭、請求正文
• HTTP響應組成：狀態行、消息報頭、響應正文
• 請求行組成：以一個方法符號開頭，後面跟着請求的URL和協議的版本。
• 狀態行組成：服務器HTTP協議的版本，服務器返回的響應狀態碼和狀態碼的文本描述

請求

響應

請求方法

• GET 請求獲取Request-URI所標識的資源
• POST 在Request-URI所標識的資源後附加新的數據
• HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
• PUT 請求服務器存儲一個資源，並用Request-URI做爲其標識
• DELETE 請求服務器刪除Request-URI所標識的資源
• TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
• CONNECT HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
• OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

HTTP狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示信息--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操做

4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現

5xx：服務器端錯誤--服務器未能實現合法的請求

經常使用的請求報頭

• Accept請求報頭域用於指定客戶端接受哪些類型的信息。eg：Accept：image/gif，Accept：text/

• htmlAccept-Charset請求報頭域用於指定客戶端接受的字符集。

• Accept-Encoding：Accept-Encoding請求報 頭域相似於Accept，可是它是用於指定可接受的內容編碼。

• Accept-Language請求報頭域相似於Accept，可是它是用於指定一種天然語言。

• Authorization請求報頭域主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服 務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進 行驗證。

• Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的，發 送請求時，該報頭域是必需的。

• User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。

經常使用的響應報頭

• Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域經常使用在更換域名的時候。
• Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。
• WWW-Authenticate響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。

經常使用的實體報頭

請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。實體報頭定義了關於實體正文（eg：有無實體正文）和請求所標識的資源的元信息。

• Content-Encoding實體報頭域被用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，於是要得到Content-Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。
• Content-Language實體報頭域描述了資源所用的天然語言。
• Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示。
• Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。
• Last-Modified實體報頭域用於指示資源的最後修改日期和時間。
• Expires實體報頭域給出響應過時的日期和時間。

關於報頭這篇文章講的很清楚，點此連接

cookies與session

• cookie是保存在客戶端的 而session 是保存在服務端的
• 當客戶端每次發送URL請求時，cookie的內容都會附加在請求頭上
• Session則保存在服務器端，經過惟一的值sessionID來區別每個用戶。SessionID隨每一個鏈接請求發送到服務器，服務器根據sessionID來識別客戶端，再經過session 的key獲取session值。

cookie 的使用

1)Cookie：客戶端將服務器設置的Cookie返回到服務器; 2)Set-Cookie：服務器向客戶端設置Cookie;

服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie 頭中發送給服務器。從而實現會話的保持。

session 的使用

HTTP緩存機制

• 緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：若是是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
• 緩存的優勢：減小相應延遲 減小網絡帶寬消耗

兩種緩存策略；

• Etag/If-None-Match策略
• Last-Modified/If-Modified-Since策略

緩存流程：

https協議分析

• 採用非對稱加密手段，數字證書策略 CA
• HTTPS協議、SSL協議、TLS協議、握手協議的關係
  • HTTPS是Hypertext Transfer Protocol over Secure Socket Layer的縮寫，即HTTP over SSL，可理解爲基於SSL的HTTP協議。HTTPS協議安全是由SSL協議實現的。
  • SSL協議是一種記錄協議，擴展性良好，能夠很方便的添加子協議，而握手協議即是SSL協議的一個子協議
  • TLS協議是SSL協議的後續版本，本文中涉及的SSL協議默認是TLS協議1.2版本

http2 協議分析

• 使用二進制格式傳輸，更高效、更緊湊
• 對報頭壓縮，下降開銷。
• 多路複用，一個網絡鏈接實現並行請求
• 服務器主動推送，減小請求的延遲
• 默認使用加密

瞭解HTTP3

• 由google 創造 原名叫 HTTP-over-QUIC
• 基於 QUIC協議
• HTTP3 不是http2的擴展
• HTTP3 將是一個全新的協議 目前處於測試階段

HTTP與反向代理

正向代理： 客戶端——》局域網內 —proxy—》 互聯網 反向代理： 互聯網 —proxy—》服務器

反向代理的做用：

• 加密和SSL加速
• 負載均衡
• 緩存靜態內容
• 壓縮
• 減速上傳
• 安全
• 外網發佈