【问题标题】:Loading bar process on a TCP connection在 TCP 连接上加载 bar 进程
【发布时间】:2019-08-06 02:29:56
【问题描述】:

所以,根据我从 TCP 数据包(包括您将在浏览器中处理的大部分流量)中得知的信息,它们是有序的,但没有上限。意思是,包头会说“包号:6”,而不是“包号:6/180”。

那么,怎样才能给出一个准确的加载条呢?您无法计算当前/最大值比率,因为最大值不存在。

我是在将电影等大文件下载到文件系统或仅在单页应用程序中接收一些 JSON blob 的情况下提出这个问题的。在这两种情况下,准确的加载栏如何工作?

我知道许多 SPA 使用微调器,但没有明确的百分比,但一些 SPA,如 YouTube 和 Instagram,确实使用加载栏。

【问题讨论】:

  • HTTP 标头包含Content-Length
  • 这是否意味着服务于该请求的服务器会计算并将其放入标头中?如果 SPA 中的一个视图有多个网络请求怎么办?此外,它如何知道在等待服务器甚至响应来自 SPA 的请求时更改加载栏?

标签: browser tcp cross-browser single-page-application


【解决方案1】:

在 TCP 级别上,既不知道传输文件的长度,也没有文件的概念——它只是一个字节流,可能会在将来的某个时间关闭。甚至有可能通过这个字节流传输多个实际文件,但在 TCP 级别上却一无所知。

可以用于某些进度条的知识来自应用程序级别。当使用 HTTP(即今天通常使用的协议)下载文件时,服务器在大多数情况下会在 HTTP 标头中发送一个 Content-length 字段,该字段显示响应的最终长度。由于客户端知道已经接收了多少字节,他可以显示接收到的数据的百分比。

对于客户端知道要上传的数据长度并知道它已经发送了多少数据的上传也是类似的。请注意,客户端不确定实际收到了多少数据。但是 TCP 的机制确保还有一个有限的“正在运行”的字节窗口,并且只有在服务器确认足够的先前数据后,客户端才能发送更多数据。

但请注意,并非在所有情况下都可以使用这种进度表。即使使用 HTTP,服务器也不需要预先发送长度。它可以简单地忽略此信息并在传输所有数据后关闭 TCP 连接。或者它可以使用分块传输编码,它以较小的块发送数据,以长度为前缀,但响应的最终长度是预先未知的。在这种情况下,浏览器无法显示正确的进度表,因为不知道最终长度,因此通常只显示仍有一些传输正在进行,而不是传输完成了多少。

这仅适用于 HTTP 协议。但其他应用程序协议类似,可能预先知道或不知道长度,在这种情况下,某些进度表可能会显示传输的百分比,也可能不显示。

【讨论】:

    猜你喜欢
    • 2012-11-01
    • 2010-10-17
    • 1970-01-01
    • 2015-09-08
    • 1970-01-01
    • 2016-11-19
    • 1970-01-01
    • 2014-10-20
    • 2012-11-26
    相关资源
    最近更新 更多