什么是最小的 HTTP 和 HTTPS 数据请求答案

【问题标题】：What is the smallest possible HTTP and HTTPS data request什么是最小的 HTTP 和 HTTPS 数据请求
【发布时间】：2012-02-10 19:05:07
【问题描述】：

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

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

或者，如果数据效率更高，则可以仅使用头部请求完成事务。

【问题讨论】：

您不能在没有标头的情况下发出 HTTP 请求。
如果我只做一个HEAD请求，最小的数据量是多少，能不能把服务器端的headers量减到最少，也就是我的数据？
@Chris，是的，你可以。根据spec，Request-Line（例如GET /）并不是严格意义上的标题。
如果可能，您应该考虑直接在 TCP 级别进行。
虽然最小的“GET”HTTP 请求很有趣，但我认为 HTTP 开销问题在更广泛的意义上更有趣 - 如果我想包装我的 TCP，我会为 HTTP 标头支付什么费用带有 HTTP 的二进制协议（PUT / Post / GET）我必须实现的最小标头是什么？

标签： http https

【解决方案1】：

如果您打算使用 HTTP/1.1（如果您最终在虚拟主机上或多或少需要），您的 GET 请求将需要在 Host 标头中或作为请求行中的绝对 URI（请参阅 RFC 2616 section 5.1.2）。

您的回复还需要Content-Length 或transfer encoding headers and delimiters。

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

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

编辑：

这是一个简单的示例，这将取决于您的主机名（假设 HTTP 1.1）。我想你可以改用OPTIONS。这取决于您愿意破坏 HTTP 的程度...

请求：

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

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

回复：

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 格式）。

【讨论】：

好的，有谁知道使用http协议和https协议传输的实际最小可能字节数是多少？它实际上是有人提到的 30，还是更大/更小/？
GET / 后跟两个 CRLF 是您可以发出的最小的 HTTP 请求。你为什么要这样做完全是另一回事。
是的，TLS 握手比较臃肿，但是这在 TLS 1.3 中得到了改进

【解决方案2】：

你到底想达到什么目的，这是一种保持活力吗？

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

【讨论】：

我想检查一个字节中最低 nybble 中的标志位，有 300 万用户，我想将数据传输保持在尽可能低的数量。
@alphablender 也许你应该使用 HTTP 以外的东西。您可以轻松编写如下所示的 TCP 协议：(1) 客户端连接，(2) 立即发送您的最小负载，(3) 断开连接。这几乎是斯巴达式的。
我同意 Chris 的观点，如果您实施自己的服务器/协议，您可以将数据流量降至最低。 HTTP 不是这里的最佳选择。

【解决方案3】：

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

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

本站解释清楚：http://netsekure.org/2010/03/tls-overhead/

文章引用：

要记住会影响计算的一件事是大多数消息的可变大小。变量的性质不允许计算精确的值，但是对变量字段取一些合理的平均值，可以得到一个很好的开销近似值。现在，让我们浏览每条消息并考虑它们的大小。

ClientHello – 初始客户端问候的平均大小约为 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 字节加。

【讨论】：