一、Http的特點
1、簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、PUT、DELETE、POST。每種方法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。
2、靈活：HTTP允許傳輸任意類型的資料對象。
3、無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。
4、無狀态：HTTP協定是無狀态的，HTTP 協定自身不對請求和響應之間的通信狀态進行儲存。任何兩次請求之間都沒有依賴關系。直覺地說，就是每個請求都是獨立的，與前面的請求和後面的請求都是沒有直接聯系的。協定本身并不保留之前一切的請求或 響應封包的資訊。這是為了更快地處理大量事務，確定協定的可伸縮性，而特意把 HTTP 協定設計成如此簡單的。
二、Http封包
Http封包包括請求封包和響應封包兩大部分，其中請求封包由請求行（request line）、請求頭（header）、空行和請求體四個部分組成。而響應封包由狀态行、響應頭部、空行和響應體四個部分組成。接下來我們詳細介紹下請求封包的各個部分及其作用。
1、請求行
用來說明請求類型、要通路的資源以及所使用的HTTP版本。
POST /chapter17/user.html HTTP/1.1
以上代碼中 POST 代表請求方法， /chapter17/user.html 表示URI， HTTP/1.1 代表協定和協定的版本。現在比較流行的是Http1.1版本。大家也可以了解下 2.0 ：《讓面試官顫抖的 HTTP 2.0 協定面試題》。
2、請求頭
由關鍵字 / 值對組成，每行一對，關鍵字和值用英文冒号“:”分隔。
請求頭部通知伺服器有關于用戶端請求的資訊。它包含許多有關的用戶端環境和請求正文的有用資訊。其中比如：
Host：表示主機名，虛拟主機。
Connection：HTTP/1.1增加的，使用keepalive，即持久連接配接，一個連接配接可以發多個請求。
User-Agent：請求發出者，相容性以及定制化需求。
3、空行
最後一個請求頭之後是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。
4、請求體
可以承載多個請求參數的資料。
name=tom&password=1234&realName=tomson
上面代碼，承載着name、password、realName三個請求參數。
三、HTTP請求方法
GET：請求指定的頁面資訊，并傳回實體主體。
HEAD：類似于get請求，隻不過傳回的響應中沒有具體的内容，用于擷取報頭。
POST：向指定資源送出資料進行處理請求（例如送出表單或者上傳檔案）。資料被包含在請求體中。
PUT：從用戶端向伺服器傳送的資料取代指定的文檔的内容。
DELETE：請求伺服器删除指定的頁面。
四、GET與POST差別
GET在浏覽器回退時是無害的，而POST會再次送出請求。
GET請求會被浏覽器主動緩存，而POST不會，除非手動設定。
GET請求參數會被完整保留在浏覽器曆史記錄裡，而POST中的參數不會被保留。
GET請求在URL中傳送的參數是有長度限制的，而POST沒有限制。
GET參數通過URL傳遞，POST放在Request body中。
五、Http狀态碼
狀态代碼有三位數字組成，第一個數字定義了響應的類别，共分五種類别：
1xx：訓示資訊——表示請求已接收，繼續處理。
2xx：成功——表示請求已被成功接收、了解、接受。
3xx：重定向——要完成請求必須進行更進一步的操作。
4xx：用戶端錯誤——請求有文法錯誤或請求無法實作。
5xx：伺服器端錯誤——伺服器未能實作合法的請求。
比如我們平時常見兩種出錯的狀态碼：
403 Forbidden //對被請求頁面的通路被禁止404 Not Found //請求資源不存在，比如：輸入了錯誤的URL
更多看下這篇文章《兩張趣圖助你了解 HTTP 狀态碼》
六、持久連接配接
1、為什麼需要持久連接配接
HTTP協定的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接配接。以當年的通信情況來說，因為都是些容量很小的文本傳輸，是以即使這樣也沒有多大問題。可随着 HTTP 的 普及，文檔中包含大量圖檔的情況多了起來。比如，使用浏覽器浏覽一個包含多張圖檔的 HTML 頁面時，在發送請求通路 HTML 頁面資源的同時，也會請 求該 HTML 頁面裡包含的其他資源。是以，每次的請求都會造成無謂的 TCP 連接配接建立和斷開，增加通信量的 開銷。
2、持久連接配接的特點
為解決上述 TCP 連接配接的問題， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接配接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接配接的特點是，隻要任意一端沒有明确提出斷開連接配接，則保持TCP連接配接狀态。
持久連接配接的好處在于減少了 TCP 連接配接的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。另外， 減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。
在 HTTP/1.1 中，所有的連接配接預設都是持久連接配接，但在 HTTP/1.0 内并未标準化。雖然有一部分伺服器通過非 标準的手段實作了持久連接配接，但伺服器端不一定能夠支援持久連接配接。毫無疑問，除了伺服器端，用戶端也需 要支援持久連接配接。
七、管線化
持久連接配接使得多數請求以管線化（pipelining）方式發送成為可能。從前發送請求後需等待并收到響應，才能 發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。
這樣就能夠做到同時并行發送多個請求，而不需要一個接一個地等待響應了。通俗地講，請求打包一次傳輸過去，響應打包一次傳遞回來。管線化的前提是在持久連接配接下。
假如當請求一個包含 10 張圖檔的 HTML Web 頁面，與挨個連接配接相比，用持久連接配接可以讓請求更快結束。 而管線化技術則比持久連接配接還要快。請求數越多，時間差就越明顯。用戶端需要請求這十個資源。以前的做法是，在同一個TCP連接配接裡面，先發送A請求，然後等待伺服器做出回應，收到後再發出B請求，以此類推，而管道機制則是允許浏覽器同時發出這十個請求，但是伺服器還是按照順序，先回應A請求，完成後再回應B請求。
于是在使用持久連接配接的情況下，某個連接配接上消息的傳遞類似于：
請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3
管線化方式發送變成了類似這樣：
請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3
參考
《圖解HTTP》[日] 上野宣 著