導讀：什么是 HTTP？它有什么屬性？我們常用的是什么呢？快來閱讀本文，將會為你一一道來。

什么是 HTTP 協(xié)議？

在了解HTTP之前，我們需要了解什么是網絡通信模型(也就是我們常說的 OSI 模型)

OSI 模型

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

在 OSI 中我們所處在最頂層，我們所有的網絡的行為，數據的傳遞都是從頂至下然后在從下至頂完成一次傳遞的。每一層都會有對應的一些協(xié)議，協(xié)議就好比是數據的 '通行證'，有些協(xié)議會把我們的數據加密，讓它更安全，有些協(xié)議幫助數據建立通道，指明去路。而我們這次要說的 HTTP 協(xié)議屬于應用層中的協(xié)議，它的主要作用就是傳遞資源，建立通道讓我們更加方便的去訪問網絡資源。資源必須是通過 URL 地址可以訪問到的，包括但不限于圖片，數據，文件等等。

HTTP屬性

我們已經知道了 HTTP 協(xié)議在 OSI 中的位置以及功能。那么現(xiàn)在我們就來看看它神秘面紗下的樣子吧。

HTTP結構

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

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

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

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

那么現(xiàn)在讓我們進一步分析所展示的數據吧

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協(xié)議有沒被修改。7.DELETE ：刪除對應url位置的文件

Status Code: 狀態(tài)碼，不同的狀態(tài)碼代表不同情況，如下羅列一些常用狀態(tài)碼

?1 開頭的狀態(tài)碼代表信息響應?2 開頭表示請求的成功，常見有：200?3 開頭的狀態(tài)嗎表示重定向，常見有：304?4 開頭的狀態(tài)碼表示客戶端的響應，常見有：404( Not Found )?5 開頭的狀態(tài)碼則代表服務端的響應，常見有：500( 服務器器遇到了問題 )

如果過需要了解詳細 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

Remote Address: 遠程地址，這個地址代表的是服務器所在IP地址

Refer Policy: 這是用來監(jiān)管哪些訪問來源信息，no-referrer-when-downgrade (默認值)，意思是在沒有指定任何策略的情況下用戶代理的默認行為。在同等安全級別的情況下，引用頁面的地址會被發(fā)送( HTTPS->HTTPS )，但是在降級的情況下不會被發(fā)送 ( HTTPS->HTTP )。

具體請查看—> https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Referrer-Policy

Response Headers(代表服務器的響應信息)

Connection: keep-alive，這個 header 表示客戶端和服務器在一次請求和響應之后不要關閉連接

但是為什么要使用這個頭部呢？原因是在早期的 HTTP 1.0中，每發(fā)出一個請求都要創(chuàng)建一個連接，但是創(chuàng)建連接的過程是一個損耗資源的過程，所以在后期的 HTTP/1.0 以及 HTTP/1.1 中引入了重用連接機制，需要添加該請求頭，而在 HTTP/1.1 中已經默認是長連接了。

Content-Encoding: gzip，這個 header ****主要是設置數據壓縮，在 Web 應用中我們通常都要打開gzip壓縮，這樣使得我們的數據體積更小，所占用的帶寬也更小所以達到了性能優(yōu)化的目的

Content-type: text/html; charset=utf-8，這個 header 表明了資源類型，因為我們訪問的是網頁所以類型便是 text-html 而我們設置的編碼是 utf-8

Date: 表示報文創(chuàng)建的日期

Server: nginx，這個 header 表明服務器類型，nginx 說明使用了代理服務器，也許并不是應用真正的服務器類型

Set-Cookie: 被用來服務端向客戶端設置 cookie

Strict-Transport-Security: 這是一個安全設置，表示只有 HTTPS (一種加密的 HTTP 協(xié)議，通常可以代替第6層 OSI 模型的功能)才能訪問

Transfer-Encoding: 消息首部指明了將 entity 安全傳遞給用戶所采用的編碼形式。chunked表示數據以一系列分塊的形式進行發(fā)送

Request Headers(代表客戶端請求信息)

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

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

Accept-Language: 請求頭允許客戶端聲明它可以理解的自然語言，以及優(yōu)先選擇的區(qū)域方言。

Cashe-Control: 設置緩存

Cookie: 客戶端傳遞的 cookie

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

結語

本文中我們學習了 OSI 模型，知道了 HTTP 協(xié)議是在模型的那一層，知道了一個完整的HTTP請求是怎么樣的，然后通過 Chrome DevTools 分析了一個完整的 HTTP 請求，我們知道了常用的請求方法，常用的網絡狀態(tài)碼，響應頭以及請求頭，還有一些常用到的 header。但是本文介紹的只是HTTP中的一小部分，還有很多有用的 header 等待我們去發(fā)現(xiàn)，以及還有 HTTP 2.0 版本的激動人心的新特性。