TCP 协议详解(二)-- TCP首部详解与抓包分析实践(上)

前言

TCP(Transmisson Control Protocol)又叫传输控制协议作为传输层最重要的协议,对于信息的可靠传输有着重要的意义,针对这一协议的攻击也数不胜数,这里就对这一协议以及相关内容进行详细的总结,将从以下几个方面进行介绍。
本文以韩立刚老师的《计算机网络》网课为基础,感兴趣的话可以私信我要资料
这一章讲TCP首部的以下几个部分,想了解窗口到填充的内容,请移步下一篇博客

1. TCP首部介绍(端口、序号、确认号、数据偏移)

先通过图看一下
在这里插入图片描述
如图,大致上,TCP首部包括20字节的固定首部部分和选项(长度可变)部分,然后TCP首部和TCP的数据部分组成组成TCP报文段,这是在传输层,TCP报文段在网络层就成为了网络层的IP数据部分,然后再加上IP首部就组成了ip数据包。
这一章聚焦TCP首部部分。
由图可知,TCP首部的主体部分是20个字节的固定首部,里面规定记录了多数信息,选项和填充里的信息是两台计算机需要协商的其他内容,后面会讲到。本章主要讲固定部分。
固定部分共分为5行,每行4个字节,逐行进行介绍

1. 源端口和目标端口
端口对应着进程,TCP传输的数据要从A计算机的一个进程传输到B计算机的一个的话,除了在网络层通过指定IP地址来唯一的确定目标计算机,还需要通过在传输层的TCP首部中说明自己携带的信息来自于自己的哪个端口,又需要到达目标计算机的哪一个端口,从而被目标计算机的特定进程所使用,从而与网络层的IP地址一起构成完整的套接字。
源端口和目标端口各占两个字节,也就是16位。
大家都知道,计算机的端口范围是0-65535,而16位的二进制能够表示的十进制的范围也就是0-65535。
2. 序号
序号标记着TCP报文中数据部分的第一个字节在源文件中是第几个字节
如图:

1-99 代表着计算机中文件的字节流,其是有顺序的,将其存入TCP缓存,然后分段通过TCP协议进行传输,那么在传输的过程中,需要加入TCP首部,为了表明TCP数据包的“身份”,用其携带数据的第一个字节在其源文件中的序号作为整个TCP报文的序号,让报文具有唯一性和特定性,如图:
在这里插入图片描述
序号占4个字节,这个大小是足足够用了。
3. 确认号
当B计算机收到一个数据报文以后,需要给A一个反馈,表示其已经收到相应数据报文,并让其发送下一个数据报文,首部中的确认号就是起这个作用,其具体值是已经收到数据的最后一个字节在源文件(字节流)中的顺序序号加1,如图:
在这里插入图片描述
在这里插入图片描述
然后后面的顺序就是在重复这一过程。
4. 数据偏移
前文已经说过,首部包括20字节的固定首部,再加上长度可变的选项,那么既然长度不确定,那么哪里是真正数据部分的开始呢?如果不标明的话,接收方就不知道在哪里开始读取数据,这种标明数据开始位置的方式就是添加数据偏移完成的。
“数据偏移”这名字很晦涩,其实就是4个二进制位,从0000到1111,表示的十进制是从0到15,这里问题就出现了,固定首部就已经是20个,而数据偏移的最大值才是15,这还怎么表明真正数据开始的位置?
为了解决这个问题,TCP协议在这里规定了,这里的0到15表示的0到60,也就是说每个数字表示的意思是它本身的4倍,例如1表示4, 3表示12, 15表示60,那么又会出现问题,当数据开始的地方不是4的整数倍怎么办,协议的制定者也想到了这个问题,因此在首部的选项那里,后面有“填充”值,这个值无意义,只是保证整个首部的字节数是4的整数倍,和数据偏移这里相适应,如图:
在这里插入图片描述
既然最大值是60,固定首部占20,那么选项的大小也就是0到40个字节。
5. 保留

2. 抓包分析TCP首部

本节通过实验对上一节介绍的TCP首部进行分析。
实验内容:使用虚拟机访问阿里云服务器中的一个网站,通过抓包对来往TCP数据包进行抓取分析
实验环境:client:win7虚拟机 server:阿里云服务器
使用工具:ethereal抓包工具
第一步:访问网站,抓取数据包,如图:
在这里插入图片描述
我的网站域名是ningcui.site,大家有兴趣的可以试着攻击一下。
访问结束后各类包的数量如下:

可以看到,通过ARP(地址解析协议)查找网管的包,通过UDP向DNS服务器发送域名解析的包,已经网站和客户端互相传输数据的TCP包
2. 抓取的数据包如下:
在这里插入图片描述
在这里插入图片描述
如图,客户端有两个端口53376和53377都与服务器建立了TCP 连接,为了分析方便,只选取其中一个,即53377为例:
通过“tcp.port eq 53377”来筛选端口,如图:
在这里插入图片描述
三次握手的过程将在下面第三节进行介绍,现在主要分析连接已经建立以后的数据传输部分。
这里选取连接建立以后的6个tcp数据包,如下:
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
根据以上六个包可以得出以下示意图:

在这里插入图片描述
如图,黄色的是数据,蓝色的是首部。

3. TCP首部标记位介绍

在保留字段后面有6个二进制位,每个位自然也就有可能有两种状态:0或者1
如图:
在这里插入图片描述
分别为URG(urgent的缩写),ACK(acknowledge的缩写),PSH(push的缩写),RST(reset的缩写),SYN(Synchronize的缩写),FIN(finish的缩写)
其实从字面意思也很好理解,分别是紧急,确认,往前推,充值,同步,完成的意思。
下面一一进行分析

  1. URG:考虑一种情况,当你想终止TCP数据报文的交互,向服务器发送终止命令的数据包如果还是按照原来的方式跟在缓存的队列后,等待传送,那么这个操作就不能及时的传送,这个时候就需要把URG这一标记位置位1,那么这一报文就会进入发送的最前列(插队,而且是插在最前面),这样就使较为紧急的数据得以先传送。
  2. ACK:只有当这个标记位置为1时,前文讲到的“确认号”也有效。
  3. SYN:SYN要和ACK一起说明,因为涉及到工作面试中将常会遇到的问题:三次握手和四次挥手,下面着重介绍一下三次握手的过程,从而理解这两个标志位的作用。
    拿刚才抓的那一系列包的前三个做例子,第一个为:
    在这里插入图片描述
    由图可知,client先向服务器发送了一个tcp包,其中两个标志位分别为ACK:0,SYN:1,序列值Seq设为0,确认号此时是无效的,也默认为0,长度为0,也就是说不传送任何有效数据,只是建立连接,协商MSS等数据,此时只有SYN置为1,其他都没有意义,这是第一次握手。
    第二个包为:
    在这里插入图片描述
    接着服务器做出响应,发出的TCP报文将ACK标志位置为1,这样确认号就有了意义,为了向客户端表明自己收到了这个连接请求,将对方发来的Seq加上1也就是0+1=1作为确认号(ack)发回给客户端,同时SYN置为1,也向客户端发送长度为0的序列。这是第二次握手。
    第三个包为:
    在这里插入图片描述
    客户端在收到响应包以后,为了向服务器表明自己收到了这个响应,在对方发来的seq基础上加上1也就是0+1=1作为ack值发换回对方,然后根据对方的确认号,发送Seq为1的值 ,此时已经完成了同步,SYN已经失去了作用,故在后来传输数据的过程中一直置为0

大家也看到了,关于ACK和ack, 1和0的问题,搞得是不是脑壳疼,其实这都是表示不严谨和数值选择不合适导致的,下面我将对其进行严格的区分,选择不那么容易混淆的数字进行讲解,和大家一起掌握这个重要的知识点
大家首先要搞明白的是ACK和ack,虽然只是大小写的不同,好多讲解中都没有说清楚,这里的ACK是标记位中的值,它是个布尔值,只能是0或者1,而ack是确认号,其表示的是对于信息的确认,是对方发来的序列号+1得到的值,你可以理解成是催着对方接着发这个序列的数据,其是一个整数。
还有就是在这三次握手中的1和0太混乱,我举得例子中就是这样,那么我们就假如发送方和接收方第一次发送的序列值不是0,而是88和10(随便)

在这里插入图片描述
这样应该更加好理解了。

  1. PSH: 下列这张图应该很好理解。在这里插入图片描述
  2. RST: 当连接被不正常的中断时,整个TCP需要重置,这个时候RST就需要置为1
  3. FIN: 当数据已经传输完成时,需要把这个值置为1,代表整个TCP连接已经完成。断开连接。

猜你喜欢

转载自blog.csdn.net/qq_29566629/article/details/106047458
今日推荐