udp协议，一个包1K大小，不会发生内部错误吧？

[screen12]

使用udp协议，发送的数据包不超过1K（超过1K的分成1K的小包发送）。接收端最多是接收不到这个包（丢包），但如果收到了，不会发生内部错误，是吗？

我听说udp协议，发送大数据时，在传送过程中，会由于ＭＴＵ的问题，分成很多小包，以致于传送到接收端，会先丢包，或顺序发生变化。

那么１Ｋ一个包，不会再分成更小的包了吧？这样的话，接收端要么收不到，收到的话，数据就是正确的，是吗？

[珍惜生命远离CPP]

IP层可能会拆分，具体大小得看网络上经过的设备。 UDP接收到的都是正确的数据，错误的都丢弃了。

[shenyi0106]

具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

[Eleven]

如果接收端提供足够大的缓冲区，要么都收到，要么什么也收不到~

[汪宁宇]

引用 4 楼 screen12 的回复:

[quote=引用 3 楼 shenyi0106 的回复:] 具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

你说‘接收端必须64个包都收到了，才向你的应用层返回数据“，是不是说，接收缓冲区如果小64K，那么发送大于64K的数据包是不可能的？（就是一个发送一整个大于64K的包） 还想问一个问题：听说udp协议，接收到包的顺序和发送时的顺序可能不一样。这个不一样，是指应用层发送多个包，这多个包收到的顺序可能不一样？还是应用层发的包，在传输过程中被拆分成多个小包，这多个小包达到的顺序可能不一样？ 如果是后者，那你的话，我不太懂，应用层一次发送一个64K的大包，传输过程中被拆分成64个小包，到达时，你说有一个包未到，就整个丢弃。那如果64个包全到了，当然就不会丢弃，那这64个是不是会发生内部顺序错误？如果会，这组合起来的64K和发送时的就不一样了。 [/quote] 这64个包是极有可能乱序的，一般都不会按你发送的顺序来接收~~ 特别是经过多层路由~~

[screen12]

引用 5 楼 wangningyu 的回复:

[quote=引用 4 楼 screen12 的回复:] [quote=引用 3 楼 shenyi0106 的回复:] 具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

你说‘接收端必须64个包都收到了，才向你的应用层返回数据“，是不是说，接收缓冲区如果小64K，那么发送大于64K的数据包是不可能的？（就是一个发送一整个大于64K的包） 还想问一个问题：听说udp协议，接收到包的顺序和发送时的顺序可能不一样。这个不一样，是指应用层发送多个包，这多个包收到的顺序可能不一样？还是应用层发的包，在传输过程中被拆分成多个小包，这多个小包达到的顺序可能不一样？ 如果是后者，那你的话，我不太懂，应用层一次发送一个64K的大包，传输过程中被拆分成64个小包，到达时，你说有一个包未到，就整个丢弃。那如果64个包全到了，当然就不会丢弃，那这64个是不是会发生内部顺序错误？如果会，这组合起来的64K和发送时的就不一样了。 [/quote] 这64个包是极有可能乱序的，一般都不会按你发送的顺序来接收~~ 特别是经过多层路由~~ [/quote] 那就是说：只要udp协议发送的数据大小，超过了MTU的限制，在传送过程中被拆分了，收到的数据就有可能是错误了。是吗？ 只有包的大小比较小，不超过MTU，在传送过程中不会拆分，收到的才能确定是正确的，是不是？

[screen12]

引用 3 楼 shenyi0106 的回复:

具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

你说‘接收端必须64个包都收到了，才向你的应用层返回数据“，是不是说，接收缓冲区如果小64K，那么发送大于64K的数据包是不可能的？（就是一个发送一整个大于64K的包） 还想问一个问题：听说udp协议，接收到包的顺序和发送时的顺序可能不一样。这个不一样，是指应用层发送多个包，这多个包收到的顺序可能不一样？还是应用层发的包，在传输过程中被拆分成多个小包，这多个小包达到的顺序可能不一样？ 如果是后者，那你的话，我不太懂，应用层一次发送一个64K的大包，传输过程中被拆分成64个小包，到达时，你说有一个包未到，就整个丢弃。那如果64个包全到了，当然就不会丢弃，那这64个是不是会发生内部顺序错误？如果会，这组合起来的64K和发送时的就不一样了。

[screen12]

引用 2 楼 VisualEleven 的回复:

如果接收端提供足够大的缓冲区，要么都收到，要么什么也收不到~

收到的，就是正确的。是吗？如果1K的数据包在传输过程中不被分包的话（1K的会被分包吗？）

[汪宁宇]

引用 6 楼 screen12 的回复:

[quote=引用 5 楼 wangningyu 的回复:] [quote=引用 4 楼 screen12 的回复:] [quote=引用 3 楼 shenyi0106 的回复:] 具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

你说‘接收端必须64个包都收到了，才向你的应用层返回数据“，是不是说，接收缓冲区如果小64K，那么发送大于64K的数据包是不可能的？（就是一个发送一整个大于64K的包） 还想问一个问题：听说udp协议，接收到包的顺序和发送时的顺序可能不一样。这个不一样，是指应用层发送多个包，这多个包收到的顺序可能不一样？还是应用层发的包，在传输过程中被拆分成多个小包，这多个小包达到的顺序可能不一样？ 如果是后者，那你的话，我不太懂，应用层一次发送一个64K的大包，传输过程中被拆分成64个小包，到达时，你说有一个包未到，就整个丢弃。那如果64个包全到了，当然就不会丢弃，那这64个是不是会发生内部顺序错误？如果会，这组合起来的64K和发送时的就不一样了。 [/quote] 这64个包是极有可能乱序的，一般都不会按你发送的顺序来接收~~ 特别是经过多层路由~~ [/quote] 那就是说：只要udp协议发送的数据大小，超过了MTU的限制，在传送过程中被拆分了，收到的数据就有可能是错误了。是吗？ 只有包的大小比较小，不超过MTU，在传送过程中不会拆分，收到的才能确定是正确的，是不是？ [/quote] 你还没理解4楼想说的，总大小和单包数问题，通俗点理解，就是无论你的总大小，你发一次(全部或分包)，这一次是有可能丢包，当然这一次的丢包代价是不同的， 如果一次发全部时丢包，代价就太大了(你仔细想)； 如果只是分包的时候，丢了那一次的，因为只需要补发这一小包即可，代价相对会小一点； 无论如何，单包大小都要尽量控制在MTU以内，特别是UDP的，也不要去擦边，尽量留有余地吧 当然，如果你的程序不经过路由，处在同级交换机，就不需要考虑这些问题了

[Wenxy1]

不会，IP层会根据Path MTU自动分片，然后在信宿的IP层再组片。

[danscort2000]

udp 的校验是公开的,因此,内容可以被伪造和修改 无论多大的udp包,只要你这边发出去是指定长度,例如1k , 2k , 3k 那么无论中间的设备mtu有多小,无论如何重新分片,接收端会自动重新组包 1k, 2k ,3k 或者因为分片不全被丢弃 使用udp , 必须从每一个udp包都可能是伪造的这个思路出发去做,否则除非你只用在实验或者封闭环境,否则是无法经受考验的.

[screen12]

引用 7 楼 wangningyu 的回复:

[quote=引用 6 楼 screen12 的回复:] [quote=引用 5 楼 wangningyu 的回复:] [quote=引用 4 楼 screen12 的回复:] [quote=引用 3 楼 shenyi0106 的回复:] 具体的拆包和组包都是协议栈帮你完成的，对你的应用层是透明的，你应用程序感觉不到这其中的变化。 这里需要解释的唯一一点是： 1. 如果你一次发送64K的包； 2. 假设数据包的路径都是在以太网内传输； 3. 再假设以太网的MTU是1024（原本是1500，为了方便计算，假设是1024）； 那么协议栈会帮你把64K的数据分成64个1K的数据包然后发送到网络上；接收端接收时，会等待着64个1K的数据包都收到了，才向你的应用层返回数据。这里再次假设接收了63个丢了1个，那么对于协议栈而言，就意味着这64K的数据都必须要丢掉（已经收到的63K也必须丢掉），这就造成了极大的浪费。 所以，如你业务逻辑可以接受小包传输的话，最好还是在应用层拆包发送，这样即使最后一个1K丢了，那前面的63K你是已经收到了，重发最后一个1K就可以了，或者可以忍受丢掉这1K所带来的损失。效率上有大的提高

你说‘接收端必须64个包都收到了，才向你的应用层返回数据“，是不是说，接收缓冲区如果小64K，那么发送大于64K的数据包是不可能的？（就是一个发送一整个大于64K的包） 还想问一个问题：听说udp协议，接收到包的顺序和发送时的顺序可能不一样。这个不一样，是指应用层发送多个包，这多个包收到的顺序可能不一样？还是应用层发的包，在传输过程中被拆分成多个小包，这多个小包达到的顺序可能不一样？ 如果是后者，那你的话，我不太懂，应用层一次发送一个64K的大包，传输过程中被拆分成64个小包，到达时，你说有一个包未到，就整个丢弃。那如果64个包全到了，当然就不会丢弃，那这64个是不是会发生内部顺序错误？如果会，这组合起来的64K和发送时的就不一样了。 [/quote] 这64个包是极有可能乱序的，一般都不会按你发送的顺序来接收~~ 特别是经过多层路由~~ [/quote] 那就是说：只要udp协议发送的数据大小，超过了MTU的限制，在传送过程中被拆分了，收到的数据就有可能是错误了。是吗？ 只有包的大小比较小，不超过MTU，在传送过程中不会拆分，收到的才能确定是正确的，是不是？ [/quote] 你还没理解4楼想说的，总大小和单包数问题，通俗点理解，就是无论你的总大小，你发一次(全部或分包)，这一次是有可能丢包，当然这一次的丢包代价是不同的， 如果一次发全部时丢包，代价就太大了(你仔细想)； 如果只是分包的时候，丢了那一次的，因为只需要补发这一小包即可，代价相对会小一点； 无论如何，单包大小都要尽量控制在MTU以内，特别是UDP的，也不要去擦边，尽量留有余地吧 当然，如果你的程序不经过路由，处在同级交换机，就不需要考虑这些问题了 [/quote] 那么就是说：结论是这样的：如果用udp发很小的数据包（小于MTU，也不擦边），那么，接收端要么能收不到，收到的话，就是正确的。 发送比较大的包，由于在传输过程中要拆分成小包，所以收到的不一定正确。而且你不知道是哪个部分和哪个部分顺序错了，所以数据不可靠。 如果要发大的包，只能在程序中，将其拆分为小包发送，每个小包保证其在传输过程中不会再拆分了，然后在接收端，收到以后，在程序中，将其按顺序组装好（程序发送时当然会编好号）。由于每个小包不超过MTU，所以每个小包都是正确的（如果收到的话），如果哪个包没收到，程序通知发送端再发一次，全部收到后，组装好，就是正确的大包了。是吗？

[赵4老师]

udp类似寄信

[shenyi0106]

UDP头部是有效验和字段的，这个效验和的计算是需要包含你要发送的数据部分； 如果接收端丢分片，或者接收乱序，效验和检查是过不了的，所以不用担心你收上来的数据是乱序的。 只要是驱动通知你的，你就可以认为它是正确的，没有乱序，没有丢分片。