TCP三次握手/四次挥手

基础普及：
    a>序号：Seq序号，占32位，用来标识从tcp源端向目的端发送的字节流，发起方发送数据时对此进行标记；
    b>确认序号：Ack确认序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1；
    c>标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
URG：紧急指针(urgent pointer)有效。
ACK：确认序号有效。
PSH：接收方应该将这个报文提交给应用层。
RST：重置连接。
SYN：发起一个新连接。
FIN：释放一个连接。
    d>ACK置为1，表示验证字段有效；
        SYN置为1，表示建立连接；
        FIN置为1，表示断开连接；

• 三次握手

tcp三次握手流程：

    1、由客户端发送建立连接的请求报文，其中报文包含Seq序列号(由客户端随机生成)，并且将报文中SYN字段置为1，表示需要建立tcp连接。(SYN=1,Seq=x,x为随机生成数)；
    2、由服务端应答客户端发送的tcp连接请求报文，其中报文包含Seq序列号(由服务端随机生成)，并且将报文中SYN字段置为1；而且会产生Ack字段，Ack字段的值是在客户端发送过来的报文Seq值基础上+1，以便客户端收到信息时，知晓自己的tcp建立请求已经得到验证。(SYN=1,Ack=x+1,Seq=y,y为随机生成数)这里Ack可以理解成是确立和谁建立连接。
    3、客户端收到服务端发送的tcp建立验证请求后，会使自己的Seq序列号+1，并且再次回复Ack验证请求，在服务端发送过来的Seq值基础上+1。(SYN=1,Ack=y+1,Seq=x+1)建立正确，客户端和服务端都进入ESTABLISHED状态，二者可以传输数据了。

附属说明：
SYN攻击：
在tcp三次握手过程中，服务端发送SYN-ACK后，收到客户端返回的ACK之前，tcp连接成为半连接(half-open connect)，此时服务端处于SYN_RECV状态；当后续收到了客户端的ACK应答后，服务端转入ESTABLISHED状态。
SYN攻击就是客户端在短时间内伪造大量不存在的IP地址，并向服务端不断发送连接SYN包，服务端回复ACK确认包，并等待客户端确认报文。由于客户端IP是伪造不存在的，因此，服务端需要不断重发直至超时。这些伪造的SYN包会长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。
SYN攻击是一种典型的DDOS攻击，当服务端有大量的半连接状态且源IP地址随机的，可以判定遭到了SYN攻击了。
netstat -nap | grep SYN_RECV
解决方法：1、设置 服务端ACK应答次数；
2、SYN cookie技术
ACK攻击：
在tcp三次握手完成后，客户端和服务端进入ESTABLIESH状态。所有的数据传输tcp报文都是带有ACK标志位的， 服务器收到一个带有ACK标志为的时候，需要检查该数据包所表示的连接四元组是否存在；如果存在则检测数据包所表示的状态是否合法，然后再向应用层传输该数据包；如果检测中发现数据包不合法，例如数据包指向的目的端口没有开放，则服务器操作系统协议栈会回应RST包告诉对方此端口不存在。
服务器会处理两个动作：查表、回应ACK/RST。 随机源IP的ACK小包会被很快丢弃，因为在服务器的tcp堆栈中没有这些ACK包的状态信息。

解决方法：部分防火墙应对的方法是：建立一个hash表，用来存放tcp连接“状态”，相对于主机的tcp stack实现来说，状态检查的过程相对简化。例如，不作Sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的”。

• 四次挥手

tcp四次挥手说明：
    由于tcp连接是全双工的，每个方向都要单独关闭；这一原则是当一方完成数据发送后，发送一个FIN标志来终止这一方向的连接，收到这个FIN标志意味着不会再接收数据了，但是可以发送数据。
    1、客户端发送断开tcp的连接请求报文，其中报文包含Seq序列号(由发送端随机生成)，并且将报文中ACK字段置为1，表示确认序号有效，表示需要断开tcp连接。(ACK=1,Seq=x,x为随机生成数)；
    2、服务端会回复客户端发送的断开连接请求报文，其中报文包含Seq序列号(由服务端随机生成)，而且会产生Ack字段，Ack字段的值是在客户端发送过来的Seq值基础上+1，以便客户端收到信息时，知晓自己的tcp端口连接请求已经得到验证。(ACK=1,Ack=x+1,Seq=y,y为随机生成数)

    3、服务端在回复完客户端的断开请求后，不会立即端口tcp连接。服务器在断开前，会确保所有的数据都传输到客户端，一旦传输完毕，就会将回复报文的FIN置为1，并且包含Seq序列号(由服务端随机生成)。(FIN=1,ACK=1,Ack=x+1,Seq=z,z由服务端随机生成)

    4、客户端收到服务端的断开连接请求后，会回复服务端的断开连接请求，回复报文包括了Ack和Seq字段，Ack字段值会在服务端发送过来的Seq值基础上+1，从而完成服务端请求的验证回复。(ACK=1,Ack=z+1,Seq=u,u为客户端随机生成)

说明：

为什么客户端要等待2MSL?
    MSL(Maximum Segment Lifetime)，最大报文生存时间，tcp允许不同的实现设置不同的MSL值。
    第一，保证客户端应答的最后一个ACK报文能够到达服务器，因为这个ACK报文可能会丢失的；从服务器角度出发，我已经发送FIN+ACK报文请求断开了，客户端没有应答，应该是我发送的断开报文没有到达，那我重新发送一次，而客户端能在2MSL时间内收到这个重传的报文，接着给出回应报文，并且重启2MSL计时器；
    第二，防止“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个ACK报文后，在2MSL时间中，就可以使本连接中持续的时间内产生的报文都从网络中消失掉；这样新的连接中就不会出现旧连接的报文。

为什么建立连接是三次握手，释放连接是四次挥手？
    建立连接时，服务器处在LISTEN状态，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端；
    断开连接时，服务器收到FIN时，仅仅表示客户端不再发送报文信息，但是服务器有可能报文还没有发完，所以先回复一个ACK报文，告诉客户端 “我知道你关闭了发送报文”；等到服务端所有报文发送完毕后，才会再次回复FIN报文，关闭我这边的“发送报文”。

大量TIME_WAIT状态?
    服务器端主动断开大量的客户端连接，可能会出现大量的 TIME_WAIT状态；
    解决思路是让服务器能够快速回收和重用那些TIME_WAIT资源。
    修改 /etc/sysctl.conf文件中的配置项，修改完成后 /etc/sysctl -p让参数生效。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle 开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout 这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_* 一系列参数，是用来设置服务器检测连接存活的相关配置。

大量的CLOSE_WAIT状态？
    如果有大量的CLOSE_WAIT状态，那么就是对方在关闭连接服务器后，服务器没有进一步发送ACK信号。换句话说，就是在对方关闭连接后，程序没检测到或者忘记了这个时候需要关闭，于是资源就一直被占用着。
    举例 服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完 资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设 请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。