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

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

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

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

目录

一、本地环境

二、抓包分析

2.1 TCP三次握手

2.2 正常业务数据传输

2.3 TCP四次挥手

2.4 异常情况

三、流量统计分析总结

3.1 痛点

四、HTTPS

---

一、本地环境

操作系统: MacOs Sonoma 14.0

网络分析工具：Wireshark

Wireshark下载地址：

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

二、抓包分析

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

​

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

​

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请求消耗流量如下表： 

从表中可以看到，发起一次度娘的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：若大佬有更多的方案解决流量相关问题的想法，欢迎评论区留言交流或留言交流。