专栏首页moon聊技术动图图解!没有accept,能建立TCP连接吗?

动图图解!没有accept,能建立TCP连接吗?

握手建立连接流程

上面这个动图,是我们平时客户端和服务端建立连接时的代码流程。

对应的是下面一段简化过的服务端伪代码。

int main()
{
    /*Step 1: 创建服务器端监听socket描述符listen_fd*/    
    listen_fd = socket(AF_INET, SOCK_STREAM, 0);

    /*Step 2: bind绑定服务器端的IP和端口,所有客户端都向这个IP和端口发送和请求数据*/    
    bind(listen_fd, xxx);

    /*Step 3: 服务端开启监听*/    
    listen(listen_fd, 128);

    /*Step 4: 服务器等待客户端的链接,返回值cfd为客户端的socket描述符*/    
    cfd = accept(listen_fd, xxx);

      /*Step 5: 读取客户端发来的数据*/
      n = read(cfd, buf, sizeof(buf));
}

估计大家也是老熟悉这段伪代码了。

需要注意的是,在执行listen()方法之后还会执行一个accept()方法。

一般情况下,如果启动服务器,会发现最后程序会阻塞在accept()里。

此时服务端就算ok了,就等客户端了。

那么,再看下简化过的客户端伪代码。

int main()
{
    /*Step 1: 创建客户端端socket描述符cfd*/    
    cfd = socket(AF_INET, SOCK_STREAM, 0);

    /*Step 2: connect方法,对服务器端的IP和端口号发起连接*/    
    ret = connect(cfd, xxxx);

    /*Step 4: 向服务器端写数据*/
    write(cfd, buf, strlen(buf));
}

客户端比较简单,创建好socket之后,直接就发起connect方法。

此时回到服务端,会发现之前一直阻塞的accept方法,返回结果了

这就算两端成功建立好了一条连接。之后就可以愉快的进行读写操作了。

那么,我们今天的问题是,如果没有这个accept方法,TCP连接还能建立起来吗?

其实只要在执行accept() 之前执行一个 sleep(20),然后立刻执行客户端相关的方法,同时抓个包,就能得出结论。

不执行accept时抓包结果

从抓包结果看来,就算不执行accept()方法,三次握手照常进行,并顺利建立连接。

更骚气的是,在服务端执行accept()前,如果客户端发送消息给服务端,服务端是能够正常回复ack确认包的。

并且,sleep(20)结束后,服务端正常执行accept(),客户端前面发送的消息,还是能正常收到的。

通过这个现象,我们可以多想想为什么。顺便好好了解下三次握手的细节。

三次握手的细节分析

我们先看面试八股文的老股,三次握手。

TCP三次握手

服务端代码,对socket执行bind方法可以绑定监听端口,然后执行listen方法后,就会进入监听(LISTEN)状态。内核会为每一个处于LISTEN状态的socket 分配两个队列,分别叫半连接队列和全连接队列

每个listen Socket都有一个全连接和半连接队列

半连接队列、全连接队列是什么

半连接队列和全连接队列

  • 半连接队列(SYN队列),服务端收到第一次握手后,会将sock加入到这个队列中,队列内的sock都处于SYN_RECV 状态。
  • 全连接队列(ACCEPT队列),在服务端收到第三次握手后,会将半连接队列的sock取出,放到全连接队列中。队列里的sock都处于 ESTABLISHED状态。这里面的连接,就等着服务端执行accept()后被取出了。

看到这里,文章开头的问题就有了答案,建立连接的过程中根本不需要accept() 参与, 执行accept()只是为了从全连接队列里取出一条连接。

我们把话题再重新回到这两个队列上。

虽然都叫队列,但其实全连接队列(icsk_accept_queue)是个链表,而半连接队列(syn_table)是个哈希表

半连接全连接队列的内部结构

为什么半连接队列要设计成哈希表

先对比下全连接里队列,他本质是个链表,因为也是线性结构,说它是个队列也没毛病。它里面放的都是已经建立完成的连接,这些连接正等待被取走。而服务端取走连接的过程中,并不关心具体是哪个连接,只要是个连接就行,所以直接从队列头取就行了。这个过程算法复杂度为O(1)

半连接队列却不太一样,因为队列里的都是不完整的连接,嗷嗷等待着第三次握手的到来。那么现在有一个第三次握手来了,则需要从队列里把相应IP端口的连接取出,如果半连接队列还是个链表,那我们就需要依次遍历,才能拿到我们想要的那个连接,算法复杂度就是O(n)。

而如果将半连接队列设计成哈希表,那么查找半连接的算法复杂度就回到O(1)了。

因此出于效率考虑,全连接队列被设计成链表,而半连接队列被设计为哈希表。

怎么观察两个队列的大小

查看全连接队列
# ss -lnt
State      Recv-Q Send-Q     Local Address:Port           Peer Address:Port
LISTEN     0      128        127.0.0.1:46269              *:*              

通过ss -lnt命令,可以看到全连接队列的大小,其中Send-Q是指全连接队列的最大值,可以看到我这上面的最大值是128Recv-Q是指当前的全连接队列的使用值,我这边用了0个,也就是全连接队列里为空,连接都被取出来了。

当上面Send-QRecv-Q数值很接近的时候,那么全连接队列可能已经满了。可以通过下面的命令查看是否发生过队列溢出

# netstat -s | grep overflowed
    4343 times the listen queue of a socket overflowed

上面说明发生过4343次全连接队列溢出的情况。这个查看到的是历史发生过的次数

如果配合使用watch -d 命令,可以自动每2s间隔执行相同命令,还能高亮显示变化的数字部分,如果溢出的数字不断变多,说明正在发生溢出的行为。

# watch -d 'netstat -s | grep overflowed'
Every 2.0s: netstat -s | grep overflowed                                Fri Sep 17 09:00:45 2021

    4343 times the listen queue of a socket overflowed
查看半连接队列

半连接队列没有命令可以直接查看到,但因为半连接队列里,放的都是SYN_RECV 状态的连接,那可以通过统计处于这个状态的连接的数量,间接获得半连接队列的长度。

# netstat -nt | grep -i '127.0.0.1:8080' | grep -i 'SYN_RECV' | wc -l
0

注意半连接队列和全连接队列都是挂在某个Listen socket上的,我这里用的是127.0.0.1:8080,大家可以替换成自己想要查看的IP端口

可以看到我的机器上的半连接队列长度为0,这个很正常,正经连接谁会没事老待在半连接队列里。

当队列里的半连接不断增多,最终也是会发生溢出,可以通过下面的命令查看。

# netstat -s | grep -i "SYNs to LISTEN sockets dropped" 
    26395 SYNs to LISTEN sockets dropped

可以看到,我的机器上一共发生了26395次半连接队列溢出。同样建议配合watch -d 命令使用。

# watch -d 'netstat -s | grep -i "SYNs to LISTEN sockets dropped"'
Every 2.0s: netstat -s | grep -i "SYNs to LISTEN sockets dropped"       Fri Sep 17 08:36:38 2021

    26395 SYNs to LISTEN sockets dropped

全连接队列满了会怎么样?

如果队列满了,服务端还收到客户端的第三次握手ACK,默认当然会丢弃这个ACK。

但除了丢弃之外,还有一些附带行为,这会受 tcp_abort_on_overflow 参数的影响。

# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
  • tcp_abort_on_overflow设置为 0,全连接队列满了之后,会丢弃这个第三次握手ACK包,并且开启定时器,重传第二次握手的SYN+ACK,如果重传超过一定限制次数,还会把对应的半连接队列里的连接给删掉。

tcp_abort_on_overflow为0

  • tcp_abort_on_overflow设置为 1,全连接队列满了之后,就直接发RST给客户端,效果上看就是连接断了。

这个现象是不是很熟悉,服务端端口未监听时,客户端尝试去连接,服务端也会回一个RST。这两个情况长一样,所以客户端这时候收到RST之后,其实无法区分到底是端口未监听,还是全连接队列满了

tcp_abort_on_overflow为1

半连接队列要是满了会怎么样

一般是丢弃,但这个行为可以通过 tcp_syncookies 参数去控制。但比起这个,更重要的是先了解下半连接队列为什么会被打满。

首先我们需要明白,一般情况下,半连接的"生存"时间其实很短,只有在第一次和第三次握手间,如果半连接都满了,说明服务端疯狂收到第一次握手请求,如果是线上游戏应用,能有这么多请求进来,那说明你可能要富了。但现实往往比较骨感,你可能遇到了SYN Flood攻击

所谓SYN Flood攻击,可以简单理解为,攻击方模拟客户端疯狂发第一次握手请求过来,在服务端憨憨地回复第二次握手过去之后,客户端死活不发第三次握手过来,这样做,可以把服务端半连接队列打满,从而导致正常连接不能正常进来。

syn攻击

那这种情况怎么处理?有没有一种方法可以绕过半连接队列

有,上面提到的tcp_syncookies派上用场了。

# cat /proc/sys/net/ipv4/tcp_syncookies
1

当它被设置为1的时候,客户端发来第一次握手SYN时,服务端不会将其放入半连接队列中,而是直接生成一个cookies,这个cookies会跟着第二次握手,发回客户端。客户端在发第三次握手的时候带上这个cookies,服务端验证到它就是当初发出去的那个,就会建立连接并放入到全连接队列中。可以看出整个过程不再需要半连接队列的参与。

tcp_syncookies=1

会有一个cookies队列吗

生成是cookies,保存在哪呢?是不是会有一个队列保存这些cookies?

我们可以反过来想一下,如果有cookies队列,那它会跟半连接队列一样,到头来,还是会被SYN Flood 攻击打满。

实际上cookies并不会有一个专门的队列保存,它是通过通信双方的IP地址端口、时间戳、MSS等信息进行实时计算的,保存在TCP报头seq里。

tcp报头_seq的位置

当服务端收到客户端发来的第三次握手包时,会通过seq还原出通信双方的IP地址端口、时间戳、MSS,验证通过则建立连接。

cookies方案为什么不直接取代半连接队列?

目前看下来syn cookies方案省下了半连接队列所需要的队列内存,还能解决 SYN Flood攻击,那为什么不直接取代半连接队列?

凡事皆有利弊,cookies方案虽然能防 SYN Flood攻击,但是也有一些问题。因为服务端并不会保存连接信息,所以如果传输过程中数据包丢了,也不会重发第二次握手的信息。

另外,编码解码cookies,都是比较耗CPU的,利用这一点,如果此时攻击者构造大量的第三次握手包(ACK包),同时带上各种瞎编的cookies信息,服务端收到ACK包以为是正经cookies,憨憨地跑去解码(耗CPU),最后发现不是正经数据包后才丢弃。

这种通过构造大量ACK包去消耗服务端资源的攻击,叫ACK攻击,受到攻击的服务器可能会因为CPU资源耗尽导致没能响应正经请求。

ack攻击

没有listen,为什么还能建立连接

那既然没有accept方法能建立连接,那是不是没有listen方法,也能建立连接?是的,之前写的一篇文章提到过客户端是可以自己连自己的形成连接(TCP自连接),也可以两个客户端同时向对方发出请求建立连接(TCP同时打开),这两个情况都有个共同点,就是没有服务端参与,也就是没有listen,就能建立连接。

当时文章最后也留了个疑问,没有listen,为什么还能建立连接?

我们知道执行listen方法时,会创建半连接队列和全连接队列。

三次握手的过程中会在这两个队列中暂存连接信息。

所以形成连接,前提是你得有个地方存放着,方便握手的时候能根据IP端口等信息找到socket信息。

那么客户端会有半连接队列吗?

显然没有,因为客户端没有执行listen,因为半连接队列和全连接队列都是在执行listen方法时,内核自动创建的。

但内核还有个全局hash表,可以用于存放sock连接的信息。这个全局hash表其实还细分为ehash,bhash和listen_hash等,但因为过于细节,大家理解成有一个全局hash就够了,

在TCP自连接的情况中,客户端在connect方法时,最后会将自己的连接信息放入到这个全局hash表中,然后将信息发出,消息在经过回环地址重新回到TCP传输层的时候,就会根据IP端口信息,再一次从这个全局hash中取出信息。于是握手包一来一回,最后成功建立连接。

TCP同时打开的情况也类似,只不过从一个客户端变成了两个客户端而已。

总结

  • 每一个socket执行listen时,内核都会自动创建一个半连接队列和全连接队列。
  • 第三次握手前,TCP连接会放在半连接队列中,直到第三次握手到来,才会被放到全连接队列中。
  • accept方法只是为了从全连接队列中拿出一条连接,本身跟三次握手几乎毫无关系
  • 出于效率考虑,虽然都叫队列,但半连接队列其实被设计成了哈希表,而全连接队列本质是链表。
  • 全连接队列满了,再来第三次握手也会丢弃,此时如果tcp_abort_on_overflow=1,还会直接发RST给客户端。
  • 半连接队列满了,可能是因为受到了SYN Flood攻击,可以设置tcp_syncookies,绕开半连接队列。
  • 客户端没有半连接队列和全连接队列,但有一个全局hash,可以通过它实现自连接或TCP同时打开。

本文分享自微信公众号 - moon聊技术(onetraveller_llxz)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-10-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一道腾讯面试题目:没有listen,能否建立TCP连接

    这个题目是之前在我的QQ群里一个同学在腾讯面试过程中被问到的。当时在群里做了简单的讨论,今天系统的把这个问题分析一遍。

    glinuxer
  • 高性能网络编程(一)----accept建立连接(陶辉)

    http://blog.csdn.net/russell_tao/article/details/9111769

    bear_fish
  • 高性能网络编程(一)—-accept建立连接

    最近在部门内做了个高性能网络编程的培训,近日整理了下PPT,欲写成一系列文章从应用角度谈谈它。

    陶辉
  • TCP/IP详解之 《网络协议》图解 TCP 连接建立与释放

    http://blog.csdn.net/chenhanzhun/article/details/41622555

    bear_fish
  • 高性能网络编程(一)—-ACCEPT建立连接

    http://taohui.pub/2016/01/25/%E9%AB%98%E6%80%A7%E8%83%BD%E7%BD%91%E7%BB%9C%E7%B...

    bear_fish
  • 干货 | 携程一次Dubbo连接超时问题的排查

    顾海洋,携程框架架构研发部技术专家,负责携程分布式服务化领域的工作。目前主要负责 Dubbo 在携程的二次开发和推广工作。

    携程技术
  • Kubernetes 疑难杂症排查分享:神秘的溢出与丢包

    图片下载走的 k8s ingress,这个 ingress 路径对应后端 service 是一个代理静态图片文件的 nginx deployment,这个 de...

    imroc
  • 关于TCP 半连接队列和全连接队列

    最近碰到一个client端连接异常问题,然后定位分析并查阅各种资料文章,对TCP连接队列有个深入的理解 查资料过程中发现没有文章把这两个队列以及怎么观察他们的指...

    用户1263954
  • 追查iptables规则失效原因

    今天在工作中用到了一条iptables规则,虽然明白这条规则的意思,但结合之前对iptables的理解,想不明白为什么会这么工作,后来仔细研读iptables的...

    jeremyxu
  • 面试官:换人!他连 TCP 这几个参数都不懂

    TCP 性能的提升不仅考察 TCP 的理论知识,还考察了对于操作系统提供的内核参数的理解与应用。

    小林coding
  • 网络知识扫盲:扒开 TCP 的外衣,我看清了 TCP 的本质

    从阅读和在看数来看,大家对这个系列还是比较期待的,所以这周我全身心地投入本篇文章的编写,用了整整 4个晚上的时间梳理了这篇关于 TCP 的重点知识,另外还参考 ...

    Python进阶者
  • Linux Socket 编程简介和实现

    在 TCP/IP 协议中,”IP地址 + TCP或UDP端口号” 可以唯一标识网络通讯中的一个进程,”IP地址+端口号” 就称为 socket。本文以一个简单的...

    砸漏
  • Python 网络编程基础

    通常网络编程也被称为套接字(socket)编程,它最早可以追溯到 20 世纪 70 年代,在美国加利福尼亚大学的伯克利版本 UNIX系统(即BSD UNIX)上...

    arcticfox
  • Fundebug网站升级HTTP/2,真的变快了!

    作为新一代的HTTP协议,HTTP/2可以提高网站性能,优化用户体验,Fundebug也是时候升级HTTP/2了,虽然已经有点晚了。

    Fundebug
  • 你想知道的Socket,统统打包给你~

    实现网络间通信,要解决一个首要问题是-如何唯一标识一个进程,在网络上,通常利用ip地址+协议+端口号唯一标示网络中的一个进程。IP层的ip地址可以唯一标示...

    软测小生
  • Nginx高并发调优中常被忽略的参数

    从上面的解释来看,就是定义了一个队列,并设置了队列长度,那么这个队列是做什么的,接着往下看

    李俊鹏
  • linux网络编程之socket(二):C/S程序的一般流程和基本socket函数

    一、基于TCP协议的网络程序 下图是基于TCP协议的客户端/服务器程序的一般流程: ? 服务器调用socket()、bind()、listen()完成初始化...

    s1mba
  • 案例篇:服务吞吐量下降很厉害,怎么分析?

    在 Linux 系统中,常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。

    程序员小王
  • Iptables 介绍与使用

    连接跟踪是许多网络应用的基础。例如,Kubernetes Service、ServiceMesh sidecar、 软件四层负载均衡器 LVS/IPVS、Doc...

    Se7en258

扫码关注云+社区

领取腾讯云代金券