江苏龙网

  1. 主页 > 生活百科 > >

一文教会实战网络抓包和分析包( 三 )

抓包


文章插图
 
我们都知道 HTTP 是基于 tcp 协议进行传输的 ， 那么：
 

  • 最开始的 3 个包就是 TCP 三次握手建立连接的包
  • 中间是 HTTP 请求和响应的包
  • 而最后的 3 个包则是 TCP 断开连接的挥手包
 
Wireshark 可以用时序图的方式显示数据包交互的过程 ， 从菜单栏中 ， 点击 统计 (Statistics) -> 流量图 (Flow Graph) ， 然后 ， 在弹出的界面中的「流量类型」选择 「TCP Flows」 ， 你可以更清晰的看到 ， 整个过程中 TCP 流的执行过程：
一文教会实战网络抓包和分析包

文章插图
 
 
你可能会好奇 ， 为什么三次握手连接过程的 Seq 是 0 ？
 
实际上是因为 Wireshark 工具帮我们做了优化 ， 它默认显示的是序列号 seq 是相对值 ， 而不是真实值 。
如果你想看到实际的序列号的值 ， 可以右键菜单 ，  然后找到「协议首选项」 ， 接着找到「Relative Seq」后 ， 把它给取消 ， 操作如下：
一文教会实战网络抓包和分析包

文章插图
 
取消后 ， Seq 显示的就是真实值了：
一文教会实战网络抓包和分析包

文章插图
 
可见 ， 客户端和服务端的序列号实际上是不同的 ， 序列号是一个随机值 。
这其实跟我们书上看到的 TCP 三次握手和四次挥手很类似 ， 作为对比 ， 你通常看到的 TCP 三次握手和四次挥手的流程 ， 基本是这样的：
一文教会实战网络抓包和分析包

文章插图
 
 
为什么抓到的 TCP 挥手是三次 ， 而不是书上说的四次？
 
当被动关闭方（上图的服务端）在 TCP 挥手过程中 ， 「没有数据要发送」并且「开启了 TCP 延迟确认机制」 ， 那么第二和第三次挥手就会合并传输 ， 这样就出现了三次挥手 。
而通常情况下 ， 服务器端收到客户端的 FIN 后 ， 很可能还没发送完数据 ， 所以就会先回复客户端一个 ACK 包 ， 稍等一会儿 ， 完成所有数据包的发送后 ， 才会发送 FIN 包 ， 这也就是四次挥手了 。
#TCP 三次握手异常情况实战分析
TCP 三次握手的过程相信大家都背的滚瓜烂熟 ， 那么你有没有想过这三个异常情况：
 
  • TCP 第一次握手的 SYN 丢包了 ， 会发生了什么？
  • TCP 第二次握手的 SYN、ACK 丢包了 ， 会发生什么？
  • TCP 第三次握手的 ACK 包丢了 ， 会发生什么？
 
有的小伙伴可能说：“很简单呀 ， 包丢了就会重传嘛 。”
那我在继续问你：
 
  • 那会重传几次？
  • 超时重传的时间 RTO 会如何变化？
  • 在 Linux 下如何设置重传次数？
  •  
 
是不是哑口无言 ， 无法回答？
不知道没关系 ， 接下里我用三个实验案例 ， 带大家一起探究探究这三种异常 。
#实验场景
本次实验用了两台虚拟机 ， 一台作为服务端 ， 一台作为客户端 ， 它们的关系如下：
一文教会实战网络抓包和分析包

文章插图
 
 

上一篇：服务器远程端口怎么修改

下一篇：如何在Windows Server上配置静态ip？