HTTP協(xié)議是一種建立在TCP協(xié)議之上的應(yīng)用層協(xié)議，其主要特點(diǎn)是以請(qǐng)求-響應(yīng)模式為交互基礎(chǔ)，以文本行作為編碼方式的協(xié)議。通過特殊字符進(jìn)行“協(xié)議頭”分包，通過長(zhǎng)度協(xié)議頭內(nèi)容作為協(xié)議正文分包。不算一種設(shè)計(jì)的非常高效的協(xié)議，但是可以方便人工閱讀調(diào)試。

對(duì)于tcp這種流，建基于這個(gè)上面的協(xié)議，一般都要完成：分包（Content-type)，標(biāo)記處理功能(http命令如GET，PUT的URL），請(qǐng)求應(yīng)答對(duì)應(yīng)（http使用的是阻塞等待回應(yīng)方式）

而其他的一些如rpc協(xié)議，也是請(qǐng)求響應(yīng)模型，他們會(huì)使用一些長(zhǎng)度字段解決分包問題，用命令字字段解決標(biāo)記處理功能問題，用序列號(hào)字段解決請(qǐng)求應(yīng)答包對(duì)應(yīng)問題，還有的會(huì)添加會(huì)話id字段解決短線重連或短鏈接問題

協(xié)議即是規(guī)范，為了讓接收端的軟硬件能識(shí)別內(nèi)容，然后決定該怎么處理。

就好比你發(fā)了一篇文章過去，純文本不帶協(xié)議的話，只有人能識(shí)別內(nèi)容（專業(yè)領(lǐng)域甚至一般人都讀不懂，比如消息體使用了壓縮），而且有時(shí)候需要讀完全文才能明白對(duì)方想說什么。

但是如果文章開篇定義了標(biāo)題、分類、關(guān)鍵詞、中心思想等，收件人就能第一時(shí)間對(duì)內(nèi)容有一個(gè)了解。如果他是個(gè)快遞員，會(huì)按地址投到不同大區(qū)倉(cāng)庫(kù)；如果是報(bào)社工作人員，會(huì)按分類等轉(zhuǎn)交不同審稿人。那么這里的快遞員和報(bào)社工作人員就是http代理，避免最終接收和處理的人要挨個(gè)查找、翻閱跟自己無(wú)關(guān)的東西。

WRITE-BUG研發(fā)團(tuán)隊(duì)衷心希望【W(wǎng)RITE-BUG數(shù)字空間】可以給每位同學(xué)一個(gè)屬于自己的秘密空間，同時(shí)祝愿大家在“公開圈子”世界里，遇見志同道合的伙伴們，因?yàn)槲覀兣c大家一樣，都曾孤獨(dú)前行著。