確認過眼神，看清HTTP協(xié)議
掃描二維碼
隨時隨地手機看文章
導讀：什么是 HTTP？它有什么屬性？我們常用的是什么呢？快來閱讀本文，將會為你一一道來。
什么是 HTTP 協(xié)議？
在了解HTTP之前，我們需要了解什么是網(wǎng)絡(luò)通信模型(也就是我們常說的 OSI 模型)
OSI 模型
OSI 模型是對網(wǎng)絡(luò)中數(shù)據(jù)是如何被傳送和接收的一個具象化的展示，如下圖展示
在 OSI 中我們所處在最頂層，我們所有的網(wǎng)絡(luò)的行為，數(shù)據(jù)的傳遞都是從頂至下然后在從下至頂完成一次傳遞的。每一層都會有對應(yīng)的一些協(xié)議，協(xié)議就好比是數(shù)據(jù)的 '通行證'，有些協(xié)議會把我們的數(shù)據(jù)加密，讓它更安全，有些協(xié)議幫助數(shù)據(jù)建立通道，指明去路。而我們這次要說的 HTTP 協(xié)議屬于應(yīng)用層中的協(xié)議，它的主要作用就是傳遞資源，建立通道讓我們更加方便的去訪問網(wǎng)絡(luò)資源。資源必須是通過 URL 地址可以訪問到的，包括但不限于圖片，數(shù)據(jù)，文件等等。
HTTP屬性
我們已經(jīng)知道了 HTTP 協(xié)議在 OSI 中的位置以及功能。那么現(xiàn)在我們就來看看它神秘面紗下的樣子吧。
HTTP結(jié)構(gòu)
我們稱呼 HTTP 內(nèi)容為報文，一個 HTTP 由請求報文和響應(yīng)報文組成，最方便的報文查看就是瀏覽器開發(fā)者工具的 Network 這一項
以上是訪問 https://hellogithub.com/ 后查看到的請求報文 (Request Headers) 和響應(yīng)報文(Response Headers)。完整的請求就是客戶端發(fā)送請求，服務(wù)器返回響應(yīng)，關(guān)閉連接
請求和響應(yīng)的格式長得差不多，它們都是由：
?一條初始行?零或多條頭信息?一個空行?一個可選的消息體組成的
那么現(xiàn)在讓我們進一步分析所展示的數(shù)據(jù)吧
General 內(nèi)容展示的是通用頭
Request Url: 請求地址 (目前資源所在的地址)
Request Method: 請求方法，請求方法是使用 HTTP 動詞來對目標資源進行操作，常用的請求方法有如下7種
1.GET：用于請求訪問已被url識別的資源，可以通過url傳參給服務(wù)器2.POST：用于傳輸信息給服務(wù)器3.PUT：傳輸文件，報文體中包含文件內(nèi)容，保存在對應(yīng)的url位置4.HEAD：獲得報文首部，與GET方法相似，只是不返回報文主體，一般用于驗證一個內(nèi)容是否正常存在，或者url是否有效5.OPTIONS：返回服務(wù)器可用的方法（請求方法）6.TRACE：查看http協(xié)議有沒被修改。7.DELETE ：刪除對應(yīng)url位置的文件
Status Code: 狀態(tài)碼，不同的狀態(tài)碼代表不同情況，如下羅列一些常用狀態(tài)碼
?1 開頭的狀態(tài)碼代表信息響應(yīng)?2 開頭表示請求的成功，常見有：200?3 開頭的狀態(tài)嗎表示重定向，常見有：304?4 開頭的狀態(tài)碼表示客戶端的響應(yīng)，常見有：404( Not Found )?5 開頭的狀態(tài)碼則代表服務(wù)端的響應(yīng)，常見有：500( 服務(wù)器器遇到了問題 )
如果過需要了解詳細 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status
Remote Address: 遠程地址，這個地址代表的是服務(wù)器所在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(代表服務(wù)器的響應(yīng)信息)
Connection: keep-alive，這個 header 表示客戶端和服務(wù)器在一次請求和響應(yīng)之后不要關(guān)閉連接
但是為什么要使用這個頭部呢？原因是在早期的 HTTP 1.0中，每發(fā)出一個請求都要創(chuàng)建一個連接，但是創(chuàng)建連接的過程是一個損耗資源的過程，所以在后期的 HTTP/1.0 以及 HTTP/1.1 中引入了重用連接機制，需要添加該請求頭，而在 HTTP/1.1 中已經(jīng)默認是長連接了。
Content-Encoding: gzip，這個 header ****主要是設(shè)置數(shù)據(jù)壓縮，在 Web 應(yīng)用中我們通常都要打開gzip壓縮，這樣使得我們的數(shù)據(jù)體積更小，所占用的帶寬也更小所以達到了性能優(yōu)化的目的
Content-type: text/html; charset=utf-8，這個 header 表明了資源類型，因為我們訪問的是網(wǎng)頁所以類型便是 text-html 而我們設(shè)置的編碼是 utf-8
Date: 表示報文創(chuàng)建的日期
Server: nginx，這個 header 表明服務(wù)器類型，nginx 說明使用了代理服務(wù)器，也許并不是應(yīng)用真正的服務(wù)器類型
Set-Cookie: 被用來服務(wù)端向客戶端設(shè)置 cookie
Strict-Transport-Security: 這是一個安全設(shè)置，表示只有 HTTPS (一種加密的 HTTP 協(xié)議，通常可以代替第6層 OSI 模型的功能)才能訪問
Transfer-Encoding: 消息首部指明了將 entity 安全傳遞給用戶所采用的編碼形式。chunked表示數(shù)據(jù)以一系列分塊的形式進行發(fā)送
Request Headers(代表客戶端請求信息)
Accept: 請求頭用來告知客戶端可以處理的內(nèi)容類型，這種內(nèi)容類型用MIME類型來表示。借助內(nèi)容協(xié)商機制, 服務(wù)器可以從諸多備選項中選擇一項進行應(yīng)用，并使用 Content-Type 應(yīng)答頭通知客戶端它的選擇
Accept-Encoding: 會將客戶端能夠理解的內(nèi)容編碼方式——通常是某種壓縮算法——進行通知。通過內(nèi)容協(xié)商的方式，服務(wù)端會選擇一個客戶端提議的方式，使用并在響應(yīng)報文首部 Content-Encoding 中通知客戶端該選擇。
Accept-Language: 請求頭允許客戶端聲明它可以理解的自然語言，以及優(yōu)先選擇的區(qū)域方言。
Cashe-Control: 設(shè)置緩存
Cookie: 客戶端傳遞的 cookie
User-Agent: 表明客戶端一些基本設(shè)備信息
結(jié)語
本文中我們學習了 OSI 模型，知道了 HTTP 協(xié)議是在模型的那一層，知道了一個完整的HTTP請求是怎么樣的，然后通過 Chrome DevTools 分析了一個完整的 HTTP 請求，我們知道了常用的請求方法，常用的網(wǎng)絡(luò)狀態(tài)碼，響應(yīng)頭以及請求頭，還有一些常用到的 header。但是本文介紹的只是HTTP中的一小部分，還有很多有用的 header 等待我們?nèi)グl(fā)現(xiàn)，以及還有 HTTP 2.0 版本的激動人心的新特性。
下載文檔
