TCP面试过程中经常遇到的问题

1，建立连接时三次握手过程？

2，接着问如果只有两次握手会怎么样？

答：造成服务端资源浪费。假设Client发送了一个建立连接请求，但是这个请求在网络中滞留了，Client超时重传了一个请求，因为是两次握手协议，Server端收到请求建立了连接。这时滞留在网络中的建立连接请求到达了Server端，Server误认为是Client又发出一次新的连接请求，于是向Client发送确认，但是Client并没有发送请求，所以不会理会这个确认，但是Server端已经以为建立了请求，一直等待Client发送数据，Client一直不发送数据，这时Server的资源就白白浪费了。

所以如果是三次握手的话，对于刚才出现的问题，Client不会向Server的确认发出确认，Server由于收不到确认，就知道Client并没有要求建立连接。

3，SYN Flood攻击是什么意思，如何解决？

攻击者首先伪造地址对服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

解决方法：

       1，无效连接监视释放 
       这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。
       2，延缓TCB分配方法 
       SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有两种技术来解决这一问题：
       Syn Cache技术：收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中保存这种半开连接，直到收到正确的ACK报文再去分配TCB 。
       Syn Cookie技术：完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源 。
      3，使用SYN Proxy防火墙（这种方法是面试官跟我说过的，可能是现实场景中用的比较多的） 
      原理：对试图穿越的SYN请求进行验证之后才放行。这个防火墙单独使用一个硬件配置极强的服务器，只用来验证SYN请求。

4，断开连接时四次挥手过程？

5，为什么要保持TIME_WAIT状态2MSL时间而不是直接进入CLOSED状态？

     1，保证TCP协议的全双工连接能够可靠关闭
     如果直接closed了，server没有收到client最后回复的ACK，那么Server就会在超时之后继续发送FIN，而client已经关闭，最后server就会收到RST而不是ACK。
     2，保证这次连接的重复数据段从网络中消失