0%

SYN Flood攻击

在说SYN Flood攻击之前先说一下SYN超时重试

SYN超时重试

这个指的是server端接收到client发出的SYN后回复了SYN-ACK但是client掉线了,server端没有接收到client传回来的ACK,这时,server端会重发SYN-ACK,默认重发5次,重试的间隔从1s开始指数递增,时间间隔分别为1s、2s、4s、8s、16s,在第五次发送后需要等待32s才知道第五次也超时了,所以一共需要63s后server端才会断开这个TCP连接

SYN Flood

SYN Flood攻击就是利用的SYN超时重试的机制,给server端发送一个SYN之后就断掉,server端需要等待63s才会断开连接,这样可以将服务器的syn连接的队列耗尽,导致正常请求无法进行连接

那么如何防止呢?

linux提供了一个tcp_syncookies的参数,作用是当SYN队列满了后,TCP会通过源地址端口、目标地址端口和时间戳打造一个特别的Sequence Number发回去,如果是攻击者,则不会响应,如果是正常连接,则会把这个SYN Cookie发回来,然后服务端可以通过cookie建立连接,即使该连接不在SYN队列中

还有三个参数也是用来调整这个问题的

  • tcp_synack_retries 设置重试次数,可以减少重试次数
  • tcp_max_syn_backlog 设置syn连接数,可以增大syn连接数
  • tcp_abort_on_overflow 处理不过来的话就直接拒绝连接

Nginx配置优化

name相同问题

在使用@FeignClient的时候,发现多个@FeignClient中的name相同就无法启动,当然了,这是因为bean名称重复了,创建bean的时候报的错,但是如何解决呢?

A bean with that name has already been defined and overriding is disabled

可以配置不同的contextId来进行解决

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@FeignClient(name = "SPRINGCLOUD2-PROVIDER",contextId = "DeptClient",fallbackFactory = DeptClientFallBackFactory.class)
public interface DeptClient {

@GetMapping(value = "/dept/get/{id}")
CommonResult<Dept> get(@PathVariable("id") long id);

@GetMapping("/timeout")
String timeout();
}


@FeignClient(name = "SPRINGCLOUD2-PROVIDER",contextId = "DeptClient1",fallbackFactory = DeptClientFallBackFactory.class)
public interface DeptClient1 {

@GetMapping(value = "/dept/get/{id}")
CommonResult<Dept> get(@PathVariable("id") long id);

@GetMapping("/timeout")
String timeout();
}

为什么可以这样解决呢?

阅读全文 »

elasticsearch6.x查询优化

查询缓存

Elasticsearch的查询缓存实现了LRU置换算法:当缓存变满时,最近最少使用的数据被置换以便为新数据腾出空间

使用查询缓存和请求缓存来加快查询速度

1
index.queries.cache.enabled: true

查找查询慢的原因

查看热点线程

1
GET /_nodes/hot_threads

设置更好的文档模型

避免join操作

  • nested 会使得查询慢好几倍
  • parent-child关系 会使得查询慢几百倍

分布式环境下面临的问题

通信异常

分布式系统需要在各个节点之间进行网络通信,且延时会远大于单机操作。

网络分区

当网络由于发生异常情况,导致分布式系统中部分节点之间网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够进行正常通信,而另一些节点则不能。该现象称为网络分区,也就是脑裂

三态

分布式系统的每一次请求和响应存在特有的三态概念,即成功、失败与超时(传统单机中是成功或失败)。超时有两种情况

  • 由于网络原因,该请求并没有被成功地发送到接收方,而是在发送过程就发生了消息丢失现象
  • 该请求成功的被接收方接收后,进行了处理,但是在将响应反馈给发送方的过程中,发生了消息丢失现象

此时,发起方是无法确定当前请求是否被成功处理

节点故障

分布式系统中某节点可能会出现宕机或僵死现象。