UdpSocket从性能问题中恢复

我不确定这是否是语言特有的问题，但我还是试试看。
在我们公司的一个项目中，我们试图通过UDP实现22MB大文件的数据传输协议。我们知道TCP更适合于此，但硬件开发决定它必须是UDP。

我们的逻辑是客户端通过1500字节大小的包发送22MB的文件。每个包的头中都有一个唯一的ID。第一批约15000个包的传输大约需要一秒钟，但由于使用UDP，我们当然会丢失约2000个包。

每一批包都以一个唯一的“结束包”结束，告诉我们，来自客户端的传输已经完成，我们可以通过其唯一ID开始请求丢失的包。由于限制，我们一次只能请求255个包，因此我们必须发送大量的重新发送请求。由于端包的存在，我们不必使用套接字超时，每个请求周期的套接字超时必须为250ms，这样才能有效地避免遗漏仍在传输的包，从而造成大量时间损失。

现在来看手头的实际问题：
请求255个包并接收它们的第一个周期需要0.01秒，之后的每个周期需要0.4秒。我已经找到了问题的根源，找到了“recv_from”函数。我已经确保它在每个周期中都会收到相同数量的包，然后在“end package”结束，虽然它甚至会减少到完全相同的字节数，但它需要40倍的时间。

fn接收（套接字：&UdpSocket，buf:&mut[u8；1600]）->Vec{
让mut res:Vec=Vec！[]；
设mut x=持续时间：：秒（0）；
环路{
//时间跟踪
让我们开始=PreciseTime:：now（）；
let（n，u）=socket.recv_from（buf）.unwrap（）；
让end=PreciseTime:：now（）；
x=x+（开始到结束）；
//这里没有时间上的差异
设mut v=vec！[]；
v、 全部推送（&buf[0..n]）；
//这是一个终端包
如果v[8]==240{
打破
}
res.push（v）；
}
//在收到255个包的情况下首次调用此函数需要0.01秒，每次连续调用需要0.4秒
println！{“注：总传输时间：{}s”，x}；
//该值越高，第一次和连续呼叫之间的时间差越小
//在约500毫秒时，255个接收包的每次呼叫的平均时间约为0.02秒
睡眠时间（100）；
物件
}    

---

对不起，这是一个巨大的文本墙，这只是一个与这个问题伴随而来的大量背景；我甚至不知道我是否提到了所有相关的东西。

这是Reddit威胁说这是Windows的内核问题，通过迁移到Linux解决了。

fn receive( socket: &UdpSocket, buf: &mut [u8;1600] ) -> Vec<Vec<u8>>{
    let mut res: Vec<Vec<u8>> = vec![];

    let mut x = Duration::seconds( 0 );
    loop{
        // time tracking
        let start = PreciseTime::now();
        let ( n, _ ) = socket.recv_from( buf ).unwrap();
        let end = PreciseTime::now();
        x = x + ( start.to( end ));

        // difference in time doesn't occur here
        let mut v = vec![];
        v.push_all( &buf[ 0..n ]);

        // this is an end-package
        if v[8] == 240 {
            break;
        }
        res.push( v );

    }
    // first call of this function with 255 received package takes 0.01s, each consecutive call takes 0.4s
    println!{ "NOTE: Total transmission time: {}s", x };

    // the higher this value, the less the difference in times between the first and the consecutive calls
    // at ~ 500ms it evens out at about 0.02s per call of 255 received packages
    sleep_ms( 100 );
 res
}