计算机网络抓包工具_电脑如何抓包「建议收藏」

计算机网络抓包工具_电脑如何抓包「建议收藏」有很多小伙伴对于网络中的抓包没有很多的实战。同时对网络抓包工具也是不熟悉,本博文将介绍计算机网络中用于抓包的两个常用工具tcpdump和Wireshark,通过使用tcpdump/Wireshark工具来对TCP的三次握手和四次挥手进行抓包实战,给大家学习和使用tcpdump/Wireshark工具作一个参考。…………_网络抓包

摘要

对于日常工作的开发工作中,大部分同学都没有涉及到网络的抓包工作,同时对于大部分开发的同学来说对于网络抓包工具也是不熟悉。那本文将介绍计算机网络中用于抓包的两个常用工具tcpdump和Wireshark,通过使用tcpdump/Wireshark工具来对TCP的三次握手和四次挥手进行抓包实战,来帮助大家更好的理解计算机网络中的连接与断开的原理,同时也是帮助大家学会使用网络抓包工具来解决项目中的网络问题。

计算机网络知识脑图

计算机网络——计算机网络知识脑图_庄小焱的博客-CSDN博客_计算机网络面试题总结

计算机网络大厂面试问题集合

计算机网络——大厂面试问题集合_庄小焱的博客-CSDN博客

计算机网络基础知识

计算机网络——网络基础知识_庄小焱的博客-CSDN博客_数据转发服务器

IP相关基础原理

计算机网络——IP协议基础原理_庄小焱的博客-CSDN博客_ip网络技术

HTTP协议原理

计算机网络——HTTP协议原理_庄小焱的博客-CSDN博客_http协议原理

HTTP的优化方式

计算机网络——HTTP的优化方式_庄小焱的博客-CSDN博客

HTTPS协议原理

计算机网络——HTTPS协议原理_庄小焱的博客-CSDN博客_https协议原理

HTTPS的优化方式

计算机网络——HTTPS的优化方式_庄小焱的博客-CSDN博客

TCP可靠性传输原理

计算机网络——TCP可靠性传输原理_庄小焱的博客-CSDN博客_tcp的可靠性是如何实现的

TCP/IP三次握手四次挥手原理

计算机网络——HTTP的三次握手与四次挥手原理_庄小焱的博客-CSDN博客_三次握手和四次挥手原理

TCP的优化方式

计算机网络——TCP的优化方式_庄小焱的博客-CSDN博客_tcp协议优化技术

DNS协议(域名解析)原理

计算机网络——DNS协议(域名解析)原理_庄小焱的博客-CSDN博客_计算机网络dns

ARP协议(地址解析)原理

计算机网络——ARP协议(地址解析)原理_庄小焱的博客-CSDN博客_地址解析协议的工作原理

ARQ协议(自动重传请求)原理

计算机网络——ARQ协议(自动重传请求)原理_庄小焱的博客-CSDN博客_连续arq协议的原理

DHCP协议原理

计算机网络——DHCP(动态获取IP)原理_庄小焱的博客-CSDN博客_计算机网络dhcp

NAT协议原理

计算机网络——NAT协议(网络地址转换)原理_庄小焱的博客-CSDN博客

ICMP/IGMP协议原理

计算机网络——ICMP/IGMP协议原理_庄小焱的博客-CSDN博客_计算机网络igmp

HTTP网络访问全流程

计算机网络——HTTP网络访问全流程_庄小焱的博客-CSDN博客_网络访问流程

虚拟网路模型原理

计算机网络——虚拟网路模型原理_庄小焱的博客-CSDN博客

其他网络知识

计算机网络——select/poll/epoll底层原理_庄小焱的博客-CSDN博客

计算机网络——cookie/session/token原理_庄小焱的博客-CSDN博客

计算机网络——网络通信加密原理_庄小焱的博客-CSDN博客_网络通信加密

计算机网络——GRPC通信原理_庄小焱的博客-CSDN博客_grpc原理

计算机网络——tcpdump/Wireshark抓包实战_庄小焱的博客-CSDN博客_网络抓包

计算机网络——TCP抓包连接实战_庄小焱的博客-CSDN博客_tcp全连接和半连接

一、网络实战工具

这两者实际上是搭配使用的,先用Tcpdump命令在 Linux 服务器上抓包,接着把抓包的文件拖出到 Windows电脑后,用Wireshark可视化分析。如果你是在Windows上抓包,只需要用Wireshark工具就可以。

  • linux : tcpdump
  • window : Wireshark

二、Tcpdump实战

2.1 tcpdump使用说明

Tcpdump使用说明
选项 示例 说明
-i tcpdump -i eth0  指定网络接口 默认是0 号接口,any 表示所有接口
-nn tcpdump -nn  不解析IP地址和端口名称
-c tcpdump -c 5 限制要抓取的网络包的个数
-w tcpdump -w file.pcap 将信息保存到文件呢中文件以。pcap为后缀
host src host dst host tcpdump -nn host 192.168.1.100 主机过滤
port src port dst port tcpdump –nn port 80 端口过滤
ip ip6 arp tcp udp

tcpdump -nn tcp

协议过滤
and or not tcpdump -nn host 192.168.1.100 and port 80 逻辑表达式过滤
tcp[tcoflages] tcpdump -nn “tcp[tcpflags] & tcp-syn! =0” 特定状态的TCP包

2.2 Linux下Tcpdump实战

tcpdump提供了大量的选项以及各式各样的过滤表达式,来帮助你抓取指定的数据包,不过不要担心,只需要掌握一些常用选项和过滤表达式,就可以满足大部分场景的需要了。假设我们要抓取下面的 ping 的数据包:

计算机网络抓包工具_电脑如何抓包「建议收藏」

# -I ens192 表示从ens192 网卡出发 
# -c 3      表示发出3个icmp数据

(base) mystic@k8s-master:~$ ping -I ens192 -c 3 20.12.151.195
PING 20.12.151.195 (20.12.151.195) from 20.1.206.131 ens192: 56(84) bytes of data.
64 bytes from 20.12.151.195: icmp_seq=1 ttl=62 time=1.11 ms
64 bytes from 20.12.151.195: icmp_seq=2 ttl=62 time=0.421 ms
64 bytes from 20.12.151.195: icmp_seq=3 ttl=62 time=0.347 ms

--- 20.12.151.195 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2021ms
rtt min/avg/max/mdev = 0.347/0.626/1.111/0.344 ms

要抓取上面的 ping 命令数据包,首先我们要知道 ping 的数据包是 icmp 协议,接着在使用 tcpdump抓包的时候,就可以指定只抓 icmp 协议的数据包:

tcpdump -i ens192 icmp and host 20.12.151.195 -nn

# -i ens192 
# icmp
# host
# -nn 
------------------------------------------------------------------
返回的结果:

时间戳协议源地址.源端口 > 目的地址.目的端口网络包详细信息

计算机网络抓包工具_电脑如何抓包「建议收藏」

计算机网络抓包工具_电脑如何抓包「建议收藏」

从tcpdump 抓取的 icmp 数据包,我们很清楚的看到 icmp echo的交互过程了,首先发送方发起了ICMP echo request 请求报文,接收方收到后回了一个ICMP echo reply 响应报文,之后 seq是递增的。

三、Wireshark实战

tcpdump -i ens192 icmp and host 20.12.151.195 -w ping.pcap

接着把 ping.pcap 文件拖到电脑,再用 Wireshark 打开它。打开后,你就可以看到下面这个界面:

计算机网络抓包工具_电脑如何抓包「建议收藏」

在Wireshark 的页面里,可以更加直观的分析数据包,不仅展示各个网络包的头部信息,还会用不同的颜色来区分不同的协议,由于这次抓包只有ICMP 协议,所以只有紫色的条目。接着,在网络包列表中选择某一个网络包后,在其下面的网络包详情中,可以更清楚的看到,这个网络包在协议栈各层的详细信息。

计算机网络抓包工具_电脑如何抓包「建议收藏」

从ping 的例子中,我们可以看到网络分层就像有序的分工,每一层都有自己的责任范围和信息,上层协议完成工作后就交给下一层,最终形成一个完整的网络包。

计算机网络抓包工具_电脑如何抓包「建议收藏」

3.1 TCP三次握手抓包实战

计算机网络抓包工具_电脑如何抓包「建议收藏」

本次例子,我们将要访问的 http://192.168.3.200 服务端。在终端一用 tcpdump 命令抓取数据包:

tcpdump -i ens192 icmp and host 20.12.151.195 and port 80 -w test.pcap
curl http://192.168.3.200

 使用 Wireshark 打开 http.pcap 后,你就可以在 Wireshark 中,看到如下的界面:

计算机网络抓包工具_电脑如何抓包「建议收藏」

Wireshark 可以用时序图的方式显示数据包交互的过程,从菜单栏中,点击 统计 (Statistics) -> 流量图(Flow Graph),然后,在弹出的界面中的「流量类型」选择 「TCP Flows」,你可以更清晰的看到,整个过程中 TCP 流的执行过程:

计算机网络抓包工具_电脑如何抓包「建议收藏」

为什么三次握手连接过程的 Seq 是0?实际上是Wireshark工具帮我们做了优化,它默认显示的是序列号 seq 是相对值,而不是真实值。如果你想看到实际的序列号的值,可以右键菜单, 然后找到协议首选项,接着找到RelativeSeq后,把它给取消,操作如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

计算机网络抓包工具_电脑如何抓包「建议收藏」

3.2 TCP四次挥手抓包实战

计算机网络抓包工具_电脑如何抓包「建议收藏」

为什么抓到的TCP挥手是三次,而不是书上说的四次?因为服务器端收到客户端的 FIN 后,服务器端同时也要关闭连接,这样就可以把 ACK 和 FIN 合并到一起发送,节省了一个包,变成了“三次挥手”。而通常情况下,服务器端收到客户端的 FIN 后,很可能还没发送完数据,所以就会先回复客户端一个ACK 包,稍等一会儿,完成所有数据包的发送后,才会发送 FIN 包,这也就是四次挥手了。如下图,就是四次挥手的过程:

计算机网络抓包工具_电脑如何抓包「建议收藏」

3.3 TCP 三次握手异常情况实战分析

本次实验用了两台虚拟机,一台作为服务端,一台作为客户端,它们的关系如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

3.3.1 TCP 第一次握手 SYN 丢包

为了模拟 TCP 第一次握手 SYN 丢包的情况,我是在拔掉服务器的网线后,立刻在客户端执行 curl 命令:

# 客户端发起请求 

$ date ; curl http://192.168.25.16; date

# 请求阻塞中…………

其间 tcpdump 抓包的命令如下:

# 客户端执行tcpdump 抓取到服务端的HTTP的数据包

$ tcpdump -i ens192 tcp and host 192.168.12.36 and port -w tcp_sys_timeout.pcap

 过了一会, curl 返回了超时连接的错误:

# 客户端发起请求 

$ date ; curl http://192.168.25.16; date

# 请求阻塞中…………
 
# 显示 connect timeout

 从date 返回的时间,可以发现在超时接近 1 分钟的时间后,curl 返回了错误。接着,把 tcp_sys_timeout.pcap 文件用 Wireshark 打开分析,显示如下图:

计算机网络抓包工具_电脑如何抓包「建议收藏」

从上图可以发现, 客户端发起了 SYN 包后,一直没有收到服务端的 ACK ,所以一直超时重传了次,并且每次 RTO 超时时间是不同的:

  • 第一次是在 1 秒超时重传
  • 第二次是在 3 秒超时重传
  • 第三次是在 7 秒超时重传
  • 第四次是在 15 秒超时重传
  • 第五次是在 31 秒超时重传

可以发现,每次超时时间 RTO 是指数(翻倍)上涨的,当超过最大重传次数后,客户端不再发送 SYN包。在 Linux 中,第一次握手的 SYN 超时重传次数,是如下内核参数指定的:

$ cat /proc/sys/net/ipv4/tcp_syn_retries
5

tcp_syn_retries 默认值为 5,也就是 SYN 最大重传次数是 5 次。

接下来,我们继续做实验,把 tcp_syn_retries 设置为 2 次:

$ echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

重传抓包后,用 Wireshark 打开分析,显示如下图:

计算机网络抓包工具_电脑如何抓包「建议收藏」

实验一总结:通过实验一的实验结果,我们可以得知,当客户端发起的 TCP 第一次握手 SYN 包,在超时时间内没收到服务端的 ACK,就会在超时重传 SYN 数据包,每次超时重传的 RTO 是翻倍上涨的,直到 SYN 包的重传次数到达 tcp_syn_retries 值后,客户端不再发送 SYN 包。

计算机网络抓包工具_电脑如何抓包「建议收藏」

3.3.2 TCP 第二次握手 SYN、ACK 丢包

为了模拟客户端收不到服务端第二次握手 SYN、ACK 包,我的做法是在客户端加上防火墙限制,直接粗暴的把来自服务端的数据都丢弃,防火墙的配置如下:

# 客户端配置防火墙
iptable -I input -s 192.168.25.16 -j DROP

 接着,在客户端执行 curl 命令:

# 客户端发起请求 $ date ; curl http://192.168.25.16; date# 请求阻塞中………… # 显示 connect timeout

 从 date 返回的时间前后,可以算出大概 1 分钟后,curl 报错退出了。客户端在这其间抓取的数据包,用 Wireshark 打开分析,显示的时序图如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

从图中可以发现:

  • 客户端发起 SYN 后,由于防火墙屏蔽了服务端的所有数据包,所以 curl 是无法收到服务端的SYN、ACK 包,当发生超时后,就会重传 SYN 包。
  • 服务端收到客户的 SYN 包后,就会回 SYN、ACK 包,但是客户端一直没有回 ACK,服务端在超时后,重传了 SYN、ACK 包,接着一会,客户端超时重传的 SYN 包又抵达了服务端,服务端收到后,超时定时器就重新计时,然后回了 SYN、ACK 包,所以相当于服务端的超时定时器只触发了一次,又被重置了。
  • 最后,客户端 SYN 超时重传次数达到了 5 次(tcp_syn_retries 默认值 5 次),就不再继续发送SYN 包了。

所以,我们可以发现,当第二次握手的 SYN、ACK 丢包时,客户端会超时重发 SYN 包,服务端也会超时重传 SYN、ACK 包。客户端设置了防火墙,屏蔽了服务端的网络包,为什么 tcpdump 还能抓到服务端的网络包?添加 iptables 限制后, tcpdump 是否能抓到包 ,这要看添加的 iptables 限制条件:

  • 如果添加的是 INPUT 规则,则可以抓得到包
  • 如果添加的是 OUTPUT 规则,则抓不到包

网络包进入主机后的顺序如下:

  • 进来的顺序 Wire -> NIC -> tcpdump -> netfilter/iptables
  • 出去的顺序 iptables -> tcpdump -> NIC -> Wire

tcp_syn_retries 是限制 SYN 重传次数,那第二次握手 SYN、ACK 限制最大重传次数是多少?TCP 第二次握手 SYN、ACK 包的最大重传次数是通过 tcp_synack_retries 内核参数限制的,其默认值如下:

$ cat /proc/sys/net/ipv4/tcp_synack_retries
5

是的,TCP 第二次握手 SYN、ACK 包的最大重传次数默认值是 5 次。
为了验证 SYN、ACK 包最大重传次数是 5 次,我们继续做下实验,我们先把客户端的 tcp_syn_retries
设置为 1,表示客户端 SYN 最大超时次数是 1 次,目的是为了防止多次重传 SYN,把服务端 SYN、
ACK 超时定时器重置。

接着,还是如上面的步骤:

  • 1. 客户端配置防火墙屏蔽服务端的数据包
  • 2. 客户端 tcpdump 抓取 curl 执行时的数据包

把抓取的数据包,用 Wireshark 打开分析,显示的时序图如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

从上图,我们可以分析出:

  • 客户端的 SYN 只超时重传了 1 次,因为 tcp_syn_retries 值为 1
  • 服务端应答了客户端超时重传的 SYN 包后,由于一直收不到客户端的 ACK 包,所以服务端一直在超时重传 SYN、ACK 包,每次的 RTO 也是指数上涨的,一共超时重传了 5 次,因为tcp_synack_retries 值为 5

接着,我把 tcp_synack_retries 设置为 2, tcp_syn_retries 依然设置为 1:

$ echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
$ echo 1 > /proc/sys/net/ipv4/tcp_syn_retries

依然保持一样的实验步骤进行操作,接着把抓取的数据包,用 Wireshark 打开分析,显示的时序图如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

由上图可见:

  • 客户端的 SYN 包只超时重传了 1 次,符合 tcp_syn_retries 设置的值;
  • 服务端的 SYN、ACK 超时重传了 2 次,符合 tcp_synack_retries 设置的值

实验二总结: 通过实验二的实验结果,我们可以得知,当 TCP 第二次握手 SYN、ACK 包丢了后,客户端 SYN 包会发生超时重传,服务端 SYN、ACK 也会发生超时重传。客户端 SYN 包超时重传的最大次数,是由 tcp_syn_retries 决定的,默认值是 5 次;服务端 SYN、ACK 包时重传的最大次数,是由 tcp_synack_retries 决定的,默认值是 5 次。

3.3.3 TCP 第三次握手 ACK 丢包

为了模拟 TCP 第三次握手 ACK 包丢,我的实验方法是在服务端配置防火墙,屏蔽客户端 TCP 报文中标志位是 ACK 的包,也就是当服务端收到客户端的 TCP ACK 的报文时就会丢弃,iptables 配置命令如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

 接着,在客户端执行如下 tcpdump 命令:

计算机网络抓包工具_电脑如何抓包「建议收藏」

 然后,客户端向服务端发起 telnet,因为 telnet 命令是会发起 TCP 连接,所以用此命令做测试:

计算机网络抓包工具_电脑如何抓包「建议收藏」

此时,由于服务端收不到第三次握手的 ACK 包,所以一直处于 SYN_RECV 状态:

计算机网络抓包工具_电脑如何抓包「建议收藏」

而客户端是已完成 TCP 连接建立,处于 ESTABLISHED 状态:

计算机网络抓包工具_电脑如何抓包「建议收藏」

过了 1 分钟后,观察发现服务端的 TCP 连接不见了:

计算机网络抓包工具_电脑如何抓包「建议收藏」

 过了 30 分别,客户端依然还是处于 ESTABLISHED 状态:

计算机网络抓包工具_电脑如何抓包「建议收藏」

接着,在刚才客户端建立的 telnet 会话,输入 123456 字符,进行发送:

计算机网络抓包工具_电脑如何抓包「建议收藏」

 持续「好长」一段时间,客户端的 telnet 才断开连接:

计算机网络抓包工具_电脑如何抓包「建议收藏」

以上就是本次的实现三的现象,这里存在两个疑点:

  • 为什么服务端原本处于 SYN_RECV 状态的连接,过 1 分钟后就消失了?

原因:服务端在重传 SYN、ACK 包时,超过了最大重传次数 tcp_synack_retries ,于是服务端的 TCP连接主动断开了。

  • 为什么客户端 telnet 输入 123456 字符后,过了好长一段时间,telnet 才断开连接?

原因:客户端向服务端发送数据包时,由于服务端的 TCP 连接已经退出了,所以数据包一直在超时重传,共重传了 15 次, telnet 就断开了连接。

计算机网络抓包工具_电脑如何抓包「建议收藏」

上图的流程:

  • 客户端发送 SYN 包给服务端,服务端收到后,回了个 SYN、ACK 包给客户端,此时服务端的TCP 连接处于 SYN_RECV 状态;
  • 客户端收到服务端的 SYN、ACK 包后,给服务端回了个 ACK 包,此时客户端的 TCP 连接处于ESTABLISHED 状态;
  • 由于服务端配置了防火墙,屏蔽了客户端的 ACK 包,所以服务端一直处于 SYN_RECV 状态,没有进入 ESTABLISHED 状态,tcpdump 之所以能抓到客户端的 ACK 包,是因为数据包进入系统的顺序是先进入 tcpudmp,后经过 iptables;
  • 接着,服务端超时重传了 SYN、ACK 包,重传了 5 次后,也就是超过 tcp_synack_retries 的值(默认值是 5),然后就没有继续重传了,此时服务端的 TCP 连接主动中止了,所以刚才处于SYN_RECV 状态的 TCP 连接断开了,而客户端依然处于ESTABLISHED 状态;
  • 虽然服务端 TCP 断开了,但过了一段时间,发现客户端依然处于ESTABLISHED 状态,于是就在客户端的 telnet 会话输入了 123456 字符;
  • 此时由于服务端已经断开连接,客户端发送的数据报文,一直在超时重传,每一次重传,RTO 的值是指数增长的,所以持续了好长一段时间,客户端的 telnet 才报错退出了,此时共重传了 15次。

四、TCP快速建立连接

客户端在向服务端发起 HTTP GET 请求时,一个完整的交互过程,需要 2.5 个 RTT 的时延。由于第三次握手是可以携带数据的,这时如果在第三次握手发起 HTTP GET 请求,需要2个RTT的时延。但是在下一次(不是同个 TCP 连接的下一次)发起 HTTP GET 请求时,经历的 RTT 也是一样,如下图:

计算机网络抓包工具_电脑如何抓包「建议收藏」

在 Linux 3.7 内核版本中,提供了 TCP Fast Open 功能,这个功能可以减少 TCP 连接建立的时延。

计算机网络抓包工具_电脑如何抓包「建议收藏」

  • 在第一次建立连接的时候,服务端在第二次握手产生一个 Cookie (已加密)并通过 SYN、ACK包一起发给客户端,于是客户端就会缓存这个 Cookie ,所以第一次发起 HTTP Get 请求的时候,还是需要 2 个 RTT 的时延;
  • 在下次请求的时候,客户端在 SYN 包带上 Cookie 发给服务端,就提前可以跳过三次握手的过程,因为 Cookie 中维护了一些信息,服务端可以从 Cookie 获取 TCP 相关的信息,这时发起的 HTTP GET 请求就只需要 1 个 RTT 的时延; 

注:客户端在请求并存储了Fast Open Cookie 之后,可以不断重复 TCP Fast Open 直至服务器认为Cookie 无效(通常为过期)。

在 Linux 上如何打开 Fast Open 功能?

可以通过设置 net.ipv4.tcp_fastopn 内核参数,来打开 Fast Open 功能。net.ipv4.tcp_fastopn 各个值的意义:

  • 0 关闭
  • 1 作为客户端使用 Fast Open 功能
  • 2 作为服务端使用 Fast Open 功能
  • 3 无论作为客户端还是服务器,都可以使用 Fast Open 功能

4.1 TCP Fast Open 抓包分析

在下图,数据包 7 号,客户端发起了第二次 TCP 连接时,SYN 包会携带 Cooike,并且长度为 5 的数据。服务端收到后,校验 Cooike 合法,于是就回了 SYN、ACK 包,并且确认应答收到了客户端的数据包,ACK = 5 + 1 = 6。

计算机网络抓包工具_电脑如何抓包「建议收藏」

4.2 TCP 重复确认和快速重传

当接收方收到乱序数据包时,会发送重复的 ACK,以便告知发送方要重发该数据包,当发送方收到 3个重复 ACK 时,就会触发快速重传,立刻重发丢失数据包。

计算机网络抓包工具_电脑如何抓包「建议收藏」

TCP 重复确认和快速重传的一个案例,用 Wireshark 分析,显示如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

  • 数据包 1 期望的下一个数据包 Seq 是 1,但是数据包 2 发送的 Seq 却是 10945,说明收到的是乱序数据包,于是回了数据包 3 ,还是同样的 Seq = 1,Ack = 1,这表明是重复的 ACK;
  • 数据包 4 和 6 依然是乱序的数据包,于是依然回了重复的 ACK;
  • 当对方收到三次重复的 ACK 后,于是就快速重传了 Seq = 1 、Len = 1368 的数据包 8;
  • 当收到重传的数据包后,发现 Seq = 1 是期望的数据包,于是就发送了个确认收到快速重传的ACK。

注意:快速重传和重复 ACK 标记信息是 Wireshark 的功能,非数据包本身的信息。

以上案例在 TCP 三次握手时协商开启了选择性确认 SACK,因此一旦数据包丢失并收到重复 ACK ,即使在丢失数据包之后还成功接收了其他数据包,也只需要重传丢失的数据包。如果不启用 SACK,就必须重传丢失包之后的每个数据包。如果要支持 SACK ,必须双方都要支持。在 Linux 下,可以通过 net.ipv4.tcp_sack 参数打开这个功能(Linux 2.4 后默认打开)。

4.3 TCP 流量控制

TCP 为了防止发送方无脑的发送数据,导致接收方缓冲区被填满,所以就有了滑动窗口的机制,它可利用接收方的接收窗口来控制发送方要发送的数据量,也就是流量控制。

接收窗口是由接收方指定的值,存储在 TCP 头部中,它可以告诉发送方自己的 TCP 缓冲空间区大小,这个缓冲区是给应用程序读取数据的空间:

  • 如果应用程序读取了缓冲区的数据,那么缓冲空间区就会把被读取的数据移除
  • 如果应用程序没有读取数据,则数据会一直滞留在缓冲区。

接收窗口的大小,是在 TCP 三次握手中协商好的,后续数据传输时,接收方发送确认应答 ACK 报文时,会携带当前的接收窗口的大小,以此来告知发送方。

假设接收方接收到数据后,应用层能很快的从缓冲区里读取数据,那么窗口大小会一直保持不变,过程如下:

计算机网络抓包工具_电脑如何抓包「建议收藏」

但是现实中服务器会出现繁忙的情况,当应用程序读取速度慢,那么缓存空间会慢慢被占满,于是为了保证发送方发送的数据不会超过缓冲区大小,服务器则会调整窗口大小的值,接着通过 ACK 报文通知给对方,告知现在的接收窗口大小,从而控制发送方发送的数据大小。

计算机网络抓包工具_电脑如何抓包「建议收藏」

4.4 零窗口通知与窗口探测

假设接收方处理数据的速度跟不上接收数据的速度,缓存就会被占满,从而导致接收窗口为 0,当发送方接收到零窗口通知时,就会停止发送数据。如下图,可以看到接收方的窗口大小在不断的收缩至 0:接着,发送方会定时发送窗口大小探测报文,以便及时知道接收方窗口大小的变化。

计算机网络抓包工具_电脑如何抓包「建议收藏」

以下图 Wireshark 分析图作为例子说明:

计算机网络抓包工具_电脑如何抓包「建议收藏」

  • 发送方发送了数据包 1 给接收方,接收方收到后,由于缓冲区被占满,回了个零窗口通知;
  • 发送方收到零窗口通知后,就不再发送数据了,直到过了 3.4 秒后,发送了一个 TCP Keep-Alive 报文,也就是窗口大小探测报文;
  • 当接收方收到窗口探测报文后,就立马回一个窗口通知,但是窗口大小还是 0;
  • 发送方发现窗口还是 0,于是继续等待了 6.8 (翻倍) 秒后,又发送了窗口探测报文,接收方依然还是回了窗口为 0 的通知;
  • 发送方发现窗口还是 0,于是继续等待了 13.5 (翻倍) 秒后,又发送了窗口探测报文,接收方依然还是回了窗口为 0 的通知; 

可以发现,这些窗口探测报文以 3.4s、6.5s、13.5s 的间隔出现,说明超时时间会翻倍递增。

4.5 TCP 延迟确认与 Nagle 算法

当我们 TCP 报文的承载的数据非常小的时候,例如几个字节,那么整个网络的效率是很低的,因为每个 TCP 报文中都会有 20 个字节的 TCP 头部,也会有 20 个字节的 IP 头部,而数据只有几个字节,所以在整个报文中有效数据占有的比重就会非常低。

这就好像快递员开着大货车送一个小包裹一样浪费。那么就出现了常见的两种策略,来减少小报文的传输,分别是:

  • Nagle 算法
  • 延迟确认

4.6 Nagle 算法是如何避免大量 TCP 小数据报文的传输?

Nagle 算法做了一些策略来避免过多的小数据报文发送,这可提高传输效率。Nagle 算法的策略:

  • 没有已发送未确认报文时,立刻发送数据。
  • 存在未确认报文时,直到「没有已发送未确认报文」或「数据长度达到 MSS 大小」时,再发送数据。

只要没满足上面条件中的一条,发送方一直在囤积数据,直到满足上面的发送条件。

计算机网络抓包工具_电脑如何抓包「建议收藏」

  • 一开始由于没有已发送未确认的报文,所以就立刻发了 H 字符;
  • 接着,在还没收到对 H 字符的确认报文时,发送方就一直在囤积数据,直到收到了确认报文后,
  • 此时没有已发送未确认的报文,于是就把囤积后的 ELL 字符一起发给了接收方;
  • 待收到对 ELL 字符的确认报文后,于是把最后一个 O 字符发送了出去

可以看出,Nagle 算法一定会有一个小报文,也就是在最开始的时候。另外,Nagle 算法默认是打开的,如果对于一些需要小数据包交互的场景的程序,比如,telnet 或 ssh这样的交互性比较强的程序,则需要关闭 Nagle 算法。可以在 Socket 设置 TCP_NODELAY 选项来关闭这个算法(关闭 Nagle 算法没有全局参数,需要根据每个应用自己的特点来关闭)。

计算机网络抓包工具_电脑如何抓包「建议收藏」

4.7 那延迟确认又是什么?

事实上当没有携带数据的 ACK,它的网络效率也是很低的,因为它也有 40 个字节的 IP 头 和 TCP
头,但却没有携带数据报文。为了解决 ACK 传输效率低问题,所以就衍生出了 TCP 延迟确认。

TCP 延迟确认的策略:

  • 当有响应数据要发送时,ACK 会随着响应数据一起立刻发送给对方
  • 当没有响应数据要发送时,ACK 将会延迟一段时间,以等待是否有响应数据可以一起发送
  • 如果在延迟等待发送 ACK 期间,对方的第二个数据报文又到达了,这时就会立刻发送 ACK

计算机网络抓包工具_电脑如何抓包「建议收藏」

延迟等待的时间是在 Linux 内核中定义:关键就需要 HZ 这个数值大小,HZ 是跟系统的时钟频率有关,每个操作系统都不一样。

计算机网络抓包工具_电脑如何抓包「建议收藏」

延迟确认 和 Nagle 算法混合使用时,会产生新的问题?

当 TCP 延迟确认 和 Nagle 算法混合使用时,会导致时耗增长,如下图:

计算机网络抓包工具_电脑如何抓包「建议收藏」

发送方使用了 Nagle 算法,接收方使用了 TCP 延迟确认会发生如下的过程:

  • 发送方先发出一个小报文,接收方收到后,由于延迟确认机制,自己又没有要发送的数据,只能干等着发送方的下一个报文到达;
  • 而发送方由于 Nagle 算法机制,在未收到第一个报文的确认前,是不会发送后续的数据;
  • 所以接收方只能等待最大时间 200 ms 后,才回 ACK 报文,发送方收到第一个报文的确认报文后,也才可以发送后续的数据。

很明显,这两个同时使用会造成额外的时延,这就会使得网络”很慢”的感觉。要解决这个问题,只有两个办法:

  • 要不发送方关闭 Nagle 算法
  • 要不接收方关闭 TCP 延迟确认

博文参考

1.5 万字 + 40 张图解 HTTP 常见面试题(值得收藏)_小林coding的博客-CSDN博客

今天的文章计算机网络抓包工具_电脑如何抓包「建议收藏」分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/58189.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注