【計算機網路筆記】2.1 Principles of Network Applications

Hello Guys, I’m LukeTseng. 歡迎你也感謝你點入本篇文章，本系列主要讀本為《Computer Networking: A Top-Down Approach, 8th Edition》，就是計算機網路的聖經，會製作該系列也主要因為修課上會用到。若你喜歡本系列或本文，不妨動動你的手指，為這篇文章按下一顆愛心吧，或是追蹤我的個人公開頁也 Ok。

2.1.1 Network Application Architectures（網路應用程式架構）

在現代網路應用開發中，開發者通常會在以下兩種典範中擇一使用：

  1. 主從式架構（Client-Server Architecture）
  2. 對等式架構（Peer-to-Peer, P2P Architecture）

主從式架構（Client-Server Architecture）

這是目前最常見、也最傳統的架構模式（例如 Web、Email）。

在此架構中會有永遠開啟的主機，稱之為伺服器（Server）。

伺服器會服務其他許多主機的請求，這些主機稱之為客戶端（Client）。

因此主從式架構可以直翻英文解讀成客戶端-伺服器架構。

  • 伺服器（Server）：
    • Always-on：這是一台（或多台）必須全時開機、隨時待命的主機。
    • 固定 IP（Fixed IP Address）：伺服器擁有一個固定的、眾所周知的位址，讓客戶端隨時都能找到它。
    • 服務中心：負責處理來自成千上萬個客戶端的請求。
  • 客戶端（Clients）：
    • 主動發起：負責向伺服器發起通訊。
    • 間歇性連線（Intermittently connected）：客戶端不需要一直開機，也可以隨時動態更換 IP 位址。
    • 互不通訊：在這種架構下，客戶端與客戶端之間不會直接通訊。

現代化的演變：資料中心（Data Center）

早期的 Client-Server 可能只是一台強大的電腦對應多個使用者。

但隨著像 Google、Facebook 這種巨型應用的出現，單一台伺服器根本無法處理數十億的請求。

因此現代 Server 往往不是指「一台電腦」，而是指位於資料中心（Data Center）中的伺服器叢集（Cluster）。

這些資料中心由成千上萬台主機組成，形成一個強大的虛擬伺服器來服務全球用戶。

對等式架構（Peer-to-Peer, P2P Architecture）

這是一種去中心化的架構，最著名的例子就是檔案分享軟體 BitTorrent（對沒錯就是 BT 種子，知道這個的人可能都比較老了，比如我）。

架構特徵：

  • 極少依賴伺服器：P2P 架構幾乎不依賴（或完全不依賴）位於資料中心的專用伺服器。
  • 直接通訊（Direct Communication）：主機與主機之間直接進行對話，這些主機被稱為 Peers（對等端）。
  • 非服務供應商擁有：這些 Peers 通常是使用者的個人電腦、筆電，分佈在家庭或辦公室，而不是由 ISP 或服務商管理的。

優勢：自我擴展性（Self-Scalability）

這是 P2P 最強大的地方。

在 Client-Server 架構中，用戶越多，伺服器的負擔就越重。

而在 P2P 架構中，當一個新的 Peer 加入時，它雖然帶來了新的需求（要下載檔案），但同時也帶來了新的服務能力（它可以上傳檔案給別人）。

成本效益（Cost Effective）問題：因為不需要龐大的伺服器基礎設施，建置成本相對較低。

P2P 的挑戰

雖然 P2P 的架構聽起來蠻棒的，但它面臨三個主要困難：

  1. ISP 友善性（ISP Friendly）：P2P 產生的大量上傳流量可能會對 ISP 的網路造成壓力。
  2. 安全性（Security）：因為高度去中心化，管理和驗證變得非常困難。
  3. 激勵機制（Incentives）：如何說服用戶貢獻頻寬而不是只下載、不上傳（當 Free-rider, 搭便車）是一個難題。

兩大架構比較表

特性主從式架構（Client-Server）對等式架構（P2P）
通訊模式客戶端 ↔ 伺服器Peer ↔ Peer（直接通訊）
伺服器依賴度極高（必須 Always-on）極低（依賴參與的用戶裝置）
可擴展性（Scalability）有限（受限於伺服器／資料中心容量）自我擴展（用戶即資源）
基礎設施成本高（需要維護大型資料中心）低（利用用戶現有硬體）
管理難度較易（集中管理）較難（高度分散、異質性高）
典型應用Web (HTTP), Email, FTPBitTorrent, Skype（早期）, 區塊鏈

2.1.2 Processes Communicating（行程通訊）

首先要區分兩種「溝通」情境：

  1. 同一台主機內溝通：如果兩個行程（Process）在同一台電腦上，它們之間的溝通是由作業系統（Operating System, OS）管理的（例如透過 Pipe 或 Shared Memory），這屬於作業系統的範疇，在本篇計算機網路不討論。
  2. 不同主機之間溝通：當行程位於不同的終端系統（End Systems）時，它們透過交換訊息（Messages）來進行溝通。

簡單來說網路應用程式的本質，就是由分處兩地的行程透過網路交換訊息。

關鍵術語

  • 客戶端與伺服器行程（Client and Server Processes）：
    • 在任何一對通訊的行程中，必須定義誰是誰。
    • Client（客戶端）：負責發起（Initiates）通訊的那一方。
    • Server（伺服器端）：負責等待（Waits）被聯繫的那一方。
    • 註：即使是 P2P 架構，當在下載檔案時，發起請求的是 Client，提供檔案的對方是 Server。在 P2P 中，一個行程可能同時扮演這兩個角色，但在「單次通訊」中，角色是固定的。
  • Socket（插座／套接字）：
    • 這是行程與電腦網路之間的介面（Interface）。
    • 比喻：
      • 如果行程是一棟房子，Socket 就是這棟房子的門。
      • 當想寄信時，你把信推出門外（Socket），剩下的運送工作就交給門外的運輸設施（網際網路）處理。
      • 當信件到達目的地時，它會穿過接收者的門（Socket）進入屋內。
  • API（Application Programming Interface，應用程式設計界面）：
    • Socket 也被稱為應用程式與網路之間的 API，這是開發者唯一能控制的地方。
    • 補充：
      • API 是一組預定義的規則、協定和工具，允許不同的軟體應用程式相互通訊與交換資料。
      • 如同橋樑或服務員，讓開發者無需從頭建立功能，即可利用現有程式碼、系統或第三方服務（如 Google Maps API），實現模組化編程，提升開發效率與系統整合性。

Socket：應用層與傳輸層的邊界

Socket 位於網路協定堆疊的關鍵位置：

層級（Layer）控制者（Controller）權限（Authority）
應用層（Application）開發者完全控制，可決定要傳什麼資料、怎麼編碼。
—Socket（門）—API應用層與傳輸層的溝通介面
傳輸層（Transport）作業系統（OS）有限控制，只能選擇協定類型（TCP 或 UDP）以及設定少數參數（如緩衝區大小），一旦資料推入 Socket，剩下的就由 OS 和網路接管了。

定址（Addressing）：如何找到對方？

如果我們要寄信給某人，需要地址才知道要寄去哪裡。

在網路世界，要讓一個行程（Process）找到另一個行程，需要兩個資訊：

  1. 主機地址（IP Address）：
    • 就像是大樓的地址，IP Address 用來識別網路上的一台特定主機（Host）。
    • 光有 IP 還不夠，因為這台主機上可能同時跑著很多網路程式（Web Server, Mail Server 等），因此需要第二個東西，Port Number。
  2. 埠號（Port Number）：
    • 就像是大樓裡的房間號碼，Port Number 用來識別主機上特定的接收行程（Receiving Process）。
    • 常見例子：
      • Web Server（HTTP）通常使用 Port 80。
      • Mail Server（SMTP）通常使用 Port 25。

要送訊息給對方，必須指定（IP Address, Port Number）這組配對。

2.1.3 Transport Services Available to Applications（應用程式可使用的傳輸服務）

在設計網路應用程式時，必須選擇一個傳輸層協定（在 Internet 中通常是 TCP 或 UDP）。

這個選擇取決於應用程式對服務品質（QoS, Quality of Service）有什麼樣的需求。

核心問題：應用程式在傳輸資料時，最在意什麼？是資料不能掉？還是傳輸速度要穩？或者是不能有延遲？

生活比喻：這就像選擇交通工具一樣，假設現在要從高雄出發到台北。

  • 如果趕時間（Timing），就搭高鐵。
  • 若要運送大量便宜貨物（Cost／Throughput），則走海運或貨運火車。
  • 若要運送易碎貴重物品（Reliability），則找專業快遞。

四大服務分析

  1. 可靠的資料傳輸（Reliable Data Transfer）：
    • 可靠性需求（Reliability）：
      • 定義：保證發送端送出的每一個 bit，都能正確且完整地到達接收端。
      • 例子：文件傳輸、電子郵件 (Email)、網頁瀏覽 (Web)、金融交易，這些應用掉了一個字元都可能導致嚴重後果（例如銀行轉帳金額錯誤）。
    • 容忍遺失應用（Loss-Tolerant Applications）：
      • 定義：可以接受一定程度的資料遺失。
      • 例子：即時多媒體應用（如 YouTube 串流、Discord 視訊等）。
      • 在看影片時，如果掉了一兩個封包，畫面可能只是閃爍一下（Glitch），使用者通常能接受，這比為了重傳資料而導致畫面停頓（Lag）來得好。
  2. 吞吐量（Throughput）：此為關於「頻寬需求」的分類。
    • 頻寬敏感應用（Bandwidth-Sensitive Applications）：
      • 定義：這類應用必須要有保證的傳輸速率才能運作。
      • 例子：網路電話（VoIP）。假設編碼需要 32 kbps，如果網路只能提供 10 kbps，語音就會斷斷續續，甚至根本無法通話，這類應用寧可放棄傳輸，也不要在頻寬不足的情況下勉強運作。
    • 彈性應用（Elastic Applications）：
      • 定義：這類應用非常有彈性，頻寬大就傳快點，頻寬小就傳慢點，怎樣都能活。
      • 例子：電子郵件、檔案下載。不管網速快慢，信終究會寄出去，檔案終究會下載完。
  3. 時程（Timing）：
    • 定義：要求資料必須在嚴格的時間限制內到達。
    • 痛點：對於互動式應用，延遲是致命傷。
    • 例子：
      • 線上遊戲：按下滑鼠開槍，如果 0.5 秒後伺服器才收到，早就被對手打死了。
      • 網路電話：如果講一句話要延遲數百毫秒對方才聽到，對話會變得非常尷尬且難以進行。
  4. 安全性（Security）：
    • 定義：傳輸層能否提供機密性（Confidentiality）、資料完整性（Data Integrity）和端點驗證（End-point Authentication）。
    • 現狀：傳統的 TCP 和 UDP 是沒有加密的，如果不加處理，密碼在網路上就是明文傳輸（Cleartext），任何在中間監聽的人都看得到。
    • 解法：雖然這屬於傳輸層服務的範疇，但在 Internet 中，通常是在應用層使用 SSL/TLS 來強化 TCP。

常見應用程式的需求表

應用程式（Apps）資料遺失（Data Loss）傳輸量（Throughput）時間敏感（Time-Sensitive）
檔案傳輸（File Transfer）不可容忍（No Loss）彈性（Elastic）否（No）
電子郵件（E-mail）不可容忍（No Loss）彈性（Elastic）否（No）
網頁文件（Web Documents）不可容忍（No Loss）彈性（Elastic）否（No）
即時語音／視訊（Real-time Audio/Video）可容忍（Loss-Tolerant）頻寬敏感（需要最小速率）是（100s of msec）
串流影音（Streaming stored audio/video）可容忍（Loss-Tolerant）頻寬敏感是（幾秒鐘的緩衝）
線上遊戲（Online Game）可容忍（Loss-Tolerant）頻寬敏感（只需少量 kbps）是（100s of msec）
即時訊息否（No）彈性（Elastic）是也不是

2.1.4 Transport Services Provided by the Internet（網際網路提供的傳輸服務）

網際網路（以及更一般性地，TCP/IP 網路）提供兩種傳輸層協定給應用程式做使用：

  • UDP（使用者資料包協定，User Datagram Protocol）
  • TCP（傳輸控制協定，Transmission Control Protocol）

作為一名軟體開發者，建立網際網路應用程式時，首先要決定用 TCP 還是 UDP。

TCP（Transmission Control Protocol）

TCP（Transmission Control Protocol）是一個提供全方位服務的協定，如果選擇 TCP，它會提供以下服務：

  1. 連線導向服務（Connection-Oriented Service）
    • 握手（Handshaking）：在真正傳送資料前，客戶端和伺服器必須先交換控制訊息，「打個招呼」確認彼此都在，並準備好接收資料。
    • TCP 連線（TCP Connection）：握手完成後，兩者之間就建立了一條邏輯上的全雙工（Full-duplex）連線，當傳輸結束，這條連線必須被拆除。
  2. 可靠的資料傳輸（Reliable Data Transfer）
    • 保證送達：TCP 保證應用程式送出的所有位元組（Bytes），都會無錯誤、不遺漏、且按順序地到達接收端。
    • 懶人開發者用：對於不想處理掉包、重傳邏輯的開發者來說，用了 TCP 只需專注於應用層邏輯。
  3. 壅塞控制（Congestion Control）
    • 為整體福祉著想：不只是為了你的應用程式好，而是為了整個網路好，當網路變得壅塞時，TCP 會強制勒令發送端降低發送速率。
    • 代價：表示你的應用程式傳輸速度可能會忽快忽慢，受到網路狀況的牽制。
  4. 安全性增強（TCP with TLS）
    • 原生無加密：傳統的 TCP 和 UDP 都是明文傳輸，沒有加密。
    • TLS（Transport Layer Security）：
      • 為了安全，Internet 社群開發了 TLS（以前叫 SSL）。
      • 並非第三種傳輸協定，而是加強版的 TCP。
      • TLS 在應用層實現，提供了加密、資料完整性和端點驗證。

UDP（User Datagram Protocol）

UDP（User Datagram Protocol）是一個「陽春」的協議，它提供的服務非常極簡。

  1. 無連線服務（Connectionless）
    • 沒有握手：UDP 不會先打招呼，發送端隨時想傳就傳，這使得它在建立通訊時沒有延遲。
  2. 不可靠的資料傳輸（Unreliable Data Transfer）
    • UDP 不保證資料會送達。
    • 資料可能會掉包、可能會亂序到達。
    • 如果應用程式選擇 UDP，必須自己處理這些問題，或者接受這些損失。
  3. 無壅塞控制（No Congestion Control）
    • UDP 不會管網路塞不塞車。
    • 發送端可以用它能力所及的最快速度（受限於鏈路頻寬）把資料灌入網路當中。
    • 這對某些即時應用很有吸引力，但也可能導致網路癱瘓。

網際網路傳輸協定沒有提供的服務

上一節提到的四大需求，對比 TCP/UDP 的能力，會發現 Internet 的傳輸層缺乏兩個重要的保證：

  1. 沒有頻寬／吞吐量保證：網際網路無法保證應用程式隨時都有 xx Mbps 的頻寬，頻寬是隨網路流量動態變化的。
  2. 沒有時程保證：網際網路無法保證資料一定能在 xx 毫秒內送達，封包可能會在路由器排隊很久。

雖然 Internet 沒有這些硬性保證，但像 Skype 或 Zoom 這樣的即時應用程式在今天依然運作得很好。

因為現代網路頻寬通常夠大，加上應用層使用了聰明的技術（如緩衝區、自適應編碼）來克服這些限制。

受歡迎的網際網路應用

常見的應用程式都用了什麼協定，以及底層傳輸協定是什麼？

應用應用層協定底層傳輸協定理由
電子郵件（如 Gmail）SMTPTCP信件訊息不能一字不漏，可靠性第一
遠端終端機存取Telnet / SSHTCP指令必須準確送達
網頁HTTP 1.1TCP網頁內容不能缺損
檔案傳輸FTPTCP檔案上傳、下載必須完整
串流多媒體HTTP（如 Youtube）、DASHTCP 或 UDP雖然 UDP 效率較好，但現代串流（如 YouTube, Netflix）多用 HTTP/TCP，因為能穿透防火牆且簡化設計
網路電話SIP、RTP 或私人協定（如 Skype）TCP 或 UDP首選 UDP 以求低延遲，如果 UDP 被防火牆擋住，則退回使用 TCP 作為備案

2.1.5 應用層協定（Application-Layer Protocols）

在網際網路中，應用層協定定義了執行在不同終端系統上的應用程式行程如何相互傳遞訊息。

為什麼需要應用層協定？

  • 如果自己寫 Client-Server，可自己發明一套規則（例如先傳長度，再傳內容）。
  • 但若要寫一個瀏覽器去讀取別人的網站，必須遵守一套共同的標準，這就是協定的用途，確保不同開發者寫出的軟體能互相溝通。

協定定義的四大要素

應用層協定定義了：

  1. 訊息類型（Types of messages）：
    • 定義有哪些種類的訊息。
    • 例如：請求（Request）訊息和回應（Response）訊息。
  2. 訊息語法 (Syntax)：
    • 定義訊息的格式。
    • 例如：有哪些欄位（Fields）？這些欄位怎麼排列？是用冒號分隔，還是用換行分隔？
  3. 訊息語意（Semantics）：
    • 定義欄位中的資訊代表什麼意義。
    • 例如：Status: 200 這個欄位中的 200 代表什麼？（在 HTTP 中代表成功）。
  4. 規則（Rules）：
    • 定義「何時」以及「如何」發送訊息或回應訊息。
    • 例如：收到請求後必須在多久內回應？遇到錯誤該怎麼辦？

技術原理與細節

應用程式 vs. 應用層協定（Application vs. Protocol）

兩者差別：

  • 應用層協定只是應用程式的一部分。
  • 應用程式包含了很多東西，如使用者介面（UI）、內部邏輯、資料庫操作等。

書中舉例：

應用程式（Application）應用層協定（Protocol）其他組成部分
全球資訊網（www, world wide web）HTTP網頁瀏覽器（如 Chrome）、Web 伺服器（如 Apache）、HTML 文件格式
電子郵件（E-mail）SMTP, POP3, IMAP郵件客戶端（如 Outlook／Gmail App）、郵件伺服器

就像 Web 是一個龐大的應用生態系，而 HTTP 只是裡面用來搬運網頁文件的規則。

不能直接說 Web 就是 HTTP，因為 Web 還包含了 HTML、瀏覽器引擎等等這些東西。

公開協定 vs. 專利協定（Open vs. Proprietary Protocols）

在選擇或設計協定時，通常會遇到兩類：

  1. 公開協定（Open Protocols）：
    • 定義：規範被詳細寫在 RFC（Request For Comments）文件中，屬於公共領域。
    • 優點：任何開發者都可以照著 RFC 寫出能互通的軟體。
    • 例子：
      • HTTP（如 Web）
      • SMTP（如 Email）
      • 註：因為 HTTP 是公開的，所以 Chrome 瀏覽器可以打開由 Apache 伺服器架設的網站，即便它們由不同公司開發。
  2. 專利協定（Proprietary Protocols）：
    • 定義：由特定公司私有，不對外公開細節。
    • 目的：通常是為了綁定生態系或保護商業機密。
    • 例子：
      • Skype（早期的 P2P 版本）
      • Zoom
      • 註：要用 Skype 通話，就必須雙方都安裝 Skype 軟體，因為外人不知道它的通訊規則，無法寫出相容的程式。

總整理

網路應用程式的兩大架構

  1. 主從式架構（Client–Server）
    • 核心概念：集中式服務。
    • 特徵：
      • 伺服器必須 Always-on、擁有 固定 IP。
      • 客戶端主動發起請求，彼此之間不直接通訊。
    • 現代演進：單一伺服器 → 資料中心（Data Center）+ 伺服器叢集（Cluster）。
    • 優缺點：
      • 優：管理簡單、集中控制。
      • 缺：可擴展性受限、基礎設施成本高。
    • 應用：Web、Email、FTP
  2. 對等式架構（P2P, Peer-to-Peer）
    • 核心概念：去中心化、使用者即資源。
    • 特徵：
      • Peer 與 Peer 直接通訊。
      • 幾乎不依賴中央伺服器。
    • 最大優勢：自我擴展性（Self-scalability）。
    • 主要挑戰：
      • ISP 壓力。
      • 安全與管理困難。
      • 使用者搭便車（Free-rider）問題。
    • 應用：BitTorrent、早期 Skype、區塊鏈。

行程通訊

觀念

網路應用的本質：不同主機上的行程（Process）透過網路交換訊息。

關鍵角色

  • Client Process：發起通訊。
  • Server Process：等待被聯繫。

即使是 P2P 架構，當在下載檔案時，發起請求的是 Client，提供檔案的對方是 Server。在 P2P 中，一個行程可能同時扮演這兩個角色，但在「單次通訊」中，角色是固定的。

Socket（插座）

  • 角色定位：
    • 行程與網路之間的介面（API）。
    • 位於應用層與傳輸層的邊界。
  • 責任分工：
    • 應用層：資料內容與邏輯（開發者控制）
    • 傳輸層：資料如何送（OS 控制，TCP / UDP）
層級（Layer）控制者（Controller）權限（Authority）
應用層（Application）開發者完全控制，可決定要傳什麼資料、怎麼編碼。
—Socket（門）—API應用層與傳輸層的溝通介面
傳輸層（Transport）作業系統（OS）有限控制，只能選擇協定類型（TCP 或 UDP）以及設定少數參數（如緩衝區大小），一旦資料推入 Socket，剩下的就由 OS 和網路接管了。

定址（Addressing）

所謂定址就是透過 IP 地址找到主機並配合 Port 號鎖定特定程式，以確保資料精準送達目的地的過程。

  • 要讓一個行程（Process）找到另一個行程，需要兩個資訊：
    • IP：主機。
    • Port：主機上的特定行程。

要送訊息給對方，必須指定（IP Address, Port Number）這組配對。

應用程式對傳輸服務的需求

設計應用時，需思考 QoS（Quality of Service），重點包含四項：

  1. 可靠的資料傳輸（Reliable Data Transfer）：
    • 可靠性需求（Reliability）：
      • 定義：保證發送端送出的每一個 bit，都能正確且完整地到達接收端。
      • 例子：文件傳輸、電子郵件 (Email)、網頁瀏覽 (Web)、金融交易。
    • 容忍遺失應用（Loss-Tolerant Applications）：
      • 定義：可以接受一定程度的資料遺失。
      • 例子：即時多媒體應用（如 YouTube 串流、Discord 視訊等）。
  2. 吞吐量（Throughput）：
    • 頻寬敏感應用（Bandwidth-Sensitive Applications）：
      • 定義：這類應用必須要有保證的傳輸速率才能運作。
      • 例子：網路電話（VoIP）。
    • 彈性應用（Elastic Applications）：
      • 定義：這類應用非常有彈性，頻寬大就傳快點，頻寬小就傳慢點，怎樣都能活。
      • 例子：電子郵件、檔案下載。
  3. 時程（Timing）：
    • 定義：要求資料必須在嚴格的時間限制內到達。
    • 痛點：對於互動式應用，延遲是致命傷。
    • 例子：
      • 線上遊戲
      • 網路電話
  4. 安全性（Security）：
    • 定義：傳輸層能否提供機密性（Confidentiality）、資料完整性（Data Integrity）和端點驗證（End-point Authentication）。
    • 現狀：傳統的 TCP 和 UDP 是沒有加密的，如果不加處理，密碼在網路上就是明文傳輸（Cleartext），任何在中間監聽的人都看得到。
    • 解法：雖然這屬於傳輸層服務的範疇，但在 Internet 中，通常是在應用層使用 SSL/TLS 來強化 TCP。

不同應用，優先考量不同需求。

網際網路實際提供的傳輸服務

  • TCP（Transmission Control Protocol）
      1. 連線導向服務（Connection-Oriented Service）
      • 握手（Handshaking）：客戶端和伺服器必須先交換控制訊息。
      • TCP 連線（TCP Connection）：握手完成後，兩者之間就建立了一條邏輯上的全雙工（Full-duplex）連線，當傳輸結束，這條連線必須被拆除。
    1. 可靠的資料傳輸（Reliable Data Transfer）
      • 保證送達：TCP 保證應用程式送出的所有位元組（Bytes），都會無錯誤、不遺漏、且按順序地到達接收端。
      • 懶人開發者用：對於不想處理掉包、重傳邏輯的開發者來說，用了 TCP 只需專注於應用層邏輯。
    2. 壅塞控制（Congestion Control）
      • 為整體福祉著想：不只是為了你的應用程式好，而是為了整個網路好，當網路變得壅塞時，TCP 會強制勒令發送端降低發送速率。
      • 代價：表示你的應用程式傳輸速度可能會忽快忽慢，受到網路狀況的牽制。
    3. 安全性增強（TCP with TLS）
      • 原生無加密：傳統的 TCP 和 UDP 都是明文傳輸，沒有加密。
      • TLS（Transport Layer Security）：
        • 為了安全，Internet 社群開發了 TLS（以前叫 SSL）。
        • 並非第三種傳輸協定，而是加強版的 TCP。
        • TLS 在應用層實現，提供了加密、資料完整性和端點驗證。
  • UDP（User Datagram Protocol）
      1. 無連線服務（Connectionless）
      • 沒有握手：發送端隨時想傳就傳，建立通訊時沒延遲。
    1. 不可靠的資料傳輸（Unreliable Data Transfer）
      • UDP 不保證資料會送達。
      • 資料可能會掉包、可能會亂序到達。
      • 如果應用程式選擇 UDP，必須自己處理這些問題，或者接受這些損失。
    2. 無壅塞控制（No Congestion Control）
      • UDP 不管網路塞不塞車。
      • 發送端可以用它能力所及的最快速度（受限於鏈路頻寬）把資料灌入網路當中。
      • 對某些即時應用很有吸引力，但也可能導致網路癱瘓。

網際網路沒有提供的保證：

  • 頻寬保證
  • 延遲保證

解法通常在應用層（緩衝、自適應編碼）。

應用層協定的角色

為什麼需要應用層協定？

  • 確保不同開發者、不同系統能互通。
  • 沒有協定，就無法跨平台溝通。

協定定義的四大要素：

  1. 訊息類型（Request / Response）
  2. 語法（格式與欄位）
  3. 語意（欄位的意義）
  4. 規則（何時送、如何回）

應用程式 ≠ 協定：

  • 協定只是應用的一部分
  • 例：
    • Web = HTTP + 瀏覽器 + HTML + Server。
    • Email = SMTP / POP3 / IMAP + 郵件系統。

公開 vs 專利協定：

  • 公開協定（RFC）：
    • HTTP、SMTP。
    • 促進互通與生態系。
  • 專利協定：
    • Skype、Zoom。
    • 封閉、生態綁定。