TCP连接建立只需要三次握手，为什么断开连接需要四次挥手？

通常TCP连接是由客户端向服务器发起和断开的。因为只有服务器在监听端口，客户端上没有监听端口，所以客户端无法接收主动来的连接。而客户端获得了自己想要的资源或者服务之后，就会断开连接。下面的三次握手和四次挥手描述了典型情况。

TCP连接建立过程：
1、客户端向服务器发送SYN，其中seq=x。
2、服务器收到SYN报文段后，发送SYN+ACK，其中seq=y，确认号=x+1。
3、客户端收到SYN+ACK报文段后，发送ACK，确认号=y+1。服务器收到ACK报文段后，连接建立。

建立后客户端和服务器就知道了对方的序列号，序列号用来做确认重传、排序。也知道了对方的窗口大小，可以用于端到端的流控，永远不会发送对方处理不了的数据量。
还可以通过连接过程来进行选项的协商。通过MSS（Maximum Segment Size/最大报文段长度），用于告诉对端本端能够接收的最大Segment Size。可以协商使用选择性的确认，而不单纯是累计确认，这样可以提高性能。还可以协商使用Window Scale Option（窗口扩大因子），将TCP窗口大小变大，用于突破65535的限制，提高长肥管道中的传输速率。

TCP连接断开过程：
1、客户端TCP模块在收到应用程序的通知后，发送FIN，seq=x。
2、服务器收到FIN报文段，发送ACK，确认号=x+1，并且通知应用程序客户端关闭了连接。客户端收到ACK报文段。
3、服务器端的应用程序通知TCP关闭连接，服务器端TCP发送FIN+ACK，seq=y，确认号=x+1（这里ACK只是一般性的捎带ACK，TCP总是这样，以增强健壮性，反正也不费力气，从原理上说，对连接断开不是必须的）。
4、客户端收到FIN+ACK报文段后，发送ACK，确认号y+1。服务器收到ACK报文段后，连接断开。

为什么不去掉第二步，直接进行第三步呢？
因为，第二步中，服务器端通知应用程序并获得反馈信息可能需要可观的时间，这可能涉及人机交互操作，也可能服务器应用层暂时还不想关闭连接。第二步结束后，服务器还可以继续通过这条连接发送数据给客户端，客户端已经不能发送数据了，但是仍然可以回复ACK。第二步中服务器立即发送确认是为了防止客户端重传FIN报文。

当然也有可能双方同时来连接，这个时候通信双方是对等的，比如BGP peer之间就是对等的，翻译成中文为BGP对等体，也算是贴切。如果双发使用非监听端口发起连接，这样最终需要断开其中一条多余的连接。如果双发都使用自己监听的端口发起连接，那就成了四次握手，正好建立起一条双向连接。

也有可能服务器在不想继续为客户端提供服务了，主动断开连接。不过这种情况对于TCP而言仍然是普通的四次挥手。

还有可能客户端和服务器同时断开连接，仍然是发送四个报文，你可以把它看做是四次挥手，但是它不再是普通的四次挥手。因为这4个报文在时间上有重叠。就TCP状态机的迁移而言，也和普通的四次挥手不同。将不再进入FIN-WAIT-2状态。