现实生活中有哪些TCP和UDP实例?


73

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

但是在现实生活中,谁能提供TCP和UDP应用程序(用法)的示例(越多越好)以证明两者之间的区别?

Answers:


144

UDP:如果您总是获得所有数据,则无需过多关注

  • 隧道/ VPN(丢失的数据包可以-隧道协议可以解决)
  • 媒体流(丢帧是可以的)
  • 如果你不关心游戏的每个更新
  • 本地广播机制(在不同计算机上运行的同一应用程序彼此“发现”)

TCP:几乎所有需要获取所有传输数据的地方

  • 网页
  • SSH,FTP,远程登录
  • SMTP,发送邮件
  • IMAP / POP,接收邮件

编辑:我不会打扰解释差异,因为您声明您已经知道并且其他答案仍然可以解释它:)


43

UDP正在邮局寄一封信。

TCP正在邮局邮寄带有回执的信件,但邮局主管将按邮寄顺序组织信件,并仅按顺序发送。

好吧,无论如何都是尝试。


1
这实际上是一个出色的基本类比。
bagofmilk

5
@bagofmilk我一直很喜欢它,因为它可以迅速阐明为什么TCP比UDP“更昂贵”,以及当单个数据包需要重传时,TCP如何受到附加的延迟。感谢您的补充。
Edwin Buck

14

TCP

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

UDP

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

2
难道这意味着当我们使用youtube时Http连接可以使用UDP吗?
学习者

9

经典观点是将TCP视为安全,将UDP视为不可靠。

但是,在安全关键型应用程序中使用TCP-IP协议时,不建议使用TCP,因为它可能由于多种原因而在出错时停止。UDP使应用程序软件可以处理错误,重传计时器等。

而且,TCP比UDP具有更多的处理开销。

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

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


8

TCP的实时应用程序:

电子邮件:

原因:假设如果缺少某些数据包(单词/语句),我们将无法理解其内容。它应该是可靠的。

UDP的实时应用程序:

视频流:

* **原因: ***如果缺少某些数据包(帧/序列),我们可以理解其内容。由于视频是帧的集合。一秒钟的视频应该有25帧(图像)。即使我们能理解由于我们的想象力技巧,有些帧丢失了。这就是为什么UDP用于视频流的原因。


3
想象力技巧,以了解丢失的帧...很好的解释...
SK Venkat

7

TCP协议

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

这个过程很慢

用于安全目的

例如:网络,发送邮件,接收邮件等

UDP协议

在这里,我毫不犹豫地表示感谢。

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

例如:视频流,在线游戏等

TCP + UDP = SMTP(例如:移动电话)


6

TCP保证(按顺序)分组传送。UDP不会。

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


2
TCP不能保证数据包的传递。如果您在到达目的地之前发送了某些东西而出了点问题(断电,路由丢失等),则说明您的数据包将无法发送。
埃德温·巴克

1
否,但是接收者应立即按照TCP协议中的说明再次请求它,因此再次发送数据包的请求对于TCP / IP堆栈(不是真正的堆栈)的较高组件是透明的。
AnthonyVallée-Dubois

1
接收方仅要求在检测到的未送达数据包上进行重发。如果没有发送最后一个要发送的数据包(这是最常见的路由丢失情况),则不会为接收方提供丢失数据包的线索,因此他不会要求接收。
埃德温·巴克

1
这应该改写,TCP保证“按顺序”发送数据包。仅存储和转发协议会尝试保证交付。
埃德温·巴克

是的,它还保证按顺序发送数据包。但是,缺少数据包时,尚未发生成功的TCP传输。因此,如果您已经通过TCP收到了某些信息,则可以确保已全部收到(按顺序),或者传输失败。两者之间没有。
边缘

4

TCP是一种面向连接的协议,它通过交换机,路由器代理等一路建立路径或虚拟连接,然后开始任何通信。存在诸如路由djikstras最短路径算法之类的各种机制来建立虚拟端到端连接。因此,它发现自己在浏览HTML和其他页面时通常使用,从而进行付款和Web应用程序。

UDP是无连接协议-它仅具有目的地,而节点则尽可能地将其传递。因此,数据包乱序,沿各种路径到达等情况很常见。因此,即时通讯程序和类似的软件开发人员认为UDP是理想的解决方案。

在现实生活中,如果您想将数据扔到网上,而不必担心到达时间,则到达顺序使用UDP。如果在开始丢包之前想要一个固定的路径,并且希望数据包使用相同的顺序和等待时间,请使用TCP-我将对Torrent使用UDP,对PayPal使用TCP!


2

当您必须移动大量数据(>〜1 kB),并且需要将所有数据都交付时,TCP是合适的。几乎所有通过Internet传输的数据都是通过TCP来实现的-HTTP,SMTP,BitTorrent,SSH等均使用TCP。

当您有可能丢失的小消息并且希望尽可能高效地发送它们时,UDP是合适的。您有能力承受损失的原因之一是,如果它们丢失,您可以重新发送。互联网上的主要示例是DNS-DNS由一些小的查询组成,例如“ stackoverflow.com的IP地址是什么?”之类的内容,并且响应也相应较小。计算机会进行很多此类查询,因此应该高效地进行查询,但是如果它们在途中丢失,则很容易超时并重新发送它们。


媒体流通常使用UDP-超过1kB。DNS不仅限于UDP,它更常用。
Erik

FTP也使用UDP,并且它当然不接受将文件的“一部分”作为“确定”。UDP的关键是应用程序将检测丢失的数据包并进行相应的处理。对于TCP,丢失的数据包将由网络堆栈处理并重试。对于音频,播放该数据包的时间可能已经过去,因此“相应地处理”可能意味着不必担心它。对于FTP,“相应处理”意味着重新询问该文件块。
埃德温·巴克

1
@Edwin:FTP不使用UDP,它使用TCP。TFTP使用UDP-是否将它们混在一起?
汤姆·安德森

@Erik:媒体流是一个有趣的案例,我没有想到。在那里,您可以承受丢失单个数据包的风险,因为这会导致音频输出的瞬时下降,但是您不能承受延迟整个数据包流的速度,因为那样会使输出完全停止。
汤姆·安德森

2

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

UDP不保证传送NOR顺序。数据包可以以任何顺序到达(或不到达!)。

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


2

关于上面讨论的有序交付的某些注释,还有另一种想法。...必须澄清的是,目标计算机可能会从网络上无序接收数据包,但目标计算机上的TCP负责“重新安排数据包”。 -order数据”,然后再传递到堆栈的上层。当您说TCP保证有序的数据包传送时,这意味着它将以正确的顺序将数据包传送到堆栈的上层。


2
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

1
  • TCP:将以有意义的顺序到达那里
  • UDP:上帝知道(也许)

1

由于tcp的用法与其他答案非常直接,因此我将提及一些有趣的UDP用例:

1)DHCP-动态主机配置协议,用于向连接设备动态分配IP地址和其他一些网络配置。简而言之,该协议允许您仅连接到网络电缆(或wifi)并开始使用Internet,而无需任何其他配置。DHCP使用UDP协议。由于设置请求消息是从主机广播的,因此无法与DHCP服务器建立TCP连接(您不知道它的地址),因此无法使用TCP。

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


0

UDP在游戏或其他点对点设置中得到了广泛应用,因为它速度更快,而且在大多数情况下,您不需要协议本身即可确保一切都按原始顺序到达目的地(UDP不保证数据包的传递或交货单)。

另一方面,Web通信是通过TCP进行的。(我不确定在这里,但我认为这与HTTP协议的构建方式有关)

编辑,因为我在UDP上失败。


0

TCP和UDP tcp的真实示例->电话,短信或目标UDP特有的任何内容-> FM无线电频道(AM),Wi-Fi。


3
我认为您的例子根本不是很好。SMS更像是UDP,您似乎根本不了解UDP,它与广播无关。
安德鲁·巴伯

我认为他非常了解它,并通过将网络技术投影到移动通信上提供了一个很好的类比!问题是:这不是问题的答案:(
Nippey 2012年

0

TCP:

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

可靠– TCP仅在传输层严格管理消息确认,重传和超时。多次尝试传递邮件。如果途中丢失,服务器将重新请求丢失的部分。在TCP中,没有丢失数据,或者在发生多个超时的情况下断开了连接。(但是,此可靠性不包括应用层,在该层仍需要单独的确认流控制)

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

重量级–在发送任何用户数据之前,TCP需要三个数据包来建立套接字连接。TCP处理可靠性和拥塞控制。流式传输–数据作为字节流读取,没有区别的指示会传输到信号消息(段)边界。

TCP的应用

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

UDP:

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

不可靠–发送UDP消息时,无法知道它是否会到达目的地;它可能会迷路。没有确认,重传或超时的概念。

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

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

数据报–数据包是单独发送的,只有到达时才检查完整性。数据包具有确定的边界,在接收时会遵守这些边界,这意味着在接收方套接字上进行的读取操作将产生原始发送的完整消息。没有拥塞控制– UDP本身不能避免拥塞。拥塞控制措施必须在应用程序级别上实施。

广播-无连接,UDP可以广播-子网中的所有设备都可以将发送的数据包定为可接收的地址。

多播–支持多播操作模式,通过该模式可以自动路由单个数据报包,而不会与大量用户重复。

UDP的应用

许多重要的Internet应用程序都使用UDP,其中包括:域名系统(DNS),查询必须快速并且仅由单个请求后跟单个答复包,简单网络管理协议(SNMP),路由信息协议( RIP)和动态主机配置协议(DHCP)。

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

一些VPN系统(例如OpenVPN)在应用程序级别实现可靠连接和错误检查时,可能会使用UDP。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.