1 连接状态图
2 建立连接:三次握手,不使用DNS和使用DNS
3 关闭连接-四次握手
<div align="center"/>
</div>
连接双方任何一方调用close()后，连接的两个传输方向都关闭，不能再发送数据了。如果一方调用shutdown()则连接处于半关闭状态，仍可接收对方发来的数据。
如果出现半关闭，例如客户->服务器方向关闭。则服务器还可以发，客户端还可以收。
协议规定主动关闭一方，进入FIN_WAIT_2->TIME_WAIT，必须等待2MSL（MSL为最大报文段生存时间，LWIP为1分钟，windows为2分钟）时间然后才进入CLOSED，删除TCP控制块。在2MSL等待时间内迟到的报文段将被抛弃。
如果我们在客户端关闭一个连接然后又立刻建立连接（使用同一端口号），2MSL时间内之前连接的端口号不能使用，即使调用bind函数也将返回-1（绑定失败），内核将自动分配一个新的端口号使用。通常情况下这个我们并不关心，因为客户端的端口号我们并不关心，只要能用就可以。但是如果是服务器就不一样了，服务器的端口一般是固定的，客户端必须知道服务器的端口号才能建立连接，所以如果服务器端主动断开连接时，就需要注意，或者做一些处理：不让它等待2MSL后才可以使用，具体做法：使能SO_REUSEPORT(允许重用本地地址)，可以通过调用setsockopt函数来使能。
2MSL等待的原因：报文段有生存时间，当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的。另一个原因是可靠的实现全双工连接的终止。
在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也已对它进行确认。除非我们在实行半关闭，否则将等待另一端的应用层意识到它已收到一个文件结束符说明，并向我们发一个FIN来关闭另一方向的连接。只有当另一端的进程完成这个关闭，我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这个状态(FIN_WAIT_2,如果对方不发送FIN包)。另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭（调用close然后进入LAST_ACK）。
