网络传输一丢丢记录【数据包大小限制】

我会带着你远行 2021-11-22 09:20 651阅读 0赞

今早用udp传一个对象序列化字节数组，大小达到了7000+字节，然后udp的send就报异常；

“一个在数据报套接字上发送的消息大于内部消息缓冲区或其他一些网络限制，或该用户用于接收数据报的缓冲区比数据报小。”

网上查了一下，说是超过udp的单包容量（一般不超过1000字节），所以报错。如果用udp传大的数据包（比如传一个文件）标准做法是分包发送，比如，先把文件分包，256一个包，每包数据的第一个字节，放包序号，这样收到后，再组装。传小数据，则不用分包。

相关有用参考

UDP不会自动拆包，必须在发送前自行将数据拆分后发送，超过1500的必须拆分，安全起见设定为1400。  
另外为了UDP传输的安全性，每个数据包的前面第一个字节必须用来存放当前包序号，为了序号不连续的丢包现象能及时被发现并重传，而整个数据的大小应该在序号为0的数据包后仅跟着4字节长度（int类型）来指明。

如果你传超过以太网帧（1500字节左右）的数据，udp就不太适合，否则udp可能乱序，你自己维护序列号得烦死你

可是为什么99%的情况下传几十k的数据都没问题呢？我……

如果我没记错，TCP/IP详解里说了udp是可以自动分片的，因为udp是传输层，而分片是更底层的ip层做的，不是一个层级  
  
你的问题可能就是传输中丢包或乱序了

彻底解决udp的丢包和乱序，需要有个流水号记录顺序和丢失状况，还有有超时重发机制，这个超时重发通常又是重发全部而不是一个包，因为你不知道哪个包丢了，让对端告诉你的话这个“通知”一样可能丢  
  
如果udp没开校验和，还需要加个crc之类的保证没有电磁干扰造成的错误  
  
最后就相当于自己实现tcp，开销往往比直接用tcp还大  
  
所以udp只适合不怕丢包，不怕乱序的场合

[https://bbs.csdn.net/topics/390101585][https_bbs.csdn.net_topics_390101585]

[https://bbs.csdn.net/topics/432364][https_bbs.csdn.net_topics_432364]

[https://bbs.csdn.net/topics/320152618][https_bbs.csdn.net_topics_320152618]

udp有限制  
  
常见IP碎片攻击详解  
[http://fanqiang.chinaunix.net/a5/b2/20021205/060200350.html][http_fanqiang.chinaunix.net_a5_b2_20021205_060200350.html]  
1. 为什么存在IP碎片  
\-=-=-=-=-=-=-=-=-=-=-=  
链路层具有最大传输单元MTU这个特性，它限制了数据帧的最大长度，不同的网络类型都有一  
个上限值。以太网的MTU是1500，你可以用 netstat -i 命令查看这个值。如果IP层有数据包  
要传，而且数据包的长度超过了MTU，那么IP层就要对数据包进行分片（fragmentation）操  
作，使每一片的长度都小于或等于MTU。我们假设要传输一个UDP数据包，以太网的MTU为150  
0  
字节，一般IP首部为20字节，UDP首部为8字节，数据的净荷（payload）部分预留是  
1500-20-8=1472字节。如果数据部分大于1472字节，就会出现分片现象。

(1)控制包的大小 IP层最大65535字节（ip包头长度16bit）决定UDP最大为65535－20－8（28为Ip包头与udp包头大小之和），链路层MTU(不同介质MTU大小不同,最小的296），当IP包大于MTU会造成IP层分片，容易导致丢片，所以为了避免分片常用包的大小为256，有的为512。  
(2)把文件流按统一长度，分包发送。每个包至少两部分组成：顺序号＋文件字节数据。  
(3)接收时，安照顺序号，把收到的数据组装成一个文件。  
(4)第一个包　包括：总文件长度，数据包数；最后一个包　加上结束标志  
(5)还可以加校验位，数据包中的规则自己可以发挥，根据需要自己规定就行了。

以下两篇讲的很好

[https://www.cnblogs.com/HPAHPA/p/7737641.html][https_www.cnblogs.com_HPAHPA_p_7737641.html]

[https://www.cnblogs.com/HPAHPA/p/7737531.html][https_www.cnblogs.com_HPAHPA_p_7737531.html]

[https_bbs.csdn.net_topics_390101585]: https://bbs.csdn.net/topics/390101585
[https_bbs.csdn.net_topics_432364]: https://bbs.csdn.net/topics/432364
[https_bbs.csdn.net_topics_320152618]: https://bbs.csdn.net/topics/320152618
[http_fanqiang.chinaunix.net_a5_b2_20021205_060200350.html]: http://fanqiang.chinaunix.net/a5/b2/20021205/060200350.html
[https_www.cnblogs.com_HPAHPA_p_7737641.html]: https://www.cnblogs.com/HPAHPA/p/7737641.html
[https_www.cnblogs.com_HPAHPA_p_7737531.html]: https://www.cnblogs.com/HPAHPA/p/7737531.html