完成端口中TCP一次能发送多大数据量?

[小竹z]

RT，我知道一个MTU为1500字节，但是这是包含IP首部等信息的，在使用tcp时，发送缓冲区最好多大呢？这里最好的意思是保证一次投递(发送)完成，不需要循环投递(发送)，也就是接收端能一次接收完的数据量。
还有一个问题，假设我连续10次投递(发送)数据(假设均能在一次完成)，接收端也是接收10次吗？这10次数据会不会在底层合并成更大的数据流，导致接收端少于10次就能接收完数据，从而需要显示加入每个数据的结束标记呢？

[一叶之舟]

TCP包头中数据长度是16bit,也就是说最大65535.

[木头菇]

1.tcp一次发送多少，与用完成端口还是阻塞api，没关系。看看tcp/ip原理吧，总的来说就是“略攒一会儿一起发+攒太多了马上发。” 2.你的缓冲区设置64K就可以了。你上层调用的时候，一次投递不要太多，一次8K很够了，至于对端一次收多少，和你这边一次发多少没关系，投递也不是循环投递，一次投递成功了再投递下次，理由见1. 3.你所说的数据的结束标记，就是常说的“协议”。

[赵4老师]

不知道有多少前人掉在TCP Socket send(人多)send(病少)send(财富) recv(人多病)recv(少财富) 陷阱里面啊！ http://topic.csdn.net/u/20120210/09/51109ed0-07b9-41f2-b487-a51597f2ca01.html

[max_min_]

不用担心， 你只要发送数据给大小过来 协议会帮你解决的！

[赵4老师]

协议虽然能解决数据大小不一时发送接受，但解决不了通讯两端忙闲不一时发生同步错误。

[nextseconds]

引用 1 楼 spirit008 的回复:

1.tcp一次发送多少，与用完成端口还是阻塞api，没关系。看看tcp/ip原理吧，总的来说就是“略攒一会儿一起发+攒太多了马上发。” 2.你的缓冲区设置64K就可以了。你上层调用的时候，一次投递不要太多，一次8K很够了，至于对端一次收多少，和你这边一次发多少没关系，投递也不是循环投递，一次投递成功了再投递下次，理由见1. 3.你所说的数据的结束标记，就是常说的“协议”。

建议8k、8k比较好

[kunkun2013]

tcp没有规范语意来定义这个。也就是说它就是个stream，读或写。所有的操作都是先做后判。如果你违背，或许有时候可行，或许干脆不可行。对于它的推送都没有明确的定义，操作系统不同而不同。推送是同步还是异步也没有明确的定义。 最稳妥的办法就是发送端流式发送，接收端流式解析。没有它法。几个和几个只存在于幻想，这不存在。在调试环境下或许可行。在复杂网络环境下，这只能是自寻死路。

[独自听枫]

凡事都有约定，底层投多少，怎么投，你一次收多少，这些都不是你要考虑的。 你要做的是按照你自己设计好的约定，发送信件，收取信件。 同时检查信件的正确性，包括信件数量，质量、等等。 不要陷入网上各种极端情况的误区， 对于极端情况 只需要能判断出来，然后丢弃，重传。

[cmchao]

历史原因，貌似ipv4网卡每次只能发送64k数据，要是你发送比较频繁，每次发送量比较小，你可以把包缓存到64k发送，不过貌似有些优秀的网络编程库比如ace帮你干了这件事情，所以你不用考虑每次发多少，只管不停的发，就像往一个文件里面不断写数据一样！ 协议比较严格可以加8个字节同步字符串，那的保证数据区域不能包含同步字符串，所以不管你包粘包，还是中间有断开程序考虑不周，会丢数据，都能保证正确拆分每个包，不过这种做法效率比较差，会多发很多字符； 常用做法是每个数据包前加长度，要是发现包无法正确解析马上断开，要对方重新组包发数据。 linux对tcp处理是非常棒的，把数据按照文件来处理，其实tcp本来就是流数据，可以理解从磁盘读写文件那么一样。