網(wǎng)絡(luò)協(xié)議之所以是叫做協(xié)議，而不是規(guī)定，就是因為傳輸什么內(nèi)容，前后端都得商量著來

客戶端需要什么，需要告訴服務端；服務端發(fā)什么給客戶端，要看客戶端能不能看懂

那他們又是怎么商量的呢？以前學習過HTTP協(xié)議的同學肯定知道，是根據(jù)請求行來進行協(xié)商的

而HTTP協(xié)議中又是怎么定義協(xié)商內(nèi)容的呢？協(xié)商好之后又該怎么表述呢？

今天就來聊聊上面的這些個問題，希望我的文字能讓你把這些內(nèi)容弄清楚

內(nèi)容協(xié)商

在HTTP中，內(nèi)容協(xié)商分為2種，分別是主動式內(nèi)容協(xié)商與響應式內(nèi)容協(xié)商

之前沒接觸過的童鞋，聽到這些名詞肯定是稀里糊涂的，別著急，咱們一個一個的來

主動式內(nèi)容協(xié)商

千言萬語不如一張圖來的形象，先上張主動式內(nèi)容協(xié)商的過程圖

起點是客戶端(Client)，先看看圖，看不懂沒關(guān)系，有個印象就好了。不然接下來我說的內(nèi)容，對你來說可能就是天書了

這圖猛的一看挺復雜的，花里胡哨一大堆。其實過程非常簡單

其實就是客戶端發(fā)起了一個HTTP1.1的GET請求資源后，服務端返回資源的一個情況

發(fā)起GET請求后，通過Accept、Accept-Language、Accept-Encoding這三個請求頭，客戶端告訴服務器：我現(xiàn)在要一個text/類型的文件，并且我只接受這個文件語言為en（英語），我這里能看得懂的編碼格式只有br、gzip格式，q(權(quán)重)都是0.8，你（服務器）有哪種編碼格式隨便給我都行

服務器看到我們的要求，根據(jù)我們的要求以及請求的URL，就到這個URL里定位的資源，尋找是否有符合我們要求的資源

我們請求的URL在服務器是存在對應文件的，所以告訴我們狀態(tài)碼是200，并且把URLe對應的資源給到了我們（客戶端）

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

我們（客戶端）拿到符合要求的文件，也就可以正常解析數(shù)據(jù)了

響應式內(nèi)容協(xié)商

來，咱們再來看看什么是響應式內(nèi)容協(xié)商，還是老規(guī)矩，先上一張圖，韻個味

看懂了之前的主動式內(nèi)容協(xié)商，我相信這張圖你也能看的七七八八。因為區(qū)別并不大

區(qū)別就在于Client（客戶端）請求了之后，居然給我們一個300（重定向），而不是我們之前的200（OK）

居然還要我們再去請求一次，才把URLe的內(nèi)容給我們

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

在響應式內(nèi)容協(xié)商中，客戶端發(fā)送請求，服務器端無法抉擇要返回什么內(nèi)容，所以就把客戶端請求的URL對應的資源列表全部返回，然后由客戶端自行抉擇。客戶端進行選擇后再去訪問指定資源

而因為RFC中沒有明確指出客戶端應該依據(jù)怎樣的規(guī)則去對資源進行抉擇，所以各大瀏覽器的實現(xiàn)方式都不一致

又因為各大瀏覽器實現(xiàn)方式都不統(tǒng)一，相對來說，用到響應式內(nèi)容協(xié)商的地方就很少了

質(zhì)量因子

上面有些內(nèi)容大家如果沒有學過HTTP協(xié)議，會發(fā)現(xiàn)有些東西看不太明白，比如q是什么玩意？

前面為了便于你們的理解，我在最開始出現(xiàn)的時候，寫了個注釋--權(quán)重

它本身的含義是表示內(nèi)容的質(zhì)量或者可接受因子的優(yōu)先級

內(nèi)容的質(zhì)量，就比如說圖片展示的質(zhì)量：

若只需要展示供用戶快速瀏覽的縮略圖，我們可以對圖片進行大范圍的壓縮，這樣圖片質(zhì)量會很低，質(zhì)量因子也很低

若為醫(yī)學用圖，需要展示高清圖，我們不能丟失圖片細節(jié)，圖片內(nèi)容質(zhì)量高，質(zhì)量因子自然也就很高了

可接受因子的優(yōu)先級，最常用的就是字符編碼與語言的優(yōu)先級展示

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

Accept-Language:zh-cn,zh;q=0.8,en-us;q=0.7,en;q=0.6

zh-cn：簡體中文，zh：中文，這兩個質(zhì)量因子都是0.8，但是優(yōu)先展示簡體中文，如果服務器中沒有簡體中文的資源，則尋找中文資源，若還是沒有該資源，則接著就是美式英語（en-us），最后再是展示英語（en）

總結(jié)來說：質(zhì)量因子越大，意味著資源權(quán)重越高，越優(yōu)先展示。質(zhì)量因子一致，則排序在前面的先展示

常見的協(xié)商要素除了質(zhì)量因子之外，還有以下幾個請求頭

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

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

資源表述

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

注意我的用詞哦，是表述資源，不是解析資源

換句話說，就是資源的自我介紹，告訴別人它是屬于哪一種編碼類型，內(nèi)容又是如何編碼的，對應的是什么地方的語言

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

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

是不是有種似曾相識的感覺？沒錯，上面我們在告訴服務端我們需要什么文件時，請求頭上有三個字段與這三哥們特別相似

沒印象的可以往上面翻一翻，基本上就是Content與Accept一個單詞的區(qū)別

這也體現(xiàn)出了HTTP協(xié)議的特性，可讀性高與低門檻

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

還記得十年前的上網(wǎng)環(huán)境么？經(jīng)常有小網(wǎng)站出現(xiàn)亂碼，其實就是因為媒體類型編碼格式不對導致

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

最后一個Content-Language我想大家都應該熟悉的，畢竟混跡互聯(lián)網(wǎng)這么長時間，你就沒上過國外的小網(wǎng)站？

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

寫在最后

今天就寫到這里了，內(nèi)容不算多，但是也不算少了

網(wǎng)絡(luò)協(xié)議這東西還真的是不好寫，基礎(chǔ)的內(nèi)容實在太多了。我想來想去，還是從實踐入手學習最快，就選了從我們每天都接觸的HTTP協(xié)議開始說起

比如說狀態(tài)碼，請求頭，響應頭之類的這些特別基礎(chǔ)的東西，巴拉巴拉一大堆，說來說去也說不出什么花樣

本來協(xié)議這東西就很枯燥乏味，一個寫不好就成了文檔翻譯。干貨摻水真不是一件容易的事情

如果覺得寫得不錯，不要忘了點個好看喲