如何正确关闭TCP连接
先上结论
- Read方法返回EOF错误，表示本端感知到对端已经关闭连接（本端已接收到对端发送的FIN）。此后如果本端不调用Close方法，只释放本端的连接对象，则连接处于非完全关闭状态（CLOSE_WAIT）。即文件描述符发生泄漏。
- Write方法返回broken pipe错误，表示本端感知到对端已经关闭连接（本端已接收到对端发送的RST）。此后本端可不调用Close方法。连接处于完全关闭状态。
- 由于golang里net.conn内部对文件描述符的所有io操作都有状态保护，所以即使在对端或本端关闭了连接之后，依然可以任意次数调用Read、Write、Close方法。
个人认为正确、简单、语义清晰、高效的做法：应该在Read或Write返回错误后调用Close。不论是主动关闭还是被动关闭，调用Close后，不应该再Read或Write，并尽快释放net.conn对象(也可以理解为在关闭连接之前一定要确保对端不会再发数据过来，一定要处理完对端的数据后才能关闭)。
部分demo测试与分析
我的测试环境： go version go1.13.1 darwin/amd64
第三方工具： netstat和wireshark
验证结论一
假设我们有两个demo程序——server和client。
client主动连接上server后不做任何操作，直接关闭net.conn对象。用于模拟主动关闭端。代码如下：
package main
import (
"log"
"net"
)
func main(){
conn, err := net.Dial("tcp", "127.0.0.1:8888")
if err != nil {
log.Println("dial error:", err)
return
}
defer conn.Close()
}
server在accept新连接后，在新连接的处理函数中调用Read方法，Read返回io.EOF后不调用Close方法，直接退出处理函数，释放连接对象。代码如下：
package main
import (
"log"
"net"
)
func main() {
listen, err := net.Listen("tcp", "127.0.0.1:8888")
if err != nil {
panic(err)
}
defer listen.Close()
for {
conn, err := listen.Accept()
if err != nil {
panic(err)
}
buf := make([]byte, 1024) //读一次
n, err := conn.Read(buf)
log.Println(n, err)
//conn.Close()
}
}
启动server后，再启动client，server打印出0 EOF。
用netstat查看连接情况：
$netstat -an | grep 8888
TCP 127.0.0.1:2593 127.0.0.1:8888 FIN_WAIT_2
TCP 127.0.0.1:8888 0.0.0.0:0 LISTENING
TCP 127.0.0.1:8888 127.0.0.1:2593 CLOSE_WAIT
client处于FIN_WAIT_2状态，说明client发送了FIN，并收到了对应的ACK。
server处于CLOSE_WAIT状态，说明server收到了FIN，并发送了对应的ACK。
用wireshark抓包：
再测试一遍，发现client发送了FIN，server回复了对应的ACK。但是server并没有发送FIN。与netstat显示的状态相符合。
修改server代码，在Read返回EOF后，调用conn.Close()
重新测试，再使用netstat和wireshark分析，发现server也发送了FIN，两端都正常关闭。
验证结论二
修改server代码。伪代码如下：
package main
import (
"log"
"net"
"time"
)
func main() {
listen, err := net.Listen("tcp", "127.0.0.1:8888")
if err != nil {
panic(err)
}
defer listen.Close()
for {
conn, err := listen.Accept()
if err != nil {
panic(err)
}
buf := make([]byte, 1024)
time.Sleep(5 * time.Second)
n, err := conn.Write(buf)
log.Println(n, err)
time.Sleep(5 * time.Second)
n, err = conn.Write(buf)
log.Println(n, err)
}
}
server输出如下：
2021/09/15 21:11:24 1024 <nil>
2021/09/15 21:11:29 0 write tcp 127.0.0.1:8081->127.0.0.1:14856: write: broken pipe
server的第一次Sleep 5秒是为了确保在第一次Write之前client已关闭连接，实际测试不加这个时间也可以。
用netstat观察：
我们发现在5秒内，server处于CLOSE_WAIT状态，client处于FIN_WAIT_2状态。
5秒之后，两端都进入完全关闭状态。
用wireshark抓包：
发现5秒后，server向client发送第一次1024字节数据后，client向server回复了RST包。
10秒后，server并不会再发送第二次的1024字节数据。
server的第二次Sleep 5秒是为了确保在第一次Write之后，server接收到了RST包。如果去掉第二次的Sleep，可能出现server连续发送两次数据给client，client回复两次RST给server。
Server端收到RST包后，也不用再回复ACK了，直接关闭连接。
如果是服务端收到请求立马close掉，客户端sleep 2次往conn里write数据，第一次可以写成功，第二次也会报"broken pipe"的错误。
验证结论三
场景一
对端关闭后，本端一直Read，则一直得到EOF错误。
这是由于系统调用Read会一直返回0。
场景二
对端关闭后，本端一直Write，则一直得到如下错误：
write tcp 127.0.0.1:8081->127.0.0.1:14856: write: broken pipe
这是由于系统调用Write会一直返回EPIPE。
场景三
本端关闭后，本端继续调用Read或Write或Close，则一直得到如下错误：
127.0.0.1:63482->127.0.0.1:8081: use of closed network connection
127.0.0.1:63448->127.0.0.1:8081: use of closed network connection
这是由fd_mutex.go中的mutexClosed标志决定的，当文件描述符被关闭后，该标志会被设置，之后所有io操作都会返回错误。
