TCP 與 UDP 協定

TCP 和 UDP 在網際網路協定簇的傳輸層運行，負責促進網路上裝置之間的資料傳輸。

TCP（傳輸控制協議）是一種面向連接的協議，在發送方和接收方之間建立可靠的通道。

它確保所有資料包都以正確的順序準確傳遞，使其成為資料完整性至關重要的應用程式的理想選擇。

UDP（用戶資料封包協議）是一種無連線協議，無需建立專用的端對端連線即可傳送資料。

它不保證資料包的交付或順序，這減少了開銷並允許更快的傳輸速度。

這使得 UDP 適合比可靠性更重要的速度應用程式。

---

了解 TCP 和 UDP

---

A. 傳輸控制協定（TCP）

面向連線的協定

TCP 是一種面向連接的協議，這意味著在任何資料傳輸開始之前，它需要在發送方和接收方之間建立正式的連接。

此設定過程稱為「三向握手」。

在此握手中，發送方和接收方交換同步 (SYN) 和確認 (ACK) 封包，以就初始序號和視窗大小達成協議。

建立此連線可確保雙方做好通訊準備，為資料交換提供可靠的通道。

可靠的資料傳輸

TCP 的主要優勢之一是能夠保證資料包按照發送的確切順序可靠地傳送。

它透過排序和確認機制來實現這一點：

• 排序：每個位元組的資料都分配有一個序號。

這允許接收者以正確的順序重新組裝資料包，即使它們由於網路路由而未按順序到達。

• 確認：接收者發回對收到的資料包的確認。

如果發送方在一定時間內沒有收到確認，則認為資料包遺失並重新傳輸。

流量控制和擁塞控制

TCP 結合了流量控制和擁塞控制演算法來有效管理資料傳輸：

• 流量控制：此機制可防止發送者過快地用過多資料淹沒接收方。

TCP 使用滑動視窗協議，接收方通告其一次可以接受的資料量（視窗大小）。

傳送者必須遵守此限制，確保資料流暢並防止接收方緩衝區溢位。

• 壅塞控制： TCP 監視網路狀況以偵測網路擁塞。

它使用慢啟動、擁塞避免、快速重傳和快速恢復等演算法來調整資料傳輸速率。

當偵測到封包遺失或延遲（潛在擁塞的跡象）時，發送方會降低傳輸速率以減輕網路壓力。

相反，如果網路暢通，TCP 會逐漸提高傳輸速率以優化吞吐量。

---

B. 用戶資料報協定（UDP）

無連線協定

UDP 是一種無連接協議，這意味著在傳輸資料之前不需要專用的端對端連接。

與透過握手程序建立連線的 TCP 不同，UDP 直接向接收者發送資料包（稱為資料封包），無需事先進行任何通訊設定。

缺乏連線建立減少了初始延遲並允許立即開始資料傳輸。

發送者無需等待接收者的任何確認，使通訊過程簡單且有效率。

無需事先建立連線即可發送數據

• 立即傳輸：由於無需建立連接，資料一旦準備好就可以發送，這對於時間敏感的應用程式至關重要。

• 無握手過程：消除與建立和終止連線相關的開銷，減少延遲。

• 無狀態通訊：每個資料封包都是獨立的，包含路由所需的所有信息，這簡化了協定並減少了網路設備的資源使用。

不可靠但更快的資料傳輸

UDP 提供「不可靠」的服務，在網路術語中意味著：

• 不保證資料包交付：資料封包可能會在傳輸過程中遺失，而不會通知寄件者。

• 無法保證順序：封包可能會亂序到達，因為 UDP 不會對它們重新排序。

• 無糾錯：與 TCP 不同，UDP 不會檢查錯誤或重新傳輸遺失或損壞的資料包。

某些情況下不可靠的優點

• 減少開銷：透過不追蹤封包傳送或處理確認，UDP 減少了透過網路傳送的額外資料量。

• 更快的傳輸：發送方和接收方都需要更少的處理，從而實現更高的吞吐量和更低的延遲。

• 應用程式層級控制：有些應用程式喜歡自己處理可靠性和糾錯，而不是依賴傳輸協定。

低開銷

UDP 的簡約設計有助於降低開銷：

• 較小的報頭大小：UDP 的報頭只有 8 個位元組長，相較之下 TCP 的 20 位元組報頭長。較小的尺寸意味著每個資料包發送的資料較少，從而節省頻寬。

• 簡化處理：更少的功能意味著更少的網路設備和端點的計算工作，這可以提高效能，特別是在高負載下。

• 高效能應用程式的效率：開銷的減少使得 UDP 適合需要快速發送大量資料並且可以容忍一定資料遺失的應用程式。

---

用例範例和實際應用

---

A. TCP 的用例

1. 網頁瀏覽（HTTP/HTTPS）

頁面渲染需要可靠的資料傳輸

網頁瀏覽在很大程度上依賴資料的準確和完整傳輸才能正確呈現網頁。

HTTP 和 HTTPS 協定使用 TCP 來確保網頁的所有元素（例如文字、映像和腳本）均以正確的順序可靠地傳送。

TCP 的錯誤檢查和確認功能可確保重新傳輸遺失或損壞的資料包，防止影像損壞或內容不完整，這對於使用者體驗和功能至關重要。

2. 電子郵件服務（SMTP、IMAP）

確保訊息完整有序的傳遞

像 SMTP（簡單郵件傳輸協定）和 IMAP（網際網路訊息存取協定）這樣的電子郵件協定使用 TCP 來提供可靠的訊息傳輸。

電子郵件通常包含重要資訊和附件，必須完好無損地送達。

TCP 確保電子郵件的所有部分都按正確的順序接收，沒有錯誤，保持通訊的完整性並防止資料遺失，這對於個人和專業通訊至關重要。

---

B. UDP 的用例

1. 即時通訊（VoIP、視訊會議）

優先考慮速度而非可靠性，以減少延遲

IP 語音 (VoIP) 和視訊會議等應用需要最小的延遲，以促進流暢、即時的通訊。

使用 UDP 是因為它允許快速傳輸數據，而無需建立連接或確保資料包傳送的開銷。

雖然 UDP 不能保證所有資料包都到達或按順序排列，但偶爾丟失資料包可能會導致短暫的故障，但不會顯著影響整體會話。

首要任務是減少延遲以維持自然的溝通流程。

3. 串流服務

連續播放時可容忍輕微資料遺失

串流服務，例如即時視訊或音訊串流，使用 UDP 向使用者連續發送資料。

該協定的低開銷允許穩定的資料流，而不會出現與錯誤檢查和重傳相關的延遲。

輕微的資料包遺失可能會導致品質輕微下降，但使用者通常無法察覺。

主要目標是防止緩衝和中斷，提供不間斷的觀看或聆聽體驗。

UDP 使服務能夠優先考慮連續播放而不是完美的資料準確性。

2. 線上遊戲

需要快速資料傳輸以實現即時互動

線上遊戲需要快速、持續的資料交換，以即時反映玩家的行為。

UDP 是首選，因為它提供低延遲通信，這對於響應式遊戲至關重要。

玩家可以體驗即時互動，沒有明顯的延遲。

雖然部分資料包可能會遺失，但遊戲通常會透過頻繁更新遊戲狀態來進行補償，確保無縫體驗。

為了保持遊戲的流暢性，重點是速度而不是絕對可靠性。

---

性能考慮因素

在 TCP 和 UDP 之間進行選擇時，必須考慮每種協定的特性如何影響網路效能。

關鍵因素包括延遲、吞吐量、可靠性以及這些因素如何影響應用程式的功能和使用者體驗。

---

延遲和吞吐量

1. TCP 開銷

確認封包和握手可能會導致延遲

TCP 專為可靠性和有序資料傳輸而設計，這會帶來額外的開銷：

• 三次握手：在資料傳輸開始之前，TCP 需要透過三次握手建立連線。

此過程涉及交換 SYN（同步）和 ACK（確認）封包，增加初始延遲。

• 確認和重傳：建立連線後，TCP 透過要求對收到的資料包進行確認來確保可靠性。

如果未收到確認，TCP 會重新傳送資料。雖然這保證了交付，但可能會導致延遲，尤其是在高延遲網路或長距離中。

• 流量控制和擁塞控制： TCP 根據網路狀況調整資料傳輸速率，以防止擁塞。

雖然有利於網路穩定性，但這些機制會降低擁塞期間的吞吐量，從而影響應用程式效能。

2.UDP效率

減少開銷可降低延遲
UDP 的設計優先考慮速度和效率：

無連線建立： UDP 是無連線的，因此在傳送資料之前不需要握手。

無需初始設定可減少延遲，從而實現即時資料傳輸。

無確認： UDP 不會等待確認或重新傳輸遺失的資料包，從而消除了 TCP 中與這些過程相關的延遲。

最小的協定開銷：憑藉較小的標頭大小和更少的協定機制，UDP 減少了透過網路發送的額外資料量，從而提高了吞吐量並減少了延遲。

B. 可靠性與速度的權衡

一、申請要求

決定速度還是可靠性重要

在 TCP 和 UDP 之間進行選擇取決於應用程式的特定需求：

• 當可靠性至關重要時：文件傳輸、網頁瀏覽和電子郵件服務等應用程式需要完整且準確的資料傳輸。

在這些情況下，TCP 的可靠性特性對於確保資料完整性和順序至關重要。

• 當速度和低延遲至關重要時：即時視訊串流、線上遊戲和 VoIP 等應用程式優先考慮即時資料傳輸而不是完美的可靠性。

在這裡，UDP 的低開銷和更快的傳輸使其成為首選，即使一些資料包在傳輸過程中遺失。

2. 混合方法

在適當的地方使用兩種協定

在某些場景下，TCP 和 UDP 的組合可以最佳化效能：

• 選擇性協定使用： 應用程式可能使用 TCP 來實現某些功能，而使用 UDP 來實現其他功能。

例如，視訊會議應用程式可以使用 UDP 傳輸即時音訊和視訊串流，以最大程度地減少延遲，同時使用 TCP 在應用程式內發送文字訊息或檔案傳輸，以確保可靠的傳輸。

• 基於 UDP 的自訂可靠性機制： 開發人員可以在 UDP 之上實現自己的錯誤檢查和重傳策略。

這種方法可以實現低延遲通信，並在需要時提高可靠性，專門針對應用程式的要求進行客製化。

• 並行連接：有些應用程式同時建立 TCP 和 UDP 連接，適當地利用每種協定的優勢。

---

安全影響

在 TCP 和 UDP 之間進行選擇時，不僅要考慮效能和可靠性，還要考慮安全影響。

每個協定都有可能被惡意行為者利用的固有漏洞。

了解這些漏洞並實施適當的緩解技術對於維護網路安全至關重要。

思考了5秒

V.安全影響

在 TCP 和 UDP 之間進行選擇時，不僅要考慮效能和可靠性，還要考慮安全影響。每個協定都有可能被惡意行為者利用的固有漏洞。了解這些漏洞並實施適當的緩解技術對於維護網路安全至關重要。

A. TCP 安全性問題

1. 漏洞

對 SYN 氾濫攻擊的敏感度

TCP 連線導向的特性需要三向握手（SYN、SYN-ACK、ACK）來在客戶端和伺服器之間建立連線。

在SYN洪水攻擊中，攻擊者透過向伺服器發送大量SYN請求但從未完成握手來利用此機制。

具體而言，攻擊者：

• 發送大量帶有欺騙性 IP 位址的 SYN 封包。

• 伺服器以 SYN-ACK 封包回應，並為每個半開連線分配資源。

• 由於客戶端的最終 ACK 永遠不會到達，這些連線保持半開啟狀態，消耗伺服器的記憶體和處理能力。

結果是合法客戶端無法建立連接，因為伺服器資源不堪重負，導致拒絕服務 (DoS) 情況。

2. 緩解技術

SYN Cookie 的實作

SYN cookie 是一種伺服器端技術，可減輕 SYN 洪氾攻擊，而無需為半開連線提供額外資源。它們的工作原理如下：

當收到 SYN 封包時，伺服器不會分配資源，而是將狀態（例如序號和其他連線參數）編碼到 SYN-ACK 封包的初始序號 (ISN) 欄位中。

如果客戶端回覆ACK封包（完成握手），伺服器可以依照ISN重建原始連線狀態並繼續建立連線。

這種方法允許伺服器處理大量 SYN 請求，而不會使其資源過載，因為它不需要追蹤半開連接。

使用防火牆和入侵防禦系統

可以設定防火牆和入侵防禦系統 (IPS) 來偵測和緩解 SYN 泛洪攻擊：

速率限制：限制來自單一 IP 位址或子網路的 SYN 封包數量可以減少攻擊的影響。

閾值和警報：設定正常 SYN 流量的閾值並在超出時產生警報有助於早期偵測。

過濾欺騙性 IP 位址： 實作入口和出口過濾以封鎖具有偽造來源 IP 位址的封包。

超時調整

調整半開連線的逾時時間可以更快釋放資源：

減少 SYN-RECEIVED 逾時：減少伺服器在斷開半開連接之前等待最終 ACK 的時間。

B. UDP 安全問題

1. 漏洞

容易遭受 DNS 放大等放大攻擊

UDP 的無連接特性和缺乏驗證使其容易受到放大攻擊，攻擊者可以放大針對目標的流量，從而導致分散式拒絕服務 (DDoS)。在 DNS 放大攻擊：

• 攻擊者使用欺騙性來源 IP 位址（受害者的 IP）發送小型 DNS 查詢請求以開啟 DNS 解析器。
• DNS 伺服器以更大的 DNS 回應回應受害者的 IP 位址。
• 放大係數可能很大，因為回應遠大於請求。

類似的放大攻擊可以利用其他基於 UDP 的服務，例如 NTP（網路時間協定）和 SSDP（簡單服務發現協定）。

2. 緩解技術

速率限制

實作速率限制來控制進出網路的流量：

• 限制傳入請求： 設定伺服器每秒回應單一 IP 或子網路的請求數的閾值。
• 出站回應限制：限制伺服器發送回應的速率，以防止其被用作放大器。

強大的濾波機制

採用先進的過濾技術來阻止惡意流量：

• 入口和出口過濾： 在網路邊緣封鎖具有欺騙性 IP 位址的封包，以防止它們進入或離開網路。
• 應用程式層網關：使用代理程式或網關，可以在轉送應用程式層資料之前檢查和驗證應用程式層資料。
• 協定合規性檢查：確保傳入請求符合預期的協定行為，並丟棄格式錯誤或可疑的資料包。 停用未使用的 UDP 服務

透過停用未使用的 UDP 服務來減少攻擊面：

• 關閉不必要的連接埠：關閉在不必要的UDP連接埠上執行的服務。

• 確保開放服務的安全：對於必要的服務，實施身分驗證和存取控制以防止濫用。

• 使用 DNSSEC 和回應速率限制 (RRL)
  對於 DNS 伺服器：

DNSSEC（網域名稱系統安全擴充）：向 DNS 回應新增身分驗證，降低欺騙攻擊的有效性。

回應速率限制：設定DNS伺服器限制回應速率，防止參與放大攻擊。

以上是TCP 與 UDP 協定的詳細內容。更多資訊請關注PHP中文網其他相關文章！