转 【转载】 SYN cookies 机制下连接的建立

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介:

      在正常情况下,服务器端接收到客户端发送的 SYN 包,会分配一个连接请求块(即 request_sock 结构),用于保存连接请求信息,并且发送 SYN+ACK 包给客户端,然后将连接请求块添加到半连接队列中。客户端接收到 SYN+ACK 包后,会发送 ACK包 对服务器端的包进行确认。服务器端收到客户端的确认后,根据保存的连接信息,构建一个新的连接,放到监听套接字的连接队列中,等待用户层 accept 连接。这是正常的情况,但是在并发过高或者遭受 SYN flood 攻击的情况下,半连接队列的槽位数量很快就会耗尽,会导致丢弃新的连接请求,SYN cookies 技术可以使服务器在半连接队列已满的情况下仍能处理新的 SYN 请求  
      如果开启了 SYN cookies 选项,在半连接队列满时,SYN cookies 并不丢弃 SYN 请求,而是将源目的 IP、源目的端口号、接收到的客户端初始序列号以及其他一些安全数值等信息进行 hash 运算,并加密后得到服务器端的初始序列号,称之为 cookie 。服务器端在发送初始序列号为 cookie 的 SYN+ACK 包后,会将分配的连接请求块释放。如果接收到客户端的 ACK 包,服务器端将客户端的 ACK 序列号减 1 得到的值,与上述要素 hash 运算得到的值比较,如果相等,直接完成三次握手,构建新的连接。SYN cookies 机制的核心就是避免攻击造成的大量构造无用的连接请求块,导致内存耗尽,而无法处理正常的连接请求  
      启用 SYN cookies 是通过在启动环境中设置以下命令完成:  
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
      注意,开启该机制并不意味着所有的连接都是使用 SYN cookies 机制来完成连接的建立只有在半连接队列已满情况下才会触发 SYN cookies 机制。由于 SYN cookies 机制严重违背 TCP 协议不允许使用TCP 扩展,可能对某些服务造成严重的性能影响(如 SMTP 转发),对于防御 SYN flood 攻击的确有效。对于没有受到攻击的高负载服务器,不要开启此选项,可以通过修改 tcp_max_syn_backlog 、tcp_synack_retries 和tcp_abort_on_overflow 系统参数来调节。  
      下面来看看内核中是怎么通过 SYN cookie 机制来完成连接的建立。  
      客户端的连接请求由 tcp_v4_conn_request() 函数处理。tcp_v4_conn_request() 中有一个局部变量 want_cookie,用来标识是否使用 SYN cookies 机制。want_cookie 的初始值为 0,如果半连接队列已满,并且开启了 tcp_syncookies 系统参数,则将其值设置为 1,如下所示:  
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
#ifdef CONFIG_SYN_COOKIES
    int want_cookie = 0;
#else
#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
#endif
 
...... 
 
    /* TW buckets are converted to open requests without
     * limitations, they conserve resources and peer is
     * evidently real one.
     */
      if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
#ifdef CONFIG_SYN_COOKIES
             if (sysctl_tcp_syncookies) {
            want_cookie = 1;
        } else
#endif
       
        goto drop;
    }
 
......
 
drop:
    return 0;
}
      如果没有开启 SYN cookies 机制,在半连接队列满时,会跳转到 drop 处,返回 0 。在调用 tcp_v4_conn_request() 的 tcp_rcv_state_process() 中会直接释放 SKB 包。  
      我们前面提到过,造成半连接队列满有两种情况(不考虑半连接队列很小的情况),一种是负载过高,正常的连接数过多;另一种是 SYN flood 攻击。如果是第一种情况,此时是否继续构建连接,则要取决于连接队列的情况及半连接队列的重传情况,如下所示:  
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
        goto drop;
      sk_acceptq_is_full() 函数很好理解,根据字面意思就可以看出,该函数是检查连接队列是否已满。inet_csk_reqsk_queue_young() 函数返回的是半连接队列中未重传过 SYN+ACK 段的连接请求块数量。如果连接队列已满并且半连接队列中的连接请求块中未重传的数量大于 1,则会跳转到 drop 处,丢弃 SYN 包。如果半连接队列中未重传的请求块数量大于 1,则表示未来可能有 2 个完成的连接,这些新完成的连接要放到连接队列中,但此时连接队列已满。如果在接收到三次握手中最后的 ACK 后连接队列中没有空闲的位置,会忽略接收到的 ACK 包,连接建立会推迟,所以此时最好丢掉部分新的连接请求,空出资源以完成正在进行的连接建立过程。还要注意,这个判断并没有考虑半连接队列是否已满的问题。从这里可以看出,即使开启了 SYN cookies 机制并不意味着一定可以完成连接的建立  
      如果可以继续连接的建立,调用 inet_reqsk_alloc() 分配连接请求块,如下所示:  
req = inet_reqsk_alloc(&tcp_request_sock_ops);
    if (!req)
        goto drop;
      看到这里可能就有人疑惑,既然开启了 SYN cookies 机制,仍然分配连接请求块,那和正常的连接构建也没有什么区别了。这里之所以要分配连接请求块是用于发送 SYN+ACK 包给客户端,发送后会释放掉,并不会加入到半连接队列中。  
      接下来就是计算 cookie 的值,由 cookie_v4_init_sequence() 函数完成,如下所示:  
if (want_cookie) {
#ifdef CONFIG_SYN_COOKIES
        syn_flood_warning(skb);
        req->cookie_ts = tmp_opt.tstamp_ok;
#endif
        isn = cookie_v4_init_sequence(sk, skb, &req->mss);
    }
      计算得到的 cookie 值会保存在连接请求块 tcp_request_sock 结构的 snt_isn 成员中,接着会调用 __tcp_v4_send_synack() 函数发送 SYN+ACK 包,然后释放前面分配的连接请求块,如下所示:  
if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)
        goto drop_and_free;
      在服务器端发送完 SYN+ACK 包后,我们看到在服务器端没有保存任何关于这个未完成连接的信息,所以在接收到客户端的 ACK 包后,只能根据前面发送的 SYN+ACK 包中的 cookie 值来决定是否继续构建连接。  
      我们接下来看接收到 ACK 包后的处理情况。ACK 包在 tcp_v4_do_rcv() 函数中调用的 tcp_v4_hnd_req() 中处理,如下所示:  
static struct sock *tcp_v4_hnd_req(struct sock *sk, struct sk_buff *skb)
{
    ......
 
#ifdef CONFIG_SYN_COOKIES
    if (!th->rst && !th->syn && th->ack)
        sk = cookie_v4_check(sk, skb, &(IPCB(skb)->opt));
#endif
    return sk;
}
      由于在服务器端没有保存未完成连接的信息,所以在半连接队列或 ehash 散列表中都不会找到对应的 sock 结构。如果开启了 SYN cookies 机制,则会检查接收到的数据包是否是 ACK 包,如果是,在cookie_v4_check() 中会调用 cookie_check() 函数检查 ACK 包中的 cookie 值是否有效。如果有效,则会分配 request_sock 结构,并根据 ACK 包初始化相应的成员,开始构建描述连接的 sock 结构。创建过程和正常的连接创建过程一样。  

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
网络协议 Linux
字节一面:服务端挂了,客户端的 TCP 连接还在吗?
收到一位读者的私信,说字节面试有这么一个问题:服务端挂了,客户端的 TCP 连接会发生什么? 如果「服务端挂掉」指的是「服务端进程崩溃」,那么这个读者猜的想法是对的,服务端的进程在发生崩溃的时候,内核会发送 FIN 报文,与客户端进行四次挥手。 但是,如果「服务端挂掉」指的是「服务端主机宕机」,那么是不会发生四次挥手的,具体后续会发生什么?还要看客户端会不会发送数据? 如果客户端会发送数据,由于服务端已经不存在,客户端的数据报文会超时重传,当重传次数达到一定阈值后,会断开 TCP 连接; 如果客户端一直不会发送数据,再看客户端有没有开启 TCP keepalive 机制? 如果有开启,客
142 0
|
3月前
|
网络协议
【qt】TCP客户端信息的接受和发送
【qt】TCP客户端信息的接受和发送
33 0
|
1月前
|
存储 网络协议 Java
【网络】UDP回显服务器和客户端的构造,以及连接流程
【网络】UDP回显服务器和客户端的构造,以及连接流程
49 2
|
2月前
|
运维 网络协议
深入解析TCP三次握手与四次挥手:建立与断开连接的关键过程
深入解析TCP三次握手与四次挥手:建立与断开连接的关键过程
133 0
|
3月前
|
网络协议 算法
SYN Cookie技术
【8月更文挑战第18天】
117 4
|
3月前
|
网络协议 Linux 网络安全
SYN Cookie技术原理
【8月更文挑战第21天】
123 1
|
3月前
|
网络协议 网络性能优化 开发者
深入理解TCP连接的建立过程
【8月更文挑战第24天】
148 0
|
11月前
|
Cloud Native Go
线上 udp 客户端请求服务端客户端句柄泄漏问题
线上 udp 客户端请求服务端客户端句柄泄漏问题
|
网络协议 Java
《bug记录》在利用TCP协议创建【服务器-客户端交互程序】中出现的一些问题
《bug记录》在利用TCP协议创建【服务器-客户端交互程序】中出现的一些问题
|
存储 网络协议 数据库
SIP协议 会话发起协议(一)
SIP协议 会话发起协议(一)
219 0