UDP数据包接收逻辑的优化修改以及对性能的影响

最新推荐文章于 2024-08-06 08:11:08 发布
最新推荐文章于 2024-08-06 08:11:08 发布
阅读量4k 收藏 14
点赞数 4
分类专栏： C-C++ Linux 网络技术 文章标签： udp select UDP性能测试 UDP性能 读写缓冲区
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/test1280/article/details/79779835
版权
Linux 同时被 3 个专栏收录
124 篇文章 3 订阅
订阅专栏
C-C++
97 篇文章 7 订阅
订阅专栏
网络技术
30 篇文章 1 订阅
订阅专栏

UDP数据包接收逻辑的优化修改以及对性能的影响

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <netdb.h>
#include <signal.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

static int totalMsg = 0;

void sigINT(int dwsigno)
{
    printf("totalMsg: %d\n", totalMsg);
    exit(0);
}

int openServer()
{
    struct addrinfo hints;
    memset(&hints, 0, sizeof(hints));
    hints.ai_flags = AI_PASSIVE;
    hints.ai_socktype = SOCK_DGRAM;

    struct addrinfo *res;
    static char *port = "4020";
    int e = getaddrinfo(NULL, port, &hints, &res);
    if (e == EAI_SYSTEM)
    {
        printf("openServer: getaddrinfo error=%d(%s)!!!\n", errno, strerror(errno));
        return -1;
    }
    else if (e != 0)
    {
        printf("openServer: getaddrinfo error=%s!!!\n", gai_strerror(e));
        return -1;
    }

    int fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
    if (fd < 0)
    {
        printf("openServer: create socket error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }

    int rcvBufSize = 131071;
    socklen_t optlen = sizeof(rcvBufSize);
    if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvBufSize, optlen) < 0)
    {
        printf("openServer: setsockopt error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    int rcvRealSize = -1;
    if (getsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvRealSize, &optlen) < 0)
    {
        printf("openServer: getsockopt error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    printf("recrive-buff-size: %d\n", rcvRealSize);

    if (bind(fd, (struct sockaddr *)res->ai_addr, res->ai_addrlen) < 0)
    {
        printf("openServer: bind error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    printf("create udp socket(%d) ok!\n", fd);
    return fd;
}

void monUdpSock(int udpSock)
{
    static fd_set fds;
    FD_ZERO(&fds);
    FD_SET(udpSock, &fds);

    static struct timeval tv = {0, 20000};
    int readyNum = select(udpSock+1, &fds, NULL, NULL, &tv);
    if (readyNum < 0)
    {
        printf("monUdpSock: select error=%d(%s)!!!\n", errno, strerror(errno));
        // 异常处理
        return;
    }
    else if (readyNum == 0)
        return; // select超时，do nothing
    else
        ; // 存在可读写fd

    if (!FD_ISSET(udpSock, &fds))
        return;

    static char udpMsg[1024*64]; // 64KB
    int rbytes = read(udpSock, udpMsg, sizeof(udpMsg));
    if (rbytes <= 0)
        return;
    // 处理收到的Udp消息
    totalMsg++;
}

int main()
{
    if (signal(SIGINT,sigINT) == SIG_ERR)
    {
        printf("set single handler error!\n");
        exit(1);
    }

    int udpSock = openServer();

    while (1)
    {
        monUdpSock(udpSock);
        usleep(3); // 做其他工作，占用了3ms
    }
}

如上所示是一个UDP服务端程序，用以接收UDP数据包并统计接收总量。

这个UDP Server设置自己的UDP服务Socket接收缓冲区为128K，实际在内核占用的缓冲区为256K。

在主循环中的睡眠，是为了模拟程序做其他的工作，每次耗时3ms。

性能统计小脚本：

#!/bin/bash

while [ true ]; do
    sleep 1
    netstat -an | grep $1
done

脚本功能是每秒中去netstat查看/列出指定UDP Socket的接收缓冲区队列中滞留的，尚未被read到用户态的UDP数据量。

模拟压力测试，每个UDP数据包为1800字节左右：

1）1000caps，总量100000个UDP数据包：

脚本输出部分如下：

udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp     2152      0 0.0.0.0:4020                0.0.0.0:*                               
udp     2152      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp     2152      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp     2152      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp     2152      0 0.0.0.0:4020                0.0.0.0:*

输出表明：

程序执行时，接收缓冲区存在很多数据来不及收，虽然没有太大的堆积量，也没有到接收缓冲区上限256K，但是UDP服务器并不能及时的将数据取出来（即：UDP服务器还是有问题的！！！）。

[jiang@localhost svr]$ ./main
recrive-buff-size: 262142
create udp socket(3) ok!
^CtotalMsg: 100000

实际UDP服务端收到了100000个UDP数据包，并未发生丢包。

但未丢包不代表万事大吉，只能说明，UDP服务器的处理速度（从内核读缓冲区中取数据的速度）和模拟端的写速度达到了一个相对平衡的状态。

此时如果增加一倍的caps呢？

2）2000caps，总量200000个UDP数据包：

脚本输出部分如下：

[jiang@localhost pm]$ ./netstat.sh 4020                              
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp    17216      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp     8608      0 0.0.0.0:4020                0.0.0.0:*                               
udp    15064      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp    15064      0 0.0.0.0:4020                0.0.0.0:*                               
udp     8608      0 0.0.0.0:4020                0.0.0.0:*                               
udp    15064      0 0.0.0.0:4020                0.0.0.0:*                               
udp     8608      0 0.0.0.0:4020                0.0.0.0:*                               
udp     4304      0 0.0.0.0:4020                0.0.0.0:*                               
udp     6456      0 0.0.0.0:4020                0.0.0.0:*                               
udp     8608      0 0.0.0.0:4020                0.0.0.0:*                               
udp   262544      0 0.0.0.0:4020                0.0.0.0:*                               
udp   258240      0 0.0.0.0:4020                0.0.0.0:*                               
udp   262544      0 0.0.0.0:4020                0.0.0.0:*                               
udp   260392      0 0.0.0.0:4020                0.0.0.0:*                               
udp   260392      0 0.0.0.0:4020                0.0.0.0:*                               
udp   262544      0 0.0.0.0:4020                0.0.0.0:*

输出表明：

程序运行时，由于服务端程序从内核读缓冲区中read慢了（读出速度小于写入速度），导致读缓冲区中数据堆积，UDP接收缓冲区溢出，出现丢包的情况。

[jiang@localhost svr]$ ./main
recrive-buff-size: 262142
create udp socket(3) ok!
^CtotalMsg: 170327

我模拟发送20万个UDP数据包，实际只收到170327个，丢了近3w个数据包。

我们的主循环，除了接收UDP数据包，还会干别的事情（3ms）。

最理想状态下，假如CPU时间片切换、信号唤醒等立刻完成（不耗用时间），睡眠3ms，在2000caps的情况下，意味着这3ms中将会有6个UDP数据包一定堆积。

假设一个UDP数据包100K，也就是说，从3ms开始的时刻计算，到3ms结束的时刻，共计有600K的数据堆积在缓冲区中，得不到处理。

实际情况更为复杂，堆积的数据只会比理想状态下多，绝不会比其少。

仔细观察UDP数据包接收逻辑：

    static struct timeval tv = {0, 20000};
    int readyNum = select(udpSock+1, &fds, NULL, NULL, &tv);
    if (readyNum < 0)
    {
        printf("monUdpSock: select error=%d(%s)!!!\n", errno, strerror(errno));
        // 异常处理
        return;
    }
    else if (readyNum == 0)
        return; // select超时，do nothing
    else
        ; // 存在可读写fd

    if (!FD_ISSET(udpSock, &fds))
        return;

    static char udpMsg[1024*64]; // 64KB
    int rbytes = read(udpSock, udpMsg, sizeof(udpMsg));
    if (rbytes <= 0)
        return;
    // 处理收到的Udp消息
    totalMsg++;

由于每时每刻都有数据到来，所以select并不会真的等待20ms，而是立刻返回。

即，主循环在不停歇地干两件事情：

1）从udp server sock fd中读取【一个】UDP数据包；
2）干其他事情，花费3ms；

换言之，我们可以认为至少每3ms这个周期中，才会去接收**一个**UDP数据包。

实际上，在select指明有数据到来时，我们可以不断地读取接收缓冲区中的数据包，直到缓冲区再无可读取的数据包。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <netdb.h>
#include <signal.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>

static int totalMsg = 0;

void sigINT(int dwsigno)
{
    printf("totalMsg: %d\n", totalMsg);
    exit(0);
}

int openServer()
{
    struct addrinfo hints;
    memset(&hints, 0, sizeof(hints));
    hints.ai_flags = AI_PASSIVE;
    hints.ai_socktype = SOCK_DGRAM;

    struct addrinfo *res;
    static char *port = "4020";
    int e = getaddrinfo(NULL, port, &hints, &res);
    if (e == EAI_SYSTEM)
    {
        printf("openServer: getaddrinfo error=%d(%s)!!!\n", errno, strerror(errno));
        return -1;
    }
    else if (e != 0)
    {
        printf("openServer: getaddrinfo error=%s!!!\n", gai_strerror(e));
        return -1;
    }

    int fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
    if (fd < 0)
    {
        printf("openServer: create socket error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }

    int rcvBufSize = 131071;
    socklen_t optlen = sizeof(rcvBufSize);
    if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvBufSize, optlen) < 0)
    {
        printf("openServer: setsockopt error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    int rcvRealSize = -1;
    if (getsockopt(fd, SOL_SOCKET, SO_RCVBUF, &rcvRealSize, &optlen) < 0)
    {
        printf("openServer: getsockopt error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    printf("recrive-buff-size: %d\n", rcvRealSize);

    if (bind(fd, (struct sockaddr *)res->ai_addr, res->ai_addrlen) < 0)
    {
        printf("openServer: bind error=%d(%s)!!!\n", errno, strerror(errno));
        freeaddrinfo(res);
        return -1;
    }
    freeaddrinfo(res);

    // 设置UDP服务Socket为非阻塞模式
    int sockflag;
    if ((sockflag = fcntl(fd, F_GETFL, 0)) < 0)
    {
        printf("openServer: get socket(%d) flag error=%d(%s)", fd, errno, strerror(errno));
        return -1;
    }
    sockflag = sockflag | O_NONBLOCK;
    if (fcntl(fd, F_SETFL, sockflag) < 0)
    {
        printf("openServer: set socket(%d) flag error=%d(%s)", fd, errno, strerror(errno));
        return -1;
    }

    printf("create udp socket(%d) ok!\n", fd);
    return fd;
}

void monUdpSock(int udpSock)
{
    static fd_set fds;
    FD_ZERO(&fds);
    FD_SET(udpSock, &fds);

    static struct timeval tv = {0, 20000};
    int readyNum = select(udpSock+1, &fds, NULL, NULL, &tv);
    if (readyNum < 0)
    {
        printf("monUdpSock: select error=%d(%s)!!!\n", errno, strerror(errno));
        // 异常处理
        return;
    }
    else if (readyNum == 0)
        return; // select超时，do nothing
    else
        ; // 存在可读写fd

    if (!FD_ISSET(udpSock, &fds))
        return;

    static char udpMsg[1024*64]; // 64KB
    int rbytes = read(udpSock, udpMsg, sizeof(udpMsg));
    while (rbytes > 0)
    {
        // 处理收到的Udp消息
        totalMsg++;
        rbytes = read(udpSock, udpMsg, sizeof(udpMsg));
    }
    if (rbytes < 0 &&
            errno != EAGAIN &&
            errno != EWOULDBLOCK &&
            errno != EINTR &&
            errno != EINVAL)
    {
        printf("monUdpSock: read error=%d(%s)!!!\n", errno, strerror(errno));
        return;
    }
}

int main()
{
    if (signal(SIGINT,sigINT) == SIG_ERR)
    {
        printf("set single handler error!\n");
        exit(1);
    }

    int udpSock = openServer();

    while (1)
    {
        monUdpSock(udpSock);
        usleep(3); // 做其他工作，占用了3ms
    }
}

注意：

除了在monUdpSock中不断read直到read返回非正值退出的逻辑改动之外，在openServer时，还将服务端的UDP Socket设置为非阻塞模式。

如果不是非阻塞模式会有什么后果呢？

如果read不发生错误，monUdpSock永远不会结束，即使没有UDP数据到来。

由于sock是阻塞型的，读不到就一直挂着自己（read挂起），这个线程再也没办法做别的事情（例如usleep(3)）。

如果设置为非阻塞模式，read不到数据并不会真的把自己（执行线程）挂起来，而是立刻返回-1，设置errno为EAGAIN。

我们的核心思想就是：

用read从内核接收缓冲区中尝试收一个UDP数据包，收的到，就继续尝试再收下一个……直到收不到返回。

新版的UDP服务端程序压测如下：

UDP服务端Socket接收缓冲区256KB（同上），每个消息1800B，3000caps：

udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp    10760      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp    12912      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*

略微有点堆积，但是也是正常的，那个时刻可能由于CPU调度线程没得到时间片，没来得及收。

[jiang@localhost svr]$ ./main
recrive-buff-size: 262142
create udp socket(3) ok!
^CtotalMsg: 30000

3000cap毫无压力！

最高压测：

UDP服务端Socket接收缓冲区256KB（同上），每个消息1800B，30000caps（不是3000，是3wcaps）：

[jiang@localhost pm]$ ./netstat.sh 4020
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   122664      0 0.0.0.0:4020                0.0.0.0:*                               
udp   126968      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*

此次测试是30000个包/秒，数据量也就是：30000*1800B=51MB/秒。

接收缓冲区略微有点堆积也应该是系统调度的原因。

测试共计5次，30000caps无丢包现象。

UDP Socket接收缓冲区在256KB，30000caps，1800B/消息，不会出接收缓冲区满发生丢包。

但是此时再增加量到40000caps，则总出现少许的丢包现象。

其实可以通过增大内核读缓冲区，支持更大的数据量。

通过setsockopt修改读缓冲区大小为1MB，测试100000caps（10wcaps），1800B/消息：

udp   294824      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   294824      0 0.0.0.0:4020                0.0.0.0:*                               
udp   299128      0 0.0.0.0:4020                0.0.0.0:*                               
udp   294824      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   290520      0 0.0.0.0:4020                0.0.0.0:*                               
udp   355080      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   288368      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   458376      0 0.0.0.0:4020                0.0.0.0:*                               
udp   393816      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   292672      0 0.0.0.0:4020                0.0.0.0:*                               
udp   294824      0 0.0.0.0:4020                0.0.0.0:*                               
udp   314192      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*                               
udp   294824      0 0.0.0.0:4020                0.0.0.0:*                               
udp        0      0 0.0.0.0:4020                0.0.0.0:*

堆积量挺多，不过还远未接近1MB上限，并不会发生丢包。

[jiang@localhost pm]$ ./main 10000000 100000
totalUdp: 10000000
maxRate: 100000
udp data len: 1806
loaded 1806 Bytes Data
finish 10000000 in 100.001, rate: 99999
[jiang@localhost svr]$ ./main
recrive-buff-size: 2097152
create udp socket(3) ok!
^CtotalMsg: 10000000

1000万个UDP包，一个也没有丢失，全部收到。

所谓的缓冲区，除了提供UDP数据包的数据之外，还有一个功能就是容错，容时差。

UDP数据包可以在接收缓冲区中堆积，但一定是由于某种原因暂时的堆积，例如时间片切换，可以堆积部分包，到下次线程轮到时间片时全部处理。

如果服务端程序从接收缓冲区读出的速度小于写入速度，那即使缓冲区设置再大也没有用，终将会堆满接收缓冲区并溢出丢包。

增大接收缓冲区，可以提高由于某些原因导致服务端“抖动”（间隔不规律的读出）而导致接收缓冲区满（UDP溢出）的抗性；

增强服务器消耗（从缓冲区中读出数据）的性能，可以从根本上减少读缓冲区溢出的问题。

UDP数据包是否丢失，与一个UDP数据包的大小、服务端接收缓冲区的大小、读出（接收缓冲区数据）的性能密切相关。

test1280
关注
专栏目录
冲破内核瓶颈，让I/O性能飙升~【DPDK工程师手册】
qq_28616237的博客
12-14 1783
一、什么是DPDK？ 数据平面开发套件 (DPDK [1] ,Data Plane Development Kit)是由6WIND,Intel等多家公司开发，主要基于Linux系统运行，用于快速数据包处理的函数库与驱动集合，可以极大提高数据处理性能和吞吐量，提高数据平面应用程序的工作效率。 二、DPDK的主要目的 开发DPDK的主要目的，是在数据平面应用中为快速的数据包处理提供一个简单而完善的架构。在理解此工具集之后，开发人员可以以此为基础进行新的原型设计，或简单地为我所用。 三、工作环境 DPDK的环境.
UDP数据包解析解析UDP数据包
12-11
在C#中，解析UDP数据包涉及到对网络数据的接收、解包以及数据结构的理解。以下是关于UDP数据包解析的详细知识点： 1. **基础概念**： - **UDP头**：每个UDP数据包都有一个8字节的头部，包含源端口号、目标端口号、...
UDP.rar_UDP接收_udp包_udp数据包
09-19
在Windows环境下socket编程，实现服务器端发送UDP数据包并接收客户端返回数据，客户端接收UDP数据包并返回自己的NETBIOS名
UDP数据包接收（客户端）
02-13
本代码详细解释了UDP数据包接收、创建过程，运行过程中，需要与另外一台电脑处在同一个网段中，形成一个服务器-客户端模式进行通信
TCP与UDP详解（非常详细）零基础入门到精通，收藏这一篇就够了
最新发布
Python_paipai的博客
08-06 2620
内容概要：包括 内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…技术文档也是我自己整理的，包括我参加大型网安行动、CTF和挖SRC漏洞的经验和技术要点，电子书也有200多本，由于内容的敏感性，我就不一一展示了。网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我自己录的网安视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。因此，UDP的传输速度较快，适用于实时应用。
UDP.rar_UDP数据包传输
09-20
网络编程 实现UDP数据包的传输 可以简单的传输的功能
内核udp报文截取、修改和发送
BOKE
01-15 2307
近来做一个产品需要在网关上获取特定UDP端口（假设是1000端口）的报文，并将其转发给其它设备的1000端口。虽然此类文章网上已经有很多了，但我还是贴上来，这样自己也做下记录，大家也多一份参考。 下面只给出了代码片段，自己慢慢调试。 我们假设网络拓扑如下所示： LINUX  --------- --------- ---------  | PC-1 |-------| Server |
网络编程_UDP协议发送和接收数据代码优化
辐_射的博客
04-10 861
package cn.itcast_03; import java.io.IOException; import java.net.DatagramPacket; import java.net.DatagramSocket; /* * 多次启动接收端: * Unrecognized Windows Sockets error: 0: Cannot bind * 端口被占用。
提高UDP的性能30%
yisong_net的专栏
04-20 2306
UDP进行可靠数据传输开发，在UDP每次发送数据前底层的协议是先连接一下远端主机，然后在发送数据，发送完毕在释放所建立的临时连接。因此为了不每次创建临时连接可以先连一次然后用send发送，接收端也可先连然后recv。这种情况下一般会提高UDP传输性能30%以上。并且由于连接的建立，UDP还可收到数据能否到达对应主机的通知，因此在进行UDP传输时最好先连接。
修改IP、TCP、UDP校验码
turbock的博客
07-22 1360
ipv4数据报文中修改的来源ip或目的ip后，一般需要修改对应的校验码。首先ip校验码是最基础的，然后因为TCP/UDP对应的校验码会根据伪报文头检查（其中包含src ip 和 dst ip）,所以也需要修改tcp/udp报文的校验码。这里修复了一些其他文章中的BUG，例如缓存溢出、构造TCP/UDP伪报文采用的参数等，通过实验能够正常运行。 1.IP检验码 unsigned int Che...
QT Udp/Tcp 收发 自定义复杂数据包【包头+内容】（key--len--value）
dhl11的博客
04-21 6744
在学习QT的过程，客户端/服务端 收发自定义结构体（结构体带指针的不定长数据）的处理 示例如下，首先在头文件中申明这个自定义结构体（收发部分都需要包含这个结构体定义） 其中char pValue[0]表示这个是变长的部分！！！ #pragma pack(1) struct DHPacket { int len; char pValue[0]; }; #pragma pack() 一定要记得#pragma pack(1)【c...
C++调用WinSock api实现UDP传输
qq_26341675的博客
09-08 1294
1，网络部分 实验室使用较多的是UDP0）首先，加入需要使用库的头文件#include <WinSock2.h> #pragma comment(lib,"Ws2_32.lib ")1） WSAStartup 　　初始化Ws2_32.dll的函数//函数原型 int WSAStartup( __in WORD wVersionRequested,//标识了用户调用的Wins
receive-UDP-data.zip_UDP发送_UDP数据接收_工控_数据包
09-20
在这个"receive-UDP-data.zip"压缩包中，包含了一个关于UDP数据包发送和接收的程序。工控（Industrial Control）领域经常使用UDP进行通信，因为它能够快速地传递控制指令和实时数据，这对于工业自动化设备和系统的...
get_udp_code.rar_libpcap_libpcap udp_数据包捕获
09-21
在`get_udp_code.c`中，可能包含的代码逻辑会涉及初始化Libpcap上下文，设置过滤器（比如只捕获UDP包），然后在一个循环中持续接收和处理数据包。数据包的处理可能包括打印其头部信息，或者进一步分析其负载内容。 ...
Linux内核UDP收包为什么效率低？能做什么优化？
Netfilter
08-03 9379
现在很多人都在诟病Linux内核协议栈收包效率低，不管他们是真的懂还是一点都不懂只是听别人说的，反正就是在一味地怼Linux内核协议栈，他们的武器貌似只有DPDK。 但是，即便Linux内核协议栈收包效率真的很低，这是为什么？有没有办法去尝试着优化？而不是动不动就DPDK，一窝蜂跟上去的东西，大部分都是很low的东西。 再次重申，我不写技术文档，我也不分析源码，本文只是一个思考的总结，但凡是思考...
网络协议：UDP
happy19870612's blog
10-11 2539
一 UDP协议及其特点 1.1 什么是UDP协议 UDP: User Datagram Protocol， 用户数据报协议，它是一种无连接，不可靠的传输，面向报文的一种协议。在IP协议的基础上提供了简答的功能，比如：复用分用和差错检测功能 1.2 UDP协议特点 #1 无连接： 和IP协议一样，发送数据报之前不需要建立连接，减少了网络开销和延时，节省了系统资源 #2 不可靠： 和IP协议一样，只保证尽最大努力交付，所以不保证可靠交付。因此不需要维护一些复杂的连接状态信息，适合可以接受数据丢失的
TCP、UDP数据包大小的限制
开挂的熊猫
09-04 6404
1、概述 首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 　　 其中以太网（Ethernet）的数据帧在链路层 　　 IP包在网络层 　　 TCP或UDP包在传输层 　　 TCP或UDP中的数据（Data)在应用层 　　 它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝ 　　     不同的协议层对数据包有不同的称谓，在传输层叫做段(segment)，在网络...
网络性能优化思路
qq_40500045的博客
02-21 4957
网络性能优化思路 文章目录网络性能优化思路前言一、确定优化目标二、网络性能工具网络性能优化应用程序套接字传输层网络层链路层总结 前言 网络问题比我们前面学过的 CPU、内存或磁盘 I/O 都要复杂。无论是应用层的各种 I/O 模型，冗长的网络协议栈和众多的内核选项，抑或是各种复杂的网络环境，都提高了网络的复杂性。不过，也不要过分担心，只要你掌握了 Linux 网络的基本原理和常见网络协议的工作流程，再结合各个网络层的性能指标来分析，你会发现，定位网络瓶颈并不难。找到网络性能瓶颈后，下一步要做的就是优化了
ros 封udp数据包
01-02
ROS的节点间通信可以使用UDP数据包进行传输。ROS提供了一些工具和库来封装和解析UDP数据包。 首先，需要创建一个ROS节点来封装UDP数据包。在这个节点中，需要使用ROS提供的UDP通信库来建立UDP连接，并将需要传输的数据封装成UDP数据包。这个节点可以指定UDP的发送端口和接收端口。 其次，还需要创建另一个节点来解析收到的UDP数据包。在这个节点中，同样使用ROS提供的UDP通信库来建立UDP连接，并监听指定的接收端口。当收到UDP数据包后，需要解析其中的数据并进行相应的处理。 在使用ROS封装UDP数据包的过程中，需要注意网络通信的安全性和稳定性。可以使用ROS提供的认证和加密机制来确保通信的安全。同时，需要考虑异常情况的处理，比如网络断开或UDP数据包丢失的情况，以保证通信的稳定性。 总之，通过ROS封装UDP数据包，可以在ROS系统中实现节点间的高效通信。同时，ROS提供的各种工具和库也能够简化封装和解析UDP数据包的过程，使得开发者可以更专注于节点间的通信逻辑。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值