关闭套接字上的 C# TcpClient WriteAsync 不会引发异常
C# TcpClient WriteAsync on closed socket does not throw an exception
使用 TcpClient 通过网络推送数据。客户端只发送数据。在某些时候,服务器可能会关闭套接字。服务器关闭套接字后,第一个客户端发送无异常完成。客户端第二次发送抛出 IOException。
我本以为第一个客户端会向 return 发送一个 IOException,因为远端的套接字已关闭。
是否可以解释为什么会这样?
我本以为第一次发送到关闭的套接字会抛出异常,因为它没有到达远端的套接字。
重现此行为的示例代码:
const string _address = "127.0.0.1";
const int _port = 5500;
const int _payloadSize = 100;
static async Task RunTestAsync()
{
IPAddress.TryParse(_address, out IPAddress ip);
Task serverTask = Task.Run(async () =>
{
Console.WriteLine("Server listening");
IPEndPoint ipLocal = new IPEndPoint(ip, _port);
TcpListener listener = new TcpListener(ipLocal);
listener.Start();
using (TcpClient serverSocket = await listener.AcceptTcpClientAsync())
{
Console.WriteLine("Server accepted connection");
byte[] serverbytes = new byte[_payloadSize];
using (NetworkStream serverStream = serverSocket.GetStream())
{
int bytesRead = await serverStream.ReadAsync(serverbytes, 0, serverbytes.Length);
Console.WriteLine("Server received {0} bytes", bytesRead);
}
}
Console.WriteLine("Socket closed from server (CLOSE_WAIT until client closes)");
listener.Stop();
Console.WriteLine("Listener stopped");
});
using (TcpClient clientSocket = new TcpClient())
{
await clientSocket.ConnectAsync(ip, _port);
Console.WriteLine("Client connected");
byte[] clientbytes = new byte[_payloadSize];
using (NetworkStream clientStream = clientSocket.GetStream())
{
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client transmitted bytes");
await Task.Delay(2000);
Console.WriteLine("Client delay for server to close socket");
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client transmitted bytes on closed socket (FIN_WAIT_2) with no error");
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client never transmitted these bytes. Got exception instead");
}
}
await serverTask;
}
我还窃听了应用 运行。
我本以为来自第二个数据包的 RST,ACK returned 会在应用程序中生成异常,因为远端的套接字已关闭,因此数据包显然没有到达其接收者。
1 10:14:25.980424 127.0.0.1 127.0.0.1 TCP 66 50131 → 5500 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
2 10:14:25.980464 127.0.0.1 127.0.0.1 TCP 66 5500 → 50131 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
3 10:14:25.980537 127.0.0.1 127.0.0.1 TCP 54 50131 → 5500 [ACK] Seq=1 Ack=1 Win=2619648 Len=0
4 10:14:25.982960 127.0.0.1 127.0.0.1 VNC 154
5 10:14:25.982976 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [ACK] Seq=1 Ack=101 Win=2619648 Len=0
6 10:14:25.984495 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [FIN, ACK] Seq=1 Ack=101 Win=2619648 Len=0
7 10:14:25.984511 127.0.0.1 127.0.0.1 TCP 54 50131 → 5500 [ACK] Seq=101 Ack=2 Win=2619648 Len=0
8 10:14:27.986372 127.0.0.1 127.0.0.1 VNC 154
9 10:14:27.986583 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [RST, ACK] Seq=2 Ack=201 Win=0 Len=0```
请注意,在您的 Wireshark 日志中,RST 直到 FIN 后两秒才到达。 FIN 表示远程端点关闭连接。 RST 表示响应是尝试写入连接的结果。直到连接关闭后第一次尝试写入连接时才会出现此响应。
参见例如this answer 一个 TCP 行为讨论示例。
当您调用 WriteAsync()
时,将发生的只是发送字节。就是transmission个字节代表操作成功完成。 TCP 不提供字节已 收到 的确认。重要的是,在收到 RST 响应 之前 识别成功完成(实际上,通常甚至在发送之前,尽管这是时间问题,与本次讨论无关)。
发送操作为网络层提供了一个机会来接收断开连接的通知(即 RST),但在发送操作成功完成后到达。因此,在任何后续的发送操作中,API 现在知道断开的连接并可以完成并出现错误,以便您的应用程序代码可以检测到问题。
换句话说,是的……您看到的行为是正常的。这就是为什么每个应用程序级协议都必须包含优雅的闭包语义,两个端点都必须为任何套接字操作的失败做好准备,并且必须不假设是否实际接收到发送的数据。确定远程端点收到了什么的唯一方法是询问它并让它回复。
具体来说,请注意,虽然您可能不希望远程端点发送任何实际数据,但您仍然应该从套接字读取,以便您可以检测到正常关闭(即读取操作完成,长度为 0 字节).
如果您在上面的代码示例中这样做,您会看到当远程端点关闭套接字时立即报告关闭。这样,您的客户端代码就能够更及时地收到关闭通知。它不会是 error 条件的明确通知,因为端点当然可以以“发送”原因关闭套接字,同时仍在接收数据。但在您的场景中,如果您对应用程序协议的实际设计方式有更多了解,它将提供重要信息。
使用 TcpClient 通过网络推送数据。客户端只发送数据。在某些时候,服务器可能会关闭套接字。服务器关闭套接字后,第一个客户端发送无异常完成。客户端第二次发送抛出 IOException。 我本以为第一个客户端会向 return 发送一个 IOException,因为远端的套接字已关闭。
是否可以解释为什么会这样?
我本以为第一次发送到关闭的套接字会抛出异常,因为它没有到达远端的套接字。
重现此行为的示例代码:
const string _address = "127.0.0.1";
const int _port = 5500;
const int _payloadSize = 100;
static async Task RunTestAsync()
{
IPAddress.TryParse(_address, out IPAddress ip);
Task serverTask = Task.Run(async () =>
{
Console.WriteLine("Server listening");
IPEndPoint ipLocal = new IPEndPoint(ip, _port);
TcpListener listener = new TcpListener(ipLocal);
listener.Start();
using (TcpClient serverSocket = await listener.AcceptTcpClientAsync())
{
Console.WriteLine("Server accepted connection");
byte[] serverbytes = new byte[_payloadSize];
using (NetworkStream serverStream = serverSocket.GetStream())
{
int bytesRead = await serverStream.ReadAsync(serverbytes, 0, serverbytes.Length);
Console.WriteLine("Server received {0} bytes", bytesRead);
}
}
Console.WriteLine("Socket closed from server (CLOSE_WAIT until client closes)");
listener.Stop();
Console.WriteLine("Listener stopped");
});
using (TcpClient clientSocket = new TcpClient())
{
await clientSocket.ConnectAsync(ip, _port);
Console.WriteLine("Client connected");
byte[] clientbytes = new byte[_payloadSize];
using (NetworkStream clientStream = clientSocket.GetStream())
{
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client transmitted bytes");
await Task.Delay(2000);
Console.WriteLine("Client delay for server to close socket");
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client transmitted bytes on closed socket (FIN_WAIT_2) with no error");
await clientStream.WriteAsync(clientbytes, 0, clientbytes.Length);
Console.WriteLine("Client never transmitted these bytes. Got exception instead");
}
}
await serverTask;
}
我还窃听了应用 运行。
我本以为来自第二个数据包的 RST,ACK returned 会在应用程序中生成异常,因为远端的套接字已关闭,因此数据包显然没有到达其接收者。
1 10:14:25.980424 127.0.0.1 127.0.0.1 TCP 66 50131 → 5500 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
2 10:14:25.980464 127.0.0.1 127.0.0.1 TCP 66 5500 → 50131 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
3 10:14:25.980537 127.0.0.1 127.0.0.1 TCP 54 50131 → 5500 [ACK] Seq=1 Ack=1 Win=2619648 Len=0
4 10:14:25.982960 127.0.0.1 127.0.0.1 VNC 154
5 10:14:25.982976 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [ACK] Seq=1 Ack=101 Win=2619648 Len=0
6 10:14:25.984495 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [FIN, ACK] Seq=1 Ack=101 Win=2619648 Len=0
7 10:14:25.984511 127.0.0.1 127.0.0.1 TCP 54 50131 → 5500 [ACK] Seq=101 Ack=2 Win=2619648 Len=0
8 10:14:27.986372 127.0.0.1 127.0.0.1 VNC 154
9 10:14:27.986583 127.0.0.1 127.0.0.1 TCP 54 5500 → 50131 [RST, ACK] Seq=2 Ack=201 Win=0 Len=0```
请注意,在您的 Wireshark 日志中,RST 直到 FIN 后两秒才到达。 FIN 表示远程端点关闭连接。 RST 表示响应是尝试写入连接的结果。直到连接关闭后第一次尝试写入连接时才会出现此响应。
参见例如this answer 一个 TCP 行为讨论示例。
当您调用 WriteAsync()
时,将发生的只是发送字节。就是transmission个字节代表操作成功完成。 TCP 不提供字节已 收到 的确认。重要的是,在收到 RST 响应 之前 识别成功完成(实际上,通常甚至在发送之前,尽管这是时间问题,与本次讨论无关)。
发送操作为网络层提供了一个机会来接收断开连接的通知(即 RST),但在发送操作成功完成后到达。因此,在任何后续的发送操作中,API 现在知道断开的连接并可以完成并出现错误,以便您的应用程序代码可以检测到问题。
换句话说,是的……您看到的行为是正常的。这就是为什么每个应用程序级协议都必须包含优雅的闭包语义,两个端点都必须为任何套接字操作的失败做好准备,并且必须不假设是否实际接收到发送的数据。确定远程端点收到了什么的唯一方法是询问它并让它回复。
具体来说,请注意,虽然您可能不希望远程端点发送任何实际数据,但您仍然应该从套接字读取,以便您可以检测到正常关闭(即读取操作完成,长度为 0 字节).
如果您在上面的代码示例中这样做,您会看到当远程端点关闭套接字时立即报告关闭。这样,您的客户端代码就能够更及时地收到关闭通知。它不会是 error 条件的明确通知,因为端点当然可以以“发送”原因关闭套接字,同时仍在接收数据。但在您的场景中,如果您对应用程序协议的实际设计方式有更多了解,它将提供重要信息。