1、HTTP報文大致可分為報文首部和報文主體兩塊。兩者由最初出現的空行（CE+LF）來划分。通常，並不一定要有報文主體。
2、請求報文和響應報文的結構
請求行：包含用於請求的方法，請求URI和HTTP版本
狀態行：包含表明響應結果的狀態碼，原因短語和HTTP版本
首部字段：包含表示請求和響應的各種條件和屬性的各類首部（通用首部、請求首部、響應首部和實體首部）
其他：可能包含HTTP的RFC里未定義的首部（Cookie等）
3、HTTP在傳輸數據時，可以按照數據原貌直接傳輸，但也可以在傳輸過程中通過編碼提升傳輸速率。但是編碼會消耗更多的CPU資源。
報文：HTTP通信中的基本單位，由8位組字節流組成，通過HTTP通信傳輸。
實體：作為請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。
HTTP報文的主體用於傳輸請求或響應的實體主體。
通常報文主體等於實體主體，只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異。
內容編碼：指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼后的實體由客戶端接收並負責解碼。
常用的內容編碼有：gzip（GUN zip）、compress（UNIX系統的標准壓縮）、deflate（zlib）、identity（不進行編碼）
分塊傳輸編碼：在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面而不用等到全部傳輸完畢再顯示。每一塊都會用十六進制來標記塊的大小，而實體主體的最后一塊會使用“0（CE+LF）”來標記。
傳輸編碼：可以在通信時按某種編碼方式傳輸，但只定義作用於分塊傳輸編碼中。
4、發送多種數據的多部分對象集合：HTTP協議采納了多部分對象集合，發送的一份報文主體內可含有多類型實體，通常是在圖片或文本文件等上傳時使用。
- multipart/form-data：在web表單文件上傳時使用
- multipart/byteranges：狀態碼206（Partial Content，部分內容）響應報文包含了多個范圍的內容時使用
在HTTP報文中使用多部分對象集合時，需要在首部字段里加上Content-type，boundary用於划分多部分對象集合指明的各類實體。在boundary字符串指定的各個實體的起始行之前插入“--”標記（如：--AaB03x--、--THIS_STRING_SEPARATES），在多部分對象集合對應的字符串的最后插入“--”標記（如：--AaB03x--、--THIS_STRING_SEPARATES--）作為結束。
5、獲取部分內容的范圍請求
執行范圍請求時，會用到首部字段Range來指定資源的byte范圍，例如
針對范圍請求，響應會返回狀態碼為206的響應報文，如果服務器無法響應范圍請求，則會返回狀態碼200 OK和完整的實體內容。
6、內容協商返回最合適的內容。
內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，然后提供給客戶端最為適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等作為判斷的基准
內容協商的類型：
服務器驅動協商：由服務器端進行內容協商，以請求的首部字段為參考，在服務端自動處理。對用戶來說，以瀏覽器發送的信息作為判定的依據，並不一定能篩選出最優內容。
客戶端驅動協商：用戶從瀏覽器顯示的可選列表中手動選擇，還可以利用JavaScript腳本在web頁面上自動進行上述選擇。
透明協商：由服務器端和客戶端各自進行內容協商的一種方法。