TCP（Transmission Control Protocol）传输控制协议。是面向连接的、全双工的协议。主要用来传输TCP报文的。而传输需要客户端client与服务器Server建立连接来完成（三次握手）。传输完成后需要释放链接（四次挥手）
建立连接—三次握手：
第一次握手：首先客户A主动打开连接，服务器B被动打开连接，双方都会先创建传输控制块TCP,此时客户A和服务器B都处于CLOSED状态，当客户A向服务器B发送连接请求报文段时，同步位SYN置1，确认ACK=0，序号seq随机产生为x，此时客户端进入SYN-SEND（同步发送状态），此时服务器B还处于LISTEN(监听状态)。
第二次握手：服务器B接收到客户A的连接请求报文时，如果同意建立连接则会向A发送确连接请求，此时同步位SYN=1，确认ACK=1，确认好ack=x+1，并随机生成自己的序号seq=y。此时服务器B进入SYN-RCVD（同步收到）状态。
第三次握手：客户端A收到B的确认连接时，会继续向B发送确认。此时确认ACK=1，确认号ack=y+1，序号seq=x+1。此时客户A进入ESTABLISHEED（已建立连接）状态。当B收到A的确认时，B也进入ESTABLISHED状态。到此完成客户A与服务器B的tcp连接。
为什么要第三次握手？
这主要是为了防止已失效的链接请求突然传输到了B，产生错误，造成资源浪费。假设A第一次向B发送连接请求时，由于请求报文丢失，在一定时间内A收不到B的确认连接时，A会继续向B重传连接请求，当第二次请求被B接收后，会与A建立连接，当A与B数据传输完成后会释放连接，但如果A的地第一次请求报文并不是丢失，而是在某个网络节点长时间滞留了，当A-B释放完连接时，A的第一次请求报文又发送到了B，而B会误认为A又一次向自己发送了请求连接，然后向客户A发送连接确认，但客户A和服务器B传输完数据后并没有再一次向B发送连接请求报文，所以会对B的连接确认“置之不理”，这样服务器B就只能干等着A给与确认，这样就极大的浪费了服务器B的网络资源。采用第三次握手可以解决这个问题，此时第三次握手，即A如果向B的确认发送确认后，B就知道A又一次向B发送连接请求，相反，如果A没有向B的确认发送确认，则B会认为A并没有像向B再一次发送连接请求。
释放链接—四次挥手：
释放连接说明此时客户A和服务器B都处于ESTABLISHED（连接状态），释放连接A和B之间需要发送四次报文，即四次挥手。
第一次挥手：客户A的应用进程会先向TCP发送连接释放报文，并停止向B发送数据，终止与B的连接。此时终止控制位FIN=1，序号seq=u（等于最后连接状态情况下最后序号加1），此时A进入终止等待状态（FIN-WAIT1）,等待B的确认。
**第二次挥手：**B收到A的释放链接请求报文时，确认ACK=1，确认号ack=u+1，并产生自己的序号v。此时B进入CLOSED-WAIT(关闭等待状态)。这个连接处于半连接状态，即A不能向B发送数据，但B向A的这条连接并没有关闭，B可以继续向A发送数据。
第三次挥手：如果B没有向A发送数据，则会通知tcp释放链接，并向A发送确认，此时确认终止控制位FIN=1，确认ACK=1，确认号ack=v+1,并产生序号seq=w，等待A的确认，此时A接收到B的确认时，进入FIN-WAIT2（终止等待）状态。B进入LAST-ACK（最后确认）状态。
第四次挥手：在A收到B的连接释放报文时，A需要对B再一次发送确认，在报文中确认ACK=1，确认号ack=w+1,序号seq=u+1。此时连接还没有释放掉，需要等待一段时间（时间等待计时器设置为2MSL），此时A进入TIME-WAIT（时间等待）状态。当服务器B接收到A的确认时，B进入CLOSED的状态。而经过2MSL时间后A的传输控制块TCB撤销时A进入CLOSED状态。
为什么要第四次挥手（A等待2MSL时间？）？
第一：是为了保证A最后一次发送的确认ACK能够到达B。ACK报文段可能丢失，当在2MLS时间内，B收不到A的确认ACK，就会重传FIN-ACK请求，A就会对B再次重传确认ACK，重启2MSL计时器，保证B接收到A的ACK确认。最后A和B都处于CLOSED状态，关闭A和B的连接。
第二：是为了防止建立连接时，A发出的第一连接请求因为在网络节点长时间滞留而再一次出现在释放连接中。由于2MSL时间内，可以使连续时间内连接的报文段从网络中消失，即使已失效的连接请求报文段出现在了本连接中，