TCP三次握手的理论知识

描述

关于TCP三次握手的理论知识,往上一搜一大片,本文就跳过理论,直接上手。Let’s go。

准备知识

抓一个TCP三次握手的包

开启三个窗口,窗口1执行命令:

sudo tcpdump -i lo -nn -s0 -vvv port 7899 -A -X

这个命令用来抓包,抓的是7899端口的包。-A和-X是为了显示详细的包内容,方便分析。如果不习惯用tcpdump直接分析,也可以使用wireshark,更加直观一些。

窗口2执行命令:

nc -l 7899

该命令监听7899端口,相当于启动了一个监听7899端口的server。当然你要是有兴趣的话,可以用代码写一个server。

窗口3执行命令:

telnet 127.0.0.1 7899

这个命令是向127.0.0.1:7899建立连接,相当于client执行connect函数。

这个命令一执行,就会连接到7899端口上 ,在第一个窗口上立即就会抓到连续的三个包,如下图所示:

代码

如上步骤,演示了TCP建立连接的过程,tcpdump抓到的三个包,正好就是三次握手。

很多资料讲解三次握手时,都会有一幅类似于这样的图:

代码

我们对应抓到的三个包来看。

第一个包:

  • 127.0.0.1.48448 > 127.0.0.1.7899 说明是从client 发往server的, client的端口是48448

第二个包:

  • 127.0.0.1.7899 > 127.0.0.1.48448 说明是从server发往client的

第三个包:

  • 127.0.0.1.48448 > 127.0.0.1.7899 从client发往server

这个步骤,和上图大致是能一一对应上的。

除了这些简而易见的信息,还有一些 可能一时半会儿看不懂的东西,比如:

Flags [S], cksum 0xfe30 (incorrect -> 0x2d48), seq 3051156309, win 65495, options [mss 65495,sackOK,TS val 2052530964 ecr 0,nop,wscale 7], length 0

要了解这些东西,需要先了解TCP协议栈。

相关视频推荐

tcpip,accept,11个状态,细枝末节的秘密

手写一个用户态协议栈以及零拷贝的实现

netmap到dpdk,硬件到协议栈,4个维度构建网络体系

需要C/C++ Linux服务器架构师学习资料加qun812855908获取(资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等),免费分享

代码

了解一下TCP协议栈

首先,我们应该知道,一个完整的以太网帧,包含了ethdr + iphdr + tcpdhr + data + etend

其中,以太网头占14字节,IP头占20字节,TCP头占20字节,以太网尾占4字节,应用数据大小不定,但不会超过一个MTU。

因为我们只研究三次握手,所以关于以太网帧,了解这些就够了。

代码

我们再来看看具体的TCP协议栈:

代码

TCP协议栈包含:

16位源端口号,占2字节

16位目的端口号,占2字节

32位序号(seq),占4字节

32位确认序号(ack),占4字节

4位首部长度,占0.5字节

6位保留位,占0.75字节

6位标志位,占0.75字节, 以上:4位首部长度+6位保留长度+6位标志位,合计16位,计2字节

标志位包括:

 URG
  • 紧急指针标志
  • 此标志用于将输入数据标识为“紧急”。这样的进入段不必等待直到先前段被接收端消耗,而是直接发送并立即处理。
    ACK
  • 用于确认数据包的成功接收
    PSH
  • 推送标志
  • 就是指数据包到达接收端以后,不对其进行队列处理,而是尽可能的将数据交给应用程序处理
    RST
  • 重置标志
  • 当段到达不用于当前连接时,使用复位标志,表示主机已重置连接
    SYN
  • 发送/同步标志
  • 用来建立连接,一般和ACK搭配使用
    FIN
  • 结束标志
  • 用于结束一个TCP会话, 一般用于四次挥手

16位窗口大小(window size),占2字节

16位校验和(checksum),占2字节

16位紧急指针,占2字节

庖丁解牛,深度剖析TCP协议栈的三次握手

有了以上这些知识,我们再来解析上面的协议栈。

第一个包

127.0.0.1.48448 > 127.0.0.1.7899: Flags [S], cksum 0xfe30 (incorrect -> 0x2d48), seq 3051156309, win 65495, options [mss 65495,sackOK,TS val 2052530964 ecr 0,nop,wscale 7], length 0
0x0000: 4510 003c dbf7 4000 4006 60b2 7f00 0001 E..<..@.@.`.....
0x0010: 7f00 0001 bd40 1edb b5dc f355 0000 0000 .....@.....U....
0x0020: a002 ffd7 fe30 0000 0204 ffd7 0402 080a .....0..........
0x0030: 7a57 2314 0000 0000 0103 0307 zW#.........

十六进制报文中,前20个字节是IP协议头,后20个字节虽然也属于TCP协议 ,但是是可选项option,并非标准的TCP协议一定有的内容,所以我们真正关心的内容 , 是下面高亮的部分:

代码

即:

bd40 1edb b5dc f355 0000 0000 a002 ffd7 fe30 0000

接下来,我们逐个字节解析:

16位源端口, 即 bd40, 转换成10进制为48448

16位目的端口,即1edb,转换成10进制为7899

  • 从以上信息可知,该条消息是从48448发往7899端口,即客户端发往服务端

32位序号:b5dc f355, 即3051156309

32位确认号:0000 0000,即0

后面三个域由于不是 完整的字节,放在一块解析:

  • a002翻译成二进制 ,为:1010 0000 0000 0010
  • 其中,4位首部长度,为1010,即10
  • 6位保留字段,即0000 00,不做解释
  • 6位标志位,即00 0010
    标志位要解释一下 :
    

代码

标志位哪一位设置为1,就代表当前属于什么包

由上面对应关系,可知当前是一个SYN包。

16位窗口大小:ffd7, 即65495

16位校验和,即:fe30

16位紧急指针,即0000

由以上内容,我们提取一些关键信息:

第一次握手:

  • 客户端发往服务端
  • 标志位为SYN
  • seq为3051156309
  • ack为0

第二个包

127.0.0.1.7899 > 127.0.0.1.48448: Flags [S.], cksum 0xfe30 (incorrect -> 0xd4f6), seq 2031501770, ack 3051156310, win 65483, options [mss 65495,sackOK,TS val 2052530964 ecr 2052530964,nop,wscale 7], length 0
0x0000: 4500 003c 0000 4000 4006 3cba 7f00 0001 E..<..@.@.<.....
0x0010: 7f00 0001 1edb bd40 7916 41ca b5dc f356 .......@y.A....V
0x0020: a012 ffcb fe30 0000 0204 ffd7 0402 080a .....0..........
0x0030: 7a57 2314 7a57 2314 0103 0307 zW#.zW#.....

由上面的知识,我们知道TCP报文主要是下面这段:

1edb bd40 7916 41ca b5dc f356 a012 ffcb fe30 0000

通过同样的方法,可以解析出:

第二次握手:

  • 服务端发往客户端
  • 标志位为ACK+SYN
  • seq为2031501770
  • ack为3051156310, 正好是第一次握手的seq+1

第三个包

127.0.0.1.48448 > 127.0.0.1.7899: Flags [.], cksum 0xfe28 (incorrect -> 0xfbb2), seq 1, ack 1, win 512, options [nop,nop,TS val 2052530964 ecr 2052530964], length 0
0x0000: 4510 0034 dbf8 4000 4006 60b9 7f00 0001 E..4..@.@.`.....
0x0010: 7f00 0001 bd40 1edb b5dc f356 7916 41cb .....@.....Vy.A.
0x0020: 8010 0200 fe28 0000 0101 080a 7a57 2314 .....(......zW#.
0x0030: 7a57 2314 zW#.

TCP协议部分:

bd40 1edb b5dc f356 7916 41cb 8010 0200 fe28 0000

可以解析出 :

第三次握手:

  • 客户端发往服务端
  • 标志位:ACK
  • seq为3051156310,为第一次我收的 seq+1,也是第二次握手的ack
  • ack为2031501771, 为 第二次握手的seq+1

归纳:

以上内容,如果用比较直观的方式总结一下 ,大约如下图:

代码

为什么需要三次握手

又回到老生常谈的话题:为什么需要三次握手?少一次行不行?只握手一次成不成?

在聊这个话题之前,我们引入一下著名科幻小说《三体》中叶文杰教主和三体文明建立联系的过程。

首先,叶教主向三体文明发送了一条消息,紧接着,三体人回复了一条消息,内容是“不要回答,不要回答,不要回答!”然后叶教主回复了这条消息 ,导致地球成功被三体人定位。

不得不说,大刘是懂TCP协议的。至少他懂三次握手的重要性。

第一次发消息,你说三体人收到没有?肯定是收到了的。但这个连接可靠不?明显不可靠。对于三体人来说,他怎么知道这个消息是谁发的?发消息的文明是否还活着?对于地球来说,更是如此,他怎么知道 这条消息对方肯定收到了?又没有人收?

第二次发消息,三体人差不多要把ACK标志写在脸上了,就是明明白白告诉你,我这是一个ACK消息,你只要不应答这个ACK,我们这个连接就建立不成,三体小说就全剧终。这就相当于三体人告诉叶教主:我活着,并且能收到你的消息,但是我还不知道你是谁,你能不能收到我这条消息。

所以第三条消息,狡猾的大刘当然不会让三体就此game over,就是老叶告诉三体人,我也能收到你的消息,从此以后,咱们是“同志”了。

类比三次握手,和这个步骤非常相似,缺少其中任意一环,这个连接都是不可靠的,因为你不知道对方能不能收到我的消息。所以三次握手,并不是表示连接“可达”的,而是表示连接“可靠”的。这之间是有区别的,可达很简单,UDP也能可达,一次握手也是可达的,但是并不可靠。因为无法知道这条消息对方能不能正确接收到。只有这样反复确认后,才能表示这个连接是可靠的连接。

有杠精肯定表示不服,说理虽然是这么个理,但是会不会有巧合啊。比如某个服务既是客户端又是服务端,我在给你发第一次握手的时候,你也恰好在给我发第一次握手,让我误以为你给我的消息是第二次握手的回包,从而建立了一个不可靠的连接?

而杠精之所以是杠精,就是因为木有脑子。你考虑的问题,咱们祖师爷肯定都考虑到了。

我们在前面分析三次握手的过程的时候,为什么要强调ack = 上一次的seq+1?就是代表我不仅收到了你的,我还在你的seq上加1,代表我收到的确实是你的消息,这就相当于给这条消息打上了独一无二的标志,别人想鱼目混珠都不可能。

最后,咱们说说,三体人和叶文杰建立的是TCP连接吗?咳咳,明显不是。本文只是举例类比。要知道,叶文杰第一个包可是broadcast,谁都能收到的。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分