UDP数据包丢失因包装大小而异

Question

I have application to test udp sockets in Qt. It is really simple. One socket binds to port and listens incomming packages. Other socket is used to send packages. First number in package is packages sent from sender, subsequent data is just for test. When receiver gets package it shows received/sent rate. You can vary package size, and timeout of timer to send packages. And I have two computers behind two different routers, which I tested like this:

Bind both sockets to same port. Add port forwarding to this port. Then send packets to 127.0.0.1 and to router external ip.

Both computers showed, that maximum size of package received is 32kb - 28b. 28b is UDP header size. I suppose.

Then I try to test in the same way between two computers. And test shows same results in one way(for example when I send from comp1 to comp2), but when I send from comp2 to comp1 maximum size is around 3kb(2975b). Comp1 does not get package larger than this.

This is code of program:

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow),
    receiveSocket(),
    sendSocket(),
    timer(),
    packetSend(0),
    packetReceived(0),
    address(),
    sendPort(63465), 
    receivePort(62345),
{
    ui->setupUi(this);

    timer.setSingleShot(false);
    timer.setInterval(100);

    receiveSocket.bind(receivePort);

    connect(&timer, SIGNAL(timeout()), this, SLOT(sendData()));
    connect(&receiveSocket, SIGNAL(readyRead()), this, SLOT(receiveData()));

    connect(ui->startButton, SIGNAL(clicked()), this, SLOT(startStopSend()));
}

MainWindow::~MainWindow()
{
    delete ui;
}


void MainWindow::receiveData()
{
    unsigned int otherSideSent = 0;
    do
    {
        receiveDatagram.resize(receiveSocket.pendingDatagramSize());
        receiveSocket.readDatagram(receiveDatagram.data(), receiveDatagram.size());
    }while(receiveSocket.hasPendingDatagrams());

    QDataStream in(&receiveDatagram, QIODevice::ReadOnly);
    in >> otherSideSent;

    float tempVal;
    std::vector<float> value;
    for (int i=0; i<receiveDatagram.size()/8 - 1;i++ )
    {
        in >> tempVal;
        value.push_back(tempVal);
    }

    packetReceived++;

    ui->packetData->setText(QString("I receive/you sent:     ")+QString::number(packetReceived)+QString("/")+QString::number(otherSideSent));
}


void MainWindow::sendData()
{
    QDataStream out(&sendDatagram, QIODevice::WriteOnly);
    out << ++packetSend;
    for(unsigned int i = 0; i < 8185; ++i)
    {
        out << 1.0 + i/100.0;
    }

    sendSocket.writeDatagram(sendDatagram, address, sendPort);
}


void MainWindow::startStopSend()
{
    if(!timer.isActive())
    {
        address.setAddress(ui->ipLine->text());
        timer.start();
    }
    else
    {
        timer.stop();
    }
}

First test, I think, showed that none router1, router2, comp1 or comp2 limits maximum size of UDP package. But only in case from comp2 to comp1 maximum package size is limited to strange number.

Question is Why?

Answer 1

Most devices support MTU/MRU up to around 1500 bytes. The fact that you can send/receive packets larger than this means you either have jumbo frames enabled all the way through, or packets are getting fragmented.

It isn't 100% clear what you are doing, but you mentioned router external IP . If the two computers are sitting on two different locations connected to the Internet via two different routers, the oversized packets that you are sending will most definitely be fragmented by the routers that "connect the Internet".

I actually think it's amazing that you can send 32KB packet from comp1 to comp2 via the Internet, if that's what you are actually doing, because the router that has to firstly fragment it won't be too happy when it receives a 32KB sized packet and have to fragment it down to, say, 32 x 1KB packets, not to mention the receiving end, that will have to reassemble it.

I am not sure what exactly it is that you are trying to test when you say 'to test udp sockets', but most network tests are performed with packets sizes less than 1518 (or 1522) bytes for this reason.