三次握手

SYN-->				//请求同步信号 （server端收到后 确认client能发）
	<--ACK ,SYN		//确认接收信号，+ 请求同步信号 （client端收到后 确认自己能收能发，service能收能发）
ACK-->				//确认接收信号 （service端收到后 确认自己能收能发，client能收能发 ）

加

seq=x -->			//seq自己发的序列号 
	<-- seq=y,ack=x+1	//ack应答号 ack=x+表示自己接到了对面seq=x的消息
seq,ack-->			//由上两步也可以推出 seq=x+1 ack=y+1

四次挥手

FIN-->			//请求结束
 	<--ACK		//确认应答
 	；；；；		//server 发还没有发完的消息(这就是为什么有四次握手的原因)
 	<--ACK,FIN	//server 请求结束
ACK-->			//确认应答

加

seq=x-->
	<--seq=y,ack=x+1
	<--seq=y+n,ack=x+1
seq，ack-->			// seq=x+1 ack=y+n+1;

问题总结：

为什么是3次握手，不是2次
2次握手可能出现的情况：

如上图：
第一个丢失的报文段延误后到达服务端，此时服务端误认为客户端又发出一次新的连接请求，同意建立连接。
只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据。

什么是半连接：
第一次握手后，服务端不确定客户端能不能接受，先把连接请求放入半连接队列中，进入SYN_RECV状态(连接请求已接收状态)，
完成三次握手再把连接放到全连接队列中。
一直没收到第三次握手，service端发重传包，达到规定次数，从半连接队列里删除。（发重传包间隔时间一般指数增长）

为什么有四次挥手，
service端收到FIN请求后要先应答ACK，
等发完未发的数据，然后再发FIN；

什么是2MSL，为什么要等2MSL
MSL：maximum segment lifetime——最大报文生命周期
1：让client接受完service在第2-3次挥手期间发的内容
2：保证本次连接所有报文从网络中消失。（不影响下一次连接）