《計算機網絡自頂向下方法》(1) 應用層

應用層

應用層是網絡應用程序及它們的應用層協議存留的地方，位於應用層的信息分組稱爲報文（message）。

2.2 Web 和 HTTP

HTTP概況

Web 的應用層協議是超文本傳輸協議（HTTP），HTTP 運行在服務端和客戶端中，兩者通過交換 HTTP 報文進行會話。服務器提供 Web 界面，通常含有一個 HTML 基本文件及其通過 URL 引用的幾個對象，其中 URL 由存放對象的服務器主機名和對象的路徑名組成。

HTTP 運行在 TCP 協議上，端口號爲 80。HTTP 客戶向服務器發起 TCP 連接，連接建立後，兩者即可通過套接字接口互相發送 HTTP 報文。一旦報文通過套接字接口，就完全進入了 TCP 的控制。

HTTP 不保存關於客戶的任何信息，是一個無狀態協議。服務器將獨立處理從客戶端發送而來的每個 HTTP 報文，即使是同一個用戶在短時間內對同一個對象的重複請求。

非持續連接和持續連接

一對客戶的請求及服務器對其的響應，我們稱之爲一個請求響應事務；一個請求響應事務所花費的大致時間，我們稱之爲往返時間（RTT）。考慮一系列請求響應事務：

若每個請求響應事務都使用各自的 TCP 連接，稱爲非持續連接，這意味着一個 TCP 連接將在一個請求響應事務完成後即拆除；若所有請求響應事務使用同一個 TCP 連接，稱爲持續連接，這意味着一個 TCP 連接將保持一段時間，在這段時間內，所有請求響應事務都經由該連接完成，若該連接經過一定時間間隔（可配置的超時間隔）未被使用，HTTP 服務器就關閉該連接。

非持續連接的缺點：一是必須爲每個請求的對象建立並維護一個全新的連接，建立每個連接都需要消耗資源，這爲服務器帶來了沉重的負擔；二是必須爲每個請求的對象耗費 2 RTT 的時延，一個用於創建 TCP 連接，另一個用於請求和接收一個對象。

非持續連接可以採用並行連接優化。客戶端打開多個並行的 TCP 連接，每個連接都處理一個請求響應事務。

持續連接可以採用流水線優化。非流水線的客戶端必須串行執行每個請求響應事務，而採用流水線的客戶端能夠接連發送多個請求，而不必等待上一個請求的響應到達。

各個版本時延比較

假定客戶端發送一個請求，服務器響應以一個附有八個小對象的 HTTP 文件，計算各個版本的時延。

串行非持續連接：一個 HTTP 基本文件耗時 2 RTT，八個小對象耗時 16 RTT，共計 18 RTT

並行非持續連接：假定採用五個並行連接，一個 HTTP 基本文件耗時 2 RTT，八個小對象分兩批請求，耗時 4 RTT，共計 6 RTT

非流水線持續連接：一個 HTTP 基本文件耗時 2 RTT，此時 TCP 連接已建立好，接下來八個小對象均可利用該連接進行請求，每次請求和接收耗費 1 RTT，八個對象耗時 8 RTT，共計 10 RTT

流水線持續連接：一個 HTTP 基本文件耗時 2 RTT，八個小對象的請求並行處理，耗費 1 RTT，共計 3 RTT

HTTP/1.1 的默認模式是使用帶流水線的持續連接。

HTTP 報文格式

HTTP 請求報文

一個典型的 HTTP 請求報文如下所示：

第一行是請求行，從左到右由空格分隔的依次是方法字段、URL 字段和 HTTP 版本字段。方法字段常見爲 GET 和 POST，也有 HEAD、PUT 和 DELETE 等。URL 字段指明請求對象的路徑名。版本字段指明使用的版本，一般是 HTTP/1.1 版本。

往下是首部行，一直到空行（CRLF）爲止，由若干個鍵值對構成，指明該請求的一些附加信息。

最後是實體體，通常在使用 POST 方法提交表當時使用實體體，在使用 GET 方法時實體體通常爲空。

HTTP 響應報文

一個典型的 HTTP 響應報文如下所示：

第一行是狀態行，從左到右依次是協議版本字段、狀態碼和相應狀態信息。往下是首部行，一直到空行爲止。最後是實體體，包含了所請求的對象的內容。

用戶與服務器的交互：cookie

HTTP 是無狀態的，這簡化了服務器的設計，並提供了提高性能的空間。然而，服務器通常希望識別發送報文的用戶，爲此，HTTP 採用了 cookie。

cookie 用於標識一個用戶的過程：用戶首次訪問一個站點時，服務器的 HTTP 響應報文的首部行中包含一個 cookie，用戶的瀏覽器保存並管理該 cookie。當用戶再次向該站點發送 HTTP 請求報文時，瀏覽器將該 cookie 添加至報文的首部行中，服務器接收到請求報文後，查看首部行中的 cookie 字段，並與站點的後端數據庫進行比對，因此識別出用戶。cookie 在一段時間後會過期，在過期前，用戶都可憑 cookie 標識自己的身份。

這樣，cookie 就在無狀態的 HTTP 之上建立了一個用戶會話層。

Web 緩存

Web 代理服務器具有磁盤存儲空間，並在存儲空間中保存最近請求過的對象的副本，以此代理用戶的 HTTP 請求。

使用代理服務器，客戶端首先與代理服務器建立 TCP 連接，並向代理服務器發送 HTTP 請求。代理服務器檢查存儲空間中是否存有該請求的對象的副本，若有，則向客戶返回請求的對象；若無，代理服務器將與該請求的初始服務器建立 TCP 連接，併發送 HTTP 請求，待初始服務器的響應報文到達後，代理服務器在存儲空間中保存對象的副本，並向客戶發送該副本。在此過程中，代理服務器既是服務器又是客戶。

注意到，請求報文的 URL 字段只標識了對象的路徑而沒有主機的名稱，而一個完整的對象應由主機名和對象路徑來標識，那麼代理服務器如何知道初始服務器呢？解決的方案是在請求報文中加上一個 “Host” 首部行，以該行的值作爲主機名，與對象路徑拼接起來，來判斷是否備份了該對象的副本。

Web 代理服務器的優勢：

大大減少客戶請求的響應時間，特別是當客戶與初始服務器之間的瓶頸帶寬遠低於客戶與代理服務器之間時；
大大減少一個機構的接入鏈路到因特網的通信量；
大大減少因特網整體的 Web 流量，從而改善了所有應用的性能。

條件 GET 方法

代理服務器的對象副本可能是過時的，爲此，HTTP 提供了條件 GET 方法，以判斷代理服務器備份的副本是否是最新的。

服務器的響應報文的首部行中，通常含有一個 “Last-Modified” 首部行，以標識對象的最後修改日期。代理服務器在存儲對象的副本時，也會存儲該最後修改日期。使用條件 GET 方法，代理服務器只要在請求報文中使用 GET 方法，並加上一個 “If-Modified-Since” 首部行，值爲存儲的對象最後修改日期。服務器在接收到該請求報文時，檢查 “If-Modified-Since” 首部行中的時間。若在指定時間後對象被修改過，才發送該對象，否則服務器發送一個響應報文（並沒有包含該對象），表明代理服務器持有的對象副本是最新的，可以使用。

2.3 文件傳輸協議：FTP

FTP 是文件傳輸協議，基於 TCP 協議，在 FTP 用戶代理與遠程主機之間運行，會話期間保留用戶的狀態信息。

FTP 協議使用兩個並行的 TCP 連接，一個是控制連接（端口號爲 21），用於在兩主機之間傳輸控制信息，另一個是數據連接（端口號爲 20），用於在兩主機之間傳輸數據文件，其中，控制連接貫穿整個用戶會話期間，而數據連接只在需要進行文件傳輸時按需建立。因爲 FTP 協議使用一個獨立的控制連接，所以稱其控制信息是帶外傳送的，而 HTTP 顯然是帶內的。

FTP 的命令由 4 個大寫的 7 比特長度的 ASCII 字符組成，如 USER、PASS 等。

2.4 因特網中的電子郵件

簡單郵件傳輸協議 SMTP

電子郵箱由用戶代理、郵件服務器和簡單郵件傳輸協議（SMTP）組成，每個用戶在某個郵件服務器上有一個郵箱。

郵件發送的過程是，從發送方的用戶代理開始，傳輸到發送方的郵件服務器，再傳輸到接收方的郵件服務器，然後在這裏被分發到接收方的郵箱中。如果發送方的郵箱所在的郵件服務器不能將郵件交付給接收方的郵件服務器，那麼發送方的服務器會在一個報文隊列中保持該報文並在以後嘗試再次發送。

用戶代理與郵件服務器之間、郵件服務器與郵件服務器之間都是通過 TCP 建立連接，其中郵件服務器的端口號爲 25。SMTP 採用持續連接，如果發送服務器有幾個報文發往同一個接收服務器，可以使用同一個 TCP 連接。

SMTP 與 HTTP 的相同點：持續的 HTTP 和 SMTP 都使用持續連接。

SMTP 與 HTTP 的不同點：

SMTP 基本是一個推協議，HTTP 主要是一個拉協議；
SMTP 要求每個報文（包括它們的體）使用 7 比特 ASCII 碼格式，HTTP 不受格式限制；
SMTP 把所有報文對象放在一個報文中，HTTP 把每個對象封裝到它自己的 HTTP 響應報文中。

郵件訪問協議

SMTP 是一個推協議，所以不能用來從郵件服務器取報文。常見的郵件訪問協議有 POP3、IMAP 和 HTTP。

POP3

POP3 按照三個階段進行工作：特許、事務處理和更新。特許階段，用戶代理髮送用戶名和口令以鑑別用戶；事務處理階段，用戶代理取回報文，通常有下載並刪除和下載並保留兩種方式，採用下載並保留，用戶就能夠在不同機器上讀取郵件。

雖然在 POP3 會話期間，可能有某些郵件報文被標記爲刪除，但 POP3 是個無狀態協議。

IMAP

POP3 是無狀態協議，所以它不能將郵件指派到不同文件夾上，而維護了用戶狀態信息的 IMAP 協議可以。另外，IMAP 允許用戶代理獲取報文組件，如只讀取一個報文的報文首部。

HTTP

HTTP 是個拉協議，所以同樣能夠勝任。此時，用戶代理就是普通的瀏覽器，用戶和他遠程郵箱之間的通信通過 HTTP 運行，而郵件服務器之間仍然採用 SMTP。

2.5 DNS：因特網的目錄服務

DNS 提供的服務

主機有兩種標識方式，主機名或 IP 地址，顯然人類喜歡主機名而路由器喜歡 IP 地址。爲了解決這個衝突，互聯網提供了一種能進行主機名到 IP 地址轉換的目錄服務：域名系統（DNS）。DNS 包括一個由分層的 DNS 服務器實現的分佈式數據庫，與一個使得主機能夠查詢分佈式數據庫的應用層協議組成，該協議運行在 UDP 上，端口號爲 53。

DNS 將用戶提供的主機名解析爲 IP 地址，該服務通常提供給其他應用層協議，比如 HTTP、SMTP 和 FTP。用戶視角下 DNS 服務過程爲，首先用戶主機上的 DNS 客戶端將待解析的主機名發送給 DNS 服務器，等待 DNS 服務器返回包含相應的 IP 地址的報文，然後利用該 IP 地址進行後續操作。可以看到，DNS 引入了額外的時延。

DNS 除了域名解析外，還提供別的服務：

主機別名。規範主機名通常較爲複雜，使用較爲簡單的主機別名能夠方便記憶，DNS 爲規範主機名、主機別名與 IP 地址之間進行轉換。
郵件服務器別名。郵件服務器名也很複雜，使用較爲簡單的郵件服務器別名能夠方便記憶。
負載分配。繁忙的站點被冗餘分佈在多臺服務器上，每臺服務器均運行在不同的端系統上，有着不同的 IP 地址，因此，一個規範主機名就與一個 IP 地址集合相聯繫。DNS 服務器可以循環使用 IP 地址集合中的地址，來響應 DNS 解析請求，以分攤負載。

DNS 工作機理概述

如果因特網上僅使用一個 DNS 服務器，那麼，在這種集中式設計中，可能會出現例如單點故障、通信容量過大、遠距離時延過大、維護困難等問題，毫無擴展能力可言。爲了處理擴展性問題，DNS 使用了大量的 DNS 服務器，以層次結構組織分佈在世界各地。沒有一臺 DNS 服務器擁有因特網上所有主機的映射。

DNS 的層次結構，自頂向下依次是根 DNS 服務器、頂級域 DNS 服務器、權威 DNS 服務器。根服務器有 13 個；頂級域服務器負責頂級域名，如 com；權威服務器是因特網上具有公共可訪問主機的組織機構提供的。

同時，還有與 Web 緩存類似的 DNS 緩存，也就是本地 DNS 服務器。本地 DNS 服務器代理用戶的 DNS 請求，若請求的域名，在本地已有緩存，則向用戶返回相應的 IP 地址，否則本地服務器將採用遞歸查詢或迭代查詢方式進行查詢。實踐中，從請求主機到本地 DNS 服務器的查詢是遞歸的，其餘的是迭代的。

本地 DNS 服務器緩存接收到的域名解析信息，並在一定時間後丟棄緩存的信息，因爲主機名與 IP 地址的映射並不是永久的。有了 DNS 緩存，改善了時延性能，並減少了在因特網到處傳輸的 DNS 報文數量。

DNS 記錄

DNS 服務器存儲了資源記錄，即包含了 (Name, Value, Type, TTL) 字段的四元組。對於不同的 Type，各個字段（除了 TTL，表示該記錄的生存時間）有不同的含義：

Type = A，則 Name 是主機名，Value 是該主機名對於的 IP 地址。
Type = NS，則 Name 是個域，而 Value 是個知道如何獲得該域中主機 IP 地址的權威 DNS 服務器的主機名。
Type = CNAME，則 Value 是別名爲 Name 的主機對應的規範主機名。
Type = MX，則 Value 是個別名爲 Name 的郵件服務器的規範主機名。

如果一臺 DNS 服務器是用於某特定主機名的權威 DNS 服務器，那麼該 DNS 服務器會有一條包含該主機名的類型 A 記錄（緩存有該映射的本地服務器也可能有類型 A 的記錄），否則該服務器將包含一條類型 NS 記錄（Value 對應於包含主機名的域）與一條類型 A 記錄（Value 對應於在 NS 記錄的 Value 字段中的 DNS 服務器的 IP 地址）。

2.6 P2P 應用

続く