假设一个办公室的人，他们希望将 HTTP 下载限制在其互联网连接速度的最大 40% 带宽，以便它不会阻止其他流量。
我们说“你的防火墙不支持它”，他们说不可避免的一句话“我们过去可以用我们的 Netgear/DLink/DrayTek 做到这一点”。
想了想，一个下载是这样的：
HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.
速度取决于服务器向您发送数据的速度以及您确认数据的速度。
因此，要限制下载速度，您有两种选择：
1）指示服务器以更慢的速度向您发送数据 - 我认为在 TCP 或 HTTP 中没有任何协议功能可以请求该功能。
2）通过限制上传速度来更慢地确认数据包，并且也会破坏您的上传速度。
设备如何进行这种限制？有标准的方法吗？
Sha*_*den 12
TCP 本身实现了拥塞控制。
这些速率限制器会简单地将超过限制的数据包扔掉。TCP 处理这个，确保数据包全部到达并且全部按顺序到达；客户端不会确认丢弃的数据包，它们由服务器重新发送。
服务器的 TCP 堆栈将重新发送数据包，并且还会稍微回拨其发送速率，因为它认为它与客户端之间存在拥塞。它会加快速度，直到速率限制器再次丢弃数据包，依此类推。
我听过的关于 TCP 固有节流方法的最佳描述来自最近的Security Now 播客。引用史蒂夫·吉布森的话：
因此，根据通用协议，TCP 作为这种非常聪明的协议，它会执行一种称为“慢启动”的操作。通常允许在没有确认的情况下发送一定数量的数据包。所以我们的想法是，让我们在这里做一些事情。通常这个数字是两个。所以当 TCP 启动时，它可以发送两个数据包，一个接一个。在没有确认第一个的情况下，它将发送第二个。但它等待。然后限制规则是我们允许未确认数据包的数量每收到一个确认就增加一个。
所以让我们考虑一下。对于我们收到的每个确认，我们允许将未确认数据包的数量增加一个。所以我们首先发送两个数据包作为我们商定的开始。他们得到承认。所以我们有了第一个确认。我们允许自己发送两个。现在，随着收到第一个确认，我们将其增加一到三个。所以我们现在可以再发送三个数据包而无需任何进一步的确认。当我们之前发送的任何内容得到确认时，我们将其增加到四个。这被称为“拥塞窗口”。它不是一个在线发送的窗口，也就是说，它不像接收窗口，它是 TCP 标头的 16 位，它告诉我们我们能够提前发送多少数据。这个是——它是一扇窗户。它'
如果我们不断增加每次收到确认时允许发送的未确认数据包的数量，那么在某些时候我们将达到一个限制。这个系统的美妙之处在于，当我们开始尝试以比路由器之间最薄弱的链路（字面上的链路）更快的速度发送数据包时，我们会在某个时候找到最薄弱的链路断开的点。它丢弃了我们试图发送的数据包，因为我们试图发送它们太快了。因此来自另一端的确认停止，因为数据不再通过。
TCP 所做的是，如果它接收失败——这在策略上有所不同。随着时间的推移，该策略、实际拥塞避免策略发生了很大变化。有像 Tahoe 和 Reno 这样的名字，还有一大堆其他的名字，如果你做一些谷歌搜索和维基百科，你会看到它们具体是什么行为。但这个想法是，当发送方意识到它的数据因为缺少确认而不再通过时，它会迅速降低其发送速率。通常，它将其分成两半。所以它显着地缩小了它，然后又回到了增加它的地方。
所以本质上这意味着丢失数据包是“我们不能更快地发送数据”的信号功能，并且连接两端的 TCP 发送器，在整个互联网上，总是有点 - 他们'重新尝试比两个端点之间可用的最大速度更快，即最弱的链接，无论在哪里，他们总是将其推到极限。因此，考虑到某处有一个点比他们发送数据包的能力弱，他们会找到它，因为他们会抽出数据包。只要有数据要发送并且它们有高带宽连接，发送方就会增加发送速率，即未完成数据包的数量，允许作为确认即时发送的数据包回来，积极地不断向上移动这个数字，直到它把它推得太远。然后它会后退很多，然后再次向前移动。
所以这就是 TCP 连接之间实际发生的事情，我可能不知道有多少百分比，但是 Internet 上最大的流量百分比是通过 TCP 连接的。我们所有在内核中的操作系统，在所谓的 TCP 堆栈中，都有这些计数器。当我们发送文件、上传大文件或接收网页时，另一端的服务器也在做同样的事情。它在单个连接的基础上尽可能多地推送尚未确认的数据包，增加数据包速率，直到达到开始失败或断断续续的程度。然后它退出，让事情恢复，然后重新开始工作。
所以这最终成为一种自我限制的系统，考虑到限制，我的意思是，它看起来真的有点古怪和粗糙。”
| 归档时间： |
|
| 查看次数： |
7105 次 |
| 最近记录： |