一次HTTP请求流量分析详解(很详细一看就懂)

为什么要研究一个请求需要多少流量?

某天,办公室WIFI挂了,然后就开启热点用了一天,手机流量直接耗光50多个G。

后来排查发现有个任务每分钟成百上千个请求,所以才开始想到研究一下每个请求到底消耗了多少流量。以便在今后的工作中,某些场景下需要节约流量时如何处理。

目录

一、本地环境

二、抓包分析

2.1 TCP三次握手

2.2 正常业务数据传输

2.3 TCP四次挥手

2.4 异常情况

三、流量统计分析总结

3.1 痛点

四、扩展


一、本地环境

操作系统: MacOs Sonoma 14.0

网络分析工具:Wireshark

Wireshark下载地址:

  • windows下载地址:Wireshark
  • Mac下载地址:Wireshark · Go Deep
  • 本地环境安装包4.0.8下载资源地址:https://download.csdn.net/download/imwucx/88399757
  • 安装:一直点下一步即可。

二、抓包分析

随机发一个请求,以度娘为例,先获取度娘ip:

一次HTTP请求流量分析详解(很详细一看就懂)_第1张图片

发一次请求命令 curl www.baidu.com:

一次HTTP请求流量分析详解(很详细一看就懂)_第2张图片

Wireshark抓包如下:

  • 上部分窗口:为数据包概要信息窗口
  • 左下角窗口:为数据包解析窗口
    • Frame:表示该帧数据的整体信息
    • Ethernet:数据链路层
    • Internet:网络层
    • Transmission Control Protocol:传输控制协议
    • Hypertext transfer protocol:超文本传输协议
  • 右下角窗口:为数据包数据窗口

如上图所示分析,分为三个阶段:

  • No 4526, No 4527, No 4528 是TCP三次握手
  • No 4529 ~ No 4533 数据传输
  • No 4534, No 4537, No 4538, No 4539 是TCP四次挥手

TCP三次握手和四次挥手图解详见:TCP三次握手和四次挥手(彻底弄明白)_小贤java的博客-CSDN博客TCP,全称 Transmission Control Protocal。从名字可以知道这是一个用于 控制传输 的位于传输层的协议。TCP 位于 TCP/IP 和 OSI 模型的传输层。我们最常使用的 HTTP 协议,底层通常使用的就是 TCP 协议。如果要在客户端和服务端创建 TCP 连接,我们需要在开始的时候发送三个请求确认双方的通信能力正常,这三次连接就被称为 TCP 的三次握手。建立 TCP 连接一段时间后,如果要断开 TCP 连接,就会进行 TCP 四次挥手过程完成断开操作。https://cxian.blog.csdn.net/article/details/133679493

2.1 TCP三次握手

首先是三次握手,毕竟 HTTP 也是基于TCP的,所以需要先建立TCP连接:

  • 客户端:发送两次请求(No 4526和 No 4528)总共 78字节 + 54字节 = 132字节,
  • 服务端:一次请求(No 4527)共 78 字节。

2.2 正常业务数据传输

然后是数据传输:

  • 客户端:发起两次消耗流量分别是 130字节 + 54字节 = 184字节
  • 服务端:发起三次消耗流量分别是 54字节 + 1494字节 + 1395字节 = 2943字节

2.3 TCP四次挥手

最后是结束阶段四次挥手:

  • 客户端:发起两次消耗流量分别是 54字节 + 66字节 = 120字节
  • 服务器:发起两次消耗流量分别是 54字节 + 54字节 = 108字节

2.4 异常情况

异常流量:

一次TCP Spurious Retransmission(No4535)、一次TCP retransmission(No4536)和一次TCP Dup ACK(No4540):总共消耗流量 1395字节(服务端) + 66字节(客户端) + 66字节(服务端) = 1527字节

  • TCP Spurious Retransmission(No 4525):意味着发送端认为发送的包已经丢失了,然后就重传了,尽管此时接收端已经发送了对这些包的确认(确认还没收到或者已经丢失了)
  • TCP retransmission(No 4536 客户端做的应答):如果一个包真的丢了,又没有后续包可以在接收方触发[Dup Ack],就不会快速重传。这种情况下发送方只好等到超时了再重传,此类重传包就会被Wireshark标上[TCP Retransmission]。
  • TCP Dup ACK(No4540):当乱序或丢包发生时,接收方会收到一些 Seq 号比期望值大的包。没收到一个这种包就会 Ack 一次期望的 Seq 值,提现发送方。

异常情况分析说明:

  • Packet size limited during capture:标记了的包没抓全
  • TCP Previous segment not captured:Wireshark 发现后一个包的 Seq 大于 Seq+Len,就知道中间缺失了一段。
  • TCP ACKed unseen segment:发现被 Ack 的那个包没被抓到,就会提示。
  • TCP Out-of-Order:后一个包的 Seq 号小于前一个包的 Seq+Len 时。
  • TCP Dup  ACK:当乱序或丢包发生时,接收方会收到一些 Seq 号比期望值大的包。没收到一个这种包就会 Ack 一次期望的 Seq 值,提现发送方。
  • TCP Fast Retransmission:三次DUP ACK之后出发快速重传。
  • TCP Retransmission:发送方只好等到超时了再重传。
  • TCP zerowindow:0窗口懂得都懂!没法再收。
  • TCP window Full:窗口耗尽。没法再发!
  • Time-to-live exceeded:分片无法正常组装

三、流量统计分析总结

经过前现的分析, 基本上已经可能确定消耗了多少流量,这里合计一下,一次http请求消耗流量如下表: 

CS/阶段 TCP3次握手 正常业务数据传输 TCP四次挥手 异常情况流量 总计
Client 132字节 184字节 120字节 66字节 502字节
Server 78字节 2943字节 108字节 1461字节 4590字节

从表中可以看到,发起一次度娘的HTTP请求,客户端消耗了502字节,服务端消耗流量4590字节,总共5090字节。

业务数据: 184字节 + 2943字节 = 3127字节,占比3127 / 5092 * 100% = 61.41%。

非业务数据: 5092字节 - 3127字节 = 1965字节,占比3127 / 5090 * 100% = 38.59%。

客户端:502 / 5092 * 100% = 9.86%

服务端:4590 / 5092 * 100% = 90.14%

3.1 痛点

假设一天请求度娘100万次http请求。

不计算异常情况一次HTTP请求总流量为 5092字节 - 66字节 - 1461字节 = 3565字节,即3565B。

  • 业务流量:2943字节 + 184字节 = 3127字节,即占87.71%
  • 非业务流量:132字节 + 78字节 + 120字节 + 108字节 = 438字节,即占12.29%

那么100万次就是  1000000 * 3565 = 3565000000B = 3481445.31KB = 3399.85MB = 3.32GB。

业务流量: 3399.85MB * 87.71% = 2982.01MB = 2.91GB 

非业务流量: 3399.85MB -  2982.01MB = 417.84 = 0.408GB (浪费的流量)

假设100万次http请求中我们只建立一次TCP三次握手和一次TCP四次挥手(即开启长连接,保持长连接也是消耗流量的),那么可以节省的流量有:438B * 1000000 = 438000000B = 427734.375KB = 417.71MB = 0.4079GB (就可以节省这些流量,当然还要减去长连接的流量)

四、HTTPS

这里不再抓HTTPS包了,感兴趣的同学可以按以上步骤亲手操作抓包看看。HTTPS还会有额外的消耗(TLS握手消耗),所以理论上HTTP肯定是比HTTPS快的,但是HTTPS多了TLS层极大增强了安全性,会更加的安全。

PS:若大佬有更多的方案解决流量相关问题的想法,欢迎评论区留言交流或留言交流。

你可能感兴趣的:(Web,http,tcp/ip,网络,网络协议,后端)