Http協議類
Http協議的主要特點
-
簡單快速：每個資源都是一個固定的uri
-
靈活：每一個http協議頭部會有一個數據類型，通過一個http協議就可以完成不同數據類型的傳輸
-
無連接：我鏈接一次他就會斷掉不會保持連接
-
無狀態：客戶端和服務端是兩種身份，客戶端向服務端請求數據，http幫你建立連接，幫你中間傳輸，完成任務連接就斷開了
Http方法
- GET 獲取資源
- POST 傳輸資源
- PUT 更新資源
- DELETE 刪除資源
- HEAD 獲得報文首部
Http的報文組成
-
請求報文：請求行：請求方法 URL地址 協議名稱或版本號
請求頭: 鍵值對 服務端據此獲取客戶端的信息
空行: 分隔請求頭和請求體
請求體: 通過請求體傳值
-
響應報文： 狀態行： 說明所請求的資源情況
響應頭 ： 描述服務器基本信息
空行 ： 分隔響應頭和響應體
響應體：服務端返回的數據
POST和GET的區別
- GET在瀏覽器回退時是無害的，而POST會再次提交請求
- GET產生的url地址可以被收藏，而POST不可以
- GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置
- GET只能進行url編碼，而POST支持多種編碼
- GET參數會被瀏覽器保存在在瀏覽記錄裏，而POST不會
- GET請求在url傳遞參數有長度限制
- 對參數數據類型，GET只接受ASCII字符
- GET比POST更不安全，參數直接暴露在url上，不能用來傳遞敏感信息
- GET參數通過url傳遞，而POST放在Request body中
Http狀態碼
- 1xx：指示信息，表示請求已成功接收
- 2xx：成功，請求已成功接收 200 OK：客戶端請求成功
- 3xx：重定向，完成請求必須進行更進一步操作
- 4xx：客戶端錯誤 400 Bad Request：客戶端請求語法有錯誤，不能被服務端理解 404 NOT Found 請求資源不存在
- 5xx：服務端錯誤 500 服務器發生不可預期的錯誤
持久連接
-
HTTP協議採用“請求-應答”模式，不開啓KeepAlive模式時，每個req/res客戶端和服務端都要新建一個連接，完成之後立即斷開連接（HTTP協議爲無連接的協議）；
-
當開啓Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。
管線化
持久連接的情況下
非管線化：
請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3
管線化
請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3
管線化機制通過持久連接完成，僅HTTP/1.1支持此技術
只有GET和HEAD請求可以進行管線化，而POST則有所限制
初次創建連接時不應啓動管線機制，因爲對方（服務器）不一定支持HTTP/1.1版本的協議
HTTP/1.1要求服務器端支持管線化，但並不要求服務器端也對響應進行管線化處理，只是要求對於管線化的請求不失敗即可
由於上面提到的服務器端問題，開啓管線化很可能並不會帶來大幅度的性能提升，而且很多服務器端和代理程序對管線化的支持並不太好，因此現代瀏覽器默認併爲開啓管線化支持