計算機網路：應用層

阿新 • • 發佈：2018-12-09

應用層協議原理

網路應用程式體系結構

在客戶-服務體系結構（client-server architecture）中，有一個總是開啟的主機稱為伺服器，它服務於來自許多其他稱為客戶的主機的請求。一個經典的例子就是Web應用程式。

在一個P2P體系結構中，對位於資料中心的專用伺服器有最小的（或者沒有）依賴。相反，應用程式在間斷連線的主機對之間使用直接通訊，這些主機對被稱為對等方。例如，對於許多即時通訊應用而言，伺服器被用於跟蹤使用者的IP地址，但使用者到使用者的報文在使用者之間（無需通過中間伺服器）直接傳送。

程序通訊

進行通訊的實際上是程序（process）而不是程式。一個程序可以被認為是執行在端系統中的一個程式。

在兩個不同端系統上的程序，通過跨越計算機網路交換報文（message）而相互通訊。傳送程序生成並向網路中傳送報文；接收程序接收這些報文並可能通過將報文傳送回去進行響應。

客戶和伺服器程序

網路應用程式由成對的程序組成，這些程序通過網路相互發送報文。

在給定的一對程序之間的通訊會話場景中，發起通訊（即在該會話開始時發起與其他程序的聯絡）的程序被表示為客戶，在會話開始時等待聯絡的程序是伺服器。

程序與計算機網路之間的介面

程序通過一個稱為套接字（socket）的軟體介面向網路傳送報文和從網路接收報文。

套接字是同一臺主機內應用層與運輸層之間的介面。由於該套接字是建立網路應用程式的可程式設計介面，因此套接字也稱為應用程式和網路之間的應用程式程式設計介面

（Application Programming Interface，API）。

應用程式開發者可以控制套接字在應用層端的一切，但是對該套接字在運輸層端幾乎沒有控制權。應用程式開發者對於運輸層的控制權僅限於：
- 選擇運輸層協議；
- 設定運輸層引數，如最大快取和最大報文段長度等。

程序定址

在一臺主機上執行的程序為了向在另一臺主機上執行的程序傳送分組，需要有一個接收程序的地址。為了標識該接收程序，需要定義：
- 主機的地址；IP地址（IP address）
- 在目的主機中的接收程序的識別符號。埠號（port number）

可供應用程式使用的運輸服務

可靠資料傳輸
吞吐量
定時
安全性

因特網提供的運輸服務

TCP服務
- 面向連線的服務：在應用層資料報文開始流動之前的握手階段，TCP讓客戶和伺服器相互交換運輸層控制資訊。握手階段之後，就在兩個程序的套接字之間建立了一個TCP連線。連線雙方的程序都可以在此連線上同時進行報文收發，當應用程式結束報文傳送時，必須拆除該連線。
- 可靠的資料傳輸服務：通訊程序能夠依靠TCP，無差錯、按適當順序交付所有傳送的資料。

TCP協議還具有擁塞控制機制，這種服務不一定能為通訊程序帶來直接好處，但能為因特網帶來整體好處。當傳送方和接收方之間的網路出現阻塞時，TCP的擁塞控制機制會抑制傳送程序（客戶或伺服器）。TCP擁塞控制也試圖限制每個TCP連線，使它們達到公平共享網路頻寬的目的。

UDP服務

UDP是一種不提供不必要服務的輕量級運輸協議，它僅提供最小服務。UDP是無連線的，因此在兩個程序通訊前沒有握手過程。UDP協議提供一種不可靠資料傳送服務，也就是說，當程序將一個報文傳送進UDP套接字時，UDP協議並不保證該報文將達到接受程序，而且到達接受程序的報文也可能是亂序到達的。

UDP沒有包括擁塞控制機制，所以UDP的傳送端可以用它選定的任何速率向其下層（網路層）注入資料。

應用層協議

應用層協議（application-layer protocol）定義了執行在不同端系統上的應用程式程序如何相互傳遞報文。特別是應用層協議定義了：

交換的報文型別，例如請求報文和響應報文。
各種報文型別的語法，如報文中的各個欄位及這些欄位是如何描述的。
欄位的語義，即這些欄位中包含的資訊的含義。
一個程序何時以及如何傳送報文，對報文進行響應的規則。

有些應用層協議是由RFC文件定義的，因此它們位於公共域中。例如，Web的應用層協議HTTP（超文字傳輸協議[RFC 2616]）就作為

RFC：Request For Comments（RFC），是一系列以編號排定的檔案。檔案收集了有關網際網路相關資訊，以及UNIX和網際網路社群的軟體檔案。目前RFC檔案是由Internet Society（ISOC）贊助發行。基本的網際網路通訊協議都有在RFC檔案內詳細說明。RFC檔案還額外加入許多的論題在標準內，例如對於網際網路新開發的協議及發展中所有的記錄。因此幾乎所有的網際網路標準都有收錄在RFC檔案之中。

Web和HTTP

HTTP概況

Web的應用層協議是超文字傳輸協議（HyperText Transfer Protocol，HTTP），它是Web的核心。HTTP由兩個程式實現：一個客戶程式和一個伺服器程式。客戶程式和伺服器程式執行在不同的端系統中，通過交換HTTP報文進行會話。HTTP定義了這些報文的結構以及客戶和伺服器進行報文交換的方式。

Web頁面（Web page）（也加文件）是由物件組成的。一個物件（object）只是一個檔案，例如，HTML檔案、JPEG圖形、Java小程式或視訊片段，且它們都可以通過一個URL地址定址。
多數Web頁面含有一個HTML基本檔案（base HTML file）以及幾個引用物件。HTML基本檔案通過物件的URL地址引用頁面中的其他物件。每個URL地址由兩部分組成：存放物件的伺服器主機名和物件的路徑名。
Web瀏覽器（Web browser）實現了HTTP的客戶端；Web伺服器（Web server）實現了HTTP的伺服器端，它用於儲存Web物件，每個物件由URL定址。流行的Web伺服器有Apache和Microsoft Internet Information Server（微軟網際網路資訊伺服器）。

伺服器向客戶傳送被請求的檔案，而不儲存任何關於該客戶的狀態資訊。所以說HTTP是一個無狀態協議（stateless protocol）。同時Web伺服器總是開啟的，具有一個固定的IP地址，且它服務於可能來自數以百萬計的不同瀏覽器的請求。

非持續連線和持續連線

當客戶-伺服器的互動是經過TCP進行的，應用程式的研製者就需要決定每個請求/響應對是經過一個單獨的TCP連線傳送，還是所有的請求及其響應經相同的TCP連線傳送。如果採用前一種方法，該應用程式被稱為使用非持續連線（non-persistent connection）；採用後一種方法，該應用程式被稱為使用持續連線（persistent connection）。

HTTP既能夠使用非持續連線，也能夠使用持續連線。儘管HTTP在預設方式下使用持續連線，HTTP客戶和伺服器也能配置成使用非持續連線。一般來說，如果一條連線經過一定時間間隔（一個可配置的超時間隔）仍未被使用，HTTP伺服器就關閉該連線。

HTTP報文格式

HTTP請求報文

GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
實體主體

第一行為請求行（request line），包括：方法欄位、URL欄位和HTTP版本欄位，方法欄位包括GET、POST、HEAD、PUT和DELETE；其後繼的行叫做首部行（header line）。

HTTP響應報文

HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
data data data data data ...

有三個部分：初始狀態行（status line），首部行（header line）和實體主體（entity body）。實體主體部分是報文的主要部分，它包含了所請求的物件本身。狀態行包含：協議版本欄位、狀態碼和相應狀態資訊。

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

cookie技術有4個元件：

在HTTP響應報文中的一個cookie首部行；
在HTTP請求報文中的一個cookie首部行；
在使用者端系統中保留有一個cookie檔案，並由使用者的瀏覽器進行管理；
位於Web站點的一個後端資料庫。

響應報文：

Set-cookie: 1678\r\n

請求報文：

Cookie： 1678\r\n

cookie可以用於標識一個使用者。使用者首次訪問一個站點時，可能需要提供一個使用者標識。在後繼會話中，瀏覽器向伺服器傳遞一個cookie首部，從而向該伺服器標識了使用者。因此cookie可以在無狀態的HTTP之上建立一個使用者會話層。

Web快取

Web快取器（Web cache）也叫代理伺服器（proxy server），它是能夠代表初始Web伺服器來滿足HTTP請求的網路實體。Web快取器有自己的磁碟儲存空間，並在儲存空間中儲存最近請求過的物件的副本。

Web快取器是伺服器同時又是客戶。當它接收瀏覽器的請求併發迴響應時，它是一個伺服器。當它向初始伺服器發出請求並接收響應時，它是一個客戶。

Web快取器通常由ISP購買並安裝。

大大減少對客戶請求的響應時間，特別是當客戶與初始伺服器之間的瓶頸頻寬遠低於客戶與Web快取器之間的瓶頸頻寬時更是如此。
大大減少一個機構的接入鏈路到因特網的通訊量。
從整體上大大減低因特網上的Web流量，從而改善所有應用的效能。

條件GET方法

儘管快取記憶體能減少使用者感受到的響應時間，但也引人了一個新的問題，即存放在快取器中的物件副本可能是陳舊的。換句話說，儲存在伺服器中的物件自該副本快取在客戶上以後可能已經被修改了。

HTTP 協議有一種機制，允許快取器證實它的物件是最新的這種機制就是條件GET (conditional GET）方法：

請求報文使用 GET 方法；
並且②請求報文中包含一個“ If- Modified-Since ：”首部行。

因特網中的電子郵件

使用者代理（user agent）
郵件伺服器（mail server）
簡單郵件傳輸協議（Simple Mail Transfer Protocol, SMTP）

郵件伺服器形成了電子郵件體系結構的核心。每個接收方在其中的某個郵件伺服器上有一個郵箱（ mailbox ）。郵箱管理和維護著傳送給他的報文。

一個典型的郵件傳送過程是：從傳送方的使用者代理開始，傳輸到傳送方的郵件伺服器，再傳輸到接收方的郵件伺服器，然後在這裡被分發到接收方的郵箱中。

如果Mail From的伺服器不能將郵件交付給Mail To的伺服器，Mail From的郵件伺服器在一個報文佇列（ message queue ）中保持該報文並在以後嘗試再次傳送。通常每 30 分鐘左右進行一次嘗試；如果幾天後仍不能成功，伺服器就刪除該報文並以電子郵件的形式通知傳送方。

SMTP

SMTP 是因特網電子郵件應用的核心，用於從傳送方的郵件伺服器傳送報文到接收方的郵件伺服器。

SMTP 一般不使用中間郵件伺服器傳送郵件，即使這兩個郵件伺服器位於地球的兩端也是這樣。

使用Telnet連線SMTP伺服器的命令：

telnet serverName 25

之後可以通過命令傳送報文，例如：HELO、MAIL FROM、RCPT TO、DATA以及QUIT。

與HTTP相比：
1. HTTP主要是一個拉協議（pull protocol），SMTP基本上是一個推協議（push protocol）。
2. SMTP 要求每個報文使用 7 位元 ASCII 碼格式。
3. HTTP 把每個物件封裝到它自己的 HTTP 響應報文中，而 SMTP 則把所有報文物件放在一個報文之中。

郵件報文格式

一個典型的報文首部看起來如下：

From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.

在報文首部之後，緊接著一個空白行，然後是以 ACSII 格式表示的報文體。

郵件訪問協議

POP3：第三版的郵局協議（ Post Office Protocol-Version 3, POP3 ）
IMAP：因特網郵件訪問協議（ Internet Mail Access Protocol, IMAP)
HTTP：基於 Web 的電子郵件，使用者代理就是普通的瀏覽器，使用者和他遠端郵箱之間的通訊則通過 HTTP 進行，而郵件伺服器之間傳送和接收郵件時，仍然使用的是 SMTP。

DNS：因特網的目錄服務

域名系統（Domain Name System, DNS ）的主要任務是進行主機名到地址轉換的目錄服務。

DNS 是：
1.一個由分層的 DNS 伺服器（ DNS server ）實現的分散式資料庫；
2. 一個使得主機能夠查詢分散式資料庫的應用層協議。

DNS 伺服器通常是執行 BIND ( Berkeley Internet Name Domain ）軟體 [ BIND 2012 ] 的UNIX 機器。 DNS 協議執行在 UDP 之上，使用 53 號埠。

DNS 提供的重要服務：
- 主機別名（ host aliasing ）
- 郵件伺服器別名（ mail server aliasing ）
- 負載分配（ load distribution ）
DNS採用集中式設計的問題：
- 單點故障（ a single poinl of failure ）
- 通訊容量（ traffic volume）
- 遠距離的集中式資料庫（ distant centralized database ）
- 維護（ maintenance）
DNS 伺服器的層次結構：
- 根 DNS 伺服器
- 頂級域（ DNS ）伺服器
- 權威 DNS 伺服器
- 本地 DNS 伺服器

從理論上講，任何 DNS 查詢既可以是迭代的也可以是遞迴的。

在一個請求鏈中，當某 DNS 伺服器接收一個 DNS 回答（例如，包含主機名到IP地址的對映）時，它能將該回答中的資訊快取在本地儲存器中。** DNS 快取**（ DNS caching ）可以改善時延效能並減少在因特網上到處傳輸的 DNS 報文數量。

DNS 伺服器儲存的資源記錄是一個包含了下列欄位的4元組：

(Name, Value, Type, TTL)

TTL 是該記錄的生存時間，它決定了資源記錄應當從快取中刪除的時間。
如果 Type= A，則 Name 是主機名， Value 是該主機名對應的 IP 地址。
如果 Type ＝ NS，則 Name 是個域（如 foo.com ），而 Value 是個知道如何獲得該域中主機IP地址的權威 DNS 伺服器的主機名。
如果 Type= CNAME ，則 Value 是別名為 Name 的主機對應的規範主機名。
如果 Type= MX ，則 Value 是別名為 Name 的郵件伺服器的規範主機名。

使用 nslookup 程式（ nslookup program ）可以向DNS伺服器傳送 DNS 查詢報文。

P2P應用

P2P檔案分發

P2P體系結構的擴充套件性

分發時間(distribution time)是所有 N 個對等方得到該檔案的副本所需要的時間。

客戶-伺服器體系結構
- $D_{c-s}>=max（\frac{NF}{u_s},\frac{F}{d_min}）$
- N：對等方數目
- F：被分發檔案大小
- u_s：伺服器接入鏈路的上載速率
- d_min：具有最小下載速率的對等方的下載速率，即 $d_{min}=min(d_1,d_2,……,d_N)$
P2P 體系結構
- $D_{p-p}>=max（\frac{F}{u_s},\frac{F}{d_min},\frac{NF}{u_s+\sum_{i=1}^N{u_i}}）$

BitTorrent

BitTorrent是一種用於檔案分發的流行 P2P 協議。

洪流(torrent)：參與一個特定檔案分發的所有對等方的集合。在一個洪流中的對等方彼此下載等長度的檔案塊(chunk)，典型的塊長度為256KB。

當一個對等方首次加入一個洪流時，它沒有塊。隨著時間的流逝，它累積了越來越多的塊。當它下載塊，也為其他對等方上載了多個塊。一且某對等方獲得了整個檔案，它也許(自私地)離開洪流，或(大公無私地)留在該洪流中井繼續向其他對等方上載塊。同時，任何對等方可能在任何時候僅具有塊的子集就離開該洪流，並在以後重新加入該洪流中。

每個洪流具有一個基礎設施結點，稱為追蹤器(tracker)。當一個對等方加入某洪流時，它向追蹤器註冊自己，並週期性地通知追蹤器它仍在該洪流中。以這種方式，追蹤器跟蹤正參與在洪流中的對等方。

當一個新的對等方 A 加入該洪流時，追蹤器隨機地從參與對等方的集合中選擇對等方的一個子集，並將這些對等方的IP地址傳送給 A ，A 持有對等方的這張列表，試圖與該列表上的所有對等方建立並行的 TCP 連線。我們稱所有這樣與 A 成功地建立一個 TCP 連線的對等方為“鄰近對等方”。一個對等方的鄰近對等方將隨時間而波動（有些離開，有些加入）。

A 應當從它的鄰居請求哪些塊

最稀缺優先(rarest first)的技術：針對它沒有的塊在它的鄰居中決定最稀缺的塊，並首先請求那些最稀缺的塊。這樣，最稀缺塊得到更為迅速的重新分發，其目標是均衡每個塊在洪流中的副本數量。

A 應當向哪些向它請求塊的鄰居傳送

對換演算法：根據當前能夠以最高速率向它提供資料的鄰居，給出其優先權。被選中的對等方被稱為疏通(unchoked)。同時，每過 30 秒，它也要隨機地選擇另外一個鄰居並向其傳送塊，如果速率更快則進行替換。這種效果是對等方能夠以趨向於找到彼此的協調的速率上載。

分散式散列表

在 P2P 網路中實現一個簡單的鍵-值資料庫。考慮構建這種資料庫的一個分散式、 P2P 的版本，在數以百萬計的對等方上儲存(鍵，值)對。在該 P2P 系統中，每個對等方將保持 (鍵，值)對僅佔總體的一個小子集。我們將允許任何對等方用一個特別的鍵來查詢該分散式資料庫。分散式資料庫則將定位擁有該相應(鍵，值)對的對等方，然後向查詢的對等方返回該(鍵，值)對。任何對等方也將允許在資料庫中插入新鍵-值對。這樣一種分散式資料庫被稱為分散式散列表( Distributed Hash Table, DHT)。

為每個對等方分配一個識別符號，其中每個識別符號是一個[ O, 2^N -1 ] 範圍內的整數，N 取某些固定的值。並設計一個雜湊函式，將每一個鍵的值對映到這個範圍內。

環形DHT

將對等方組織為一個環。在這種環形設定中，每個對等方僅與它的直接後繼和直接前驅聯絡。使用該環形覆蓋網路，初始對等方生成一個查詢報文，並繞環順時針傳送該報文。無論何時某對等方接收到該報文，因為它知道其後繼和前驅的識別符號，它能夠確定是否是由它負責(即最鄰近)查詢的鍵。如果某對等方不負責該鍵，它只需將該報文傳送給它的後繼。：O（N/2）

具有捷徑的環形DHT

細化的方案之一是以該環形覆蓋網路為基礎，但增加“捷徑”，使每個對等方不僅聯絡它的直接後繼和直接前驅，而且聯絡分佈在環上的數量相對少的捷徑對等方。使用捷徑來加速查詢報文的路由選擇。研究表明 DHT 能被設計成每個對等方的鄰近數量以及每個請求的報文數量均為O(log N)。

對等方擾動

在P2P系統中，對等方能夠不加警示地到來和離去。因此，當設計一個 DHT 時，我們也必須關注存在這種對等方擾動時維護 DHT 的情況。為處理對等方擾動，我們要求每個對等方知道其第一個和第二個後繼的IP地址。

視訊流和內容分發網路

DASH

經HTTP的動態適應性流（Dynamic Adaptive Streaming over HTTP，DASH）。

在DASH中，視訊編碼為幾個不同的版本，其中每個版本具有不同的位元率，對應不同的質量水平。每個版本具有一個不同的URL，HTTP伺服器也有一個告示檔案（manifest file），為每個版本提供一個URL及其位元率，客戶用HTTP GET請求報文一次選擇一個不同的塊，在下載塊的同時，使用者也測量頻寬並執行一個速率決定演算法來選擇下次請求的塊。

CDN：內容分發網路

CDN的全稱是Content Delivery Network，即內容分發網路。CDN是構建在網路之上的內容分發網路，依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、排程等功能模組，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。CDN的關鍵技術主要有內容儲存和分發技術。

CDN的基本原理是廣泛採用各種快取伺服器，將這些快取伺服器分佈到使用者訪問相對集中的地區或網路中，在使用者訪問網站時，利用全域性負載技術將使用者的訪問指向距離最近的工作正常的快取伺服器上，由快取伺服器直接響應使用者請求。

內容分發網路(CDN)是一個經策略性部署的整體系統，包括分散式儲存、負載均衡、網路請求的重定向和內容管理4個要件.

大多數CDN利用DNS來截獲和重定向請求。
CDN的部署核心是叢集選擇策略（cluster selection strategy）：
- 地理上最為臨近（geographically closest）的叢集。
- 對叢集和客戶之間的時延和丟包效能執行週期性的實時測量（real-time measurement）。

TCP和UDP套接字程式設計

UDP套接字程式設計

UDPClient.py

from socket import *
serverName = ’ hostname ’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)
message = raw_input (’ Input lowercase sentence z’)
clientSocket.sendto(message,(serverName, serverPort))
modified.Message, serverAddress = clientSocket.recvfrom(2048)
print modified.Message
clientSocket. close ( )

UDPServer.py

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM) serverSocket.bind{ ("" , serverPort))
print "The server is ready to receive"
while true:
    message, clientAddress = serverSocket.recvfrom(2048)
    modifiedMessage = message.upper()
    serverSocket.sendto(modifiedMessage, clientAddress)

TCP套接字程式設計

TCPClient.py

from socket import *
serverName = ’ servername ’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName, serverPort))
sentence = raw_input(’ Input lowercase sentence:’)
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print ’From Server:’, modifiedSentence
clientSocket.close()

TCPServer.py

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((’’, serverPort))
serverSocket.listen(1)//最大併發連線數
print ’The server is ready to receive’
while true:
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024)
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence)
    connectionSocket.close()

想了解更多關於計算機網路架構與網路安全：計算機網路架構與網路安全專欄