UDP socket查询高速缓存

秒速五厘米 2023-07-04 04:49 4阅读 0赞

UDP没有连接的概念，所以UDP不会保存 ***“正在和谁通信的信息”*** ，换句话说，UDP数据的发送是oneshot的。

我们来做个实验，两台机器分别部署UDP的server和client。

先看server：

#define PORT 2222
    int main()
    { 
    	int sockfd;
    	char buffer[MAXLINE];
    	char *tosend = "aaaaaaaaaaa";
    	struct sockaddr_in servaddr, cliaddr;
    
    	sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    
    	servaddr.sin_family = AF_INET;
    	servaddr.sin_addr.s_addr = inet_addr("192.168.56.101");
    	servaddr.sin_port = htons(PORT);
    
    	bind(sockfd, (const struct sockaddr *)&servaddr, sizeof(servaddr));
    
    	n = recvfrom(sockfd, (char *)buffer, 64, MSG_WAITALL, ( struct sockaddr *) &cliaddr, &len);
    	sendto(sockfd, (const char *)tosend, strlen(tosend), MSG_CONFIRM, (const struct sockaddr *) &cliaddr, len);
    
    	return 0;
    }

server逻辑很简单，接受client的一个buffer，然后回复一堆aaaaaaa…

再看client：

#define PORT 2222
    
    int main()
    { 
    	int sockfd;
    	char buffer[MAXLINE];
    	char *tosend = "bbbbbbbbbbbbb";
    	struct sockaddr_in	 servaddr;
    
    	sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    
    	servaddr.sin_family = AF_INET;
    	servaddr.sin_port = htons(PORT);
    	servaddr.sin_addr.s_addr = inet_addr("192.168.56.101");
    
    	sendto(sockfd, (const char *)tosend, strlen(tosend), MSG_CONFIRM, (const struct sockaddr *) &servaddr, sizeof(servaddr));
    	n = recvfrom(sockfd, (char *)buffer, 64, MSG_WAITALL, (struct sockaddr *) &servaddr, &len);
    	printf("data: %s %d\n", buffer, htons(servaddr.sin_port));
    
    	return 0;
    }

在client上配置iptables规则：

iptables -t raw -A INPUT -p udp -j NOTRAC
    iptables -t nat -A INPUT -p udp --sport 2222 -j SNAT --to-source :12345

意思很简单，client给server的2222端口发送一堆b，然后server使用12345端口回复一堆a给client。作为iptables的替代，在recvfrom和sendto之间再次bind不同的address即可。

这肯定是可行的，数据是可以发送成功的。

*  ***两个UDP socket互相通信，源端口是可以不断变化的。***

UDP接收端在真的收到数据报文之前，是不知道源端口变化了的，按照UDP的规范，UDP socket在协议栈里不能以4元组来组织，而只能通过 ***\{本地IP地址，本地端口\}*** 来组织。

即便是connected UDP也不行。

> connected UDP在查找时只是在compare时附加了源IP地址和源端口的检测。

这意味着一些高负载流式的UDP服务（***用UDP传输流式数据，比如quic***）在 ***连接数*** （即唯一四元组的数量）很多时，socket无法通过四元组很好地进行散列，而只能退化成一条链表：

*  ***服务端的端口与IP均相同。（相关的socket会hash到同一个bucket）***
 *  ***客户端的端口与IP无法被利用（按照UDP语义和规范，它们‘可能’会发生变化）。***

但是，可以为四元组加个缓存！

我们看Linux内核的实现，为了优化查询性能，在 ***目标端口*** hash之外，引入了一个 ***\{目标IP，目标端口\}*** 二元组hash，当端口hash表冲突链长度大于10时，启用二元组hash查询。

然而，无济于事！

为了解决这个问题，加个四元组hash表查询缓存是一个正确的思路。缓存是规范外的。

我们可以看到，类似nf\_conntrack，UDP防火墙等等均采用了 ***“UDP四元组作为连接性”*** 来优化查询性能的。我们看一个nf\_conntrack的例子：

ipv4     2 udp      17 22 src=192.168.56.101 dst=192.168.56.110 sport=2222 dport=45069 [UNREPLIED] src=192.168.56.110 dst=192.168.56.101 sport=45069 dport=12345 mark=0 zone=0 use=2

--------------------

实现这个代码非常简单，照猫画虎UDP socket组织的hash2即可，在hash2操作的地方，按照引入一个四元组hash3的对应操作即可：

*  ***udp\_lib\_get\_port：*** 按照四元组插入hash3。
 *  ***\_\_udp4\_lib\_lookup\_skb：*** 先按照四元组查询hash3。
 *  ***udp\_lib\_rehash：*** 如果探测到元组变化，则更新hash3。
 *  ***udp\_lib\_unhash：*** 结束时，从hash3中摘除当前socket四元组item。

是不是很简单呢？当然，经理并不这么认为。

--------------------

浙江温州皮鞋湿，下雨进水不会胖。