当前位置：文江博客话题详情

最小的 HTTP 和 HTTPS 数据请求是多少

发布于 2025-01-04 15:30:19 字数 271 浏览 1 评论 0原文

假设我想使用 HTTP 协议从服务器获取一个字节，并且我想最小化所有内容。没有标题，只是 http://myserver.com/b，其中 b 是一个包含一个字符的文本文件，或者更好的是 b 只是一个字符（不确定这是否可能）。

有没有办法用 Apache 来做到这一点？完整的 http 和完整的 HTTPS 事务所需的最小数据量是多少？

或者，如果数据效率更高，则可以仅通过头请求来完成事务。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

妳是的陽光 2025-01-11 15:30:19

如果您计划使用 HTTP/1.1（如果您最终使用虚拟主机，则或多或少需要），您的 GET 请求将需要包含主机名，可以在 Host 中 标头或作为请求行中的绝对 URI（请参阅 RFC 2616 第 5.1.2 节）。

您的回复还需要 Content-Length 或传输编码标头和分隔符。

如果您愿意通过使用 HEAD 请求来“破坏”HTTP，那么听起来 HTTP 可能不是协议的最佳选择。您也许还可以在自定义标头中返回某些内容，但这不是一种干净的方法。

请注意，即使您实现自己的协议，您也需要实现类似于 Content-Length 或分块编码提供的机制，以便能够确定何时停止从远程方读取（否则，您将无法检测严重关闭的连接）。

编辑：

这是一个简单的示例，这将根据您的主机名而有所不同（假设是 HTTP 1.1）。我想你可以使用OPTIONS来代替。这取决于您愿意破坏 HTTP 的程度...

请求：

GET / HTTP/1.1
Host: www.example.com

即 14 + 2 + 21 + 2 + 2 = 41 字节（2 表示 CRLF）

响应：

HTTP/1.1 200 OK
Content-Length: 1
Content-Type: text/plain

a

即 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 字节

对于 HTTPS，SSL/TLS 通道本身会有少量开销，但其中大部分将由握手占用，特别是，服务器证书（假设您没有使用客户端证书身份验证）应该是最大的。检查证书的大小（DER 格式）。

If you're planning to use HTTP/1.1 (more or less require if you end up on a virtual host), your GET request will need to have the host name, either in the Host header or as an absolute URI in the request line (see RFC 2616 section 5.1.2).

Your response will also need a Content-Length or transfer encoding headers and delimiters.

If you're willing to "break" HTTP by using a HEAD request, it sounds like HTTP might not be the best choice of protocol. You might also be able to return something in a custom header, but that's not a clean way of doing it.

Note that, even if you implement your own protocol, you will need to implement a mechanism similar to what Content-Length or chunked encoding provide, to be able to determine when to stop reading from the remote party (otherwise, you won't be able to detect badly closed connections).

EDIT:

Here is a quick example, this will vary depending on your host name (assuming HTTP 1.1). I guess you could use OPTIONS instead. It depends on how much you're willing to break HTTP...

Request:

GET / HTTP/1.1
Host: www.example.com

That's 14 + 2 + 21 + 2 + 2 = 41 bytes (2 for CRLF)

Response:

HTTP/1.1 200 OK
Content-Length: 1
Content-Type: text/plain

a

That's 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 bytes

For HTTPS, there will be a small overhead for the SSL/TLS channel itself, but the bulk of it will be taken by the handshake, in particular, the server certificate (assuming you're not using client-cert authentication) should be the biggest. Check the size (in DER format) of your certificate.

回复收藏 0 原文

难得心□动 2025-01-11 15:30:19

你究竟想要实现什么目标，这是一种保持活力吗？

您可以执行“GET /”，这意味着正在使用 HTTP/1.0，但这会阻止您使用虚拟主机等内容。您可以将“/”映射到 cgi 脚本，它不需要是真实的文件，具体取决于您想要实现的目标。您可以将 Apache 配置为仅返回最小的标头集，这基本上是“Content-Type: text/plain”（或其他更短的 mime 类型，可能是自定义 mimetype，例如“Content-Type: a/b”）和“ Content-Length: 0”，因此根本不返回响应正文。

回复收藏 0 原文

月依秋水 2025-01-11 15:30:19

这是一个老问题，但也许有人发现它有用，因为没有人回答问题的 HTTPS 部分。

对我来说，这是为了在我的代理中轻松验证 HTTPS 通信所需要的，该代理通过隧道连接不可信的其他代理。

这个网站解释得很清楚：http://netsekure.org/2010/03/tls-overhead /

文章引用：

要记住的一件事会影响计算，那就是大多数消息的可变大小。变量的性质不允许计算精确的值，但是对变量字段取一些合理的平均值，可以得到开销的良好近似值。现在，让我们浏览每条消息并考虑它们的大小。
ClientHello – 初始客户端 hello 的平均大小约为 160 到 170 字节。它会根据客户端发送的密码套件的数量以及存在的 TLS ClientHello 扩展的数量而有所不同。如果使用会话恢复，则还需要为Session ID字段添加32个字节。
ServerHello – 该消息比 ClientHello 更加静态，但由于 TLS 扩展，大小仍然可变。平均大小为 70 到 75 字节。
- 证书 – 此消息是不同服务器之间大小变化最大的消息。该消息携带服务器的证书，以及证书链中的所有中间颁发者证书（减去根证书）。由于证书大小根据所使用的参数和密钥的不同而有很大差异，因此我平均每个证书使用 1500 字节（自签名证书可以小至 800 字节）。另一个不同的因素是直到根证书的证书链的长度。为了更加保守地看待网络上的情况，我们假设链中有 4 个证书。总的来说，这条消息的花费约为 6k。
ClientKeyExchange – 让我们再次假设最广泛使用的情况 – RSA 服务器证书。这对应于该消息的 130 字节大小。
ChangeCipherSpec – 固定大小为 1（技术上不是握手消息）
已完成 - 根据使用 SSLv3 还是 TLS，大小变化很大 - 分别为 36 和 12 字节。目前大多数实现至少支持 TLSv1.0，因此我们假设将使用 TLS，因此大小将为 12 字节

因此最小值可以大（或小）为：

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249

尽管根据文章，平均值约为 <代码>6449 字节。

另外，重要的是要知道 TLS 会话可以恢复，因此只有第一个连接有此开销。所有其他消息大约有 330 字节以上。

It is an old question, but maybe someone found it useful, because nobody has answered the HTTPS part of the question.

For me this was needed for an easy validation of HTTPS communication in my proxy, which connects untrustable other proxies through tunnel.

This site explains it clearly: http://netsekure.org/2010/03/tls-overhead/

Quotes from the article:

One thing to keep in mind that will influence the calculation is the variable size of most of the messages. The variable nature will not allow to calculate a precise value, but taking some reasonable average values for the variable fields, one can get a good approximation of the overhead. Now, let’s go through each of the messages and consider their sizes.
ClientHello – the average size of initial client hello is about 160 to 170 bytes. It will vary based on the number of ciphersuites sent by the client as well as how many TLS ClientHello extensions are present. If session resumption is used, another 32 bytes need to be added for the Session ID field.
ServerHello – this message is a bit more static than the ClientHello, but still variable size due to TLS extensions. The average size is 70 to 75 bytes.
-Certificate – this message is the one that varies the most in size between different servers. The message carries the certificate of the server, as well as all intermediate issuer certificates in the certificate chain (minus the root cert). Since certificate sizes vary quite a bit based on the parameters and keys used, I would use an average of 1500 bytes per certificate (self-signed certificates can be as small as 800 bytes). The other varying factor is the length of the certificate chain up to the root certificate. To be on the more conservative side of what is on the web, let’s assume 4 certificates in the chain. Overall this gives us about 6k for this message.
ClientKeyExchange – let’s assume again the most widely used case – RSA server certificate. This corresponds to size of 130 bytes for this message.
ChangeCipherSpec – fixed size of 1 (technically not a handshake message)
Finished – depending whether SSLv3 is used or TLS, the size varies quite a bit – 36 and 12 bytes respectively. Most implementations these days support TLSv1.0 at least, so let’s assume TLS will be used and therefore the size will be 12 bytes

So the minimum can be as big (or small) as:

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249

Though according to the article, the average is about 6449 bytes.

Also it is important to know that TLS sessions can be resumed, so only the 1st connection has this overhead. All other messages have about 330 bytes plus.

回复收藏 0 原文