概述HTTP
HTTP協議是因特網的多媒體信使。HTTP可以從遍佈世界的Web服務器上將這些信息快迅速，便捷，可靠地搬移到人們桌面上的Web瀏覽器上去。
HTTP協議主要分Web客戶端和服務器。其中Web服務器是Web資源的宿主。Web資源可以包含任意媒體類型內容，HTTP協議爲了標識各種媒體類型，會給通過Web傳輸的對象都打上MIME類型的數據標籤格式。(MIME科普:最初設計MIME(Multipurpose Internet Mail Extension，多用途因特網郵件擴展)是爲了解決在不同的電子郵件系統之間搬移報文時存在的問題。HTTP隨後也採用了它，用他來描述並標記多媒體內容。)
同時，每個web服務器資源都有一個名字去標識，這被稱爲統一資源標識符(Uniform Resource Identifier)。URI有兩種類型，一種是我們常見的統一資源定位符URL，另外一種被稱爲統一資源名URN。後者仍處於試驗階段，未大範圍使用。
web頁面可以包含多個對象，如一個頁面會包括許多圖片，視頻，音頻等內容。客戶端通過向Web服務器發送請求命令來進行事務處理。服務器響應客戶端請求，並傳送相應數據。
請求和響應報文都有固定的規範。報文由一行一行簡單字符串組成的。HTTP報文都是純文本，而不是二進制代碼，所以人們可以很方便的進行讀寫(但難以解析)。報文分爲三部分
- 起始行 GET /index.html HTTP/1.0
- 首部字段 每個首部字段包含一個名字和一個值，爲了便於解析，兩者之間用冒號來分割。首部以一個空行結束。
- 主體 起始行和首部都是文本形式且都是結構化的，主體則可以包含任意的二進制數據，當然也可以包含文本。
HTTP協議的報文是通過傳輸控制協議(Transmission Control Protocol,TCP)連接從一個地方搬移到另外一個地方去的。
TCP提供了
- 無差錯的數據傳輸
- 按序傳輸 (數據總是會按照發送的順序到達)
- 未分段的數據流 (可以在任意時刻以任意尺寸將數據發送出去)
在HTTP客戶端向服務器發送報文之前，需要用網際協議(Internet Protocol,IP)地址和端口號在客戶端和服務器之間建立一條TCP/IP連接。首先需要將URL進行DNS解析成IP地址，再用IP地址連接Web服務器，默認端口是80。
除了客戶端與服務器之外，還有許多比較重要的Web結構組件
- 代理 位於客戶端和服務器之間的HTTP中間實體
- 緩存 HTTP的倉庫，使常用頁面的副本可以保存在離客戶端更近的地方
- 網關 連接其他應用程序的特殊Web服務器
- 隧道 對HTTP通信報文進行盲轉發的特殊代理
- Agent代理 發起自動HTTP請求的半智能Web客戶端
URL與資源
URL提供了一種統一的資源命名方式，大多數URL都有同樣的:”方案://服務器位置/路徑”結構。
URL的語法
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
幾乎沒有哪個URL包含了所有這些組件。
URL最重要的3個部分是方案(scheme)，主機(host)和路徑(path)。
URL編碼
轉義表示法包含一個百分號%，後面跟着兩個表示字符ASCII碼的十六進制數。
例子http://www.baidu.com/%7Ejoe ~ 126(0x7E)
HTTP報文
HTTP報文是在HTTP應用程序之間發生的數據塊。這些數據塊以一些文本形式的元信息(meta-information)開頭，這些信息描述了報文的內容及含義，後面跟着可選的數據部分。這些報文在客戶端，服務器和代理之間流動。
報文的語法
所有的報文都可以分爲兩類:請求報文(request message)和響應報文(response message)。
請求報文
<method> <request-URL> <version>
<headers>
<entity-body>響應報文
<version> <status> <reason-phrase>
<headers>
<entity-body>起始行
方法
| 方法 | 描述 |
|---|---|
| GET | 從服務器獲取一份文檔 |
| HEAD | 只從服務器獲取文檔的首部 |
| POST | 向服務器發送需要處理的數據 |
| PUT | 將請求的主體部分存儲在服務器上 |
| PUT | 對可能經過代理服務器傳送到服務器上去的報文進行追蹤 |
| OPTIONS | 決定可以在服務器上執行哪些方法 |
| DELETE | 從服務器上刪除一份文檔 |
並不是所有服務器都實現了上述7種方法，而且，由於HTTP設計的易於擴展，所以其他服務器可能還會實現一些自己的請求方法。
狀態碼
| 整體範圍 | 已定義範圍 | 分類 |
|---|---|---|
| 100 ~ 199 | 100~101 | 信息提示 |
| 200~299 | 200~206 | 成功 |
| 300~399 | 300~305 | 重定向 |
| 400~499 | 400~415 | 客戶端錯誤 |
| 500~599 | 500~505 | 服務器錯誤 |
當前的HTTP版本只爲每類狀態定義了幾個代碼，隨着協議的發展，HTTP規範中會正式的定義更多的狀態碼，如果收到了不認識的狀態碼，可能是有人將其作爲當前協議的擴展定義的。可以根據其所處範圍，將它作爲那個類別中一個普通的成員來處理。
首部
首部分類：
- 通用首部 既可以出現在請求報文中又可以出現在響應報文中
- 請求首部 提供更多有關請求的信息
- 響應首部 提供更多有關響應的信息
- 實體首部 描述主體的長度和內容，或者資源自身
- 擴展首部 規範中沒有定義的新首部
實體的主體部分
HTTP報文的第三部分是可選的實體主體部分。實體的主體是HTTP報文的負荷，就是HTTP要傳輸的內容。
連接管理
世界上幾乎所有的HTTP通信都是由TCP/IP承載的，TCP/IP是全球計算機及網絡設備都在使用的一種常用的分組交換網絡分層協議集。客戶端應用程序可以打開一條TCP/IP連接，連接到可能運行在世界任何地方的服務器應用程序。
web瀏覽器通過TCP連接與web服務器進行交互的流程
https://github.com:80/WilsonLiu95
1. 瀏覽器利用解析出主機名 github.com
2. 瀏覽器查詢這個主機名的IP地址 192.30.252.122
3. 瀏覽器獲得端口號 80
4. 瀏覽器發起到192.30.252.122端口80的連接
5. 瀏覽器向服務器發送一條HTTP GET報文
6. 瀏覽器從服務器讀取HTTP響應報文
7. 瀏覽器關閉TCP連接
HTTP事務的時延
與建立TCP連接，以及傳輸請求和響應報文的時間相比，事務處理時間可能是很短的。除非客戶端或服務器超載，或正在處理複雜的動態資源，否則HTTP時延就是由TCP網絡時延構成的。
HTTP事務時延的有以下幾種主要原因
1. 客戶端首先需要根據URI確定Web服務器的IP地址和端口號。其中IP地址需要通過DNS解析URL中的主機名獲得，這可能花費數十秒的時間。
2. 客戶端向服務器發送TCP連接請求，即著名的”三次握手”。這個值通常最多隻有一兩秒鐘，但如果有數百個HTTP事務的話，這個值就會快速疊加上去。
3. 因特網傳輸報文，以及服務器處理請求報文都需要花費時間。
4. web服務器回送HTTP響應也需要時間。
這些TCP網絡時延取決於硬件速度，網絡和服務器的負載，請求和響應報文的尺寸，以及客戶端和服務器之間的距離。TCP協議的技術複雜性也會對時延產生巨大的影響。
性能聚焦區域
一下是其餘一些會對HTTP產生影響，最常見的相關時延
1. TCP連接建立握手
2. TCP慢啓動擁塞控制
3. 數據聚焦的Nagle算法
4. 用於捎帶確認的TCP延遲確認算法
5. TIME_WAIT時延和端口耗盡
TCP連接建立握手
TCP連接握手需要經過一下幾個步驟
1. 酷虎的向服務器發送一個小的TCP分組(通常是40-60字節)。這個分組中設置了一個特殊的SYN標記，說明這是一個連接請求。
2. 如果服務器接收了連接，就會對一些連接參數進行計算，並向客戶端回送一個TCP分組，這個分組中的SYN和ACK標記都被置位了，說明連接請求已經被接收了。
3. 最後，客戶端向服務器回送一條確認信息，通知它連接已成功建立。現代的TCP棧都允許客戶端在這個確認分組中發送數據。
如果連接只用來傳送少量的數據，這些交換過程就會嚴重降低HTTP的性能。小的HTTP事務可能會在TCP建立上花費50%或者更多的時間。
延遲確認
每個TCP段都有一個序列號和數據完整性校驗和。每個段的接收者收到完好的段時，都會向發送者回送小的確認分組。如果發送者沒有在指定的窗口時間內收到確認信息，發送者就認爲分爲已被破壞或損毀，並重發數據。
爲了增加確認報文找到同向傳輸數據分組的可能性，很多TCP棧都實現了一種”延遲確認”算法。延遲確認算法會在一個特定的窗口時間(通常是100~200毫秒)內將輸出確認存放在緩衝區中，以尋找能夠捎帶它的輸出數據分組。如果在那個時間段內沒有輸出數據分組，就講確認信息放在單獨的分組中傳送。
通常，延遲確認算法會引入相當大的時延，所以可以調整或者禁止延遲確認算法。
TCP慢啓動
TCP數據傳輸的性能還取決於TCP連接的使用期(age)。TCP連接會隨着時間進行自我“調諧”，起初會限制連接的最大速度，如果數據成功傳輸，會隨着時間的推移提高傳輸的速度。這種調諧被稱爲TCP慢啓動(slow start)，用於防止因特網的突然過載和擁塞。
Nagle算法與TCP_NODELAY
Nagle算法鼓勵發送全尺寸(LAN上最大尺寸的分組大約是1500字節，在因特網上是幾百字節)的段。只有當所有其他的分組都被確認之後，Nagle才允許發送非全尺寸的分組，如果其他分仍然在傳輸過程中，就將那部分數據緩存起來。只有當掛起分組被確認，或者緩存中積累了足夠發送一個全尺寸分組的數據時，纔會將緩存的數據發送出去。
Nagle算法會引發幾種HTTP性能問題。首先小的HTTP報文無法填滿一個分組，可能會因爲等待那些永遠不會到來的額外數據而產生時延。其次，Nagle算法與延時確認之間的交互存在問題——Nagle會阻止數據的發送，直到有確認分組抵達爲止，但確認分組自身會被延遲確認算法延遲100-200毫秒。
因此，HTTP應用程序常常會在自己的棧中設置參數TCP_NODELAY,禁用Nagle算法，提高性能。
TIME_WAIT累計和端口耗盡
當某個TCP端點關閉TCP連接時，會在內存中維護一個小的控制塊，用來記錄最近所關閉連接的IP地址和端口號。這類信息會維持一小段時間，以確保在這段時間內不會創建於相同地址和端口號的新連接。
客戶端每次連接到服務器上去時，都會獲得一個新的端口號，以實現連接的唯一性。但由於可用的源端口數量有限，因此會出現端口耗盡的情況。就會無法建立新的連接。
解決辦法：增加客戶端負載生成機器的數量，或者確保客戶端和服務器在循環使用幾個虛擬的IP地址以增加更多的連接組合。
HTTP連接的處理
HTTP允許在客戶端和最終的源端服務器之間存在一串HTTP中間實體(代理，高速緩存等)。可以從客戶端開始，逐跳地將HTTP報文經過這些中間設備，轉發到源端服務器上去(或者進行反向傳輸)。
Connection首部
在某些情況下，兩個相鄰的HTTP應用程序會爲它們共享的連接應用一組選項。HTTP的Connection首部字段中有一個由逗號分隔的連接標籤列表，這些標籤爲此連接指定了一些不會傳播到其他連接中去的選項。
Connection首部可以承載3種不同類型的標籤
- HTTP首部字段名，列出了只與此連接有關的首部
- 任意標籤值，用於描述此連接的非標準選項
- 值close，說明操作完成之後需關閉這條持久連接
串行事務處理時延
如果支隊連接進行簡單的管理，TCP的性能時延可能會疊加起來。串行加載的另外一個缺點是，有些瀏覽器在對象加載完畢之前無法獲知對象的尺寸，而且它們可能需要尺寸信息來決定將對象放在屏幕的什麼位置上，所以在加載了足夠多的對象之前，無法在屏幕上顯示任何內容。
以下爲4種提高HTTP連接性能的技術。
- 並行連接 通過多條TCP連接發起併發的HTTP請求
- 持久連接 重用TCP連接，以消除連接及關閉時延
- 管道化連接 通過共享的TCP連接發起併發的HTTP請求
- 複用的連接 交替傳送請求和響應報文 (實驗階段)
並行連接
HTTP允許客戶端打開多條連接，並行地執行多個HTTP事務。
並行連接可以提高符合頁面的傳輸速度，但並行連接也有一些缺點:
1. 每個事務都會打開/關閉一條新的連接，好耗費時間和帶寬
2. 由於TCP慢啓動特性的存在，每條新連接的性能會有所降低
3. 可打開的並行連接數量實際上是有限的
持久連接
Web客戶端經常會打開到同一個站點的連接。因此，初始化了對某服務器的HTTP請求的應用程序很可能會在不久的將來對那臺服務器發起更多的請求。這種性質被稱爲站點局部性。
因此，HTTP/1.1允許HTTP設備在事務處理結束之後將TCP連接保持在打開狀態，以便爲將來的HTTP請求重用現存的連接。
在事務處理結束之後仍然保持在打開狀態的TCP連接被稱爲持久連接。非持久連接會在每個事務結束之後關閉。持久連接會在不同事務之間保持打開狀態，直到客戶端或服務器決定將其關閉爲止。
重用已對目標服務器打開的空閒持久連接，就可以避開緩慢的連接建立階段。而且，已經打開的連接還可以避免慢啓動的擁塞適應階段，以便更快速地進行數據的傳輸。
持久連接有一些比並行連接更好的地方。持久連接降低了時延和連接建立的開銷，將連接保持在已調諧狀態，而且減少了打開連接的潛在數量。(持久連接有兩種類型:比較老的HTTP/1.0+ “keep-alive”連接，以及現代的HTTP/1.1 “persistent”連接)
並行連接與持久連接配合使用可能是最高效的方式。
管道化連接
允許在持久連接上可選的使用請求管道，這是相對於keep-alive連接的又一性能優化。
在響應到達之前，可以將多條請求放入隊列。當第一條請求通過網絡流向地球另一端的服務器時，第二條和第三條請求也可以開始發送了。在高時延網絡條件下，這樣做可以降低網絡的環回時間。
總結
本文爲《http權威指南》的第一部分，由第一到四章組成，介紹了HTTP的基礎構件和HTTP的核心技術。希望大家能夠喜歡。
