確認過眼神，看清 HTTP 協議

導讀：什麼是 HTTP？它有什麼屬性？咱們經常使用的是什麼呢？快來閱讀本文，將會爲你一一道來。

1、什麼是 HTTP 協議？

在瞭解HTTP以前，咱們須要瞭解什麼是網絡通訊模型(也就是咱們常說的 OSI 模型)

1.1 OSI 模型

OSI 模型是對網絡中數據是如何被傳送和接收的一個具象化的展現，以下圖展現

在 OSI 中咱們所處在最頂層，咱們全部的網絡的行爲，數據的傳遞都是從頂至下而後在從下至頂完成一次傳遞的。每一層都會有對應的一些協議，協議就比如是數據的 '通行證'，有些協議會把咱們的數據加密，讓它更安全，有些協議幫助數據創建通道，指明去路。而咱們此次要說的 HTTP 協議屬於應用層中的協議，它的主要做用就是傳遞資源，創建通道讓咱們更加方便的去訪問網絡資源。資源必須是經過 URL 地址能夠訪問到的，包括但不限於圖片，數據，文件等等。

2、HTTP屬性

咱們已經知道了 HTTP 協議在 OSI 中的位置以及功能。那麼如今咱們就來看看它神祕面紗下的樣子吧。

2.1 HTTP結構

咱們稱呼 HTTP 內容爲報文，一個 HTTP 由請求報文和響應報文組成，最方便的報文查看就是瀏覽器開發者工具的 Network 這一項

以上是訪問 hellogithub.com/ 後查看到的請求報文 (Request Headers) 和響應報文(Response Headers)。完整的請求就是客戶端發送請求，服務器返回響應，關閉鏈接

請求和響應的格式長得差很少，它們都是由：

• 一條初始行
• 零或多條頭信息
• 一個空行
• 一個可選的消息體組成的

那麼如今讓咱們進一步分析所展現的數據吧

3、General 內容展現的是通用頭

Request Url: 請求地址 (目前資源所在的地址)

Request Method: 請求方法，請求方法是使用 HTTP 動詞來對目標資源進行操做，經常使用的請求方法有以下7種

1. GET：用於請求訪問已被url識別的資源，能夠經過url傳參給服務器
2. POST：用於傳輸信息給服務器
3. PUT：傳輸文件，報文體中包含文件內容，保存在對應的url位置
4. HEAD：得到報文首部，與GET方法類似，只是不返回報文主體，通常用於驗證一個內容是否正常存在，或者url是否有效
5. OPTIONS：返回服務器可用的方法（請求方法）
6. TRACE：查看http協議有沒被修改。
7. 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/…

4、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表示數據以一系列分塊的形式進行發送

5、Request Headers(表明客戶端請求信息)

Accept: 請求頭用來告知客戶端能夠處理的內容類型，這種內容類型用MIME類型來表示。藉助內容協商機制, 服務器能夠從諸多備選項中選擇一項進行應用，並使用 Content-Type 應答頭通知客戶端它的選擇

Accept-Encoding: 會將客戶端可以理解的內容編碼方式——一般是某種壓縮算法——進行通知。經過內容協商的方式，服務端會選擇一個客戶端提議的方式，使用並在響應報文首部 Content-Encoding 中通知客戶端該選擇。

Accept-Language: 請求頭容許客戶端聲明它能夠理解的天然語言，以及優先選擇的區域方言。

Cashe-Control: 設置緩存

Cookie: 客戶端傳遞的 cookie

User-Agent: 代表客戶端一些基本設備信息

6、結語

本文中咱們學習了 OSI 模型，知道了 HTTP 協議是在模型的那一層，知道了一個完整的HTTP請求是怎麼樣的，而後經過 Chrome DevTools 分析了一個完整的 HTTP 請求，咱們知道了經常使用的請求方法，經常使用的網絡狀態碼，響應頭以及請求頭，還有一些經常使用到的 header。可是本文介紹的只是HTTP中的一小部分，還有不少有用的 header 等待咱們去發現，以及還有 HTTP 2.0 版本的激動人心的新特性。下面給你們安利一個經常使用網站 developer.mozilla.org/zh-CN/ （MDN）若是你是 Web 開發者千萬不要錯過，這個網站囊括了關於 Web 開發全路線教程。

最後祝願你們天天早下班，代碼無Bug，迎娶白富美，走向人生巔峯

公衆號

HelloGitHub 連載三年，GitHub 上已經得到超過 1萬顆 ⭐

關注公衆號加入交流羣，一塊兒討論有趣的技術話題。分享本文給你的朋友們吧！