《計算機網絡自頂向下方法-第七版》第二章總結

2 Principle of Network Applications

2.2 The Web and HTTP

HTTP協議定義了Client和Server之間如何交換信息以及信息的格式。一個網頁由多個object構成，通常包含一個base HTML file，其中包含了其餘object的URL。URL由兩部分組成，存儲object的Server的Hostname + object的所在路徑。

HTTP底層依賴TCP協議，Client發起與Server的TCP鏈接，Client發送HTTP Request Message，接收HTTP Response Message，Server則相反。事實上HTTP是一個無狀態協議，Server並不會保存與其交互的Client的狀態，這可以簡化Server的設計，可是有時候對Client進行標記是必要的，能夠用Cookie解決該問題。

Client可能連續向Server發起一系列Request，若是爲每一個Request創建TCP鏈接，則稱爲Non-persistent Connection，這種方式的弊端爲：創建大量的HTTP鏈接會消耗大量的系統資源而且創建每一個TCP鏈接都須要額外的一個RTT，增長了延時。與之相反的是，默認的HTTP協議都會利用單一的TCP鏈接傳輸連續的Request，直到給定時間沒有接收到Request以後，Server會將TCP鏈接關閉。這種方式稱爲Persistent Connection。

 

HTTP Request Message以下所示：

GET /somedir/page.html HTTP/1.1　　// Request Line
Host: www.someschool.edu　　　　　　// Header Lines
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

　　

Request Message由Request line，Header lines以及Entity body組成，Header lines與Entity body之間存在一個空行。在如上所示的Header Lines中，Host字段並很少餘，由於它能夠被Client與Server中間的Web Cache所使用。而Connection字段，則是Client用於通知Server沒必要創建Persistent Connection。User-agent則標示了發送Request的瀏覽器類型，Server可能對於不一樣的瀏覽器發送同一個object的不一樣版本。

HTTP Response Message以下所示：

HTTP/1.1 200 OK　　　　// Response Line
Connection: close　　　// Header Line
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

　　

Response Message相似地由Response line，Header lines以及Entity body組成。Header lines中的Date字段代表Server構建以及發送Response的時間。Last-Modified字段則表示獲取的object上一次修改的時間，它能夠用於檢測緩存的對象是否須要更新。幾種經常使用的返回狀態以下：

200 OK：Request成功而且在Response中包含了所需的信息

301 Move Permanently：請求的object已經被永久轉移了，可是Response Header中的Location字段代表了object新的URL，Client能夠根據該URL再次發起請求

400 Bad Request：經常使用的錯誤碼，代表Server不理解請求的含義

505 HTTP Version Not Supported：Server並不支持請求中的HTTP版本

 

HTTP是無狀態服務，所以須要Cookie爲Server端對Client進行標記，獲取Cookie及使用的過程以下：

1）Client首次向一個Server發起HTTP Request，Server爲該Client建立一個惟一的ID，以該ID爲Key在後端數據庫創建表項，並在HTTP Response中包含一個額外的Header，例如："Set-cookie: 1678"

2）Client接受到HTTP Response，將其中的Cookie提出，把Set-cookie中的ID以及Server的Hostname，存儲到Cookie file中

3）當Client再次訪問該Server時，會首先查詢Cookie file，若存在相應的Cookie，則在Request Header中增長Cookie Header，例如："Cookie: 1678"

4）Server根據Request中的Cookie Header，能夠對該請求進行特定的操做

事實上，Cookie能夠在無狀態的HTTP協議之上建立一個User Session Layer。

 

Web Cache位於Client和Server之間，Client可通過配置以後，直接訪問Web Cache，若相應的object不存在，則由Web Cache從Server進行獲取並緩存。而Web Cache的優點主要包含兩點：1）Web Cache可極大地減小Client的訪問延時，特別是Client和Server間的網絡帶寬遠遠小於Client和Web Cache之間的網絡帶寬。2）Web Cache也能夠極大地減小整個互聯網的流量壓力，重複的請求能夠直接在接入網以前進行處理。而Web Cache的表明就是CDN，經過在邊緣架設一系列的CDN能夠將多數流量進行本地化，從而避免遠程訪問。

 

若是GET請求中包含了"If-Modified-Since:"這種Header，則稱該請求爲The Conditional GET。當Web Cache須要檢查某個object是否爲最新時，能夠對該object發起GET請求，幷包含"If-Modified-Since: TIME"這一Header，而TIME就是上文中在HTTP Response的"Last-Modified"這個Header的內容。若object自TIME以來未經修改，則HTTP Response返回的狀態碼爲"304 Not Modified"且不包含object，由於這是沒必要要的，徹底是浪費帶寬，並且對於大的object還會增長響應延時。

2.4 DNS-The Internet's Directory Service

Internet中的一臺主機既能夠用Hostname表示，也能夠用IP表示，Hostname由人類使用，可是因爲其長度不定，所以其難以被路由器處理，並且其中包含的定位信息不多，例如，只能從後綴.cn表示主機在中國。相反，IP易於被路由器處理而且是一個層級結構，從左到右能逐漸對主機進行更精準的定位。

Domain Name System（DNS）就是Internet中用於提供Hostname和IP轉換服務的系統。DNS本質上由兩部分組成：1）一個由層級DNS Server構成的分佈式數據庫，2）一個運行主機對該分佈式數據庫進行查詢的應用層協議，該協議基於UDP實現，通常綁定53號端口，一般被HTTP等其他應用層協議調用。

DNS除了提供Hostname到IP的轉換服務之外，還能提供如下服務：

1) Host aliasing：一般一個主機包含多個Hostname，其中一個爲Canonical Hostname，所以DNS還提供根據一個Alias Name查詢Canonical Hostname以及IP地址的服務

2) Mail Server Aliasing：DNS能夠被Mail Application調用獲取相應的Canonical Hostname。事實上，DNS中的MX Record容許一個公司的Mail Server和Web Server有着一樣的（Aliased）Hostname。好比，一個公司的Web Server和Mail Server均可覺得enterprise.com

3) Load Distribution：一個Hostname每每能夠和多個IP地址相對應，對於這樣的Hostname，DNS Reply會將全部的IP地址返回，用戶一般會選擇其中第一個IP地址進行訪問，所以爲了可以在多個IP地址間進行負載均衡，DNS Reply會對這些IP地址的排列順序進行輪轉，保證每一個IP都能等機率地被訪問。

DNS系統由大量分佈在全球的DNS Server構成，且能夠將這些Server分紅Root DNS Server，Top-Level-Domain（TLD）Server和Authoritative DNS Server三類並依次從上到下造成一個層級結構：

Root DNS Server：全球的Root Name Server由13個組織控制，它用於提供相應的TLD Server的IP地址

TLD Server：包含com，org，edu等頂級域名，它用於提供相應的Authoritative DNS Server的地址

Authoritative DNS Server：若是一個組織有主機提供對外服務，則它須要提供本身的Authoritative DNS Server，用於轉換該組織本身的Hostname和IP地址。

Local DNS Server：該類型的Server準確地說並不在上述層級體系中，它通常在主機連入的時候由Residential ISP提供，它能夠做爲Proxy，用於接收相鄰主機的DNS請求，再由它來訪問上述層級體系，獲取目標IP地址。關於Local DNS Server的做用，一方面它能夠對DNS Reply進行緩存，從而提升訪問速度，另外由於它是固定的，所以可以選擇對最近的Root DNS Server，TLD Server以及Authoritative DNS Server進行訪問，減少延遲。

DNS Records and Messages

全球的DNS Server組成了一個分佈式數據庫，其中存儲的條目稱爲Resource Records（RR），每個DNS Reply能夠包含一個或多個Resource Records。一個RR由（Name，Value，Type，TTL）四部分組成而且分爲如下四種類型：

1）Type = A：提供標準的Hostname到IP的映射，其中Name爲Hostname，Value爲IP

2）Type = NS：根據Hostname查詢相應的Authoritative DNS Server，例如（foo.com，dns.foo.com，NS），這種類型的RR通常還須要跟一個A類型的RR，用於描述dns.foo.com和它的IP之間的映射

3）Type = CNAME：提供Alias Hostname和Canonical Hostname之間的映射

4）Type = MX：提供Alias Hostname到Mail Server的Canonical Hostname之間的映射，若是要獲取Web Server的Canonical Hostname則獲取CNAME類型的RR，對於Mail Server則獲取MX類型的RR

通常來講DNS協議只包含Query和Reply兩種類型的Message，且兩種類型報文的格式相同。報文主要可分爲12字節的Header和一系列的RR組成。Header包含了ID，一系列的Flag以及Questions，Answer RRs，Authority RRs以及Additional RRs的數量。Questions包含查詢的Name以及Type，Answer RRs返回相應的RR，Authority RRs返回Authority Server的Records，最後的Additional RRs用於，對於一個MX類型的Query，會返回Mail Server的Canonical Hostname而且會在Additional中包含Canonical Hostname到IP的A型RR。

DNS Security

對於DNS Server的DDos攻擊，因爲緩存的存在，Root DNS Server其實不多被直接訪問，攻擊TLD DNS Server是更有效的方式。對於DNS Poisoning Attach，攻擊者能夠發送給DNS Server錯誤的Reply，誘使其對它進行緩存，從而讓用戶訪問攻擊者指定的網站。不過上述攻擊形成的影響都頗有限，DNS已經被證實是一個魯棒性很是強的系統。

關於如何在DNS中註冊新域名以及對其進行訪問的例子：

1）例如一個初創公司決定其域名爲abc.com，首先須要向Registrar註冊域名，保證其惟一性，同時須要提供對應的Authoritative DNS Server的Name和IP地址，例如，dns.abc.com，212.2.212.1，Registrar會向TLD Server中插入兩條Resource Record，以下：

（abc.com，dns.abc.com，NS），（dns.abc.com，212.2.212.1，A）

同時須要確保：Web Server www.abc.com的A類資源和Mail Server mail.abc.com的MX類資源已經寫入Authoritative DNS Server中

2）例如Alice須要對www.abc.com進行訪問，首先將DNS請求發送到Local DNS Server，Local Server訪問Root DNS Server獲取com的TLD Server的IP地址（如有緩存，則可跳過此步驟），再對com TLD Server進行訪問並獲取在步驟1中插入的兩條Resource Record，而後訪問dns.abc.com獲取www.abc.com的類型A資源，最後Local DNS Server將結果返回Alice。

2.5 Peer-to-Peer File Distribution

對於Client-Server架構老是須要Server始終運行，可是P2P架構對於Server始終運行的要求能降到最低。下面以文件分發做爲例子，對Client-Server架構以及P2P架構的擴展性進行對比：

設須要分發的文件的大小爲F，Server的上傳速度爲Us，共有N個peers，第i個peer的上傳速度爲Ui，下載速度爲Di。

所以對於Client-Server模式，最小的分發時間Tcs的下界爲max{NF/Us, F/Dmin}，Dmin表示Peer中最小的下載速度，能夠證實若是Server能對分發的流量進行合理的調度，這一下界是可以達到的。對於擴展性，可見隨着N的增大，Tcs也將線性增加

對於P2P模式，其分發時間的估算是很是複雜的，這取決於Peer之間如何對已有的部分文件進行分發，可是咱們仍然能對其分發時間的下界Tp2p進行估算，獲得的結果爲max{F/Us, F/Dmin, NF/(Us + 對Ui求和)}。若是Peer在收到一個bit以後能立刻對其進行分發，則能夠找到一種分發方式達到這一下界。不過事實上，文件都是按照塊而非bit進行分發的。但這一結果也能對分發時間進行很好的近似。假設Ui都相等爲U，則理想狀況下，無論N多大，P2P模式下的分發時間不會超過F/U。顯然，P2P模式具備很是好的自擴展性。

BitTorrent

全部加入文件分發的Peer構成一個Torrent，文件通常被切分爲大小爲256KB的塊在Peer間分發。

在Torrent中有一個特殊的節點稱爲Tracker，它記錄了Torrent中全部Peer的信息。例如，當Alice想要加入Torrent進行文件下載時，她首先須要在Tracker中進行註冊並階段性地向Tracker發送心跳。Tracker會將Torrent中一部分Peer的信息發送給Alice，Alice將與這些Peer創建鏈接，固然以後可能也會有Peer主動與Alice創建鏈接。在每一個時刻，每一個Peer都會有待傳輸的文件的一個子集且各個Peer間的子集並不相同。所以Alice會階段性地向與其相連的Peer發送請求，獲取它們已有數據塊的列表，再與本身已有的數據塊列表進行匹配，發送請求獲取本身尚未的數據塊。

在與Peer互相傳輸數據塊時，Alice須要考慮以下兩個問題：

1）對於本身尚未的數據塊，應該優先請求哪些數據塊？

2）對於向本身發出請求的Peer，應該向它們中的哪些發送數據塊？

對於上述兩個問題的解決方案以下：

1）Rarest First：即優先獲取在Alice以及與其相連Peer的數據塊List中副本數最少的數據塊，從而增長這些數據塊的分發，確保數據塊副本數量的均衡

2）對於如何應答Peer的請求，Alice每隔十秒會對各個鏈接的Peer傳輸數據給她的速率進行計算並選取其中的前四名，知足它們的請求。同時，每隔30秒，Alice會隨機選擇一個Peer進行應答，這就給了新加入的Peer進行傳輸的機會。上述機制的實現，保證了整個系統的正常運行，不然每一個Peer都會成爲只下載而不上傳的Freerider。

P2P架構的另外一種應用是Distributed Hash Table（DHT），DHT事實上就是一個簡單的數據庫，其中的條目被分佈式地記載在P2P系統的Peer中。

2.6 Video Streaming and Content Distribution Networks

Video一個很是重要的特性是它能夠壓縮，現有的壓縮算法可以將Video壓縮到任意的Bit Rate，顯然Bit Rate越大，壓縮的程度越小，用戶體驗也就越好。對於Video Streaming這一場景下，最重要的性能指標是端到端的吞吐量。所以，對於同一Video能夠根據壓縮程度的不一樣製做多個版本，根據用戶的帶寬傳輸相應的版本。

Dynamic Adaptive Streaming over HTTP（DASH），Client會動態地獲取一系列的塊，計算下載速率，並根據算法選擇下一次下載的塊的數目。DASH容許Client在一次會話過程當中，根據帶寬的不一樣在各個Video Version之間進行切換。每一個版本的Video都存儲在HTTP Server中，用不一樣的URL表示。Client最開始須要從Server中獲取一個Manifest，其中包含各個版本的URL以及下載它們所需的Bit Rate。

Content Distribution Networks

若是將全部的Video存儲在單個數據中心中併爲全部Client提供Streaming Video服務則會存在如下三個問題：

1） 數據中心距離Client太遠，所以二者之間的交互可能會跨越多個ISP，不一樣的ISP甚至可能在不一樣的大洲，若是中間某條鏈路的吞吐量過小，則會對總體形成巨大的延遲

2）對於流行的Video，它可能會播放不少次，所以對於同一鏈路，會對該Video進行屢次重複的傳輸，這不只是對Internet總體帶寬的浪費，Video Company也須要爲這些重複的流量付費

3）單點故障

Content Distribution Networks（CDN）經過將服務器分佈到不一樣的地理位置並將用戶的請求轉發到可以提供最佳體驗的CDN Location用以解決上述問題。

CDN一般有以下兩種部分方式：

1）Enter Deep：將服務器部署在儘可能多的Access ISP，經過減小用戶和服務器之間的距離下降延遲。但同時因爲如此普遍的部署，對於如此大量分散的服務器的維護將變得很是困難

2）將大規模的服務器部署在Internet Exchange Points（IXP），從而下降維護成本，但伴隨着更高的延遲和更低的吞吐量

事實上CDN不會將全部的Video預先複製到全部的Cluster中，而是會採用一種簡單拉取的策略：若是Client向一個Cluster拉取一個Video，若該Video不存在，則Cluster會一邊從Central Repository或者其餘Cluster拉取Video緩存到本地，一邊向Client發送數據流。

那麼如何將用戶的請求截取並轉發至CDN Server？例如要觀看www.abc.com的Video，則Local DNS Server會向abc Authoritative DNS Server發送DNS請求，可是abc Authoritative DNS Server並不會直接返回IP，而是會返回例如King CDN的Authoritative DNS Server，以後Local DNS Server再向King CDN的Authoritative發起DNS請求，獲取DNS Server的IP，從而實現請求的轉發。

Cluster Selection Strategies

如何爲某個Client選擇CDN中最優的Cluster是整個CDN體系中最爲核心的問題，已知CDN可以獲知Local DNS Server的IP地址，所以有以下幾種策略：

1）在大多數狀況下，選擇地理上距離Local DNS Server最近的Cluster便可，可是對於某些狀況下，地理距離上的最近並不表明網絡距離上的最近，並且有的Client可能會使用遠程的Local DNS Server，另外這種相對固定的策略並無考慮到網絡的延遲和帶寬會隨着時間的推移而發生變化。

2）另外一種方法是CDN會讓它全部的Cluster按期地給全世界的Local DNS Server發送心跳，從而對二者之間的延遲進行實時地測量，從而動態地對Client和CDN Cluster進行匹配，但這種方法的問題是，並非全部Local DNS Server都會對Cluster的心跳做出迴應。