这里有一篇帖子：
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html
指出“浏览器能够下载的最小文件大小是1K字节。”
这是由于网络上数据包的最小大小造成的吗？如果不是，那么原因是什么（如果确实如此）？
答案1
包此处是一个含糊不清的术语，因为它有时会被误用来指代传输的不同元素。让我们看看您的数据被包裹在什么中，您就会明白我的意思，并希望得到您想要的答案：
假设你正在通过互联网发送 1 个字节的数据1 ，TCP/IP 模型。
这数据从应用程序级别开始，需要包装在较低级别的标头中，以便可以传递。
首先，数据被包装在TCP 段，它添加了一个 20 字节的标头（最小大小现在为 21 字节）。
这使我们处于传输级别。
然后将其包裹在IP 数据包，它添加了另一个 20 字节的标头（最小大小现在为 41 字节）。
现在我们处于互联网级别。
请注意，每次新路由器将您的数据转发到新子网时，此包装都会更改。
这包含在一个链接中框架某种类型 - 其页眉和页脚大小根据所用框架的类型而变化，而框架的类型又取决于所用链接的类型。
这是在链接级别。
每次在两个实体之间传输单元时，此包装都会发生变化。
最后是物理传输（例如，通过电缆传输的电信号、无线电波等）。
以下是维基百科提供的一些信息图片TCP/IP 模型有助于直观解释正在发生的事情的页面：
1. 我猜你可能可以发送 0 个字节...但我还没检查过。事实上我也没检查过是否允许发送 1 个字节，不过没关系。
答案2
这是不正确的，下载没有最小大小限制。您可以通过在 Web 服务器上创建一个小文件并使用 wireshark 观察下载该文件时的网络流量来验证这一点。
标准以太网数据包的最小大小为 64 字节。
答案3
从表面上看，您引用的博客文章是错误的。HTTP 没有“最小下载大小”。（而且您关于最小数据包大小的理论也是错误的。）
但是，这种说法有一定道理。那就是，如果您下载的文件足够小，HTTP 响应消息（由文件和 HTTP 响应标头组成）将适合单个网络数据包。如果发生这种情况，浏览器可能会比使用两个或更多数据包发送响应更快地获取文件。
（如果响应中只有一个数据包，则数据包被丢弃并需要重新发送的可能性较小，并且 TCP/IP 流控制窗口不会为数据包确认增加额外的往返延迟的可能性较大。）
对于以太网，发送/接收的数据包的典型最大大小 (MTU) 为 1500 字节。如果将 IP 和 TCP 开销以及典型 HTTP 响应标头的大小考虑在内，则响应的第一个数据包中可能剩下约 1K 的空间用于文件数据。因此，博主的评论有一定道理。
答案4
情况比你想象的还要糟糕。
页面加载缓慢是因为浏览器在渲染 1x1 像素 800000 次时出现问题（例如，对于设置为 1000x800 的浏览器窗口）。很多年前，大概是 1999 年，我读到一篇文章，其中规定 16x16 是平铺的“最快”x 最小值。当然，现在的渲染可能有所不同。
如果你读过这篇博文，你会发现抱怨其实是页面加载速度慢，而不是下载速度慢。虽然这是一个有趣的讨论，但与数据包无关。
因此也许应该重新措辞这个问题。