NetworkStream.Write是否会阻塞，直到它将要发送的数据放入TCP发送缓冲区，还是会阻塞，直到数据实际上由接收主机确认？什么情况会导致NetworkStream.Write阻塞？
注意：套接字配置为阻止I/O。
编辑：哎呀，当然没有TcpClient.Write这样的东西！大家都明白我们在谈论TcpClient.GetStream().Write，实际上是NetworkStream.Write！
：
成功完成发送功能并不表示数据已成功发送并已收到收件人。此功能仅表示数据已成功发送。
如果传输系统中没有可用的缓冲空间来保存要传输的数据，则发送将被阻塞，除非套接字已被置于非阻塞模式。在非阻塞的面向流的套接字上，写入的字节数可以在1和请求的长度之间，具体取决于客户端和服务器计算机上的缓冲区可用性。
假设write在下面调用send，那么对winsock文档的严格解释将表明没有保证数据在返回时将其传递到管道的另一端。
这里是链接到winsock的文档我从引用： http://msdn.microsoft.com/en-us/library/windows/desktop/ms741416(v=VS.85).aspx
TcpClient.Write将阻塞，直到数据包缓冲区已被刷新到网络并且已收到适当的ACK。您会注意到，丢弃的连接通常会在Write操作中抛出异常，因为它会等待ACK，但在定义的超时期限内没有得到该连接。
我不同意这两个答案[它声明它阻止]。写入TCP/IP套接字不会阻塞，除非底层缓冲区已经充满了未确认数据。一般来说，它不会阻止，而只是交给TCP实现。但是，当然，现在我必须去追查一些参考除非.NET是使用Winsock的比其他的东西，然后根据winsock的引用来支持这一行动:)
从SO
我似乎看到你的答案是在Mono正确的，而其他的答案似乎是正确的Windows上。我非常困惑。希望你会找到参考，因为我找不到任何结论。 –
+1表示参考。我还没有找到关于这个主题的任何其他文档，所以我假设你引用的内容可能是正确的。 –
+1引用方面的好工作（在我认为理所当然的东西上找到docos令人惊讶地很难） – tcarvin
（是的，.NET使用Windows上的Winsock的操作系统套接字。） –