Rad*_*094 7 udp network-protocols unreliable-connection
我正在阅读有关可靠UDP的实现(即发送ACK数据包并再次重新发送非确认数据包).
我似乎在网络中找到了两种主要模式:
客户端使用该数据包的序列为每个接收到的数据包发送ACK.除非收到ACK,否则服务器假定数据包未送达.
客户端发送一个ACK数据包,其中包含它认为缺失的数据包序列.服务器假定数据包已传递,除非它从客户端收到一条ACK,说它缺少序列,然后再次重新发送请求的(丢失的)数据包.
简而言之,在1.中,客户端发送接收到的数据包的序列,而在2.客户端发送丢失数据包的序列.
只是想知道每种方法的优点/缺点是什么,哪一种更主流(我假设1,但是2似乎是一种非常聪明的方法,因为大多数数据包确实到达而且通常只丢失一些).
编辑:两种方法的简短示例:
Method 1: Server sends: 1,2,3,4,5
Client received: 1,3,5,4
Client sends back: ACK 1, ACK 3, ACK 5, ACK 4
Server resends: 2.. maybe more if ACK packets were lost
Method 2:
Server sends 1,2,3,4,5,6,7,8
Client receives: 1,3,2,5,7
Client Sends :ACK (lowest continuous 3,highest received 7, seem to be missing 4,6)
Server resends: 4,6,8
Run Code Online (Sandbox Code Playgroud)
#2也称为负ACK,又名NAK,它是传输的乐观观点.这意味着当运输正常运行时,秤会更好.
#1是一个悲观的观点,并假设传输经常会失败.
TCP使用ACK,因为对拥塞控制存在基本依赖性以丢弃数据包以执行流量整形以创建公平的网络.可靠的UDP通道通常使用NAK,因为您使用的是可靠的高速中速或低速率流,在基本ACK实现的典型锁定步骤中需要低延迟.
请注意,如果您提高一步并查看可靠的UDP通道上方的订阅管理,则无法确认ACK或NAK使用情况.市场数据世界已证明在高容量网络上高速使用这两种技术.通过订阅,ACK可以在网络出现故障后不需要复杂的重新同步,但是当每个主机发出重新订阅时,您将看到网络和CPU使用率的一致峰值.