golang 网络编程之如何正确关闭tcp连接以及管理它的生命周期
欢迎访问我的个人网站获取更佳阅读排版 golang 网络编程之如何正确关闭tcp连接以及管理它的生命周期 | yoko blog (https://pengrl.com/p/47401/)
本篇文章部分内容涉及到tcp协议以及socket编程的通用底层知识。讨论的tcp连接对象皆为golang的net.conn对象。如果存在错误，请一定指正，谢谢。
先上结论
- 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.11.4 darwin/amd64
第三方工具： netstat和wireshark
验证结论一
假设我们有两个demo程序——server和client。
client主动连接上server后不做任何操作，直接关闭net.conn对象。用于模拟主动关闭端。伪代码如下：
conn, _ := net.Dial("tcp", "127.0.0.1:8081")
conn.Close()
server在accept新连接后，在新连接的处理函数中调用Read方法，Read返回io.EOF后不调用Close方法，直接退出处理函数，释放连接对象。伪代码如下：
func handleConn(conn net.Conn) {
buf := make([]byte, 1024)
n, err := conn.Read(buf)
log.Println(n, err)
//conn.Close()
}
启动server后，再启动client，server打印出0 EOF。
用netstat查看连接情况：
# 在shell中输入
$netstat -an | grep 8081
tcp4 0 0 127.0.0.1.8081 127.0.0.1.62871 CLOSE_WAIT
tcp4 0 0 127.0.0.1.62871 127.0.0.1.8081 FIN_WAIT_2
tcp46 0 0 *.8081 *.* LISTEN
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代码。伪代码如下：
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输出如下：
2019/04/17 16:08:17 1024 <nil>
2019/04/17 16:08:18 0 write tcp 127.0.0.1:8081->127.0.0.1:64124: 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。
验证结论三
场景一
对端关闭后，本端一直Read，则一直得到EOF错误。
这是由于系统调用Read会一直返回0。
场景二
对端关闭后，本端一直Write，则一直得到如下错误：
write tcp 127.0.0.1:8081->127.0.0.1:63520: 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操作都会返回错误。
