CategoryFrontiers

【转】从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字节积累确认;

【转】SDN与OpenFlow技术简介

热身

推荐两个YouTube视频,第一个的要点是SDN与传统网络对比的3D示意图、中心化控制

——

第二个的要点是Control Plane、Data Plane

——

本文是2012年文章,对Openflow的发展、规范、应用和SDN的提出及相关应用做出较为客观全面的介绍。笔者希望通过本文对OpenFlow/SDN做一个初步介绍,以期帮助大家能够进一步深入了解和学习OpenFlow/SDN。

序言:从网络虚拟化说起

云计算的发展,是以虚拟化技术为基础的。云计算服务商以按需分配为原则,为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。虚拟化技术将各种物理资源抽象为逻辑上的资源,隐藏了各种物理上的限制,为在更细粒度上对其进行管理和应用提供了可能性。近些年,计算的虚拟化技术(主要指x86平台的虚拟化)取得了长足的发展;相比较而言,尽管存储和网络的虚拟化也得到了诸多发展,但是还有很多问题亟需解决,在云计算环境中尤其如此。OpenFlow和SDN尽管不是专门为网络虚拟化而生,但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。

起源与发展

OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。CleanSlate项目的最终目的是要重新发明英特网,旨在改变设计已略显不合时宜,且难以进化发展的现有网络基础架构。在2006年,斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane[2],该项目试图通过一个集中式的控制器,让网络管理员可以方便地定义基于网络流的安全控制策略,并将这些安全策略应用到各种网络设备中,从而实现对整个网络通讯的安全控制。受此项目(及Ethane的前续项目Sane[3])启发,Martin和他的导师Nick McKeown教授(时任Clean Slate项目的Faculty Director)发现,如果将Ethane的设计更一般化,将传统网络设备的数据转发(data plane)和路由控制(control plane)两个功能模块相分离,通过集中式的控制器(Controller)以标准化的接口对各种网络设备进行管理和配置,那么这将为网络资源的设计、管理和使用提供更多的可能性,从而更容易推动网络的革新与发展。于是,他们便提出了OpenFlow的概念,并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus …

Notes on SIGCOMM’19

Opening Keynotes

Steps Toward a Robust Global Internet (CC)

Mark Handley, UCL

Lessons from struggles in CC over all these years

  1. change is hard
  2. even the best CC algorithm cannot, by itself, solve congestion
    1. Feedback Loops
      1. (HTTP GET – [TCP: