关于recvfrom使用过程中的一个坑点

• 问题描述

首先对于recvfrom的原型如下：

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);

返回值为读取到的字节长度，这里有一个坑点，我们在接收时需要传入一个buffer用于拷贝接收到的数据，传入参数包括buffer的首地址和长度，如果这里buffer长度小于这个udp包的长度会如何呢，recvfrom是否会返回一个小于0的值提示我们调用失败呢？测试代码，客户端：

发送一个4096字段的udp包，此外我们不可以设置socket的不分片策略，否则会出现发送失败，提示msg too large，服务端程序如下：

最终运行结果为在服务端收到了2048个字节之后，程序阻塞在了第二次recvfrom这里，第一次没有接收完的部分第二次并不能接收。

 

• 原因分析

这个需要深入到recvfrom的源码来进行分析，这里只截取了内核源码中的关键部分，如下：

从这里可以看到，当取到这个skb之后，判断了实际包大小与buffer大小关系，取最小值，从而只把部分包COPY到缓存中，其它部分被丢弃了，因此在实际应用中，recvfrom传入的buffer大小应该是一个大于udp单个包大小的值，大于65536，这样的话无论如何都不会出现问题。

 

• 问题扩展

在实际应用过程中，我们在进行UDP发包时通常会考虑小于MTU，正常MTU一般为1500，其实如果大于这个值UDP包也是可以正常发送的，在上述测试过程中，抓包结果如下：

可以看到包发出后，实际上发生了IP分片，后两个udp包为分片包，到达源端之后，被IP层组装后再交给UDP层，在实际传输过程中，应该尽量避免底层产生拆包，如果一个分片丢掉的话，整个包都无法交付给上层。