winsocket 一个udp的包究竟能发多大

[yiyefangzhou24]

实际操作过程中发现无论我缓冲区设置多大，好像跟一个udp包数据量的大小无关，只要一个UDP包超过1024（1k）就收不到，但sendto和recvfrom都不报错，就是收不到数据，有没有办法能够手动改变一个udp包大小的？

[赵4老师]

不要迷信书、考题、老师、回帖； 要迷信CPU、编译器、调试器、运行结果。 并请结合“盲人摸太阳”和“驾船出海时一定只带一个指南针。”加以理解。 任何理论、权威、传说、真理、标准、解释、想象、知识……都比不上摆在眼前的事实！

[zilaishuichina]

如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

[www_adintr_com]

UDP 的最大长度是由底层网络硬件决定的. 通常以太网在链路层一个包最大为 1500 字节, 除去各部分包头UDP中的数据为 1472 字节 不过如果你的包跨越了多个路由器, 则最大数据是由中间最小的那个网络的 MTU 决定的,

[yiyefangzhou24]

引用 1 楼 zilaishuichina 的回复:

如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

我是做了分包，每个包分了32K的大小，但是我发现sendto已经发出去了，因为返回不是-1，但是recvfrom的时候一直阻塞收不到数据，如果将包大小调至1k的时候可以正常收发。 如果分1k一个包的话，对于udp这种无序协议，组包的时候有点费劲

[zilaishuichina]

引用 3 楼 yiyefangzhou24 的回复:

[quote=引用 1 楼 zilaishuichina 的回复:] 如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

我是做了分包，每个包分了32K的大小，但是我发现sendto已经发出去了，因为返回不是-1，但是recvfrom的时候一直阻塞收不到数据，如果将包大小调至1k的时候可以正常收发。 如果分1k一个包的话，对于udp这种无序协议，组包的时候有点费劲[/quote] 就算你程序逻辑不愿意分包， 一长串数据直接到了ip层，还是会被分包的 ip协议会对数据分片，就会被分成MTU -20 -8 这么大的一个包来分段发送 如果在实际网络环境中，ip层传丢了一个包，你就得依赖上层逻辑来要求发送端重传 udp就是比较费劲，想不费劲就tcp喽

[yiyefangzhou24]

引用 4 楼 zilaishuichina 的回复:

[quote=引用 3 楼 yiyefangzhou24 的回复:] [quote=引用 1 楼 zilaishuichina 的回复:] 如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

我是做了分包，每个包分了32K的大小，但是我发现sendto已经发出去了，因为返回不是-1，但是recvfrom的时候一直阻塞收不到数据，如果将包大小调至1k的时候可以正常收发。 如果分1k一个包的话，对于udp这种无序协议，组包的时候有点费劲[/quote] 就算你程序逻辑不愿意分包， 一长串数据直接到了ip层，还是会被分包的 ip协议会对数据分片，就会被分成MTU -20 -8 这么大的一个包来分段发送 如果在实际网络环境中，ip层传丢了一个包，你就得依赖上层逻辑来要求发送端重传 udp就是比较费劲，想不费劲就tcp喽[/quote]实现的是一个远程屏幕监控的一个功能，截图->压缩->传送->接受->解压缩->显示的过程，分包其实我也写了，但是我发现不同的网络环境，不同的系统一次一个包的大小不太一样，有的能一次发十几K，有的一次只能发1K，在实际环境中如何才能确定一次包大小，以便于在分包的时候知道分多少

[Henzox]

http://blog.csdn.net/henzox/article/details/43233157

[yiyefangzhou24]

引用 8 楼 zilaishuichina 的回复:

[quote=引用 6 楼 yiyefangzhou24 的回复:] [quote=引用 4 楼 zilaishuichina 的回复:] [quote=引用 3 楼 yiyefangzhou24 的回复:] [quote=引用 1 楼 zilaishuichina 的回复:] 如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

我是做了分包，每个包分了32K的大小，但是我发现sendto已经发出去了，因为返回不是-1，但是recvfrom的时候一直阻塞收不到数据，如果将包大小调至1k的时候可以正常收发。 如果分1k一个包的话，对于udp这种无序协议，组包的时候有点费劲[/quote] 就算你程序逻辑不愿意分包， 一长串数据直接到了ip层，还是会被分包的 ip协议会对数据分片，就会被分成MTU -20 -8 这么大的一个包来分段发送 如果在实际网络环境中，ip层传丢了一个包，你就得依赖上层逻辑来要求发送端重传 udp就是比较费劲，想不费劲就tcp喽[/quote]实现的是一个远程屏幕监控的一个功能，截图->压缩->传送->接受->解压缩->显示的过程，分包其实我也写了，但是我发现不同的网络环境，不同的系统一次一个包的大小不太一样，有的能一次发十几K，有的一次只能发1K，在实际环境中如何才能确定一次包大小，以便于在分包的时候知道分多少[/quote] 实际环境中的包大小，是由整个链路上的每一个转发节点（路由器）上设置的MTU的最小值决定的， linux下可以用traceroute查数据包经过的每一跳（windows下用tracert），然后一个个的ping过去，试出来 但是～ 对于应用逻辑来说，或者对于你的可靠UDP协议来说，你不需要知道这个最小MTU是多少。 就算你定的包大小，比实际环境中的最小MTU大，也没有关系，UDP下一层的IP协议会自动给你的大包分片发送的。 所以你只要保证：1、逻辑层能正确的分包，拼包，2、正确检测超时/丢失，然后重传就可以了[/quote]非常受教

[zilaishuichina]

引用 6 楼 yiyefangzhou24 的回复:

[quote=引用 4 楼 zilaishuichina 的回复:] [quote=引用 3 楼 yiyefangzhou24 的回复:] [quote=引用 1 楼 zilaishuichina 的回复:] 如果你说的是逻辑包，那么理论上无限大 关键在于你发送一个大包的时候， 发送端如何拆包，接收端如何确保收包顺序，并拼包 如果你说的是upd协议封好之后的udp包 最大数据长度为 65535 - ip头20字节 - udp头8字节 = 65507字节 如果没收到数据 1、考虑是不是路由器/防火墙拦截了超出一定长度的数据包 2、考虑在收发端分别抓包确认是否发送，是否接收到

我是做了分包，每个包分了32K的大小，但是我发现sendto已经发出去了，因为返回不是-1，但是recvfrom的时候一直阻塞收不到数据，如果将包大小调至1k的时候可以正常收发。 如果分1k一个包的话，对于udp这种无序协议，组包的时候有点费劲[/quote] 就算你程序逻辑不愿意分包， 一长串数据直接到了ip层，还是会被分包的 ip协议会对数据分片，就会被分成MTU -20 -8 这么大的一个包来分段发送 如果在实际网络环境中，ip层传丢了一个包，你就得依赖上层逻辑来要求发送端重传 udp就是比较费劲，想不费劲就tcp喽[/quote]实现的是一个远程屏幕监控的一个功能，截图->压缩->传送->接受->解压缩->显示的过程，分包其实我也写了，但是我发现不同的网络环境，不同的系统一次一个包的大小不太一样，有的能一次发十几K，有的一次只能发1K，在实际环境中如何才能确定一次包大小，以便于在分包的时候知道分多少[/quote] 实际环境中的包大小，是由整个链路上的每一个转发节点（路由器）上设置的MTU的最小值决定的， linux下可以用traceroute查数据包经过的每一跳（windows下用tracert），然后一个个的ping过去，试出来 但是～ 对于应用逻辑来说，或者对于你的可靠UDP协议来说，你不需要知道这个最小MTU是多少。 就算你定的包大小，比实际环境中的最小MTU大，也没有关系，UDP下一层的IP协议会自动给你的大包分片发送的。 所以你只要保证：1、逻辑层能正确的分包，拼包，2、正确检测超时/丢失，然后重传就可以了