去年寫私有棧的時候戚篙，就想分享出一個關(guān)于公有棧的分析网持，奈何中間一些瑣事打斷。現(xiàn)在重新拾起來冯吓，寫一些內(nèi)容蔫浆，分享出來殖属，很多技術(shù)本來沒有那么難，但是越來越多的命名就顯得越來越復(fù)雜瓦盛！畢竟不命名點(diǎn)東西洗显，就顯得沒有那么高大上了！我希望的是原环，更多人能以大白話的方式明白更多的道理挠唆。比如：http協(xié)議沒有那么神秘！
三次握手嘱吗、四次揮手不多說了玄组，基于tcp的！如果不明白谒麦，可以看TcpClient這篇文章俄讹！這個東西沒有那么困難。主要是什么呢绕德。都是人為定義的患膛，并不是定理，只要了解制定的規(guī)范就能整明白耻蛇，哪怕就是對計算機(jī)一竅不通的踪蹬，看看也就得了！
背景：分別抓取了get臣咖、post跃捣、file流的http請求數(shù)據(jù)！
一夺蛇、Post分析：
選取一個流的完整過程
前面幾個沒有什么特別需要說的疚漆，就是同步報文段、確認(rèn)報文段等。
對于每個報文里面所包含的物理層娶聘、數(shù)據(jù)鏈路層灵临、網(wǎng)絡(luò)協(xié)議、傳輸控制層對應(yīng)每個字節(jié)所表示的意義趴荸，可以參考我的另一篇文章TcpClient. ，
我就不再重復(fù)解析宦焦。只針對要點(diǎn)信息解析发钝。
所以，根據(jù)以上進(jìn)行了三次握手同步波闹、確認(rèn)同步酝豪、確認(rèn)之后，接下來就是http的超文本傳輸協(xié)議了精堕。
對于前四層是什么孵淘，我在 TcpClient.
里面也有講，主要是一些源與目標(biāo)機(jī)器之間的信息確認(rèn)歹篓、報文段的標(biāo)記等tcp相關(guān)的內(nèi)容瘫证。
我們主要還是要看超文本傳輸協(xié)議：Hypertext Transfer Protocol。標(biāo)記處藍(lán)色的內(nèi)容即超文本傳輸協(xié)議的內(nèi)容庄撮。
1背捌、開頭即為請求類型，那么說明這個請求類型是比較關(guān)鍵的洞斯，跟平時的認(rèn)知也是相關(guān)的毡庆，然后看紅框的內(nèi)容，16進(jìn)制的20表示一個空格烙如，也就是說：http協(xié)議中以 20空格作為分隔符（不是160空格）么抗。
Post：50 4f 53 54
空格：20
2、緊跟在其后的是訪問的url亚铁，同上也是以20空格作為分隔的蝇刀。
Url：2f 61 70 69 2f 73 65 61 72 63 68 2f 72 65 70 6f 72 74 2f 65 6d 70 74 79 77 6f 72 64 73 2f
空格：20
3、http協(xié)議版本刀闷。這里有些不一樣了熊泵，使用0d 0a作為分隔符，0d 0a查找16進(jìn)制轉(zhuǎn)換符號可以知道甸昏，分別表示的是“回車” 與 “換行”顽分。
Request version：48 54 54 50 2f 31 2e 31
回車換行符：0d 0a
4、攜帶內(nèi)容的數(shù)據(jù)類型Content-type施蜜，任然是0d 0a分隔符卒蘸。
Content-Type：43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e
回車換行符：0d 0a
5、同樣 user-agent，這個是攜帶客戶信息的字段缸沃，比如告知的是什么樣的瀏覽器恰起，操作系統(tǒng)等。
User-Agent：55 73 65 72 2d 41 67 65 6e 74 3a 20 50 6f 73 74 6d 61 6e 52 75 6e 74 69 6d 65 2f 37 2e 31 36 2e 33 0d 0a
回車換行符：0d 0a
6趾牧、accept检盼，表示response的時候，接收的是什么樣的數(shù)據(jù)翘单，這里明顯 “*” 表示接收所有的數(shù)據(jù)吨枉。
Accept：41 63 63 65 70 74 3a 20 2a 2f 2a
回車換行符：0d 0a
7、用于針對request哄芜、response的緩存機(jī)制貌亭，具體內(nèi)容可以自行百科，針對這里认臊，
明顯是說request請求no-cache圃庭，也就是每次都重新請求Cache-control
Cache-Control：43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 65
回車換行符：0d 0a
8、postman-token大概跟session類似的吧失晴，反正都是字節(jié)流剧腻，自己篡改就好了。
9涂屁、host：
Host：48 6f 73 74 3a 20 31 30 2e 34 2e 34 30 2e 31 36 38 3a 38 38 30 36
回車換行符：0d 0a
10恕酸、Accept-Encoding：這是要聲明瀏覽器的接收的壓縮編碼類型，這里是可以接受gzip胯陋、deflat的壓縮類型蕊温。
Accept-Encoding：41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 2c 20 64 65 66 6c 61 74 65
回車換行符：0d 0a
11、Content-Length：這個很明顯就是請求的內(nèi)容的長度遏乔，這里寫的是62字節(jié)
Content-Length：43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 36 32
回車換行符：0d 0a
12义矛、Connection：keep-alive，很明顯長鏈接盟萨。
Connection：43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 65
0d 0a 0d 0a
回車換行符：0d 0a
標(biāo)紅處凉翻，有連續(xù)兩個0d、0a捻激，這個大概表示到頭了吧制轰，接下來就是結(jié)構(gòu)體了。
接下來獲取62個字節(jié)的內(nèi)容胞谭，就是傳輸?shù)男畔?/p>
然后按照Content-Type進(jìn)行編解碼垃杖，日入這里是application/json，那么就是要把這些個流丈屹，解析成json格式调俘。
二伶棒、Get分析
同理，比如cookie彩库，即在12之前的位置上寫入cookie：key=value這樣的形式肤无。
此外，還有Upgrade-Insecure-Requests骇钦、Accept-Language宛渐、If-None-Match等，都是以這樣的形式產(chǎn)生的眯搭，如下是某個Get請求：
這樣的組合起來就是超文本協(xié)議了皇忿，注意，這是協(xié)議坦仍。
三、文件流分析
此圖是一個excel的文件請求流信息叨襟，關(guān)鍵信息在這里繁扎，標(biāo)記了一些文件類型，也就是可以接受的文件類型是這樣的
接下來是文件信息傳輸：
此時已經(jīng)不是http的超文本傳輸協(xié)議了糊闽，而是高可靠的tcp傳輸協(xié)議梳玫，我們已經(jīng)看不到對應(yīng)的http信息投了，而是一些包含信息右犹。用于client端解析接下來的輸入流的提澎。
超過了1514，發(fā)生了mtu分片念链，緊接著可能會有多個分片的報文信息盼忌，到達(dá)客戶端之后，組合成一個文件輸出流掂墓。
文件流傳輸完成后谦纱，會告知結(jié)尾
產(chǎn)生如此一個http協(xié)議通知，然后服務(wù)端等待客戶端確認(rèn)完成君编。只有60字節(jié)跨嘉，去掉tcp頭部等信息，僅剩下幾個字節(jié)（20~40）吃嘿，說明就是通知用的祠乃。
后記，所以大家有沒有發(fā)現(xiàn)：
一兑燥、http協(xié)議的格式很容易亮瓷，分隔符也很容易，即“空格”與“回車換行”降瞳。然后最終還是基于tcp進(jìn)行數(shù)據(jù)的push推送寺庄；
二、http攜帶的內(nèi)容信息，很大部分不是我所需要的斗塘。咱們可以看一個比例赢织，以第一個post請求為例，最終到達(dá)客戶端時馍盟，我能用到的信息僅有62字節(jié)于置，但是總體卻傳輸了3376字節(jié)，去掉tcp頭部信息那么也有3260字節(jié)贞岭，有效數(shù)據(jù)利用率為
62 /3314 ~=0.018 八毯；
如果看過私有棧，那么會發(fā)現(xiàn)私有棧的頭部信息瞄桨，僅有25以內(nèi)的字節(jié)话速，以dubbo為例，當(dāng)時我看的那個版本的頭部信息僅有22字節(jié)芯侥。像螞蟻的sofa泊交，京東的jcf，58的scf（14字節(jié)）估計也僅20字節(jié)以內(nèi)柱查。然后搭配私有的編解碼方式廓俭，利用率比http協(xié)議高很多倍是肯定的了，大概是幾十倍吧唉工。
也許會說研乒，如果我一個http信息發(fā)送的數(shù)據(jù)量大了，再加上未來網(wǎng)速越來越快淋硝，帶寬不是問題雹熬？！比例會慢慢與私有棧持平谣膳，但是要知道橄唬，即使帶寬不是問題，那么他的處理方式還是順序處理的参歹；另外仰楚，如果一個集群達(dá)到一定程度，即使是很小一部分的性能也要盡量壓榨犬庇，因?yàn)橐稽c(diǎn)的消耗僧界，就能引起很大的不同。關(guān)鍵是看量級臭挽。
技術(shù)的使用方式上捂襟，主要還是要看應(yīng)用場景，選擇適合的才是最好的欢峰。技術(shù)的提升也是要慢慢迭代的葬荷。
所以涨共，知道了這些，同學(xué)你是不是可以寫一個Servlet了宠漩！
