大家好，又见面了，我是你们的朋友全栈君。
- 问题描述
首先对于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层，在实际传输过程中，应该尽量避免底层产生拆包，如果一个分片丢掉的话，整个包都无法交付给上层。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/163432.html原文链接：https://javaforall.cn
