改编自另一个网站上的一个问题,基于将其发布在这里的建议......
以下视频(https://www.youtube.com/watch?v=4e0fRKHG7Hk&t=125s) 让我想到——如果你有一台旧电脑,例如,需要 5 分钟才能解码一帧现代 Youtube 视频(所有操作都由软件、旧处理器等完成)。因此,只要你拥有必要的软件,你就可以以每分钟 0.2 帧的速度观看视频。实际上,你可能不会试图这样做,因为这可能就像看着油漆变干一样……但假设你这样做了。因此,你的计算机只能以与此解码速率相对应的速率接受来自 Google 的视频数据包,以免本地缓冲区溢出。这样做会不会有问题——例如,从服务器到你的计算机的所有计算机是否都会放慢速度来适应?
我猜想,在某个时候,数据包的请求速度太慢,计算机会认为连接已经断开,并中断传输,而不是继续进行传输——我的问题是,这个临界点在哪里?显然,世界上有些地方的人们仍然使用拨号上网,因此必须对此有一定的容忍度。但这种容忍度有多大?
对于视频之类的内容,容忍度与文本是否不同?换句话说,当 Youtube 的服务器向您发送视频时,它会“犹豫”并以低于发送纯文本网页的服务器的数据包传输截止率停止发送吗?
答案1
我猜想,在某个时候,数据包的请求速度太慢,计算机会认为连接已经断开,并中断传输,而不是继续进行传输——我的问题是,这个临界点在哪里?显然,世界上有些地方的人们仍然使用拨号上网,因此必须对此有一定的容忍度。但这种容忍度有多大?
在大多数情况下,只要数据包承认及时(即您能够将 TCP ACK 发送回服务器),即使在最慢的连接上您也无法真正达到这一点。TCP 流控制处理慢速连接的方式与处理繁忙程序或弱系统的方式相同 - “接收窗口”大小可以根据需要缩小,并且传输协议中没有固有或故意的下限。
特定软件可能如果有效速度太低,则在某个时候开始关闭连接,但这不是通用的,也没有标准的“太低”,这取决于情况。
(此外,现代互联网不仅仅是视频——仍然有很多协议基本上是文本。即使撇开臃肿的 HTML/JS 网页,您仍然可以通过 SMTP 发送电子邮件或使用各种聊天应用程序,您仍然可以通过 SSH 或 Telnet 连接到远程系统等。——即使在 9600bps 串行链路上,SSH 仍然有效,尽管有点痛苦。)
对于视频之类的内容,容忍度与文本是否不同?换句话说,当 Youtube 的服务器向您发送视频时,它会“犹豫”并以低于发送纯文本网页的服务器的数据包传输截止率停止发送吗?
YouTube 是这里的一个特例(稍后会讲到)。
一般来说,当您通过 HTTP 下载某些内容时,“视频”不会自动成为其中的考虑因素 - 情况可能会有所不同,但这取决于服务器的精心配置,因为服务器本身并不知道它正在向您发送视频数据,它只是以任何方式提供 HTTP 请求 - 除非服务器管理员确定某些配置将使其在视频服务方面表现得“更好”。
“静态”与“实时”(或者可能是“按需”与“实时”)可能是更重要的区别。当服务器向您发送静态文件(即使它是一个巨大的文件)并且 TCP 告诉它客户端当前无法接收更多文件(流量控制)时,服务器可以暂时搁置您并稍后恢复;它不需要在 RAM 中缓冲,因为磁盘上的文件实际上是“缓冲区”。
另一方面,当它向你发送实时流时,数据持续地生成的,相同的 TCP 将要求服务器无限地缓冲所有数据(因为 TCP 承诺可靠传输),因此在某个时候服务器将达到其强加的每个客户端限制并断开您的连接。
(我举个具体的例子,IRC 聊天。这一切都只是文本– 实际上是拨号时代的一种协议 – 但如果你连接到 IRC 服务器,并且处于太多频道,而用户发送消息的速度比你接收消息的速度快,最终服务器为你分配的缓冲区将要填满并将以“SendQ Exceeded”关闭连接。)
YouTube与一般视频的情况不同。YouTube 使用 TCP/HTTP,但播放器会“按需”以小块下载视频(无论是流媒体还是录制的视频),因此即使是直播流也像“静态”的情况一样工作——没有可能被填满的持久连接;如果播放器注意到下载某个块花费的时间太长,它会切换到较低的质量,并可以在需要时重试同一块。如果计算机无法足够快地处理某个块,播放器就不会要求下一个,直到准备好为止。
大多数其他“实时”事物使用非 TCP 协议,如果无法及时传送数据,则允许简单地丢弃数据,例如,用于 VoIP 音频/视频流的 RTP 而不是 TCP。如果连接速度较慢,一些数据包将被丢弃,但流将继续 - 但如果丢弃的数据包太多,服务器或客户端可能会选择结束流。
从服务器到您的计算机之间的所有计算机的速度是否都会减慢以适应?
他们中的大多数人根本不关心。传输速度由端点控制——只有发送者决定何时将数据包发送给接收者;沿途的路由器要么转发它,要么将其排队,要么丢弃它,但实际上不会“减慢”太多。(路由器会一些排队,但它们更喜欢丢弃多余的数据包而不是保留它们。)
如果某个链路由于某种原因开始丢包(例如连接速度太慢,路由器的缓冲区已满,以至于丢包),发送方将注意到缺少确认,其“流量控制”和“拥塞控制”算法将导致其减慢传输速度。这种情况已经发生了每时每刻– 具有 10Gbps 链路的服务器适应具有 10Mbps 链路的客户端,或者通过 1Gbps 链路的下载适应wget
只能以 1MB/s 的速度将数据写入廉价闪存驱动器。
换句话说,在互联网上,发件人减慢适应接收方和中间路由器的速度(即它适应全部到接收器的路径上速度较慢或链路拥挤)。