大的数据包是不是拆成小于MTU的多个小包发送会好些?

csumck

如题, 比如一个100K的包,分成1.4K的几十个包发送网络不容易堵塞?
我这里客户端拉去一些大的文件(几百K)时, 如果10K分片拉取就很容易发生tcp重传, 如果分成1.4K拉取就没事.
求有经验的兄弟分享下经验.

多谢.

Fixend

但你这样调用发送函数的次数就会多，性能并不好。

csumck

Fixend 发表于 2014-07-10 19:34
但你这样调用发送函数的次数就会多，性能并不好。

确实. 有啥好办法吗?

hellioncu

非阻塞，根据send返回值决定下次发送的偏移位置

Fixend

csumck 发表于 2014-07-10 19:45
确实. 有啥好办法吗?

我比较在乎性能，所以我都是合并小的包，然后一次性发送的。
你这个一个mtu大小发一次，很明显不合适的，发送太频繁了。
至于一次发送多大，要以实际应该环境为准，你可以压力测试一下。
我这里包很小，数量多，重传的消耗可以忽略不计，
所以我这里是合并成4-8k左右一个，但不会大于64k。
如果传文件的话，可以大一点。

pppStar

8成是接收端处理有问题

一次发一个大包性能就会好? 网络底层还是按mtu 帮你分成一个一个小包发出去了, 看似用户层性能好了, 实际是把开销转移到内核层去了

folklore

以太网的话， 小包比较好，
其它网， 大的比较好～～

考虑到现在大多数是以太网卡，
在网络负载大时，
发小包的确也有必要。

如果网络负载比较小，
发大包自然比较快。

csumck

folklore 发表于 2014-07-11 10:10
以太网的话， 小包比较好，
其它网， 大的比较好～～

我们客户有PC的,也有手机的, 这两种设备是不是要区别对待? 手机算是以太网不?

cobras

手机如果用WiFi就算，用蜂窝数据就不算。不知对否。

zylthinking

难道不是 tcp 自己分包是瞎操心吗？ 除非发一个小包就 sleep 一下， 睡他几十毫秒