说一说tcp的三次握手。
TCP报文的头部：
端口是属于传输层的，TCP和udp报文中没有IP协议。
两个进程要进行通讯的前提是能够唯一标识另外一个进程。（PID只在本地能够唯一标识，如果是两台计算机之间的通讯就不够用了。）IP可以唯一标识主机。TCP加端口号可以唯一标识一个进程。IP+TCP+端口号标识网络中的一个进程，这种模式叫做套接字。
为1有效，为0无效。
URG：紧急指针标志。ACK：确认序号标志。PUH：push标志。RST：重置连接标志。SYN：同步序号，用于建立连接过程。FIN：finish标志，用于释放连接。
TCP的连接是全双工，三次握手的过程如下：
在建立连接之前，客户和服务器端都要先生成一个传输控制块TCB；在进行连接
第一次握手：建立连接时：客服端发送SYN包（seq=x）到服务器，并进入SYN-SEND状态，等待服务器确认。
第二次握手：服务器收到了SYN包，必须确认客户的SYN包（ack+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包。，此时服务器进入SYN-RECV状态；
第三次握手：客服端收到服务器的SYN+ACK包以后，向服务器端发送确认包ACK（ack=y+1）,该包发送完毕服务器端和客户端进入ESTABLISHED状态，完成三次握手。
为什么需要三次握手呢？
为了初始化Sequence Numbwer;
通讯的双方需要互相通知对方自己初始化的Sequence Numbwer;
就是xy值，作为下一次通讯的序号，保证不会出现乱序问题。
首次握手中存在的隐患;syn超时：
问题起因：服务器端收到客服端的SYN，回复SYN+ACK的时候未收到ACK；
服务器端不断尝试导致超时，LINux下面尝试五次以后默认等待63（1+2+4+8+16+32）秒才断开连接。
针对SYN Flood的防护：通过tcp-syncookies参数回发SYN cookie
如果为正常连接，客户会回发SYN cookie直接建立连接。
建立连接后客户端出问题了怎么办？
像对方发送保活探测秘密报文。如果没有回应继续发送。
尝试次数达到保活探测数仍未得到相应则中断连接。
