tcp 连接是双工的，既可以上行数据，又可以下行数据。连接断开时，两侧通道也是分别关闭的。
从 api 层面看，如果 read 返回 0 ，则说明上行数据已经关闭，后续不再会有数据进来。但此时，下行通道未必关闭，也就是说对端还可能期待收取数据。
同样，如果 write 返回 -1 ，错误是 epipe ，则表示下行通道已经关闭，不应再发送数据。但上行通道未必关闭，之后的 read 还可能收到数据。
用 shutdown 指令可以主动关闭单个通道（上行或下行）。
如果 tcp 连接只有一侧关闭，我们（skynet 中）称之为半关闭状态。在最开始，skynet 是将半关闭视为关闭的。这是因为，skynet 一开始只考虑网络游戏应用。在网络游戏中，连接被视为不可靠的，任何时候客户端都应该妥善处理服务器断开的情况，而服务器也应该处理客户端不告而别。业务层一般会额外做一套握手协议，不完全依赖 tcp 的底层协议。状态一般是不在客户端保存的。如果上一次链接上有数据没有发送到，那么下一次建立连接会重新拿取必要的数据。
所以，在 read 返回 0 ，或是 write 出错后，skynet 的底层都直接 close 连接。这种简单粗暴的方法可以大大简化底层的实现复杂度。同时，如果需要确保业务层数据交换的可靠性，就在业务层增加确认机制