04.HTTP交互.ppt_第1頁
04.HTTP交互.ppt_第2頁
04.HTTP交互.ppt_第3頁
04.HTTP交互.ppt_第4頁
04.HTTP交互.ppt_第5頁
已閱讀5頁,還剩14頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

2 6Http交互的宏觀運行原理 2 6 1請求 響應(yīng)協(xié)議HTTP協(xié)議是基于請求 響應(yīng)模式的 客戶機向服務(wù)器發(fā)送請求 RequestRequest 絕大多數(shù)的HTTP通信都是由客戶發(fā)起的 包含一個作用于服務(wù)器上某個資源的請求 例如下載服務(wù)器上的文件 請求包含以下內(nèi)容 請求方法 method 例如 get 統(tǒng)一資源標(biāo)識符 URI 例如 2 6Http交互的宏觀運行原理 續(xù) 服務(wù)器向客戶發(fā)送響應(yīng) ResponseResponse 服務(wù)器在收到客戶的請求后 按照客戶的要求對指定資源進行適當(dāng)處理 例如檢索到客戶所需的文件 并給予相應(yīng)的響應(yīng) 響應(yīng)包含以下內(nèi)容 一個狀態(tài)行 包括 消息的協(xié)議版本號 version 一個成功或錯誤的狀態(tài)碼 successorerrorcode MIME格式的消息 服務(wù)器信息 serverinformation 實體元信息 meta information 還可能會有實體的正文內(nèi)容 bodycontent 2 6Http交互的宏觀運行原理 續(xù) 2 6 2客戶與服務(wù)器通信的三種方式 直接通信 DirectCommunicationDirectCommunication 這種方式是一種最簡單的情況 通過用戶代理 UA 和源服務(wù)器 O 之間的單個連接來完成 如圖所示 2 6Http交互的宏觀運行原理 續(xù) 通過中介的HTTP通信中介有三種常見的形式 代理代理 Proxy 網(wǎng)關(guān)網(wǎng)關(guān) Gateway 和隧道隧道 Tunnel Proxy Proxy是一種將請求轉(zhuǎn)發(fā) forwarding 的代理 agent 接收客戶的請求 在對該請求進行局部或者全部的修改后 將請求轉(zhuǎn)發(fā)給URI所指示的服務(wù)器 服務(wù)器把響應(yīng)發(fā)回給Proxy Proxy然后把響應(yīng)再發(fā)給客戶端 2 6Http交互的宏觀運行原理 續(xù) 通過中介的HTTP通信 續(xù) Gateway Gateway是一種接收 receiving 代理 通常作為兩類服務(wù)器 e g Web和Email 的中介 將一類服務(wù)器所支持的協(xié)議翻譯為另一類服務(wù)器所支持的協(xié)議 示例 HTTP POP3網(wǎng)關(guān)在收到客戶的請求 HTTP協(xié)議 時 對其進行轉(zhuǎn)換 并以其它協(xié)議 POP3 的格式提交給POP3服務(wù)器 當(dāng)收到POP3服務(wù)器的響應(yīng)后 將其以HTTP的格式返回給客戶 Tunnel Tunnel是兩個連接之間的中繼系統(tǒng) 與Proxy和Gateway不同 它不對HTTP消息作任何修改 當(dāng)客戶與服務(wù)器的通信需要通過防火墻 firewall 等中介系統(tǒng)時 就可以使用Tunnel 2 6Http交互的宏觀運行原理 續(xù) 通過中介的HTTP通信 續(xù) 通常 可以以任意的方式來組合各種中介系統(tǒng) 從而構(gòu)成不同的應(yīng)用解決方案 如圖所示 在用戶代理 UA 和源服務(wù)器 O 之間有三個中介 A B和C 一個通過整個鏈的請求或響應(yīng)消息必須經(jīng)過四個獨立的連接 盡管該圖中的連接是線性的 事實上 每個參與者都可能進行多重的 并發(fā)的通訊 例如 B還可以從其它許多客戶機接收請求 而不僅僅局限于A 并將這些請求傳送給其它的服務(wù)器 而不僅僅局限于C 這些工作可以同時以并發(fā)的方式完成 2 6Http交互的宏觀運行原理 續(xù) 2 6Http交互的宏觀運行原理 續(xù) 使用緩存的HTTP通信在HTTP通信中的任何一個成員 包括 客戶代理 服務(wù)器 中介 除隧道外 均可以采用內(nèi)部的緩存來處理客戶請求 如果HTTP通信鏈中的一個成員已經(jīng)對某個請求的響應(yīng)進行了緩存 那么它就不再將該請求向前傳遞 而直接將響應(yīng)返回給用戶 從而縮短請求 響應(yīng)鏈 優(yōu)點 這樣的處理方式能減少請求 響應(yīng)鏈路上的網(wǎng)絡(luò)負(fù)載 提高響應(yīng)速度 在用戶經(jīng)常提出同樣的請求 或者多個用戶具有類似請求的情況下 該方式非常有用 例如 公司的Intranet上 或者校園網(wǎng)的網(wǎng)絡(luò)中心 都可以設(shè)置Proxy 對于大家經(jīng)常下載的公用軟件和資料 可以直接從Proxy上獲得 這樣可以加快下載速度 降低網(wǎng)絡(luò)費用 2 6Http交互的宏觀運行原理 續(xù) 下圖是針對一個未被UA或A所緩存的請求 而B中曾經(jīng)對該請求的響應(yīng)進行過緩存 B之所以會對該請求進行緩存 可能是該用戶或其它用戶在以前提交過同樣的請求 2 7Http交互的內(nèi)部操作過程 2 7 1基于網(wǎng)絡(luò)層的HTTP交互過程HTTP是應(yīng)用層協(xié)議 它從應(yīng)用的角度規(guī)定了客戶和服務(wù)器在通信時的消息格式和語義 而它的實現(xiàn)必須建立在其下的網(wǎng)絡(luò)層之上 下面 以Socket這一最常用的網(wǎng)絡(luò)層編程接口為例來說明客戶和服務(wù)器是如何通過網(wǎng)絡(luò)層來實現(xiàn)HTTP交互 整個過程包括四個步驟 建立連接 發(fā)送請求 發(fā)送響應(yīng) 關(guān)閉連接 2 7Http交互的內(nèi)部操作過程 續(xù) 建立連接HTTP服務(wù)器始終在HTTP端口守候客戶的連接要求 客戶打開一個套接字 Socket 并把它綁定在一個隨機選擇的端口上 然后通過該套接字向服務(wù)器的HTTP端口發(fā)出連接要求 當(dāng)有一個連接要求到達時 服務(wù)器生成一個新的套接字 然后產(chǎn)生一個新的過程或線程來處理用戶的請求 2 7Http交互的內(nèi)部操作過程 續(xù) 建立連接 續(xù) 2 7Http交互的內(nèi)部操作過程 續(xù) 發(fā)送請求在客戶和服務(wù)器成功建立連接后 客戶機可以使用Socket接口中的send write等API將請求消息發(fā)送出去 而服務(wù)器則可以使用Socket接口中的recv read等API來接收請求消息 發(fā)送響應(yīng)服務(wù)器在處理完客戶的請求后 要向客戶機發(fā)送響應(yīng)消息 此時可使用Socket接口中的send write等API將響應(yīng)消息發(fā)送出去 而客戶則使用Socket接口中的recv read等API來接收響應(yīng)消息 注意 將客戶的請求和服務(wù)器的響應(yīng)正確地發(fā)送給對方是網(wǎng)絡(luò)層的任務(wù) 而為了確??蛻艉头?wù)器能夠正確地理解對方傳遞的消息則是HTTP這一應(yīng)用層協(xié)議的任務(wù) 即需要規(guī)定客戶和服務(wù)器雙方所發(fā)送消息的格式和語義 2 7Http交互的內(nèi)部操作過程 續(xù) 關(guān)閉連接在一次請求 響應(yīng)完畢后 客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束HTTP交互 HTTP 1 0中僅支持非持久連接 因此 在一次請求 響應(yīng)完畢后 客戶或服務(wù)器將通過關(guān)閉套接字來結(jié)束HTTP交互 在HTTP 1 1中 連接的缺省類型為持久連接 即在客戶與服務(wù)器建立連接后 可以發(fā)送多個請求和響應(yīng) 直到客戶或者服務(wù)器顯式地關(guān)閉該連接 之后 客戶在發(fā)送新的請求之前 必須與服務(wù)器重新建立連接 使用持久連接具有以下優(yōu)點 節(jié)省宿主機的開銷 減少用戶的等待時間 將減少網(wǎng)絡(luò)流量 緩解網(wǎng)絡(luò)堵塞 客戶的請求和服務(wù)器的響應(yīng)可以以流水線 pipeline 的方式運作 這樣可以提高連接的使用效率 減少用戶的等待時間 2 7Http交互的內(nèi)部操作過程 續(xù) 2 2一個實際的例子下面 我們給出一個實際的例子 通過分析客戶 服務(wù)器在HTTP交互中發(fā)送的數(shù)據(jù)包來進一步說明HTTP作為一個網(wǎng)絡(luò)層之上的應(yīng)用是如何利用TCP IP協(xié)議所提供的可靠通信服務(wù)的 2 7Http交互的內(nèi)部操作過程 續(xù) 說明 在實際情況下 上述數(shù)據(jù)包是相互混雜的 此處為了清晰起見 將它們分開列出 2 7Http交互的內(nèi)部操作過程 續(xù) 2 7Http交互的內(nèi)部操作過程 續(xù) 從該例子中可以看出 兩個TCP連接是獨立的 它們在各自的數(shù)據(jù)傳輸完畢后分別結(jié)束 客戶與服務(wù)器的交互過程中 除了傳輸?shù)腍TML文件和圖像文件是有效負(fù)載以外 其它的數(shù)據(jù)包是為了傳輸文件而發(fā)送的額外負(fù)載 即使不傳輸任何文件 客戶和服務(wù)器之間為了建立和關(guān)閉連接至少需要交換7個數(shù)據(jù)包 這占據(jù)HTTP協(xié)議開銷中的一大部分 2 7Http交互的內(nèi)部操作過程 要求 能力宏觀上掌握HTTP協(xié)議運作

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論