最近在公司写了个基于UDP协议的日志收集服务，逻辑很简单，客户端(PHP应用)通过socket把数据发过来，服务端记录日志并返回成功。由于开发测试时Server和Client都是同一台机器上，一直平安无事。后来又找了台机器想做一下压力，却发现无论如何Client都不到回包。通过tcpdump看，Server端的确已经回包了，但Client机器上只能看到一个发包。
这个问题排查了整个下午，因为一直没有头绪。最初想到的是网络原因，可能端口被防火墙拦截，但用nc试验收发包，没有问题，所以排除了网络原因。然后怀疑是不是某些系统调用出问题了？写了一段最简单的udp收发包代码，发现也没有问题。然后怀疑是不是框架出问题了，打了一些点，重新编译，也没有发现异常，这时想到之前用同一个框架写的服务，找出来编译运行，发现竟然可以正常收发包。然后我开始修改这个服务的发包部分，逐渐减少sendto的内容，直到不行，这时开始怀疑是不是UDP包有最小长度限制。
因为日志服务逻辑简单，返回内容也很简单，返回内容包括开始结束标识、请求序列号、结果字段，加起来才8个字节。这时我随便增加几个返回字节，发现Client已经可以正常收到回包，问题算是解决了。最后测试出UDP包长不能低于12个字节，这其中不包括UDP自己的8个字节的头部。
再用nc试验，验证了这个问题：
（1）Server端，用nc监听5544端口，如果有请求则返回a.txt文件中的内容，a.txt中是两个字符；
（2）Client端，用nc给Server端发包；
（3）Server端的tcpdump，可以看到收到了包也回了包，回包长度length=2；
（4）Client端的tcpdump，只能看到发包，看不到回包。用netstat -us也没有看到收包错误的增加。
（5）这时将Server端的返回增加到12个字节（文件末尾还有一个字节），可以看到Client端可以正常收到回包。
继续查这个问题，发现有人说：
“802.3 规定数据部分至少为38字节，以太网最少要46字节.不足的空间插入填充字节.”
其中，IP头部是20字节（包括双方IP、长度、控制字段等），UDP头部是8个字节（包括双方端口、长度、校验和），这两个头部占用了28个字节。
其他参考：
TCP/IP详解学习笔记（8）– UDP：用户数据报协议
http://www.cnblogs.com/newwy/p/3227767.html
IP数据包长度问题总结
http://blog.csdn.net/naturebe/article/details/6712153联系客服
