如果我通过TcpClient的NetworkStream发送数据，并且TcpClient.SendBufferSize小于数据，那么NetworkStream.Write（）方法的行为是什么？
MSDN documentation for SendBufferSize说
如果网络缓冲区小于 <您提供的数据量 将执行Write方法，多个网络发送操作 对于您对Write方法的每次调用。你可以做得更好 确保您的网络缓冲区至少为数据吞吐量 大到你的应用程序缓冲区。
所以我知道数据将在多个操作中发送，接收TCP-Stack应该透明地将它重新组合成一个连续的流。
但是在这段时间我的计划到底发生了什么？
如果SendBuffer中有足够的空间，TcpClient.GetStream().Write() will not block at all, and return immediately，那么NetworkStream.Flush().
如果我将TcpClient.SendBufferSize设置为小于数据的值，那么Write() 会阻止直到
TcpClient.SendTimeout已过期？还是以其他方式工作？它实际上是在等待TCP ACK吗？
除了较小的缓冲区大小的开销之外还有其他缺点吗？在运行中更改SendBufferSize是否有问题？
示例：
byte[] data = new byte[20] // 20 byte data
tcpClient.SendBufferSize= 10; // 10 byte buffer
tcpClient.SendTimeout = 1000; // 1s timeout
tcpClient.GetStream().Write(data,0,20);
// will this block until the first 10 bytes have been full transmitted?
// does it block until a TCP ACK has been received? or something else?
// will it throw if the first 10 bytes have not been received in 1 second?
tcpClient.GetStream().Flush(); // would this make any difference?
我的目标主要是更好地了解网络内部。
另外，我想知道这是否可能被滥用以更快地对网络故障作出反应。如果数据不经常发送，并且每个数据包足够小以便一次传输，并且在给定的消息协议中没有接收消息，则在网络错误之后可能需要很长时间才能调用下一个Write（） ;所以很长一段时间才会抛出异常。
如果SentBuffer非常小，是否会更快地发现错误，除非它发生在数据的末尾？
我可以滥用它来衡量单个数据包传输和确认所需的时间吗？