Wireshark网络协议分析 - TCP协议

在我的博客阅读本文

文章目录

  • 1. 基础
  • 2. 实战
      • 2.1. 用Go写一个简单的TCP服务器与客户端
      • 2.2. Wireshark抓包分析
      • 2.3. 限制数据包的大小——MSS与MTU
      • 2.4. 保证TCP的有序传输——Seq，Len与Ack
      • 2.5. TCP头标志位——URG，ACK，PSH，RST，SYN，FIN
      • 2.6. TCP连接建立——三次握手
      • 2.7. TCP连接释放——四次挥手
      • 2.8. 大包拆分——累计确认，TCP窗口
      • 2.9. 动态调整TCP窗口——从慢启动到阻塞避免
      • 2.10. 丢包问题——RTO与快速重传
      • 2.11. 减轻网络负担可能降低性能——延迟确认与Nagle算法
  • 3. 参考资料

1. 基础

根据TCP/IP四层模型，在TCP场景下如下图：

Untitled

其中，TCP头的信息：

Untitled

2. 实战

2.1. 用Go写一个简单的TCP服务器与客户端

要分析TCP协议，尽管可以直接使用一个http的访问进行抓包，但是http的过程中又涉及DNS，ARP等过程混淆我们，为了纯粹的分析TCP协议，我们这里使用Golang写了一个简单的9830端口的TCP服务器与客户端，源代码简单展示如下：

服务端：

package serverimport ("fmt""net""os""strings""test/util"
)func StartTCPServer(c chan<- string) {listener, err := net.Listen("tcp", "localhost:9830")if err != nil {util.HandleError(err)os.Exit(1)}defer listener.Close()c <- "ready"// 等待连接conn, err := listener.Accept()if err != nil {util.HandleError(err)os.Exit(1)}// 处理连接handleRequest(conn)
}func handleRequest(conn net.Conn) {defer conn.Close()var res strings.Builderbuf := make([]byte, 1024)for {n, err := conn.Read(buf)if err != nil {break}res.Write(buf[:n])}fmt.Print("Received client message, size:", res.Len())
}

客户端：

package clientimport ("fmt""net""os""strings""test/util"
)func StartTCPClient() {conn, err := net.Dial("tcp", "localhost:9830")if err != nil {util.HandleError(err)os.Exit(1)}defer conn.Close()// 发送200kb消息largeMessage := strings.Repeat("A", 200*1024)_, err = conn.Write([]byte(largeMessage))if err != nil {util.HandleError(err)os.Exit(1)}fmt.Println("Sent message to server!")
}

执行入口：

package mainimport ("fmt""sync"c "test/internal/client"s "test/internal/server"
)// main wireshark filter express: tcp.port==9830
func main() {var wg sync.WaitGroupwg.Add(2)serverReady := make(chan string, 1)go func() {s.StartTCPServer(serverReady)wg.Done()}()go func() {<-serverReadyc.StartTCPClient()wg.Done()}()wg.Wait()
}

编译执行，控制台输出如下：

Untitled

2.2. Wireshark抓包分析

由于我们这里TCP的客户端和服务端都是面向localhost ，使用adapter for loopback traffic capture接口捕获回环流量，过滤器过滤tcp端口9830即可：

tcp.port==9830

Untitled

需要注意，即使代码和我一样，最终抓包的数据依然会有差距，因为MTU，window size等参数会因为OS的策略不同有差异，求同存异抓共性。

大体分为三部分：

  • 协议连接建立与确认：即包号92~96部分，图中具体又分为两部分：
    • 包号92~93中的Source和Destination都是::1，这个地址是IPV6的地址，类似于IPV4中的127.0.0.1。TCP客户端先尝试了连接IPV6的9830端口，被服务器中断（RST）。
    • 包号94~96尝试了尝试了IPV4的9803端口，这一次得到了服务器的正确回应，开始了**TCP协议中的“三次握手”，此时建立TCP连接**
  • 具体的业务数据交互：即包号97~103
  • 协议连接断开与确认：即包号104~107，也就是**TCP协议中的“四次挥手”，此时释放TCP连接**

点开包号96，我们查看其Network层的数据情况：

Untitled

Source Port之类的字段比较直观易于理解，下面我们重点看一下一些不太直观的字段代表的数据含义。

2.3. 限制数据包的大小——MSS与MTU

网络对包的大小是存在限制的，这部分是在建立TCP连接的“三次握手”中进行声明，即：

  • MSS（Maximum Segment Size，最大段大小）
  • MTU（Maximum Transmission Unit，最大传输单元）：MSS+ TCP头长度 + IP头长度即是MTU

Untitled

在“三次握手中”，包号94中，客户端向服务端声明了MSS=65495 ，可以计算MTU（单位为Byte，一般Wireshark中出现的数字单位都是Byte）：

MTU = 65495 + 20(TCP头) + 20(IP头) = 65535

同理，包号95中，服务端在给客户端的ACK包中也声明了自己的MSS，也可以计算出MTU。

客户端和服务端各自有MTU，实际的传输包的大小是由客户端与服务端2个MTU中较小的数值去决定的。

2.4. 保证TCP的有序传输——Seq，Len与Ack

TCP提供的是有序传输，每个数据段都要标上一个序号。

在实际场景中，TCP传输数据时并不能严格保证有序，总会出现乱序的情况，需要根据序号进行排序。

  • Len：length，数据长度
  • Seq：Sequence Number，序号，即上一个数据段Seq + Len，发送方和接收方都需各自维护Seq状态
  • Ack：Acknowledge Number，确认号，待接受的数据序号,发送方和接收方都需各自维护Ack状态

以包号97~99为例：

Untitled

  • 97号：客户端发送数据，声明自己的Seq=1，Len=65495
  • 98号：服务端声明自己的Seq=1，Len=0，同时计算Ack=65496，即发送方的Seq + Len
  • 99号：客户端发送数据，声明自己的Seq=65496，Len=65495，ACK为1，即上一步中服务端的Seq + Len

可以推断出：

  • Seq和Len主要表达的是作为发送方当前的数据序号和长度
  • Ack主要表达的是作为接收方的接收到的数据序号和长度的和
  • TCP通信中，一个客户端/服务端既有发送的场景，也有接受的场景，因此Seq，和Ack都各自需要单独维护，Len则是实际的数据长度。

2.5. TCP头标志位——URG，ACK，PSH，RST，SYN，FIN

TCP头包含一系列的标识位（也称作控制位或标志位），它们用于控制和管理TCP连接的不同方面。每个标识位都占用TCP头部中的1个比特。

Wireshark不仅帮我们“翻译”了当前封包的状态，也把TCP头的所有状态位都做了提示。

Untitled

  • URG（紧急）：表示紧急指针字段（Urgent Pointer）有效，用于指示紧急数据。
  • ACK（确认）：表示确认字段（Acknowledgment Field）有效。几乎所有的TCP报文，除了最初的SYN报文外，都会设置这个标志。
  • PSH（推送）：提示接收端应该立即将这个报文交给应用层，而不是等待缓冲区满。
  • RST（重置）：用于重置错误的连接，或拒绝非法的报文或打开的连接。
  • SYN（同步）：在建立连接时用来同步序列号。当一个连接开始时，用来初始化序列号并开始连接建立。
  • FIN（结束）：用于释放一个连接。当数据传输结束时，发送方用它来告诉接收方它已经结束发送数据。

2.6. TCP连接建立——三次握手

包号94~96行则为TCP的“三次握手”行为，发生在TCP连接建立之初：

Untitled

“三次握手”主要分为3步：

  1. 客户端 → 服务端：【SYN】申请建立连接，声明初始Seq
  2. 服务端 → 客户端：【SYN，ACK】收到连接请求，声明初始Seq，声明Ack=客户端声明的初始Seq + 1
  3. 客户端 → 服务端：【ACK】收到确认请求，声明Ack=服务端初始Seq + 1

2.7. TCP连接释放——四次挥手

包号104~107行则为TCP的“四次挥手”行为，发生在TCP连接需要中断，释放连接时：

Untitled

**“四次挥手”**主要分为4步，发起方可能是客户端，也可能是服务端：

  1. 发起方发起释放连接请求：【FIN，ACK】，声明Seq和Ack
  2. 接受方返回确认收到：【ACK】，声明Ack=第1.步中发起方的Seq + 1
  3. 接收方发起释放连接请求：【FIN，ACK】，声明Seq和Ack（与上一步一样）
  4. 发起方返回确认收到：【ACK】，声明Ack=第3.步中接收方的Seq + 1

2.8. 大包拆分——累计确认，TCP窗口

  • 我们TCP客户端代码中发送了一个200kb的字符串给服务端，之前分析过我们的MTU限制在65535b，不算TCP头和IP头的MSS为65495b。我们实际无法在一个数据帧中发送全部数据，需要按照MTU拆分为多个数据帧进行发送。
  • 多个数据帧的发送不一定每一条都需要等待接收方回复ACK，可以发送若干条数据帧之后，接收方回复一条ACK即可，这是TCP的累计确认。
  • TCP连接的一方连续发送的数据帧数是存在限制的，否则无限发送数据帧，另一方处理速率赶不上就会遇到Back Pressure（背压）的情况，这个限制则是TCP Window(TCP窗口)，即Wireshark中的Win的数值：

Untitled

  1. 包号95是三次握手的第二次，win=65535，这是声明自己的接受窗口大小是65535，在我们的例子中是服务端声明自己的接受窗口大小是65535，这是协商的初始窗口大小。
  2. 客户端按照MTU/MSS要求拆分数据帧
  3. 包号97，客户端向服务端发送了Len=65495的数据
  4. 包号98，服务端向客户端发送ACK，调整了自己的TCP窗口，声明Win=2161152。这里如果窗口大小为零，发送方将停止发送数据，并等待下一个窗口更新。也就是说，窗口大小是动态调整的。
  5. 客户端获知服务端的窗口变大了，因此自己可以连续发送多个数据帧
  6. 包号99~101，客户端连续向服务端发送了3个数据帧，无需等待服务端回复ACK，Seq按序增加，由于服务端没有回复ACK，这3帧数据的Ack都一样为1。
  7. 包号102，服务端向客户端发送了ACK，Ack=204801，刚好是包号101的Seq + len，这里实际上代表当前客户端已经收到了包号99~101的内容，这被称为TCP的累计确认。

窗口大小在TCP协议设计之初只留了2byte，这个可以在Wireshark中看到：

Untitled

后续为了提升Wireshark的长度，在TCP“三次握手”时的Options中有Window scale ：

Untitled

最终窗口大小计算公式 = Window的数值 8442 * 2的window scale次方

2.9. 动态调整TCP窗口——从慢启动到阻塞避免

在上一部分大包拆分中，可以看到TCP窗口是会动态调整的，这是有一个具体的调整策略的。

  1. 连接刚建立，发送方对网络情况一无所知，需要定一个初始值，可以是几个MSS大小。
  2. 连接初期，由于发生拥塞概率很低，如果发出去的包都得到确认，可以尝试增大阻塞窗口，RFC建议是每收到n个确认，阻塞窗口就增大n个MSS，这个过程需要慢慢增长，称为慢启动过程。
  3. 持续一段时间后，窗口大小达到一个较大的值，发生拥塞的概率变大，不能继续使用慢启动的算法，需要再缓慢一点，RFC建议每个往返时间增加1个MSS，这个过程称为拥塞避免。

Untitled

2.10. 丢包问题——RTO与快速重传

TCP连接过程中有可能出现丢包的情况。

对于发送方来说，如果发出去的包不像往常一样得到确认，有可能是网络延迟导致，发送方会等待一段时间再去判断，如果一直收不到，就会判定包已丢失，进行重传。这个过程称为超时重传，从发出原始包刀重传该包的时间段称为RTO：

Untitled

重传之后，TCP窗口也会被调整，会先降到1个MSS，之后会进入慢启动过程。不过这次从慢启动到拥塞的临界窗口值有了参考依据，RFC5681建议应该设置为拥塞时没被确认的数据量的1/2，不小于2个MSS：

Untitled

RTO的过程对性能影响是比较大的：

  1. RTO阶段等待重传不能传数据，浪费处理时间
  2. RTO之后的TCP窗口急剧减小，传输比之前慢

与RTO不同，如果拥塞很轻微，发生部分丢包，发送方还是能接收到部分Ack包，Ack会有期望Seq号，通过这个期望Seq号，发送方会意识到发生包丢失，当发送方收到3个及以上Dup Ack(重复确认)时会立刻重传，这个过程称为快速重传。

这里之所以需要凑齐3个及以上Dup Ack的原因是实际场景中包可能会乱序，Ack好像表现出一个缺失的包，但是这个包并没有丢失，而是由于乱序还在数据传输路上，可能很快就会传输过来，因此设置一个数量要求一定程度避免乱序导致快速重传：

Untitled

快速重传的过程对性能影响是比较小的，因为依然有部分包能够被发送和接收到，说明拥塞并不严重，因此只需传慢一点即可，无需突然大幅度TCP窗口重新慢启动。RFC5681建议重新设置临时窗口为拥塞时没被确认数据的1/2，不小于2个MSS，拥塞窗口设置为临界窗口+3个MSS

Untitled

2.11. 减轻网络负担可能降低性能——延迟确认与Nagle算法

  • 延迟确认：如果收到一个包后暂时没什么数据要发给对方，那就延迟一段时间再确认；假设这段时间内恰好有数据要发出，则确认信息和数据可以在一个包里发。延迟确认减少了部分确认包，减轻了网络负担，但有时候会影响性能，带来传输数据延迟。
  • Nagle算法：在发出去的数据还没有被确认之前，如果有小数据生成，就把小数据收集起来凑满一个MSS或者等收到确认后再发送。

3. 参考资料

  • 林沛满 -《Wireshark网络分析就这么简单》
  • 刘超 ——《趣谈网络协议》

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/442381.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

MyBatis常见面试题汇总

MyBatis常见面试题汇总

说一下MyBatis执行流程&#xff1f; MyBatis是一款优秀的基于Java的持久层框架&#xff0c;它内部封装了JDBC&#xff0c;使开发者只需要关注SQL语句本身&#xff0c;而不需要花费精力去处理加载驱动、创建连接等的过程&#xff0c;MyBatis的执行流程如下&#xff1a; 加载配…
阅读更多...
TCP/IP网络模型

TCP/IP网络模型

大家好我是苏麟 , 今天聊聊TCP/IP四层网络模型 . 资料来源 : 小林coding 小林官方网站 : 小林coding (xiaolincoding.com) 应用层 最上层的&#xff0c;也是我们能直接接触到的就是应用层&#xff08;Application Layer&#xff09;&#xff0c;我们电脑或手机使用的应用软件都…
阅读更多...
鸿蒙（HarmonyOS）项目方舟框架（ArkUI）之Gauge组件

鸿蒙（HarmonyOS）项目方舟框架（ArkUI）之Gauge组件

鸿蒙&#xff08;HarmonyOS&#xff09;项目方舟框架&#xff08;ArkUI&#xff09;之Gauge组件 一、操作环境 操作系统: Windows 10 专业版、IDE:DevEco Studio 3.1、SDK:HarmonyOS 3.1 二、Gauge组件 数据量规图表组件&#xff0c;用于将数据展示为环形图表。 子组件 无…
阅读更多...
如何用Docker+jenkins 运行 python 自动化？

如何用Docker+jenkins 运行 python 自动化？

1.在 Linux 服务器安装 docker 2.创建 jenkins 容器 3.根据自动化项目依赖包构建 python 镜像(构建自动化 python 环境) 4.运行新的 python 容器&#xff0c;执行 jenkins 从仓库中拉下来的自动化项目 5.执行完成之后删除容器 前言 环境准备 Linux 服务器一台(我的是 CentOS7)…
阅读更多...
harmony开发ohpm mac环境配置

harmony开发ohpm mac环境配置

Mac电脑 安装 Ohpm &#xff5c;HarmonyOS 安装 Ohpm ohpm环境配置好后&#xff0c;执行ohpm会报如下的错 ohpm has not been initialized yet. Execute the init script to initialize it first. 解决办法 鸿蒙OS开发&#xff0c;解决报错“ohpm has not been initialized yet…
阅读更多...
架构秘笈：移花接木。使用mysql模拟redis

架构秘笈：移花接木。使用mysql模拟redis

这年头&#xff0c;你看到的东西未必就是你认为的东西。一个 mysql 协议的后面&#xff0c;可能是tidb&#xff1b;一个 linux 机器后面&#xff0c;可能是一个精简的 docker &#xff1b;你觉得xjjdog是个女的&#xff0c;但可能ta自己也不太清楚&#xff1b;而当你大呼 php万…
阅读更多...
活动回顾 | 矩阵起源 CEO 王龙：与大数据结合，是大模型成熟的必经之路

活动回顾 | 矩阵起源 CEO 王龙：与大数据结合，是大模型成熟的必经之路

导读 近日&#xff0c;由数据猿和上海大数据联盟主办&#xff0c;上海市经济和信息化委员会、上海市科学技术委员会指导的“第六届金猿季&魔方论坛——大数据产业发展论坛”在上海市四行仓库举行&#xff0c;吸引了数百位业界精英的参与。 本次论坛以“小趋势大未来”为主…
阅读更多...
揭开空白网页背景色的神秘面纱

揭开空白网页背景色的神秘面纱

前言 一个看似简单实则有坑的问题&#xff1a;空白网页的背景色是什么&#xff1f; 大家是不是都会认为是白色&#xff0c;但事实并非如此&#xff0c;有时候我们眼睛看到的也不一定是真的&#x1f9d0; 页面根元素背景色 比如下面这段代码&#xff1a; <!-- ... --> <…
阅读更多...
DSP系统时钟总结

DSP系统时钟总结

一、stm32中断偏移向量介绍 1.1 为什么要设置中断向量偏移 上图可以看出程序上电先进入0x08000000开始运行&#xff0c;紧接着执行复位中断向量&#xff0c;然后执行复位中断程序&#xff0c;然后进入main函数。 如果想要app的中断正常运行&#xff0c;那就必须手动设置中断向…
阅读更多...
HBase表结构

HBase表结构

HBase是非关系型数据库&#xff0c;是高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库。 HBase使用场景 大规模数据存储&#xff1a;如日志记录、数据库备份等。实时数据访问&#xff1a;如实时搜索、实时分析等。高性能读写&#xff1a;如高并发、低延迟的读写操…
阅读更多...
如何使用Docker部署JSON Crack

如何使用Docker部署JSON Crack

文章目录 1. 在Linux上使用Docker安装JSONCrack2. 安装Cpolar内网穿透工具3. 配置JSON Crack界面公网地址4. 远程访问 JSONCrack 界面5. 固定 JSONCrack公网地址 JSON Crack 是一款免费的开源数据可视化应用程序&#xff0c;能够将 JSON、YAML、XML、CSV 等数据格式可视化为交互…
阅读更多...
电加热热水器上架亚马逊美国站需要的UL174报告

电加热热水器上架亚马逊美国站需要的UL174报告

电加热热水器上架亚马逊美国站需要的UL174报告 家用热水器出口美国需要办理UL174测试报告。 热水器就是指通过各种物理原理&#xff0c;在一定时间内使冷水温度升高变成热水的一种装置。分为制造冷气部分和制造热水部分。其实这两个部分又是紧密地联系在一起&#xff0c;密不可…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023