# Computer Networking — 2.1 Principles of Network Applications

contributed by <[`kaeteyaruyo`](https://github.com/kaeteyaruyo)>

###### tags: `Computer Networking`

假設你有一個新的網路應用程式的點子，這個程式可能可以造福人群、討好你的指導教授（XDD）、讓你大撈一筆，又或是單純開發起來很好玩，不管你想開發這個應用的動機是什麼，都讓我們來看看怎麼把這樣的想法轉換成真正的網路應用程式。

開發網路應用程式的核心概念，就是**寫出可以在多個不同的終端裝置上執行的程式，讓他們藉由網路來進行溝通並達成服務**。例如：網頁應用程式就牽涉到兩個不同的應用程式之間的溝通，一個是跑在使用者的裝置上的瀏覽器，另一個是跑在提供服務的主機上的伺服器，在這個例子中，這兩支程式會長得很不一樣。但另一個例子： P2P 檔案傳輸應用程式，是一支跑在該檔案共享社群中的每一台電腦上的、知道怎麼傳輸檔案的程式，在這個例子中，在每一台電腦中的程式都長得一樣。

所以，開發新的網路應用程式，重點就是要寫出像這樣子可以在不同終端裝置上執行的程式。重點在於，**你不需要寫跑在網路核心中的那些路由器或交換器上的程式**，老實說就算你想寫也沒辦法，因為那些機器執行的協定並不是跑在應用層上，而是跑在更下面的網路協定層中。這樣的基本設計限制了應用程式就是只能跑在終端裝置上，就像 Figure 2.1 當中表示的這樣，而這種設計也使得網路應用程式的開發與佈署變得更快速，催生了更多元的應用出現。

> Figure 2.1 網路應用程式之間的溝通是藉由跑在應用層上的終端裝置傳輸的

## 2.1.1 Network Application Architectures

在開始著手寫程式之前，你需要先對自己的程式架構有概念才行。注意這裡說的**應用程式架構 (application's architecture)** 不是網路協定那個五層的架構 (network architecture)。對應用程式開發者來說，網路架構是訂死的，並且它提供了一些寫應用的人需要用到的介面和功能。但我們說的應用程式架構，是你這個軟體開發者自己設計的，用來決定你寫出來的這些放在不同終端系統上的程式要怎麼互相溝通。一般來說，現代的網路應用程式主要都採用主從式架構 (client-server architecture) 或是對等式架構 (peer-to-peer (P2P) archirtecture) 這兩種其中之一。

> Figure 2.2 (a) 主從式架構 (b) 對等式架構

在**主從式架構**中，一定會有一台不會關機的主機，叫作伺服器 (server)，持續服務從其他主機，也就是客戶端 (client)，所傳來的請求。最經典的例子就是網頁服務，網頁伺服器會持續提供服務從不同客戶端的主機上的瀏覽器發過來的請求。

* 在主從式架構中，各個客戶端之間是不會直接互相溝通的，例如：網頁瀏覽器之間就沒辦法互相傳送訊息
* 伺服器一定要有一個不會變動的、大家都知道的地址，叫 IP 位址（之後會提到），因為伺服器永遠不會關機，他的位址也永遠都不會變，所以無論何時，客戶端都可以傳封包到伺服器的位址
* 基於主從式架構的一些有名的應用服務有：網頁服務、FTP、Telnet、email 等

主從式架構很常出現一個問題，就是單一一台主機沒辦法處理所有客戶端的請求，大流量的網站如果只有一台伺服器，很容易就會被塞爆。所以我們很常會用資料中心 (data center) 來解決這個問題。資料中心就是用很多台主機共同組成的一個強大的虛擬伺服器，很多大公司（像是Google 啊 Facebook 啊 Amazon 那種世界級的）都擁有一到多個資料中心，Google 甚至有 30 - 50 個資料中心。每個資料中心裡面都有數十萬台電腦，這些電腦必須要一直插著電，也需要持續維護，服務供應商還必須要額外支出把這些資料中心連接起來的網路流量的費用。

在**對等式架構**當中就沒有這種需要依賴資料中心裡的專用伺服器的狀況了，資料是在直接互相連接的主機之間進行傳輸的，這些主機被稱作 peers （好像不太會翻譯這個字），他們不是服務供應商所擁有的電腦，通常就只是一般的使用者所擁有的電腦或筆電之類的，廣泛存在於住家、學校還有工作環境中。

* 因為資料傳輸不需要經過專責的伺服器，而是直接在兩台主機之間傳輸，所以才會叫作 peer-to-peer
* 現今有許多傳輸量很大的有名的應用程式，都是基於 P2P 架構的，像是檔案傳輸（BitTorrent 聽過ㄅ）、協同下載加速器 (peer-assisted download acceleration)、網路電話和視訊會議等
* 有些應用服務採用混合式架構，例如：即時通訊的應用程式會有一台伺服器，但伺服器的功能只是用來追蹤各個客戶端的 IP，聊天訊息的傳輸則是直接在兩個客戶端的電腦之間互傳

對等式架構最引人注目的特色就是他有自行擴增的能力 (self-scalability)，比如在檔案傳輸應用的例子中，==每個 peer 雖然在要檔案時都會增加工作量，但藉由這個傳遞檔案給其他 peer 的過程，系統的服務容量也提升了（這句話其實我沒看懂QQ）== 。對等式架構在資源使用上也比較有效率，因為他們沒有主從式架構那一大堆的基本開銷。但對等式架構在安全性、效能和可靠度上是比較有問題的，因為這個架構高度地去中心化。

## 2.1.2 Processes Communicating

除了應用程式架構之外，你也需要對這些被放在不同裝置上的程式該怎麼互相溝通有點基本理解，才能開始開發網路應用程式。如果有兩個被放在同一台電腦上的程序 (process) 需要互相溝通，他們可以直接按照該電腦上的作業系統提供的程序間通訊的功能進行溝通就好了。但在本書中我們要關注的問題是執行在**不同電腦**上（他們可能跑不同的作業系統）的程序之間要怎麼溝通。

兩個執行在不同終端裝置上的程序需要透過網路來交換**訊息 (message)**（這是應用層的封包的專用術語，請參考 [1.5.1](https://hackmd.io/@kaeteyaruyo/computer-networking-1-5#151-Layered-Architecture)）。會有一個專門傳訊息的程序用來把訊息送到網路上；也會有一個專門收訊息的程序用來接收訊息，並且有可能會再傳一個訊息回去作為回覆。Figure 2.1 當中描繪了這個過程。

### Client and Server Processes

網路應用程式就是由一對對透過網路交換訊息的程序組成的。一般來說，我們會把進行通訊的這兩個程序分成客戶端 (client) 和伺服器端 (server)，無論是在主從式架構中還是在對等式架構中都是。

在對等式架構中，一台電腦有可能既是客戶端又是伺服器端。儘管如此，對於任何一個溝通的連線階段 (session)，我們還是會根據以下定義來區分出客戶端和伺服器端：

> 在兩個程序的連現階段中，發起整個通訊的電腦（也就是一開始要求要跟另一個電腦溝通的那一台電腦），被定義為客戶端；而等待被聯絡的那一台電腦，則定義為伺服器端。

舉例來說，在網頁服務中，瀏覽器會是首先發起要求跟網頁伺服器要網頁的人，所以瀏覽器就是客戶端，而網頁伺服器就是伺服器端；在檔案分享服務中，當 Peer A 跟 Peer B 要一個檔案，那 A 就是首先發起通訊的人，所以下載檔案的 A 就是客戶端，而上傳檔案的 B 就是伺服器端。只要不會造成混淆，我們有時候也會用 "client side" 和 "server side" 這樣的術語來進行描述。在本章最後的練習中，我們會把客戶端和伺服器端的程式都練習寫過一遍。

### The Interface Between the Process and the Computer Network

兩個網路應用程式之間需要透過網路來傳輸訊息，而他們使用的介面，就叫作**插座 (socket)**。我們用以下的情境來形容應用程式跟插座之間的關係：應用程式就像是一棟房子，而他的插座就是這棟房子的門。當送信方要傳訊息時，他會把訊息丟出門外，然後預期門外會有負責進行傳輸的基礎建設（郵差之類的）來幫他把這個訊息傳到收信方那邊。收信方收到訊息時，這個訊息也一定要先通過他家的門，才能進到房子裡，此時收信方才會開始處理訊息。

> Figure 2.3 應用程序、網路插座，還有底下的傳輸層協定

Figure 2.3 描繪了插座通訊是怎麼讓兩個程序透過網際網路溝通的（在 Figure 2.3 當中我們假設傳輸層協定是 TCP）。我們可以看到插座是應用層和傳輸層之間的溝通介面，因此又被稱作應用程式與網路之間的**應用程式介面 (Application Programming Interface, API)**。應用程式開發者對於插座在應用層的這一端有完整的操控權，但是對於在傳輸層的那一端就沒有什麼可以操控的了。在傳輸層那一端，開發者頂多只能決定 (1) 要用哪一個傳輸協定，(2) 可能可以調整一些簡單的參數，像是緩衝區大小上限或是區段 (segment) 長度上限等（這我們第三章會提）。一旦傳輸協定決定了，我們就只能使用該協定提供的功能來開發程式了。關於網路插座，我們會在 2.7 節進行更進一步的討論。

### Addressing Processes

就像寄信要在信封上寫收信人地址一樣，電腦要傳輸訊息，當然也要知道收信端的程序的地址。為了要辨識是哪一個程序在收訊息，我們會需要 (1) 收信端主機的位址 (2) 在收信端主機上，可以用來代表收信的程序的一個辨識符，這兩樣資訊。

在網際網路中，主機的位址就是 **IP 位址**，詳細的內容我們會在第四章才提到，現在我們只需要知道 IP 位址就是一個 32 位元長，可以辨識出網路上任何一台主機的辨識符。由於一台主機上可能會同時執行著很多個網路應用程式，因此我們還需要**埠號 (port)** 來辨識出收信端程序（更精確來說，是收信端的插座）。一些有名的網路服務是有固定的埠號的，像是網頁服務通常用 80， email 通常用 25 等等，更多有名的埠號可以在 www.iana.org 查詢到。關於埠號我們會在第三章當中詳細介紹。

## 2.1.3 Transport Services Available to Applications

插座作為應用程式跟傳輸層之間的介面，在應用程式往插座裏面丟了訊息之後，另一頭的傳輸層就有義務把這個訊息送到收信端的插座那邊。

許多網路，包含網際網路，都有提供不只一種的傳輸層協定可以用。在開發應用程式時，你必須要選一種。但要怎麼選呢？通常你必須要去看各個協定的使用說明書，看看他提供了哪些傳輸服務，然後挑一個最適合你的應用程式的來用。這就像你買東西的時候可以選海運或空運一樣，你必須要選也只能選一種方法來送貨，而不同的方法有不同好處（例如海運比較便宜、空運比較快）。

傳輸層協定可以提供給應用程式的服務到底有哪些呢？我們大致上可以根據以下四個面向來給這些服務分類：可靠的資料傳輸、吞吐量、時差保證，還有安全性。

### Reliable Data Transfer

就像我們在[第一章](https://hackmd.io/@kaeteyaruyo/computer-networking-1-4#142-Queuing-Delay-and-Packet-Loss)提到的，封包在傳遞的過程時是有可能會搞丟的，而對於很多網路服務來說，封包遺失可能會造成毀滅性的後果（試想如果你用網路銀行轉帳結果封包搞丟了，銀行沒收到入帳的訊息，你的錢就不見ㄌ...）。因此，我們需要有某種機制來保證封包一定會正確的並完整地傳送到收信端程序。如果某個協定有提供這種機制，那我們就會說他有提供**可靠的資料傳輸 (reliable data transfer)**。傳輸層協定可以提供的一個重要服務就是程序到程序的可靠資料傳輸。如果程式開發者使用了這個協定，那他就可以把訊息丟進插座裏面，然後放一百個心地確信那個資料一定會被送到收信端程序手上，不會出任何錯誤。

如果一個傳輸層協定沒有提供這種功能，那藉由它傳輸的資料就有可能會有一部份遺失。對於某些可以忍受掉包的應用程式來說，使用這種協定是可以接受的。大部分的多媒體應用，像是語音/視訊通話等，一兩個封包掉了是不會怎樣的，頂多就只是造成一點延遲或是掉幀而已。

### Throughput

在第一章我們有提到吞吐量這個概念。由於網路頻寬是由很多程式共享的，這些程式也不是隨時都在溝通，所以吞吐量是會隨著時間波動的。因此，傳輸層協定自然而然就發展出了一種服務，那就是保證可用吞吐量高於某個流量。如果有這樣的服務，那麼應用程式就可以要求傳輸時要保證吞吐量至少有 $r$ bits/sec。這種服務對某些應用來說是有必要的，例如：如果有個網路電話應用將聲音編碼在 32kbps，那這個應用就必須要有 32 kbits/sec 的傳輸速度，使用者才能聽到正常的聲音，否則他就只能轉用更低品質的編碼或是直接放棄通話。像這種對吞吐量有要求的應用程式叫作 **bandwidth-sensitive application**（對頻寬敏感的應用），現代有許多多媒體服務都是這種類型的應用，儘管他們通常也會隨著當前的頻寬來動態調整編碼品質，讓影音得以正常傳輸。

相對於 bandwidth-sensitive application，**elastic applications**（有彈性的應用程式）對於吞吐量沒有特別的要求，不管當前可用吞吐量多大，他們要嘛就是有多少用多少，要嘛就是只用固定的一點點流量。網頁服務、email、檔案傳輸服務等都是這類型的應用。當然，流量是愈多愈好。俗話說的好，沒有人會嫌自己太有錢、太瘦，或是有太多流量！（沒有這句話 XDD）

### Timing

除了吞吐量，傳輸層協定還可以保證傳輸的時間差，這個服務有很多不同的形式，其中一種就是保證每一個送信方傳輸的位元在送出去到抵達收信方之間的時間差不高於 100 毫秒之類的。這個保證對於即時型 (real-time) 服務來說很重要，像是網路電話、線上遊戲、虛擬實境等等（詳見第九章以及 [Gauthier 1999; Ramjee 1994]）。太長的延遲都會造成這些服務用起來不舒服，例如網路電話如果延遲太長，說話的人就總是會需要等很久才會聽到對方的回話；線上遊戲如果延遲太長，就會有閃現或是卡幀的問題；虛擬實境如果延遲太長，使用者動作一下就要等很久物體才會有反應，感覺起來就很不真實。對於非即時應用來說，延遲當然也是愈小愈好，但就沒有嚴格限制時差一定要小於多少的必要。

### Security

最後，傳輸層協定還可以提供跟安全性有關的服務。例如：送信方的傳輸層協定可以先把要送出的訊息加密，然後收信方的傳輸層協定再把收到的訊息解密，才傳給收信方的程式。這樣就算訊息在傳遞的過程中被偷聽了，也不怕訊息內容外洩。除了加密之外，資料完整性 （data integrity，指的是[「確保資訊或資料不被未授權的篡改或在篡改後能夠被迅速發現」](https://zh.wikipedia.org/zh-tw/%E6%95%B0%E6%8D%AE%E5%AE%8C%E6%95%B4%E6%80%A7)） 和終端身份認証也是傳輸層協定可以提供的安全性服務。這些我們在第八章會詳談。

## 2.1.4 Transport Services Provided by the Internet

目前為止我們都只是在想像網路**可能可以**提供什麼樣的傳輸服務而已，該是時候看看真正的例子了。在網際網路（或精確一點說，TCP/IP 網路）當中，有兩種傳輸服務可以提供給應用程式使用，那就是 UDP 和 TCP。當我們在開發應用時，第一件事情就是要從這兩種裡面挑一個，而這兩個協定提供了不同類型的服務。Figure 2.4 展示了幾個不同的應用程式各自的需求。

|應用服務|是否能忍受掉包|對吞吐量的需求|對最大時差是否有要求|
|-|-|-|-|
|**檔案傳輸/下載服務**|不能掉包|沒有特殊需求|沒有要求|
|**Email**|不能掉包|沒有特殊需求|沒有要求|
|**網頁服務**|不能掉包|沒有特殊需求（只會用固定幾 kbps）|沒有要求|
|**網路電話/視訊會議**|可以掉包|音訊: few kbps - 1 Mbps<br>影片: 10 kbps - 5 Mbps|不得超過 100 msec|
|**影音串流**|可以掉包|同上|不能超過數秒|
|**互動式遊戲**|可以掉包|few kbps - 10 kbps|不得超過 100 msec|
|**智慧型手機的聊天服務**|不能掉包|沒有特殊需求|有時有有時沒有（？）|
> Figure 2.4 幾個不同網路應用的需求

### TCP Services

TCP 服務模型包含了連線導向的 (connection-oriented) 服務和可靠的資料傳輸。分別說明如下：

* **連線導向的服務**：TCP 要求要通訊的兩台電腦必須要在應用層服務開始傳遞訊息**之前**，就先交換好傳輸層的控制資訊。這個過程叫作交握 (handshaking)，目的是為了要讓客戶端和伺服器端都準備好接受接下來一連串的封包。一旦交握完成，我們就會說有一個 **TCP 連線**存在於傳輸雙方的插座之間了。這個連線是一個全雙工 (full-duplex) 的連線，意思就是說雙方可以同時傳訊息給對方。一旦傳輸完成，這個連線就必須要被關閉。在第三章我們會進一步探討連線導向服務的細節並研究他是怎麼被實作的。
* **可靠的資料傳輸**：應用程式可以相信 TCP 可以確保他傳送的所有資料都會正確的並且依照正常順序的送到收信端。當一個應用服務送出了一連串的位元組，TCP 可以保證這個資料流會依照相同的順序送到收信的插座，不會有遺失或是重複的位元組出現。

TCP 同時也含有壅塞控制的機制，這個機制是為了整個網際網路的正常運作而設計的，倒不是為了服務特定的傳輸程序。當傳輸雙方之間的網路狀況已經太壅塞了，TCP 的壅塞控制機制就會阻止送信方繼續送資料。我們也會在第三章提到，TCP 壅塞控制也會試圖限制每一個 TCP 連線的傳輸量，以求網路頻寬可以被公平的分配給所有人。

:::info
:memo: **Securing TCP**

不論是 TCP 還是 UDP，他們都沒有提供任何加密的功能 —— 應用層丟了什麼樣的資料進到插座中，這個資料就會原封不動的在網路上流動。所以，舉個例子，如果有人傳送了明文密碼，這個明文密碼就會光溜溜地流過傳輸雙方之間的每一個網路鍊結，並且有可能在任何一個節點被偷聽或是被發現。由於近年來愈來愈多的應用服務有對隱私和其他安全性的需求，網際網路社群因此發展出了一個增強版的 TCP，叫作**安全通訊協定 (Secure Sockets Layer，SSL)**。由 SSL 強化的 TCP 不只有原本的 TCP 有的所有功能，還額外提供了非常嚴謹的端到端安全性服務，包含資料加密、資料完整性，和端點身份認証。我們要再次強調 SSL 並不是一個跟 TCP 和 UDP 同一層的第三個傳輸協定，而是 TCP 的強化功能，而且它是實作在應用層上的。實務上來說，如果一個應用程式需要 SSL 的服務，那他就需要在客戶端和伺服器端都引入 SSL 的程式碼（一些既存的、最佳化過的函式庫和類型）。SSL 有自己的插座介面，跟原本的 TCP 插座長得很像。當應用程式使用了 SSL，他就可以把明文資料傳到 SSL 插座，由 SSL 把資料加密之後，再丟給 TCP 的插座。如此一來資料就可以用密文的形式傳遞到收信端的 TCP 插座，對方的 TCP 插座把密文傳給 SSL 插座後，再由 SSL 進行解密，最後才傳到對方的應用程式中。我們會在第八章當中詳細介紹 SSL。
:::

### UDP Services

UDP 是一個只會提供最基本服務的、輕量化的傳輸協定（好像廉航喔）。在 UDP 當中是沒有連線的 (connectionless) ，所以傳輸雙方在開始傳輸前也就不會有需要進行交握這回事。UDP 也沒有可靠的資料傳輸，也就是說，當你把資料丟進 UDP 的插座，並不會保證這份資料一定會送到對方手上，就算送到了也不保證順序會跟丟出去的順序一樣。

UDP 也沒有什麼壅塞控制機制，所以 UDP 爽用多快的速度把資料丟出去（到網路層）都沒問題。（但端到端之間的吞吐量可能還是會比 UDP 丟出資料的速度還要再少一點，因為網路之間的傳輸容量是有上限的，而且還有可能會塞車。）

### Services Not Provided by Internet Transport Protocols

我們已根據可靠資料傳輸、吞吐量、時差保證，和安全性四個面向來統整過傳輸服務了，TCP 和 UDP 分別提供了哪些呢？我們已經提到 TCP 有可靠傳輸，也可以很簡單地用 SSL 來加強安全性。但顯然我們在上面的敘述中完全沒有提到 跟吞吐量和時差保證 —— 因為這些服務至今網際網路都是沒有提供的。但很顯然那些即時服務還是在現今的網際網路上服務了好幾年，這是因為這些服務都被設計成可以應付沒有任何吞吐量或時差保證的傳輸環境。他們到底用了什麼魔法，我們在第九章會提到。但無論這些設計再聰明，在延遲過大或是吞吐量過低的時候都還是有它的限制。總結來說，現今的網際網路基本上可以提供令人滿意的服務給那些即時應用，但並沒有辦法給出任何有關吞吐量或時差的保證。

|應用服務|應用層協定|底下的傳輸層協定|
|-|-|-|
|**電子郵件**|SMTP [RFC 5321]|TCP|
|**遠端終端機存取**|Telnet [RFC 854]|TCP|
|**網頁服務**|HTTP [RFC 2616]|TCP|
|**檔案傳輸**|FTP [RFC 959]|TCP|
|**多媒體串流**|HTTP (e.g., Youtube)|TCP（居然嗎）|
|**網路電話**|SIP [RFC 3261], RTP [RFC 3550]，或是專有軟體 (e.g., Skype)|UDP or TCP|
> Figure 2.5 一些有名的網際網路服務，他們所使用的應用層協定，還有底下的傳輸層協定

Figure 2.5 條列出了各個有名的網際網路服務所使用的傳輸層協定。Email、遠端終端機、網頁服務，還有檔案傳輸服務都使用了 TCP，他們主要的考量是需要可靠的資料傳輸。相較之下，網路電話可以容忍掉包，但是對於最小的傳輸速率是有要求的，所以他們會選擇使用 UDP，以規避 TCP 的壅塞控制和一些控制封包的基本開銷。但由於有許多的防火牆都會封鎖 UDP 流量，因此他們還是需要 TCP 作為備援，在 UDP 傳輸無法使用的時候改用 TCP。

## 2.1.5 Application-Layer Protocols

現在我們知道應用程式可以透過插座傳訊息給彼此了，可是這些訊息自己本身又長什麼樣子呢？這些訊息中的每一個欄位代表什麼意思？什麼時候應該要傳這些訊息出去？這些問題都是歸應用層協定管的。一個**應用層協定 (application-layer protocol)** 決定了以下幾件事情：

* 傳遞的訊息種類，例如：是請求 (request) 訊息還是回應 (response) 訊息
* 不同類型訊息的語法，例如：有哪些欄位以及每個欄位如何編排
* 每個欄位的語意，也就是每個欄位所代表的意義
* 一套用來決定什麼時候送和怎麼送出和回覆這些訊息的規則

有些應用層協定是描述在 RFC 裡面的，因此屬於公共領域（意思就是說沒有著作權，大家都可以用）。例如：網頁服務用的 HTTP 協定 (HyperText Transfer Protocol [RFC 2616]) 就是一個例子。任何瀏覽器開發者只要遵循 HTTP RFC 的規範，他寫出來的瀏覽器就可以拿到任何一個同樣也遵守 HTTP 規範的網頁伺服器上的網頁。但同時也有一些應用層協定是有專利的，因此就不屬於公共領域。例如： Skype 就是用他們自己專有的應用層協定。

區別「網路應用服務」和「應用層協定」是一件很重要的事，應用層協定只是網路應用服務中的一部份而已（雖然從我們的角度來看是超重要的一部份！）。舉個例子：網頁服務讓使用者可以從網頁伺服器中取得網頁，這個服務包含了網頁的格式 (HTML)、瀏覽器、網頁伺服器，還有 HTTP 傳輸協定。HTTP 只是規定了網頁要怎麼傳輸，所以只是網頁服務的一小部份（更正，很重要的部份！）。再一個例子：電子郵件服務包含了很多個元件，像是 email 伺服器（真的放信的地方）、email 客戶端（讓使用者可以讀信和寫信）、信件的格式，還有定義信件如何傳輸和解讀的應用層協定。最後這個協定叫作 SMTP (Simple Mail Transfer Protocol) [RFC 5321]，他只是電子郵件服務的一小部份（就說了是很重要的部份！）。

（到底多強調笑死 XDD）

## 2.1.6 Network Applications Covered in This Book

每天都有一堆新的網路應用服務正在被開發。與其包羅萬象的介紹一大堆應用，我們選擇聚焦在幾個比較重要且隨處可見的的應用上。在這個章節中，我們一共會介紹五個重要的應用程式：

* 網頁服務：我們首先看網路服務，不只是因為它真的太常見了，也是因為他使用的應用層協定 HTTP 非常的直觀易懂
* 電子郵件：這是網路上的第一個殺手級服務。電子郵件比網頁服務還要更複雜一點，他使用了不只一種的應用層協定
* DNS：這是網際網路的目錄服務，就像電話簿一樣。大部份使用者並不會直接用到 DNS，而是透過其他的應用來執行 DNS 的查詢。DNS 很好地展示了網路核心的功能（網域名稱和網路地址的轉譯）是如何被實作在應用層的
* P2P 檔案傳輸
* 影音串流服務：包含如何使用內容傳遞網路 (Content Distribution Network, CDN) 來傳遞影片。在第九章，我們會更詳細的探討多媒體應用，包含網路電話和視訊會議。

----

[<< 2. Application Layer](https://hackmd.io/@kaeteyaruyo/computer-networking-2) | [目錄](https://hackmd.io/@kaeteyaruyo/computer-networking-index) | [2.2 The Web and HTTP >>](https://hackmd.io/@kaeteyaruyo/computer-networking-2-2)