1.HTTP協議的主要特點
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
http協議沒法保存客戶機信息，也就沒法區分每次請求的不同之處。關於http無狀態阻礙了交互式應用程序的實現。比如記錄用戶瀏覽哪些網頁、判斷用戶是否擁有權限訪問等。HTTP無狀態的特性嚴重阻礙了這些交互式應用程序的實現，畢竟交互是需要承前啓後的，簡單的購物車程序也要知道用戶到底在之前選擇了什麼商品。於是，兩種用於保持HTTP狀態的技術就應運而生了，一個是Cookie，而另一個則是Session。Cookie是客戶端的存儲空間，由瀏覽器來維持。具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。
2.HTTP報文的組成部分
請求報文：請求行、請求頭、空行、請求體
響應報文：狀態行、響應頭、空行、響應體
3.HTTP方法
GET–獲取資源
POST–傳輸資源
PUT–更新資源
DELETE–刪除資源
HEAD–獲得報文首部
4.GET和POST的區別
- GET在瀏覽器中回退時是無害的，而POST會再次提交請求
- GET請求在URL中傳送傳參的長度是限制的2kb，而POST沒有限制
- GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留
- GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置
- GET參數通過URL船體，POST放在Request body中
- GET比POST更不安全，因爲參數暴露在地址欄上，所以不能用來傳遞敏感信息
- GET請求只能進行url編碼，而POST支持多種編碼方式
- GET產生的URL地址可以被收藏，而POST不可以
- 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制
5.HTTP狀態碼
1XX：指示信息–表示請求已接收，繼續處理
2XX：成功–表示請求已被成功接收
3XX：重定向–要完成氫氣必須進行更進一步的操作
4XX：客戶端錯誤–請求有語法錯誤或請求無法實現
5XX: 服務器有錯誤–服務器未能實現合法的請求
舉例：
200：客戶端請求成功
206：Partial Content客戶發送了一個帶有Range頭的GET請求，服務器完成了它
301：所請求的頁面已經轉移至新的url
302：所請求的頁面已經臨時轉移至新的url
304：客戶端有緩衝的文檔併發出了一個條件下的請求i，服務器告訴客戶，原來緩衝的文檔還可以繼續使用
400：客戶端有語法錯誤，不能被服務器所理解
401：請求未經授權，這個狀態碼必粗和WWW-Authenticate報頭域一起使用
403：對被請求頁面的訪問被禁止
404：請求資源不存在
500：服務器發生不可預期的錯誤原來緩衝的文檔還可以繼續使用
503：請求未完成，服務器臨時過載或宕機，一段時間後可能恢復正常
6.HTTP的持久連接
HTTP協議採用“請求-應答”模式，當時有普通模式，即非Keep-Alive模式時，每個請求/應答客戶和服務器都要建立一個連接，完成之後立即斷開連接（HTTP協議無連接的協議）
當使用Keep-Alive模式（持久連接、連接重用）時，Keep-Alive功能是客戶端到服務器的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接
http 1.1中默認啓用Keep-Alive，如果加入"Connection: close "，才關閉
Keep-Alive的應用：
Keep-Alive: timeout=5, max=100
timeout=5表示這個TCP通道可以保持5秒
max=100，表示這個長連接最多接收100次請求就斷開。
Http1.0和Http1.1中
Http1.0：默認Keep-Alive時關閉的，需要在Header頭中添加Connection: Keep-Alive啓用。
Http1.1:默認啓用Keep-Alive，加入Connection: close才關閉。
7.HTTP的管線化
- 那麼持久連接和管線化的區別在於：
持久連接的一個缺點是請求和響應式是順序執行的，只有在請求1的響應收到之後，纔會發送請求2，而管線化不需要等待上一次請求得到響應就可以進行下一次請求。實現並行發送請求。
-
只有GET和HEAD要求可以進行管線化，而POST則有所限制
-
初次創建連接時也不應啓動管線機制，因爲對方（服務器）不一定支持HTTP/1.1版本的協議。
-
HTTP1.1要求服務器端支持管線化，但並不要求服務器端也對響應進行管線化處理，只是要求對於管線化的請求不失敗，而且現在很多服務器端和代理程序對管線化的支持並不好，現代瀏覽器Chrome和Firefox默認並未開啓管線化支持。