Web(World Wide Web)
20世紀90年代初
因特網應用
Web應用的組成
- 文檔格式標準 HTML
- Web瀏覽器
- Web服務器
- 應用層協(xié)議HTTP
網頁(Web Page)
由對象組成每辟。對象是一個文件瞪讼，如HTML文件，JPEG圖像，Java程序再沧，視頻片段等。
對象可通過一個URL地址尋址棕所。
Web頁面常由一個HTML基本文件和多個引用對象構成瀑踢。
URL地址
URL(Uniform Resoure Locator)：統(tǒng)一資源定位器 RFC1738
Scheme://host:port/path
用以尋址Web對象
由一個存放對象的服務器主機名和對象路徑名構成。
超文本傳輸協(xié)議(HyperText Transfer Protocol,HTTP)
HTTP 由客戶端程序和服務端程序實現(xiàn)哄陶，二者通過交換HTTP報文會話帆阳。
HTTP規(guī)范定義了HTTP客戶端和服務端之間的通信協(xié)議。
Web瀏覽器實現(xiàn)HTTP客戶端,請求屋吨、接收蜒谤、展示Web對象
Web服務器實現(xiàn)HTTP服務端,響應客戶的請求，發(fā)送對象
HTTP使用TCP作為支撐運輸層協(xié)議至扰。
端口：80
無狀態(tài)協(xié)議 服務器不保存關于客戶的任何信息
服務器向客戶發(fā)送被請求的文件鳍徽，而不存儲任何關于客戶的狀態(tài)信息。
往返時間（Round-Trip Time,RTT)
一個短分組從客戶到服務器然后再返回客戶所花費的時間敢课。
非持續(xù)連接
某客戶和服務器的一次會話中阶祭，每個請求/響應對通過一個單獨的TCP連接傳輸
HTTP 1.0版本使用非持續(xù)性連接
串行非持續(xù)連接
對多個待獲得的web對象，客戶端一次只請求一個對象直秆，待前一個對象接收完畢后再發(fā)送對下一個對象的請求濒募。
時間分析
- 為請求一個小web對象(對象傳輸時間可忽略)，需要消耗兩個RTT時間圾结。第一個RTT執(zhí)行TCP握手的前兩部分瑰剃，第二個RTT結合TCP握手的第三部分發(fā)送請求報文，接收響應報文疫稿。
- 請求一個引用a個小web對象的小基本web對象需要耗時
個RTT
并行非持續(xù)連接
瀏覽器通常支持并行的TCP連接。并行TCP連接數(shù)通常為5~10個舀凛。
對多個待獲得的web對象，客戶端一次可同時建立多個TCP連接梯醒，以同時請求多個web對象。
時間分析
- 建立TCP連接并獲得小基本web文檔需要兩個RTT。若在瀏覽器并行能力之內猫胁，被引用的多個小web對象可同時獲得弃秆，需要兩個RTT氢卡。共4個RTT。
持續(xù)連接
某客戶和服務器的一次會話中们拙，所有請求/響應對經同一TCP連接傳輸
HTTP 1.1版本在默認方式下采用持續(xù)連接突勇，但也可由客戶端/服務器配置為非持續(xù)連接。
無流水(pipelining)的持久性連接
客戶端只有收到前一個響應后才發(fā)送新的請求
可理解為同個TCP內的串行
時間分析
- 建立TCP連接并獲得小基本web文檔需要兩個RTT。每個被引用的小web對象耗時1個RTT氏捞。
- 請求一個引用a個小web對象的小基本web對象需要耗時
個RTT
帶有流水機制的持久性連接
客戶端只要遇到一個引用對象就盡快發(fā)出請求
可理解為同個TCP內的并行
HTTP 1.1的默認選項
時間分析
- 理想情況下液茎，收到所有的引用對象只需耗時約1個RTT
- 請求一個引用a個小web對象的小基本web對象需要耗時
個RTT
TCP 三次握手
1.客戶向服務器發(fā)送一個小TCP報文段；
2.服務器用一個小TCP報文段做出確認和響應辞嗡；
3.客戶向服務器返回確認和一個HTTP請求報文豁护；
4.服務器返回相應HTML文件;
HTTP報文格式
HTTP規(guī)范
RFC 1945 , RFC 2616
用ASCII文本書寫
HTTP協(xié)議有兩類消息，請求消息(request)和響應消息(response)
HTTP 請求報文
請求行 HTTP請求報文的第一行
- 方法字段 值可用為：GET POST HEAD PUT DELETE 欲间； 絕大多數(shù)HTTP請求報文使用GET方法
- URL字段 請求對象的標識
- HTTP版本字段
方法
- GET方法 請求一個對象
- POST方法 提交表單
- HEAD方法 類GET，但返回特殊的響應報文(無實體體)断部，而非所請求的對象猎贴，常用于調試
- PUT方法 用戶上傳對象到指定Web服務器的指定目錄
- DELETE方法 允許用戶刪除Web服務器上的對象
首部行 請求行后繼的其它行，包含一些會話信息
空行 回車換行蝴光，分隔首部行和實體體
實體體(entity body)
GET方法下實體體為空
POST方法下實體體包含表單信息
HTTP 響應報文
狀態(tài)行
- 協(xié)議版本字段
- 狀態(tài)碼
- 狀態(tài)信息
常見狀態(tài)碼
- 200 OK
- 301 Moved Permanently
- 400 Bad Request
- 404 Not Found
- 505 HTTP Version Not Supported
首部行
空行
實體體
包含了所請求的對象
cookie
HTTP是無狀態(tài)協(xié)議她渴，但cookie技術允許服務器識別用戶
cookie在無狀態(tài)的HTTP之上建立一個用戶會話層
參見 [RFC 6265]
cookie組件
- HTTP響應報文中的cookie首部行
- HTTP請求報文中的cookie首部行
- 用戶端系統(tǒng)中保留一個cookie文件，由瀏覽器管理
- Web站點中的后臺數(shù)據(jù)庫
cookie技術的爭議在于它可能泄露用戶的隱私
Web緩存器（代理服務器）
代表原Web服務器來響應HTTP請求的網絡實體
- Web緩沖器的存儲空間保存最近請求過的對象的副本
- 可以配置用戶瀏覽器蔑祟，使得HTTP請求首先指向Web緩沖器
Web緩沖器通常由ISP購買并安裝
條件GET方法
允許緩存器證實其緩存的副本是新的趁耗。
如果緩存器有web對象最新的版本，則初始服務器不需要向緩存器發(fā)送該web對象
在HTTP請求消息中聲明所持有版本的日期
If-modified-since: <date>
如果緩存的版本是最新的疆虚，則響應消息中不包含對象
HTTP/1.0 304 Not Modified
web緩存工作機制
- 瀏覽器向web緩存器請求web對象A,若該請求緩存未命中苛败，則緩存器向存放A的初始服務器請求web對象A并緩存之，而后將對象A發(fā)送給瀏覽器径簿。
注意初始服務器給緩存器的響應報文中包括首部行:Last-Modified:date 1罢屈，該行說明了對象A上次被修改的時間。 - 一定時間后篇亭，瀏覽器再次向web緩存器請求web對象A,該請求緩存命中缠捌，且瀏覽器注意到A的上次修改時間為date 1。
緩存器向初始服務器發(fā)送條件GET請求译蒂，該請求在對web對象A的普通請求基礎上添加了首部行：If-Modified-Since:date 1曼月。 - 初始服務器收到緩存器的條件GET請求，檢查在date 1后該對象有無修改柔昼，若有修改哑芹，發(fā)送新的對象A并附上最近一次修改的時間。若未修改岳锁，發(fā)送帶有 304 Not Modified 狀態(tài)行的響應報文绩衷，且該報文實體體為空蹦魔。
- 緩存器接收到初始服務器響應后，給瀏覽器發(fā)送相應對象A咳燕。
緩存機制優(yōu)點
- web緩存器可大大減少對客戶請求的響應時間勿决，特別是當客戶與初始服務器間的瓶頸帶寬遠低于客戶與web緩存器間的瓶頸帶寬時。
- 大大減少一個機構的接入鏈路到因特網的通信流量以降低費用
- 從整體上招盲，大大減小因特網上的Web流量低缩，實現(xiàn)有效的內容分發(fā)
內容分發(fā)網絡（Content Distribution Network,CDN）
基于緩存器技術，CDN公司在因特網上安裝許多地理上分散的緩存器曹货，使得大流量本地化咆繁。
有共享CDN(Akamai,Limelight)，專用CDN（谷歌顶籽，微軟）
