当调用NetworkStream.Read(buffer,offset,size)且当前没有数据可用时，它将一直阻塞，直到收到至少一个字节，或者关闭流。
Microsoft 的NetworkStream.Read()的实现是否始终在收到第一个tcp数据包后立即返回，如果没有，在哪种情况下它会等待进一步的数据？
换句话说，当只发送一个字节时，平均大小为1的缓冲区的Read()与缓冲区大小较大的Read()的时间是否相同？
如果只发送一个字节，NetworkStream.Read(buffer,0,1)的返回速度可能会快于NetworkStream.Read(buffer,0,1024)吗？
例如当发送方没有发送TCP推送位（PSH）？
我发现有关此信息存在冲突。特别是我找到了this quote：
WSARecv文档中的如果在强制TCP层的情况下，则低延迟 至关重要，那么接收应用程序应该recv（）到小 缓冲区以提高延迟。接收缓冲区（由提供者提供） 接收应用程序）不应与接收窗口混淆 （由接收TCP层提供）。
和this remark，我认为是NetworkStream.Read()使用的基础Windows api调用：
对于TCP，这是指传入TCP段的情况 被放入接收请求数据缓冲区，其中没有 TCP段指示PUSH位值为1.在这种情况下，TCP 可能 暂停部分填充的接收请求以允许 使用具有PUSH的TCP段到达的其余数据 位设置为1。
关于丢失推送位正确的tcp数据包，我的结论是什么？
如果是这样，我可以期待的最大延迟是多少？
还有其他情况，根据缓冲区大小，Read（）可能会进一步延迟吗？