互联网工程任务组(IETF)官员透露,HTTP-over-QUIC实验协议将重命名为HTTP/3,并有望成为HTTP协议的第三个正式版本。
UDP协议被广泛用到对网络数据传输的实时性很高,对数据准确性不是非常高的场合,并且如今网络物理介质的高速提升(光纤)降低了数据丢包的机率,并且当网络状况很好的情况下,UDP的缺点又可以很好的大程度上的被改善。因此UDP协议发展前途无量。
所以,作为新一代HTTP协议的底层,要不要重温下?
UDP是什么?
UDP是User Datagram Protocol的缩写,是一种用户数据报协议,又称为用户数据报文协议。区别于TCP是面向连接的协议,UDP是一个简单的面向数据报的传输层协议,UDP的发起和接受是不需要经过连接的,仅仅只需要发送在对应端口上进行监听接受即可,不需要两个客户端一定是连接的
UDP传输不可靠的原因有五点:
TCP协议和UDP协议的区别是什么?
常见问题:QQ用的是TCP还是UDP?
QQ采用的通信协议以UDP为主,辅以TCP协议。QQ并不是完全基于UDP实现,比如在使用QQ进行文件传输等活动的时候,就会使用TCP作为可靠传输的保证。
由于QQ的服务器设计容量是海量级的应用,一台服务器要同时容纳十几万的并发连接,因此服务器端只有采用UDP协议与客户端进行通讯才能保证这种超大规模的服务。
QQ客户端之间的消息传送也采用了UDP模式,因为国内的网络环境非常复杂,而且很多用户采用的方式是通过代理服务器共享一条线路上网的方式,在这些复杂的情况下,客户端之间能彼此建立起来TCP连接的概率较小,严重影响传送信息的效率。而UDP包能够穿透大部分的代理服务器,因此QQ选择了UDP作为客户之间的主要通信协议。
采用UDP协议,通过服务器中转方式。大家都知道,UDP协议是不可靠协议,它只管发送,不管对方是否收到的,但它的传输很高效。但是,作为聊天软件,怎么可以采用这样的不可靠方式来传输消息呢?于是,腾讯采用了上层协议来保证可靠传输:如果客户端使用UDP协议发出消息后,服务器收到该包,需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况,就是因为客户端发出的消息服务器已经收到并转发成功,但客户端由于网络原因没有收到服务器的应答包引起的。
之所以当时应用UDP,最本质上UDP的优势还是带宽的利用。这一切要回归到99~03年的网络状况,当时网络的特点就是接入带宽很窄而且抖动特别厉害。所谓抖动可能是多方面的,例如延时突发性地暴增、也有可能是由于路由层面的变化突然导致路由黑洞,还各种等等等等的问题。TCP因为拥塞控制、保证有序等原因,在这种网络状态上对带宽的利用是非常低的。而且因为网络抖动的原因,应用层心跳超时,应用层主动断掉socket之后TCP需要三次握手才能重新建立链接,一旦出现频繁的小抖动就会使得带宽利用更低。而等待四次挥手的时间,也会占用服务器上宝贵的资源。
总结来说,当网络差到一定程度了,TCP的优势反而会成为劣势。
UDP2000个客户端左右 并发
单个数据包最大512字节
Internet 10MB带宽
要求效率(尽可能快,尽可能少丢包),这种情况下用哪种通讯模型比较有优势!
想用IOCP,因为和select模型相比,这个稍微熟悉一点,也在项目中用过,不过是TCP的。
有两个问题,大家懂得的帮忙给指导一下:
是否可以理解为UDP模式下,一次recvfrom 只对应一次sendto。
2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。
------解决方案--------------------------------------------------------
-------------------------------------
等不到,包被截断了。
2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。
--------------------------
其实,我个人认为对udp而言,不用iocp也可以满足。 首先sendto都是立即完成的,无需异步操作。而recvfrom可以只需阻塞一个线程就够了,不需要重叠操作。
------解决方案--------------------------------------------------------
用UDX协议最可靠,效率高,开发简单,非开源。
UDT开源,对于你这种2000客户,够用,开源。
------解决方案--------------------------------------------------------
1.sendto 10k,接受部分要么收到10k,要么全部丢失,不会出现部分收到的情况。
------解决方案--------------------------------------------------------
-------------------------------------
在局域网可以,公网,一般1K也收不到。
2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。
--------------------------完全可以
------解决方案--------------------------------------------------------
1.如果UDP数据在传输过程中被分包,则你需要对数据包进行标识,已确保获取的包完整。一次recvfrom并不对应一次sendto,考虑UDP不可靠传输的因素。
2.不可以,因为sendto和recvfrom都是对同一个资源Socket进行操作。如果在多个线程中对同一个资源进行操作,如果不加锁的情况下,会非常可怕的。而且,如果你加锁了,其实还不如单线程操作。
按照你的需求最好还是采用UDP,不过可以考虑组播。
2.API调用完全没有问题。但是接到的数据可能和发送的数据次序不一样,这本身是UDP乱序特性决定了的。而且你发送方可能是多线程,从API层面来说,这些调用都是可以的,完全没有问题。但是给你接收方处理带来一系列问题。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)