本篇文章部分内容涉及到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对象。用于模拟主动关闭端。伪代码如下:
1 | conn, _ := net.Dial("tcp", "127.0.0.1:8081") |
server在accept新连接后,在新连接的处理函数中调用Read方法,Read返回io.EOF后不调用Close方法,直接退出处理函数,释放连接对象。伪代码如下:
1 | func handleConn(conn net.Conn) { |
启动server后,再启动client,server打印出0 EOF
。
用netstat查看连接情况:
1 | 在shell中输入 |
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代码。伪代码如下:
1 | buf := make([]byte, 1024) |
server输出如下:
1 | 2019/04/17 16:08:17 1024 <nil> |
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,则一直得到如下错误:
1 | write tcp 127.0.0.1:8081->127.0.0.1:63520: write: broken pipe |
这是由于系统调用Write会一直返回EPIPE。
场景三
本端关闭后,本端继续调用Read或Write或Close,则一直得到如下错误:
1 | 127.0.0.1:63482->127.0.0.1:8081: use of closed network connection |
这是由fd_mutex.go中的mutexClosed标志决定的,当文件描述符被关闭后,该标志会被设置,之后所有io操作都会返回错误。
本文完,作者yoko,尊重劳动人民成果,转载请注明原文出处: https://pengrl.com/p/47401/