这里是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。
• 场景：
  • 远程服务器管理。
  • 数据传输和控制指令必须可靠。

总结

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

---

特性	UDP	TCP
是否可靠	不可靠传输，需应用层处理	可靠传输，提供顺序和重传机制
数据传输方式	面向报文	面向字节流
连接管理	无需连接，开销小	需三次握手建立连接，开销大
时延	低延迟	高延迟
广播/多播支持	支持	不支持
应用场景	实时通信、直播、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 的特点

1. 基于 UDP：

   • KCP 使用 UDP 作为底层传输协议，继承了 UDP 的低延迟和无连接特性。
   • 适合高实时性场景，但克服了原始 UDP 不可靠的问题。

2. 可靠性：

   • KCP 在 UDP 之上实现了类似 TCP 的可靠性特性，比如数据包确认、超时重传等。
   • 确保数据能够完整到达接收端。

3. 流量控制：

   • KCP 使用滑动窗口机制，可以动态调整发送和接收窗口，防止发送方发送过多数据导致网络拥塞。
   • 提供了流量控制的能力，类似于 TCP。

4. 高效：

   • 相较于 TCP 的复杂性，KCP 的实现更加轻量，适合对实时性要求较高的应用。
   • 提供了灵活的拥塞控制算法，可以根据场景调整配置。

5. 快速重传和数据重组：

   • KCP 支持快速重传机制，可以在接收到部分丢失数据包的情况下快速恢复通信。
   • 接收端会对乱序到达的数据包进行重组，确保应用层接收到的数据是完整有序的。

6. 支持自定义优化：

   • KCP 提供了多种参数可供调节，比如超时重传时间、窗口大小等，开发者可以根据实际场景优化性能。

---

KCP 的核心机制

1. 滑动窗口：

   • 发送端和接收端都维护滑动窗口，控制数据的发送和确认。
   • 窗口内的数据可以被发送，但未确认的数据不会被移出窗口。

2. 数据包确认和重传：

   • 每个数据包都有一个唯一的序列号，用于标识顺序。
   • 接收端会发送确认（ACK）给发送端，丢失的包会被发送端检测并重传。

3. 拥塞控制：

   • KCP 并未强制指定拥塞控制算法，但允许开发者根据需要实现自己的控制逻辑。
   • 可以动态调整发送速率，避免过载。

4. 乱序处理：

   • UDP 本身不保证包的顺序，KCP 会对接收到的乱序数据包进行缓存，并在重组后交给上层应用。

5. 快速重传：

   • 如果发现某个包的确认延迟过长，KCP 会主动触发重传，而不是等待超时。

---

KCP 的优势

1. 低延迟：

   • 继承了 UDP 的低延迟特性，适合实时性要求高的场景。

2. 高灵活性：

   • 开发者可以调整 KCP 的参数来满足不同的需求，比如更快的响应时间或更高的吞吐量。

3. 轻量化：

   • 相较于 TCP，KCP 实现简单，性能开销更小。

4. 跨平台：

   • KCP 是一个开源项目（KCP GitHub），可以在多种操作系统和设备上使用。

---

KCP 的缺点

1. 复杂性：

   • KCP 的配置项较多，需要开发者根据场景进行优化，默认配置未必适合所有应用。

2. 缺乏内置的安全性：

   • KCP 本身不提供加密机制，如果需要安全通信，需要配合其他协议（如 DTLS 或 TLS）使用。

3. 流量开销：

   • 由于需要额外的头部信息（如序列号、确认号等）和重传机制，KCP 相较于原生 UDP 会有一定的流量开销。

---

KCP 的应用场景

1. 在线游戏：

   • 游戏对实时性要求高，而 KCP 可以在低延迟的同时保证数据传输的可靠性。

2. 实时音视频：

   • KCP 可以减少音视频传输中的卡顿和延迟问题。

3. 弱网环境：

   • 在网络条件较差的环境下，KCP 的快速重传和灵活配置可以显著提升传输效率。

4. VPN：

   • 一些基于 UDP 的 VPN 协议（如 Shadowsocks 的 KCPTUN）使用了 KCP 作为底层传输协议，以提升传输性能。

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