計算機網路:自頂向下 第二章2.1應用層協議

前言

在第一章中我們大致的了解了互聯網的全貌,我們簡略的提及了兩個主機間通信的程序，讓我們再來回顧一下這個程序，一臺主機向另外一臺主機發送資訊，資訊先經歷自身主機的五層封裝，然后通過物理層的鏈路向路由器或者電路轉換器發送向目標主機，再經歷目標主機的五層拆解，最終用戶得到了你想要發送的資訊，這其中最關鍵的自然是網路的五個層級，自頂向下分別為應用層、傳輸層、網路層、鏈路層、物理層，接第一章中我們大致的了解了整個網路世界的框架，接下來我們需要更加深入的了解每個層級，根據自頂向下的原理，自然而然的我們需要介紹應用層，

在開始之前我們先問自己一個問題，我們為什么需要網路？
回答這個問題的方式十分簡單，想象一下如果我們沒有了網路我們將會怎么樣，斷網的一天，你待在家里，沒法和別人打游戲、發訊息、上網瀏覽資訊… 正是我們需要這些服務，我們才需要網路來幫助我們來實作，這些服務也稱之為網路應用，有趣的網路應用是因特網成功的驅動力，而這些應用處于的層級我們很自然的稱之為應用層，

2.1 應用層協議原理

讓我們來考慮一下假設你有一個極佳的想法，比方說你想要創造一個網路應用能夠讓用戶互相分享自身喜歡的音樂的應用，那么該如何實作呢？你或許需要借助一種編程語言例如：C、C++、JAVA、Python 來撰寫這個應用程式，同時你需要考慮到，這個應用可能需要在不同的系統上來進行運行這可讓人頭大，但是幸運的是，我們不需要寫在網路核心設備如路由器或者鏈路層交換機上運行的軟體，這種設計方式即將應用程式限制在端系統的方法，在第一章中我們知道了分層的概念，在應用層之下是傳輸層，這也意味著你無需理會網路層、鏈路層的相關細節，需要考慮網路層的是傳輸層，以此類推，也就是你想要寫一個應用只需要借助傳輸層的一些功能來幫助你來完成你所需要的所有要求，

2.1.1 網路應用程式體系的結構

網路程式的體系結構明顯不同于網路的體系結構，網路的體系結構是確定的五個層級，而程式的結構設計則隨著程式員的想法而變動，這里介紹兩個主流的框架

1. 客戶——服務器體系結構
2. 對等（P2P）

客戶——服務器結構

在這個架構中，總有一個開著的服務器來回應客戶端，例如最出名的搜索引擎——谷歌，采用的就是這個模式，在這個模式下，兩個瀏覽器間并不直接通信，而是借助服務器來傳輸資訊，這種大型服務器也被稱之為資料中心，因為它必須能夠滿足大量的用戶需求，這也意味著的需要更多的資金，這種模式的優勢體現在只要服務器足夠強大，馬上資料的傳輸將會更加的安全，

P2P

這個模式與上一種模式最大的區別就是無需借助服務器的幫助，應用程式在間斷連接的主機之間直接通信，這些主機被稱為對等方，同時P2P最引人入勝的地方是其自拓展性，例如在一個P2P檔案共享應用中，盡管每個對等方都由于請求檔案產生作業負載，但每個對等方通過向其他對等方分發檔案來為系統增加服務能力，這種模式無需服務器，所有更具有經濟效益，然而在高度非集中式結構，面臨著安全性，性能和可靠性等挑戰，

2.1.2行程通信

在構建網路應用程式前，我們還需要對運行在多個端系統上的程式事如何通信的情況有一個基本的了解，用作業系統的術語來說，進行通信實際上是一個行程（process），那么什么是行程呢，簡單來說就是正在運行的程式，在同一臺主機上運行的不同行程通過行程間的通信機制來相互通信，行程間的相互通信規則則由作業系統來確定，而不同的主機間進行行程的通信的方式則是跨越計算機網路來交換報文來互相通信，下面我們來分析一下兩個主機之間的行程通信，

1. 客戶和服務器的行程
   網路應用的行程一定是成對出現的，這比較好理解，畢竟你需要與別人通信，那么這兩臺主機有什么區別呢？通常我們將發起通信的行程標識為客戶，在會話開始時等待聯系的主機稱之為服務器，

2. 我們知道應用層通過運輸層來完成報文的交換，那具體的程序是怎么樣的呢，通常傳輸層會給應用層提供一個軟體介面我們又稱之為套接字（socket），客戶端的報文放入主機的套接字軟體，隨后服務器的套接字軟體來接受客戶端的報文，套接字是建立于網路應用的可編程介面，因此又稱為應用程式編程介面（Application Programming Interface API），程式員可以控制套接字在應用端的一切，但是在傳輸層幾乎沒有操作空間，所以對于一般的網路編程而言，套接字是作業中最常見的編程作業，

3. 行程尋址
   通信的程序類似與發送郵件，我們必須將自身主機的地址與目的主機中指定接受行程的識別符號在報文中寫清楚，通信才能被正確的連接，在因特網中，主機由IP地址來標識，簡單來說IP地址就是一個32位元的量且它能夠唯一的標識該主機，就像每個人的身份證一樣，而識別符號也叫做埠號，由于服務器需要接受多個客戶端的請求，但是每個客戶端請求的內容可能不同，所以再細致的分為不同的埠號，常見的Web服務器用埠號80來標識，而郵件服務器用埠號25來標識，這些都是約定熟成的，

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

上面我們提到了套接字這個概念，在發送端的應用程式將報文推進套接字，在該套接字的另外一側，運輸層協議負責從接受行程的套接字得到該報文，

但是包括因特網在內的很多網路提供了不止一種的運輸層協議，當開發一個應用時必須選擇一種可用的運輸車協議，該如何做出這種選擇，是我們需要思考的一個很重要的問題，通常我們需要考慮運輸層協議提供的服務，選擇一個最為適合的一個，在服務中每個協議都有其擅長的一部分，我們大體能夠從四個方面對應用服務程式進行分類：可靠的資料傳輸、吞吐量、定時、安全性，下面我們來簡略的來解釋這四個概念，

1. 可靠的資料傳輸
   在第一章中我們知道，分組在計算機網路中由于各種因素可能被丟失，一般像發送郵件這種需求，資料的丟失是難以被接受的，因此為了支持這些應用必須做一下作業來確保由應用程式的一段到另外一端發送的資料正確，如三次握手、四次揮手，有些資料的丟失是可以被允許的，如音頻檔案，所以我們常常看見音樂的下載有無損音質、普通音質這些差別，由于人的耳朵并沒有那么敏感，丟失資料可能會出現一些小干擾，但不是致命的，

2. 吞吐量
   在第一章中我們提及過這個概念，吞吐量（網速）就像是一種資源，我們當然希望吞吐量越大越好，這意味著資料傳輸的速度更快，但是由于資金等方面的因素，我們需要合理的利用這個資源，類似即時通話這型別的應用對于吞吐量的要求就相對較高，

3. 定時
   定時的概念與吞吐量類似，大致意思就是保證資料傳輸在一定的時間范圍內傳輸完成，

4. 安全性
   這個概念從字面上就可以理解，可靠的資料傳輸保證資料的不丟失，而安全性保證了資料的私密性，沒有安全性的保證，資料將會被隨意的竊取，這對于一些機密而言是不可忍受的，但是對于一些隨處可見的資料來說，安全性就沒有那么總要，

以上我們了解了不同的應用，需要應用不同的服務，我們當然希望資料的傳輸更加可靠、更加快速、更加安全，但是情況往往不允許我們魚和熊掌兼得，適當的做出取舍是程式員的必備素養，

2.1.4 因特網提供的運輸服務

在應用層中，主流的協議有兩種TCP、UDP，作為開發者，往往我們的選擇是二者中的其中一個，下面我們來討論一下二者區別，

1. TCP服務
   TCP服務模型中包括了面向連接服務和可靠資料傳輸服務，面向連接的服務，在握手階段完成，在前面的內容中我們簡略的解釋了三次握手，一個TCP連接是雙向的，雙方的行程可以同時進行報文的發送，而結束發送報文時需要斷開連接，至于可靠的資料傳輸服務，可參照上面的解釋來理解，總而言之TCP通過連接提供了更可靠的資料傳輸，
2. UDP服務
   UDP相較于TCP，它僅提供最小的服務且是無連接的，這樣做的好處是，它的程序更加簡單迅速，相對的UDP協議并不保證該報文將到達接受行程，而且到達接受行程的報文也可能是亂序的，

因特網服務中不提供的服務

上面兩種協議我們主要討論了資料的可靠傳輸這方面的需求差異，然而并未提及其他三個方面的內容，這是因為在多年的網路服務中，吞吐量以及定時這兩種協議完成的都十分不錯，這也是用戶更加直觀體驗到的方面，無論那種服務，我們都希望得到更加快速的回應，至于安全性，TCP在應用層提供了SSL來加強安全性，在TCP和UDP中二者都未對資料加密進行處理，而SSL可以看作加強版的TCP，它在應用層幫助TCP完成更好的安全性，

2.1.5 應用層協議

我們剛學習了通過報文發送進套接字并實作網路行程間的互相通信，但是如何構造這些報文？這些報文的各個欄位的含義是什么？行程何時發送這些報文？這些問題的回答需要我們更加深入的了解應用層協議的具體內容，在應用層協議中詳細的定義了這些問題的答復，具體的內容放在后面來講，

2.1.6 本書涉及的網路應用

如今有大量的網路應用被提出，而在本書中將會挑選其中幾個來講解，如Web、檔案傳輸、電子郵件、目錄服務、流式視頻、和P2P，這些同樣會在后文中，提供給大家學習，

總結

在這小節中我們學習了行程間的通信與應用層的結構，以及相應概念，知道了不同的應用需要根據需求來選擇不同的協議，并且大致的了解了協議的內容，當然這中間還有許多細節需要我們來學習，