去年寫私有棧的時候，就想分享出一個關(guān)于公有棧的分析，奈何中間一些瑣事打斷?，F(xiàn)在重新拾起來，寫一些內(nèi)容，分享出來，很多技術(shù)本來沒有那么難，但是越來越多的命名就顯得越來越復雜！畢竟不命名點東西，就顯得沒有那么高大上了！我希望的是，更多人能以大白話的方式明白更多的道理。比如：http協(xié)議沒有那么神秘！
三次握手、四次揮手不多說了，基于tcp的！如果不明白，可以看TcpClient這篇文章！這個東西沒有那么困難。主要是什么呢。都是人為定義的，并不是定理，只要了解制定的規(guī)范就能整明白，哪怕就是對計算機一竅不通的，看看也就得了！
背景：分別抓取了get、post、file流的http請求數(shù)據(jù)！
一、Post分析：
選取一個流的完整過程
前面幾個沒有什么特別需要說的，就是同步報文段、確認報文段等。
對于每個報文里面所包含的物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)協(xié)議、傳輸控制層對應(yīng)每個字節(jié)所表示的意義，可以參考我的另一篇文章TcpClient. ，
我就不再重復解析。只針對要點信息解析。
所以，根據(jù)以上進行了三次握手同步、確認同步、確認之后，接下來就是http的超文本傳輸協(xié)議了。
對于前四層是什么，我在 TcpClient.
里面也有講，主要是一些源與目標機器之間的信息確認、報文段的標記等tcp相關(guān)的內(nèi)容。
我們主要還是要看超文本傳輸協(xié)議：Hypertext Transfer Protocol。標記處藍色的內(nèi)容即超文本傳輸協(xié)議的內(nèi)容。
1、開頭即為請求類型，那么說明這個請求類型是比較關(guān)鍵的，跟平時的認知也是相關(guān)的，然后看紅框的內(nèi)容，16進制的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進制轉(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的緩存機制，具體內(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
標紅處，有連續(xù)兩個0d、0a，這個大概表示到頭了吧，接下來就是結(jié)構(gòu)體了。
接下來獲取62個字節(jié)的內(nèi)容，就是傳輸?shù)男畔?/p>
然后按照Content-Type進行編解碼，日入這里是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)鍵信息在這里，標記了一些文件類型，也就是可以接受的文件類型是這樣的
接下來是文件信息傳輸：
此時已經(jīng)不是http的超文本傳輸協(xié)議了，而是高可靠的tcp傳輸協(xié)議，我們已經(jīng)看不到對應(yīng)的http信息投了，而是一些包含信息。用于client端解析接下來的輸入流的。
超過了1514，發(fā)生了mtu分片，緊接著可能會有多個分片的報文信息，到達客戶端之后，組合成一個文件輸出流。
文件流傳輸完成后，會告知結(jié)尾
產(chǎn)生如此一個http協(xié)議通知，然后服務(wù)端等待客戶端確認完成。只有60字節(jié)，去掉tcp頭部等信息，僅剩下幾個字節(jié)（20~40），說明就是通知用的。
后記，所以大家有沒有發(fā)現(xiàn)：
一、http協(xié)議的格式很容易，分隔符也很容易，即“空格”與“回車換行”。然后最終還是基于tcp進行數(shù)據(jù)的push推送；
二、http攜帶的內(nèi)容信息，很大部分不是我所需要的。咱們可以看一個比例，以第一個post請求為例，最終到達客戶端時，我能用到的信息僅有62字節(jié)，但是總體卻傳輸了3376字節(jié)，去掉tcp頭部信息那么也有3260字節(jié)，有效數(shù)據(jù)利用率為
62 /3314 ~=0.018 ；
如果看過私有棧，那么會發(fā)現(xiàn)私有棧的頭部信息，僅有25以內(nèi)的字節(jié)，以dubbo為例，當時我看的那個版本的頭部信息僅有22字節(jié)。像螞蟻的sofa，京東的jcf，58的scf（14字節(jié)）估計也僅20字節(jié)以內(nèi)。然后搭配私有的編解碼方式，利用率比http協(xié)議高很多倍是肯定的了，大概是幾十倍吧。
也許會說，如果我一個http信息發(fā)送的數(shù)據(jù)量大了，再加上未來網(wǎng)速越來越快，帶寬不是問題？！比例會慢慢與私有棧持平，但是要知道，即使帶寬不是問題，那么他的處理方式還是順序處理的；另外，如果一個集群達到一定程度，即使是很小一部分的性能也要盡量壓榨，因為一點的消耗，就能引起很大的不同。關(guān)鍵是看量級。
技術(shù)的使用方式上，主要還是要看應(yīng)用場景，選擇適合的才是最好的。技術(shù)的提升也是要慢慢迭代的。
所以，知道了這些，同學你是不是可以寫一個Servlet了！
