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