Internet History, Technology, and Security第七讲心得

Posted 2022-02-26 ptolemy

　　这一讲来到了应用层，同时也是协议体系中的顶层。

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那里一路传下来，导致这种槽糕的拓展性的原因，是因为负载的拓展性或者说用户数量严格地跟数据有关，而且数据只能有一个源头。反过来如果你只关心数据本身 那么你沿着数据的源头方向去找。只要你在路上找到了这个数据，意味着你已经有了它的拷贝，那么这个数据的传送任务也就完成了。