当图像从客户端的机器上传到客户端（浏览器）时，它需要 html 中的FileReader() API，然后将图像的base64 encoded url（比如说）以块的形式发送到服务器，它需要要重新组装。所有这些都由开发人员负责。
但是，当图像从服务器发送到客户端时，只需服务器机器内部的directory path of the image 就足够了，不需要分块和编码。
我的问题是：
1.服务器是否将图像分块发送到html文件。如果没有，如何发送完整图像而不是瓶服务器的网络？如果视频文件很大，会发生什么？
2.发送给客户端的图片是以什么形式的二进制数据-base64url / ArrayBuffer / binarystring / text / etc.
3. 如果服务器确实以块的形式发送图像，那么之后谁在客户端进行分块和重新组装？
谢谢。
【问题讨论】：
HTML 在这里并不重要。您关心的是所使用的传输协议 - 很可能是 HTTP 和 TCP。
默认情况下，HTTP 不会分块，尽管有一些高级标头允许这样做 - 这些标头主要用于支持在大文件（例如 PDF、视频）中查找。从技术上讲，这并不是真正的分块——它只是允许部分下载的基础设施（即“给我从字节 1024 到字节 2048 的数据。”）。
TCP 是一种基于流的协议。从程序员的角度来看，这就是它的全部 - 没有分块。但是，从技术上讲，它会处理您的输入数据并将其作为不同的数据包发送，这些数据包在另一端按顺序重新组合。这是一个实用问题 - 它允许您管理数据延迟、流式传输、数据包重传等。TCP 在连接协商期间处理细节 - 流量控制、窗口大小、拥塞控制......
不过，这还没有结束。所有其他层都添加了自己的位 - 他们自己的方式来打包有效负载并根据需要对其进行拆分，他们自己的方式来处理路由和过滤，他们自己的方式来处理拥塞......
最后，就像 HTTP 本身支持下载一样，它也支持上传数据。只需发送一个 HTTP 请求（通常是 POST 或 PUT）并以服务器可以理解的格式写入数据 - 从文本到 base-64 到原始二进制数据的任何内容。在您的情况下，限制因素不是服务器、浏览器或 HTTP，而是 JavaScript。基本机制仍然相同 - 请求后响应。
现在，解决您的问题：
img 标记中看到 URL 时，它将发起一个新的、单独的仅针对图像数据的请求。它与从链接下载文件没有根本不同。至于传输本身，它遵循与原始 HTML 文档几乎完全相同的方式 - HTTP 标头，然后是有效负载。[1] 现在，有一些方法可以将图像直接嵌入 HTML 文本中，但根据图像大小、缓存要求等不同，实用性也有所不同。
【讨论】：