TCP 包类型

标志位　　

　　在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN(synchronous建立联机)，ACK(acknowledgement 确认)，PSH(push传送)，FIN(finish结束)，RST(reset重置)，URG(urgent紧急)。其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是：

• SYN：建立连接
• FIN：关闭连接
• ACK：响应
• PSH：有DATA数据传输
• RST：连接重置

　　ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。

　　但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。

　　RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。

　　一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。

　　PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

RST

　　TCP的异常终止是相对于正常释放TCP连接的过程而言的，我们都知道，TCP连接的建立是通过三次握手完成的，而TCP正常释放连接是通过四次挥手来完成，但是有些情况下，TCP在交互的过程中会出现一些意想不到的情况，导致TCP无法按照正常的四次挥手来释放连接。如果此时不通过其他的方式来释放TCP连接的话，这个TCP连接将会一直存在，占用系统的部分资源。在这种情况下，我们就需要有一种能够释放TCP连接的机制，这种机制就是TCP的reset报文。

场景：

• 客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。
• 客户端建立连接时，接收到服务器的syn超时，客户端发送reset报文。
• 客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送reset报文，告之对方释放相关的TCP连接。
• 接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文。
• 在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。
• 有些应用开发者在设计应用系统时，会利用reset报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率。

利用：

• 安全设备利用reset报文阻断异常连接：安全设备（如防火墙、入侵检测系统等）在发现某些可疑的TCP连接时，会构造交互双方的reset报文发给对端，让对端释放该TCP连接。比如入侵检测检测到黑客攻击的TCP连接，其构造成被攻击端给黑客主机发送reset报文，让黑客主机释放攻击连接。
• 利用reset报文实施攻击：安全设备可以利用reset报文达到安全防护的效果，黑客和攻击者也可以利用reset报文实现对某些主机的入侵和攻击，最常见的就是TCP会话劫持攻击。

SYN Flood

　　SYN Flood是指利用TCP协议缺陷，发送大量伪造的TCP连接请求（SYN包），从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。

　　解决方法：

• 增加积压队列：在内核里有个队列用来存放还没有确认ACK的客户端请求，当等待的请求数大于tcp_max_syn_backlog时，后面的会被丢弃。所以，适当增大这个值，可以在压力大的时候提高握手的成功率。推荐大于1024。
• 回收最早的半开TCP连接：一旦积压已被填补，另一个缓解策略就是覆盖最早的半开式连接。这种策略要求合法连接可以在比可以填充恶意SYN数据包的积压时间更短的时间内完全建立。当攻击量增加时，或者如果积压量太小而不实际，这种特定的防御就会失败。
• 减少ack重试：这个是三次握手中，服务器回应ACK给客户端里，重试的次数。默认是5。显然攻击者是不会完成整个三次握手的，因此服务器在发出的ACK包在没有回应的情况下，会重试发送。当发送者是伪造IP时，服务器的ACK回应自然是无效的。为了防止服务器做这种无用功，可以把tcp_synack_retries设置为0或者1。因为对于正常的客户端，如果它接收不到服务器回应的ACK包，它会再次发送SYN包，客户端还是能正常连接的，只是可能在某些情况下建立连接的速度变慢了一点。
• SYN cookie：当半连接的请求数量超过了 tcp_max_syn_backlog 时，内核就会启用SYN cookie机制，不再把半连接请求放到队列里，而是用SYN cookie来检验。SYN cookie是非常巧妙地利用了TCP规范来绕过了TCP连接建立过程的验证过程，从而让服务器的负载可以大大降低。在三次握手中，当服务器回应（SYN + ACK）包后，客户端要回应一个n + 1的ACK到服务器，其中n是服务器自己指定的。当启用tcp_syncookies时，backlog满了后，linux内核生成一个特定的n值，并不把客户端的连接放到半连接的队列里（即没有存储任何关于这个连接的信息，不浪费内存）。当客户端提交第三次握手的ACK包时，linux内核取出n值，进行校验，如果通过，则认为这个是一个合法的连接。（backlog表示全连接队列长度）

　　https://www.cnblogs.com/sunsky303/p/11811097.html

　　https://blog.51cto.com/u_15169172/2710119

• 限制SYN并发数