- TCP 提供可靠且有序的傳輸,並具有流量和擁塞控制功能,是網頁、電子郵件和檔案傳輸的理想選擇。
- UDP協定最大限度地減少了開銷和延遲,使其成為線上遊戲和VoIP等應用程式的關鍵。 流 以及 DNS 或 DHCP 等協定。
- 許多服務使用相同的連接埠號,但傳輸方式不同(例如,DNS 使用 53/TCP 和 53/UDP,或 RDP 使用 3389/TCP 和 3389/UDP)。
- TCP 連接埠還是 UDP 連接埠的選擇會影響效能、資料消耗和攻擊面,因此在防火牆中對其進行管理至關重要。

當我們深入研究網路世界時,遲早會遇到這樣一個典型問題: TCP連接埠和UDP連接埠之間究竟有哪些差異? 以及何時使用哪種方式比較合適。雖然乍看之下我們只看到連接埠號碼(80、443、3389、53…),但實際上,網路上傳輸資料的方式有兩種截然不同的途徑,它們會影響傳輸速度。 可靠性 甚至在安保領域也是如此。
本文將冷靜地分析這個問題。 TCP 和 UDP 的工作原理、連接埠的作用以及它們各自使用的協定。它們如何影響瀏覽網頁、玩線上遊戲、進行視訊通話或透過遠端桌面連接等日常活動,以及它們對效能有何影響。 網絡安全 以及防火牆配置。
TCP 和 UDP:兩種不同的資料傳輸方式
在討論港口之前,重要的是要了解… TCP(傳輸控制協定)和UDP(用戶資料報協定)是傳輸層協定。 TCP/IP 模型,它們定義了來源和目標之間的通訊方式。
TCP是一種連線導向的協定在發送資料之前,它會使用眾所周知的「三次握手」(SYN、SYN-ACK、ACK)在發送方和接收方之間建立邏輯通道。然後,它會對資料段進行編號,確保資料段依序到達,偵測錯誤,要求重傳,並根據網路和接收方的容量調整傳輸速度。
另一方面,UDP 是一種無連線協定。這種模式沒有建立連線階段;發送方直接向目的地發送資料報,無需等待確認或追蹤。它不進行資料包排序,不保證送達,也不應用流量或擁塞控制機制。因此,它大大降低了開銷和延遲。
基於此,最大的實際差異在於: TCP優先考慮資料的可靠性和一致性。而 UDP 注重速度和簡潔性。接受資訊在傳輸過程中可能會丟失一部分這一事實。
TCP 或 UDP 連接埠究竟是什麼?
在 TCP 和 UDP 中,連接埠都只是一個簡單的符號。 一個介於 0 到 65535 之間的數字,用於標識資料流應到達哪個服務或應用程式。 在裝置內部,它與 IP 位址一起構成著名的「套接字」(IP:連接埠),應用程式使用該套接字來監聽和發送流量。
當我們談到“TCP連接埠”或“UDP連接埠”時,我們指的不是不同的數字,而是… 與同一港口編號相關的不同類型的運輸例如,DNS 可以使用 53/TCP 和 53/UDP 端口,而從某些版本開始,RDP 可以使用 3389/TCP 和 3389/UDP 連接埠。
編號以以下方式組織: 三級 TCP和UDP的共同用途有明顯的差異:
- 知名埠(0-1023):由 IANA 保留,用於 HTTP (80/TCP)、HTTPS (443/TCP)、FTP (21/TCP) 等標準服務。 SSH (22/TCP)、DNS(53/TCP 和 53/UDP)等。
- 註冊埠 (1024-49151):分配給特定應用程序,例如 MySQL 的 3306/TCP 或許多 OpenVPN 部署中的 1194/UDP。
- 動態或專用連接埠 (49152-65535):客戶端暫時用於短暫會話;它們由作業系統動態分配。
多虧了這種組織方式,單一伺服器可以 同時監聽多個服務 (網頁、電子郵件、資料庫、VPN…)資料流不會混淆,因為每個裝置都佔用自己的連接埠。
TCP 的關鍵特性:可靠度至上
TCP的設計使得 資料完整無誤地到達,且順序與發送順序一致。即使是在 IP 網路上,其設計也是“盡力而為”,不作任何保證。
為了實現這一點,TCP 使用 幾種相當複雜的機制:
- 段編號和確認每個資料段都帶有序號,接收方會傳送確認訊息(ACK)。您可以使用選擇性 ACK 一次驗證多個資料段。
- 校驗所有資料段都帶有校驗和,用於檢測資料損壞;如果校驗失敗,則丟棄該資料段並重新請求。
- 計時器如果經過一定時間仍未收到來自資料段的 ACK,則發送方假定資料遺失並自動重新傳送。
- 重複項目過濾器如果同一個資料段到達兩次,TCP 會根據其編號偵測到重複項並將其丟棄。
此外,TCP實現了 流量控制 基於滑動視窗:接收方宣布其緩衝區可以儲存多少字節,發送方在收到新的 ACK 以「滑動」視窗之前不能超過該限制。
同時,TCP 包括 擁塞控制 它擁有自己的視窗(擁塞視窗),旨在防止網路飽和。如果它偵測到丟包(表示網路擁塞),則會觸發擁塞視窗。 路由器),降低速度;當道路暢通時,以可控制的方式再次提高速度(慢速啟動、避免擁塞和穩定階段)。
同 El Temppo 已經出現 日益先進的壅塞演算法就像早期的太浩湖和里諾一樣,拉斯維加斯,CUBIC(在…中被廣泛使用) Linux)或 BBR,由 Google 更好地利用可用頻寬,同時避免網路過載。
另一個重要的優點是 TCP是全雙工的,並且支援多路復用。資料可以透過相同通道同時傳送和接收,主機可以同時保持與不同目的地或服務的多個開啟的套接字。
TCP 頭部、MSS 和重載
每個 TCP 段都包含一個頭部,該頭部至少佔用 20 位元組(如有更多選項)其中我們發現:
- 始發港及目的港 (來源端口,目的端口)。
- 序號 y 確認編號 (確認)。
- 標誌 例如 SYN、ACK、FIN、RST、URG 等。
- 接待窗口尺寸對流量控制至關重要。
- 校驗 以及可能的選項(例如,視窗縮放)。
最大段大小由下列因素決定: MSS(最大段大小)是在運輸層面定義的。通常計算如下: MSS = MTU − IP 封包頭 − TCP 封包頭在典型的乙太網路(MTU 1500)和最小標頭中,我們說的是 1460 位元組的有用資料。
雖然這個相對較大的頭部會增加開銷,但它允許 TCP 傳輸。 整合所有這些控制機制 這賦予了它很高的可靠性。
建立和關閉 TCP 連線:三次握手和 END
要開始使用 TCP 交換數據,首先需要… 在客戶端和伺服器之間建立邏輯連接經典的流程是三次握手:
- 客戶端發送一個包含以下內容的段落: 標誌 SYN 以及初始序號。
- 伺服器回應 同步確認並標明自己的序號,同時確認客戶的序號。
- 客戶發送最後一個片段,內容如下: ACK 由此,雙方即可開始雙向資料傳輸。
這種序號協商機制使得外部攻擊者難以進行攻擊。 很容易偽造已建立的 TCP 連接但是,如果它位於中間人(MitM),它仍然可以操縱流量。
會話結束時,其中一方發送一段包含以下內容的片段: END對方會回覆 ACK,通常也會發送自己的 FIN,FIN 也必須確認。在某些情況下,可能會出現「半開」連接,即一方已關閉連接,但另一方仍在繼續發送資料。
TCP相關攻擊與漏洞
正是因為這種聯繫, TCP 容易受到 SYN 洪水攻擊而遭受拒絕服務攻擊。攻擊者發送大量偽造的 SYN 段,導致伺服器存在大量半開連接,消耗資源。
為了緩解這些攻擊,通常會採取以下措施: 限制同時連線數 (全球或按IP位址) 依可信任位址範圍篩選 或使用以下技術 SYN cookie這樣一來,在獲得可靠確認之前,資源的實際預留就會被推遲。
另一種經典的攻擊方式是 TCP序號預測如果攻擊者能夠猜到合法主機將使用的值,他們就可以注入看似屬於連接一部分的偽造資料包。為了實現這一點,他們通常會先竊聽兩台可信任電腦之間的流量,估算出編號模式,有時還會對真實主機發動拒絕服務攻擊,使其“靜默”,同時偽造其會話。
一旦連接建立,攻擊者就可以 注入任意數據這可能導致會話終止或目標應用程式出現意外行為。老舊、未修補的系統和設備通常是這些技術的最佳攻擊目標。
什麼是UDP?為什麼它的速度這麼快?
UDP的設計理念有所不同: 以盡可能低的開銷發送資料報幾乎所有控制權都留給了上層。它既不建立預連接,也不進行重新排序、重新傳輸或調節傳輸速率。
發送方只需發送UDP資料封包即可。 UDP 會將封包傳送到目標端口,前提是接收方已開啟監聽套接字。如果出現網路擁塞、接收方速度較慢,或路由器決定丟棄資料包,UDP 都不會採取任何措施來修正這種情況。
它的床頭板很小,只有 8字節包含四個基本欄位:
- 原產港.
- 目的港.
- 資料報長度.
- 校驗 (用於標題和數據)。
正是由於這種簡單性, 大部分資料包都用於有效載荷。這大大提高了效率,尤其是在即時通訊和以最大限度減少延遲為優先事項的環境中。
然而,由於沒有流量或擁塞控制措施, 如果發射器比接收器或網路快得多資料報將開始遺失,而管理這種遺失的責任完全落在應用程式上。
TCP和UDP的實際優缺點
簡而言之,我們可以說: TCP速度較慢,但非常可靠。,而 UDP速度較快,但可靠性較低。讓我們把它放到實際應用案例中來看。
當資料完整性至關重要時,TCP 是理想的選擇: 電子郵件、網頁瀏覽、文件傳輸、遠端管理 數據庫……在所有這些情況下,即使多花幾毫秒時間,接收錯誤或不完整的資訊也是毫無意義的。
UDP 在以即時性為首要考慮的環境中表現出色,例如: 在線遊戲VoIP、視訊通話、直播、DNS、DHCP……在這種情況下,丟掉一個資料包導致影片短暫出現像素化是可以接受的,而不是停止播放等待重新傳輸。
就數據消耗而言, TCP 的開銷也比 UDP 大。它的頭部較大,並且會因確認和重送而產生額外的流量。在實際測試中… VPN 據觀察,對於相同的有用信息,透過 TCP 傳輸的 OpenVPN 可能比透過 UDP 傳輸的 OpenVPN 多消耗幾個百分點的資料。
就純粹的安全性而言,這兩種協定本身都不具備加密或認證功能,儘管 TCP 架構讓惡意流量注入變得更加困難。 多虧了序列追蹤和確認機制。實際上,當我們使用TLS、VPN或加密隧道時,TCP和UDP都依賴更高層的協定來保護內容。
最後, UDP支援多播和廣播。 當然,這使得同時向多個接收者發送相同資料流變得更加容易(視訊會議、向多個客戶端串流、發現協定),而 TCP 由於是嚴格的點對點傳輸,因此無法做到這一點。
TCP和UDP在VPN中的作用
VPN 服務依賴 TCP 或 UDP 協定在客戶端和伺服器之間建立加密隧道。實際上, 大多數現代 VPN 協定都傾向於使用 UDP 協定。 因為它能降低延遲,更好地支援中等程度的丟包情況。
例如,在 OpenVPN 中,您可以選擇以下方式: TCP 或 UDP 隧道使用 UDP 時,大部分可靠性都委託給隧道內的應用程式(通常又是 TCP,例如 HTTP/HTTPS),從而避免了雙層錯誤控制,而雙層錯誤控制只會增加延遲。
這意味著 基於UDP的OpenVPN隧道 可能會丟包,但如果內部傳輸的是HTTP流量(使用TCP),那麼必要時將由內部TCP請求重送。實際結果是,連線安全可靠,應用層穩定,傳輸層速度更快。
WireGuard更進一步, 它完全使用UDP作為傳輸機制。所有複雜性都轉移到其自身的加密和控制邏輯中,從而實現了最短的設定時間和非常快速的漫遊速度,當我們切換網路(例如,從 Wi-Fi 切換到 4G)時,VPN 不會讓人察覺。
然而,在防火牆對UDP限制非常嚴格的環境中(例如某些企業網路),許多VPN被迫… 降低頻率至 TCP 以繞過過濾器和代理但代價是延遲略有增加。
網路上的 TCP 與 UDP 之爭以及向 QUIC 的演進
如今, HTTP 和 HTTPS 幾乎都依賴 TCP。傳統的 HTTP 通常使用 80/TCP 端口,而 HTTPS 使用 443/TCP 端口,並添加了 TLS 來加密通訊。
在HTTP/2之前,情況很清楚: 整個網站都基於TCP協議運作。雖然具有可靠性優勢,但在高丟包連接中也存在延遲和標頭阻塞等問題。
HTTP/3 登場 QUIC 是一種基於 UDP 的傳輸協定。 它整合了 TCP(擁塞控制、錯誤修正、流排序)和 TLS(強制加密)的特性。 QUIC 允許在相同連線上重複使用多個獨立的資料流,從而降低資料包遺失對通訊中任何一部分的影響。
多虧了這一點, 透過 QUIC 協定運行的 HTTP/3 通常能提供更快的載入速度特別是在 手機網絡 或高抖動連接。此外,透過使用UDP,它能更好地克服傳統基礎設施中某些專為TCP設計的瓶頸。
實際服務中的 TCP 和 UDP 連接埠:範例和表格

運輸類型和連接埠號的組合定義了 使用的是哪種應用層協定?一些非常常見的例子:
- 80/TCPHTTP(未加密的網路)。
- 443/TCPHTTPS(使用 TLS 加密的 Web)。
- 21/TCP 和 20/TCPFTP(控制和資料)。
- 22/TCPSSH 和 SFTP。
- 25/TCP,587/TCPSMTP 用於傳送電子郵件。
- 110/TCP,995/TCP:POP3 和 POP3S。
- 143/TCP,993/TCP:IMAP 和 IMAPS。
- 53/UDP 和 53/TCPDNS(透過 UDP 進行快速查詢,透過 TCP 進行區域傳輸)。
- 67/UDP 和 68/UDPDHCP客戶端/伺服器。
- 123/UDPNTP,時間同步。
- 161/UDPSNMP。
- 445/TCP用於檔案共用的 Microsoft SMB/CIFS。
- 554/TCP/UDP:RTSP 用於流控制。
- 631/TCP/UDP:IPP(網路印刷)。
知名註冊港口的完整清單非常詳盡,但這足以表明: TCP通常在關鍵和以事務為導向的應用程式中佔據主導地位。而 UDP規則應用於發現、串流或輕量級控制協定。.
RDP:支援 TCP、UDP 還是兩者都支援?
El 遠端桌面協定 (RDP) 微軟的這項服務允許您連接到另一台計算機,就像您坐在它的螢幕前一樣。其工作原理是:遠端主機向客戶端發送壓縮後的桌面影像,客戶端則接收來自遠端主機的鍵盤和滑鼠輸入。
傳統上,RDP 一直使用 埠 3389/TCP 作為主要傳輸方式,利用 TCP 的可靠性來確保每個螢幕更新、點擊和控制資料包都能正確、按順序到達。
自 RDP 8.0 起,該協定也可以使用 3389/UDP 連接埠用於優化效能通常情況下,用戶端會先嘗試建立 UDP 通道(因為其延遲較低且頻寬較高),如果由於網路限製而無法建立 UDP 通道,則會回退到經典的 TCP 通道。
這種混合方法允許 RDP 大部分圖形資料透過UDP發送。在這種情況下,丟失幾個幀幾乎察覺不到,必要時可以將 TCP 保留用於傳輸絕對關鍵的資訊。在延遲較高或訊號遺失較多的網路中,效能提升可能非常顯著。
如何在 Windows 上為 RDP 開啟 TCP 和 UDP 連接埠
要使從外部建立的 RDP 會話正常運作,主機的防火牆必須 允許連接埠 3389 上的入站流量如果想要利用現代最佳化技術,TCP 和 UDP 都是必不可少的;如果出現問題,建議檢查… 阻止 RDP 的網路策略.
En Windows中, 基本設置 來自防火牆 Windows Defender的 包括:
- 進入 控制台 > 系統與安全性 > Windows Defender防火牆 開啟高級設定。
- 創建一個 新增類型為「連接埠」的入站規則選擇 TCP 並指定 3389 為具體的本機連接埠。
- 選擇“允許連線”,將其套用至必要的設定檔(網域、私有、公用),並賦予一個描述性名稱,例如“RDP TCP 3389”。
- 重複此過程 UDP 在同一連接埠 3389 上,或使用另一個名稱,例如“RDP UDP 3389”。
- 確認兩條規則均已啟用,並從遠端用戶端測試連線。
就安全性而言,除了開放連接埠之外,這一點至關重要。 使用強密碼, 啟用 網路級認證 (NLA) 確保只有經過驗證的使用者才能登入圖形會話,限制哪些帳戶具有遠端存取權限,並保持系統始終處於最新狀態,以防止 RDP 服務出現漏洞。
TCP連接埠:安全性、風險和最佳實踐
任何暴露在網際網路上的 TCP 連接埠都會變成 可能的攻擊途徑攻擊者會自動掃描整個 IP 位址範圍,尋找開放端口(使用 Nmap 等工具),一旦偵測到開放端口,就會測試已知漏洞或進行暴力破解攻擊。
高度敏感的服務,例如 SSH(22/TCP)、RDP(3389/TCP)、SMB(445/TCP)或資料庫 這些是優先目標,因為一旦這些目標出現故障,就可能導致直接存取內部網路或關鍵資料。
為了減少攻擊面,建議應用以下原則: 連接埠最低權限只打開絕對必要的程序,盡可能透過 IP 或 VPN 限制訪問,關閉或過濾所有不使用的程序。
這也是個好主意 將網路劃分為多個區域 (用戶區域網路、伺服器DMZ、管理網路等),並使用內部防火牆規則隔離關鍵服務。這樣,即使攻擊者攻破了一台機器,也很難橫向移動到其他敏感系統。
使用EL 監控和日誌記錄工具 它可以偵測連接埠中的異常模式(掃描、大量失敗嘗試、來自不尋常國家的連接),並在事件升級之前觸發警報。
最後,建議進行以下操作: 定期港口審計 使用外部和內部掃描儀,並記錄每個掃描器上正在監聽的服務。這有助於識別過時的應用程式、被遺忘的服務或應該停用的危險預設設定。
TCP 和 UDP 連接埠之間的效能差異
當我們比較透過 TCP 連接埠和 UDP 連接埠傳輸的流量時,我們真正測量的是 兩種傳輸協定在不同條件下的行為 網路狀況.
TCP憑藉其錯誤控制與擁塞控制機制,往往 當偵測到訊號遺失或飽和時,減速優先保證所有內容正確到達,而不是快速到達。在網路擁塞或高延遲的情況下,這可能會導致載入時間延長。 下載 靈活性較差。
UDP 不會因為壅塞而停止運作: 如果路徑擁塞,路由器會直接丟棄資料包。由於沒有自動中繼,通訊仍然流暢,但存在資訊缺口,應用程式必須對其進行管理(例如,透過緩衝或自身的糾錯)。
在利用 VPN 和跨越較大地理距離進行的測試中,觀察到: 透過UDP協定使用OpenVPN通常比透過TCP協定使用OpenVPN速度快得多。隨著網路狀況惡化,這種差異會變得更加明顯。這既是由於資料包頭部變短,也是由於缺少持續的確認(ACK)和重傳機制。
這也會對以下方面產生影響: 數據消耗由於更重的報頭和額外的控制訊息,TCP 傳輸每 MB 有效資料會消耗更多頻寬。對於有流量限制的行動網路連線來說,這在月底可能會造成顯著的成本差異。
除了 TCP 和 UDP 之外的其他傳輸協定
儘管實際上幾乎所有的互聯網都與 TCP 和 UDP 作為基礎還有其他一些傳輸協定是為特定用例設計的。
其中之一是 SCTP(串流控制傳輸協定)它結合了 TCP 和 UDP 的特性:它提供可靠有序的傳輸,同時允許在同一連接中存在多個獨立的資料流。它被廣泛應用於… 先進的電信和 VoIP 訊號與傳統 TCP 相比,它能降低延遲。
另一個是 DCCP(資料封包擁塞控制協定)它保留了UDP的離線風格,但融入了 綜合擁塞控制專為即時多媒體應用而設計,在這種應用中,丟包比引入過多的延遲要好。
也是 RDP(可靠數據協定)重點關注軍事和科學環境,並且,正如前面提到的, QUIC它依賴 UDP,但在單一層中實現了可靠性、多路復用和加密,是 HTTP/3 的基礎。
儘管它具有技術優勢,但現實情況是: 新協議的大規模採用十分複雜。路由器、防火牆等整個生態系統 OS 應用程式針對 TCP 和 UDP 進行了最佳化,更改這種底層架構需要投入大量精力、成本和風險。此外,許多防火牆預設會阻止一些不常用的協議,而 TCP 80/443 連接埠流量和大量的 UDP 流量幾乎總是被允許的。
理解透徹 TCP 和 UDP 連接埠的工作原理,哪些服務依賴它們,以及它們對效能和安全性有何影響。 這使我們能夠做出明智的決定:何時值得犧牲一些速度來獲得可靠性,何時使用 UDP 來減少延遲有利,在防火牆中打開或關閉哪些端口,或者在 VPN 或伺服器中調整哪些參數以確保我們的網路平穩運行並儘可能不受攻擊。
對字節世界和一般技術充滿熱情的作家。我喜歡透過寫作分享我的知識,這就是我在這個部落格中要做的,向您展示有關小工具、軟體、硬體、技術趨勢等的所有最有趣的事情。我的目標是幫助您以簡單有趣的方式暢遊數位世界。
