首页 > web前端 > js教程 > 正文

TCP 与 UDP 协议

DDD
发布: 2024-11-05 11:06:02
原创
575 人浏览过

TCP 和 UDP 在互联网协议簇的传输层运行,负责促进网络上设备之间的数据传输。

TCP(传输控制协议)是一种面向连接的协议,在发送方和接收方之间建立可靠的通道。

它确保所有数据包都以正确的顺序准确传递,使其成为数据完整性至关重要的应用程序的理想选择。

UDP(用户数据报协议)是一种无连接协议,无需建立专用的端到端连接即可发送数据。

它不保证数据包的交付或顺序,这减少了开销并允许更快的传输速度。

这使得 UDP 适合速度比可靠性更重要的应用程序。


了解 TCP 和 UDP


TCP vs UDP protocol

A. 传输控制协议(TCP)

面向连接的协议

TCP 是一种面向连接的协议,这意味着在任何数据传输开始之前,它需要在发送方和接收方之间建立正式的连接。

此设置过程称为“三向握手”。

在此握手中,发送方和接收方交换同步 (SYN) 和确认 (ACK) 数据包,以就初始序列号和窗口大小达成一致。

建立此连接可确保双方做好通信准备,为数据交换提供可靠的通道。

TCP vs UDP protocol

可靠的数据传输

TCP 的主要优势之一是能够保证数据包按照发送的确切顺序可靠地传送。

它通过排序和确认机制实现这一点:

  • 排序:每个字节的数据都分配有一个序列号。

这允许接收者以正确的顺序重新组装数据包,即使它们由于网络路由而未按顺序到达。

  • 确认:接收方发回对收到的数据包的确认。

如果发送方在一定时间内没有收到确认,则认为数据包丢失并重新传输。

流量控制和拥塞控制

TCP 结合了流量控制和拥塞控制算法来有效管理数据传输:

  • 流量控制:此机制可防止发送方过快地用过多数据淹没接收方。

TCP 使用滑动窗口协议,接收方通告其一次可以接受的数据量(窗口大小)。

发送方必须遵守此限制,确保数据流顺畅并防止接收方缓冲区溢出。

  • 拥塞控制: TCP 监视网络状况以检测网络拥塞。

它使用慢启动、拥塞避免、快速重传和快速恢复等算法来调整数据传输速率。

当检测到数据包丢失或延迟(潜在拥塞的迹象)时,发送方会降低传输速率以减轻网络压力。

相反,如果网络畅通,TCP 会逐渐提高传输速率以优化吞吐量。


TCP vs UDP protocol

B. 用户数据报协议(UDP)

无连接协议

UDP 是一种无连接协议,这意味着在传输数据之前不需要专用的端到端连接。

与通过握手过程建立连接的 TCP 不同,UDP 直接向接收者发送数据包(称为数据报),无需事先进行任何通信设置。

缺乏连接建立减少了初始延迟并允许立即开始数据传输。

发送者无需等待接收者的任何确认,使通信过程简单高效。

无需事先建立连接即可发送数据

  • 立即传输:由于无需建立连接,数据一旦准备好就可以发送,这对于时间敏感的应用程序至关重要。

  • 无握手过程:消除与建立和终止连接相关的开销,减少延迟。

  • 无状态通信:每个数据报都是独立的,包含路由所需的所有信息,这简化了协议并减少了网络设备的资源使用。

不可靠但更快的数据传输

UDP 提供“不可靠”的服务,在网络术语中意味着:

  • 不保证数据包交付:数据报可能会在传输过程中丢失,而不会通知发件人。

  • 无法保证顺序:数据包可能会乱序到达,因为 UDP 不会对它们重新排序。

  • 无纠错:与 TCP 不同,UDP 不会检查错误或重新传输丢失或损坏的数据包。

某些情况下不可靠的优点

  • 减少开销:通过不跟踪数据包传送或处理确认,UDP 减少了通过网络发送的额外数据量。

  • 更快的传输:发送方和接收方都需要更少的处理,从而实现更高的吞吐量和更低的延迟。

  • 应用程序级控制:一些应用程序更喜欢自己处理可靠性和纠错,而不是依赖传输协议。

低开销

UDP 的简约设计有助于降低开销:

  • 较小的报头大小:UDP 的报头只有 8 个字节长,相比之下 TCP 的 20 字节报头长。较小的尺寸意味着每个数据包发送的数据较少,从而节省带宽。

  • 简化处理:更少的功能意味着更少的网络设备和端点的计算工作,这可以提高性能,特别是在高负载下。

  • 高性能应用程序的效率:开销的减少使得 UDP 适合需要快速发送大量数据并且可以容忍一定数据丢失的应用程序。


用例示例和实际应用


TCP vs UDP protocol

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中文网其他相关文章!

来源:dev.to
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板