1.TCP三次握手和四次挥手
三次握手（Three-way Handshake）主要作用就是为了确认双方的接收能力和发送能力正常。其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息，为后面的可靠性传送做准备。
刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
Q1：为什么两次握手不可以？(A客户端，B服务器)
为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如：A 发出的第一个连接请求报文段在网路结点上延误到之后的连接释放以后的某个时间段才到达 B。 B 收到此失效的请求报文段后，就误认为 A 又发出一次新的连接请求。如果不进行第三次握手，B 发出确认后就进入了新的运输连接状态，一直等待 A 发来数据。
Q2：接收端收到 客户端的 SYN 后，为什么还要传回 SYN？
接收端传回发送端所发送的 SYN 是告诉客户端接收到的信息确实是客户端所发送的信号了。
SYN 是 TCP / IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个
Q3：传了 SYN，为什么还要传 ACK？
传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。
Q4：为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？（MSL：最长报文段寿命）
TCP释放连接时为什么time_wait状态必须等待2MSL时间
1.如果 接收端A 在 TIME-WAIT 状态不等待一段时间，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。
2. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。下一个连接中不会出现旧的连接请求报文段。
Q5：为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?
当服务器执行第二次挥手之后, 客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数上一次请求的资源，所以服务端会等到把之前未传输完的数据传输完毕之后再发送关闭请求。
Q6：TCP 协议是如何保证可靠传输的？
- 数据包校验：检测数据在传输过程中若出错，则丢弃报文段并且不给响应， TCP 发送数据端超时后会重发数据；
- 对失序数据包重排序：既然 IP 数据报的到达可能会失序，TCP 报文段作为 IP 数据报来传输，到达也可能会失序。TCP 将失序重排，然后才交给应用层；
- 能够丢弃重复数据；
- 应答机制：收到发自 TCP 连接另一端的数据，将发送一个确认标志ACK。
- 超时重发：当 TCP 发出一个段后，就会启动一个定时器，设定时间内没有收到ACK将重发这个报文段；
- 流量控制：TCP 连接的双方都有固定大小的缓冲空间。不允许对方发送超过自己缓冲区容量的数据，以防较快主机致使较慢主机的缓冲区溢出。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
Q7：Tcp握手成功后，如果一方宕机，没有主动请求关闭，连接会一直保存么？
当TCP连接发生一些物理上的意外情况时，例如网线断开，linux上的TCP实现会依然认为该连接有效，而windows则会在一定时间后返回错误信息。可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。
连接断开过程-----四次挥手