HTTP權威指南-學習筆記

目錄

• HTTP權威指南-學習筆記
  • HTTP: Web的基礎
    • URL與資源
    • HTTP報文
    • 鏈接管理
  • HTTP結構
    • Web服務器
    • 代理
    • 緩存
    • 集成點: 網關，隧道及中繼
    • Web機器人
  • 識別，認證與安全
    • 客戶端識別與cookie機制
    • 基本認證機制
    • 安全HTTP
  • 內容發佈與分發
    • Web主機託管

[]

HTTP權威指南-學習筆記

HTTP (Hypertext Transfer Protocol, 超文本傳輸協議)

• 運行實例

HTTP: Web的基礎

• Web客戶端和服務器: Web內容都是存儲在服務器上的，Web服務器使用的是HTTP協議。
• 資源: Web服務器是Web資源(Web resource)的宿主，Web資源是Web內容的源頭。
• HTTP仔細地給每種要經過Web傳輸的對象都打上名爲MIME(Multipurpose Internet Mail Extension, 多用途因特網郵件擴展)類型的數據格式標籤。
• 統一資源標識符(Uniform Resourse Identifier, URI), 惟一標識並定位信息資源。
  • URL(統一資源定位符，大量使用中)和URN(統一資源名)兩種對象。
• 一條HTTP事物由一條請求命令和一個響應結果組成。HTTP報文(HTTP message)格式化數據塊進行的。
  • 每條HTTP請求都包含一個方法: 該方法告訴服務器要執行什麼動做: 獲取一個Web網頁，運行一個網關程序，刪除一個文件等。
  • GET: 從服務器向客戶端發送命名資源。
  • PUT: 將客戶端的數據存儲到一個命名的服務起資源中去。
  • DELETE: 從服務器中刪除命名資源。
  • POST: 將客戶端數據發送到一個服務器網關應用程序。
  • HEAD: 僅發送命名資源響應中的HTTP首部。
• 每條HTTP響應報文返回時都會攜帶一個狀態碼(狀態碼時一個三位數的代碼)。
• HTTP報文時由一行一行的簡單字符串組成的。
  • HTTP報文都是純文本，不是二進制代碼，能夠很方便地進行讀寫。
  • 起始行、首部、主體。(請求報文，request message; 響應報文，response message)。
• HTTP是個應用層協議，HTTP無需操心網絡通訊的具體細節，它把聯網的細節都交給了通用、可靠的因特網傳輸協議TCP/IP。
  • TCP: 無差錯的數據傳輸，按序傳輸(數據老是會按發送的順序到達)，未分段的數據流(能夠在任意時刻以任意尺寸將數據發送出去)。
• 能夠經過Telnet程序直接與Web服務器進行對話。
• Web的結構組件:
  • 代理: 位於客戶端和服務器之間的HTTP中間實體。
  • 緩存: HTTP的倉庫，使經常使用頁面的副本能夠保存在離客戶端更近的地方。
    • Web緩存(Web cache)或代理緩存(proxy cache)是一種特殊的HTTP代理服務器，將代理傳送的經常使用文檔複製保存起來。
  • 網關: 鏈接其餘應用程序的特殊Web服務器。
    • 網關(gateway)是一種特殊的服務器，做爲其餘服務器的中間實體使用，一般用於將HTTP流量轉換成其餘的協議
  • 隧道: 對HTTP通訊報文進行盲轉發的特殊代理。
    • 隧道(tunnel)是創建起來以後，就會在兩條鏈接之間對原始數據盲轉發的HTTP應用程序。
    • HTTP隧道一般用來在一條或多條HTTP鏈接上轉發非HTTP數據，轉發時不會窺探數據。
    • HTTP隧道的一種常見用途時經過HTTP鏈接承載加密的安全套接字層(SSL, Secure Sockets Layer)流量。
  • Agent代理: 發起自動HTTP請求的半智能Web客戶端。
    • Web瀏覽器。
  • HTTP代理服務器時Web安全、應用集成以及性能優化的重要組成模塊。(代理做爲轉發全部Web流量的可信任中間節點使用)
    • 代理能夠對請求和響應進行過濾。

URL與資源

• URL就是因特網資源的標準化名稱。
• URL語法，URL編碼覈字符規則, 常見的URL方案, URL的將來(URN).
• URI是一種通用的資源標識符, URL其實是它的一個子集。
• URL的第一部分是URL方案，第二部分是服務器的位置，第三部分是資源路徑。
• URL資源能夠經過HTTP, FTP, SMTP來訪問。
• <scheme>://<user>:<password>@<host>:<port>/<path>:<params>?<query>#<frag>.
• 方案名與大小寫無關，URL支持使用片斷(frag)組件來白哦是一個資源內部的片斷。
• http默認端口是80端口號，https默認端口號是443，rtsp(實時流傳協議，Real Time Streaming Protocol)解析音視頻媒體資源的標誌符。
• 永久統一資源定位符(persistent uniform resource locators, PURL): 搜索資源的過程引入一箇中間層，經過一箇中間資源定位符服務器對資源的實際URL進行登記核跟蹤。

HTTP報文

• HTTP報文至關於包裹（是在HTTP應用程序之間發送的數據塊），HTTP報文的三個組成部分(起始行，首部和實體的主體部分)。
• 術語"流入"和"流出"，"上游"和"流出"來描述報文方向。
  • 全部報文的發送者在接收者的上游(upstream)。
• HTTP報文的三個部分: 起始行，首部，主體。
  • 起始行和首部就是行分割的ASCII文本，報文的主體是可選數據塊(主體能夠包含文本或二進制數據，也能夠是空，Content-Type說明主體是什麼，Content-Length說明了主體有多大)。
• 全部的HTTP報文能夠分爲兩種: 請求報文(request message)和響應報文(response message):
  • 請求報文的格式:

  <method> <request-URL> <version>
   <headers>
  
   <entity-body>

  • 響應報文格式:

  <version> <status> <reason-phrase>
   <headers>
  
   <entity-body>

• HTTP經常使用的方法:
  • GET: 從服務器獲取一份文檔。
  • HEAD: 只從服務器獲取文檔的首部。
  • POST: 向服務器發送須要處理的數據。
  • PUT: 將請求的主體部分存在服務器上。
  • TRACE: 對可能通過代理服務器傳送到服務器上去的報文進行追蹤。
  • OPTIONS: 決定能夠在服務器上執行哪些方法。
  • DELETE: 從服務器上刪除一份文檔。
• 狀態碼分類:
  • 100~199: 信息提示。
  • 200~299: 成功。(200-成功)
  • 300~399: 重定向。
  • 400~499: 客戶端錯誤。(401-未受權，404-未找到)
  • 500~599: 服務器錯誤。

鏈接管理

• HTTP的優化: 並行鏈接，keep-alive(持久鏈接)和管道化鏈接。
• TCP爲HTTP提供一條可靠的比特傳輸管道，從TCP鏈接一端填入的字節會從另外一端以原有的順序、正確地傳送出來。
• TCP流是分段的，由IP分組傳送: TCP的數據是經過名爲IP分組(或IP數據報)的小數據塊來發送的。
• HTTP事務的性能很大程度上取決於底層TCP通道的性能，HTTP時延不少狀況是由網絡時延構成。
• 最多見的TCP相關時延:
  • TCP鏈接創建握手；
    • SYN/SYN+ACK(IP分組)會產生一個可測量的時延，TCP鏈接的ACK分組一般都足夠大，能夠承載整個HTTP請求報文，並且不少HTTP服務器響應報文均可以直接放入一個IP分組中去。
    • 針對小的HTTP事物進行優化，由於小的HTTP事物可能會在TCP創建上花費50%的時間在創建鏈接上。
  • TCP慢啓動擁塞控制；
    • 每一個TCP段都有一個序列號和數據完整性校驗和，收到無缺的段時會回送一個小的確認分組，發送者在指定時間內沒有收到確認信息，就會重發數據；
    • TCP將返回的確認信息和輸出的數據分組結合在一塊兒，能夠有效地利用網絡。
    • 爲了增長確認報文找到同向傳輸數據分組的可能性，不少TCP棧都實現了一種"延時"確認算法。
    • 確認算法會在一個特定窗口時間(100~200毫秒)內將輸出確認存放在緩衝區中，以尋找可以捎帶它的輸出數據分組(沒有找到就將確認信息放在單獨的分組中傳輸)。
    • HTTP具備雙峯特徵的請求 -- 應答行爲下降了捎帶信息的可能(延遲確認算法可能會給HTTP引入至關大的時延)。
    • 在對TCP棧的任何參數進行修改以前，必定要對本身在作什麼有清醒的認識。
    • TCP數據傳世的性能還取決於TCP鏈接的使用期(age)，TCP鏈接會隨着時間進行自我協調，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度 -- 這種協調被稱做TCP慢啓動(slow start)， 用於防止因特網的忽然過載和擁塞。
    • TCP慢啓動限制了一個TCP端點在任意時刻能夠傳輸的分組數，因爲已調諧鏈接更快一些，因此HTTP中有一些能夠重用現存鏈接的工具(HTTP持久鏈接)。
  • 數據彙集的Nagle算法;
    • TCP有一個數據流接口，應用程序能夠經過它將任意尺寸的數據放入TCP棧中(可是每一個TCP段中都至少裝載了40個字節的標記和首部，因此TCP發送大量包含少許數據的分組，網絡性能就會嚴重降低)。
    • Nagle算法試圖在發送一個分組以前，將大量TCP數據綁定在一塊兒，以提升網絡效率。
    • Nagle算法鼓勵發送全尺寸(LAN上最大尺寸得分組約是1500字節，在因特網上是幾百字節)得段。
    • 只有當其餘分組都被確認後，Nagle算法才容許發送非全尺寸得分組。
    • Nagle算法會因小的HTTP報文等待額外數據產生時延。Nagle算法會阻止數據的發送，直到有確認分組抵達爲止，但確認分租自身會被延遲確認算法延遲100~200毫秒。
    • HTTP應用程序經常會在本身的棧中設置參數TCP_NODELAY禁用Nagle算法，提升性能。
  • 用於捎帶確認的TCP延遲確認算法；
  • TIME_WAIT時延和端口耗盡。
    • TIME_WAIT端口耗滿是很嚴重的性能問題，會影響到性能基準。
    • 當某個TCP端點關閉TCP鏈接時，會在內存中維護一個很小的控制塊，用來記錄最近關閉鏈接的IP地址和端口號；這類信息會維持一小段時間，一般是估計的最大分段使用.
• HTTP容許在客戶端和最終的源端服務器之間存在一串HTTP中間實體(代理、高速緩存等)。
• HTTP的Connection首部字段中有一個由逗號分割的鏈接標籤列表，這些標籤爲鏈接指定了一些不會傳播到其餘鏈接中去的選項。
  • 並行鏈接: 經過多條TCP鏈接發起併發的HTTP請求。
  • 持久鏈接: 重用TCP鏈接，以消除鏈接及關閉的時延。
  • 管道化鏈接: 經過共享的TCP鏈接發起併發的HTTP請求。
  • 複用的鏈接: 交替傳送請求和響應報文。
• 每條HTTP響應都應該有精確的Content-Length首部，用以描述響應主體的尺寸。
• 儘管用戶Agent代理可能會讓操做員來選擇是否對請求進行重試，但必定不能自動重試非冪等方法或序列。
• 徹底關閉與半關閉:
  • close()會將TCP鏈接的輸入和輸出信道都關閉，稱爲徹底關閉。
  • shutdown()單獨關閉輸入或輸出信道，這稱爲半關閉。
    • 使用半關閉來防止對等實體收到非預期的寫入錯誤很關鍵。正常關閉的應用程序首先應該關閉它們的輸出信道，而後等待鏈接另外一端的對等實體關閉它的輸出信道。
    • 先半關閉其輸出信道，而後週期性地檢查其輸入信道的狀態(查找數據，或流的末尾)。若是在必定時間內對端沒有關閉信道，應用程序能夠強制關閉鏈接，以節省資源。

HTTP結構

HTTP服務器，代理，緩存，網關和應用程序。

Web服務器

• web服務器會對HTTP請求進行處理並提供響應。全部的Web服務器都可以接收請求資源的HTTP資源的HTTP請求，將內容回送給客戶端。
• Web服務器實現了HTTP和相關的TCP鏈接處理。負責管理Web服務器提供的資源，以及對Web服務器的配置，控制及擴展方面的管理。
• 多線程Web服務器都會對線程/進程的最大數量進行限制。
• 複用I/O的服務器，在複用結構中，要同時監聽全部鏈接上的活動，當鏈接的狀態發生變化時，就對那條鏈接進行少許的處理；處理後，將鏈接返回到開放鏈接列表中，等待下一次狀態變化。
• 複用的多線程Web服務器，多線程中的每個都在觀察打開的鏈接，並對每條鏈接執行少許的任務。
• Web服務器的文件系統中會有一個特殊的文件夾專門用於存放Web內容，文檔的根目錄(document root, docroot).
  • 服務器不能讓相對URL退到docroot以外，將文件系統的其他部分暴露出來。
  • 虛擬託管Web服務器會根據URI或Host首部的IP地址或主機名來識別要使用的正確文檔根目錄。
  • 虛擬託管的Web服務器會在同一臺Web服務器上提供多個Web站點，每一個站點在服務器上都有本身獨立的文檔根目錄。
• 不少Web服務器還提供了對服務器包含項(SSI)的支持。
• 若是一個呃呃超載的服務器收到一條請求，服務器能夠將客戶端重定向到一個負載不過重的服務器上去。狀態碼303 See Other和307 Temporary Redirect可用於重定向。

代理

Web代理(proxy)服務器是網絡的中間實體，代理位於客戶端和服務器之間，扮演中間人的角色，在各端點之間來回傳送HTTP報文。

• HTTP的代理服務器便是Web服務器又是Web客戶端，HTTP客戶端會向代理髮送請求報文，代理服務器必須像Web服務器同樣，正確地處理請求和鏈接，而後返回請求報文。
• 單個客戶端專用的代理被稱爲私有代理，衆多客戶端共享的代理被稱爲公共代理。
  • 高速緩存代理服務器，會利用用戶間的請求，匯入同一個代理服務器的用戶越多，高速緩存服務器就越有用。
• 代理鏈接的是兩個或多個使用相同協議的應用程序，而網關鏈接的則是兩個或多個使用不一樣協議的端點。
  • 網關扮演的是協議轉換器的角色，即便客戶端和服務器使用的是不一樣的協議，客戶端也能夠經過它完成與服務器之間的事物處裏。
• 商業化的代理服務也會實現網關的功能來支持SSL安全協議，SOCKS防火牆，FTP訪問，以及基於Web的應用程序。
• 代理服務器能夠看到並接觸到全部流過的HTTP流量，因此代理能夠監視流量並對其進行修改，以實現不少有用的增值的Web服務。
  • 網絡安全工程師一般會使用代理服務器來提升安全性。
  • 反向代理提升訪問慢速Web服務器上公共內容時的性能。反向代理稱爲服務器加速(Server accelerator)。
• 代理如何獲取流量:
  • 修改客戶端，手工配置，預先配置瀏覽器，代理的自動配置(Proxy Auto-Configuration, PAC), WPAD的代理髮現，Web代理自動發現協議。
  • 修改網絡
  • 修改DNS的命名空間
  • 修改Web服務器
• 代理能夠做爲訪問控制設備使用，HTTP定義了一種名爲代理認證(Proxy authentication)的機制，這種機制能夠阻止對內容的請求，直到用戶向代理提供了有效的訪問權限證書爲止。

緩存

緩存減小了冗餘的數據傳輸，緩存緩解了網絡瓶頸的問題，緩存下降了對原始服務器的要求，緩存下降了距離時延(較遠的地方加載頁面會更慢一些)。

• 緩存還能夠緩解網絡的瓶頸問題. 緩存在破壞瞬間擁塞(Flash Crowds)時顯得很是重要。
• 緩存的拓撲結構:
  • 緩存能夠是單個用戶專用的，也能夠是數千名用戶共享的，專用緩存被稱爲私有緩存(private cache)，共享的緩存被稱爲公有緩存(public cache).
• 不一樣的Web服務器爲HTTP cache-control和Expiration首部的設置提供了一些不一樣的限制。
• 專門有算法來計算文檔的使用期和緩存的新鮮度: 已緩存副本的使用期和已緩存副本的新鮮生存期(freshness lifetime)

集成點: 網關，隧道及中繼

• Web是一種強大的內容發佈工具(數據庫內容或動態生成的HTML頁面)。
• 在HTTP和其餘協議及應用程序之間起到接口做用的網關。
• 容許不一樣類型的Web應用程序互相通訊的應用程序接口。
• 容許用戶在HTTP鏈接上發送非HTTP流量的隧道。
• 做爲一種簡化的HTTP代理，一次將數據轉發一跳的中繼。

網關

網關能夠做爲某種翻譯器使用，它抽象出了一種可以到達資源的方法，網關是資源和應用程序之間的粘合劑。

• 網關能夠向數據庫發送查詢語句，或者生成動態的內容。

隧道

• HTTP的另外一種用法 -- Web隧道(Web tunnel), 這種方式能夠經過HTTP應用程序訪問使用非HTTP協議的應用程序。
• SSL隧道，隧道會經過一條HTTP鏈接來傳輸SSL流量，以穿過端口80的HTTP防火牆。

中繼

• HTTP中繼(relay)是沒有徹底遵循HTTP規範的簡單HTTP代理，中繼負責處理HTTP中創建鏈接的部分，而後對字節進行盲轉發。
• 盲中繼存在一個常見的問題是，因爲他們沒法正確處理Connection首部，因此在潛在的掛起keep-alive鏈接的可能。

Web機器人

• Web爬蟲是一種機器人，它們會遞歸地對各類信息性Web站點進行遍歷，獲取第一個Web頁面，而後獲取那個頁面指向的全部Web頁面，而後是哪些頁面指向全部Web頁面，以此類推。
• 爬蟲開始訪問的URL初始集合被稱做根集(root set).
• 文件系統中的符號鏈接會形成特定的潛在環路，由於它們會在目錄層次深度有限的狀況下，形成深度無限的假象。
• 爬蟲的自動化程度越高(人爲的監管越少)，就越可能陷入麻煩之中，有些技術的使用可使機器人有更好的表現:
  • 規劃化URL: 將URL轉換爲標準形式以免語法上的別名。
  • 廣度優先的爬行，將環路的影響最小化。
  • 節流: 限制一段時間內機器人能夠從一個Web站點獲取的頁面數量。
  • 限制URL的大小，URL/站點黑名單，模式檢測，內容指紋(計算校驗和，checksum)，人工監視。
• 大格局:
  • Web發展初期，搜索引擎就是一些至關簡單的數據庫，Web上有數十億可訪問的頁面，搜索引擎已經稱爲因特網用戶查找信息不可缺乏的工具。
  • 如今的搜索引擎都構建了一些名爲全文索引的複雜本地數據庫，裝載了全世界的Web頁面，以及這些頁面所包含的內容。全文索引就是一個數據庫，給一個單詞，它能夠當即提供包含這個單詞的全部文檔，建立索引後，就不須要對文檔自身進行掃描了。
• 相關性排名(relevancy ranking), 對一系列搜索結果的評分和排序處理。
• 用網關應用程序來生成一些在某些特定單詞上能夠更好欺騙搜索引擎相關性算法的假冒頁面。
• HTTP-NG: 模塊化三層: 報文傳輸層，遠程操做層和Web應用功能層。

識別，認證與安全

客戶端識別與cookie機制

• 承載用戶身份信息的HTTP首部
• 客戶端IP地址跟蹤，經過用戶的IP地址對其進行識別，用戶登陸，用認證方式來識別用戶，胖URL，一種在URL中嵌入識別信息的技術。
• cookie是當前識別用戶，實現持久會話的最好方式: 會話cookie和持久cookie。
  • 會話cookie睡一種臨時cookie，它記錄了用戶訪問站點時的設置和偏好，用戶退出瀏覽器時，會話cookie就被刪除了。
  • 持久cookie的生存時間更長一些，它們存儲在硬盤上，瀏覽器退出，計算機重啓時它們任然存在，一般會用持久cookie維護某個用戶會週期性訪問的站點的配置文件或登陸名。
• cookie是能夠禁止的，並且能夠經過日誌分析或其餘方式來實現大部分跟蹤記錄，因此cookie自身並非很大的安全隱患。

基本認證機制

• HTTP提供了一個原生的質詢/響應(challenge/response)框架，簡化了對用戶的認證過程。
• 基本認證便捷靈活，但極度不安全，用戶名和密碼都是以明文形式傳送的，沒有采起任何措施防止對報文的篡改。
• 摘要認證的改進:
  • 永遠不會以明文方式在網絡上發送密碼。
  • 能夠防止惡意用戶捕獲並重放認證的握手過程。
  • 能夠有選擇地防止對報文內容的篡改。
  • 防範其餘集中常見的攻擊方式。
• 使用傳輸層安全(Transport Layer Security, TLS)和安全HTTP(Secure HTTP, HTTPS)協議更安全一些。
• MD5摘要，用隨機數防止重放攻擊，摘要認證的握手機制:
  • 服務器會計算出一個隨機數，並將隨機數放到WWW-Authenticate質詢報文中。
  • 客戶端選擇一個算法，計算出密碼和其餘數據的摘要，將摘要放在一條Authorization報文中發回服務器。
  • 服務器接收摘要，選中的算法以及支撐數據，計算出與客戶端相同的摘要。
• 多重質詢: 若是服務器不瞭解客戶端能力，就能夠即提供基本認證質詢，又提供摘要認證質詢；客戶端面對多重質詢時，必須以它所支持的最強的質詢機制來應答。
• 域值，與被訪問服務器的標準根URL結合在一塊兒，定義了保護空間。

安全HTTP

重要的事務須要將HTTP和數字加密技術結合起來使用，才能保證安全。

• HTTPS是最流行的HTTP安全形式，數據都要經過安全層(SSL或TLS)進行加密處理。
• 密碼: 對文本進行編碼，使偷窺者沒法識別的算法。
• 密鑰: 改變密碼行爲的數字化參數。
• 對稱密鑰加密系統: 編解碼使用相同密鑰的算法。
• 不對稱密鑰加密系統: 編解碼使用不一樣密鑰的算法。
• 公開密鑰加密系統: 一種可以使數百萬計算機便攜地發送機密報文的系統。
• 數字簽名: 用來驗證報文未被僞造或篡改的校驗和。
• 數字證書: 由一個可信的組織驗證和簽發的識別信息。
• 流行的對稱密鑰加密算法包括: DES, Triple-DES, RC2和RC4.

內容發佈與分發

Web主機託管

• 對內容資源的存儲、協調以及管理的職責稱爲Web主機託管(主機託管使Web服務器的主要功能之一)。
• 主機託管服務，專用託管，虛擬主機託管

重定向與負載均衡

• HTTP並非獨立運行在網上，不少協議都會在HTTP報文的傳輸過程當中對其數據進行管理：
  • HTTP 重定向
  • DNS 重定向
  • 任撥路由
  • 策略路由
  • IP MAC轉發
  • IP地址轉發
  • WCCP(Web緩存協調協議)
  • ICP(緩存間通訊協議)
  • HTCP(超文本緩存協議)
  • NECP(網元控制協議)
  • CARP(緩存陣列路由協議)
  • WPAD(Web代理自動發現協議)
• 網絡中的重定向的優勢: 可靠地執行HTTP事務，最小化時延，節約網路帶寬。