导读：今天首席CTO笔记来给各位分享关于udp大数据包用哪个好的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
UDP同通信好还是Tcp的好
本来他们两个是为了适用不同的需求而出来的传输方式，没得说谁好谁坏，如果硬是要说好和坏，只能从不同业务需求来说，对于实时性要求比较高的时候，肯定是udp，因为实时性中传输大量的数据，丢一些包不妨碍实时性； 如果是网络非常好的情况，并且要数据完整的只能说优先考虑tcp，udp也是可以做到的，但是就比较麻烦需要去做拆包分包的帧的验证和判断，但是做好了绝对比tcp好，这是在公司人力资源允许的情况下；
因此综上所述：inter网的传输优先考虑udp，实时性高的只能用udp，tcp开发相对简单，为了开发效率可以考虑；
如果是局域网的传输，想都别想就用tcp，无论是实时的还是大文件的都用tcp，因为局域网的网速是不用质疑的；
另外，拿个QQ例子，个人认为，qq文件传输中，应该是判断对方好友是否是和本人在同一个局域网下，如果是就用tcp连接发送文件飞快，如果是外网的应该是用udp
UDP数据包,对电脑有害吗?
没有！
UDP数据包和TCP数据包一样，是一种网络协议的数据包！
UDP数据包具有较强的网络穿透能力，可以用于网络环境相对复杂的场合进行网络通信。其代表软件就是腾讯QQ
UDP数据包的缺点在与他不会像TCP包那样，发送出去后会等待接受方的验证是否收到，数据包是否合法。这样就造成UDP数据包相对TCP数据包更容易出现数据包丢失的情况。
如果对一台主机发送大量的UDP数据包，就会造成DoS攻击。现在从各个厂商的硬件防火墙来看，能够实现这种攻击的只有UDP数据包。TCP和SYN数据包大多会被拦截，无法形成攻击。
到底使用UDP还是TCP
在编写网络游戏的时候，到底使用UDP还是TCP的问题迟早都要面对。
一般来说你会听到人们这样说：“除非你正在写一个动作类游戏，否则你就用TCP吧” 或者是 “你能够在MMO游戏中用TCP,因为魔兽世界就用的TCP！”
遗憾的是，这些观点都没有反映这个问题的复杂性。
背景
首先，说明一下，我之前主要是用TCP进行网络编程。我曾为一个流行的在线纸牌游戏编写服务器了好几年，在高峰期我们的每台服务器能够承受4000到10000个连接（同一台物理机器上有多个服务器进程在跑）都没有问题。在我来看，TCP是一种安全而且常见的选择。
尽管如此，我们最新的项目却是使用UDP协议，而且我们的项目无法通过任何方式在TCP下工作。事实上，项目一开始使用的TCP，但是后来发现我们使用TCP无法达到我们需求的连接数量时，我们只能换成UDP了。
在使用中TCP表现怎么样呢
从原理上，TCP的优势有：
简单直接的长连接
可靠的信息传输
数据包的大小没有限制
任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。
除了上面列出的这些问题外，一个好的TCP模块确实不好编码实现。
但是，TCP最糟糕的特性是它对阻塞的控制。一般来说，TCP假定丢包是由于网络带宽不够造成的，所以发生这种情况的时候，TCP就会减少发包速度。
在3G或WiFi下，一个数据包丢失了，你希望的是立马重发这个数据包，然而TCP的阻塞机制却完全是采用相反的方式来处理！
而且没有任何办法能够绕过这个机制，因为这是TCP协议构建的基础。这就是为什么在3G或者WiFi环境下，ping值能够上升到1000多毫秒的原因。
为什么不用UDP
UDP相对TCP来说既简单又困难。
举个例子来说，UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。
但是，大多数情况下你需要的仅仅是一些连接的概念罢了，一些基本的包序功能，以及所谓的连接可靠性。可惜的是，这些功能UDP都没有办法简单的提供给你，而你使用TCP却都可以免费得到。
这也是人们为什么经常推荐TCP的原因。在用TCP的时候你可以不考虑这些问题，直到你需要同步连接的数量级达到500以上的时候。
所以，是的，UDP没有提供所有的解决方法，但是就像你看到的那样，这也正是UDP好用的地方。在某种意义上来说，TCP对UDP就好比是Hibernate和手写SQL的区别。
使用TCP失败的地方
人们经常给你建议，让你去使用TCP，比如“TCP跟UDP一样快”或者“游戏X用TCP如此成功，所以TCP当然是首选”，然而，他们完全没有理解为什么在那个特定的游戏中TCP是有效的，为什么UDP不按照顺序发送数据包呢？
那么为什么魔兽世界采用TCP呢？首先我们需要解释这个问题。这个问题其实是“为什么魔兽世界有的时候1000毫秒以上的延迟还能够运行？”这是TCP的性质决定的，在发生丢包的时候，会产生巨大的延迟，因为TCP首先会去检测哪些包发生了丢失，然后重发所有丢失的包，直到他们都被接收到。
可靠的UDP也是有延迟的，但是由于它是在UDP的基础之上建立的通信协议，所以可以通过多种方式来减少延迟，不像TCP，所有的东西都要依赖于TCP协议本身而无法被更改。
就这一点来讲，一些人要开始提到Nagle算法了，实际上它是你在实现任意一个对延迟敏感的TCP模型时首先需要禁止使用的。
那么魔兽世界以及其他的一些游戏是怎么处理延迟问题的呢？
方法也很简单，他们能够隐藏掉延迟带来的影响。
在魔兽世界中，玩家和玩家是无法碰撞的：因为这类碰撞是无法通过一些预测来处理的，但是玩家和环境之间的碰撞却是可以通过预测来处理的，所以这里使用TCP是没有问题的。
我们来看一下魔兽世界的战斗就会发现，玩家的攻击指令发送给服务器的操作是放在比如“attack_entity(entity_id)”或者”cast_spell(entity_id, spell_id)“的接口中来做的，换句话说，瞄准操作是独立于进行的。如此一来，一些类似发起攻击动作和释放技能特效就能够在没有收到服务器确认的情况下就直接执行，比如展现冰冻技能的效果就可以在服务器没有返回数据前在客户端就做出来。
客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术。
几年前，我为一个叫“Five Card Jazz”的纸牌游戏编写过客户端。它使用的是http协议，它比直接的TCP协议连接的延迟更加严重。
我们用简单的纸牌绘制和抽牌的动画来掩盖延迟的问题，所以延迟的问题只在非常糟糕的连接下才会被看出来。这种方法也非常的典型：发送请求的同时开始播放牌桌的动画，一直播放翻动最后一张牌直到接收到了服务端传回来的数据为止。魔兽世界的战斗特效就是使用类似的原理。
这也意味着，我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。
TCP在什么时候失效
一个采用TCP的游戏必须能够处理好突发的延迟问题（纸牌客户端就很典型，对突发性的一秒的延迟，玩家也不会产生什么抱怨）或者是拥有缓解延迟问题的好方法。
但是如果你运行的是一个无法使用任何减缓延迟措施的游戏呢？玩家对玩家的动作类游戏通常就属于这个范畴，但是这也不仅仅限于动作类游戏。
举个例子：
我目前正在写一个多人游戏（War Arcana）。
一种常见的操作是，你快速的移动你的角色通过一张充满战争迷雾的世界地图，但是一旦你探索过，迷雾就会被打开。
为了确保游戏的规则，防止玩家作弊，服务器只能显示玩家当前位置附近的信息。这意味着不像魔兽世界，玩家无法在没有得到服务器响应的情况下，做出完整的动作。和Five Card Jazz相比，我们即使允许500毫秒的延迟，也已经非常困难了。
在实现了游戏的原型后，在局域网内一切都进行的非常顺利，但当我们在WiFi环境下测试时，操作会间歇性的卡起来或者延迟高起来。写了一些测试程序之后发现，WiFi环境下偶尔会发生丢包行为，每当发生丢包的时候，服务器的响应速度就从100-150毫秒上升到1000-2000毫秒。
没有任何办法可以绕过TCP的这个设置来避开这个问题。
我们替换了TCP的代码，用了自定义的可靠的UDP来实现，把大量的丢包产生的延迟降到了仅仅只有50毫秒，甚至比以前TCP不丢包的情况一个来回的延迟还要小。当然，这只可能建立在UDP之上，这样我们才对可靠性拥有完全的掌控力。
困惑：可靠的UDP只是TCP的一种简单的实现？
你有没有听过这种说法：“可靠的UDP就像TCP一样，所以还是用TCP吧”。
问题是这种说法是错误的。可靠的UDP一点也不像TCP，要去实现一个特殊的阻塞控制。事实上，这也是你使用可靠UDP代替TCP的最大的原因，避免TCP的阻塞控制。
另一个重点是可靠的UDP的可靠性是如何保证的。这里有很多种方法去实现。我非常喜欢Quake3网络库代码里的一些想法，它们也激发了我在War Arcana中使用UDP协议。
你也可以使用许多支持可靠通信的UDP库，当然，这样在可靠性方面，相比自己手动实现全部的代码而言，可能会更加通用而失去了一些性能优势。
底线
那么到底是用UDP还是TCP呢？
如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。
如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。
如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。
这些也应该考虑在内：你的MMO客户端也许首先使用HTTP去获取上一次的更新内容，然后使用UDP跟游戏服务器进行连接。
永远不要害怕去使用最佳的工具来解决问题。
UDP数据包是什么？
UDP协议的全称是用户数据报，在网络中它与TCP协议一样用于处理数据包。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据报分组、组装和不能对数据包的排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。
为什么要使用UDP
在选择使用协议的时候，选择UDP必须要谨慎。在网络质量令人不十分满意的环境下，UDP协议数据包丢失会比较严重。但是由于UDP的特性：它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们聊天用的ICQ和OICQ就是使用的UDP协议。
在Java中操纵UDP
使用位于JDK中Java.net包下的DatagramSocket和DatagramPacket类，可以非常方便地控制用户数据报文。
在描述它们之前，必须了解位于同一个位置的InetAddress类。InetAddress实现了Java.io. Serializable接口，不允许继承。它用于描述和包装一个Internet IP地址，通过三个方法返回InetAddress实例：
getLocalhost()：返回封装本地地址的实例。
getAllByName(String host)：返回封装Host地址的InetAddress实例数组。
getByName(String host)：返回一个封装Host地址的实例。其中，Host可以是域名或者是一个合法的IP地址。
DatagramSocket类用于创建接收和发送UDP的Socket实例。和Socket类依赖SocketImpl类一样，DatagramSocket类的实现也依靠专门为它设计的DatagramScoketImplFactory类。DatagramSocket类有3个构建器：
DatagramSocket()：创建实例。这是个比较特殊的用法，通常用于客户端编程，它并没有特定监听的端口，仅仅使用一个临时的。
DatagramSocket(int port)：创建实例，并固定监听Port端口的报文。
DatagramSocket(int port, InetAddress localAddr)：这是个非常有用的构建器，当一台机器拥有多于一个IP地址的时候，由它创建的实例仅仅接收来自LocalAddr的报文。
值得注意的是，在创建DatagramSocket类实例时，如果端口已经被使用，会产生一个SocketException的异常抛出，并导致程序非法终止，这个异常应该注意捕获。DatagramSocket类最主要的方法有4个：
Receive(DatagramPacket d)：接收数据报文到d中。receive方法产生一个“阻塞”。
Send(DatagramPacket d)：发送报文d到目的地。
SetSoTimeout(int timeout)：设置超时时间，单位为毫秒。
Close()：关闭DatagramSocket。在应用程序退出的时候，通常会主动释放资源，关闭Socket，但是由于异常地退出可能造成资源无法回收。所以，应该在程序完成时，主动使用此方法关闭Socket，或在捕获到异常抛出后关闭Socket。
“阻塞”是一个专业名词，它会产生一个内部循环，使程序暂停在这个地方，直到一个条件触发。
DatagramPacket类用于处理报文，它将Byte数组、目标地址、目标端口等数据包装成报文或者将报文拆卸成Byte数组。应用程序在产生数据包是应该注意，TCP/IP规定数据报文大小最多包含65507个，通常主机接收548个字节，但大多数平台能够支持8192字节大小的报文。DatagramPacket类的构建器共有4个：
DatagramPacket(byte[] buf, int length, InetAddress addr, int port)：从Buf数组中，取出Length长的数据创建数据包对象，目标是Addr地址，Port端口。
DatagramPacket(byte[] buf, int offset, int length, InetAddress address, int port)：从Buf数组中，取出Offset开始的、Length长的数据创建数据包对象，目标是Addr地址，Port端口。
DatagramPacket(byte[] buf, int offset, int length)：将数据包中从Offset开始、Length长的数据装进Buf数组。
DatagramPacket(byte[] buf, int length)：将数据包中Length长的数据装进Buf数组。
DatagramPacket类最重要的方法就是getData()了，它从实例中取得报文的Byte数组编码。
★简单的实例说明
{接收数据的服务器}
byte[] buf = new byte[1000];
DatagramSocket ds = new DatagramSocket(12345);
//开始监视12345端口
DatagramPacket ip = new DatagramPacket(buf, buf.length);
//创建接收数据报的实例
while (true)
{
ds.receive(ip);
//阻塞，直到收到数据报后将数据装入IP中
System.out.println(new String(buf));
}
{发送数据的客户端}
InetAddress target = InetAddress.getByName("");
//得到目标机器的地址实例
DatagramSocket ds = new DatagramSocket(9999);
//从9999端口发送数据报
String hello = "Hello, I am come in!";
//要发送的数据
byte[] buf = hello.getBytes();
//将数据转换成Byte类型
op = new DatagramPacket(buf, buf.length, target, 12345);
//将BUF缓冲区中的数据打包
ds.send(op);
//发送数据
ds.close();
//关闭连接
IP数据包 tcp数据报 udp数据报三者有什么区别和联系？ 能否解释详细点
1、
IP数据包包含 tcp数据包 udp数据包，IP是第三层（网络层）的协议，TCP与UDP都属于第四层（传输层）的协议。
TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快
2、关键点区分：
A。基于连接与无连接
B。对系统资源的要求（TCP较多，UDP少）
C。UDP程序结构较简单
D。流模式与数据报模式
E。TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证
3、
TCP发送的包有序号，对方收到包后要给一个反馈，如果超过一定时间还没收到反馈就自动执行超时重发，因此TCP最大的优点是可靠。一般网页（http）、邮件（SMTP)、远程连接(Telnet)、文件(FTP)传送就用TCP
UDP是面向消息的协议，通信时不需要建立连接，数据的传输自然是不可靠的，一般用于多点通信和实时的数据业务，比如语音广播、视频、QQ、TFTP(简单文件传送）、SNMP（简单网络管理协议）、RTP（实时传送协议）RIP（路由信息协议，如报告股票市场，航空信息）、DNS(域名解释）。注重速度流畅。
要了解TCP，一定要知道【三次握手，四次拜拜】，上网一搜就知道了 ，而所谓的三次握手，就是发送数据前必须建立的连接叫三次握手，握手完了才开始发的，这也就是面向连接的意思。
tcp udp 协议编程,数据包大小通常设为多少最宜??
如果局域网应用的话大一些比较好。
广域网的话，需要自己测试调优了。大包如果发生丢包重试造成的损失会比较大，包小的话，开销比较大。
结语：以上就是首席CTO笔记为大家整理的关于udp大数据包用哪个好的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～