http 協議是網際網路的基礎協議，它是基於 tcp/ip 協議(傳輸層協議)的應用層協議，不涉及資料報傳輸，主要規定了客戶端和伺服器之間的通訊格式，預設使用80埠，是一種請求/響應式的協議，客戶端與伺服器建立連線後，傳送乙個請求給伺服器，伺服器接到請求後，給予相應的響應資訊。
http/1.0 版的主要缺點是：每個tcp連線只能傳送乙個請求。傳送資料完畢，連線就關閉，如果還要請求其他資源，就必須再新建乙個連線。
tcp連線的新建成本很高，因為需要客戶端和伺服器三次握手，並且開始時傳送速率較慢。所以，http 1.0版本的效能比較差。隨著網頁載入的外部資源越來越多，這個問題就愈發突出了。
為了解決這個問題，有些瀏覽器在請求時，用了乙個非標準的connection欄位。
connection: keep-aliveconnection: keep-alive由請求行、請求頭欄位、乙個空行和訊息主體構成。
請求行
請求訊息的第一行就是請求行。它指明使用的請求方法、資源標示符、和 http 版本。如：
get /demo.htm http/1.1請求方法用來定義操作資源的方式，http/1.1 協議中定義了八種請求方法：
請求頭欄位
空行
指示頭字段區完成，訊息主體開始（如果有訊息主體的話）。
訊息主體
訊息主體是請求訊息的承載資料。比如在提交post表單，並且表單方法不是get時，表單資料就是打包在訊息主體內的。訊息主體是可選的。
狀態行
由http版本、狀態碼、狀態描述文字構成。如：
http/1.1 200 okhttp 狀態碼是用以表示網頁伺服器 http 響應狀態的3位數字**。 所有的狀態碼的第乙個數字代表了響應的五種狀態之一:
常見狀態碼有：
http1.1 版的最大變化，就是引入了持久連線，即tcp連線預設不關閉，可以被多個請求復用，不用宣告connection: keep-alive。
客戶端和伺服器發現對方一段時間沒有活動，就可以主動關閉連線。不過，規範的做法是，客戶端在最後乙個請求時，傳送connection: close，明確要求伺服器關閉tcp連線。
connection: closehttp1.1 版還引入了管道機制，即在同乙個tcp連線裡面，客戶端可以同時傳送多個請求。這樣就進一步改進了http協議的效率。
舉例來說：客戶端需要請求兩個資源。以前的做法是，在同乙個tcp連線裡面，先傳送a請求，然後等待伺服器做出回應，收到後再發出b請求。管道機制則是：允許瀏覽器同時發出a請求和b請求，但是伺服器還是按照順序，先回應a請求，完成後再回應b請求。
乙個tcp連線現在可以傳送多個回應，勢必就要有一種機制，區分資料報是屬於哪乙個回應的。這就是content-length欄位的作用，宣告本次回應的資料長度。
content-length: 3495在1.0版中，content-length欄位不是必需的，因為瀏覽器發現伺服器關閉了tcp連線，就表明收到的資料報已經全了。
使用content-length欄位的前提條件是，伺服器傳送回應之前，必須知道回應的資料長度。
對於一些很耗時的動態操作來說，這意味著，伺服器要等到所有操作完成，才能傳送資料，顯然這樣的效率不高。更好的處理方法是，產生一塊資料，就傳送一塊，採用」流模式」（stream）取代」快取模式」（buffer）。
因此，1.1版規定可以不使用content-length欄位，而使用」分塊傳輸編碼」。只要請求或回應的頭資訊有transfer-encoding欄位，就表明回應將由數量未定的資料塊組成。
transfer-encoding: chunked另外，客戶端請求的頭資訊新增了host欄位，用來指定伺服器的網域名稱。
host: www.example
.com
雖然1.1版允許復用tcp連線，但是同乙個tcp連線裡面，所有的資料通訊是按次序進行的。伺服器只有處理完乙個回應，才會進行下乙個回應。要是前面的回應特別慢，後面就會有許多請求排隊等著。這稱為」隊頭堵塞」。
為了避免這個問題，只有兩種方法：一是減少請求數，二是同時多開持久連線。這導致了很多的網頁優化技巧，比如合併指令碼和樣式表、將嵌入css**、網域名稱分片等等。如果http協議設計得更好一些，這些額外的工作是可以避免的。
2023年，谷歌公開了自行研發的 spdy 協議，主要解決 http/1.1 效率不高的問題。
這個協議在chrome瀏覽器上證明可行以後，就被當作 http/2 的基礎，主要特性都在 http/2 之中得到繼承。
http/1.1 版的頭資訊肯定是文字（ascii編碼），資料體可以是文字，也可以是二進位制。http/2 則是乙個徹底的二進位制協議，頭資訊和資料體都是二進位制，並且統稱為」幀」（frame）：頭資訊幀和資料幀。
二進位制協議的乙個好處是，可以定義額外的幀。http/2 定義了近十種幀，為將來的高階應用打好了基礎。如果使用文字實現這種功能，解析資料將會變得非常麻煩，二進位制解析則方便得多。
http/2 復用tcp連線，在乙個連線裡，客戶端和瀏覽器都可以同時傳送多個請求或回應，而且不用按照順序一一對應，這樣就避免了」隊頭堵塞」。
舉例來說，在乙個tcp連線裡面，伺服器同時收到了a請求和b請求，於是先回應a請求，結果發現處理過程非常耗時，於是就傳送a請求已經處理好的部分， 接著回應b請求，完成後，再傳送a請求剩下的部分。
這樣雙向的、實時的通訊，就叫做多工（multiplexing）。
因為 http/2 的資料報是不按順序傳送的，同乙個連線裡面連續的資料報，可能屬於不同的回應。因此，必須要對資料報做標記，指出它屬於哪個回應。
http/2 將每個請求或回應的所有資料報，稱為乙個資料流。每個資料流都有乙個獨一無二的編號。資料報傳送的時候，都必須標記資料流id，用來區分它屬於哪個資料流。另外還規定，客戶端發出的資料流，id一律為奇數，伺服器發出的，id為偶數。
資料流傳送到一半的時候，客戶端和伺服器都可以傳送訊號（rst_stream幀），取消這個資料流。1.1版取消資料流的唯一方法，就是關閉tcp連線。這就是說，http/2 可以取消某一次請求，同時保證tcp連線還開啟著，可以被其他請求使用。
客戶端還可以指定資料流的優先順序。優先順序越高，伺服器就會越早回應。
http 協議不帶有狀態，每次請求都必須附上所有資訊。所以，請求的很多欄位都是重複的，比如cookie和user agent，一模一樣的內容，每次請求都必須附帶，這會浪費很多頻寬，也影響速度。
http/2 對這一點做了優化，引入了頭資訊壓縮機制（header compression）。一方面，頭資訊使用gzip或compress壓縮後再傳送；另一方面，客戶端和伺服器同時維護一張頭資訊表，所有欄位都會存入這個表，生成乙個索引號，以後就不傳送同樣欄位了，只傳送索引號，這樣就提高速度了。
http/2 允許伺服器未經請求，主動向客戶端傳送資源，這叫做伺服器推送（server push）。
常見場景是客戶端請求乙個網頁，這個網頁裡面包含很多靜態資源。正常情況下，客戶端必須收到網頁後，解析html原始碼，發現有靜態資源，再發出靜態資源請求。其實，伺服器可以預期到客戶端請求網頁後，很可能會再請求靜態資源，所以就主動把這些靜態資源隨著網頁一起發給客戶端了。
http 協議入門
https 公升級指南
http,http2.0,spdy,https你應該知道的一些事
http 協議簡介
超文字傳輸協議（http）介紹
HTTP協議學習總結
http 協議是網際網路的基礎協議，它是基於 tcp ip 協議 傳輸層協議 的應用層協議，不涉及資料報傳輸，主要規定了客戶端和伺服器之間的通訊格式，預設使用80埠，是一種請求 響應式的協議，客戶端與伺服器建立連線後，傳送乙個請求給伺服器，伺服器接到請求後，給予相應的響應資訊。缺點 http 1.0...
HTTP協議總結
http協議是一種物件導向的協議，其簡單，快捷，方便，實用與分布式資訊網路管理系統 http協議的特點有 1.支援 c s和b s 支援客戶 伺服器模式 2.簡單快捷 向服務端請求時只需傳遞請求的方式 post,get,head,delete等 3.靈活 在傳遞時只需要在content type中定...
HTTP協議總結
http是應用層協議，由http客戶端發起乙個請求，建立乙個到伺服器指定埠的tcp連線。http 伺服器則在埠監聽客戶端的請求，一旦受到請求就會向客戶端返回乙個狀態 200，500等 以及返回內容。注 http是乙個無狀態的協議，通過伺服器認證後成功請求了乙個資源後再次請求這一資源時，伺服器仍舊會要...