对 HTTP 数据包进行计数
HTTP 数据包的数量与网页中对象的数量之间有什么关系？
What is relation between number of HTTP packets and number of objects in a web page?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
HTTP 数据包的数量与网页中对象的数量之间有什么关系？
What is relation between number of HTTP packets and number of objects in a web page?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
简而言之，答案是显然存在某种关系，但您无法准确预测其中之一。
对于更长的答案，我们首先需要纠正问题中的一些误解：
不存在“HTTP 数据包”这样的东西。 HTTP 是一种面向消息的应用程序协议，每个获取的“资源”都有一条请求消息和一条响应消息。它位于称为 TCP 的可靠字节流协议（具有流量控制等）之上。这又位于称为 IP 的数据包交换协议之上。 HTTP 请求/响应交换需要不可预测数量的 IP 数据包……具体取决于消息大小和网络条件。其他 HTTP 功能（例如压缩、保持连接活动、缓存等）使事情变得更加复杂。
“对象”的概念是不明确的。一个“对象”可以在 HTTP 请求/响应对（即上面的“资源”）之间具有一对一的对应关系，那么这部分就很简单了。 OTOH，“资源”可以是网络服务器应用程序域中多个“对象”的呈现。
除此之外，您还必须考虑到这样一个事实：典型的 HTML 资源引用了其他资源（脚本、CSS、图像等），甚至可能涉及 Ajax 回调。其中每一个都是一个“资源”，可能需要也可能不需要获取...取决于缓存等。
最后，有一个隐含的假设，即所有“对象”的大小相同。这在某些应用程序域中可能是正确的，但一般情况下并非如此。
总而言之，要预测获取一定数量的“对象”所需的网络数据包的数量，有很多变量和未知因素。
更实用的方法是将数据包级网络分析器连接到您的网络，并让它计算发送和接收的数据包数量。
如果您做出以下假设：
那么一个“对象”需要两个“HTTP 数据包”。
但坦率地说，您已经将问题简化到了这样的程度：答案对于预测真实 Web 服务器的实际性能几乎毫无用处。 （例如，这些“对象”中的任何一个都可能很小……也可能很大。如果您允许任意 javascript 或视频流链接等内容，那么一种或另一种“数据包”的数量为可能是无限的。）
The short answer is there is obviously some relation, but there is no way you can accurately predict one from the other.
For a longer answer, we first need to correct some misconceptions in the question:
There is no such thing as an "HTTP packet". HTTP is a message oriented application protocol with one request message and one response message per "resource" fetched). This sits on top of a reliable byte stream protocol (with flow control, etc) called TCP. This in turn sits on top of a packet switching protocol called IP. An HTTP request/response exchange takes an unpredictable number of IP packets ... depending on message sizes AND network conditions. Other HTTP features such as compression, keeping connections alive, caching and so on make things even more complicated.
The idea of an "object" is ill-defined. An "object" could have a one-to-one correspondence between HTTP request / response pairs (i.e. a "resource" in the above) then that part is simple. OTOH, a "resource" could be a rendering of multiple "objects" in the application domain of the webserver.
On top of that, you've also got to account for the fact that a typical HTML resource has references to other resources (Scripts, CSS, images, etc) and may even involve Ajax callbacks. Each of these is a "resource", that may or may not need to be fetched ... depending on caching, etc.
Finally, there is an implicit assumption that all "objects" are the same size. This might be true in some application domains, but it is not true in general.
So to summarize, there are far to many variables and unknowns for it to be feasible to predict the number of network packets required to fetch a certain number of "objects".
A more practical approach is to attach a packet-level network analyser to your network and get it to count the number of packets sent and received.
If you make the following assumptions:
then one "object" requires two "HTTP packets".
But frankly, you've simplified the problem to a point where the answer is next to useless for predicting actual performance of real web-servers. (For instance, any one of those "objects" could be tiny ... or huge. And if you allow for arbitrary javascript, or content such as links to video streams, then the number of "packets" of one kind or another is potentially unbounded.)
针对 HTML 页面中引用的每个文件发出 GET 请求，所有这些文件通常都适合一个 TCP 流段。 HTTP 是一种状态机，因此，许多请求/响应可以在一个请求/响应中进行管道传输。
响应中发送的数据包数量因对象的大小和缓存参数而异。例如，如果文件已经在浏览器缓存中，它将进行条件获取并收到 HTTP/1.1 304 Not Modified 响应代码，该响应代码不包含任何数据。此外，可以在一个分段中发出许多 HTTP/1.1 304，因为与分段的最大大小相比，这一响应非常小。另一个例子，如果一个文件大于最大段大小，则该文件可能（并且可能会）被分成许多段。
这是您想知道的吗？
A GET request is issued for every file referred in a HTML page, all of which, usually, fit in one TCP stream segment. HTTP is a state machine, so, many requests/response can be pipelined in one request/response.
The number of packets sent in response vary in the size of the objects and in caching parameters. For example, if a file is already in the browser cache, it will make a conditional get and will receive a HTTP/1.1 304 Not Modified response code, which does not contain any data. Moreover, many HTTP/1.1 304 can be issued in one segment, as this response is very tiny compared to segments' maximum size. Another example, if a file is bigger than the maximum segment size, the file may (and it probably will) be divided in many segments.
Is this what you wish to know?