tcp & udp使用场合

陈硕，Linux C++程序员，muduo 网络库作者

Euan、金鹤、洪乐 等人赞同

UDP 的使用范围很窄，而且编程比 TCP 难多了：

1. 你真的很在乎延迟，不能忍受重传，那么就用UDP，例如 NTP 协议。重传NTP消息纯属添乱。
2. 你真的不在乎可靠性，丢一些包也不需要重传，那么就可以用 UDP。例子我想不出来。有人说音频或视频流可以用UDP，不过据我看来各大视频网站都用HTTP协议，而HTTP是基于TCP的。
3. 你需要NAT穿透，那么不得不用UDP。
4. 其他情况，一旦程序要自己做重传，你都是在用UDP模拟出蹩脚的TCP，还不如直接用TCP呢。

总之：使用 UDP 需要有强大到不容置疑的理由，when in doubt, use TCP.

一些协议，出于历史原因，受当时技术和网络条件限制，选择了基于UDP实现，其选择的理由现在很可能已经不再成立了。因此“xxx协议用UDP”不是你现在写网络应用程序也该用UDP的理由，除非你本身就是在实现xxx协议。

另外，那些说TCP比UDP慢、效率低的，你拿UDP写个程序，把千兆网带宽打满（TCP等价的代码只有两行：客户端 while (true) { send(...); } 服务端 while (true) { recv(...); }。），且不说你的程序会有多复杂，先看看goodput到底是不是比TCP大、CPU使用率是不是比TCP低嘛。

pansz，自由软件开发者

Euan、金鹤、赖琦 等人赞同

陈硕说的基本是对的，我补充一下他所说的可以用 UDP 的情况。

1，
实时音视频是可以而且应该用 UDP 的，一方面因为它常常涉及到网络穿透，另外一方面它不需要重传。——我需要实时的看到你的图像跟声音，至于中间丢一帧什么的完全不重要。而为了重传往往会造成延迟与不同步，考虑一下，某一帧因为重传，导致0.5秒以后才到，那么整个音视频就延迟了0.5秒。

考虑一下接收方看视频，如果使用 TCP 导致视频的中间延迟了0.5秒，只要我不按「快进」键，那么后续的视频全都会比发送方延迟0.5秒。这种延迟是累加的，随着持续丢帧，延迟会越来越大，达到数秒，甚至分钟级，这会严重影响实时音视频的用户体验。

因此「实时音视频聊天」功能通常都会使用 UDP 实现。

2，
网络真的非常非常可靠，以至于你完全不需要考虑 UDP 丢包问题的情况。
典型的例子应该是专门为有线局域网设计的协议。

3，
另外一个问题是 TCP 是纯粹的流式数据，所以制定传输协议的时候，接受方需要自行判定一个包的开始和结束，因为你完全可能接受到半个包或者两个包。——如果数据报的起止判定对你具体的程序会成为大问题，也可以考虑 UDP。


至于其他的情况， “ when in doubt, use tcp ”

林仔，cumter， coder

常常、zeekvfu、黄建乐 等人赞同

udp处理数据报，tcp处理网络流。
读udp socket 一次返回一个报文
读TCP socket不一定能读到一个完整的报文
udp不保证报文到达的先后顺序，不保证是否有报文丢失
tcp保证写入流的数据按顺序被读出来
tcp可靠性高，效率低
udp效率高，可靠性低

深井里的冰，心无属，意阑珊

XIE TAO、yaocoder、小眼Archer 等人赞同

0、TCP是面向流字符的，数据流间无边界；UDP是面向分组的，分组间有明确的边界。
对于TCP，发送一串数字（1，2，3，4，5），接收时有可能变成两次（1，2）和（2，4，5），或者变成任意接收方式，协议栈只保证接收顺序正确；UDP发送一个分组，接收方或者接收完全失败，如果成功整个分组都会接收到。

1、TCP是面向连接的，UDP是无连接的。类比于打电话和发电报的关系。
TCP建立一个连接需要3次握手IP数据包，断开连接需要4次握手。另外断开连接时发起方可能进入TIME_WAIT状态长达数分钟（视系统设置，windows一般为120秒），在此状态下连接（端口）无法被释放。

2、TCP是可靠的，通过数据校验保证发送和接收到的数据是一致的；UDP是不可靠的，发送一串数字分组（1，2，3）可能接收到时就变成（1，0，0）了，做UDP连接时需要自己做数据校验。

3、TCP数据是有序的，以什么顺序发送的数据，接收时同样会按照此顺序；UDP是无序的，发出（1，2，3），有可能按照（1，3，2）的顺序收到。应用程序必须自己做分组排序。

4、TCP因为建立连接、释放连接、IP分组校验排序等需要额外工作，速度较UDP慢许多。TCP适合传输数据，UDP适合流媒体。

5、UDP比TCP更容易穿越路由器防火墙。

张观石，互联网技术，运维，开发

booter jack、杜亮、pyty 赞同

打个比方：
TCP就像是两个人传递球
A:我要传球给你了哦，你准备好了吗？
B:准备好了！
A:开始传一号球
B:收到！
A:二号球
B:收到
....
A:传完了
B:我也接完了
A：88
B：88

UDP，你闭着眼往一个框里扔球
1号球
2号球
3号球

即使2号没进去，也不管了，继续扔
4号球
....



不知楼主问的是tcp、udp，还是主要问socket
TCP不用说，最常见
在互联网技术中，UDP常用在缓存读取，保存；用在监控或终端上报；
常用dns服务，SNMP协议都是UDP协议的

如果是问socket的话，这么讲吧：
socket文件为同一台服务器间的不同进程提供了一种网络通信的方式，通过文件就可以，而不需要通过物理网卡。

内核里sock和socket还是不一样的两个东西

问题太含糊，只能讲这么多了

王丹

Euan 赞同

就标准协议而言，TCP、UDP、SCTP协议的应用场合如下：

很难给出一个明确的界限，区分出两者的使用场景，上图中有不少协议，同时使用TCP和UDP。
基本上，需要可靠性但自己又不想维护可靠性时，用TCP。
很简单的应用、隧道技术、对时延和抖动敏感的应用，可以使用UDP。
如同前面说的，不确定的时候，用TCP。

再补充一些我知道的信息：
1. 移动网的核心网部分（如Gn、Gb、Iu、A10/A11、WAP），大都采用了隧道技术，外层都是UDP。
2. 早期的p2p、视频程序，用UDP的比较多。现在多是TCP了，直接使用HTTP协议，被限制或封堵的概率很小：）
3. 游戏类程序，使用UDP的仍然较多。

德斯特尼，你就是个悲剧

常常 赞同

陈硕和pansz说的都差不多了哈。我再补充点。

1. TCP是流式协议，即数据包是没有边界的，需要自己识别（这个pansz已经提到）。可以把发TCP数据包的动作理解成往对端用管子灌水。水就是数据包，它们之间没有边界；UDP是面向消息的，每个包是有边界的。可以把发UDP数据包的动作理解成往对端滚玻璃球。每个玻璃球是一个数据包，它们之间有明显的边界。而且由于每个玻璃球的速度可能不一样，先滚的不一定先到，所以需要自己处理乱序。

2. UDP比TCP效率高些。道理很简单啊，TCP要检查丢没丢包等额外的工作。

3. TCP也是可以做NAT穿透的哈（俗称打洞）。

朱曦炽，为了以后不用介绍自己而努力

郑国栋 赞同

关于TCP和UDP的区别和概念上面都有人写过了。我这里写一个UDP的应用。

在多人网络游戏中，人物的移动可以用UDP来发。因为人物一直处于移动当中，会频繁发出位置信息的包。由于发的比较频繁，而且后面的位置信息会覆盖掉前面的位置信息，所以丢不丢包不重要。就可以用UDP来发。每个UDP包的数据里面加个时间戳，那么进来的包你判断下时间，如果是已经过期的包，就可以直接丢掉。这样，即使udp包过来的顺序不一样都无所谓了。

鹰之翔，C++程序员，来这里玩玩

UDP和TCP的适用范围是由它们各自的特性决定的。

UDP的特性是：数据报，无连接，简单，不可靠，会丢包，会乱序（实际中遇到的主要是丢包）
TCP的特性是：流式，有连接，复杂，可靠，延迟较大、带宽占用较大（均是相对于UDP来说）

不同的应用场合会选择不同的协议。以流媒体为例，一类是对实时性要求不高的音视频点播应用（比如各大视频网站），这类应用就多用TCP/HTTP，因为用户可以忍受延时，可以进行缓冲，但不能忍受丢包导致的马赛克。

另一类是对实时性要求很高的音视频通信应用，比如视频会议、视频监控，这类应用用户是无法忍受过高的延时的，相反，偶尔丢一下包却无关大碍。而且，在这类应用中，基于UDP的组播技术也是经常用到的，因为它可以大大减轻服务器和交换机的压力。

不太同意陈硕的第一句话，在编程上，UDP比TCP简单得多，因为它没有建立连接的过程，而且是数据报方式，接收端不用像TCP那样需要自己重组应用层的协议包。陈硕说UDP比TCP复杂，估计还是考虑到用UDP来实现可靠传输，如果是这样，那就应该使用TCP。如果对可靠性要求不是那么高，给UDP加上确认重传也是比较简单的事情（乱序问题我在实际中还未遇到过，也许是出现了未被观察到）。

另外，SCTP是一个兼顾了UDP和TCP优点的协议，看它的特性是很吸引人的，不过我还没在实际中还没接触过。