现实生活中 TCP 和 UDP 的例子都有哪些？

Posted 2023-02-16

技术标签:

【中文标题】现实生活中 TCP 和 UDP 的例子都有哪些？【英文标题】：What are examples of TCP and UDP in real life?现实生活中 TCP 和 UDP 的例子有哪些？ 【发布时间】：2011-07-16 20:40:21 【问题描述】：

我知道两者在技术层面上的区别。

但在现实生活中，谁能提供 TCP 和 UDP 的应用（用途）示例（越多越好）来说明区别？

【问题讨论】：

【参考方案1】：

UDP：只要您始终获取所有数据，您就不会太在意任何事情

隧道/***（丢失数据包是正常的 - 隧道协议会处理它）媒体流（丢帧没问题）不管你是否获得每个更新的游戏本地广播机制（在不同机器上运行的同一应用程序相互“发现”）

TCP：几乎所有你必须获取所有传输数据的地方

网络 SSH、FTP、远程登录 SMTP，发送邮件 IMAP/POP，接收邮件

编辑：我不会费心解释这些差异，因为您声明您已经知道并且所有其他答案都解释了它:)

【讨论】：

【参考方案2】：

UDP 正在邮局邮寄一封信。

TCP 正在邮局邮寄一封带有回执的信件，但邮政主管将按邮寄顺序组织信件并仅按顺序投递。

好吧，无论如何，这是一次尝试。

【讨论】：

这实际上是一个绝妙的基本类比。 @bagofmilk 我一直很喜欢它，因为它很快阐明了为什么 TCP 比 UDP“更昂贵”，以及当单个数据包需要重新传输时 TCP 如何受到额外的延迟。感谢您的友好补充。【参考方案3】：

TCP：

万维网 (HTTP) 电子邮件 (SMTP TCP) 文件传输协议 (FTP) 安全外壳 (SSH)

UDP：

域名系统 (DNS) 电影等流媒体应用在线多人游戏 IP 语音 (VoIP) 普通文件传输协议 (TFTP)

【讨论】：

那么这是否意味着当我们使用 youtube 时，Http 连接适用于 UDP？不，这个答案在这一点上是不正确的。 Youtube、Netflix 等都使用 TCP over HTTP（你永远不会真正使用 HTTP over UDP）。我认为@sndu 想说的是，使用视频的流媒体应用程序（如 Skype、Zoom 等）确实使用 UDP - 这是一种不需要或订购所有内容的情况【参考方案4】：

TCP 实时应用：

电子邮件：

原因：假设如果某些数据包（单词/语句）丢失，我们无法理解内容。它应该是可靠的。

UDP 实时应用：

视频流：

* **原因： ***假设如果缺少某些数据包（帧/序列），我们可以理解内容。因为视频是帧的集合。对于 1 秒的视频，应该有 25 帧（图像）。尽管我们可以理解由于我们的想象力而缺少一些帧。这就是为什么 UDP 用于视频流。

【讨论】：

想象力来理解丢失的帧...很好的解释...【参考方案5】：

经典的观点是认为 TCP 是安全的，而 UDP 是不可靠的。

但是当 TCP-IP 协议用于安全关键应用程序时，不推荐使用 TCP，因为它可能因多种原因而因错误而停止。而 UDP 让应用软件处理错误、重传计时器等。

此外，TCP 比 UDP 有更多的处理开销。

目前，UDP 用于飞机控制和飞行仪表，在 ARINC 664 标准中也称为 AFDX（航空电子全双工交换以太网）。在 ARINC 664 中，TCP 是可选的，但 UDP 与为 ARINC 653 标准（民用飞机中的高可靠性控制软件）设计的 RTOS（实时操作系统）一起使用。

有关在 AFDX 中使用 IP 和 UDP 进行实时控制的更多信息，您可以阅读第 27 至 50 页 http://www.afdx.com/pdf/AFDX_Training_October_2010_Full.pdf

【讨论】：

【参考方案6】：

TCP

在得到确认之前，我将不再发送数据。

这个过程很慢

用于安全目的

示例：网络、发送邮件、接收邮件等

UDP

在这里，我对确认不感到头疼。

这个过程更快，但这里的数据可能会丢失。

示例：视频流、在线游戏等

TCP + UDP = SMTP（例如：手机、电话）

【讨论】：

【参考方案7】：

TCP 保证（按顺序）数据包传送。 UDP没有。

TCP - 用于需要所有数据的流量。即html，图片等。 UDP - 用于丢包后不会受到太大影响的流量，例如视频和语音流、在线游戏的某些数据通道等。

【讨论】：

TCP 不保证数据包的传递。如果您发送的东西在到达目的地之前出现问题（停电、路线丢失等），您的数据包将不会被递送。否，但接收方应立即再次请求，正如 TCP 协议中所指定的那样，再次发送数据包的请求对 TCP/IP 堆栈的更高组件是透明的（这不是真的是一堆）。接收方仅要求对检测到的未传递数据包进行重传。如果最后一个要传输的数据包没有被传递（这是丢失路由的最常见情况），接收者没有得到它丢失数据包的线索，所以他不会要求一个。这应该被改写，TCP 保证“按顺序”数据包传递。只有存储和转发协议才能保证交付。是的，它还保证了数据包的有序传递。但是当数据包丢失时，没有发生成功的 TCP 传输。因此，如果您通过 TCP 接收到某些东西，则可以保证您已经全部收到（按顺序），或者传输失败。中间没有。【参考方案8】：

TCP 是一种面向连接的协议，它通过交换机、路由器代理等建立路径或虚拟连接，然后开始任何通信。存在各种机制，如路由 djikstras 最短路径算法来建立虚拟端到端连接。因此，它会在浏览 HTML 和其他页面、进行支付和一般网络应用程序时使用。

UDP 是一种无连接协议——它只是有一个目的地，节点只要尽可能地传递它就可以了。所以数据包乱序到达，沿着不同的路线等是很常见的。因此即时通讯工具和类似软件开发人员认为 UDP 是理想的解决方案。

在现实生活中，如果你想将数据扔到网络中，而不用担心到达所花费的时间，到达的顺序使用 UDP。如果您在开始发送数据包之前想要一条可靠的路径，并且希望您的数据包具有相同的顺序和延迟，请使用 TCP - 我将使用 UDP 用于 Torrent，而 TCP 用于 PayPal！

【讨论】：

【参考方案9】：

当您必须移动大量数据 (> ~1 kB) 并且您需要传送所有数据时，TCP 是合适的。几乎所有在互联网上传输的数据都是通过 TCP 进行的——HTTP、SMTP、BitTorrent、SSH 等，都使用 TCP。

当您有可以承受丢失的小消息并希望尽可能高效地发送它们时，UDP 是合适的。您可能有能力丢失它们的一个原因是，如果它们丢失了，您可以重新发送它们。互联网上的主要示例是 DNS - DNS 由一些小的查询组成，例如“***.com 的 IP 号码是多少？”，并且响应相应地很小。计算机会进行大量此类查询，因此应该高效地进行查询，但如果它们在途中丢失，很容易超时并重新发送。

【讨论】：

媒体流通常使用 UDP - 超过 1kB。而且 DNS 不仅限于 UDP，它只是更常用。 FTP 也使用 UDP，它当然不接受将文件的“部分”作为“ok”。 UDP 的关键是应用程序将检测到丢失的数据包并进行相应的处理。 TCP 丢失的数据包将由网络堆栈处理并重试。对于音频，播放该数据包的时间可能已经过去，因此“相应处理”可能意味着不必担心它。对于 FTP，“相应处理”意味着重新请求该文件块。 @Edwin：FTP 不使用 UDP，它使用 TCP。 TFTP 使用 UDP - 你把它们弄混了吗？ @Erik：媒体流是一个有趣的案例，我没有想到。在那里，您可以承受丢失单个数据包的后果，因为这会导致音频输出暂时下降，但您不能承受整个数据包流延迟，因为这会完全停止输出。【参考方案10】：

TCP 保证数据包的传递和顺序。在为可执行文件等文件重建数据时，顺序几乎与交付一样重要。

UDP 不保证交付或订单。数据包可以按任何顺序到达（或不到达！）。

TCP 的常见用途包括文件传输，其中数据包的完整性至关重要。语音/视频应用程序可以承受丢失一些数据，同时仍保持可接受的质量，因此通常使用 UDP。

【讨论】：

【参考方案11】：

关于上面一些关于有序传递的 cmet 的额外想法......必须澄清的是，目标计算机可能会在线路上接收到乱序的数据包，但目标的 TCP 负责“重新安排”无序数据”，然后将其传递到堆栈的上层。当你说 TCP 保证有序的数据包传递时，这意味着它会以正确的顺序将数据包传递到堆栈的上层。

【讨论】：

【参考方案12】：

SCTP vs TCP vs UDPServices/Features       SCTP        TCP       UDP
Connection-oriented                       yes         yes       no
Full duplex                               yes         yes       yes
Reliable data transfer                    yes         yes       no
Partial-reliable data transfer            optional    no        no
Ordered data delivery                     yes         yes       no
Unordered data delivery                   yes         no        yes
Flow control                              yes         yes       no
Congestion control                        yes         yes       no
ECN capable                               yes         yes       no
Selective ACKs                            yes         optional  no
Preservation of message boundaries        yes         no        yes
Path MTU discovery                        yes         yes       no
Application PDU fragmentation             yes         yes       no
Application PDU bundling                  yes         yes       no
Multistreaming                            yes         no        no
Multihoming                               yes         no        no
Protection against SYN flooding attacks   yes         no        n/a
Allows half-closed connections            no          yes       n/a
Reachability check                        yes         yes       no
Psuedo-header for checksum                no (vtags)  yes       yes
Time wait state                           vtags       4-tuple   n/a

【讨论】：

【参考方案13】：

由于 tcp 的使用与其他答案相比非常简单，我将提到一些有趣的 UDP 用例：

1)DHCP - 动态主机配置协议，用于为连接的设备动态分配 IP 地址和一些其他网络配置。简单来说，该协议允许您只需连接到网线（或 wifi）即可开始使用互联网，无需任何额外配置。 DHCP 使用 UDP 协议。由于设置请求消息是从主机广播的，并且无法与 DHCP 服务器建立 TCP 连接（您不知道它的地址），因此无法使用 TCP 代替。

2)Traceroute - 著名的网络诊断工具，可让您探索您的数据报通过哪条网络路径到达目的地（以及需要多长时间）。默认情况下，它通过将具有不太可能的目标端口号（范围从 33434 到 33534）的 UDP 数据报发送到 ttl（生存时间）字段设置为 1 的目标来工作。当网络中某处的路由器收到这样的数据报时 -它发现数据报已过期。然后，路由器丢弃该数据报并向数据报的源发送一个 ICMP（Internet 控制消息协议）错误消息，指示数据报的 ttl 已过期并包含路由器的名称和 IP 地址。每次主机发送具有越来越高的 TTL 的数据报，从而增加它成功克服的网络部分并从新路由器获得新的 ICMP 消息。当它最终到达它的目的地时（数据报 TTL 足够大以允许它），- 目标主机向源主机发送“目标端口不可达”ICMP 消息。这样，Traceroute 就知道已到达目的地。由于 TCP 保证数据段的传递，因此使用它而不是 UDP 至少效率低下，而 UDP 反过来又允许数据报在没有任何重新发送尝试的情况下被丢弃（重新发送是在更高级别上实现的，如上所述，TTL 会不断增加） .

【讨论】：

【参考方案14】：

TCP：

传输控制协议是一种面向连接的协议，这意味着它需要握手来建立端到端通信。建立连接后，可以通过该连接双向发送用户数据。

可靠——仅在传输层，TCP 管理消息确认、重传和超时。多次尝试传递消息。如果它在途中丢失，服务器将重新请求丢失的部分。在 TCP 中，要么没有丢失数据，要么在多次超时的情况下，连接被丢弃。（但是这种可靠性不包括应用层，在该层仍然需要单独的确认流控制）

Ordered – 如果通过连接按顺序发送两条消息，则第一条消息将首先到达接收应用程序。当数据段以错误的顺序到达时，TCP 缓冲区会延迟乱序数据，直到所有数据都可以正确重新排序并交付给应用程序。

重量级——TCP 需要三个数据包来建立一个套接字连接，然后才能发送任何用户数据。 TCP 处理可靠性和拥塞控制。流式传输——数据以字节流的形式读取，没有区别指示传输到信号消息（段）边界。

TCP的应用

万维网、电子邮件、远程管理和文件传输依赖于 TCP。

UDP ：

用户数据报协议是一种更简单的基于消息的无连接协议。无连接协议不设置专用的端到端连接。通信是通过从源到目的地沿一个方向传输信息来实现的，而无需验证接收器的就绪状态或状态。

不可靠——发送 UDP 消息时，无法知道它是否会到达目的地；它可能会在途中迷路。没有确认、重传或超时的概念。

未排序 – 如果将两条消息发送给同一收件人，则无法预测它们到达的顺序。

轻量级 - 没有消息排序，没有跟踪连接等。它是一个设计在 IP 之上的小型传输层。

数据报——数据包是单独发送的，只有在它们到达时才检查完整性。数据包有明确的边界，在接收时遵守，这意味着接收器套接字上的读取操作将产生原始发送的整个消息。无拥塞控制——UDP 本身不能避免拥塞。拥塞控制措施必须在应用层实施。

广播 - 无连接，UDP 可以广播 - 发送的数据包可以被寻址，以便子网中的所有设备都可以接收。

多播——支持多播操作模式，单个数据报包可以自动路由到大量订阅者，而不会重复。

UDP 的应用

许多关键的 Internet 应用程序都使用 UDP，包括：域名系统 (DNS)，其中查询必须快速且仅由一个请求和一个回复数据包组成，简单网络管理协议 (SNMP)，路由信息协议 (RIP) 和动态主机配置协议 (DHCP)。

语音和视频流量通常使用 UDP 传输。实时视频和音频流协议旨在处理偶尔丢失的数据包，因此只会出现轻微的质量下降，而不是在重新传输丢失的数据包时出现较大的延迟。由于 TCP 和 UDP 在同一个网络上运行，许多企业发现最近来自这些实时应用程序的 UDP 流量增加正在阻碍使用 TCP 的应用程序的性能，例如销售点、会计和数据库系统。当 TCP 检测到数据包丢失时，它将限制其数据速率使用。由于实时应用程序和业务应用程序对企业都很重要，因此开发服务质量解决方案被一些人视为至关重要。

Open*** 等一些 *** 系统可能会使用 UDP，同时在应用程序级别实现可靠连接和错误检查。

【讨论】：

【参考方案15】： TCP：将按有意义的顺序到达那里 UDP：天知道（也许）

【讨论】：

【参考方案16】：

UDP 在游戏或其他点对点设置中得到了广泛应用，因为它速度更快，而且大多数时候您不需要协议本身来确保一切都按原始顺序到达目的地（UDP 不保证数据包交付或交付订单）。

另一方面，Web 流量通过 TCP。（这里我不确定，但我认为这与 HTTP 协议的构建方式有关）

已编辑，因为我在 UDP 上失败了。

【讨论】：

【参考方案17】：

TCP 和 UDP 的真实示例 tcp -> 一个电话、短信或任何特定于目的地的东西 UDP -> FM 无线电频道 (AM)、Wi-Fi。

【讨论】：