TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接，就好像你给别人打电话，必须等线路接通了、对方拿起话筒建立了连接才能相互通话。
TCP三次握手的过程为：
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
TCP用三次握手（three-way handshake）过程创建一个连接。在连接创建过程中，很多参数要被初始化，例如序号被初始化以保证按序传输和连接的强壮性。
一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字（socket）然后监听来自另一方的连接，这就是通常所指的被动打开（passive open）。服务器端被被动打开以后，用户端就能开始创建主动打开（active open）。
1）客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为随机数 A。
2）服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK 的确认码应为 A+1，SYN/ACK 包本身又有一个随机序号 B。
3）最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包序号被设定为收到的确认号 A+1，而响应则为 B+1。
为什么需要三次握手？
简单地说，就是要保证在一段有效时间内，双方收到对方的有效信息。
一个简单例子，A发给B，B回复A，如果A不再回复B，B如何知道A收到了自己的信息？
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。
不管哪个例子，都是为了满足”在不可靠信道上可靠地传输信息”这一需求。请注意这里的本质需求，信道不可靠，数据传输要可靠。还是那句话，就是要保证在一段有效时间内，双方收到对方的有效信息。
Socket状态对应
Socket API 和 TCP 协议中各个状态是如何对应的呢？我们可以通过下图来看:
2. 断开连接四次挥手
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。比如服务器收到一个FIN只意味着客户端不再发送数据，但它还可以向客户端发送数据，当服务器不再发数据了，他也要向客户端发送FIN。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，断开连接就需要进行TCP四次分手：
第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment
Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence
第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
FIN_WAIT_1: 当SOCKET在ESTABLISHED状态，主动关闭连接时，向对方发送FIN报文，此时该SOCKET进入到FIN_WAIT_1状态。当对方回应ACK报文后，则进入到FIN_WAIT_2状态。（主动方）
FIN_WAIT_2：处于FIN_WAIT_2状态下的SOCKET为半连接状态，等待对方发起断开要求，（注意对方可以在断开时捎带信息）稍后再关闭连接。（主动方）
TIME_WAIT: 收到了对方FIN报文，并发送出了ACK报文，等待2MSL后即可回到CLOSED状态了。
注意：在FIN_WAIT_1状态下，如果收到了对方同时带FIN和ACK标志的报文（复用一个报文）时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
CLOSING（比较少见）: 如果双方几乎同时试图断开一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，即会出现CLOSING状态，表示双方都试图关闭SOCKET连接。
CLOSE_WAIT: 等待关闭连接，当对方发送FIN报文，回应ACK报文给对方后，则进入到CLOSE_WAIT状态。如果此时没有数据发送给对方，就可以关闭这个SOCKET，发送FIN报文给对方，即关闭连接。（被动方）
LAST_ACK: 被动关闭方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，进入到CLOSED状态。（被动方）
CLOSED: 连接中断。