CategoryNetworks

“The Internet and all that it enables is a vast new frontier, full of amazing challenges. There is room for great innovation. Don’t be constrained by today’s technology. Reach out and imagine what could be and then make it happen.” —— Leonard Kleinrock

【转】从TCP到QUIC:从Telnet到HTTP2.0

事情从20世纪70年代开始。

不得不说,人们最初的想法是不要让应用感知网络的存在,分层模型早已有之,网络层协议会处理网络细节。这就使得不管最终谁成了传输协议的标准,都一定要是端到端的。从业务的角度看,人们希望通过网络远程登录一台UNIX主机,这也就使得Telnet成了TCP/IP体系下最为古老的协议之一,一直到今天,我们依然在使用它(虽然现在它已经退化成端口测试工具了)(现在一般用更安全的SSH)。

See also: 【转】End-to-End Principle

我们来看看Telnet这一类程序的特点:

  • 远程输入必须到达主机,一个字节都不能丢;
  • 远程输出必须到达终端显示,一个字节都不能丢;
  • 输入的顺序必须和主机接收的顺序一致,不能乱序;
  • 输出的顺序必须和终端接收的顺序一致,不能乱序。

这写特征可以总结为强时序依赖,你很难跳过一些步骤提前做以后的事情,因为未来的输出依赖于此前的输入。这注定未来承载Telnet的协议需要构建的是一个双向串行流

为了在一个不可靠的网络中构建端到端的可靠的双向串行流,主机需要做什么以及怎么做?

从资源的角度来看,20世纪70年代是一个资源匮乏的年代,无论是带宽还是内存,如果说网络是不可靠的,为了在主机端保证可靠性(*),排队论告诉我们这注定会让主机的内存利用率指数级膨胀,最终系统崩溃。

(*):按照字节顺序排队且不能丢

另一方面,请了解一下停等协议,这应该是最简单的实现上述可靠按序需求的主机端方案(端到端需求)了,嗯,就是它了!

人们很自然地会从停等协议得到扩展,如果能1个字节停等,那就能2个字节停等,那为什么不是n个字节停等?因此,这注定了所谓的TCP协议实现所具有的超级特征,即:

  • n字节停等,n字节积累确认;

【转】ACKnowledgments in TCP

Cumulative ACK

Background: too many ACK segments would waste networking resources which should be used to transfer data from Application Layer.

Cumulative acknowledgment is a process in which the receiver sends a single acknowledgment in response to a finite number …