最近在写一点通讯方面的代码，我的程序逻辑可能在判断到某些异常是需要断开客户端socket的链接。

看官方文档，提供了 client.end() 方法和 client.destory()方法，好像都可以用来断开连接。

看官方描述，如果你调用了end方法，你会将socket置于半关闭（Half-closes）状态，然后他会发送一个 FIN 包给对端，这个时候呢，服务器可能还是会发送数据给你的。（表示这个时候的还是可读的？）

如果你调用的是destroy方法，官方描述是 “确保此套接字上不再发生I/O活动，破坏流并关闭连接。”(Ensures that no more I/O activity happens on this socket. Destroys the stream and closes the connection.)，看起来像是会彻底摧毁套接字，此时应该不可以再进行读写了。

网上查了一些资料，有点发现。

这张图是默认TCP链接被终止时，应该走的流程。

主动断开的是左侧，被动断开的是右侧

左端主动关闭要发起一个FIN包，告诉右端我想关闭连接，然后将自己置于终止等待1(FIN_WAIT_1)状态。
右端收到FIN包时被动关闭，此时知道左端想关闭连接。右端会立刻回复一个ACK包给左端，然后将自己状态改成等待关闭（CLOSE WAIT）,并且通知上层应用，对端想关闭连接了，咋办？
左端收到右端的ACK之后，知道右端已经知道我想关闭链接啦，此时进入终止等待2(FIN_WAIT_2)状态，等待右侧的FIN包。
右端的上层应用会说，好吧，关闭吧，然后协议栈就会发送FIN包给左端（此时仍然可以发送数据给左端，左端也可以读到）。然后进入最后确认状态（LAST_ACK），此刻等待左端的一个ACK就能真的关闭了。
左端收到右端的FIN包之后，就知道状况了，进入一个时间等待（TIME_WAIT）的状态，然后等待2MSL时间，然后关闭连接
右端收到这个ACK包之后，也会从LAST_ACK状态关闭连接，释放端口号和资源。

这大概是TCP断开连接的四次挥手过程，虽然复杂但是很严谨。

这里说下最后这个2MSL等待时间是啥意思，不是2毫秒的意思哦。

通信所要解决的首要问题就是，保持通信双方的信息对称，使通信双方处于同步状态。

TCP四次挥手遵循的套路大概是这样：

主动断开的一侧为A，被动断开的一侧为B。

第一个消息：A发FIN

第二个消息：B回复ACK

第三个消息：B发出FIN

此时此刻：B单方面认为自己与A达成了共识，即双方都同意关闭连接。

此时，B能释放这个TCP连接占用的内存资源吗？不能，B一定要确保A收到自己的ACK、FIN。

所以B需要静静地等待A的第四个消息的到来：

第四个消息：A发出ACK，用于确认收到B的FIN

当B接收到此消息，即认为双方达成了同步：双方都知道连接可以释放了，此时B可以安全地释放此TCP连接所占用的内存资源、端口号。

所以被动关闭的B无需任何wait time，直接释放资源。

但，A并不知道B是否接到自己的ACK，A是这么想的：

1）如果B没有收到自己的ACK，会超时重传FiN

那么A再次接到重传的FIN，会再次发送ACK

2）如果B收到自己的ACK，也不会再发任何消息，包括ACK

无论是1还是2，A都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，这个最坏情况是：

去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。

这恰恰就是2MSL( Maximum Segment Life)。

等待2MSL时间，A就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。为何一定要等2MSL？
如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满足这个需求（尽管非常保守）！

我擦，好像跑题了。

下面是我的个人理解，不一定准确。

如果你调用client.end()方法，会触发end事件和close事件。如果你调用client.destory()方法，只会触发close事件。

net.Server这个对象在构造的时候，可以传一个重要的参数 allowHalfOpen，默认是false。对于这个参数的理解也很重要，如果这个值是默认值的false的话，如果服务端收到客户端的FIN之后，服务端会自动的给客户端ACK和FIN，链接关闭。但是如果你指定这个值是true的话，如果服务端收到客户的FIN，服务端不会自动的回FIN给客户端，你需要监听end事件来捕获这一情况，并且手动调用socket的end方法，来发送FIN给客户端。

所以，这个end()方法会尝试发送FIN来走TCP的正常的四次挥手来拆除tcp链接。是不是自动拆除取决于你的allowHalfOpen。

至于这个destory()方法，官方说法叫“确保在此 socket 上不再有 I/O 活动。销毁流并关闭连接。（Ensures that no more I/O activity happens on this socket. Destroys the stream and closes the connection.）”，用一种强硬的手段来确保socket上不再有I/O活动，销毁流，并关闭连接。官方文档还说，更多详情见writable.destroy()；

writable.destroy([error])

销毁流。可选地触发 'error'，并且触发 'close' 事件（除非将 emitClose 设置为 false）。调用该方法后，可写流就结束了，之后再调用 write() 或 end() 都会导致 ERR_STREAM_DESTROYED 错误。这是销毁流的最直接的方式。前面对 write() 的调用可能没有耗尽，并且可能触发 ERR_STREAM_DESTROYED 错误。如果数据在关闭之前应该刷新，则使用 end() 而不是销毁，或者在销毁流之前等待 'drain' 事件。