- 報文分爲請求報文和響應報文，是 HTTP 通信中的基本單位，由 8 位組字節流組成。
- 報文分爲報文頭部、空行和報文主體。
- 報文主體是可選的，如一個 GET 請求報文中，就沒有報文主體。
- 實體其實是報文的一部分，存在於報文主體內，作爲請求或響應的有效載荷數據被傳輸。
- 實體的內容由實體首部和實體主體組成。實體主體是我們想要傳輸的實際信息，實體首部是對該信息的描述。
- 通常，報文主體等於實體主體。只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異。
- 一個報文裏一個包含多個實體，實體裏，也有實體頭部、實體主體，同樣是通過CR+LF分割。
- 常用的內容編碼有以下幾種。
- gzip（GNU zip）
- compress（UNIX 系統的標準壓縮）
- deflate（zlib）
- identity（不進行編碼）
- 在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱爲 分塊傳輸編碼.
- HTTP 協議中也採納了 多部分對象集合(Multipart)，發送的一份報文主體內可含有多類型實體。通常是在圖片或文本文件等上傳時使用。
- 以前，如果下載過程中遇到網絡中斷的情況，那就必須重頭開始。爲了解決上述問題，需要一種可恢復的機制。所謂恢復是指能從之前下載中斷處恢復下載。
- 要實現該功能需要指定下載的實體範圍。像這樣，指定範圍發送的請求叫做 範圍請求（Range Request）。
- 針對範圍請求，響應會返回狀態碼爲206 Partial Content的響應報文。如果服務器端無法響應範圍請求，則會返回狀態碼200 OK 和完整的實體內容。
- 當瀏覽器的默認語言爲英語或中文，訪問相同 URI 的 Web 頁面時，則會顯示對應的英語版或中文版的 Web 頁面。這樣的機制稱爲內容協商（Content Negotiation）。
- 內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，然後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等作爲判斷的基準。
- 內容協商技術有以下 3 種類型。
- 服務器驅動協商（Server-driven Negotiation）：由服務器端進行內容協商。以請求的首部字段爲參考，在服務器端自動處理。
- 客戶端驅動協商（Agent-driven Negotiation）：由客戶端進行內容協商的方式。用戶從瀏覽器顯示的可選項列表中手動選擇。
- 透明協商（Transparent Negotiation）：是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。
- HTTP 狀態碼負責表示客戶端 HTTP 請求的返回結果，標記服務器端的處理是否正常，通知出現的錯誤等工作。
- 藉助狀態碼，用戶可以知道服務器端是正常處理了請求，還是出現了錯誤。
- 狀態碼的類別如下：
| 狀態碼 | 類別 | 原因短語 |
|---|---|---|
| 1XX | Informational 信息性狀態碼 | 接收的請求正在處理 |
| 2XX | Success 成功狀態碼 | 請求正常處理完畢 |
| 3XX | Redirection 重定向狀態碼 | 需要進行附加以完成請求 |
| 4XX | Client Error 客戶端錯誤狀態碼 | 服務器無法處請求 |
| 5XX | Server Error 服務器狀態碼 | 服務器處理請求出錯 |
- 只要遵守狀態碼類別的定義，即使改變 RFC2616 中定義的狀態碼，或服務器端自行創建狀態碼都沒問題。
- 在響應報文內，隨狀態碼一起返回的信息會因方法的不同而發生改變。
- 一些常見的 HTTP 狀態碼
| 狀態碼 | 含義 |
|---|---|
| 200 OK | 請求已經正常處理 |
| 204 No Content | 響應報文中不含也不允許返回任何實體的主體 |
| 206 Partial Content | 響應報文中包含由 Content-Range 指定範圍的實體內容 |
| 301 Moved Permanently | 請求的資源已被永久性分配了新的URI: Location 首部字段提示的 URI |
| 302 Found | 臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問。 |
| 303 See Other | 請求對應的資源存在着另一個 URI，應使用 GET 方法定向獲取請求的資源。 |
| 304 Not Modified | 客戶端發送附帶條件的請求時，服務器端允許請求訪問資源，但因發生請求未滿足條件 |
| 307 Temporary Redirect | 臨時重定向。該狀態碼與 302 Found 有着相同的含義 |
| 400 Bad Request | 請求報文中存在語法錯誤 |
| 401 Unauthorized | 發送的請求需要有通過 HTTP認證（BASIC認證、DIGEST認證）的認證信息。 另外若之前已進行過 1 次請求，則表示用戶認證失敗。 |
| 403 Forbidden | 請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由 |
| 404 Not Found | 服務器上無法找到請求的資源。或服務器端拒絕請求且不想說明理由時使用。 |
| 500 Internal Server Error | 服務器端在執行請求時發生了錯誤。也有可能是 Web 應用存在的 bug 或某些臨時的故障。 |
| 503 Service Unavailable | 服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。 |
- 即使物理層面只有一臺服務器，但只要使用虛擬主機的功能，則可以假想已具有多臺服務器。
- 虛擬主機（Virtual Host，又稱虛擬服務器）。
- 如果一臺服務器內託管了 www.tricorder.jp 和 www.hackr.jp 這兩個域名，當收到請求時就需要弄清楚究竟要訪問哪個域名。在相同的 IP 地址下，由於虛擬主機可以寄存多個不同主機名和域名的 Web 網站，因此在發送 HTTP 請求時，必須在 Host 首部內完整指定主機名或域名的 URI。
- HTTP 通信時，除客戶端和服務器以外，還有一些用於通信數據轉發的應用程序，例如代理、網關和隧道。它們可以配合服務器工作。這些應用程序和服務器可以將請求轉發給通信線路上的下一站服務器，並且能接收從那臺服務器發送的響應再轉發給客戶端。
- 代理：代理是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端“中間人”的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。
- 網關：網關是轉發其他服務器通信數據的服務器，接收從客戶端發送來的請求時，它就像自己擁有資源的源服務器一樣對請求進行處理。有時客戶端可能都不會察覺，自己的通信目標是一個網關。
- 隧道：隧道是在相隔甚遠的客戶端和服務器兩者之間進行中轉，並保持雙方通信連接的應用程序。
- 代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。
- 持有資源實體的服務器被稱爲源服務器。
- 每次通過代理服務器轉發請求或響應時，會追加寫入 Via 首部信息。
- 使用代理服務器的理由有：利用緩存技術減少網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的，等等。
- 代理有多種使用方法，按兩種基準分類。一種是是否使用緩存，另一種是是否會修改報文。
- 緩存代理：代理轉發響應時，緩存代理（Caching Proxy）會預先將資源的副本（緩存）保存在代理服務器上。 當代理再次接收到對相同資源的請求時，就可以不從源服務器那裏獲取資源，而是將之前緩存的資源作爲響應返回。
- 透明代理轉發請求或響應時，不對報文做任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。
- 網關的工作機制和代理十分相似。而網關能使通信線路上的服務器提供非 HTTP 協議服務。
- 利用網關能提高通信的安全性，因爲可以在客戶端與網關之間的通信線路上加密以確保連接的安全。 比如，網關可以連接數據庫，使用 SQL 語句查詢數據。另外，在 Web 購物網站上進行信用卡結算時，網關可以和信用卡結算系統聯動。
- 隧道可按要求建立起一條與其他服務器的通信線路，屆時使用 SSL 等加密手段進行通信。隧道的目的是確保客戶端能與服務器進行安全的通信。
- 隧道本身不會去解析HTTP請求。也就是說，請求保持原樣中轉給之後的服務器。隧道會在通信雙方斷開連接時結束。
- 通過隧道的傳輸，可以和遠距離的服務器安全通信。隧道本身是透明的，客戶端不用在意隧道的存在。
- 緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減少對源服務器的訪問，因此也就節省了通信流量和通信時間。緩存服務器是代理服務器的一種，並歸類在緩存代理類型中。
- 緩存服務器的優勢在於利用緩存可避免多次從源服務器轉發資源。因此客戶端可就近從緩存服務器上獲取資源，而源服務器也不必多次處理相同的請求了。
- 即使存在緩存，也會因爲客戶端的要求、緩存的有效期等因素，向源服務器確認資源的有效性。若判斷緩存失效，緩存服務器將會再次從源服務器上獲取“新”資源。
- 緩存不僅可以存在於緩存服務器內，還可以存在客戶端瀏覽器中。 以 Internet Explorer 程序爲例，把客戶端緩存稱爲臨時網絡文件（Temporary Internet File）。
- 瀏覽器緩存如果有效，就不必再向服務器請求相同的資源了，可以直接從本地磁盤內讀取。