【Internet History, Technology, and Security】第七讲心得
这一讲来到了应用层,同时也是协议体系中的顶层。
Application Layer
其实从之前的课程中可以发现,每一个层次都会依赖它的下一层,应用层也一样,它将会应用TCP层的服务,TCP层的服务为应用层提供了可靠、有序的端到端数据流。可以从一台电脑中一个应用程序开始,到另一台电脑的应用中结束并可提供双向交流。在我们得到了这样的框架后,我们应该怎么去使用它?在日常通信中,我们该如何请求数据?
课程中的图给出了很好的答案,左端表示客户端,而右端则为服务端,客户端给我们信息,而服务器负责给客户端提供信息,所以客户端经常要发出请求,然后服务器回应请求,这之间的消息传递就是我们之前所学习的四个层次。因此,我们可以基于这个原理建立邮件系统、万维网或者我们可以观看流视频。这时候就要重点提一下万维网了,它基于上面所说的原理,整体简洁且优雅,可以说是最为人所熟知的一个概念,虽然也有很多其他的协议存在,但是万维网协议是最普遍的协议。
那么现在有两个问题需要应用层来处理了。其一是哪个应用将获得数据?这个问题通过一个叫做端口的机制解决。端口允许拥有一个IP地址,或一台电脑,或一个服务器,通过这种方式得以提供多项服务,然后客户端能像电话接线那样拨号,选择客户端想要的服务,当你连接上了你想要使用的服务,比如万维网时,你就可以使用协议来和它沟通。
现在来聊聊端口和连接,如果我添加一台随机的服务器,比如图中的服务器,域名为www.umich.edu,它有一个连接着云的IP地址,我们可以用许多客户端和它进行交流。服务器有许多端口,分别起着不同的作用。而一旦我们和网络服务器、邮箱服务器或邮局服务器有了连接,我们就得了解如何和它进行沟通,这就是所谓的应用协议(Application protocols),也就是我们要面对的第二个问题,与应用程序交谈的规则是什么?TCP提供了可靠的连接,我们现在可以通过端口连向想要的的服务器,而现在的问题是:我们在整次连接中要说些什么?说什么?谁先说?需要发送些什么内容?而这取决于你进行对话的是哪类服务器,例如在视频中,就是使用万维网服务器。
万维网有时也被称为浏览器,万维网客户端和万维网服务器使用叫做HTTP的协议进行沟通,你会看到URL的开端显示的是http://,HTTP有一套协议使你可以由客户端建立连接到服务器,客户端请求一个文件,服务器提供这个文件然后连接就被断开了。整体的运行流程就像这样:
在了解了流程之后,我们可以尝试去“攻击”网站,因为HTTP基本上是一个公共协议,它并没有被高度保护,所以它也是较为容易被攻击的,而攻击安全的协议不单单只是输入指令,还需要写软件,因此我们需要安装Telnet,之后的操作中视频中都有给出,最终的目的就是欺骗服务器,让它认为我们是浏览器,从而向我们发送数据。
回到正题,我们已经介绍完了四层架构,但非常不可思议的是,这些大部分都来自1970年代的研究工作,且现在都还在使用,随着NSFnet的出现,会有一定的调整,但关键性的调整也都是上个世纪八十年代的事了。但另一方面,计算机的数量则大幅度增长,从1969年的6台到2011年的几十亿级别,他们仍在使用这最初的六台所使用的框架。当你看着现在的网络的时候,你可能会觉得它像一个生物,有着鲜活的生命,同时也像大部分生物一样,有着自愈的功能,因为它不是完美的。
Van Jacobson - Content Centered Networking
这个章节的最后是对Van Jacobsom的采访,他提出了内容中心网络(Content Centric Networking)的概念。Van认为我们现在面临着大量的关于拓展性问题,他想把以信息为中心的网络模型,和以主机为中心的TCP/IP模型整合到一起。
网络最开始只是电脑的一个电话系统,但随着需求的增加,ARPnet诞生了,它可以不需要像电话线路一样知道所有结点,它只需要知道消息发送的下一个结点,就能把数据发送出去,而到了二十一世纪后,网络又有了新的发展。
但这些似乎都和最开始的电话模型没什么关系,这给Van带来了很大的冲击,这让他发出疑问:如果我们放弃18世纪的电话模型,把注意力放在电线里传输的信息,而不是电线本身,会怎么样? 我们能不能把web当作通讯的基础,而不仅仅是一个覆盖在TCP/IP上的一层? 例如,你可以在你的个人网站上面发布一个视频,但是你必须得寄希望于它的点击量不是特别大,因为如果点击量过大,你的链接配额将完全饱和。那么你的互联网供应商(ISP)就会马上关闭它,这就是 Slashdot 效应。现如今,你可以看到像YouTube、谷歌、亚马逊、脸书、推特都拥有着庞大的用户群,它们都是用一个IP地址表明自己,看起来就像只有一个地点,但是对于一个拥有数亿用户的单一地点来说,在对话模型下,它的通信量将跟用户数量同比增长,比如你正在更新推特或者上传视频,你想让数百万人看到,但你没法把它放到对话模型中。
所以,Van 他们花了许多的时间来让网络误以为只有一个地点,网络层的信息在性质上与姓名,身份信息一致,只是它随机的分散在整个分组里。这样他们有了源地址和目的地址,它的前部被网络层调用,端口作为更深层次的应用层调用,以及序列号,让应用重新组装成一个大的单元,URL的整个分层都要使用它,而不是只有传输的部分。如果你把源地址,端口,序列号,URL均整合到了一起,这些就是信息的特定名称(the name of the information)。
如果每一个分组都有一个名字在上面,所有的信息都包含在其中,你随时可以查看它,只需要保证数据的前端工作是正常的。
你不必关心这些数据是从哪里获得的,你只需要关心数据本身,而不是它的来源。如果我们有两个人同时在看同一个视频,那么最靠近我们的上游网关会把一份拷贝发给我,把另一份一模一样的视频拷贝发给你,它们都要通过那一个网关的内存,因为这个对话的抽象概念的存在,网关并不知道,我们看的是相同的视频,它看到的是两个不同的对话,它没法看着它的内存,然后说:“哦!我有这个数据,我可以直接给你。”它必须要重新拿到一个新的拷贝,而且要从YouTube那里一路传下来,导致这种槽糕的拓展性的原因,是因为负载的拓展性或者说用户数量严格地跟数据有关,而且数据只能有一个源头。反过来如果你只关心数据本身 那么你沿着数据的源头方向去找。只要你在路上找到了这个数据,意味着你已经有了它的拷贝,那么这个数据的传送任务也就完成了。