參考：
HTTP協(xié)議詳解
HTTP協(xié)議處理流程
HTTP練習(xí)沙箱：httpbin.org
官方文檔：
IETF RFC2616 HTTP/1.1
https://www.w3.org/Protocols/
http://www.faqs.org/rfcs/
書籍參考：
《HTTP權(quán)威指南》
基本知識點
超文本輸出協(xié)議
快速晋南，靈活
請求方法：GET姜凄、HEAD董虱、POST、PUT、DELETE
傳輸類型以 Content-Type加以標(biāo)記
無連接：請求完收到響應(yīng)即斷開連接
無狀態(tài)：后續(xù)處理需要前面的信息就必須重傳
HTTP request：請求行，請求頭对人，請求體；
HTTP response：狀態(tài)行，響應(yīng)頭，響應(yīng)體吵护；
http狀態(tài)碼 ：
302 是請求重定向譬圣，304未改變屯蹦，用于瀏覽器緩存機(jī)制飘庄；
500以上是服務(wù)器錯誤
400以上是請求鏈接錯誤或者找不到服務(wù)器，401未授權(quán)，404未找到孕豹；
200以上是正確
100以上是請求接受成功cookie RFC6265
為了辨別用戶身份址儒，進(jìn)行session跟蹤而存儲在用戶本地終端上的數(shù)據(jù)，通常經(jīng)過加密，可以叫做瀏覽器緩存潘鲫；
cookie是由web服務(wù)器創(chuàng)建的保存在用戶瀏覽器上的小文本文件翁逞，它包含有關(guān)用戶信息，可以加快用戶訪問速度，但是會導(dǎo)致安全問題浊竟；
用戶訪問一個web服務(wù)器時，瀏覽器首先要檢查本地的cookies徘郭，并將其樣發(fā)給web服務(wù)器壳快；
cookies最經(jīng)典的應(yīng)用是判定注冊用戶是否已經(jīng)登錄網(wǎng)站镇草；HTTP URL請求過程
請求DNS域名解析
TCP/IP連接
發(fā)送請求
接受響應(yīng)
客戶端主動關(guān)閉chunked 編碼
一般情況下HTTP的header包含content-length來指明報文體長度眶痰；
但有時候服務(wù)生成HTTP回應(yīng)是無法確定消息大小的，比如大文件的下載，或者后臺需要復(fù)雜的邏輯才能全部處理頁面的請求七婴，這時需要實時生成消息長度祟偷，服務(wù)器一般使用 chunked 編碼;
編碼使用若干個Chunk組成，由一個標(biāo)明長度為0的chunk結(jié)束打厘，每個Chunk有兩部分組成修肠，第一部分是該Chunk的長度和長度單位（一般不寫），第二部分就是指定長度的內(nèi)容婚惫，每個部分用CRLF隔開。在最后一個長度為0的Chunk中的內(nèi)容是稱為footer的內(nèi)容魂爪，是一些沒有寫的頭部內(nèi)容
HTTP 原理
參數(shù)字段
- Keep-Alive:
Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效先舷，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接滓侍，有一個設(shè)置時間 - Range：
設(shè)置斷點下載/續(xù)傳的位置
Socket
socket起源于Unix蒋川，而Unix/Linux的基本哲學(xué)之一就是“一切皆文件”；
scoket是一套完成TCP/UDP協(xié)議的接口撩笆，本身并不是協(xié)議捺球，而是一個調(diào)用接口；
- 心跳
理論上socket的TCP鏈接是長連接夕冲，一般不會主動斷開氮兵，但是會出現(xiàn)異常情況導(dǎo)致連接斷開，所以在無數(shù)據(jù)傳輸?shù)臅r候要發(fā)送心跳消息歹鱼，消息內(nèi)容由開發(fā)者自定義泣栈；
HTTPS
HHTPS 使用 443端口， HTTP使用80端口弥姻；
HTTP+SSL南片，SSL(安全套接層)是Netscape公司設(shè)計的主要用于web的安全傳輸協(xié)議，通過證書來確蓖ザ兀客戶端跟服務(wù)端之間的通信數(shù)據(jù)是加密安全的疼进；
加解密算法類型：
- 對稱加密：密鑰只有一個，加密解密為同一個密碼秧廉，切加解速度快
典型的對稱加密算法有DES伞广、AES、RC5疼电、3DES等赔癌； -
非對稱加密：使用兩個密鑰，公共密鑰和私有密鑰
根據(jù)公鑰無法推知私鑰澜沟，根據(jù)私鑰也無法推知公鑰灾票，相對對稱加密速度較慢，典型的非對稱加密算法有RSA茫虽、DSA等刊苍；
私有由一方保存既们，另一方任何人都可以獲得公共密鑰；
URL導(dǎo)圖：
Paste_Image.png
Multipart/form-data
https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
https://my.oschina.net/cnlw/blog/168466
http://www.faqs.org/rfcs/
http里沒有專門用于文件上傳的請求方式正什，文件上傳請求是在post請求基礎(chǔ)之上定義出來的一種方式啥纸；
multipart請求頭信息: Content-Type，其值必須規(guī)定為multipart/form-data婴氮，具體的頭信息如下：
Content-Type: multipart/form-data; boundary=${bound}
${bound}是一個占位符斯棒，代表我們規(guī)定的分隔符；
與post請求體不同的是它的構(gòu)造方式主经，post是簡單的name=value值鏈接荣暮，而multipart/form-data則是添加了分割符等內(nèi)容的構(gòu)造體；
**要發(fā)送一個multipart請求罩驻，其實任何支持post請求的工具或語言都可以支持穗酥，只是自己要稍微包裝一下便可
