應用層協議——原理
應用層協議的實現,只需要寫出能夠運行在不同的端系統(服務器、手機、電腦等)和通過網絡彼此通信的程序。因爲網絡核心設備(路由器、交換機等,不包括端系統設備)並不在應用層上起作用,只在網絡層及下面層次起作用,所以不需要爲網絡核心設備寫對應的應用程序,即開發應用程序的時候只需要考慮適配端系統,不需要考慮網絡核心設備。
網絡應用程序體系結構
目前主流的網絡應用程序體系結構有兩種:客戶-服務器體系結構(client-server architecture)
和對等體系結構(P2P)
。
- 客戶-服務器體系結構(client-server architecture):在
客戶-服務器體系結構
中,至少有一個打開的主機,被稱爲服務器,它服務來自其他許多稱爲客戶的主機的請求。web應用程序就是一個典型的例子,他總是有至少一個web服務器在運行來響應瀏覽器的請求。客戶-服務器體系結構
的一個特徵就是服務器具有固定且被知曉的IP地址。 - 對等體系結構(P2P):
P2P體系結構
對位於數據中心的專用服務器有最小的(或者沒有)依賴。應用程序在間斷連接的主機對
之間使用直接通信,這些主機對
被稱爲對等方
。這些對等方
並不爲服務提供商所有,爲用戶控制的臺式機、筆記本等所有。因爲這種對等方
通信不必通過專門的服務器,該體系被稱爲對等方到對等方
。
進程通信
進程的定義
在操作系統中,進行通信的實際上是進程(process)
而不是程序。一個進程可以被認爲是運行在端系統中的一個程序。
兩個不同端系統上的進程,通過跨越計算機網絡交換報文
而相互通信。發送進程生成並向網絡中發送報文;接收進程接收這些報文並可能通過報文發送回去進行響應。
每對通信進程,我們通常將這兩個進程之一標識爲客戶(client)
,另一個進程標識爲服務器(server)
。P2P文件共享的某些應用中,一個進程能夠既是客戶又是服務器。所以我們可以這樣定義客戶和服務器進程:在給定的一對進程之間的通信回話場景中,發起通信(即在該會話開始時發起與其他進程的聯繫)的進程被標識爲客戶,在會話開始時等待聯繫的進程是服務器。
進程與計算機網絡直接的接口
進程通過一個稱爲套接字(socket)
的軟件接口向網絡發送報文和從網絡接收報文。套接字
是同一臺主機內應用層與運輸層之間的接口,在發送端的應用程序將報文推進套接字,在該套接字的另一側,運輸層協議負責是該報文進入接收進程的套接字。由於該套接字是建立網絡應用程序的可編程接口,因此套接字也稱爲應用程序和網絡之間的應用程序編程接口(Application Programming Interface, API)
。應用程序開發者可以控制套接字在應用層的一切,但對改套接字的運輸層端幾乎沒有控制權。開發者對運輸層的控制僅限於:①選擇運輸層協議;②也許能設定幾個運輸層參數,如最大緩存和最大報文段長度等。一旦開發者選擇了一個運輸層協議,則應用程序就建立在由該協議提供的運輸層服務上。
進程尋址
在一臺主機上運行的進程爲了向在另一臺主機上運行的進程發送分組,接收進程需要有一個地址。爲了標識改接收進程,需要定義兩種信息:①主機的地址;②定義在目的主機中的接收進程的標識符。
在因特網中,主機由其IP地址(IP address)標識。IP地址是一個32比特的量且能夠唯一地標識主機。因爲一臺主機能夠運行多個網絡應用,發送報文時,發送進程除了要知道目的地的主機地址外,還需要指定運行在接收主機上的接收進程(接收套接字)。目前比較流行的端口有:Web服務器的80端口、SMTP的25端口等。
運輸服務
可供應用程序使用的運輸服務
網絡中運輸層的協議不止一種,開發應用時需要根據需求選擇相對應的運輸層協議。根據對運輸層服務的要求,可以將運輸層服務大體分爲四類:可靠數據傳輸
、吞吐量
、定時
、安全性
。
可靠數據傳輸
有時候數據丟失可能會造成災難性的後果,所以必須做一些工作以確保由應用程序的一端發送的數據正確、完全地交付給該應用程序的另一端。如果一個協議提供了這樣的確保數據交付服務,就認爲提供了可靠數據傳輸(reliable data transfer)。當運輸協議提供這種服務時,發送進程只要將其數據傳遞進套接字,就可以完全相信該數據將能無差錯地到達接收進程。
此外,某些進程不能提供可靠數據傳輸,由發送進程發送的某些數據可能不能夠到達接收進程。這種運輸層協議一般用於多媒體應用,如音頻、視頻等。這些應用能夠承受一定量的數據丟失,卻並不致命。
吞吐量
在沿着一條網絡路徑上的兩個進程之間的通信會話場景中,可用吞吐量就是發送進程能夠向接收進程交付的比特速率。因爲其他會話將共享沿着該網絡路徑的帶寬,並且因爲這些會話將會到達和離開,該可用吞吐量將隨時間波動。這就要求運輸層協議能夠以某種特定的速率提供確保的可用吞吐量,及吞吐量服務。使用這種服務,該應用程序能夠請求r比特/秒的確保吞吐量,並且該運輸協議能夠確保可用吞吐量總是至少爲r比特/秒。
定時
運輸層協議能提供定時保證,如發送方注入進套接字中的每個比特到達接收方的套接字不遲於100ms。這種服務隊交互式實時應用程序具有很大的吸引力,如網絡電話、網絡交互遊戲等,這些應用爲了有效性而要求數據交付有嚴格的時間限制。
安全性
運輸協議能夠爲應用程序提供一種或多種安全性服務。例如,在發送主機中,運輸協議能夠加密由發送進程傳輸的所有數據,在接收主機中,運輸層協議能夠在數據交付給接收進程之前解密這些數據。運輸協議還能提供機密性以外的其他安全性服務,包括數據完整性和端點鑑別。
因特網提供的運輸服務
因特網(更一般的是TCP/IP網絡)爲應用程序提供兩個運輸層協議,即UDP
和TCP
。當爲因特網創建一個新的應用時,受限要做出的決定是選擇UDP
還是TCP
。每個協議爲調用它們的應用程序提供了不同的服務集合。下表爲一些應用程序的服務要求。
應用 | 數據丟失 | 帶寬 | 時間敏感 |
---|---|---|---|
文件傳輸 | 不能丟失 | 彈性 | 不 |
電子郵件 | 不能丟失 | 彈性 | 不 |
Web文檔 | 不能丟失 | 單行(幾kbps) | 不 |
因特網電話/視頻會議 | 容忍丟失 | 音頻(幾kbps~1Mbps)、視頻(10kbps~5Mbps) | 是,100ms |
存儲音頻/視頻 | 容忍丟失 | 同上 | 是,幾秒 |
交互式遊戲 | 容忍丟視 | 幾kbps~10kbps | 是,100ms |
即時訊息 | 不能丟失 | 彈性 | 是和不是 |
TCP服務
TCP服務模型包括面向連接服務和可靠數據傳輸服務。當某個應用程序調用TCP作爲運輸協議時,該應用程序就能獲得來自TCP的兩種服務。
- 面向連接的服務:在應用層數據報文開始流動之前,TCP讓客戶和服務器互相交換運輸層控制信息。這個所謂的握手過程提示客戶和服務器,使它們爲大量分組的到來做好準備。在握手階段後,一個TCP連接就在兩個進程的套接字之間建立了。這條連接是全雙工的,即連接雙方的進程可以在此連接上同時進行報文的收發。當應用程序結束報文發送時,必須拆除該連接。
可靠的數據傳送服務:通信進程能夠依靠TCP,無差錯、按適當順序交付所有發送的數據。當應用程序的一端將字節流傳進套接字時,它能夠依靠TCP將相同的字節流交付給接收方的套接字,而沒有字節的丟失和冗餘。
TCP協議還具有擁塞控制機制,這種服務不一定能爲通信進程帶來直接好處,但能爲因特網帶來整體好處。當發送方和接收方之間的網絡出現擁塞時,TCP的擁塞控制機制會抑制發送進程(客戶或服務器)。
UDP服務
UDP是一種不提供不必要服務的輕量級運輸協議,它僅提供最小服務。UDP是無連接的,因此在兩個進程通信前沒有握手過程。UDP協議提供一種不可靠數據傳送服務,也就是說,當進程將一個報文發送進UDP套接字時,UDP協議並不保證該報文將到達接收進程。不僅如此,達到接收進程的報文也可能是亂序到達的。
UDP沒有包括擁塞控制機制,所以UDP的發送端可以用它選定的任何速率向其下層(網絡層)注入數據。
下表指出了一些流行的因特網應用所使用的運輸協議:
應用 | 應用層協議 | 支撐的運輸協議 |
---|---|---|
電子郵件 | SMTP [RFC 5321] | TCP |
遠程終端訪問 | Telnet [RFC 854] | TCP |
Web | HTTP [RFC 2616] | TCP |
文件傳輸 | FTP [RFC 959] | TCP |
流式多媒體 | HTTP (如 YouTube) | TCP |
因特網電話 | SIP [RFC 3261]、RTP [RFC 3550]或專用的(如 Skype) | UDP 或 TCP |
因特網運輸協議所不提供的服務
運輸層協議服務有可靠數據傳輸
、吞吐量
、定時
、安全性
4個方面的服務。TCP提供了可靠的端到端數據傳送,並且TCP在應用層可以很容易地用SSL來加強已提供安全服務。但是,TCP卻沒有提供吞吐量服務和定時服務,或者說因特網運輸協議沒有提供這兩種服務。
應用層協議定義
應用層協議(application-layer protocol)
定義了運行在不同端系統上的應用程序進程如何相互傳遞報文。主要有以下的定義:
- 交換的報文類型,例如請求報文和響應報文
- 各種報文類型的語法,如報文中的各個字段及這些字段是如何描述的
- 字段的語義,即這些字段中包含的信息的含義
- 一個進程何時以及如何發送報文,對報文進行響應的規則