企业网站建设方案.doc,wordpress搞笑,福州seo排名优化,百度搜索网站怎么做最近思考udp处理的一些细节#xff0c;根据公开课#xff0c;反复思考#xff0c;终于有所理解#xff0c;做整理备用。 0#xff1a;简单汇总 1#xff1a;udp是基于报文传输的#xff0c;接收方收取数据时要一次性读完。 2#xff1a;借助udp进行发包#xff0c;…最近思考udp处理的一些细节根据公开课反复思考终于有所理解做整理备用。 0简单汇总 1udp是基于报文传输的接收方收取数据时要一次性读完。 2借助udp进行发包发大包也是没有问题的借助IP层ip分片。 》ip分片可以发生在原始主机上也可以发生在中间路由器上MTU值 》ip分片后可以再分片中间根据MTU进行判断。 》网络状态良好情况下问题不大但是网络状况不好的话如果分片后丢弃其中一个包udp整个包就丢了。 3有的路由器可以设置udp包过大会丢弃设置了不允许分包吗。 》ip头部有个标志字段flag可以设置不能分片则路由器会丢包。 4路由器会有小包优先发送的问题因此发送大包会有乱序问题分片后先发后面包的策略吧。 》这个是分片后先发的后面包吧。 5用户层对udp做分包 》网络状况不好时依赖ip分包丢一个包整个包会丢增加了风险和延迟。 》设置了udp底层不允许分包必然丢包。 》网络发生拥塞路由器或者交换机可能丢弃较大包减轻压力。 需要关注 》在用户层对udp进行分包 需要自定义协议以便组包以及分析包的最大字节数。 》组包乱序问题走不同链路可能导致路由器先发送小包可能导致。 6udp数据报大小最大65535字节报文头2字节表示长度64k 64*102465535字节 1udp发包如果一次不读完就读不到完整数据了。 //借助demo进行测试分包后发送如下前四个包1400字节 最后一个891 //这里直接借助同一个虚拟机客户端和服务端都运行在其上测试。 #抓包可以看到 收到五个包 前四个1428字节 最后 总共919字节 rootubuntu:/home/ubuntu# tcpdump -i lo -vnn port 10000 tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:33:04.369612 IP (tos 0x0, ttl 64, id 35196, offset 0, flags [DF], proto UDP (17), length 1428)192.168.40.132.48617 192.168.40.132.10000: UDP, length 1400 10:33:04.369764 IP (tos 0x0, ttl 64, id 35197, offset 0, flags [DF], proto UDP (17), length 1428)192.168.40.132.48617 192.168.40.132.10000: UDP, length 1400 10:33:04.369830 IP (tos 0x0, ttl 64, id 35198, offset 0, flags [DF], proto UDP (17), length 1428)192.168.40.132.48617 192.168.40.132.10000: UDP, length 1400 10:33:04.369889 IP (tos 0x0, ttl 64, id 35199, offset 0, flags [DF], proto UDP (17), length 1428)192.168.40.132.48617 192.168.40.132.10000: UDP, length 1400 10:33:04.369993 IP (tos 0x0, ttl 64, id 35200, offset 0, flags [DF], proto UDP (17), length 919)192.168.40.132.48617 192.168.40.132.10000: UDP, length 891#分析代码如果服务端读数据的时候buffer缓冲区不够大只读特定长度的数据一个完整的包就只读了这部分后面的数据就全不在了 #这里分析了 最后客户端发送时的buffer内容 以及服务端接收buffer的内容 #虽然有while循环但是只读了一次如果buffer不够只读了一个发送报文的前部分后面在读就从新的报文的前面了。#》所以 代码一次性要读完发送出来的一个完整的包2udp发包发大包也没问题ip底层会分片发送端或者中间路由。 》可能多次分片 这里简单实现一个udp服务端的代码在本地局域网和远端服务器上进行部署看看现象。 2.1 借助网络传输助手在虚拟机上运行服务端客户端用网络传输助手发送大包抓包发现是一个包并且服务端正常打印了数据。 接收时recvfrom缓冲区设置的比较大是20000 2.2 在远端云服务器上进行测试同样的服务端代码运行在远端 这里遇到一个自己埋坑的点看了好久云服务器上要配置端口开放配置安全组配置完要加入到对应的云服务器环境中我配置后实际环境和配置的安全组不是一个一直不通研究了半天。 如果用网络传输助手直接发一个比较大的包发现也是能成功的。这里的udpserver仅仅大的buffer接收 我简单测试发送了8次发现8次都收到了这里是手动频率不高。 用代码测试在本机虚拟机上发多个包给云服务器上demo 可以看到前三次发2048个字节最后一个335字节可以看到有接收乱序的问题。 如果我给客户端的发送多发送几次这里3次并且不等待能明显看出乱序严重有收到包。 》这里说明超过MTU,借助ip分片接收还是可以的但是有乱序的问题 如果正常的包大小进行测试看看小于MTU,这里用1400 3udp发包假设路由器有设置不允许分片或者设置不允许ip分片试试 如果我设置不允许分包这里只是简单参考设置 //这里我在客户端进行设置 然后发送前面的包1800 最后一个包符合 int val IP_PMTUDISC_DO ; setsockopt(sock, IPPROTO_IP, IP_MTU_DISCOVER, val, sizeof(val));从抓包看如果有这样的设置那么大于MTU的包就直接丢弃了sendto报时失败了没有ip分片不知道路由器中间有没有限制。 设置后直接导致发送失败 这里有个路径MTU的概念以及设置ip不分片有待研究。 汇总 1udp如果直接发大于MTU的包一般网络状况好的情况下也不会有太大问题当然有丢包概率。 2udp发送时有乱序的问题。 3在网络状态不好的情况下借助了ip分片增大了丢包的概率。 4路径MTU,以及中间路由器对包的丢包策略也是一个点 5为了防止丢包乱序以及中间路由器相关不可控问题最好用户层进行拆包拼包处理以及相关的可靠性传输。 太多的技术栈来源于零声学院工作之余跟着研究一些工作之外的知识。 推荐https://xxetb.xet.tech/s/2W52YR