計算機網絡讀書筆記(二)

一.應用層

1.1 應用層協定原理

在Web應用程式中，有兩個互相通信的不同的程式：一個是運作在使用者主機上的浏覽器程式；另一個是運作在Web伺服器主機上的Web伺服器程式。這裡采用的是C/S體系結構，即服務端的伺服器一直運作，有固定的IP位址和端口号，擴充性差；用戶端則主動與伺服器通信，與網際網路有間歇性的連接配接，可能有間歇性的連接配接，可能是動态的IP位址。另一個例子是P2P檔案共享系統，在參與檔案共享的社群中的每台主機中都有一個程式。在對等體(P2P)體系結構下，幾乎沒有一直運作的伺服器，任意端系統之間可以通信，每一個結點即是用戶端又是伺服器并且可以改變IP位址。

1.1.1 網絡應用程式體系結構

應用程式的體系結構不同于網絡的體系結構。從應用程式研發者的角度來看，網絡體系結構是固定的，并為應用程式提供特定的服務集合；應用程式體系結構由應用程式研發者設計，規定了如何在端系統上組織該應用程式。有兩種主流體系結構：客戶-伺服器體系結構或對等(P2P)體系結構。

1. 客戶伺服器體系結構：

   在客戶-伺服器體系結構中，有一個總是打開的主機稱為伺服器，它服務于來自許多其他稱為客戶的主機的請求，該伺服器擁有固定的、周知的位址，該位址稱為IP位址。并且在客戶-伺服器體系結構中，常常會出現一台單獨的伺服器主機跟不上它所有客戶請求的情況，為此，配置大量主機的資料中心常被用于建立強大的虛拟伺服器。

2. 對等(P2P)體系結構：

   對資料中心的專用伺服器有最小的依賴，應用程式在間斷連接配接的主機對之間使用直接通信，這些主機對被稱為對等方，P2P還有一個特性是它們的自擴充性，比如在檔案共享應用中，對等方可能通過向檔案的原始擁有者送出請求而産生工作量，但是對等方也有可能通過為其他對等方傳送檔案而為原始擁有者分擔壓力；P2P體系結構也是成本有效的，因為他通常不需要龐大的伺服器基礎設施和服務帶寬。

1.1.2 程序通信

用作業系統的術語來說，進行通信的實際上是程序而不是程式，一個程序可以被認定是運作在端系統中的一個程式。在兩個不同端系統上的程序，通過跨越計算機網絡交換封包而互相通信。發送程序生成并向網絡中發送封包；接收程序接收這些封包并可能通過回送封包進行相應。

1. 客戶和伺服器程序

   對每對通信程序，我們常常将這兩個程序之一辨別為客戶，而另一個程序辨別為伺服器，對于Web而言，浏覽器是一個客戶程序，Web伺服器是一個伺服器程序；對于P2P檔案共享的某些應用中，一個程序既能是用戶端也能使伺服器。是以從程序所扮演的角色來區分是客戶程序還是伺服器程序不夠精确，是以我們從發起通信的順序來定義它們：在給定的一對進城之間，首先發起通信的程序被标記為客戶程序，在會話開始時等待聯系的程序被稱為伺服器程序。

2. 程序與計算機網絡之間的接口

   程序通過一個稱為套接字的軟體接口向網絡發送封包和從網絡接收封包；套接字是同一台主機内應用層與傳輸層之間的接口。由于該套接字是建立網絡應用程式的可程式設計接口，是以套接字也成為應用程式和網絡之間的應用程式程式設計接口。一旦應用程式的開發者選擇了一個傳輸層協定，則應用程式就建立在由該協定提供的運輸層服務之上。

3. 程序尋址

   在一台主機上運作的程序為了向在另一台主機上運作的程序發送分組，接收程序需要有一個位址。為了辨別該接收程序，需要定義兩種資訊：主機的位址和在目的主機中指定接收程序的辨別符。在網際網路中主機由其IP位址辨別。除了知道封包發送目的地的主機位址外，發送程序還必須指定運作在接收主機上的接收程序(接收套接字)，目的地端口号就是用于這個目的。

1.1.3 可供應用程式使用的傳輸服務

我們大緻能夠從四個方面對應用程式服務要求進行分類：可靠資料傳輸、吞吐量、定時和安全性。

1.可靠資料傳輸

通過做一些工作以確定由應用程式的一端發送的資料正确、完全的傳遞給該應用程式的另一端。如果一個協定提供了這樣的確定資料傳遞服務，就認為提供了可靠資料傳輸。運輸層協定能夠潛在地向應用程式提供的一個重要服務是程序到程序的可靠資料傳輸。當一個傳輸協定提供這種服務時，發送程序隻要将其資料傳遞進套接字，就可以完全相信該資料能無差錯地到達接收程序。

當傳輸層不提供可靠資料傳輸時，由發送程序發送的某些資料可能到達不了接收程序，這類可以被适用于多媒體應用。

2.吞吐量

在一條網絡路徑上的兩個程序之間的通信會話中，可用吞吐量就是指能夠向接收程序傳遞比特的速率。因為會有其他會話共享該網絡的路徑的帶寬，并且因為這些會話的到來和離開，可用吞吐量将發生變化；這就導緻另一種自然的服務，即運輸層協定能夠提供确切的可用吞吐量。使用這種服務時，應用程式就能以明确的速度接收資料，并且運輸層應當保證可用吞吐量必須總是至少為該速度；

對吞吐量有明确要求的應用程式被稱為帶寬敏感的應用。許多多媒體應用是帶寬敏感的（盡管某些多媒體應用程式可能采用自适應編碼技術對數字視訊和音頻以與目前可用帶寬相比對的速度加解碼。），比如網際網路電話。而彈性應用則對吞吐量沒有嚴格的要求。這類應用包括：電子郵件、檔案傳輸以及web傳送等。值得注意的是，吞吐量當然是越多越好了。

3.定時

定時和吞吐量都是關于速度的。一個提供定時服務的例子是：發送方注入套接字中的每個比特到達接收方的套接字不遲于100ms。也就是說，定時是對資料從發送到到達所需時間的要求，而吞吐量是對資料傳遞速度的要求。打個比方，吞吐量是指一個小時内經過某個收費站的汽車數目，而定時則是第一輛車從出發到進入收費站的時間。有些應用為了服務的有效性而對資料到達時間有嚴格的要求，常見的應用有：網際網路電話、多方線上遊戲等；

4.安全性

運輸層可以提供一些安全服務，以防止傳輸的資料以某種方式在這兩個程序之間被察覺到。這些安全服務包括：資料的加解密、資料的完整性和端點鑒别等

1.1.4 網際網路提供的運輸服務

網際網路為應用程式提供兩個運輸層協定，即UDP和TCP。

1.TCP服務

TCP服務模型包括面向連接配接服務和可靠資料傳輸服務。

面向連接配接的服務：在應用層資料封包開始流動之前，TCP讓客戶和伺服器互相交換運輸層控制資訊。這個所謂的握手過程提醒客戶和伺服器，讓他們為大量分組的到來做好準備。在握手階段後，一個TCP連接配接就在兩個程序的套接字之間建立了。這條連接配接是全雙工的。

可靠資料傳送服務：通信程序能夠依靠TCP，無差錯，按适當順序傳遞所有發送的資料。當應用程式的一端将位元組流傳進套接字時，它能夠依靠TCP将相同的位元組流傳遞給接收方的套接字，而沒有位元組的丢失和備援。

TCP協定還具有擁塞控制機制，它能夠為網際網路帶來整體好處。

2.UDP服務

UDP是一種不提供不必要服務的輕量級運輸協定，它提供最小的服務。UDP是無連接配接的，是以在兩個程序通信前沒有握手過程。UDP協定提供一種不可靠資料傳送服務，也就是不保證完整送達，也不保證順序正确。UDP沒有擁塞控制機制。

3.網際網路運輸協定所不提供的服務

從可靠資料傳輸、吞吐量、定時、安全性等四個角度來看運輸層提供的服務，我們發現，運輸層無法對吞吐量和定時做出保證。但是，今天的網際網路能夠為時間敏感的應用提供滿意的服務，盡管它并不提供任何定時或者帶寬保證；

1.1.5 應用層協定

應用層協定定義了運作在不同端系統上的應用程式程序如何互相傳遞封包，這些應用層協定定義了：

1. 交換的封包類型，例如請求封包和相應封包
2. 各種封包類型的文法，如封包中的各個字段及這些字段是如何描述的
3. 字段的語義：即這些字段中的資訊的含義
4. 确定一個程序何時以及如何發送封包，對封包進行相應的規則。

1.2 Web和HTTP

1.2.1 HTTP概況

Web的應用層協定是超文本傳輸協定，HTTP由兩個程式實作：一個用戶端程式和一個伺服器程式。客戶程式和伺服器程式運作在不同的端系統中，通過交換HTTP封包進行會話。

Web網頁是由對象組成的。一個對象隻是一個檔案，他們可以通過URL位址尋址。多數Web頁面含有一個HTML基本檔案以及幾個引用對象。HTTP定義了Web客戶向Web伺服器請求Web頁面的方式以及伺服器向客戶傳送Web頁面的方式。當使用者請求一個Web頁面時，浏覽器向伺服器發出對該頁面中所包含對象的HTTP請求封包，伺服器接收到請求并用包含這些對象的HTTP相應封包進行相應。

HTTP使用TCP作為它的支撐運輸協定。HTTP客戶首先發起一個與伺服器的TCP連接配接。一旦連接配接建立，該浏覽器和伺服器程序就可以通過套接字接口通路TCP。客戶向它的套接字接口發送HTTP請求封包并從它的套接字接口接收HTTP響應封包，伺服器類似的。一旦客戶向它的套接字接口發送一個請求封包，該封包就脫離了客戶控制并進入TCP的控制。

注意到伺服器向客戶發送被請求的檔案，而不存儲任何關于該客戶的狀态資訊。若一個特定的客戶短時間内兩次請求同一個對象，伺服器會重新發送對象。也就是說，HTTP是不儲存關于客戶的任何資訊的，是一個無狀态協定。

1.2.2 非持續連接配接和持續連接配接

在許多的網際網路應用程式中，客戶和伺服器在一個相當長的時間範圍内通信。當客戶-伺服器的互動是經TCP進行的，應用程式的研制者就需要做決定，即每個請求/響應對是經過一個單獨的TCP連接配接發送，還是所有的請求及其響應經相同的TCP連接配接發送。采用前一種方法，該應用程式被稱為非持續連接配接，采用後一種方法，該應用程式被稱為持續連結。HTTP預設使用持續連結，但是也可以配置成非持續連接配接。

1. 采用非持續連接配接的HTTP

   使用非持續連接配接時，每個TCP連接配接在伺服器發送一個對象後就會關閉，也就是每個TCP隻傳送一個請求封包和響應封包；

   為了描述持續連接配接和非持續連接配接的特點，我們引入RTT(Round-Trip Time)。RTT指的是，一個短分組從用戶端到伺服器，然後再傳回用戶端所用的時間。RTT包括分組的傳播時延、排隊時延、處理時延（因為是短分組，是以其傳輸時延可不計）；因為用戶端和伺服器建立TCP連接配接的時候，會通過一個三次握手的過程來交換傳輸控制資訊。三次握手的前兩次占用了一個RTT，客戶結合第三次握手通信會通過該連接配接發送一個HTTP請求封包，一旦該分組到達伺服器，伺服器便開始使用TCP傳輸HTML對象。是以，粗略地說，響應時間是兩個RTT加上傳輸HTML的時間（不是傳播）

2. 采用持續連接配接的HTTP

   非持續連接配接必須為每個請求建立一個TCP連接配接，而每個TCP連接配接将占用系統資源，包括緩沖區和變量等，這樣伺服器的負擔就很重了。第二，一個對象将通過兩個RTT的時延才能傳遞。

   如果使用持續連接配接，那麼伺服器在發送響應封包後将保持該TCP打開，後續用戶端可以使用該連接配接來向伺服器送出請求。不但一個完整的頁面可以通過同一個連接配接傳送，同一台伺服器上的多個頁面也可以通過同一個連接配接發送。這就提高了效率；

一般來說，如果一條連接配接在一定的時間間隔後沒被使用的話，就會被關閉。HTTP預設使用的是帶流水線的持續連接配接。

在連接配接建立後，傳輸資料分為兩種，分别是流水線式和非流水線式。非流水線式就是每次發送一個請求，等待得到所需要的資料後在發出下一個請求，而流水線式則直接将所有請求以此發出，不需要等待資料接收後再發出。

1.2.3 HTTP封包格式

1.HTTP請求封包

一個請求封包能夠具有最少一行的内容，HTTP請求封包的第一行叫做請求行，其後繼行叫做首部行。請求行有3個字段：請求方法、URL字段和HTTP版本字段，方法字段可以取不同的值，包括GET、POST、HEAD、PUT、DELETE.絕大部分的HTTP請求封包使用GET方法。當浏覽器請求一個對象時，使用GET方法，在URL字段帶有的請求對象的辨別。

首部行包含是否在發送完響應封包後關閉TCP連接配接的Connection（也就是持續性以及非持續的控制）；請求的主機位址（該頭部資訊被Web高速緩存所要求）；浏覽器版本；可接受的語言等頭部資訊；

在首部行之後一個空行，之後便是請求的“實體體”(包含了所請求的對象本身)。該實體體可以在POST方法裡傳遞Form表單内容或者傳遞其它一些二進制流資料等。值得注意的是，表單也不一定必須使用POST方法。如果使用get,實體體為空，會顯示在url中。

Head類似于get方法，将會用一個http封包進行響應，但是不傳回請求對象，經常用作調試跟蹤。put方法允許使用者上傳對象到指定的Web伺服器上指定的路徑。Delete方法允許使用者或應用程式删除Web伺服器上的對象。

2.HTTP響應封包

響應封包總體上也分三個部分，第一部分是狀态行，包含HTTP版本、狀态以及狀态資訊等内容；第二部分是首部行，包含發送日期、伺服器類型、上一次修改請求資源的時間、内容的類型等内容。第三部分是實體體。實體體包含請求對象本身。

這裡的Date是從檔案系統中檢索到該對象，插入到響應封包，并發送該響應封包的時間。

常見狀态碼

200：請求成功 處理方式：獲得響應的内容，進行處理

301：請求到的資源都會配置設定一個永久的URL，這樣就可以在将來通過該URL來通路此資源 處理方式：重定向到配置設定的URL

400：非法請求 處理方式：丢棄

404：沒有找到 處理方式：丢棄

505：伺服器不支援請求封包使用的http版本。

1.2.4 使用者與伺服器的互動：cookie

HTTP伺服器是無狀态的，這簡化了設計。然而一個Web站點通常希望能夠識别使用者，可能是因為伺服器希望限制使用者的通路，或者是因為它希望把内容與使用者身份聯系起來，為此HTTP使用了cookie。

cookie有四個元件：

1. 在HTTP響應封包中的一個cookie首部行；
2. 在HTTP請求封包中的一個cookie首部行；
3. 在使用者端系統中保留有一個cookie檔案，并由使用者的浏覽器進行管理；
4. 為于Web站點的一個後端資料庫

也就是說，作為伺服器端，需要做的就是當第一次收到一個HTTP請求的時候，會在後端資料庫中建立一個唯一識别碼，并以此建立索引，然後将該索引放入到HTTP響應封包中傳回響應封包，使用者浏覽器就會将該cookie以及伺服器主機名存放在特定的cookie檔案中。當使用者之後持續通路的時候，每次請求一個Web頁面，浏覽器就會查詢該特定的cookie檔案并且抽取它對這個網站的識别碼，并放到HTTP請求封包中包括識别碼的cookie首部行中。這樣子，伺服器就能根據cookie來知道使用者的活動。

1.2.5 Web緩存

Web緩存器也叫做代理伺服器，他是能夠代表初始Web伺服器來滿足HTTP請求的網絡實體。Web緩存器有自己的磁盤存儲空間，并在存儲空間中儲存最近請求過的對象的副本。可以通過配置使用者的浏覽器，使得使用者的所有HTTP請求首先指向Web緩存器。

這樣的話，當代理伺服器收到一個HTTP請求後，它将檢查本地是否緩存過該對象，假如在緩存中存在對象并且沒有過期，那麼緩存直接傳回；如果不在緩存中的的話，緩存伺服器将根據請求封包裡的Host首部行以及請求行裡的URL字段請求原始伺服器，然後再将對象傳回至用戶端。是以，Web緩存器即是伺服器又是客戶，當他接收浏覽器的請求并發回響應時，他是一個伺服器，當他向初始伺服器送出請求并接收響應時，他是一個客戶。

通常，代理伺服器與用戶端的通信速度要快于初始伺服器與用戶端的連接配接速度；Web代理伺服器可以大起大減少對客戶請求的響應時間；而且，緩存器能從整體上大大降低網際網路上的web流量，進而有助于提高所有應用程式的性能；

1.2.6 條件GET方法

高速緩存能減少使用者感受到的響應時間，但是存放在緩存伺服器中的對象副本可能是陳舊的，也就是說儲存在伺服器中的對象自該副本緩存在客戶上以後可能被修改了。是以HTTP協定采用一種機制允許緩存器證識它的對象是最新的。這種機制就是條件GET方法。如果請求封包使用GET方法并且請求封包包含一個‘If-Modified-Since’首部行，那麼這個HTTP請求封包就是一個條件GET請求封包。

使用者在首次向Web伺服器請求某一個對象的時候，緩存器會儲存下該對象的内容以及最後修改日期，當有使用者再次通路相同的對象時，該對象仍然在這個緩存器時，他就會向Web伺服器發送一個條件GET執行最新檢查以此來确認是否在Web伺服器上對象發生改變，如果發生改變就将回複一個響應封包，并且在響應封包的資料段包含所請求的對象，如果沒有改變的話，則在狀态行中回複304 Not Modified，它告訴緩存器可以使用該對象。

1.3 網際網路中的電子郵件

電子郵件是一種異步通信媒介，即當人們友善時就可以收發郵件，不與他人的計劃進行協調。與普通郵件相比，電子郵件更為快速并且易于分發，而且價格便宜。電子郵件系統有三個主要部分構成：使用者代理、郵件伺服器和簡單郵件傳輸協定(SMTP)。

郵件伺服器形成了電子郵件體系結構的核心。每個接收方在其中的某個郵件伺服器上有一個郵件。一個典型的郵件發送過程是：從發送方的使用者代理開始，傳輸到發送發的郵件伺服器，再傳輸到接收方的郵件伺服器，然後在這裡被分發到接收方的郵箱中，當接收方使用者要在他的郵箱中讀取該封包時，他的郵件伺服器需要進行驗證。

SMTP是網際網路電子郵件中主要的應用層協定，它使用TCP可靠資料傳輸服務，從發送方的郵件伺服器向接收方的郵件伺服器發送郵件。SMTP分為兩部分：運作在發送發郵件伺服器的用戶端和運作在接收方郵件伺服器的服務端。每台郵件伺服器即運作SMTP的用戶端也運作SMTP的服務端。當一個郵件伺服器向其他郵件伺服器發送郵件時，他就就是用戶端，反之則是伺服器。

1.3.1 SMTP

SMTP的基本步驟如下所示：

1. 發送方調用其郵件代理程式并提供接收方的郵件位址撰寫封包，然後訓示使用者代理發送該封包
2. 發送方的使用者代理把封包發給它的郵件伺服器，在那裡該封包被放在封包隊列中。
3. 運作在發送方的郵件伺服器上的SMTP用戶端發現了封包隊列中的這個封包，它就建立一個到運作在接收方的郵件伺服器上的SMTP伺服器的TCP連接配接。
4. 在經過一些初始SMTP握手後，SMTP客戶通過該TCP連接配接發送發送方的封包。
5. 在接收方的郵件伺服器上，SMTP的服務端接受該封包。接收方的郵件伺服器然後将該封包放入接收方的郵箱。
6. 接收方驗證後調用使用者代理閱讀該封包。

由上可知，SMTP一般不使用中間郵件伺服器發送郵件，即使這兩個郵件伺服器為于地球的兩端也是這樣的，也就是郵件不會在中間某個郵件伺服器保留；在SMTP握手階段，SMTP用戶端将介紹發送方和接收方的郵箱位址；一旦介紹完畢後，SMTP用戶端将開始發送封包。

1.3.2 與HTTP的對比

兩個協定都是從一台主機向另一台主機傳送檔案：HTTP從Web伺服器向Web使用者傳送檔案；SMTP從一個郵件伺服器向另一個郵件伺服器傳送檔案。當進行檔案傳送時，持續的HTTP和SMTP都使用持續連接配接，但是也有一些重要的差別：

1. HTTP主要是一個拉協定，即在友善的時候，某些人在Web伺服器上裝載資訊，使用者使用HTTP從該伺服器拉取這些資訊；SMTP基本上是一個推協定，即發送郵件伺服器把檔案推向接收郵件伺服器。
2. SMTP要求每個封包采用7比特ASCII碼格式，如果封包包含了非7比特ASCII字元或二進制資料，則該封包必須按照7比他ASCII碼進行編碼。HTTP資料則不受這種限制。
3. HTTP将不同的對象(例如包含文本以及圖形的對象)封裝到自己的HTTP響應封包中，而SMTP則把所有封包對象放在一個封包中。

1.3.3 郵件封包格式

當一個人給另一個發送電子郵件時，一個包含環境資訊的首部位于封包體前面，這些環境資訊包括在一系列首部行中，由RFC 5322定義。首部行和該封包的題用空行進行分隔。RFC 5322定義了郵件首部行和它們的語義解釋的精确格式。每個首部必須含有一個From；首部行和一個To；首部行；一個首部也許包含一個subject；首部行以及其他可選的首部行。

1.3.4 郵件通路協定

SMTP是郵件伺服器之間發送郵件封包的協定，并不是使用者通過代理和郵件伺服器之間通信的協定；使用者代理使用郵件通路協定來從郵件伺服器上擷取郵件資訊；目前常用的郵件通路協定有POP3（Post Office Protocol-Version 3）、網際網路郵件通路協定（IMAP，Internet Mail Access protocol）和HTTP。

1.3.4.1.POP3

POP3是一種極為簡單的郵件通路協定，由RFC 1939進行定義。POP3按照三個階段進行工作：特許、事務處理以及更新：

在第一個階段即特許階段，使用者代理發送(以明文形式)使用者名和密碼以鑒别使用者。

在第二個階段即事務處理階段，使用者代理取回封包，同時在這個階段使用者代理還能進行如下操作，對封包進行删除标記，取消封包删除标記以及擷取郵件的統計資訊。

在第三個階段即更新階段，它出現在客戶發出了quit指令後，目的是結束該POP3會話，此時該郵件伺服器删除那些被标記為删除的封包。

一個需要注意的是，POP3使用者代理可以使用兩種事務處理模式：一種是下載下傳并删除，另一種是下載下傳保留；POP3代理發出的指令和其工作模式相關；下載下傳并删除的方法存在的問題是，如果使用者在一台裝置上檢視了郵件（下載下傳了郵件）後，郵件将被删除，那麼在其他裝置上将無法檢視郵件；這給使用者帶來一定的不便。使用下載下傳儲存方式，則使用者下載下傳郵件後，郵件還在伺服器上。

在使用者代理與郵箱伺服器之間的POP3會話期間，該POP3伺服器保留了一些狀态資訊，特别是标記了哪些使用者封包被标記為删除了。但是POP3伺服器并不在POP3會話過程中攜帶狀态資訊，大大簡化了POP3的服務。

1.3.4.2.IMAP

POP3協定無法為使用者提供郵件分類管理的功能，雖然使用者可以通過将郵件下載下傳到本地，然後由使用者代理程式做分類管理，但是處理的結果是無法同步到其他檢視裝置上的。為了解決這一問題，IMAP誕生了。IMAP是一個郵件通路協定，比POP3要複雜的多，當然也就有更多的特色了。

（遠端）IMAP将每一份郵件和一個一個檔案夾聯系起來，當封包第一次到達伺服器時，它與收件人的INBOX相關聯。收件人可以将郵件移到新建立的檔案夾，閱讀郵件，删除郵件等。IMAP允許使用者在不同檔案夾裡移動郵件并且查詢郵件。值得注意的是，IMAP伺服器維護了IMAP會話的使用者狀态資訊，但是POP3并不；IMAP協定還允許使用者代理擷取封包元件而不是封包整體。

1.3.4.3.基于Web的電子郵件

這種方式主要是指，使用者使用HTTP協定和郵件伺服器通信。使用者代理就是普通的浏覽器，但是，郵件伺服器之間還是使用SMTP協定的。

1.4 DNS：英特網的目錄服務

DNS的必要性：IP位址辨別主機，路由器，但是IP位址不好記憶，不便于人們使用，存在着字元串-ip位址轉換的重要性，是以由DNS負責将IP位址轉化為二進制的網絡位址。

1.4.1 DNS提供的服務

通過主機名或者是IP位址可以識别主機，但是對于人們而言更喜歡主機名辨別方式，而路由器則喜歡定長的、有着層次結構的IP位址。為了折中這些不同的偏好，我們需要一種能進行主機名到IP位址轉化的目錄服務。這就是域名系統的主要任務。

DNS是：

①一個由分層的DNS伺服器實作的分布式資料庫

②一個使得主機能夠查詢分布式資料庫的應用層協定

DNS伺服器通常是運作BIND軟體上的UNIX軟體，DNS協定運作在UDP之上，使用53号端口。DNS是為網際網路上的使用者應用程式以及其他軟體提供一種核心功能，即将主機名轉化為其背後的IP位址。

舉個例子，當某個使用者主機上的一個浏覽器請求URL頁面時★：

①同一台使用者主機上運作着DNS應用的用戶端。

②浏覽器從上述URL中抽取出主機名www.xxxxxx.edu，并将這台主機名傳給DNS應用的用戶端。

③DNS客戶向DNS伺服器發送一個包含主機名的請求

④DNS客戶最終會收到一份回答封包，其中含有對應于該主機名的IP位址。

⑤一旦浏覽器接收到來自DNS的該IP位址，它能夠向為于該IP位址80端口的HTTP伺服器程序發起一個TCP連接配接。

DNS還提供一些重要的服務：

主機名稱：比起主機規範名更加容易記憶，應用程式可以調用DNS來獲得主機名稱對應的規範主機名以及主機的IP位址

郵件伺服器别名：電子郵件應用程式可以調用DNS，對提供的主機名别名進行解析，以獲得該主機的規範主機名以及IP位址。

負載配置設定：DNS也被用在備援的伺服器之間配置設定負載。每個伺服器有着不同的IP位址，但是它們都和同一個主機名相關聯，也就是一個IP位址集合同一個規範主機名相聯系；當某個DNS伺服器收到DNS請求時，該伺服器獎使用IP位址的整個集合作為相應，但是在每個應答中，循環這些位址的次序。因為用戶端通常都是使用IP位址集合的首個元素，是以DNS就在備援的Web伺服器之間配置設定了負載。同理，多個郵件伺服器可以具有相同的别名。

1.4.2 DNS的工作機理概述

首先，DNS使用UDP作為其傳輸層協定；DNS服務使用53端口；當主機上的DNS用戶端收到一個轉換請求需要将主機名轉化為IP位址，用戶端将向網絡發送一個DNS查詢封包，然後用戶端将收到一個包含相關資訊的DNS回答封包，這個封包裡有用戶端想要的内容，之後DNS用戶端将IP位址傳回給請求的提出者即可。從使用DNS服務的請求者來看，DNS就像一個簡單的提供直接轉換服務的黑盒子，實際上這個黑盒子非常複雜，由分布在全球的大量DNS伺服器以及定義DNS伺服器和查詢主機之間如何通信的應用層協定組成。

集中式設計的DNS伺服器具有以下缺點：

①.單點故障：如果集中式的DNS伺服器崩潰，整個網際網路随之癱瘓

②.通信容量：單個DNS伺服器不得不處理所有的DNS查詢(用于為上億太主機産生的所有HTTP請求封包和電子郵件封包服務)。

③.遠距離的集中式資料庫：存在嚴重的時延。

④.維護：每新添加一個主機就要進行頻繁的更新

1. 分布式、層次資料庫

   根DNS伺服器、頂級域DNS伺服器和權威DNS伺服器；舉例說明，其工作的普遍流程：一個DNS用戶端，希望獲得www.baidu.com的IP位址，粗略的說，DNS用戶端首先和根DNS伺服器取得聯系，它将傳回負責解析頂級域名com的伺服器的IP位址（或者其集合），客戶将同這些伺服器之一取得聯系，然後頂級域DNS伺服器建傳回baidu.com的權威伺服器的IP集合，用戶端通過與這些伺服器之一取得聯系，獲得www.baidu.com的IP位址。

   根DNS伺服器：網際網路上有13個根DNS伺服器，大部分分布在北美洲，盡管我們可以将這13個根DNS伺服器視為單個的伺服器，但是每台伺服器實際上是一個備援的計算機網絡以提供安全性和可靠性；

   頂級域DNS伺服器：負責頂級域名，如com，org，net，edu，gov以及各個國家的頂級域名的轉換。

   權威DNS伺服器：網際網路上，具有公共可通路主機的每個組織機構必須公共可通路的DNS記錄，這些記錄将主機名映射為IP位址。一個組織的權威DNS伺服器收藏了這些DNS記錄，多數大學和大公司實作和維護它們自己的基本和輔助（備份）權威DNS伺服器；當然，也可以通過付費的方式，将相關的資訊插入到其它權威伺服器中；

   除了上面三種DNS伺服器，還有一種不在DNS層次結構之中，但是很重要的DNS，是本地DNS伺服器。本地DNS伺服器通常鄰近其所在網絡的其他主機。當主機發出DNS請求時，該請求被發往本地DNS伺服器，它起着代理的作用，并将請求轉發到DNS伺服器層次結構中。

   DNS查詢有兩種，一種是遞歸查詢一種是疊代查詢；實踐中，查詢通常滿足這樣的模式：從請求主機到本地DNS伺服器的查詢是遞歸的，其餘查詢是疊代的。所謂疊代就是，如果請求的接收者不知道所請求的内容，那麼接收者将扮演請求者，發出有關請求，直到獲得所需要的内容，然後将内容傳回給最初的請求者。也就是說，在遞歸查詢中，一定要給請求者想要的答案；疊代查詢則是指，如果接收者沒有請求者所需要的準确内容，接收者将告訴請求者，如何去獲得，但是自己并不去送出請求。

   遞歸查詢：名字解析負擔都放在目前聯絡的名字伺服器上。

   疊代查詢：本地DNS伺服器查詢根DNS伺服器，根伺服器不知道但可以将其子域傳回，即告訴本地DNS伺服器根DNS伺服器的子域，以此疊代。

2. DNS緩存

   DNS緩存實際上是為了蓋上時延性能并且減少在網際網路上傳輸的DNS封包數量而引入的。DNS緩存原理十分簡單，每當DNS伺服器送出請求後收到回答時，就将回答的内容緩存在它自己的主機空間上。這樣，如果有相同的請求到達時，就不需要再去送出請求，直接使用緩存即可；因為有了緩存，本地DNS就可以直接提供一些經常被通路的主機名所對應的IP位址，而不需要詢問根DNS伺服器了。需要注意的是，緩存不可避免的一個問題：有效時間。如果緩存過時而未得到更新，那麼就會導緻一些請求失敗。

2.4.3 DNS記錄和封包

• DNS記錄

  共同實作DNS分布式資料庫的所有DNS伺服器存儲了資源記錄(RR)，RR提供了主機名到IP位址的映射。每個DNS回答封包包含了一條或多條資源記錄。

  資源記錄是一個包含了下列字段的四元組：

  (Name, Value, Type, TTL)

  TTL是該記錄的生存時間，它決定了資源記錄應當從緩存中删除的時間。Name和Value的值取決于Type，對應不同的Type四元組的意義不同：

1. type=A：則name為主機名，value為對應的IP位址；
2. type=NS：則name為域，value為如何獲得該域下主機IP位址的權威DNS伺服器的主機名；
3. type=CNAME：則value為name（本身為主機名稱）所對應的主機的規範主機名；

4. type=MX：則value為那麼所對應的郵件伺服器的規範主機名；

   如果為了獲得郵件伺服器的規範主機名，請求一條MX記錄；為了獲得其它伺服器的規範主機名，請求一條CNAME記錄，是以如果一條記錄為type=A，則它直接包含了需要的資訊；如果是NS，需要進一步得到權威DNS伺服器的IP位址（同時傳回一條NS記錄，并傳回一條以該NS記錄的value值為name的A記錄）希望得到一條A記錄；而type=CNAME和MX的記錄則實作了主機名稱到主機規範名的轉換，可以通過該規範名繼續建構查詢鍊條，直到獲得希望的IP位址；

• DNS封包

  DNS封包有兩種，即查詢封包和回答封包，并且兩種封包有着相同的結構

  

  前12位元組為首部區域。辨別符是一個用來标記該查詢的16比特數。該标志符會被複制到相應的回答封包裡，以便比對請求和回答；

  标志字段有若幹标志，用來指出封包的類型（請求還是響應）、查詢類型（遞歸還是疊代）、是否是所請求名字的權威DNS伺服器、以及4個有關數量的字段，用來訓示4類資料區域出現的數量；

  問題區域包含了正在進行的查詢資訊，包括名字字段、查詢類型；

  回答區域包含了對最初請求的名字的資源記錄，回答封包的回答區域可以包含多條RR，是以一個主機名能有多個IP位址；

  權威區域包含了其他權威伺服器的資訊；

  附加區域包含了其它有幫助的記錄，比如在對于一個MX類型的請求回答封包裡，回答區域裡指出了郵件伺服器的規範主機名，而附加區域裡就有可能包含一個類型為A的關于該規範主機名的的IP位址；

• 向DNS資料庫中插入資料

  需要在注冊登記機構(registrar)完成這一任務，當你注冊一個域名時，需要向該機構提供你的基本和輔助DNS伺服器的名字和IP位址；該注冊機構将確定一個類型為NS和類型為A的記錄輸入對應的頂級域名伺服器；這樣就完成了插入資料

1.5 P2P檔案分發

P2P模式适用于一下模式:對總是打開的基礎設施伺服器沒有依賴，成對間歇連接配接的主機之間互相通信。

有兩種典型網際網路應用十分适合P2P體系結構，一種是檔案分發（BitTorrent)，另一種是大型對等方社群中的資料庫；我們将探讨分布式散清單的概念。P2P體系結構有着良好的自擴充性。這種擴充性的直接成因是：對等方除了比特的消費者之外還是他們的重新分發者。

• BitTorrent

  BitTorrent 是一種用于檔案分發的流行P2P協定；用BitTorrent的術語來說，參與一個特定檔案分發的所有對等方的集合被稱為一個洪流；在一個洪流中的對等方彼此下載下傳等長度的檔案塊；當一個對等方下載下傳檔案塊的時候，也向其他對等方發送了多個塊；一旦某對等方獲得了完整檔案，就可以自私地離開洪流或者大公無私地留下來繼續向其他對等方發送檔案.

  P2P檔案共享協定，參與一個特定檔案分發的所有對等方結合被稱為一個洪流（torrent），在一個洪流的對等方彼此下載下傳等長度的檔案塊，可以随時離開洪流，也可繼續向其他對等方上載。每個洪流都有一個追蹤器。

  Alice加入某洪流時，會在追蹤器裡進行注冊，周期性通知追蹤器它仍在洪流中。我們稱所有與ALICE成功的建立了一個TCP連結的對等方成為鄰近對等方。

  洪流随機從參與對等方的結合中選擇一個子集，将他們的IP位址發給Alice，Alice維護這張對等方清單，試圖與所有對等方建立并行的TCP連接配接。

  Alice周期詢問每個鄰近對等方（連上的）他們有的檔案塊清單，她随時知道鄰居有哪些檔案塊

  Alice使用最稀缺優先技術，首先請求那些鄰居們副本數量最少的塊，使該檔案塊迅速分發，以均衡每個塊在洪流中的副本數量

  BitTorrent使用一種算法，Alice優先從像她傳時速度最快的鄰居（4個，每10s修改一次）那裡擷取檔案塊。

  每過30s，Alice也要随機選擇另外一個對等方Bob，向他發送塊。若Alice是Bob最快的前四快，Bob也是Alice的前4快，則Bob和Alice互相發送資料。

  每過30s換一個新的對象，互相交換資料（一報還一報），為了使對等方能夠找到彼此協調的速率上傳

1.6 視訊流和内容分發網

1.6.1 網際網路視訊

視訊是一系列的圖像，通常以一種恒定的速率來展現。一幅未壓縮，數字編碼的圖像由像素陣列組成，其中每個像素是由一些比特編碼來表示亮度和顔色。視訊的一個重要特征是它能夠被壓縮，因而可以用比特率來衡量視訊品質。比特率越高，圖像品質越好。到目前為止，對流式視訊的最為重要的性能度量是平均端到端吞吐量。為了提供連續不斷的布局，網絡必須為流式應用提供平均吞吐量，這個流式應用至少與壓縮視訊的比特率一樣大。

1.6.2 HTTP流和DASH

在HTTP流中，視訊隻是存儲在HTTP伺服器中作為一個普通的檔案，每個檔案有一個特定的URL。當使用者要看該視訊時，客戶與伺服器建立一個TCP連接配接并發送對該URL的HTTP GET請求。伺服器則以底層網絡協定和流量條件允許的盡可能快的速率，在一個HTTP響應中發送該視訊檔案。在用戶端，一旦該緩存中的位元組數量超過預先設定的門限，客戶應用程式就開始播放。

存在的問題就是所有客戶接收到相同編碼的視訊，是以導緻一種新型基于HTTP的流的研發，它常常被稱為經HTTP的動态适應性流(DASH)，在DASH中，視訊編碼分為幾個不同的版本，每個版本有不同的比特率，對應于不同的品質水準。使用DASH後，每個視訊版本存儲在HTTP伺服器中，每個版本都有一個不同的URL。HTTP伺服器也有一個告示檔案，為每個版本提供了一個URL及其比特率，以此來根據測量的接受帶寬選擇不同速率的版本。

1.6.3 内容分發網

為了應對向分布于全世界的使用者分發巨量視訊資料的挑戰，幾乎所有主要的視訊流公司都利用内容分發網(CDN)。CDN管理分布在多個地理位置上的伺服器，在他的伺服器上存儲視訊(和其他類型的Web内容)的副本，并且所有試圖将每個使用者請求定向到一個将提最好的使用者體驗的CDN位置。

CDN可以是專用CDN，即它由内容提供商自己所擁有；另一種CDN可以是第三方CDN，它代表多個内容提供商分布内容。

CDN通常采用兩種不同的伺服器安置原則：

1. 深入

   其目标是靠近端使用者，通過減少端使用者和CDN叢集之間鍊路和路由器的數量，進而改善了使用者感受的時延和吞吐量。

2. 邀請做客

   通過在少量關鍵位置建造大叢集來邀請到ISP做客，此設計通常産生較低的維護和管理開銷，可能以對端使用者的較高時延和較低吞吐量為代價。

1.6.3.1 CDN操作

當使用者主機中的一個浏覽器指令檢索一個特定的視訊(由URL辨別)時，CDN必須截取獲該請求，以便能：

①确定此時适合用于該使用者的CDN伺服器叢集；

②将客戶的請求重定向到該叢集的某台伺服器。

大多數CDN利用DNS來截獲和重定向請求，如下所示：

1. 使用者通路為于NetCinema的Web網頁。
2. 當使用者點選連結http://xxx.xxxx.xxx/645YB23V時，該使用者主機發送了一個對于xxx.xxxx.xxx的DNS請求
3. 使用者的本地DNS伺服器(LDNS)将該DNS請求中繼到一台用于NetCinema的權威伺服器，該伺服器觀察到主機名xxx.xxxx.xxx中的字元串’xxx’。為了将該DNS請求移交給KingCDN，NetCinema權威DNS伺服器并不傳回一個IP位址，而是向LDNS傳回一個KingCDN域的主機名。
4. 從這時起，DNS請求進入了KingCDN專用DNS基礎設施。使用者的LDNS則發送第二個請求，此時是對之前傳回的KingCDN域的主機名的DNS請求，KingCDN的DNS系統最終向LDNS傳回KingCDN内容伺服器的IP位址。此時，在KingCDN的DNS系統中，指定了CDN伺服器，客戶将能夠從這台伺服器接收到它的内容。
5. LDNS向使用者主機轉發内容服務CDN節點的IP位址
6. 一旦使用者收到KingCDN内容伺服器的IP位址，它與具有該IP位址的伺服器建立一條直接的TCP連接配接，并且發出對該視訊的HTTP GET請求。如果使用了DASH，伺服器首先将使用者發送具有URL清單的告示檔案，每個URL對應視訊的每個版本，并且客戶動态的選擇不同的版本。

1.6.3.2 叢集選擇政策

任何CDN部署，其核心是叢集選擇政策，即動态地将客戶定向到CDN中的某個伺服器叢集或資料中心的機制。

一種簡單的政策是指派客戶到地理上最為臨近的叢集，每個LDNS IP位址都映射到一個地理位置。但是對于某些客戶，該方案可能效果比較差，因為就網絡路徑的長度或跳數而言，地理最鄰近的叢集可能并不是最近的叢集。

另一種所有基于DNS的方法都内在具有的問題是，某些端使用者配置使用位與遠地的LDNS，在這種情況下,LDNS位置可能遠離客戶的位置，此外這種簡單的政策忽略了時延和可用帶寬随網際網路路徑時間而變化，總是為特定的使用者指派相同的叢集。

為了基于目前流量條件為客戶決定最好的叢集，CDN能夠對其叢集和客戶之間的時延和丢包性能執行周期性的實時測量。