HTTP權威指南筆記

讀書有兩種境界，第一種境界是將書讀薄，另一種是讀厚。本篇文章就是HTTP權威指南的讀書筆記，算是讀書的第一重境界，將厚書讀薄。文章對HTTP的一些關鍵概念做了比較詳細的概述，通讀一遍之後，會對HTTP有個總體認識。然後你可以根據文章中的關鍵點，去查詢更詳細的細節。這就是讀書的第二重境界，將書讀厚。

HTTP（hypertext transfer protocol，超文字傳輸協議）是全球資訊網進行通訊時所使用的協議方案。HTTP有很多應用，但最著名的是用於Web瀏覽器和Web伺服器之間的雙工通訊。

HTTP概述

Web瀏覽器、伺服器和相關的Web應用程式都是通過HTTP相互通訊。HTTP是現代全球因特網中使用的公共語言。

HTTP-因特網的多媒體信使

每天都有數億JPEG圖片、HTML頁面、文字檔案、MPEG電影、WAV音訊檔案、java小程式和其他資源在因特網遊弋。HTTP可以從全世界的Web伺服器上將這些資訊迅速、便捷、可靠的傳輸到Web瀏覽器上。
HTTP使用的是可靠的資料傳輸協議，它能夠確保資料在傳輸過程中不會被損壞或者產生混亂。對開發容易來說，無需擔心HTTP通訊會在傳輸過程中被破壞、複製或者產生畸變。開發人員可以專注於程式特有細節的編寫，而不是考慮因特網中存在的一些缺陷和問題。

Web客戶端和伺服器

Web內容都是儲存在Web伺服器上。Web伺服器使用HTTP協議，因此還可以稱為HTTP伺服器。HTTP客戶端向伺服器發出請求，伺服器會在HTTP響應中回送所請求的資料。

最常見的HTTP客戶端就是瀏覽器。瀏覽器向伺服器請求HTTP物件，並將物件顯示在螢幕上。

媒體型別

因特網有很多的資料型別，HTTP給每種要通過Web傳輸的物件都打上MIME型別（MIME type）的資料格式標籤。最初設計MIME(Multipurpose Internet Mail Extension,多用途因特網郵件擴充套件)是為了解決不同電子郵件系統之家搬移報文時存在的問題。
Web伺服器會為所有的HTTP物件資料附一個MIME型別。當Web瀏覽器從伺服器取回一個物件時，會去檢視相關的MIME型別，看看它是否知道應該如何處理這個物件。大多數瀏覽器都可以處理上百種常見物件：顯示圖片、解析並格式化HTML檔案、播放音訊檔案、或者執行外部軟體來處理特殊格式資料。
MIME型別是一種文字標記，表示一種主要的物件型別和一個特定的子型別，中間由一條斜槓來分隔。
例如：HTML格式的文字文件 text/html型別來標記。
詳細的MIME學習可以參考

URI

每個Web伺服器都有一個名字，這樣客戶端就可以說明它們感興趣的資源是什麼。伺服器資源名被統一稱為統一資源識別符號（Uniform Resource Identifier，URI）。URI有兩種形式：分別是URL和URN。

• URL

  統一資源定位符（URL,Uniform Resource Locator）是資源識別符號最常見的形式。
  

大部分URL都遵循一種標準格式，這種格式包含三個部分。
1.URL的第一部分稱為方案（scheme），說明訪問資源所使用的協議型別。這部分通常是HTTP或者HTTPS（http://)。
2.第二部分給出了伺服器的因特網地址（www.joes-hardware.com）。
3.其餘部分指定了Web伺服器上的某個資源（比如，/specials/saw-blade.gif）。
現在幾乎所有的URI都是URL。

• URN

  URI的第二種形式就是URN（統一資源名）。URN是作為特定內容的唯一名稱使用的，與目前的資源所在地無關。使用這些與>位置無關的URN，就可以將資源四處搬動。通過URN，還可以用同一個名字通過多種網路訪問協議來訪問資源。
  URN仍然處於試驗階段，還未大範圍使用。除非特殊說明，否則這裡的都是用URL來指定URI。

事務

一個HTTP事務由一條請求命令和一個響應結果組成。這種通訊通過名為HTTP報文（HTTP message）的格式化資料塊進行。

• 方法

  HTTP支援幾種幾種不同的請求命令，這些命令被稱為HTTP方法（HTTP method）。每條HTTP請求報文都包含一個方法。這個方法會告訴伺服器要執行什麼動作（獲取一個Web頁面、執行一個閘道器程式、刪除一個檔案等）。
  常見的HTTP方法：

• 狀態碼

  每條HTTP響應報文返回時都會攜帶一個狀態碼。狀態碼是一個三位數字的程式碼，告知客戶端請求是否成功，或者是否需要採取其他動作。
  常見的HTTP狀態碼：

• Web頁面可以包含多個物件

  應用程式完成一項任務時通常會發布多個HTTP事務。比如，Web瀏覽器會發布一系列的HTTP事務來獲取並顯示一個包含豐富圖片的Web頁面。瀏覽器會執行一個事務來獲取描述頁面佈局的HTML”框架“，然後釋出另外的HTTP事務來獲取每個嵌入式圖片、影象面板、Java小程式等。這些嵌入式資源甚至可能位於不同的伺服器。因此，一個Web頁面通常並不是單個資源，而是一組資源的集合。

報文

HTTP報文都是由一行行的簡單字串組成。HTTP報文都是純文字，不是二進位制程式碼。

從Web客戶端發往Web伺服器的HTTP報文稱為請求報文（request message）。從伺服器發往客戶端的報文稱為響應報文（reponse message），此外沒有其他型別的HTTP報文。請求報文和響應報文格式類似。
HTTP報文包括以下三部分：

• 起始行

  報文的第一行就是起始行，在請求報文中用來說明要做些什麼，在響應報文中說明出現了什麼情況。

• 首部欄位

  起始行後面有0個或者多個首部欄位。每個欄位都包含一個名字和一個值，為了便於解析，兩者之間用冒號（：）分隔。首部以一個空行結束。新增一個首部欄位和新增新行一樣簡單。

• 主體

  空行之後就是可選的報文主體了，其中包含了所有型別的資料。請求主體中包括了要發給Web伺服器的資料，響應主體中裝載了要返回給客戶端的資料。起始行和首部都是文字形式且都是結構化的，而主體則不同，主體可以包含任意的二進位制資料（圖片、視訊、音訊、軟體程式）。當然，主體還可以包含文字。

  連線

• TCP/IP

  HTTP是個應用層協議。HTTP無需關心網路通訊的具體細節；它把聯網的細節都給了通用、可靠的因特網傳輸協議TCP/IP。
  TCP提供了：

  • 無差錯的資料傳輸。
  • 按序傳輸（資料總是按照發送的順序到達）；
  • 分段的資料流（可以在任意時刻以任意大小將資料傳送出去）。

  因特網自身是基於TCP/IP的，它是全世界計算機網路常用的層次化分組交換網路協議集。TCP/IP 隱藏了各種網路和硬體的特點及弱點，使各種型別的計算機和網路都能夠進行可靠地通訊。
  只要建立了TCP連線，客戶端和伺服器之間的報文交換就不會丟失、被破壞、也不會出現接收時亂序。HTTP協議位於TCP的上層。HTTP使用TCP來傳輸其報文資料。
  

• 連線、IP地址及埠號

  在HTTP客戶端向伺服器傳送報文之前，需要用網際協議（Internet Prococol，IP）地址和埠號在客戶端和伺服器之間建立一條TCP/IP連線。
  建立一條TCP連線的過程與給公司辦公室的某個人打電話的過程類似。首先，要撥打公司的電話號碼。這樣就能進入正確的機構了。其次，撥打要聯絡的那個人的分機號。
  最初怎麼獲取伺服器的IP地址呢？當然是通過URL。
  先看幾個URL:
  http://207.200.83.29:80/index.html
  http://www.netscape.com:80/index.html
  http://www.netscape.com/index.html
  第一個 URL 使用了機器的 IP 地址，207.200.83.29 以及埠.第二個 URL 沒有使用數字形式的 IP 地址，它使用的是文字形式的域名，或者稱為主機名（www.netscape.com） 。主機名就是 IP 地址比較人性化的別稱。可以通過一
  種稱為域名服務（Domain Name Service，DNS）的機制方便地將主機名轉換為 IP地址，這樣所有問題就都解決了。
  最後一個 URL 沒有埠號。HTTP 的 URL 中沒有埠號時，可以假設預設埠號是 80。有了 IP 地址和埠號，客戶端就可以很方便地通過 TCP/IP 進行通訊了。
  

步驟如下：

(a) 瀏覽器從 URL 中解析出伺服器的主機名；

(b) 瀏覽器將伺服器的主機名轉換成伺服器的 IP 地址；

(c) 瀏覽器將埠號（如果有的話）從 URL 中解析出來；

(d) 瀏覽器建立一條與 Web 伺服器的 TCP 連線；

(e) 瀏覽器向伺服器傳送一條 HTTP 請求報文；

(f) 伺服器向瀏覽器回送一條 HTTP 響應報文；

(g) 關閉連線，瀏覽器顯示文件。

• 使用Telnet例項

  Telnet程式可以將鍵盤連線到某個目標TCP埠，並將此TCP埠的輸出回送到顯示屏上。Telnet常用於遠端終端會話，但它幾乎可以連線所有的TCP伺服器，包括HTTP伺服器。
  可以通過Telnet程式直接與Web伺服器進行對話。通過Telnet可以開啟一條到某臺機器上某個埠的TCP連線，然後直接向埠輸入一些字元。Web伺服器會將Telnet程式作為一個Web客戶端來處理，然後回送給TCP連線的資料會顯示在螢幕上。
  實際例子：Telnet獲取URL http://www.joes-hardware.com:80/tools.html 所指向的文件
  

Telnet 會查詢主機名並開啟一條連線，連線到在 www.joes-hardware.com 的埠 80上監聽的 Web 伺服器。這條命令之後的三行內容是 Telnet 的輸出，告訴我們它已經建立了連線。
然後我們輸入最基本的請求命令 GET/tools.html HTTP/1.1 ，傳送一個提供了源端主機名的 Host 首部，後面跟上一個空行，請求從伺服器 www.joes-hardware.com 上獲取資源 tools.html。隨後，伺服器會以一個響應行、幾個響應首部、一個空行和最後面的 HTML 文件主體來應答。
要明確的是，Telnet 可以很好地模擬 HTTP 客戶端，但不能作為伺服器使用。而且對 Telnet 做指令碼自動化是很繁瑣乏味的。如果想要更靈活的工具，可以去看看 nc（netcat） 。通過 nc 可以很方便地操縱基於 UDP 和 TCP 的流量（包括 HTTP） ，還可以為其編寫指令碼。更多細節參見 http://www.bgw.org/tutorials/utilities/nc.php

協議版本

目前HTTP有幾個協議版本。

• HTTP/0.9

  HTTP 的 1991 原型版本稱為 HTTP/0.9。這個協議有很多嚴重的設計缺陷，只應該用於與老客戶端的互動。HTTP/0.9 只支援 GET 方法，不支援多媒體內容的MIME 型別、各種 HTTP 首部，或者版本號。HTTP/0.9 定義的初衷是為了獲取簡單的 HTML 物件，它很快就被 HTTP/1.0 取代了。

• HTTP/1.0

  1.0 是第一個得到廣泛使用的 HTTP 版本。HTTP/1.0 添加了版本號、各種 HTTP首部、一些額外的方法，以及對多媒體物件的處理。HTTP/1.0 使得包含生動圖片的 Web 頁面和互動式表格成為可能，而這些頁面和表格促使全球資訊網為人們廣泛地接受。這個規範從未得到良好地說明。在這個 HTTP 協議的商業演進和學術研究都在快速進行的時代，它集合了一系列的最佳實踐。

• HTTP/1.0+

  在 20 世紀 90 年代中葉，很多流行的 Web 客戶端和伺服器都在飛快地向 HTTP中新增各種特性，以滿足快速擴張且在商業上十分成功的全球資訊網的需要。其中很多特性，包括持久的 keep-alive 連線、虛擬主機支援，以及代理連線支援都被加入到 HTTP 之中，併成為非官方的事實標準。這種非正式的 HTTP 擴充套件版本通常稱為 HTTP/1.0+。

• HTTP/1.1

  HTTP/1.1 重點關注的是校正 HTTP 設計中的結構性缺陷，明確語義，引入重要的效能優化措施，並刪除一些不好的特性。HTTP/1.1 還包含了對 20 世紀 90 年代末正在發展中的更復雜的 Web 應用程式和部署方式的支援。HTTP/1.1 是當前使用的 HTTP 版本。

• HTTP-NG（又名 HTTP/2.0）

  HTTP-NG 是 HTTP/1.1 後繼結構的原型建議，它重點關注的是效能的大幅優化，以及更強大的服務邏輯遠端執行框架。HTTP-NG 的研究工作終止於 1998 年，編寫本書時，還沒有任何要用此建議取代 HTTP/1.1 的推廣計劃。

Web結構元件

前面重點介紹了Web應用程式（Web客戶端和Web伺服器）是如何相互發送報文來實現基本事務處理的。因特網上還有一些其他的應用程式。下面一一介紹。

• 代理

  代理位於客戶端和伺服器之間的HTTP中間實體。接收所有客戶端的 HTTP 請求，並將這些請求轉發給伺服器（可能會對請求進行修改之後轉發） 。對使用者來說，這些應用程式就是一個代理，代表使用者訪問伺服器。
  

出於安全考慮，通常會將代理作為轉發所有 Web 流量的可信任中間節點使用。代理還可以對請求和響應進行過濾。比如，在企業中對下載的應用程式進行病毒檢測，或者對小學生遮蔽一些成人才能看的內容。

• 快取

  Web 快取（Web cache）或代理快取（proxy cache）是一種特殊的 HTTP 代理伺服器，可以將經過代理傳送的常用文件複製儲存起來。下一個請求同一文件的客戶端就可以享受快取的私有副本所提供的服務了.
  

客戶端從附近的快取下載文件會比從遠端 Web 伺服器下載快得多。HTTP 定義了很多功能，使得快取更加高效，並規範了文件的新鮮度和快取內容的隱私性。

• 閘道器

  閘道器（gateway）是一種特殊的伺服器，作為其他伺服器的中間實體使用。通常用於將 HTTP 流量轉換成其他的協議。閘道器接受請求時就好像自己是資源的源端伺服器一樣。客戶端可能並不知道自己正在與一個閘道器進行通訊。
  例如，一個 HTTP/FTP 閘道器會通過 HTTP 請求接收對 FTP URI 的請求，但通過 FTP協議來獲取文件 。得到的文件會被封裝成一條 HTTP 報文，傳送給客戶端。第 8 章將探討閘道器。
  

• 隧道

  隧道（tunnel）是建立起來之後，就會在兩條連線之間對原始資料進行盲轉發的HTTP 應用程式。HTTP 隧道通常用來在一條或多條 HTTP 連線上轉發非 HTTP 資料，轉發時不會窺探資料。
  HTTP 隧道的一種常見用途是通過 HTTP 連線承載加密的安全套接字層（SSL，Secure Sockets Layer）流量，這樣 SSL 流量就可以穿過只允許 Web 流量通過的防火牆了。如圖所示，HTTP/SSL 隧道收到一條 HTTP 請求，要求建立一條到目的地址和埠的輸出連線，然後在 HTTP 通道上通過隧道傳輸加密的 SSL 流量，這樣就可以將其盲轉發到目的伺服器上去了。
  

• Agent代理

  使用者 Agent 代理（或者簡稱為 Agent 代理）是代表使用者發起 HTTP 請求的客戶端程式。所有釋出 Web 請求的應用程式都是 HTTP Agent 代理。到目前為止，我們只提到過一種 HTTP Agent 代理：Web 瀏覽器，但使用者 Agent 代理還有很多其他型別。用fiddler抓包找頭部資訊會發現類似User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
  比如，有些自己會在 Web 上閒逛的自動使用者 Agent 代理，可以在無人監視的情況下發布 HTTP 事務並獲取內容。這些自動代理的名字通常都很生動，比如“網路蜘蛛”（spiders）或者“Web 機器人” （Web robots） 。網路蜘蛛會在 Web 上閒逛，蒐集資訊以構建有效的 Web 內容檔案，比如一個搜尋引擎的資料庫或者為比較購物機器人生成的產品目錄。
  

URL和資源

因特網資源

URL是瀏覽器尋找資訊所需的資源位置。URI是一類更通用的資源識別符號，URL是URI的一個子集。URI包括URL和URN。

URL語法

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

• scheme
  訪問伺服器以獲取資源時要使用的協議 預設值 無
  
• user
  一些方案訪問資源時需要的使用者名稱 預設值 匿名
  
• password
  使用者名稱後面可能要包含密碼,中間由冒號分隔 預設值
• host
  資源宿主伺服器的主機名或點分IP地址 預設值 無
  
• port
  資源宿主伺服器正在監聽的埠號,很多方案都有預設埠號(HTTP預設埠號為80) 預設值 每個方案特有
  
• path
  伺服器上資源的本地名,由一個"/"將其與前面的URL元件分隔開來.路徑元件的語法與伺服器和方案有關 預設值 無
• params
  一些方案會用這個元件指定輸入引數. 引數為名/值對. URL中可以包含多個引數欄位,它們相互以及與路徑的其餘部分之間用分號(;)分隔 預設值 無
  
• query
  一些方案會用這個元件傳遞引數以啟用應用程式.查詢元件的內容沒有通用格式.用符號"?"將其與URL的其餘部分分隔開來 預設值 無
• frag
  一小片或一部分資源的名字.引用物件時,不會將frag欄位傳送給伺服器。這個欄位是在客戶端內部使用的.通過字元"#"將其與URL其餘部分分隔開來 預設值 無

http://www.joes-hardware.com/hammers;sale=false/index.html;graphic=ture
這個例子就有兩個路徑段，hammers和index.html。hammers路徑段的引數是sale，值為false。index.html段有引數graphics，值為true。
http://www.joes-hardware.com/inventory-check.cgi?item=12731
問號右邊的內容稱為查詢元件。URL的查詢元件和標誌閘道器資源的URL路徑元件一起被髮送給閘道器資源。基本上可以將閘道器當作訪問其他應用程式的訪問點。
HTTP伺服器只處理整個物件，而不是物件的片段，客戶端不能將片段傳送給伺服器，瀏覽器獲得整個資源後，會根據片段來顯示你感興趣的內容。

HTTP報文

報文流

HTTP報文是在HTTP應用程式之間傳送的資料塊。這些資料以文字形式的元資訊（meta-information）開頭，這些資訊描述了報文的內容及含義，後面跟著可選的資料部分。報文在客戶端、伺服器、代理之間流動。

• 報文流入源端伺服器
  HTTP使用術語流入（inbound）和流出（outbound）來描述事務處理（transaction）的反向。
  流入：客戶端->伺服器
  流出：伺服器->客戶端
  

• 報文向下遊流動
  不管是請求報文還是響應報文，所有報文都會向下遊（downstream）流動。所有報文的傳送者都在接收者的上游（upstream）。對請求報文來說，代理1位於代理3上游，但對於響應報文來說，它就位於代理3的下游。
  

報文的組成部分

三部分組成：
1.對報文進行描述的起始行（start line）
2.包含屬性的首部（header）塊
3.可選的、包含資料的主體（body）部分

• 報文的語法

請求報文

<method> <request-URL> <version>
<headers>
空行（CRLF）
<entity-body>

響應報文

<version> <status> <reason-phrase>
<headers>
空行（CRLF）
<entity-body>

• method
  客戶端希望伺服器對資源執行的動作。是一個單獨的詞，比如GET、HEAD或POST。
• request-URL
  命名了所請求資源或者URL路徑元件的完整URL。如果直接與伺服器進行對話，只要URL的路徑元件是資源的絕對路徑，通常不會有什麼問題。
• version
  報文所使用的HTTP版本
• status-code
  這三位數字描述了請求過程中所發生的情況。
• 原因短語 reason-phrase
  數字狀態碼的可讀版本，包含行終止序列之前的所有文字。

• header
  可以有0個或多個首部。每個首部都包含一個名字，然後跟著一個冒號（：），然後是一個可選的空格，接著是一個值，最後是一個CRLF(回車換行)。首部是由一個空行（CRLF）結束的。表示首部列表的結束和實體主體的開始。
  注意，一組HTTP首部總是應該以一個空行（CRLF）結束，甚至即使沒有首部和實體的主體部分也應該如此。

  起始行

• 請求行
  包含一個方法和一個請求URL，這個方法描述伺服器該執行的操作，請求URL描述了要對哪個資源執行這個方法。所有這些欄位都是由空格符分隔。

• 響應行
  響應報文承載了狀態資訊和操作產生的所有結果資料，將其返回給客戶端。響應報文的起始行稱為響應行。
  常用HTTP方法

• 狀態碼
  狀態碼是在每條響應報文的起始行總返回的。會返回一個數字狀態和一個可讀的狀態。數字碼便於程式進行差錯處理，而原因短語則更便於人們理解。
  狀態碼分類

常見的狀態碼

• 首部分類
  1.通用首部：既可以出現在請求報文中，也可以出現在響應報文中。
  2.請求首部：提供更多有關請求的資訊
  3.響應首部：提供更多有關響應的資訊
  4.實體首部：描述主體的長度和內容，或者資源本身
  5.擴充套件首部：規範中沒有定義的新首部。
  具體的每個首部用法，可以參考HTTP權威指南

• options
  options方法請求Web伺服器告知其支援的各種功能。可以詢問伺服器支援哪些方法，或者對某些特殊資源的支援方法。這為客戶端應用程式提供了一種手段，使其不用實際訪問那些資源就能判定訪問各種資源的最優方式。
  

• 重定向狀態碼
  重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供了一個替代的響應而不是資源的內容。如果資源已被移動，可傳送一個重定向狀態碼和一個可選的location首部來告知客戶端資源已被移走，以及現在在哪裡可以找到它。
  

連線管理

TCP連線

TCP的可靠資料管道

TCP會按序、無差錯的承載HTTP資料

TCP流是分段、由IP分組傳送

TCP資料是通過IP分組（IP資料報）的小資料塊來發送的。HTTP就是”HTTP over TCP over IP“這個協議棧中的最頂層了。HTTPS就是在HTTP和TCP之間插入了一個(TLS或者SSL）密碼加密層。

HTTP要傳送一條報文時，會以流的形式將報文資料的內容通過一條開啟的TCP連線按序傳輸。TCP收到資料流之後，會將資料流分成稱作段的小資料塊，並將段封裝在IP分組中，通過因特網傳輸。所有這些工作由TCP/IP軟體來處理，HTTP程式設計師看不到。
每個TCP段都是由IP分組承載，從一個IP地址傳送到另一個IP地址。每個IP分組中包括：

• 一個IP分組首部（通常為20位元組）
• 一個TCP段首部（通常為20位元組）

• 一個TCP資料塊（0或者多個位元組）
  IP首部包含了源和目的IP地址、長度和其他一些標記。TCP段的首部包含了TCP埠號、TCP控制標記，以及用於資料排序和完整性檢查的一些數字值。

  保持TCP連線的正確執行

  在任意時刻計算機都有幾條TCP連線處於開啟狀態。TCP是通過埠號來保持這些連線正確執行。
  埠號類似分機號。IP能讓你連線到正確的計算機，埠號則可以將你連線到正確的應用程式上。TCP連線通過4個值來識別：

<源 IP 地址、 源埠號、 目的IP地址、目的埠號>

這四個值一起唯一定義了一條連線。兩條不同的TCP連線不能擁有4個完全相同的地址元件值。

四條TCP連線

有些連線共享了相同目的埠號（C和D都是使用80埠）。有些連線使用了相同的源IP。有些使用了相同目的IP。但沒有兩個連線4個值都一樣。

TCP套接字程式設計

套接字API允許使用者建立TCP的埠資料結構，並將這些端點與遠端伺服器的TCP埠進行連線，並對資料進行讀寫。TCP API隱藏了所有底層網路協議的握手細節，以及TCP資料流與IP分組之間的分段和重灌細節。

TCP建立連線就需要三次握手才能建立，就是之前經常考的三次握手。
TCP關閉連線需要四次揮手。有比較好的文章講解這個問題。
TCP時延主要在於：
1.TCP的建立連線的握手
2.TCP的慢啟動
3.資料聚集的Nagle演算法
4.用於捎帶確認的TCP延遲確認演算法
5.TIME_WAIT時延和埠耗盡
具體細節可看HTTP權威指南

HTTP連線的處理

序列事務處理時延

• 並行連線：多條TCP連線發起併發的HTTP請求
• 持久連線：重用TCP連線，以消除連線及關閉時延
• 管道化連線：通過共享的TCP連線發起併發的HTTP請求。
  具體細節可看HTTP權威指南

代理

Web代理伺服器是代表客戶端完成事務的中間人。沒有Web代理，HTTP客戶端和伺服器直接對話。HTTP代理伺服器既是客戶端，也是伺服器。代理伺服器必須像Web伺服器一樣，正確處理請求和連線，然後返回響應。同時，代理自身要向伺服器傳送請求。

代理和閘道器對比

代理連線的是兩個或者多個使用相同協議的應用程式，而閘道器連線的是兩個或者多個使用不同協議的端點。

假如我通過代理訪問 A 網站，對於 A 來說，它會把代理當做客戶端，完全察覺不到真正客戶端的存在，這實現了隱藏客戶端 IP 的目的。
給瀏覽器顯式的指定代理，需要手動修改瀏覽器或作業系統相關設定，或者指定 PAC（Proxy Auto-Configuration，自動配置代理）檔案自動設定，還有些瀏覽器支援 WPAD（Web Proxy Autodiscovery Protocol，Web 代理自動發現協議）。顯式指定瀏覽器代理這種方式一般稱之為正向代理，瀏覽器啟用正向代理後，會對 HTTP 請求報文做一些修改，來規避老舊代理伺服器的一些問題。
還有一種情況是訪問 A 網站時，實際上訪問的是代理，代理收到請求報文後，再向真正提供服務的伺服器發起請求，並將響應轉發給瀏覽器。這種情況一般被稱之為反向代理，它可以用來隱藏伺服器 IP 及埠。一般使用反向代理後，需要通過修改 DNS 讓域名解析到代理伺服器 IP，這時瀏覽器無法察覺到真正伺服器的存在，當然也就不需要修改配置了。反向代理是 Web 系統最為常見的一種部署方式。

共有代理快取

公有快取是特殊的共享代理伺服器，被稱為快取代理伺服器（caching proxy server，或者更常見的被稱為代理快取（proxy cache）。代理快取會從本地快取中提供文件，或者代表使用者與伺服器聯絡。公有快取會接受來自多個使用者的訪問，所以可以有效的減少冗餘流量。

代理快取的層次結構

層次化快取是有意義的。較小快取未命中的請求會向較大父快取（parent cache）。

快取的處理步驟

1.接收-快取從網路中讀取抵達的請求報文
2.解析-快取對報文進行解析，提取URL和各種首部
3.查詢-快取檢視是否有本地副本可用，如果沒有，就讀取一份副本（並將其儲存在本地）
4.新鮮度檢測-快取檢視已快取副本是否足夠新鮮，如果不是，就詢問伺服器是否有更新
5.建立響應-快取會用新的首部和已快取的主體來構建一條響應報文
6.傳送-快取通過網路將響應發回給客戶端
7.日誌-快取可選的建立一個日誌檔案條目來描述這個事務。

保持副本的的新鮮

HTTP有一些簡單的機制可以在不要求伺服器記住有哪些快取擁有其文件副本的情況，保持已快取資料和伺服器資料之間充分一致。HTTP將這些簡單機制稱為文件過期（document expiration）和伺服器再驗證（server revalidation）。

• 文件過期
  通過特殊的HTTP cache-control首部和expires首部，HTTP協議讓原始伺服器向每個文件附加了一個過期日期。在快取文件過期之前，快取可以任意使用副本，而無需與伺服器聯絡。除非客戶端請求中包含阻止提供已快取或者未驗證資源的首部。一旦過期，快取必須和伺服器核對。一旦修改過，就要獲取一份新的副本。
• 過期日期和使用期
  cache-control：max-age 是用的使用期。只這個副本可用使用多久 Cache-Control: max-age=484200
  expires 用的是絕對時間，到這個時間之前，都可以用這個副本。Expires: Fri, 05 Jul 2002, 05:00:00 GMT

• 伺服器再驗證
  快取文件過期不意味著伺服器文件已改變，只意味著到了要核對的時間了。這種情況稱為伺服器再驗證。

  如果再驗證時發生了變化，快取會獲取一份新的文件副本，並將其儲存在舊文件位置，然後將其傳送給客戶端。
  如果沒有發生變化，快取只需要獲取新的首部，包括一個新的過期日期，並對快取中首部進行更新。

  條件法進行再驗證

• if-modified-since:Date再驗證

• if-none-match：實體標籤再驗證
  有些情況僅使用最後修改日期進行再驗證是不夠的。
  1.有些資料會週期性重寫，實際包含資料一樣。資料沒變，但是修改日期變了
  2.有些可能做了修改，但是修改不重要
  3.有些伺服器無法準確判斷其頁面的最後修改日期
  4.有些伺服器文件在亞秒之間傳送變化（如實時監視器）。對這些伺服器來說，秒為粒度的修改日期不夠用。
  為了解決這個問題，HTTP允許使用者對被稱為實體標籤（ETag）的版本識別符號進行比較。實體標籤是附加到文件上的任意標籤。他們可能包含了文件的序列號或者版本名。或者是文件內容校驗和其他指紋資訊。
  

• 強弱驗證器
  有時，伺服器希望文件的一些非實質性更改不要使所有的已快取副本都失效。HTTP/1.1支援弱驗證器。伺服器會使用"W/"來標識弱驗證器。

  控制快取的能力

  cache-control：no-store
  cache-control：no-cache
  cache-control：must-revalidate
  cache-control：max-age
  附加Expires日期到響應中
  不附加過期資訊，快取自己確定自己的過期日期
  no-store和no-cahce首部可以防止快取提供未經證實的已快取的物件。標識未no-store的響應會禁止快取對響應進行復制。快取通常像非快取代理伺服器一樣，向客戶端轉發一條no-store響應，然後刪掉物件。
  no-cache的響應其實是可以儲存在本地快取區中。只是與原始伺服器進行新鮮度再驗證前，快取不能將其提供給客戶端用。
  max-age認為此文件處於新鮮度的秒數。expires和max-age類似，只不過expires使用絕對日期。建議使用max-age，因為很多伺服器時鐘不同步。
  可以配置快取，使其提供一些陳舊（過期）的物件，以提高效能。如果原始伺服器希望快取嚴格遵守過期資訊，可以在原始響應中附加一個cache-control:must-revalidate首部。
  must-revalidate告訴快取，在事先沒有和原始伺服器進行再驗證情況下，不能提供這個物件的副本。快取仍然可以隨意提供新鮮的副本。如果快取進行must-revalidate新鮮度檢查時，原始伺服器不可用，快取就必須返回一條504Gateway Timeout錯誤。
  理解
  I believe that must-revalidate means "once the cache expires, refuse to return stale responses to the user even if they say that they are acceptable". Whereas no-cache implies must-revlidateplus the fact the response becomes stale right away.
  If a response is cacheable for 10 seconds, then must-revalidate kicks in after 10 seconds, whereas no-cache implies must-revalidate after 0 seconds.

  客戶端新鮮度

  

閘道器、隧道和中繼

閘道器

單個應用無法處理所有這些能想到的資源。為了解決這個問題，就提出了閘道器（gateway）的概念。閘道器可以作為某種翻譯器使用，它抽象出一種能夠到達資源的方法。閘道器是資源和應用程式之間的粘合劑。應用程式可以（通過HTTP或其他已定義的介面）請求閘道器處理某條請求，閘道器可以提供一條響應。閘道器可以向資料塊傳送查詢語句，或者生成動態內容，就像一個門一樣：進去一條請求，出來一個響應。

協議閘道器

將HTTP流量導向閘道器時所使用的方式與將流量導向代理的方式相同。最常見的方式是，顯式的配置瀏覽器使用閘道器，對流量進行透明的攔截，或者將閘道器配置為替代者（反向代理）。

資源閘道器

協議閘道器時網路連線客戶端和伺服器的閘道器。但最常見的閘道器時應用伺服器，會將目標伺服器與閘道器結合在一個伺服器中實現。應用程式伺服器是伺服器閘道器，與客戶端通過HTTP通訊，並與伺服器端的應用程式相連。

• 收到客戶端A的請求，根據URI將其通過API傳送到一個數碼相機應用程式。將得到的圖片繫結到一條HTTP響應報文中，再回傳給客戶端，在客戶端的瀏覽器中顯示。
• 客戶端B的URI請求是一個電子商務應用程式。客戶端B的請求是通過伺服器閘道器API傳送給電子商務軟體的，結果會被回送給瀏覽器。電子商務軟體與客戶端進行互動，引導使用者通過一系列HTML頁面來完成購物。
  第一個流行的應用程式閘道器API就是通用閘道器介面（Common Gateway Interface，CGI）。CGI是一個標準介面集，Web伺服器可以用它來裝載程式以響應對特定URL的HTTP請求，並收集程式的輸出資料，將其放在HTTP響應中回送。
  具體實現方式：請求需要使用閘道器資源時，伺服器會請輔助應用程式來處理請求。伺服器會將輔助請求資料所需的資料給它。通常就是整條請求，或者使用者想在資料庫上執行的請求之類的東西。
  然後，它會向伺服器返回一條響應或響應資料，伺服器則會將其轉發給客戶端。伺服器和閘道器是相互獨立的應用程式，因此他們的責任分的很清楚。這個簡單的協議（輸入請求，轉交，響應）就是最古老、最常用的伺服器擴充套件介面CGI的本質。
  

CGI

CGI是第一個可能仍然得到廣泛應用的伺服器擴充套件。在Web上廣泛用於動態HTML、信用卡處理以及資料塊查詢等任務。
CGI應用程式是獨立於伺服器的，所以，幾乎可以用任意語言來實現。CGI很簡單，幾乎所有的HTTP服務都支援它。
CGI的處理對使用者來說是不可見的。從客戶端的角度來看，就像發起一個普通請求語言。它完全不清楚伺服器和CGI程式直接的轉接過程。URL中出現cgi和可能出現的"?"是客戶端發現使用了CGI應用程式的唯一線索。
CGI看起來很棒，它在伺服器和眾多的資源型別之間提供了一種簡單的、函式形式的粘合方式，用來處理各種需要的轉換。這個介面還能很好的保護伺服器，防止一些糟糕的擴充套件對伺服器造成的破壞（如果擴充套件與伺服器直接相連，造成的錯誤可能會引發伺服器崩潰）。
但是，這種分離會造成效能的耗費。為每條CGI請求引發一個新程序的開銷是很高的。加重伺服器資源的負擔。為了解決這個問題，人們開發了一種新型的CGI-並將其恰當的稱為快速CGI。這個介面模擬了CGI，但它是作為持久守護程序執行的，消除了為每個請求建立或拆除新程序所帶來的效能損耗。

CGI學習（擴充套件）

最早的Web伺服器簡單地響應瀏覽器發來的HTTP請求，並將儲存在伺服器上的HTML檔案返回給瀏覽器，也就是靜態html。事物總是不斷髮展，網站也越來越複雜，所以出現動態技術。但是伺服器並不能直接執行 php，asp這樣的檔案。自己不能做，外包給別人吧，但是要與第三方做個約定，我給你什麼，然後你給我什麼，把請求引數傳送給你，然後我接收你的處理結果給客戶端。那這個約定就是 common gateway interface，簡稱CGI。這個協議可以用vb，c，php，python 來實現。CGI只是介面協議，根本不是什麼語言。下面圖可以看到流程。

WEB伺服器將根據CGI程式的型別決定資料向CGI程式的傳送方式，一般來講是通過標準輸入/輸出流和環境變數來與CGI程式間傳遞資料。 如下圖所示：

具體詳細的CGI環境變數和post與GET方法區別，可參考這篇文章 。

伺服器擴充套件API

CGI協議為外部翻譯器與現有的HTTP伺服器提供了一種簡潔的介面方式，但如果想要改變伺服器自身的行為，或者只是想盡可能提升能從伺服器上獲得的效能？伺服器開發者為這兩種需求提供了機制伺服器擴充套件API，為Web開發者提供了強大的介面，以便他們將自己的模組與HTTP伺服器直接相連。擴充套件API允許程式設計師將自己的程式碼嫁接到伺服器上，或者用自己的程式碼將伺服器的一個元件完整的替換出來。
大多數流行的伺服器都會為開發者提供一個或者多個擴充套件API。這些擴充套件通常都會繫結在伺服器自身的結構上，所以，大多數都是為某種伺服器型別特有的。

應用程式介面和Web服務

隨著Web應用程式提供的服務型別越來越多，有一點變得越來越清晰：HTTP可以作為一種連線應用程式的基礎軟體來使用。在將應用程式連線起來的過程中，一個更為棘手的問題是在兩個應用程式之間進行協議介面的協商，以便這些應用程式可以進行資料交換-這通常是針對應用程式的個案進行的。
應用程式之間要配合工作，所要互動的資訊比HTTP首部所能表達的資訊要複雜的多。因此因特網委員會開發了一組允許Web應用程式相互通訊的標準和協議。

隧道

Web隧道允許使用者通過HTTP連線傳送非HTTP流量，這樣就可以在HTTP上捎帶其他協議資料了。使用Web隧道最常見的原因就是要在HTTP連線中嵌入非HTTP流量，這樣，這類流量就可以穿過只允許Web流量通過的防火牆了。

• 用connect建立HTTP隧道
  Web隧道是用HTTP的connect方法建立起來的。connect方法並不是HTTP/1.1核心規範的一部分，但卻是得到廣泛應用的擴充套件。connect方法請求隧道閘道器建立一條到達任意目的伺服器和埠的TCP連線，並對客戶端和伺服器之間的後繼資料進行盲轉發。
  

客戶端識別與cookie機制

個性化接觸

HTTP最初是一個匿名、無狀態的請求、響應協議。伺服器處理來自客戶端的請求，然後向客戶端回送一條響應。Web伺服器幾乎沒有什麼資訊可以用來判定時哪個使用者傳送的請求，業無法記錄來訪使用者的請求序列。
現代的Web站點希望能夠提供個性化的接觸。它們希望對另一端的使用者有更多的瞭解，並且能在使用者瀏覽頁面時對其進行追蹤。

客戶端ip地址

使用客戶端ip地址識別使用者有很多缺點：

• 客戶端ip地址描述的是機器，而不是使用者。
• 因特網服務商提供動態分配ip，使用者每登陸一次，都是一個新地址。
• 為了提高安全性，並對稀缺資源進行管理，很多使用者都是通過網路地址轉換（Network Adress Translation，NAT）防火牆來瀏覽網路內容的。這些NAT裝置隱藏了防火牆後面實際的客戶端地址。將實際的客戶端IP地址轉換成一個共享的防火牆IP地址（和不同的埠號）。

• HTTP代理和閘道器通常會開啟一些新的、到原始伺服器的TCP連線。Web伺服器看到的將是代理伺服器的IP地址，而不是客戶端的。有些代理為了繞過這個問題會新增特殊的Client-IP或X-Forwarded-For擴充套件首部來儲存原始地址。但並不是所有代理都支援這種行為。

  使用者登陸

  Web伺服器無需被動的根據使用者IP來猜測身份，可以要求通過使用者名稱密碼來顯式的詢問使用者是誰。
  為了是Web站點的登陸更加簡便，HTTP中包含了一種內建機制，可以用WWW-Authenticate首部和Authorization首部向Web站點傳送使用者的相關資訊。一旦登陸，瀏覽器就可以不斷的在每條發往這個站點的請求中傳送這個登陸資訊了。
  

• 客戶端對站點www.joes-hardware.com 發起請求。
• 站點並不知道使用者身份，伺服器返回401 login required HTTP狀態碼。並新增到WWW-Authentication首部，要求使用者登陸。這樣瀏覽器就會彈出一個登陸對話方塊。
• 只要使用者輸入了使用者名稱和密碼（對其身份進行了完整性檢查），瀏覽器就會重複原來的請求。這次它會加一個Authentication首部，說明使用者名稱和密碼並對使用者名稱和密碼加密，防止有意無意的窺探者。

• 今後的請求要使用使用者名稱和密碼時，瀏覽器會自動將儲存下來的值傳送出去，甚至在站點沒有要求傳送時都會發送。

  cookie

  大多數快取和瀏覽器都不允許對任何cookie的內容進行快取。

  cookie的型別

  可以籠統的將cookie分成兩類：會話cookie和持久cookie。會話cookie是一種歷史cookie，它記錄使用者訪問站點時的設定和偏好。使用者退出瀏覽器是，會話cookie就會被刪除。持久cookie生存時間長一點。他們儲存在硬碟上，瀏覽器退出，計算機重啟時他們如仍然存在。通常永續性cookie維護某個使用者會週期性訪問的站點的配置檔案或登入名。
  會話cookie和持久cookie之間唯一的區別就是它們的過期時間。

  cookie是任何工作

  cookie就像是伺服器給使用者貼的”嗨，我叫"的貼紙一樣。使用者訪問一個Web站點時，站點就可以讀取伺服器貼在使用者身上所有的貼紙。
  使用者首次訪問Web站點時，Web伺服器對使用者一無所知。Web伺服器希望這個使用者會再回來，所以想給這個使用者拍上一個獨有的cookie，這樣以後就能識別這個使用者了。cookie包含了一個有name=value這樣的資訊構成的任意列表，並通過Set-Cookie或Set-Cookie2 HTTP響應（擴充套件）首部將其貼到使用者身上。
  

cookie罐：客戶端狀態

cookie的基本思想就是讓瀏覽器積累一組伺服器特有的資訊，每次訪問伺服器時都將這些資訊提供給它。瀏覽器負責儲存cookie資訊，所以此係統被稱為客戶端側狀態（client-side state）。cookie規範的正式名稱為HTTP狀態管理機制（HTTP state management mechanism）。

不同站點使用不同cookie

瀏覽器內部有成千上百個cookie，但瀏覽器不會將每個cookie都發送給所有的站點。通常它只向每個站點發送2-3個cookie。原因如下：

• 對所有這些cookie位元組進行傳輸會嚴重降低效能。瀏覽器實際傳輸的cookie位元組數要比實際內容節數多
• cookie中包含的是伺服器特有的名字和值對，所以對大部分站點來說，大多數cookie都只是無法識別的無用資料。

• 將所有cookie傳送給所有站點會引發潛在的隱私問題，那些你並不信任的站點也會獲得你只想發給其他站點的資訊。
  總之，瀏覽器只向伺服器傳送伺服器產生的cookie。joes-hardware.com產生的cookie會被髮送到joes-hardware.com，不會發送到bobs-books.com。

  • cookie的域屬性
    產生cookie的伺服器可以向Set——Cookie響應首部新增一個Domain屬性來控制哪些站點可以看到那個cookie。
    Set-cookie: user="mary17"; domain="airtravelbargains.com";
  • cookie路徑屬性
    cookie規範甚至允許使用者將cookie與部分Web站點關聯起來。可以通過path屬性來實現這一功能，在這個屬性列出的URL路徑字首下所有的cookie都是有效的。
    例如，某個Web伺服器是由兩個組織共享的。每個組織有獨立的cookie。站點www.airtravelbargains.com 可能將部分Web站點用於汽車租賃，例如 www.airtravelbargains.com/autos/ 用一個獨立的cookie來記錄使用者喜歡的汽車尺寸。
    Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/
    如果使用者訪問 www.airtravelbargains.com/autos/specials.html 就會獲得這個cookie：
    cookie=“mary17"
    但是如果訪問www.airtravelbargains.com/autos/cheapo/index.html 就會獲得兩個cookie：
    cookie:user="mary17"
    cookie: pref=compact

cookie成分

Set-Cookie： name=value [; expires=data] [; path=path] [; domain] [; secure]
Cookie: name1=value1 [; name2=value2] ...