HTTP協議-HTTP權威指南

1.HTTP基礎

http的特色：
 支持B/S模式模式，無狀態。
http消息：由2部分組成起始行(請求行或狀態行)和MIME信息（頭和內容）
http中介：有3種-服務器緩存代理、網關、隧道。代理根據URL的絕對格式來接收請求，重寫所有或部分消息，經過URL的標識把格式化後的請求發送給服務器。網關是一個接收代理，做爲一個其它服務器的上層，而且若是必須的話，能夠把請求翻譯給下層的服務器協議。隧道做爲不改變消息的2個鏈接之間的中繼點，經常使用於通訊須要經過一箇中介（如防火牆）或者中介不能識別消息的內容的地方。

URL由9個部分組成：
<方案>://<用戶名>:<密碼>@<主機>:<端口>/<路徑>;<參數>?<查詢>#<片斷>
 其中:// : @ / ; ? # 是各字段的分隔符，路勁後面的部分將存放在HTTP報文的實體部分被髮送
方案：使用的協議，http,https,ftp
參數：某些方案能夠用此來指定參數
  ftp://prep.ai.mit.edu/pub/gnu.giz;type=d 指定以2進制傳輸
  type爲參數名，d爲值
查詢：某些方案用此傳遞查詢條件以激活應用程序。
   http://www.joes.com/check.cgi?item=12731&color=red 經過查詢字段給出查詢條件
片斷：一小片資源的名字。瀏覽器不會把該字段傳送給服務器，服務器的資源都是一頁一頁訪問的，若是用戶想獲取一頁中的部分資源，那麼瀏覽器會請求整個資源，但只顯示指定的frage部分。
   http://www.joes.com/tools.html#drills 只請求/tools.html頁面下的drills部分資源
報文向下遊流動定理：無論是請求報文仍是響應報文都向下游流動

2.HTTP報文-請求與響應

頭部的整個部分的接收標誌： 空行+CRLF
http方法：經常使用方法有如下7種
 *GET 從服務器請求獲取一份文檔
 *PUT 將請求的主體部分存儲在服務器上
 *HEAD 只從服務器獲取文檔的首部
 *POST 向服務器發送須要處理的數據
 *TRACE 對可能通過代理服務器傳送到服務器上去的報文進行追蹤。中介收到trace請求會將本身的主機地址添加到報文的via頭部。目的主機在*響應的實體中發回接收的報文，這樣客戶端就能夠判斷請求是否被中介修改過。
 *OPTIONS 詢問服務器是否支持某些方法或資源
 *DELETE 從服務器上刪除一份文檔
http頭部分類：
 *通用頭部 date connection MIME-Version Trailer via   pragma  update  transfer-encoding ...
 *請求頭部 client-ip from host referer UA-color    UA-CPU UA-Disp UA-OS UA-Pixels UA-Agent accept  accept-*charset accept-encoding accept-language TE    if-match if-modified-since if-none-match if-range    if-*unmodified-since range authorization cookie    max-forward proxy-authorization...
 *響應頭部 server age public retry-after title warning ..
 *實體頭部 content-Type content-encoding content-length content-language content-location allow location ...
 *擴展頭部
實體能夠承載的信息：圖片 視頻 html文檔 電子郵件等
信息狀態碼：
 *100~199：信息狀態碼
 *200~299：成功狀態碼
 *300~399：重定向狀態碼
 *400~499：客戶端錯誤狀態碼
 *500~599：服務器端錯誤狀態碼
3.HTTP中的TCP鏈接管理
一條tcp鏈接是經過4個值惟一識別的<src_ip,src_port,des_ip,des_port>,2條不一樣的鏈接不能擁有徹底相同的4個值，源端的主動鏈接在同一時刻不可能有多個鏈接在同一端口src_port上。
HTTP的客戶端與服務器的常規事務交互過程：
 *客戶端從URL中解析出主機名和端口號
 *客戶端經過DNS查詢主機名的IP
 *客戶端發起到主機IP+端口號的鏈接(3次握手)
 *客戶端發起請求
 *服務器響應請求，客戶端讀取請求
 *服務器關閉讀端口，客戶端關閉讀端口(鏈接關閉)
HTTP的事務時延(從交互過程能夠看出)
 *若是最近沒有對服務器主機進行訪問,DNS解析服務器IP可能須要10+S的時間
 *TCP鏈接(3次握手)時延至多2S，但同時有多個鏈接到達服務器，那麼這個時延會累加起來(串行處理)
 *服務器處理請求可能須要花費必定的時間
 *請求發送和響應回送都須要必定的時間
常見的TCP時延
 *TCP鏈接的3次握手(該過程對http程序員不可見)：一個小的HTTP事務在鏈接創建上花的時間比太大
 *TCP進行擁塞控制採用的慢啓動
 *TCP數據彙集的Nagle算法
 *用於捎帶確認的TCP延遲確認算法
 *TIME_WAIT時延和客戶端端口耗盡
TCP鏈接的3次握手時延
 *能夠將客戶端請求放入第3次客戶端應答中去("捎帶")
TCP延遲確認算法
 *每一個TCP段都有一個序列號和校驗和，接收者收到無缺的段時都會響應一個小的確認分組，若是發送者沒有在指定的窗口時間內收到確認信息，發送者任務分組已經被破壞，並從新發送數據。 因爲確認分組很小，tcp容許在發往相同方向的數據分組中對其進行"捎帶"。爲了找到同向的數據分組，不少TCP棧都實現了"延遲確認"算法。該算法在一個特定的窗口時間100~200ms內將輸出確認放在緩衝區內，以等待可以捎帶它的數據分組，若是沒有等到，確認信息就放在單獨的分組中發送出去。
 *HTTP具備雙峯特性的請求-應答機制下降了捎帶信息的可能。因此在HTTP中延遲算法會引發很大的延時，根據操做系統的不一樣能夠禁止延遲確認算法
TCP慢啓動(流量控制)
 *TCP傳輸數據的性能還取決於TCP鏈接的使用期(age)。起初會限制數據發送的最大速度，若是數據成功傳輸(收到確認)一次，容許發送數據的最大速度會提升，這被稱爲TCP的慢啓動。擁塞窗口慢慢的被打開。因爲存在這種擁塞控制已經調諧的鏈接會比新的鏈接傳輸速度快。
Nagle算法(擁塞控制)
 *Nagle算法算法試圖將大量發往同一個目的地的TCP數據綁定在一個包中，以提升網絡效率，減小網絡中包的數量。Nagle算法將數據緩存盡力全尺寸發送(以太網1500字節)
 *Nagle算法會引發HTTP性能問題：小的HTTP報文沒法填滿一個TCP分組，從而被緩存，致使較大延時。同時Nagle算法每發送一個包要等待確認信息才發送下一個包，不然重發上一個包，而延遲確認算法在目的端會緩存確認信息100~200ms，這將致使Nagle算法發送2個包之間的時延較大。
 *TCP_NODELAY參數能夠禁止Nagle算法，提升發包速率，但要確保TCP寫入大塊的數據，這樣不會產生一堆小的分組
端口耗盡(TIME_WAIT形成的端口耗盡)
 *TIME_WAIT端口耗滿是很嚴重的問題，影響了性能根基。緣由：當某個TCP端點關閉TCP鏈接時，會在網卡內存中維持一個控制塊，用來記錄最近關閉鏈接的IP地址和端口號。TIME_WAIT維持時間爲最大分段生存期(tcp報文在網絡中的最長生存時間)的2倍,稱爲2MSL，一般爲2min以上，以確保這段時間內不會建立具備相同IP和端口號的新的鏈接(不然網絡上具備該IP和端口的數據可能到達新的TCP鏈接的數據緩存中)
 *tcp客戶端每次鏈接到每次鏈接到服務器上去，都會得到一個新的源端口，以實現鏈接的惟一性。源端口是有限的，假如爲60000個，但因爲在2MSL內鏈接是不能重用的，每秒能鏈接的次數6000/120=500次/秒，這就能夠確保不會遇到端口耗盡的問題
HTTP鏈接的處理
 *connection：close 要求對方在發送完下一條報文時，能夠關閉鏈接
 *串行事務處理時延：若是串行的處理事務，每一事務創建本身的鏈接，那麼TCP鏈接延時和慢啓動延時會疊加起來。解決辦法：並行鏈接，經過多條鏈接同時發送請求；持久鏈接，重用tcp鏈接；管道化鏈接，經過共享的tcp鏈接發起併發的http請求。
 *並行鏈接：將鏈接時間和事務處理重疊，可能會加快頁面的加載速度。但也會收到網絡帶寬限制。
 *持久鏈接有2種類型：keep-alive和persistent: connection：keep-alive 客戶端請求將鏈接保持在打開狀態，若是服務器的返回中沒有該頭域，那麼客戶端認爲服務器不支持keep-alive.persistent持久鏈接與keep-alive差很少
 *管道化鏈接：管道化鏈接就是持久鏈接上加了管道化請求，讓服務器能夠緩存客戶端的消息。持久鏈接消除TCP鏈接延遲，管道化請求消除(重疊)傳輸延時。管道化請求要求響應按照請求的順序回送。服務器出錯時，客戶端不知道發送的請求哪些沒有執行。因此有些請求方法(非冪等請求：屢次調用該方法會將產生的結果累積)不能夠在管道化鏈接中發送，
HTTP關閉鏈接
 *服務器和客戶端均可以在任意時刻關閉一條TCP鏈接
 *每條TCP響應都應該有精確的content-length頭部，不然就只能依賴於服務器關閉鏈接來講明數據的真實末尾
 *tcp關閉和重置錯誤：關閉鏈接的讀端口是很危險的，當B向A一個讀端口已經關閉的鏈接中寫數據時，A將會向B發送TCP"鏈接被對端重置"報文，收到這條報文後，B端的TCP棧將清除本身的輸入緩存和輸出緩存，當B端讀緩存時，會獲得"鏈接被對端重置錯誤"
 *安全關閉：不發送數據的一方應該首先關閉本身的輸出端，當另外一方也關閉本身的輸出端時，鏈接被TCP棧徹底關閉，這樣不會發送重置的錯誤。
HTTP服務器的功能
 *創建鏈接-處理新鏈接,反DNS客戶主機名識別,ident肯定客戶端用戶
 *接收請求-解析請求行,讀取報文頭部,檢測以CRLF結尾的標識頭部結尾的空行,           讀取content-length頭部標識長度的請求主體。
    服務器有多種：單線程,多進程多線程,複用IO,複用IO的多線程服務器
 *處理請求
 *訪問資源-訪問docroot下的資源，訪問權限控制
 *構造響應-
 *發送響應
 *記錄事務處理過程
4.HTTP代理
 代理的運行：代理既是客戶端又是服務器。客戶端向代理髮送請求報文，代理必須向服務器同樣，正確的處理請求和鏈接，而後返回響應；同時，代理自身要向服務器發出請求，其行爲像客戶端同樣，要發出請求並接收響應；若是代理要建立本身的http代理就要遵循http客戶端和服務器制定的規則。
代理功能
 兒童過濾器、文檔訪問控制、安全防火牆、web緩存、反向代理、內容路由器(根據網絡流量或內容類型將請求導向特定的服務器)、匿名者(主動刪除客戶端身份特性如IP、FROM、REFERER、URI的會話ID、cookie等首部)
代理與網關的區別
 代理鏈接的是2個或多個使用相同協議的應用程序，而網關鏈接的是2個或多個使用不一樣協議的的端點，扮演協議轉換的功能。
代理服務器在網絡中的部署
 *出口部署：部署在本網絡鏈接internet的出口點，控制本網與外網的流量，提供防火牆保護。
 *訪問(入口)代理：經常放在ISP訪問點上，處理來自客戶的聚合請求。
 *反向代理：一般部署在網絡邊緣，冒用服務器的名字和IP，這樣全部的請求就會發送給代理
 *網絡交換代理：部署在internet對等交換點，經過緩存來減輕internet的擁塞，並對流量進行監控
客戶端的代理配置
 能夠經過瀏覽器手動配置或代理自動配置(PAC)

5.HTTP緩存
緩存優勢
 *減小了冗餘的數據傳輸(經過向緩存請求數據)
 *緩減了網絡帶寬瓶頸的問題(客戶請求經過幾種不一樣網速的網絡到達服務器，網絡帶寬將以最小帶寬的網絡決定，因此緩存可以在必定程度上提升網絡帶寬)
 *下降了對原始服務器的要求
 *下降了距離時延：對決絕瞬時擁塞(同一時間段服務器接收大量請求)和距離時延，效果較好
緩存的命中與未命中
 使用緩存中已有的副本爲到達緩存的請求提供服務，稱爲命中；若是對應該請求沒有副本而被轉發給服務器，這被成爲緩存的未命中。
再驗證
 爲了保證副本不過時，須要進行新鮮度檢測，這稱爲http的再驗證revalidation。 使用If-Modified-Since頭部能夠進行再驗證，若是服務器未被修改將發送一個304 Not Modified響應，不然發送200 OK響應。若是該資源在服務器上已經被刪除了，則服務器將發送404 Not Found響應。If-None-Match頭部經過實體的惟一標籤驗證也是一種較好驗證方法。再驗證通常都使用If條件頭部
緩存的工做過程
 *接收-從網絡中讀取抵達的請求報文
 *解析-緩存提取URL和各類首部
 *查詢-查看是否有本地副本,若是沒有,就獲取一份副本並保持在本地
 *新鮮度檢查-查看已緩存副本是否足夠新鮮,若是不是,就詢問服務器是否有任何更新(再驗證)
 *建立響應-使用新的首部和已緩存的主體建立一條響應報文
 *發送響應-發送給客戶端
 *日誌-建立並記錄一條日誌
服務器控制緩存的能力
 *cache-control：no-store 將相應發給客戶端，可是自身不緩存副本。
 *cache-control：no-cache 將相應發給客戶端，自身緩存一份副本，可是沒有再驗證以前不能使用該副本。
 *cache-control：max-age 從服務器將文檔傳來時起，文檔處於新鮮度的秒數。
 *cache-control： expires 新鮮度有效的絕對日期
 *cache-control： must-revalidate 強制新鮮度檢測
客戶端控制緩存的能力
 *cache-control： min-fresh=<s> 要求緩存至少在將來s秒內將文檔保存新鮮
 *cache-control： no-cache 要求緩存對資源進行再驗證
 *cache-control： no-store 要求緩存不能保留副本
 *cache-control： only-if-cached 緩存中有副本則發送，沒有就算了

6.集成點：網關、隧道和中繼
Web是一種強大的內容發佈工具。Web瀏覽器是一種HTTP協議的應用程序，經過HTTP協議傳輸HTML標記文本，HTML標
記文本能夠告知瀏覽器要顯示的內容和如何顯示這些內容。固然，除了網頁以外，http還能夠傳輸其餘內容。
HTML網頁可使用frontpage軟件來製做，後綴爲.htm或.html。
HTML:超文本標記語言，旨在顯示數據。 XML:可擴展標記語言，標籤沒有被預約義，是對HTML的補充，旨在傳輸數據而不是顯示數據。

網關：實現HTTP協議與其餘協議或應用通訊，從而訪問HTTP之外的資源。網關的種類不少，主要分爲2大類：協議網關(HTTP/FTP,HTTPS/HTTP)和資源網關(應用程序服務器網關，數據庫查詢網關)
將HTTP流量導向網關時所使用的方式與將流量導向代理的方式相同，最多見的就是顯示的配置瀏覽器，指明使用的網關地址，對流量進行透明攔截。
資源網關最多見的是應用程序服務器(網關)。工做過程爲：客戶端經過HTTP鏈接到應用程序服務器，但應用程序服務器將請求經過一個網關應用編程接口API發送給運行在服務器上的應用程序。(應用程序服務器和網關在同一臺主機上)
第一個流行的應用程序網關API就是通用網關接口CGI(Common Gateway Interface),CGI是一個標準接口集,用以在URL與應用程序之間傳遞參數並啓動應用程序。經過CGI能夠調用任何語言編寫的應用程序。
一條發向網關的http請求：
GET ftp://ftp.irs.gov/pub/00-index.txt HTTP/1.0
HOST: ftp.irs.gov
USER-AGENT:superbroser 4.2    #瀏覽器型號

隧道:做用容許用戶經過HTTP鏈接發送非HTTP流量，這樣就能夠在HTTP上捎帶其餘協議數據，從而這類流量能夠穿過只容許web流量經過的防火牆。
隧道須要一個隧道網關，經過隧道網關轉發非HTTP流量數據,客戶端與隧道網關之間的隧道創建過程使用CONNECT方法。具體過程以下：客戶端發送一條CONNECT請求給隧道網關,
隧道網關創建到某服務器的TCP鏈接,並隧道網關返回客戶端響應,這樣就創建完成了客戶端到隧道網關的HTTP隧道;客戶端經過HTTP隧道發送的全部數據都被隧道網關直接轉發給
TCP鏈接,某服務器發送的全部數據都會經過HTTP隧道轉發給客戶端。

網頁機器人：和因此瀏覽器同樣，網頁機器人也屬於HTTP客戶端，但通常運行在高速計算機上。須要遵照HTTP規範。網頁機器人須要考慮較多問題：根基、環路避免等

7.HTTP客戶端身份識別的方法：
1).承載用戶身份信息的HTTP首部:FROM;USER-AGENT;REFERER;AUTHORIZATION;CLIENT-IP;COOKIE等
2).客戶端IP地址跟蹤：使用socket鏈接能夠得到客戶端IP，可是IP不必定對應着某個用戶
3).用戶登陸；用戶認證成功後，瀏覽器每次訪問時都會發送AUTHORIZATION首部用戶認證信息
4).胖URL-嵌入識別信息：用戶首次訪問網絡站點時(不帶ID)服務器爲其生成一個惟一的ID添加在URL後面，而後服務器會將這個被標識的客戶端導向該網站全部的胖URL，服務器收到胖URL就回去查找該胖URL對應的用戶信息
5).cookie：用於標識用戶信息，以記錄的形式被瀏覽器被保存在cookie數據庫中。能夠分爲2類：會話cookie(用戶退出瀏覽器時被刪除)和持久cookie(做爲文件保存在硬盤上)。服務器發送SET-COOKIE首部要求客戶端產生一個cookie記錄信息。
cookie存在隱私問題，設置瀏覽器能夠禁止cookie的使用。
cookie產生過程：
客戶端請求->
GET /index.html HTTP/1.0
HOST: www.joes-hardware.com
服務器響應：要求產生cookie，以便於使用客戶端->
HTTP/1.0 200 OK
SET-COOKIE:ID="34294";DOMAIN="YAHO.COM"
CONTENT-TYPE:TEXT/HTML
CONTENT-LENGTH:1903
...
客戶端從新發送請求，帶有客戶端cookie標誌->
GET /index.html HTTP/1.0
HOST: www.joes-hardware.comCOOKIE:ID="34294"