相較于HTTP 1.0，1.1 版本增加了以上特性：

1. 新增了連接管理即 keepalive，允許持久連接。

定義：

Keepalive允許客戶端和服務器在完成一次請求-響應后，保持連接處于打開狀態，以便后續請求復用同一連接，而無需重新建立連接。

工作原理：

1. 客戶端通過TCP三次握手與服務器建立連接。
2. 客戶端發送HTTP請求，服務器處理后返回響應。
3. 服務器不會立即關閉連接，而是保持空閑狀態，等待后續請求。
4. 如果客戶端在預設時間內發送新的請求，服務器將復用此連接。
5. 超過空閑時間后，服務器會關閉連接以節省資源。

優勢：

6. 減少連接開銷： 避免了頻繁的TCP連接建立和關閉，節省時間和帶寬。
7. 提升性能： 特別適用于需要多個小請求的場景，如加載多張圖片或腳本。

2. 支持pipeline，無需等待前面的請求響應，即可發送第二次請求。

定義：

Pipeline允許客戶端在一個連接中連續發送多個HTTP請求，而無需等待前一個響應。

工作原理：

1. 客戶端在同一個連接中發送多個請求。
2. 服務器按順序處理請求，并依次返回響應。
3. 客戶端在發送完所有請求后，等待服務器按順序返回響應。

優勢：

• 減少延遲： 減少等待時間，尤其在高延遲網絡中效果顯著。
• 提高吞吐量： 客戶端可以并行發送請求，提高整體傳輸效率。

注意事項：

• 服務器處理順序： 響應必須按請求順序返回，服務器無法重新排序。
• 潛在問題： 管道中的任何一個請求失敗可能導致后續請求處理延遲或失敗。

3. 支持分塊傳輸編碼（Chunked Transfer Coding）

在HTTP協議中允許服務器將響應分成多個塊發送，而無需提前知道內容的總長度。這在處理大型文件時特別有用，因為它提高了傳輸效率，減少了客戶端等待時間。

以下是一個簡明的示例：客戶端請求從服務器下載一個10GB的視頻文件。

傳統方法（無分塊傳輸）：

1. 客戶端發送HTTP GET請求到服務器。
2. 服務器處理請求，開始讀取視頻文件。
3. 服務器計算整個文件的大小，并在響應頭中設置Content-Length: 10737418240（10GB）。
4. 服務器將整個文件一次性發送給客戶端。
5. 客戶端等待接收完整個文件后，才能開始播放。

分塊傳輸方法：

1. 客戶端發送HTTP GET請求，支持接受分塊傳輸。
2. 服務器開始處理請求，并將視頻文件分割成多個塊（例如，每塊1MB）。
3. 服務器在響應頭中設置Transfer-Encoding: chunked，指示使用分塊傳輸，不設置Content-Length。
4. 服務器開始發送第一個塊，包含塊的大小（以十六進制表示）和塊數據。
5. 客戶端接收到每個塊后，立即開始處理（如播放視頻），無需等待所有塊傳輸完成。
6. 服務器發送完最后一個塊后，發送一個0大小的塊，表示傳輸結束（EOF）。
7. 客戶端完成接收，處理完成。

優點：

客戶端可以邊下載邊處理，提升用戶體驗。
服務器無需預先計算總長度，減少延遲。
節省內存，適用于大數據傳輸。

總結：

分塊傳輸編碼在處理大文件時顯著提升了效率，減少了等待時間，適用于流媒體、大型文件下載等場景。

4. 新增緩存的控制和管理。

HTTP/1.1中，緩存控制和管理主要通過以下機制實現：

1. Cache-Control頭部（用于控制緩存行為，如緩存有效期、緩存范圍等。）

• max-age=[seconds]：指定資源在緩存中的有效時間。
• s-maxage=[seconds]：針對共享緩存（如CDN）的有效時間
• no-cache：強制每次請求都驗證資源是否過期。
• no-store：禁止緩存任何內容。
• public和private：分別允許或限制第三方緩存。

2. ETag頭部（提供資源的唯一標識，用于驗證資源是否更改。）

• 工作原理：當客戶端再次請求資源時，會發送If-None-Match頭部，服務器通過ETag判斷資源是否過期，若未變化則返回304狀態碼。

3. Last-Modified頭部（指示資源的最后修改時間。）

• 工作原理：客戶端在請求中包含If-Modified-Since頭部，服務器比較時間戳，若資源未更改則返回304狀態碼。

4. 緩存驗證機制

• 強緩存：直接使用緩存內容，無需服務器驗證。
• 協商緩存：客戶端攜帶緩存驗證信息（如ETag或Last-Modified），服務器確認資源是否過期后，決定是否返回新內容。

5. 緩存有效期管理

• 過期時間：通過Cache-Control設置資源的緩存時長，過期后客戶端會重新請求資源。
• 服務器處理：服務器在接收到過期緩存請求時，會重新生成響應，確保客戶端獲得最新內容。

6. 緩存控制策略

• 合理設置緩存時間：根據資源更新頻率，設置適當的max-age值，平衡緩存和更新需求。
• 使用ETag提升效率：避免頻繁的全響應，通過ETag快速判斷資源是否變化。
• 靈活運用Cache-Control指令：根據資源類型（如公開或私有）選擇合適的緩存策略。

通過以上機制，HTTP/1.1有效地管理了緩存，提升了資源加載速度，減少了服務器負載。合理配置這些頭部和機制，可以顯著優化網站性能和用戶體驗。

5. 加入host頭

在HTTP/1.1協議中，Host頭字段的作用非常重要，主要體現在以下幾個方面：

標識目標服務器：

Host頭字段指定了請求的目標服務器的域名和端口號（如果端口號非默認）。例如，Host: www.example.com表示請求的目標是www.example.com服務器。這使得服務器能夠根據域名確定請求的來源，特別是在虛擬主機環境中，多個網站可以共享同一個IP地址，但通過不同的Host頭來區分不同的域名。

支持虛擬主機：

通過Host頭，服務器可以托管多個網站，每個網站使用不同的域名。當一個請求到達服務器時，服務器會解析Host頭，從而確定應該將請求路由到哪個虛擬主機上，提供相應的資源。這極大提高了服務器資源的利用率。

路由和定位資源：

服務器根據Host頭來確定請求的目標資源。這有助于服務器正確地路由請求，確保請求能夠到達正確的應用程序或服務。例如，一個服務器可能托管多個應用程序，每個應用程序對應不同的域名，通過Host頭可以實現精準的路由。

安全性：

Host頭還用于防止某些類型的攻擊，如HTTP頭注入攻擊。通過驗證Host頭的值，服務器可以確保請求的來源是合法的，從而增強安全性。

區分大小寫：

雖然域名通常以小寫顯示，但Host頭是區分大小寫的。理論上，不同的大小寫可能指向不同的資源，但大多數情況下，服務器會將大小寫視為不敏感。

不包含路徑信息：

Host頭只包含域名和端口號，不包含請求的路徑信息。路徑信息在URI中指定，Host頭的作用是明確請求的目標服務器，而路徑則用于定位具體資源。

總結：

Host頭在HTTP/1.1中起到了至關重要的作用，它不僅幫助服務器識別請求的目標，還支持虛擬主機的實現，提高資源利用率，同時增強安全性。正確配置和使用Host頭是確保HTTP通信正常進行的關鍵。

6. 名詞解釋

EOF：End of File，這是一個關鍵的信號，用于指示文件傳輸的結束。