一般的 ？ - 使用 TCP 协议通过连接发送的分段/分割字节的最大数量？
只是想问当数据从服务器和客户端来回发送时，字节的限制应该是多少，有了很好的反馈，我对这一点有了更多的了解，所以现在的问题是分段的大小是多少通过连接发送的字节？
因此，如果我将客户端发送到服务器的缓冲区大小设置为 3072 字节，并且将数据从服务器发送到客户端时设置为 3072 字节，那么这些字节如何分段？通过连接发送的最大字节数是多少，以便字节不会被分段？
just wanted to ask what should be the limit of bytes when data is being sent back and forth from server and client, with the great feed back i have go i understand this a bit more, so now the question is what are the size of segmented bytes sent over a connection?
So if i set a buffer size of 3072 bytes to be sent to the server from the client and the same when sending data from server to client, how are these bytes segmented? and what would be the maximum number of bytes that is sent over a connection so that the bytes dont get segmented?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
TCP 不保证客户端通过一个发送命令发送的字节数与服务器通过一个接收命令接收到的字节数相同。 TCP 是基于流的，这意味着它将连接视为字节流而不是消息流。
发送此（发送两次）：
可以接收为：
或。
或任何其他组合。
因此，您需要能够检测一条消息何时结束以及下一条消息何时开始。两种最常见的方法是使用包含长度的消息头或后缀（如换行符）来检测消息的结尾。
更新
TCP 不应该用于音频流恕我直言。原因是 TCP 保证传送所有发送的数据包。因此，如果 TCP 检测到数据包未到达，它将阻止所有排队的数据包，直到失败的数据包到达。
当传输音频时，所有数据包都到达并不重要，一个丢失的数据包不会对声音产生太大影响。丢失一点音频比让音频流完全停止要好，因为网络协议会尝试传送所有数据包。
TCP do not guarantee that the number of bytes sent with one send command in the client will be the same number of bytes received in the server with one receive command. TCP is stream based with means that it treats the connection as a stream of bytes and not a stream of messages.
Sending this (two sends):
Can be received as:
or.
or any other combination.
Hence you need to be able to detect when one message end and the next begins. The two most common ways is to either use a message header containing the length or a suffix (like a line feed) to detect the end of a message.
Update
TCP should not be used for audio streaming imho. The reason is that TCP guarantees to deliver all sent packets. Hence if TCP detects that a packet didnt arrive it will block all queued packets until the failed one arrives.
When streaming audio it's not important that all packets arrive, one lost packet wont affect the sound too much. It's better to get a little audio loss than to let the audio stream stop completely because the network protocols tries to deliver all packets.
连接的一端和另一端之间将根据该大小以及与 TCP 一起使用的协议进行关于 MTU 大小的握手。一个数据包将发送大量数据。
然而，如果您不使用低级 API，则将数据拆分/合并到数据包中是由协议栈完成的。
There will be a handshake about the
MTUsize between the one end and the other hand of the connection and according to this size and the protocols wich are used alongside withTCP. There is a amount of data which will be send with one packet.However the splitting/merging of your data into packets is done by your protocol stack if you do not use a low level API.
如果向 TCP 套接字写入 3000 字节，则接收方将收到 3000 字节。 TCP 对其之上的协议没有规定最大字节数。从 TCP 到 IP，再到堆栈再到下面的协议，是的，存在限制，但您的应用程序不必担心这一点。将以太网帧分段并重新组装为 IP 数据报等...将在您背后进行处理。
然而，您确实必须担心应用程序级别的协议，即基于 TCP 的协议。尽管 TCP 将传送所有 3000 个字节，但不能保证单次调用 receive（或任何 java/php 语言等效项）将立即返回所有 3000 个字节。在从套接字读取所有 3000 字节之前，您可能需要多次调用它。
请参阅此处了解更多信息：
如何知道什么时候完成接收 TCP 流吗？
If you write 3000 bytes to a TCP socket you will receive 3000 bytes at the receiving peer. There is no maximum number of bytes imposed by TCP on the protocol above it. From TCP down to IP down the stack to the protocols below, yes there are limits but your application doesn't have to worry about that. The segmentation and reassambly of ethernet frames into ip datagrams etc... will be take care of behind your back.
However you do have to worry about your protocol at the application level, the one riding on top of TCP. Although TCP will deliver all the 3000 bytes there is no gaurantee that a single call of recv (or whatever the java/php language equivalent is) will return all 3000 bytes at once. You might have to call it several times before all 3000 bytes are read from the socket.
See here for more info:
How to know when you finish receiving a TCP stream?
除非您正在编写 TCP 协议包装器，否则您提出这个问题的事实就很好地表明您正在错误地解决您试图解决的任何问题。您指定的语言中的 TCP 实现充当抽象，这应该使这个问题的答案完全无关。
请参阅此处，了解我对有关数据包重组的类似问题的回答：
监视套接字是否有新数据然后处理该数据的最佳方法是什么？
Unless you're writing a TCP protocol wrapper the fact that you're asking this question is a pretty good indication that you're approaching whatever problem you're trying to solve incorrectly. TCP implementations in the languages you specified act as abstractions that should make the answer to this question entirely irrelevant.
See here for my answer to a similar question about packet reassembly:
What's the best way to monitor a socket for new data and then process that data?