握手常见问题
1、连接拒绝
2、Operation now in progress
多是因为丢包、错误ip、backlog满了&阻塞&tcp_abort_on_overflow=0
3、min(maxconn, backlog) ss -lt
连接拒绝
在TCP
三次握手的时候,客户端发送SYN
这个包给服务端,服务端不接受这个请求,操作系统直接返回了一个RST
的包,来拒绝连接的请求。
最常见的情况就是客户端去请求某个服务器,服务端没有绑定对应的端口。
测试代码如下,服务端代码:
1 <?php
2
3 $server = new \Swoole\Server('127.0.0.1', 9501);
4
5 $server->set([
6 'work_num' => 2,
7 'backlog' => 128,
8 ]);
9
10 $server->on('connect', function ($server, $fd)
11 {
12 echo "Client: Connect.\n";
13 });
14
15 $server->on('receive', function ($server, $fd, $reactor_id, $data)
16 {
17 var_dump($data);
18 });
19
20 $server->on('close', function ()
21 {
22 var_dump('close');
23 });
24
25 $server->start();
这里,服务端绑定的端口是9501
。
启动服务器:
1 ~/codeDir/phpCode/hyperf-skeleton # php server.php
客户端代码:
<?php
$client = new \Swoole\Client(SWOOLE_SOCK_TCP, SWOOLE_SOCK_SYNC);
var_dump($client->connect('127.0.0.1', 9500));
这里,客户端请求的端口是9500
。
启动客户端:
~/codeDir/phpCode/hyperf-skeleton # php client.php
Warning: Swoole\Client::connect(): connect to server[127.0.0.1:9500] failed, Error: Connection refused[111] in /root/codeDir/phpCode/hyperf-skeleton/client.php on line 4
bool(false)
~/codeDir/phpCode/hyperf-skeleton #
我们发现,报错:
Error: Connection refused[111]
Operation now in progress
这个错误的绝大部分原因是因为连接超时了。
丢包
例如路由器、网关出现了故障,包被丢了。
错误ip
例如客户端请求了一个错误的ip
,那么路由器自然也就路由不到。
测试代码如下,客户端代码:
<?php
$client = new \Swoole\Client(SWOOLE_SOCK_TCP, SWOOLE_SOCK_SYNC);
var_dump($client->connect('8.8.8.8', 9501));
这里,我访问的是谷歌的DNS
服务器。因为我没有翻墙,所以是访问不了这个IP
的。因此,我们发送的包是到达不了8.8.8.8
服务器的。
启动客户端:
~/codeDir/phpCode/hyperf-skeleton # php client.php
Warning: Swoole\Client::connect(): connect to server[8.8.8.8:9501] failed, Error: Operation in progress[115] in /root/codeDir/phpCode/hyperf-skeleton/client.php on line 4
bool(false)
~/codeDir/phpCode/hyperf-skeleton #
我们发现,报错:
Error: Operation in progress[115]
backlog
服务器在三次握手的最后一次,即收到客户端发来的ACK
包的时候,会把建立好的连接放到backlog
队列里面。如果Swoole
一直不accept
连接,那么这个backlog
队列很快就会满。backlog
队列满了之后,服务端就会丢弃三次握手的SYN
包,让客户端重新去连接服务端。
测试代码如下,服务端代码:
1 <?php
2
3 $server = new \Swoole\Server('127.0.0.1', 9501, SWOOLE_BASE);
4
5 $server->set([
6 'work_num' => 2,
7 'backlog' => 128,
8 ]);
9
10 $server->on('connect', function ($server, $fd)
11 {
12 echo "Client: Connect.\n";
13 sleep(1000);
14 });
15
16 $server->on('receive', function ($server, $fd, $reactor_id, $data)
17 {
18 var_dump($data);
19 });
20
21 $server->on('close', function ()
22 {
23 var_dump('close');
24 });
25
26 $server->start();
要想测试**backlog
问题必须在Swoole
的SWOOLE_BASE
模式下,默认的SWOOLE_PROCESS
**模式是没有这个问题的。
这里,我们的**backlog
大小是128
。**
然后,我们通过**sleep(1000);
来阻塞住进程,使得Swoole
不会继续accept
连接,从而导致backlog
**队列在某个时刻变满。
客户端代码:
1 <?php
2
3 $i = 0;
4 while (true)
5 {
6 $client = new \Swoole\Client(SWOOLE_SOCK_TCP, SWOOLE_SOCK_SYNC);
7 if ($client->connect('127.0.0.1', 9501) == false)
8 {
9 break;
10 }
11 }
我们启动服务器:
~/codeDir/phpCode/hyperf-skeleton # php server.php
然后启动客户端:
~/codeDir/phpCode/hyperf-skeleton # php client.php
省略了其他的输出
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Warning: Swoole\Client::connect(): connect to server[127.0.0.1:9501] failed, Error: Operation in progress[115] in /root/codeDir/phpCode/hyperf-skeleton/client.php on line 7
bool(false)
Warning: Swoole\Client::connect(): connect to server[127.0.0.1:9501] failed, Error: Operation in progress[115] in /root/codeDir/phpCode/hyperf-skeleton/client.php on line 7
bool(false)
^C
~/codeDir/phpCode/hyperf-skeleton #
我们会发现,过一段时间,客户端这边会报错:
Error: Operation in progress[115]
服务端这边输出:
~/codeDir/phpCode/hyperf-skeleton # php server.php
Client: Connect.
因为当Swoole
服务器从backlog
队列里面accept
一个连接的时候,才会触发onReceive
回调函数。所以,当服务端accept
一个连接之后,Swoole
自己就会陷入阻塞,不会再accept
了。但是需要注意的是,尽管Swoole
服务器自身是阻塞的,操作系统还会继续去把建立好的连接放入backlog
队列里面。所以,backlog
队列会满。
SYN Flood
除了三次握手成功之后会使用到的backlog
队列,还有一个SYN
队列。也就是在三次握手时候,客户端给服务端发送了SYN
包,服务端会有一个SYN
队列来维护。
与其有关的内核配置:
tcp_max_syn_backlog
tcp_synack_retries
tcp_syncookies
其中,tcp_max_syn_backlog
就是这个SYN
队列的长度。如果大量的SYN
包把SYN
队列塞满了,那么其他正常的连接过来,服务端就无法处理。
SYN Flood
攻击就是客户端疯狂的给服务端发送SYN
包,然后服务端每次都会把请求放到SYN
队列里面。但是,客户端不给服务端回ACK
包。如果客户端不回ACK
包,那么服务端就会给客户端回SYN + ACK
包,即第二次握手发送的包。而回复SYN + ACK
包的次数就是由tcp_synack_retries
参数决定的。如果把tcp_synack_retries
设置为0,那么如果服务端没有收到ACK
包,那么服务端就不会重试发送SYN + ACK
包了,这样就减少了SYN
队列里面那个请求的存活时间。
tcp_syncookies
的原理就是,客户端发送SYN
包的时候,不会维护SYN
队列,而是返回一个cookie
给客户端。然后客户端发送第三次握手的时候,携带这个cookie
值,只有这个cookie
验证通过,服务端才会给连接分配资源。