前言

本章介紹有關網路應用的原理和實現方法；定義關鍵的應用層概念，包括程式所需要的 網路服務、 客戶和伺服器、 程式和運輸層介面；詳細考察幾種 網路應用程式，包括WEB、電子郵件、DNS、對等檔案分發和影片流；並設計開發執行在 TCP和UDP上的網路應用程式；

2.1、應用層協議原理

研發網路應用的 核心是寫出能夠執行在 不同端系統和 透過網路彼此通訊的程式；值得注意的是，我們不需要寫在網路核心裝置如路由器或者鏈路層交換機上執行的軟體，這種設計方式（ 將應用程式限制在端系統的方法），促進了大量網路應用程式的迅速研發和部署；

2.1.1 網路應用程式體系結構

應用程式的體系結構不同於網路的體系結構。從應用程式研發者的角度來看， 網路體系結構是固定的，並 為應用程式提供特定的服務集合；換言之，應用程式體系結構使用應用程式開發設計的，它規定了在端系統上如何組織應用程式。兩種常見的現代網路應用程式所採用的體系結構為： 客戶-伺服器體系結構和對等體系結構；

客戶-伺服器體系結構

在該體系結構中，有一個總是開啟的主機，即 伺服器，它接收和服務來自其他許多被稱為客戶的主機請求；值得注意的是，在該體系結構中， 客戶之間是不直接通訊的； 該伺服器具有固定的、周知的地址；

客戶-伺服器體系結構的著名應用有： Web、FTP、Telnet和電子郵件。

通常，如果僅有一臺伺服器處理所有的請求，那麼伺服器系統將很快變得不堪重負，為此， 配備大量主機的資料中心常被用於建立強大的虛擬的伺服器，一個資料中心可以有數十萬臺伺服器，它們需要供電和維護，同時服務提供商還需要支付不斷出現的互聯和頻寬費用，以及傳送和接收到達/來自資料中心的資料；

P2P體系結構

在P2P體系結構中， 對位於資料中心的專用伺服器有著最小（ 或者沒有） 依賴。應用程式在間斷連線的主機對之間使用 直接通訊，這些主機被稱為 對等方。對等方並不為服務提供商所擁有，因為這種對等方通訊不需要透過專門的伺服器，所以該體系結構也被稱為對等方到對等方結構;

目前， 流量密集型應用都是P2P體系結構的。這些應用包括 檔案共享（例如BitTorrent）、 協助下載（例如迅雷）、 因特網電話（例如Skype）和  IPTV(例如迅雷看看)。

值得注意的是， 某些應用具有混合的體系結構，它們結合了客戶-伺服器和P2P這兩種體系結果，比如許多的即時通訊工具，伺服器用來跟蹤使用者IP地址，但是使用者之間的通訊則使用直接傳送

P2P體系結構最引人入勝的特性之一就是它們的 自擴充套件性。比如在檔案共享應用中，對等方可能透過向檔案的原始擁有者發出請求而產生工作量，但是對等方也有可能透過為其他對等方傳送檔案而為原始擁有者分擔壓力；P2P體系結構也是成本有效的，因為他通常不需要龐大的伺服器基礎設施和服務頻寬。

P2P面臨以下三個問題：

1. ISP友好。大多數住宅ISP受制於非對稱頻寬應用，也就是下載比上傳要多得多。但是P2P影片和檔案分發應用改變了從伺服器到住宅ISP的上載流量，因而給ISP帶來壓力；
2. 安全性。因為其高度的分佈和開放式，P2P應用也可能給安全帶來挑戰；
3. 激勵。如何說服使用者資源嚮應用提供頻寬、儲存和計算資源？這是一個問題；

2.1.2 程式通訊

在作業系統中，實際進行通訊的是 程式而不是應用程式；當程式執行在同一個端系統上時，它們使用程式間通訊機制相互通訊； 而程式間通訊的規則是由端系統上的作業系統確定的。當程式執行在不同的端系統上時，它們透過跨越計算機網路的報文相互通訊；傳送程式產生報文並且向網路中傳送，接收程式接收報文並對此作出響應（不響應也是一種響應）;

客戶與伺服器程式

網路應用程式由成對的 程式組成，這些程式透過網路互相傳送報文。對於每對通訊程式，我們通常將這兩個程式之一標識為 客戶，而另一個程式標識為 伺服器。
需要注意的是，在 某些P2P應用中，一個程式可能既是客戶也是伺服器，因為在一個檔案共享應用中，一個程式的確既能請求檔案也能傳送檔案。所以從程式所扮演的角色來區分是客戶程式還是伺服器程式不夠精確，所以我們從 發起通訊的順序來定義它們：在給定的一對程式之間，首先發起通訊的程式被標記為客戶程式，在會話開始時等待聯絡的程式被稱為伺服器程式。

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

多數應用程式是由 通訊程式對組成的，執行在不同端系統上的程式對之間透過計算機網路來實現通訊。所以，在應用程式程式和計算機網路之間存在一個介面，該介面被稱為 套接字。更為準確的說， 套接字是同一臺主機內應用層和運輸層之間的介面。由於該套接字是建立網路應用程式的可程式設計介面，因此套接字也被稱為應用程式和網路之間的 應用程式設計介面（Application Programming Interface, API .

應用程式開發者可以控制套接字在應用層的一切內容，但是 對於運輸層的相關部分， 幾乎沒有控制權，可以做的只有：

1. 選擇傳輸層協議；
2. 設定幾個傳輸層引數，比如最大快取和最長傳輸層報文長度；

程式定址

為了向特定目的程式傳送報文，傳送機程式需要知道接收程式（更為準確的說是，接收程式對應的套接字）的標記。該標記由兩部分組成：接收程式所在的 主機地址和 在目的主機中指定接收程式的識別符號；在因特網中，主機由 IP地址標記，其中IP地址是一個32位（IPV4）標記；而接收程式（或者說是 接收套接字）使用 埠號標記；一些常用的應用程式有著固定的埠號，比如Web伺服器使用80埠、郵件伺服器（執行SMTP協議）使用25埠等；

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

傳輸層協議的特點大致可以從以下這四個方面考量： 可靠資料傳輸、 吞吐量、 定時和 安全性；

可靠資料傳輸

如同在第一章中介紹的，分組在傳輸過程中可能會丟失。比如，分組因為 路由器中的快取溢位而被丟棄或者 分組在傳輸的過程中發生了損壞等情況；有些應用是不允許資料發生丟失的，比如 電子郵件、 檔案傳輸、 遠端主機訪問、 Web文件傳輸以及 金融應用等。為了支援這些應用，必須做一些工作以 確保應用程式一段傳送的資料正確、 完全地交付給接收資料的程式。如果一個協議提供了這樣得確保資料交付的服務，就認為該協提供了 可靠資料傳輸。當應用程式使用可靠資料傳輸的傳輸層協議時，只要將要傳送的資料傳輸進套接字就可以完全相信該資料可以完整無差錯地到達接收方；

當一個運輸層協議不提供可靠資料傳輸時，由傳送方傳送的資料就可能不能夠到達接收程式。這可能被 丟失允許的應用所接受。這類應用常見的有： 交談式音訊和影片。它們能夠承擔丟失一定量的資料損失，在這些應用中，如果丟失少量資料將出現小干擾，但是不會出現致命的損傷，這些應用為容忍丟失的應用。

吞吐量

在一條網路路徑上的兩個程式之間的通訊會話中， 可用吞吐量就是指能夠向接收程式交付位元的速率。因為會有其他會話共享該網路的路徑的頻寬，並且因為這些會話的到來和離開，可用吞吐量將發生變化；這就導致另一種自然的服務，即 運輸層協議能夠提供確切的可用吞吐量。使用這種服務時，應用程式就能以明確的速度接收資料，並且運輸層應當保證可用吞吐量必須總是至少為該速度；

對吞吐量有明確要求的應用程式被稱為 頻寬敏感的應用。許多多媒體應用是頻寬敏感的，比如 因特網電話。而 彈性應用則對吞吐量沒有嚴格的要求。這類應用包括： 電子郵件、檔案傳輸以及web傳送等。值得注意的是，吞吐量當然是越多越好了;

定時

定時和吞吐量都是關於速度的。一個提供定時服務的例子是：傳送方注入套接字中的每個位元到達接收方的套接字不遲於100ms。也就是說， 定時是對資料從傳送到到達所需時間的要求，而 吞吐量是對資料交付速度的要求。有些應用為了服務的有效性而對資料到達時間有嚴格的要求，常見的應用有： 因特網電話、 多方線上遊戲等；

安全性

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

2.1.4 因特網提供的傳輸層服務

因特網（更一般的是 TCP/IP網路）為應用程式提供連個運輸層協議，即 UDP和 TCP。每個協議對應用程式提供了不同服務的組合。以下為常見的因特網應用的特點：

TCP服務
TCP服務模型包括了 面向連線的服務和 可靠資料傳輸服務。

面向連線的服務：在應用層資料包文開始流動之前，TCP會在客戶端和伺服器端相互交換傳輸層控制資訊。這個握手過程將提示客戶端和伺服器端，讓它們為即將到來的大量分組做好準備；握手階段接收後將建立一個TCP連線。這條連結是 全雙工的，即連線雙方使用該條連結可以同時進行報文的收發。這條 連線將在通訊結束後拆除；
可靠的資料傳輸：應用程式使用TCP協議可實現 無差錯、 按適當順序交付所有傳送的資料， 沒有位元組的丟失和冗餘；

TCP服務還提供了 擁塞控制機制。 該機制不一定會給通行雙方帶來好處，但是會給網路帶來整體好處；當傳送方和接收方之間的網路出現擁塞時，TCP將使用擁塞控制機制來使網路恢復正常 ；

UDP服務

UDP服務是一種不提供不必要服務的輕量級運輸協議。它僅提供 最小服務。UDP是無連線的也就是說 通訊之前沒有握手；UDP 不提供資料的可靠傳輸；UDP也 沒有擁塞控制機制，所以UDP的傳送端可以用它選定的任何速率向其下層（網路層）注入資料。有些應用場景下，UDP協議將帶來更多的便利和效率，比如 DNS和一些 因特網電話服務（為了避免擁塞控制協議的控制而使用UDP）；

傳輸層無法提供的服務

從可靠資料傳輸、吞吐量、定時、安全性等四個角度來看運輸層提供的服務，我們發現， 運輸層無法對吞吐量和定時做出保證（因為因特網已經被設計成儘可能最大可能對付這種保證的缺乏）。總之，今天的因特網能夠為時間敏感的應用提供滿意的服務，儘管它並不提供任何定時或者頻寬保證；

流行的因特網應用及其應用層協議和支撐的運輸協議

電子郵件、遠端終端訪問、Web、檔案傳輸都使用了TCP（TCP提供了可靠資料傳輸服務，確保所有資料最終到達目的地）；而因特網電話應用通常能忍受某些丟失但要求一定的最小速率才能有效工作，故通常使用UDP（有些防火牆被配置成阻擋UDP流量，則使用TCP作為備份）以避開TCP的擁塞控制機制和分組開銷；

2.1.5 應用層協議

應用層協議定義執行在不同端系統上的應用程式程式如何相互傳遞資訊。涉及的內容包括： 交換的報文型別（請求或者響應）、 報文中包含哪些欄位、 欄位如何被解釋、 一個程式何時收發報文並如何對報文進行響應等內容‘
區分網路應用和應用層協議很重要， 應用層協議只是網路應用的一部分；（例如對於一個Web應用，包括文件格式標準HTML、Web瀏覽器、WEb伺服器，以及一個應用層協議HTTP；）

2.1.6 本書涉及的網路應用

即將介紹的應用包括： Web、 檔案傳輸、 電子郵件、 目錄服務、 流式影片和P2P。Web部分將介紹HTTP協議，它比較簡單和易於理解；FTP則和HTTP形成了對照；電子郵件是比Web更為複雜的應用，因為它使用了多個應用層協議；大多數使用者不會直接和DNS接觸，但是DNS很好地說明了一種核心的網路功能是如何在應用層實現的；最後便是P2P應用的簡單介紹了；

2.2 Web和HTTP

對於大多數使用者來說，最具吸引力的就是Web的 按需操作；

2.2.1 HTTP概述

HTTP（HyperText Transfer Protocol）是Web的 應用層協議，它是Web的 核心；HTTP有兩部分實現，一個 客戶端程式和一個 伺服器程式；HTTP定義了 客戶和伺服器進行報文交換的方法；

Web頁面（也叫文件）是由 物件組成的，一個物件是一個檔案，它們透過一個URL地址進行定址。 客戶和伺服器互動的核心思想是客戶透過HTTP請求對伺服器發出對Web頁面的請求報文，伺服器收到該報文後將返回包含該物件的HTTP響應報文。 URL地址由兩部分組成： 存放物件的伺服器主機名和物件的路徑名；

HTTP使用TCP作為它的傳輸層協議；HTTP客戶首先發起一個與伺服器的TCP連線，需要注意的是，伺服器根據請求作出響應，但是 不儲存任何關於該客戶的狀態資訊；也正因為這樣，HTTP被稱為 無狀態協議。同時，Web使用了 客戶端-伺服器的應用體系結構；其中web伺服器總是開著的；

2.2.2 持續連線和非持續連線