udp协议格式(udp协议数据包格式)

UDP协议 用户数据报协议UDP(User Datagram Protocol)是无连接传输层协议，提供应用程序之间传送数据报的基本机制。1.UDP报文的格式每个UDP报文称为一个用户数据报：它分为两部分：头部和数据区。如图6-14是一个UDP报文的格式，报文头中包含有源端口和目的端口、报文长度以及UDP检验和。源端口(Source Port)和目的端口(Destination Port)字段包含了16比特的UDP协议端口号，它使得多个应用程序可以多路复用同一个传输层协议 – UDP协议，仅通过不同的端口号来区分不同的应用程序。长度(Length)字段记录了该UDP数据包的总长度(以字节为单位)，包括8字节的UDP头和其后的数据部分。最小值是8(即报文头的长度)，最大值为65,535字节。UDP检验和(Checksum)的内容超出了UDP数据报文本身的范围，实际上，它的值是通过计算UDP数据报及一个伪包头而得到的。但校验和的计算方法与通用的一样，都是累加求和。 不危险，可以打开
英文原义：User Datagram Protocol 中文释义：（RFC-768）用户数据报协议 注解：用户数据报协议（UDP）是TCP/IP协议组的一个组成部分。它的创立是为了向应用程序提供一条访问IP的无连接功能的途径。TCP和UDP都使用IP。UDP的设计允许应用程序创建数据报，以及将它们编址到访问应用程序或进程的端口。UDP的基本作用就是向一个IP分组增加一个应用程序进程的端口地址。
这种问题1般出现在WINDOWS XP 中.如果你是这种情况就按下面操作 1;打开网上邻居 按 左边的 察看网络连接 右键点 本地连接属性 再点 高级 首先要打开防火墙(记住 一定要打开 不然 无法完成接下来操作) 点击设置后 出现 服务 下面有添加 描述就打 劲爆足球 IP地址就打 222.122.224.176外部端就打 8411 内部端也是 8411 单击 确认后退出 就OK 这我试过 我也遇到同样问题 改变后就好了
在百度搜索一下，自己就会知道答案的
基于无连接数据报协议，是一种通常的网络协议，而且大部分软件都是跑udp协议，QQ就是。建议打开，放心没有危险。
没危险，UDP一般用于视频，游戏的网络协议

udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：tcp 面向连接，udp 面向非连接即发送数据前不需要建立连接；tcp 提供可靠的服务（数据传输），udp 无法保证；tcp 面向字节流，udp 面向报文；tcp 数据传输慢，udp 数据传输快；tcp 为什么要三次握手？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。 第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！ 在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立连接之后，谁都可能先开始通信。如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的在此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
TCP/IP协议是一个协议簇。里面包括很多协议的，UDP只是其中的一个， 之所以命名为TCP/IP协议，因为TCP、IP协议是两个很重要的协议，就用他两命名了。

UDP协议属于传输层协议(OSI和TCP/IP都有)，它的协议格式较简单，由源端口、目的端口，长度，检验和以及要传输的数据部分组成。前四个字段组成首部，固定8个字节，每个字段分别2个字节。 UDP是一种尽最大努力传输的协议，所以非常简单，它的传输成功率几乎就完全依靠IP层协议去保证了。
传输层。

UDP协议一般指UDPUDP 是User Datagram Protocol的简称， 中文名是用户数据报协议，是OSI（Open System Interconnection，开放式系统互联） 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。Internet 协议集支持一个无连接的传输协议，该协议称为用户数据报协议（UDP，User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据报的方法。RFC 768 描述了 UDP。扩展资料：UDP协议与TCP协议一样用于处理数据包，在OSI模型中，两者都位于传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年，虽然其最初的光彩已经被一些类似协议所掩盖，但即使在今天UDP仍然不失为一项非常实用和可行的网络传输层协议。参考资料来源：百度百科-UDP协议参考资料来源：百度百科-TCP
UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。比如，我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。例如，在默认状态下，一次“ping”操作发送4个数据包（如图2所示）。大家可以看到，发送的数据包数量是4包，收到的也是4包（因为对方主机收到后会发回一个确认收到的数据包）。这充分说明了UDP协议是面向非连接的协议，没有建立连接的过程。正因为UDP协议没有连接的过程，所以它的通信效果高；但也正因为如此，它的可靠性不如TCP协议高。QQ就使用UDP发消息，因此有时会出现收不到消息的情况。 TCP协议和UDP协议各有所长、各有所短，适用于不同要求的通信环境。

首先TCP是面向连接的，UDP是无需连接的，TCP有着三握四挥，并且三次握手和四次挥手是对TCP建立的连接有着重要意义的两步，并且TCP是对IP无可靠性提供可靠性的源头，UDP继承了IP的特性，不保证不丢失包，不保证按顺序到达TCP面向字节流，发送的时候是一个流，没有头尾，IP包不是一个流，而是一个个的IP包，UDP也是如此TCP是有拥塞控制的，但是UDP没有MAC层去掉之后，IP层首部会有一个8位的协议，这里会存放着数据里到底是TCP还是UDP，当然这里是UDP，如果我们知道UDP格式就可以解析出来了下一步就通过UDP包中的目标端口号，将这个包交给应用程序处理源端口和目标端口不可少，包的序号是为了解决乱序问题，为了解决包的先后顺序，还有就是确认序号，发出去的包要有确认，不然无法知道是否收到，若没有收到就要重新发送，直到送达，这就是TCP的不丢包的实质对于TCP来说，IP层丢不丢包管不着，但是在TCP层，会努力保证可靠性一开始，客户端和服务端都处于CLOSED状态，先是服务端主动监听某个端口，处于LISTEN状态，然后客户端主动发起连接SYN，之后处于SYN-SENT状态，服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态。客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态，因为它一发一收成功了，服务端收到ACK的ACK之后，处于ESTABLISHED，因为它也一发一收了所以三次握手就能确认双发收发功能都正常，缺一不可。最后客户端A的TIME-WAIT状态时间要足够长，长到如果B没有收到ACK的话，B会再次发送FIN关闭连接，A会重新发送一个ACK并且时间足够长到这个包到BA如果直接跑路的话，它的端口就空出来了，但是B不知道，原来发的包如果在路上，但是这时突然另一个应用开启在了这个端口上，那不就混乱了，所以A也需要等待足够时间，等到B发送的包在网络中挂掉之后再空出端口来等待时间设置为2MSL，报文最大的生存时间，协议规定MSL为2分钟，实际应用中常用的是30s，1分钟和2分钟等为了记录所有发送的包和接收的包，TCP也需要发送端和接收端分别都有缓存来保存这些记录，发送端的缓存里是按照包的ID一个个排列，根据处理情况分为下面四个部分在TCP里，接收端会给发送端报一个窗口的大小，叫做Advertised window，这个窗口大小应该等于上面说的第二部分加上第三部分也就是已经发送了但是没有得到确认的加上还没有发送，并且正在准备发送的，超过这个窗口的，接收端忙不过来，就不能发送了第二部分的窗口有多大？NextByteExpected 和 LastByteRead的差其实是还没有被应用层读取的部分占用调MaxRcvBuffer的量，定义为A，窗口大小其实是MaxRcvBuffer减去A其中第二部分里面，由于收到的包可能不是顺序的，会出现空档，只有和第一部分连续的，可以马上进行回复，中间空着的部分需要等待，哪怕后面的已经来了(可以看到接收端的窗口出现了虚线和实线的区别)发送端接收端在发送端看来，1、2、3都已经发送并且确认的；4、5、6、7、8、9都是发送了还没有确认；10、11、12是还没有发出的；13、14、15是接收方没有空间不准备发送的在接收端看来，1、2、3、4、5都是已经完成ACK的，但是是没有被应用层读取的；6、7是等待接收的；8、9是已经接收，但是还没有ACK的当前的状态假设4的ACK到了，不幸的是5的ACK丢了，6、7的数据包丢失了，这应该怎么做？对每一个发送了，但是没有ACK的包，都设有一个定时器，超过了一定的时间就重新尝试，但是这个超时的时间如何进行评估呢，这个时间不宜过短，时间必须大于往返时间RTT，否则将会引起不必要的重传，也不宜过长，这样的超时时间变长，访问就变慢了RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。估计往返时间需要TCP通过采样RTT的时间，然后进行加权平均，计算出来一个值，并且这个值还是随着网络的状况不断变化的，我们成为自适应重传算法如果过一段时间，5、6、7都超时了，就会重新发送，接收方发现5原来接受过，于是丢弃5；6收到了，发送ACK，要求下一个是7,7不幸又丢了，当7再次超时的时候，有需要重传的时候，TCP的策略是超时间隔加倍，每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前的两倍，两次超时就说明网络环境差，不适合频繁反复发送超时触发重传存在的问题是，超时周期可能相对较长有一个快速重传的机制，当接收方收到一个序号大于下一个所期望的报文段时，就检测到了数据流中的一个间隔，于是发送三个冗余的ACK，客户端收到后，在定时器过期之前，重传丢失的报文段例如，接收方发现6、8、9都已经接收了，7还没来，那肯定是丢了，于是发送三个6的ACK要求下一个是7，客户端收到3个ACK就会发现7的包确实又丢了，不再等待超时，马上重发SACK，这种方式需要在TCP头加一个SACK的东西，可以将缓存的地图发送给发送方，例如有了ACK6、ACK8、ACK9就会知道7丢了在对于包的确认中，同时会携带一个窗口的大小假设窗口不变，始终为9,4的确认来的时候，会右移一个，这个时候第13个包也可以发送了这个时候，假设发送端发送过猛，会将第三部分的10、11、12、13全部发送完毕，之后就停止发送了，未发送可发送部分为0当对于包5的确认到达的时候，在客户端相当于窗口滑动了一格，这个时候才可以有更多的包可以发送了，接下来14可以被发送如果接收方实在处理太慢，导致缓存中没有了空间，可以通过确认信息修改窗口的大小，甚至可以设置为0，让发送端暂时停止发送假设接收端应用一直不读取缓存中的数据，当数据包6被确认后，窗口大小就会减小一个变为8这个时候可以看到，接收端的窗口并没有向右移动，只是简单地将左边的标记右移一格，窗口大小变为8如果接收端一直不处理数据，则随着确认包越来越多，窗口越来越小直到为0如果情况变成这样，发送方会定时发送窗口探测数据包，看看是否有机会调整窗口的大小，当接收方比较慢的时候，要防止低能窗口综合征，不要空出一个字节就告诉发送方，然后立马被填满，可以当窗口太小的时候，不更新窗口，直到达到一定大小，或者缓冲区一般为空的时候再更新窗口拥塞控制同样通过窗口的大小来控制，滑动窗口是为了防止发送方把接收方缓存塞满，而拥塞窗口是为了不把网络填满LastByteSent - LastByteAcked <= min{滑动窗口， 拥塞窗口}TCP协议是不知道真个网络路径都是什么，TCP包常被比喻为往一个谁管理灌水TCP拥塞控制就是在不堵塞，不丢包的情况下，尽量发挥带宽网路通道的容量 = 带宽 x 往返延迟假设往返时间为8s，发送的过程4s，返回的时间4s，每个包1024byte，过了8s，8个包都发出去了，其中4个已经到达了接收端，但是ACK还在路上，不能算是发送成功了，5-8后四个包还在路上没被接收，这个时候，整个管道刚好被撑满如果我们在这个基础上再将窗口调大一点，会出现什么现象？如果从发送端到接收端会经过四个设备，每个设备处理包的时间需要1s，所以4个包的话，总共的处理时间为4s，如果窗口调大，也就有可能增加发送速度，单位时间内，会有更多的包到达这些中间设备，那么处理中的设备会丢弃到多余的包，这是我们不想看到的这个时候，我们可以为这四台设备增加缓存，处理不过来的包在队列里等待，这样就不会丢失了，但是缺点是会增加时间，在之前我们分析过只需要4s一个包即可到达发送端，但是进入缓存中多余的包肯定到达的时间是要超过4s的，如果这个时候发送方还是没有收到ACK那么就会触发超时重传，TCP的拥塞控制就是为了处理包的丢失和超时重传一条TCP连接的开始，cwnd设置为一个报文段，一次只能发送一个，当收到这个确认的时候，cwnd +1，于是一次能够发送2个，当这两个的确认到来的时候，每个确认的cwnd + 1 ，两个确认的cwnd就可以 +2，现在可以发送4个，这是指数级别的增长，但是有一个值sshthresh为65535字节，当超过这个值的时候不要增长得这么快了，可能快满了，再慢下来于是，每收到一个确认后，cwnd增长1/cwnd，一共发送8个的话，当8个确认到来的时候，每个确认增加1/8，八个确认一共cwnd + 1，于是一次能够发送9个，变成了线性增长，但是肯定有一天会满，这个时候就会出现拥堵，就需要慢慢等待包的处理拥塞的一种形式是丢包，需要超时重传，这个时候重新开始慢启动，这样的话，只要超时重传就感觉会回到解放前快速重传，当接收端发现丢了一个中间包的时候，发送三次前一个包的ACK，于是发送端就会快速重传，不必等待超时再重传，TCP认为这种情况不严重，因为大部分没丢，只丢了一小部分正是这种知道该快还是慢的情况下，使得时延很重要的情况下，反而降低了速度，但是拥塞控制还是存在问题为了优化这两个问题，有了TCP BBR拥塞算法，它企图找到一个平衡点，通过不断的加快发送速度，将管道填满，但是不会填满中间设备的缓存，因为这样时延会增加，这个平衡的时点可以很好的达到高带宽和低时延的平衡