HTTP：資源是怎麼協商、表述的？

網絡協議之因此是叫作協議，而不是規定，就是由於傳輸什麼內容，先後端都得商量着來

客戶端須要什麼，須要告訴服務端；服務端發什麼給客戶端，要看客戶端能不能看懂

那他們又是怎麼商量的呢？之前學習過HTTP協議的同窗確定知道，是根據請求行來進行協商的

而HTTP協議中又是怎麼定義協商內容的呢？協商好以後又該怎麼表述呢？

今天就來聊聊上面的這些個問題，但願個人文字能讓你把這些內容弄清楚

內容協商

在HTTP中，內容協商分爲2種，分別是主動式內容協商與響應式內容協商

以前沒接觸過的童鞋，聽到這些名詞確定是稀裏糊塗的，彆着急，我們一個一個的來

主動式內容協商

千言萬語不如一張圖來的形象，先上張主動式內容協商的過程圖

起點是客戶端(Client)，先看看圖，看不懂不要緊，有個印象就行了。否則接下來我說的內容，對你來講可能就是天書了

這圖猛的一看挺複雜的，花裏胡哨一大堆。其實過程很是簡單

其實就是客戶端發起了一個HTTP1.1的GET請求資源後，服務端返回資源的一個狀況

發起GET請求後，經過Accept、Accept-Language、Accept-Encoding這三個請求頭，客戶端告訴服務器：我如今要一個text/類型的文件，而且我只接受這個文件語言爲en（英語），我這裏能看得懂的編碼格式只有br、gzip格式，q(權重)都是0.8，你（服務器）有哪一種編碼格式隨便給我都行

服務器看到咱們的要求，根據咱們的要求以及請求的URL，就到這個URL裏定位的資源，尋找是否有符合咱們要求的資源

咱們請求的URL在服務器是存在對應文件的，因此告訴咱們狀態碼是200，而且把URLe對應的資源給到了咱們（客戶端）

告訴了咱們這是個text/html文件，語言是en，編碼方式爲br，均是符合咱們上述提出的要求

咱們（客戶端）拿到符合要求的文件，也就能夠正常解析數據了

響應式內容協商

來，我們再來看看什麼是響應式內容協商，仍是老規矩，先上一張圖，韻個味

看懂了以前的主動式內容協商，我相信這張圖你也能看的七七八八。由於區別並不大

區別就在於Client（客戶端）請求了以後，竟然給咱們一個300（重定向），而不是咱們以前的200（OK）

竟然還要咱們再去請求一次，才把URLe的內容給咱們

其實這就是響應式與主動式的區別所在了

在響應式內容協商中，客戶端發送請求，服務器端沒法抉擇要返回什麼內容，因此就把客戶端請求的URL對應的資源列表所有返回，而後由客戶端自行抉擇。客戶端進行選擇後再去訪問指定資源

而由於RFC中沒有明確指出客戶端應該依據怎樣的規則去對資源進行抉擇，因此各大瀏覽器的實現方式都不一致

又由於各大瀏覽器實現方式都不統一，相對來講，用到響應式內容協商的地方就不多了

質量因子

上面有些內容你們若是沒有學過HTTP協議，會發現有些東西看不太明白，好比q是什麼玩意？

前面爲了便於大家的理解，我在最開始出現的時候，寫了個註釋--權重

它自己的含義是表示內容的質量或者可接受因子的優先級

內容的質量，就好比說圖片展現的質量：

若只須要展現供用戶快速瀏覽的縮略圖，咱們能夠對圖片進行大範圍的壓縮，這樣圖片質量會很低，質量因子也很低

若爲醫學用圖，須要展現高清圖，咱們不能丟失圖片細節，圖片內容質量高，質量因子天然也就很高了

可接受因子的優先級，最經常使用的就是字符編碼與語言的優先級展現

此次就拿個實例來講，這樣感觸也更深一點

Accept-Language:zh-cn,zh;q=0.8,en-us;q=0.7,en;q=0.6
複製代碼

zh-cn：簡體中文，zh：中文，這兩個質量因子都是0.8，可是優先展現簡體中文，若是服務器中沒有簡體中文的資源，則尋找中文資源，若仍是沒有該資源，則接着就是美式英語（en-us），最後再是展現英語（en）

總結來講：質量因子越大，意味着資源權重越高，越優先展現。質量因子一致，則排序在前面的先展現

常見的協商要素除了質量因子以外，還有如下幾個請求頭

• 字符編碼 Accept-Charset:ISO8859-1,UTF-8;q=0.7,*;q=0.7 資源的編碼格式
• 內容編碼 Accept-Encoding:gzip,br 主要指壓縮算法
• 表述語言 Accept-Language:zh-cn,zh;q=0.8,en-us;q=0.7,en;q=0.6 前面已經提到了，主要用於語言的優先級展現

看懂前面的內容了，這三個應該還算很好理解的吧

資源表述

咱們要的資源也跟服務器要到了，那咱們該怎麼表述這個資源呢？

注意個人用詞哦，是表述資源，不是解析資源

換句話說，就是資源的自我介紹，告訴別人它是屬於哪種編碼類型，內容又是如何編碼的，對應的是什麼地方的語言

主要是經過如下三個頭字段來進行資源的表述

• 媒體類型編碼
  • Content-type:text/html;charset=utf-8
• 內容編碼
  • Content-encoding:gzip
• 語言
  • Content-Languague:zh;en

是否是有種似曾相識的感受？沒錯，上面咱們在告訴服務端咱們須要什麼文件時，請求頭上有三個字段與這三哥們特別類似

沒印象的能夠往上面翻一翻，基本上就是Content與Accept一個單詞的區別

這也體現出了HTTP協議的特性，可讀性高與低門檻

Content與Accept就像是相親中的一男一女，女方(Accept)提出要求，做爲媒婆的服務器，就把符合條件的男方(Content)拿出來，男方把本身的簡歷拿出來(Content-type等資源表述請求頭)，倆人對上眼了，天然也就過上了幸福生活(200 OK)

還記得十年前的上網環境麼？常常有小網站出現亂碼，其實就是由於媒體類型編碼格式不對致使

內容編碼就是告訴咱們客戶端/服務器所支持的編碼類型，假如客戶端不支持gzip的編碼，服務器發給客戶端gzip資源，客戶端拿到這東西，也看不懂這是啥玩意

最後一個Content-Language我想你們都應該熟悉的，畢竟混跡互聯網這麼長時間，你就沒上過國外的小網站？

別想多了，我說的是apple.com之流，截圖以證清白！

寫在最後

今天就寫到這裏了，內容不算多，可是也不算少了

網絡協議這東西還真的是很差寫，基礎的內容實在太多了。我想來想去，仍是從實踐入手學習最快，就選了從咱們天天都接觸的HTTP協議開始提及

好比說狀態碼，請求頭，響應頭之類的這些特別基礎的東西，巴拉巴拉一大堆，說來講去也說不出什麼花樣

原本協議這東西就很枯燥乏味，一個寫很差就成了文檔翻譯。乾貨摻水真不是一件容易的事情

若是以爲寫得不錯，不要忘了點個好看喲