C#中关闭NetworkStream为何会导致TcpClient断开连接？

在C#中关闭TcpClient.GetStream()获取的NetworkStream实例后，关联的TCP客户端自动断开，核心原因是TcpClient和对应的NetworkStream是强绑定的生命周期共同体，二者不是互相独立的对象。

你可以把两者的关系类比成老式有线固定电话：

• TcpClient是摆在桌面上的座机机身，负责完成拨号、对接通信线路的底层工作，本身不直接暴露数据读写的接口。
• NetworkStream是和机身硬线连接的唯一听筒，是开发者实际收发数据的唯一通道。
  • 调用TcpClient.GetStream()不是生成了一个全新的、独立的数据流，只是把机身持有的底层Socket对应的读写通道引用直接返回，这个Stream没有自己独立的底层连接，所有收发操作全靠TcpClient内部封装的Socket完成。
  • 调用NetworkStream.Close()就相当于把听筒挂回机身，会直接触发挂机逻辑，连带释放底层的Socket连接，不可能出现听筒已经挂好、电话还保持接通占线的情况。

这个行为不是代码实现漏洞，是.NET设计时刻意约定的行为，核心出发点有两个：

• 规避资源泄漏：绝大多数开发场景下，开发者拿到NetworkStream之后，后续的数据收发、资源释放操作都会直接针对Stream对象执行，很多开发者不会记得最后再手动调用TcpClient.Close()。如果关闭Stream只标记流对象不可用、不连带断开底层连接，会产生大量无效的僵死TCP连接，白白占用系统端口和内存资源。
• 避免状态不一致：TCP是面向流的传输协议，连接存在的唯一意义就是承载流数据的读写。如果承载读写的Stream已经被释放，哪怕底层暂时维持连接状态，这个连接也既不能发也不能收，没有任何实际使用价值，反而会造成通信两端的连接状态错位，提升问题排查成本。

提示：如果只是需要临时暂停流的读写，不要直接调用Close()或Dispose()方法，可以通过设置流的读写超时、业务层自定义读写控制标记实现，只要NetworkStream被正式释放，关联的TCP连接一定会被断开。

测试代码 #

TcpClient tcpClient = new();
IPEndPoint ipEndPoint = new(IPAddress.Parse("xxx.xxx.xx.xx"), 1026);
tcpClient.Connect(ipEndPoint);

Console.WriteLine($"Before open stream: tcpClient.Connected == {tcpClient.Connected}");

NetworkStream stream = tcpClient.GetStream();
Console.WriteLine($"After get stream: tcpClient.Connected == {tcpClient.Connected}");

stream.Close();
Console.WriteLine($"After close stream: tcpClient.Connected == {tcpClient.Connected}");

tcpClient.Close();

运行输出 #

Before open stream: tcpClient.Connected == True
After get stream: tcpClient.Connected == True
After close stream: tcpClient.Connected == False

内容的提问来源于stack exchange，提问作者ruttergod