第二章 網路應用 3 Web應用 3.1 Web應用概述 Web與HTTP 問題： Web是由什麼構成？ 答：Web是由網頁構成，但只有網頁是不夠的，是所有的網頁之間互相連結，從而形成一個極其龐大的資訊網路和內容網路。 問題：網頁包含了多個物件，那物件又是什麼？ 物件如HTML檔案，JPEG圖片，視訊檔案，動態指令碼等。每個網頁會有一個基本的HTML檔案，有包含對其它物件引用的連結。

物件的定址： 網際網路上有眾多的網頁，因此我們需要對其進行定址。我們之前講過，網路程序間的通訊需要經過程序的定址，那現在需要對web進行定址。 Web物件通過URL（Uniform Resoure Locator）統一資源定位器 進行定址（RFC1738） URL有一個基本的格式：

最前面是一個基本的協議， 然後是主機（域名或IP）， 然後是埠號，最後是路徑。

例子： 協議省略了HTTP，省略時我們就預設省略了HTTP。someDept是一個具體的路徑，pic.gif是具體的檔名。URL使得Web所有的識別符號都有了一個唯一的名字。

HTTP協議概述： 全球資訊網應用遵循HTTP協議，叫做超文字傳輸協議（HyperText Transfer Protocol）. HTTP採用C/S架構。 客戶機為瀏覽器，作用是請求、接收、展示Web物件。 伺服器—Web Serve: 作用為響應客戶的請求，傳送物件給客戶。

最典型的WEB serve 軟體是Apache。 HTTP的兩個版本： 1.0 RFC 1945 1.1 RFC 2068

HTTP使用TCP傳輸服務

HTTP是一種無狀態的協議

問題：為什麼用無狀態？ 1、有狀態的協議更加複雜。 2、需要維護這個狀態，如果客戶機宕機了，那麼兩邊狀態就不一致了，那麼需要來解決這種不一致，代價比較高。

3.2 HTTP連線型別 我們已經知道，web所遵循的應用層協議是HTTP，我們也知道，HTTP依靠TCP建立連線。那麼，在對TCP的使用方法上，HTTP具有兩種連線方式。

HTTP兩種連線方式 非永續性連線和永續性連線 在非永續性連線中，我們建立一個TCP連線後最多允許傳輸一個物件。（HTTP1.0） 在永續性連線中，我們允許TCP傳輸多個物件，如HTTP1.1 二者之間有什麼不同？

非永續性連線的工作過程：

主機請求的是，www.someSchool.edu 主機上的someDepartment目錄下的home.index檔案 我們假設這個HTML檔案裡面包含了一個基本的文字，同時還包含了指向10個jpeg圖片的連結，那這10張圖片將在另外的10個檔案記憶體放。 圖中從上到下時間依次推進，左邊均為客戶機，右邊均為伺服器。 在非永續性連線中，HTTP把物件傳送完之後，就會關閉TCP連線，並且告知客戶機。 HTTP解析並顯示html檔案後，發下裡面居然有10個指向jepg物件 的超連結，但是此時TCP連線已經關閉，所以沒有辦法，客戶端將會重複1~5，直到把10張圖片全部顯示完。 類似的情況在日常生活中，比如網速比較慢，那麼網頁會先把文字顯示出來，後來才把一張張圖片顯示完全。這個就說明先收到網頁解析，然後再去請求物件。

問題：這個過程的時間有多長呢？ 響應時間分析與建模 我們定義RTT（Round Trip Time）為從客戶端傳送一個很小的資料包到伺服器並返回所經歷的時間。 那麼從瀏覽器開始（即把URL輸入進去開始）一直到最後你得到的檔案，響應時間究竟是多少？ 首先，客戶端發起、建立TCP連線，這個需要一個RTT； 然後會發送HTTP請求訊息到HTTP伺服器，然後伺服器形成響應訊息直到響應訊息的前幾個字到達，這又是一個RTT； 然後在陸陸續續，把響應訊息所包含的檔案或物件傳輸過來，因此最後的時間為響應訊息所含的檔案或物件所用的傳輸時間。 總時間： Total = 2RTT + 檔案傳送時間 圖示：（這個圖的要求必須會畫，這是在學習網路，分析網路時間的一種重要方法）

結論：一個TCP連線只用來獲取一個物件 響應時間 = 兩個RTT + 檔案傳輸時間

問題：非永續性連線存在什麼問題？ 答： 1 慢，每個物件都需要2個RTT以上的時間才能獲得，如上面的例子，我們獲取一個檔案加上10個圖片物件，我們至少需要22個RTT加上檔案傳輸的時間 2 作業系統建立每個TCP連線需要開銷資源（overhead）

問題：那麼瀏覽器怎麼做更好？ 答：如果接收到的網頁可以同時建立10個TCP連線，用並行的TCP連線以獲取網路資源。但是注意，TCP連線的資源是十分寶貴的，這個代價對伺服器將是十分巨大的。

因此，我們應該改成永續性連線。既然TCP連線的建立是需要代價的，那麼我們應該多利用利用。那麼應該怎麼操作？ 方法是網頁傳過來以後，想讓伺服器別急著關閉TCP，保持TCP連線的開啟，後續的HTTP訊息可以通過這個連線傳送。 這個細分的話有兩種型別，一個是無流水的永續性連線： 即客戶端只有收到前一個響應後才傳送新的請求，那這樣每個被引用的物件耗時為1個RTT。 仍然以上面的例子，第一個網頁的需要兩個RTT，後面的10個物件需要10個RTT，那麼總共需要12個RTT。 有沒有更好的方法？下面介紹帶有流水機制的永續性連線 帶有流水機制的永續性連線： 客戶端只要遇到一個引用物件就儘快傳送請求。那麼在這種情況下，收到所有的引用物件只需要耗時約1個RTT。 仍然以上面的例子，一個網頁為兩個RTT，然後裡面的十個連結只需要1個RTT，加起來大約3個RTT就可以了。

思考一下：計算機的所有協議、機制、演算法都是由程式來完成的，這個程式應該怎麼編寫？

3.3 HTTP訊息格式 HTTP協議一共有兩類訊息，分別是請求訊息和響應訊息。 請求訊息使用ASCII碼來寫的，如圖所示

這個請求訊息怎麼看呢？ 這個訊息分成這樣幾部分： 第一行是請求行（request line），第一個詞是請求的命令，GET是其中的一個，類似的還有POST、HEAD等。後面跟的是一個URL，最後面是HTTP的版本。 第2、3、4、5行為頭部行，這個是可擴充套件的。 Host行記錄了訪問地址為www.someschool.edu，你可能會問，TCP連線已經建立，為什麼還要宣告需要訪問的主機呢？ 這個問題是個好問題，這裡賣個關子，這個資訊是有用的，在後面講到快取和代理伺服器時，再來說明有什麼用處。 第三行：User-agent 這個代表瀏覽器，這個比如說是Firefox等，這個資訊如果告訴伺服器，伺服器可以根據瀏覽器型別傳送適合你的版本。 第四行：Connection：在這裡的close表示建立完這個連線你就可以關閉了。 第五行：fr表示法語，表示客戶機期望的語言。伺服器可能會準備多個版本，有中文的、英文的等，看你需要哪個版本就傳送哪個版本 下面有一個空行，表明訊息已經結束

HTTP請求訊息的通用格式：

Entity Body包含的有所攜帶的資料。

問題：請求訊息有必要攜帶資料嗎？ 答：有些網頁可能存在一些表格，這個時候是你往伺服器端傳送資料，那就可以放到這裡面了。 問題：瀏覽器怎麼向伺服器上傳資料？ 答：最基本的方法有兩種，一種為POST方法，一種為GET方法。 POST方法即上圖所示，把資料傳到Entity Body,伺服器會從Entity Body中提取資料。 另外一種，我們可以用URL方法，輸入資訊通過request行的URL欄位中上傳 如下圖所示：

那麼我們回顧一下方法的型別：

Head方法寫的是什麼意思？ 這裡告訴伺服器：請不要把請求物件放在響應訊息中，這樣，伺服器只返回前面頭部那些資訊，這個主要用來做測試。 HTTP1.1又增加了兩種方法， PUT方法，可以支援上傳檔案和儲存，delete可以刪除URL欄位所指定的檔案。

接下來來看響應訊息： 響應訊息仍然是通過ASCII碼來寫，所以可讀，如下圖所示

第一條為狀態行，在此處表示請求訊息已經OK 頭部行 Date：表示WEB伺服器生成響應訊息的時間，注意，隔一行後還有一個時間，下面的時間是什麼意思？ 下面的時間表示這個網頁的上次修改時間是1998年6月22日， Serve：用的軟體是Apache ，這個是最主流的Web伺服器軟體 接下來是內容長度文字型別，最下面是響應訊息的具體內容。 以上即表示HTTP響應訊息。 下面說一下響應行表示的資訊： 注意上面，200表示OK，常用的還有如下幾種

作業： 換一種方式體驗HTTP，如果我們想體驗一下HTTP的整個過程，我們可以使用telnet

到此為止，我們已經把web應用的基本內容介紹完畢，後面還有兩個擴充套件性的話題。

3.4 Web應用之Cookie技術 HTTP協議是一種無狀態的協議，伺服器不會記錄客戶機的歷史行為，那麼就會帶來一些問題。 問題：為什麼需要cookie？ HTTP協議是無狀態的，但是很多應用仍然需要伺服器掌握客戶端的狀態，如上網購物，那麼該如何實現？或者說如何實現購物車？比如說你瀏覽網頁買東西，逛了5個小時，放在購物車30件東西，但等你結賬時只剩下一件東西，這肯定是不行的，因此有些網路應用是需要有會話狀態的，那麼原有的HTTP協議就不夠用了，因此我們引入cookie，

Cookie技術是什麼？ （RFC6265） Cookie技術是某些網站為了辨別使用者身份，進行回話（session）跟蹤而儲存在使用者本地終端上的資料（通常經過加密）

Cookie是架設在HTTP上的一個元件， HTTP響應訊息中會增加一個cookie的頭部行，因此可以想象，HTTP的頭部行是可擴充套件的。 HTTP的請求訊息也會增加cookie的頭部行，客戶端上有一個cookie檔案，由瀏覽器管理，Web伺服器端有專門的後臺資料庫，那麼現在是否可以解決那個問題呢？ 下面看演示

假設有一個客戶要訪問亞馬遜，假設這個客戶沒有訪問過，我們可以看到，客戶端的cookie已經有一行了，ebay 8734 ， 首次訪問時，用的是常規的HTTP請求訊息，即不帶cookie的頭部行，當伺服器收到這個常規的請求訊息後，一看，咦，這個客戶此前並沒有訪問過亞馬遜，好，伺服器為客戶建立一個ID，ID號是1678，然後把ID號和客戶資訊（比如說是IP）放到資料庫裡面，然後在返回的響應訊息中做一點手腳，這個時候我們用響應訊息的頭部行，加一個set-cookie 1678，瀏覽器收到後，會在自己的cookie中增加一行 ，客戶機再訪問亞馬遜時，請求訊息的頭部行就增加了一行 ，然後伺服器再看見時，就知道是哪個使用者發的訊息，亞馬遜就會看看這個使用者看過啥，是否可以推薦點啥，然後就生成一些對該客戶的一些特定的動作，然後再發給使用者。你肯定有過類似的體驗，購物網站會給你推薦一些相似的東西。

問題：Cookie有什麼用？ 答： （1） Cookie可以用於身份認證，比如說登入輸入使用者名稱密碼後，瀏覽器提示：是不是要儲存你的使用者名稱密碼？這個用的就是cookie技術 （2） 購物車 （3） 推薦 （4） Web e-mail 問題：Cookie 有什麼問題？ 答：最大的問題是隱私問題，你在網路上的一舉一動都是被監測的。 因此很多廠商都在研究cookie的替代技術。

在本節，我們需要理解以下內容： 1 需要理解cookie的本身 2 體會有狀態和無狀態 3 體會HTTP原來的協議中如何擴充套件

思考：

3.5 Web快取/代理伺服器技術 問題：什麼是Web快取/代理伺服器技術？ 答：可以在訪問伺服器的前提下滿足客戶端的HTTP請求。

問題：為什麼要發明這一項技術？ 答：這是一項效能優化的技術，我們可以想到，任何網路應用既有功能性的一面又有效能性的一面，這個大家要注意區分清楚。

Web快取/代理伺服器技術有如下三點效能優化： 1 縮短客戶請求的響應時間 2 減少機構/組織的流量 3 在大範圍內實現有效的內容分發，也可以稱之為CDN，內容分發網路。

聽上去好像很美好，那麼是如何實現？ 首先，它是如下所示的結構，在客戶和伺服器之間，架設了一個代理伺服器，

使用者在訪問時，都會訪問這個代理伺服器，瀏覽器會向快取/代理伺服器傳送所有的HTTP請求，如果說客戶所請求的快取在快取伺服器有，快取會返回物件；如果沒有的話，快取伺服器向原始的伺服器傳送HTTP請求，從而獲取物件，然後返回給客戶端並儲存該物件。快取既充當客戶端，也充當伺服器，這個一般由ISP來架設。

看例子： Web快取示例（1）

我們看這樣一個場景，上圖是一個機構，內容是一個區域網，區域網的速率為10 Mbps，區域網接入到網際網路，速率為1.5Mbps， 假定：

效能分析：

解決方法1：掏錢，升級為10M頻寬接入網際網路，

網路效能分析：

問題：成本太高

方法2 web快取 我們在機構內部增加一個快取伺服器，接入網際網路的頻寬不做改動，則：

一般情況下，快取伺服器的命中率在0.2~0.7之間，這裡假定命中率為0.4 網路效能分析： 40%的請求立刻得到滿足 60%的請求通過原始伺服器滿足 接入網際網路的鏈路的利用率下降到60%，從而其延遲可以忽略不計，例如10微秒 總的平均延遲：網際網路上的延遲 + 訪問延遲 + 區域網延遲 = 0.62.01秒 + 0.4n微秒 < 1.4秒，響應時間居然比花錢升級頻寬效果還好。

計算機技術中廣泛適用快取，因此快取/代理伺服器技術是個普適的技術。 現在有個問題：我們說：客戶訪問，如果物件在代理伺服器上有，自然會返回給客戶，但現在，代理伺服器如何保證自己的快取就是遠端伺服器上的新版本？或者說快取伺服器的物件是否和遠端的一致，只有一致，提供的服務才是好的服務。 解決方法：HTTP有一個條件GET方法，我們之前提到過，HTTP請求有一個Last Modified，將其結合到一起，似乎就可以解決這個問題。 如下圖所示：

我們說條件性GET的基本思想是，如果快取是最新的版本，則不需要傳送請求物件。 那麼我們這樣解決，我們在HTTP請求訊息中宣告所持有版本的日期，即：

如果遠端伺服器版本的日期在這個日期之後，則需要將新版本傳送，如果版本日期一致，則遠端伺服器需要告訴我沒有改動。 因此在伺服器端： 如果快取的版本是最新的，則響應訊息不包含物件，返回 HTTP/1.0 304 Not Modified. 因此，客戶訪問快取時，快取有必要利用條件性GET的方法向伺服器傳送請求，當沒有發生改變時，它節省了頻寬，真正改變時，它使用了頻寬。

到此為止，我們把Web應用非常系統的講完了。 課後作業：