大的數(shù)據(jù)包是不是拆成小于MTU的多個(gè)小包發(fā)送會(huì)好些?

csumck

如題, 比如一個(gè)100K的包,分成1.4K的幾十個(gè)包發(fā)送網(wǎng)絡(luò)不容易堵塞?
我這里客戶端拉去一些大的文件(幾百K)時(shí), 如果10K分片拉取就很容易發(fā)生tcp重傳, 如果分成1.4K拉取就沒(méi)事.
求有經(jīng)驗(yàn)的兄弟分享下經(jīng)驗(yàn).

多謝.

Fixend

但你這樣調(diào)用發(fā)送函數(shù)的次數(shù)就會(huì)多，性能并不好。

csumck

Fixend 發(fā)表于 2014-07-10 19:34
但你這樣調(diào)用發(fā)送函數(shù)的次數(shù)就會(huì)多，性能并不好。

確實(shí). 有啥好辦法嗎?

hellioncu

非阻塞，根據(jù)send返回值決定下次發(fā)送的偏移位置

Fixend

csumck 發(fā)表于 2014-07-10 19:45
確實(shí). 有啥好辦法嗎?

我比較在乎性能，所以我都是合并小的包，然后一次性發(fā)送的。
你這個(gè)一個(gè)mtu大小發(fā)一次，很明顯不合適的，發(fā)送太頻繁了。
至于一次發(fā)送多大，要以實(shí)際應(yīng)該環(huán)境為準(zhǔn)，你可以壓力測(cè)試一下。
我這里包很小，數(shù)量多，重傳的消耗可以忽略不計(jì)，
所以我這里是合并成4-8k左右一個(gè)，但不會(huì)大于64k。
如果傳文件的話，可以大一點(diǎn)。

pppStar

8成是接收端處理有問(wèn)題

一次發(fā)一個(gè)大包性能就會(huì)好? 網(wǎng)絡(luò)底層還是按mtu 幫你分成一個(gè)一個(gè)小包發(fā)出去了, 看似用戶層性能好了, 實(shí)際是把開(kāi)銷(xiāo)轉(zhuǎn)移到內(nèi)核層去了

folklore

以太網(wǎng)的話， 小包比較好，
其它網(wǎng)， 大的比較好～～

考慮到現(xiàn)在大多數(shù)是以太網(wǎng)卡，
在網(wǎng)絡(luò)負(fù)載大時(shí)，
發(fā)小包的確也有必要。

如果網(wǎng)絡(luò)負(fù)載比較小，
發(fā)大包自然比較快。

csumck

folklore 發(fā)表于 2014-07-11 10:10
以太網(wǎng)的話， 小包比較好，
其它網(wǎng)， 大的比較好～～

我們客戶有PC的,也有手機(jī)的, 這兩種設(shè)備是不是要區(qū)別對(duì)待? 手機(jī)算是以太網(wǎng)不?

cobras

手機(jī)如果用WiFi就算，用蜂窩數(shù)據(jù)就不算。不知對(duì)否。

zylthinking

難道不是 tcp 自己分包是瞎操心嗎？ 除非發(fā)一個(gè)小包就 sleep 一下， 睡他幾十毫秒