參考：
HTTP協議詳解
HTTP協議處理流程
HTTP練習沙箱：httpbin.org
官方文檔：
IETF RFC2616 HTTP/1.1
https://www.w3.org/Protocols/
http://www.faqs.org/rfcs/
書籍參考：
《HTTP權威指南》
基本知識點
超文本輸出協議
快速，靈活
請求方法：GET、HEAD、POST、PUT、DELETE
傳輸類型以 Content-Type加以標記
無連接：請求完收到響應即斷開連接
無狀態：后續處理需要前面的信息就必須重傳
HTTP request：請求行，請求頭，請求體；
HTTP response：狀態行，響應頭，響應體；
http狀態碼 ：
302 是請求重定向，304未改變，用于瀏覽器緩存機制；
500以上是服務器錯誤
400以上是請求鏈接錯誤或者找不到服務器，401未授權，404未找到；
200以上是正確
100以上是請求接受成功cookie RFC6265
為了辨別用戶身份，進行session跟蹤而存儲在用戶本地終端上的數據，通常經過加密，可以叫做瀏覽器緩存；
cookie是由web服務器創建的保存在用戶瀏覽器上的小文本文件，它包含有關用戶信息，可以加快用戶訪問速度，但是會導致安全問題；
用戶訪問一個web服務器時，瀏覽器首先要檢查本地的cookies，并將其樣發給web服務器；
cookies最經典的應用是判定注冊用戶是否已經登錄網站；HTTP URL請求過程
請求DNS域名解析
TCP/IP連接
發送請求
接受響應
客戶端主動關閉chunked 編碼
一般情況下HTTP的header包含content-length來指明報文體長度；
但有時候服務生成HTTP回應是無法確定消息大小的，比如大文件的下載，或者后臺需要復雜的邏輯才能全部處理頁面的請求，這時需要實時生成消息長度，服務器一般使用 chunked 編碼;
編碼使用若干個Chunk組成，由一個標明長度為0的chunk結束，每個Chunk有兩部分組成，第一部分是該Chunk的長度和長度單位（一般不寫），第二部分就是指定長度的內容，每個部分用CRLF隔開。在最后一個長度為0的Chunk中的內容是稱為footer的內容，是一些沒有寫的頭部內容
HTTP 原理
參數字段
- Keep-Alive:
Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接，有一個設置時間 - Range：
設置斷點下載/續傳的位置
Socket
socket起源于Unix，而Unix/Linux的基本哲學之一就是“一切皆文件”；
scoket是一套完成TCP/UDP協議的接口，本身并不是協議，而是一個調用接口；
- 心跳
理論上socket的TCP鏈接是長連接，一般不會主動斷開，但是會出現異常情況導致連接斷開，所以在無數據傳輸的時候要發送心跳消息，消息內容由開發者自定義；
HTTPS
HHTPS 使用 443端口， HTTP使用80端口；
HTTP+SSL，SSL(安全套接層)是Netscape公司設計的主要用于web的安全傳輸協議，通過證書來確保客戶端跟服務端之間的通信數據是加密安全的；
加解密算法類型：
- 對稱加密：密鑰只有一個，加密解密為同一個密碼，切加解速度快
典型的對稱加密算法有DES、AES、RC5、3DES等； -
非對稱加密：使用兩個密鑰，公共密鑰和私有密鑰
根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰，相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等；
私有由一方保存，另一方任何人都可以獲得公共密鑰；
URL導圖：
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請求基礎之上定義出來的一種方式；
multipart請求頭信息: Content-Type，其值必須規定為multipart/form-data，具體的頭信息如下：
Content-Type: multipart/form-data; boundary=${bound}
${bound}是一個占位符，代表我們規定的分隔符；
與post請求體不同的是它的構造方式，post是簡單的name=value值鏈接，而multipart/form-data則是添加了分割符等內容的構造體；
**要發送一個multipart請求，其實任何支持post請求的工具或語言都可以支持，只是自己要稍微包裝一下便可
