ToB企服应用市场:ToB评测及商务社交产业平台

标题: UDP/TCP ⑤-KCP || QUIC || 应用场景 [打印本页]

作者: 九天猎人 时间: 2025-1-25 04:30
标题: UDP/TCP ⑤-KCP || QUIC || 应用场景

这里是Themberfue

传输层我们到这就已经差不多进入尾声了，这节我们主要做做扩展~~~

应用场景

通过之前的学习我们知道 UDP 协议和 TCP 协议的一些基本的机制，这两的差别就在于 UDP 是不可靠传输，而 TCP 是可靠传输。
但是，TCP 协议因为要保证可靠传输而引入了一些机制，这些机制会导致数据传输效率大幅下降，尽管 TCP 协议作出了很多优化，但其传输速率依然不敌 UDP 协议。
以是，两个协议应用的场景不尽相同。TCP 协议适合应用在对数据传输速率要求不高的，但是数据必须可靠到达的场景。UDP 协议适合应用在对数据传输速率要求高的，但是可靠性不高的场景。

  UDP应用场景

  实时通信和流媒体

视频直播、语音通话、在线游戏
- 这些场景对时延敏感，须要快速传输数据。
- 丢失少量数据包对整体体验影响不大。
如：一些直播平台、微信语音通话。

广播和多播通信

协议： 广播（Broadcast）和多播（Multicast）通信通常使用UDP。
应用：
- 局域网设备发现（如UPnP）。
- 网络中的节点间状态同步。

简单查询服务

DNS查询
- DNS使用UDP快速响应客户端的域名解析哀求。
- 不须要复杂的握手或连接管理。

轻量级数据传输

如：SNMP（简单网络管理协议）。
场景：监控设备状态的简单数据通信。

在线游戏

游戏场景下，实时性优先于可靠性（如玩家位置或动作信息）。
丢失一些数据不会影响整体体验，耽误过大反而会低落游戏体验。

总结

长处：
- 传输开销小。
- 时延低。
- 支持广播、多播。
缺点：
- 无可靠性保证，丢包、乱序、重复都须要应用层处置惩罚。

  TCP应用场景

  文件传输

协议： FTP、SFTP、HTTP/HTTPS。
场景：
- 文件下载、上传。
- 网站内容加载（如浏览网页）。
- 数据传输必须完备且准确。

电子邮件

协议： SMTP、POP3、IMAP。
场景：
- 邮件的发送、吸取。
- 确保邮件内容不丢失、不重复。

数据库服务

协议： SQL数据库通信（如MySQL、PostgreSQL）。
场景：
- 数据查询和更新。
- 确保数据的一致性和完备性。

HTTPS和安全传输

协议： HTTPS（基于TLS的HTTP）。
场景：
- 电子商务、在线付出、用户登录。
- 确保数据的安全性和可靠性。

即时通讯

协议： 基于TCP的应用层协议（如WebSocket）。
场景：
- 微信聊天、企业内部消息。
- 消息须要按顺序传递且不能丢失。

远程登录和控制

协议： SSH、Telnet。
场景：
- 远程服务器管理。
- 数据传输和控制指令必须可靠。

总结

长处：
- 提供可靠的传输服务。
- 顺序保证和流量控制。
- 适合数据准确性要求高的场景。
缺点：
- 连接创建和管理有额外开销。
- 耽误较高，不适合对时延敏感的场景。

特性UDPTCP是否可靠不可靠传输，需应用层处置惩罚可靠传输，提供顺序和重传机制数据传输方式面向报文面向字节省连接管理无需连接，开销小需三次握手创建连接，开销大时延低耽误高耽误广播/多播支持支持不支持应用场景实时通信、直播、DNS查询、轻量通信文件传输、数据库访问、安全通信

选择UDP： 如果你的场景对耽误敏感，且可以容忍少量数据丢失（如直播、语音通话、在线游戏）。
选择TCP： 如果你的场景须要数据的完备性和可靠性（如文件传输、网页浏览、付出体系）。

中立协议

我们发现，UDP 和 TCP 都太极度了，UDP 发出数据后几乎不作处置惩罚，TCP 发出数据作出的处置惩罚太多了，这将大幅度低落传输效率。
以是，为了分身两者的长处，同时避免两者的缺点，出现了一些折中的协媾和机制。

  1. QUIC

  QUIC（Quick UDP Internet Connections） 是 Google 开发的一种基于 UDP 的传输协议，后来被 IETF 标准化为 HTTP/3 的底子传输协议。它试图联合 TCP 的可靠性和 UDP 的低耽误特点。
  特点

基于 UDP： 继承了 UDP 的低耽误特点，避免了 TCP 的三次握手和慢启动开销。
内置可靠性机制： 提供雷同 TCP 的重传、流量控制和拥塞控制功能。
多路复用： 避免了 TCP 的“队头阻塞”问题，每个连接可以独立传输数据。
内置加密： 逼迫使用 TLS 加密，确保通信安全。
更快的握手： 与传统的 HTTPS/TLS 相比，QUIC 的连接创建速率更快。

应用场景

HTTP/3 是基于 QUIC 的，这意味着将来的网页加载、视频流媒体等都会广泛使用 QUIC。
Google 的服务（如 YouTube、Gmail）已经在大量使用 QUIC。

  2. SCTP

  SCTP（Stream Control Transmission Protocol） 是一种面向消息的传输协议，最初计划用于电信网络，但后来逐渐推广到其他场景。它可以看作是 TCP 和 UDP 的折中。
  特点

可靠性： 像 TCP 一样提供可靠传输，支持数据确认和重传。
多流支持： SCTP 支持多流传输（multi-streaming），可以在一个连接中并行传输多个独立的数据流，避免队头阻塞问题。
多宿支持： 支持多宿主功能（multi-homing），可以绑定多个 IP 地点，提高容灾能力。
面向消息： 像 UDP 一样，SCTP 支持将数据分成离散的消息，而不是像 TCP 那样的字节省。

应用场景

通信网络（如 VoIP 信令）。
数据流场景（如股票交易体系、实时数据传输）。

  3. RUDP

  RUDP（Reliable UDP） 是一种在 UDP 底子上增长可靠性特性的协议。它的目标是为某些须要更高可靠性的场景提供支持，但不须要 TCP 的复杂性。
  特点

基于 UDP： 继承了 UDP 的快速、无连接特性。
可靠性： 增长了简单的重传机制，支持确认和超时重传。
轻量级： 相比 TCP 更简单，适合对可靠性要求不高但须要肯定数据完备性的场景。

应用场景

在线多人游戏。
语音聊天（如 VoIP 的数据通道）。

  4. DCCP

  DCCP（Datagram Congestion Control Protocol） 是一种为流媒体、VoIP 和在线游戏计划的传输协议，它尝试联合 UDP 的低耽误和 TCP 的拥塞控制特性。
  特点

拥塞控制： 提供拥塞控制机制，防止网络拥塞。
面向数据报： 继承了 UDP 的无连接和快速特性。
轻量： 比 TCP 更简单，避免了状态维护的复杂性。

应用场景

视频流媒体。
音频流和实时通信。

  5. WebSocket

  WebSocket 是一种在应用层运行的协议，但它可以视为在 TCP 底子上进行优化的一种折中协议，特别适合须要双向通信的场景。
  特点

基于 TCP： WebSocket 是在 TCP 底子上开发的，提供可靠传输。
长连接： 支持全双工通信，可以在单一连接上持续交换数据。
低耽误： 减少了 HTTP 哀求-响应的开销，适合实时场景。

应用场景

即时通讯（如聊天应用）。
在线协作（如在线文档编辑）。
实时数据更新（如股票行情）。

  6. 自定义协议

  有些应用程序会在 TCP 或 UDP 的底子上实现自己的可靠性机制，计划自定义协议以满足特定需求。
  特点

机动性： 可以根据实际需求计划可靠性、流量控制、数据格式。
适配场景： 比如某些游戏和流媒体服务，会在 UDP 上增长自定义的序列号和确认机制。

应用场景

实时竞技类游戏（如《好汉同盟》《绝地求生》）。
特定范畴的工业通信协议。

总结

如果你须要可靠性但又不能容忍 TCP 的高耽误，可以考虑 QUIC 或 RUDP。
如果须要高可靠性、多路传输，可以选择 SCTP。
对于实时通信或流媒体， DCCP 或 WebSocket 是不错的选择。
自定义协议是特定场景的机动选择，但会增长开发复杂度。

KCP

KCP 是一种基于 UDP 的可靠传输协议，主要用于须要低耽误且具备肯定可靠性的网络通信场景，比如在线游戏、实时音视频等。KCP 由中国程序员开发，因其高效和机动性被广泛使用。

KCP 的特点

基于 UDP：
- KCP 使用 UDP 作为底层传输协议，继承了 UDP 的低耽误和无连接特性。
- 适合高实时性场景，但降服了原始 UDP 不可靠的问题。
可靠性：
- KCP 在 UDP 之上实现了雷同 TCP 的可靠性特性，比如数据包确认、超时重传等。
- 确保数据可以或许完备到达吸取端。
流量控制：
- KCP 使用滑动窗口机制，可以动态调解发送和吸取窗口，防止发送方发送过多数据导致网络拥塞。
- 提供了流量控制的能力，雷同于 TCP。
高效：
- 相较于 TCP 的复杂性，KCP 的实现更加轻量，适合对实时性要求较高的应用。
- 提供了机动的拥塞控制算法，可以根据场景调解配置。
快速重传和数据重组：
- KCP 支持快速重传机制，可以在吸取到部分丢失数据包的环境下快速规复通信。
- 吸取端会对乱序到达的数据包进行重组，确保应用层吸取到的数据是完备有序的。
支持自定义优化：
- KCP 提供了多种参数可供调节，比如超时重传时间、窗口大小等，开发者可以根据实际场景优化性能。

KCP 的焦点机制

滑动窗口：
- 发送端和吸取端都维护滑动窗口，控制数据的发送和确认。
- 窗口内的数据可以被发送，但未确认的数据不会被移出窗口。
数据包确认和重传：
- 每个数据包都有一个唯一的序列号，用于标识顺序。
- 吸取端会发送确认（ACK）给发送端，丢失的包会被发送端检测并重传。
拥塞控制：
- KCP 并未逼迫指定拥塞控制算法，但答应开发者根据须要实现自己的控制逻辑。
- 可以动态调解发送速率，避免过载。
乱序处置惩罚：
- UDP 自己不保证包的顺序，KCP 会对吸取到的乱序数据包进行缓存，并在重组后交给上层应用。
快速重传：
- 如果发现某个包的确认耽误过长，KCP 会自动触发重传，而不是等候超时。

KCP 的优势

低耽误：
- 继承了 UDP 的低耽误特性，适合实时性要求高的场景。
高机动性：
- 开发者可以调解 KCP 的参数来满足差别的需求，比如更快的响应时间或更高的吞吐量。
轻量化：
- 相较于 TCP，KCP 实现简单，性能开销更小。
跨平台：
- KCP 是一个开源项目（KCP GitHub），可以在多种操纵体系和设备上使用。

KCP 的缺点

复杂性：
- KCP 的配置项较多，须要开发者根据场景进行优化，默认配置未必适合所有应用。
缺乏内置的安全性：
- KCP 自己不提供加密机制，如果须要安全通信，须要共同其他协议（如 DTLS 或 TLS）使用。
流量开销：
- 由于须要额外的头部信息（如序列号、确认号等）和重传机制，KCP 相较于原生 UDP 会有肯定的流量开销。

KCP 的应用场景

在线游戏：
- 游戏对实时性要求高，而 KCP 可以在低耽误的同时保证数据传输的可靠性。
实时音视频：
- KCP 可以减少音视频传输中的卡顿和耽误问题。
弱网环境：
- 在网络条件较差的环境下，KCP 的快速重传和机动配置可以显著提升传输效率。
VPN：
- 一些基于 UDP 的 VPN 协议（如 Shadowsocks 的 KCPTUN）使用了 KCP 作为底层传输协议，以提升传输性能。

至此，TCP 和 UDP 协议的讲解到这就竣事了，下节我们将进入更为底层的网络层（IP协议）中。
究竟不知后事怎样，且听下回分解
❤️❤️❤️❤️❤️❤️❤️

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)