確認過眼神，看清 HTTP 協議
導讀：什么是 HTTP？它有什么屬性？我們常用的是什么呢？快來閱讀本文，將會為你一一道來，
一、什么是 HTTP 協議？
在了解HTTP之前，我們需要了解什么是網路通信模型(也就是我們常說的 OSI 模型)
1.1 OSI 模型
OSI 模型是對網路中資料是如何被傳送和接收的一個具象化的展示，如下圖展示
在 OSI 中我們所處在最頂層，我們所有的網路的行為，資料的傳遞都是從頂至下然后在從下至頂完成一次傳遞的，每一層都會有對應的一些協議，協議就好比是資料的 '通行證'，有些協議會把我們的資料加密，讓它更安全，有些協議幫助資料建立通道，指明去路，而我們這次要說的 HTTP 協議屬于應用層中的協議，它的主要作用就是傳遞資源，建立通道讓我們更加方便的去訪問網路資源，資源必須是通過 URL 地址可以訪問到的，包括但不限于圖片，資料，檔案等等，
二、HTTP屬性
免費領取Python自動化學習資料 工具，面試寶典面試技巧，加QQ群，785128166，群內還會大佬技術交流
我們已經知道了 HTTP 協議在 OSI 中的位置以及功能，那么現在我們就來看看它神秘面紗下的樣子吧，
2.1 HTTP結構
我們稱呼 HTTP 內容為報文，一個 HTTP 由請求報文和回應報文組成，最方便的報文查看就是瀏覽器開發者工具的 Network 這一項
以上是訪問 hellogithub.com/ 后查看到的請求報文 (Request Headers) 和回應報文(Response Headers)，完整的請求就是客戶端發送請求，服務器回傳回應，關閉連接
請求和回應的格式長得差不多，它們都是由：
- 一條初始行
- 零或多條頭資訊
- 一個空行
- 一個可選的訊息體組成的
那么現在讓我們進一步分析所展示的資料吧
三、General 內容展示的是通用頭
Request Url: 請求地址 (目前資源所在的地址)
Request Method: 請求方法，請求方法是使用 HTTP 動詞來對目標資源進行操作，常用的請求方法有如下7種
- GET：用于請求訪問已被url識別的資源，可以通過url傳參給服務器
- POST：用于傳輸資訊給服務器
- PUT：傳輸檔案，報文體中包含檔案內容，保存在對應的url位置
- HEAD：獲得報文首部，與GET方法相似，只是不回傳報文主體，一般用于驗證一個內容是否正常存在，或者url是否有效
- OPTIONS：回傳服務器可用的方法（請求方法）
- TRACE：查看http協議有沒被修改，
- DELETE ：洗掉對應url位置的檔案
Status Code: 狀態碼，不同的狀態碼代表不同情況，如下羅列一些常用狀態碼
- 1 開頭的狀態碼代表資訊回應
- 2 開頭表示請求的成功，常見有：200
- 3 開頭的狀態嗎表示重定向，常見有：304
- 4 開頭的狀態碼表示客戶端的回應，常見有：404( Not Found )
- 5 開頭的狀態碼則代表服務端的回應，常見有：500( 服務器器遇到了問題 )
如果過需要了解詳細 developer.mozilla.org/zh-CN/docs/…
Remote Address: 遠程地址，這個地址代表的是服務器所在IP地址
Refer Policy: 這是用來監管哪些訪問來源資訊，no-referrer-when-downgrade (默認值)，意思是在沒有指定任何策略的情況下用戶代理的默認行為，在同等安全級別的情況下，參考頁面的地址會被發送( HTTPS->HTTPS )，但是在降級的情況下不會被發送 ( HTTPS->HTTP )，
具體請查看—> developer.mozilla.org/zh-CN/docs/…
四、Response Headers(代表服務器的回應資訊)
Connection：keep-alive，這個 header 表示客戶端和服務器在一次請求和回應之后不要關閉連接
但是為什么要使用這個頭部呢？原因是在早期的 HTTP 1.0中，每發出一個請求都要創建一個連接，但是創建連接的程序是一個損耗資源的程序，所以在后期的 HTTP/1.0 以及 HTTP/1.1 中引入了重用連接機制，需要添加該請求頭，而在 HTTP/1.1 中已經默認是長連接了，
Content-Encoding：gzip，這個 header ****主要是設定資料壓縮，在 Web 應用中我們通常都要打開gzip壓縮，這樣使得我們的資料體積更小，所占用的帶寬也更小所以達到了性能優化的目的
Content-type：text/html; charset=utf-8，這個 header 表明了資源型別，因為我們訪問的是網頁所以型別便是 text-html 而我們設定的編碼是 utf-8
Date：表示報文創建的日期
Server：nginx，這個 header 表明服務器型別，nginx 說明使用了代理服務器，也許并不是應用真正的服務器型別
Set-Cookie: 被用來服務端向客戶端設定 cookie
Strict-Transport-Security：這是一個安全設定，表示只有 HTTPS (一種加密的 HTTP 協議，通常可以代替第6層 OSI 模型的功能)才能訪問
Transfer-Encoding：訊息首部指明了將 entity 安全傳遞給用戶所采用的編碼形式，chunked表示資料以一系列分塊的形式進行發送
五、Request Headers(代表客戶端請求資訊)
Accept: 請求頭用來告知客戶端可以處理的內容型別，這種內容型別用MIME型別來表示，借助內容協商機制, 服務器可以從諸多備選項中選擇一項進行應用，并使用 Content-Type 應答頭通知客戶端它的選擇
Accept-Encoding: 會將客戶端能夠理解的內容編碼方式——通常是某種壓縮演算法——進行通知，通過內容協商的方式，服務端會選擇一個客戶端提議的方式，使用并在回應報文首部 Content-Encoding 中通知客戶端該選擇，
Accept-Language: 請求頭允許客戶端宣告它可以理解的自然語言，以及優先選擇的區域方言，
Cashe-Control: 設定快取
Cookie: 客戶端傳遞的 cookie
User-Agent: 表明客戶端一些基本設備資訊
六、結語
本文中我們學習了 OSI 模型，知道了 HTTP 協議是在模型的那一層，知道了一個完整的HTTP請求是怎么樣的，然后通過 Chrome DevTools 分析了一個完整的 HTTP 請求，我們知道了常用的請求方法，常用的網路狀態碼，回應頭以及請求頭，還有一些常用到的 header，（免費領取Python自動化學習資料 工具，面試寶典面試技巧，加QQ群，785128166，群內還會大佬技術交流）但是本文介紹的只是HTTP中的一小部分，還有很多有用的 header 等待我們去發現，以及還有 HTTP 2.0 版本的激動人心的新特性，下面給大家安利一個常用網站 developer.mozilla.org/zh-CN/ （MDN）如果你是 Web 開發者千萬不要錯過，這個網站囊括了關于 Web 開發全路線教程，
最后祝愿大家每天早下班，代碼無Bug，迎娶白富美，走向人生巔峰
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/53201.html
標籤：Python