计算机网络自顶向下方法学习笔记—————第二章：应用层

网络应用是计算机网络存在的理由，如果我们不能构想岀任何有用的应用，也就没有任何必要去设计支持它们的网络协议了。即应用层属于是最上层的，（例如为了去够到树上的苹果，你必须去找一些东西垫着让你能够到，在这里，苹果是目的，而你找的东西比如凳子啥的就是支持，也就是下面的几层）比喻可能不算很恰当，但属于我的理解，如果觉得不对可以直接跳过。

（2）一些网络应用的例子

社交网络 (Social Networking)：如Facebook、Twitter以及我们日常生活中经常使用到的微信，qq等。
网络 (Web)：指在互联网上使用HTTP协议进行信息交换的一种服务，用户可以通过浏览器访问各种网站。这也是我们平时经常使用的浏览功能的来源
电子邮件 (E-mail)：如Gmail、Outlook、QQ邮件、163等等，允许用户邮件之间的往来。
流媒体存储视频 (Streaming Stored Video)：如Bilibili、YouTube、Hulu、Netflix，抖音、快手等，允许用户在线观看各种类型的视频内容。
P2P文件共享 (P2P File Sharing)：允许用户通过对等网络共享文件。
语音IP (Voice over IP)
实时视频会议 (Real-time Video Conferencing)
网络搜索 (Internet Search)
远程登录 (Remote Login)

......

常用的网络应用例子还有很多很多，在这里就不补充了，有兴趣的可以自己去了解一下。

二：应用层协议原理（Principles of network applications）

（1）创建一个网络应用

当研发新应用程序之时，你首先需要编写在能在不同的终端系统（end system）上运行的软件，当今时代也有很多编程语言例如C、Java、Python等提供给我们编写软件。（eg：Web服务器软件和浏览器软件等等）

无需为网络核心（network core）编写程序，同时也做不到：由于网络核心主要是在网络层一下的较低层起作用，即主要是决定其传播（网络核心没有应用层软件eg：路由器ronter，switches）。这种设计让我们设计应用程序之时，仅需在端系统上设计，可以更快速地开发和部署网络应用。

（2）网络应用程序体系架构

下面介绍的这两个模式都是之前在概述那一章讲过的网络边缘（即主机/端系统）常用的模式之一

客户-服务器模式（Client-Server architecture）

该体系结构主要分为两个端——服务端（server）和客户端（client）
- 服务端
  - 一直运行
  - 有固定的IP地址（后面会讲）以及端口号（例如HTTP服务使用端口号：80）
  - 当接收到客户端的请求时，它向该客户端发送所请求的对象作为响应
- 客户端（eg：HTTP，FTP，SMTP）
  - 主动与服务端通信，向服务端发送请求
  - 跟其他的客户端没有通信
  - 可能是动态IP

从上图我们可以看出右下角的属于服务端，而其余的属于客户端，该服务端是不变的，一直处于那个位置，因此IP地址和端口号是不变的，而客户端可以是变化的，可以是不同的客户端，向该服务端发送请求。但这样会有一个缺点：一台单独的服务器主机跟不上众多客户端请求，负载容易过重，因此一般数据中心都会配备大量主机，从而能创建强大的虚拟服务器。

P2P体系结构
- （几乎）没有一直运行的服务器
- 任何端系统之间可以进行通信（不同于客户服务器模式的客户端间不能通信）
- 任一节点既可以是客户端也可以是服务端
- 例子：迅雷，百度网盘等...
- 不足之处：安全，性能保证，稳定性不足。

从上图我们可以看出任何一个主机都可以是服务端或者是客户端，每一个都是对等体，这就是名字的来源，这种的好处就是尽管每个对等体都会因为请求文件产生工作负载，但其也通过向其他对等体分发文件为系统增加服务能力。

（2）进程通信

进程：在主机上运行的应用程序

作用：①在同一主机内，使用进程间的通信机制通信

②在不同主机内，通过交换报文（message）来通信

（在我们上课的时候，便要求我们用Pycharm写服务端和客户端，在不同主机或者自己主机上通信；UDP和TCP都有）

客户-服务器进程
- 客户端进程：发起通信的进程
- 服务器进程：等待连接的进程（即等待客户端的请求，并将相应的文件发送）
- 注意：P2P架构的应用也有客户端进程和服务器进程之分，只是看何时打开罢了。

网络套接字（socket）
- 是进程与计算机网络之间的接口（进程可类比于一座房子，而它的套接字可以类比于它的门。）
- 进程通过socket来发送和接收报文
- 也是同一台主机内应用层与运输层之间的应用程序编程接口
- 发送跟接收各有一个套接字
- 应用程序开发者对于运输层的控制仅限于：①选择运输层协议；②也许能设定几个运输层参数，如最大缓存和最大报文段长度等（将在第3章中涉及）。

进程寻址（Addressing processes）
为了向特定目的的传输文件，需要知晓一个目的地址，因此为了明确进程，需要有一个标识以及主机地址。
- 主机有一个唯一的32位的IP地址（也是别人传输文件给主机的标识）
- 除了目的地址外，发送进程还需要指定在接收主机的接收进程（即接收套接字），这一方法主要依靠标记目的地端口号实现。

eg：发送一个HTTP报文的目的标识

IP地址：128.111.245.12

端口号：80（web服务器）

（3）可供应用程序使用的运输服务分类

由于觉得这个名字有点不是很能理解，我更愿意将这块知识点称为应用层需要传输层提供什么样的服务（或者是其指标）

数据丢失率
- 这个丢失率代表着数据是否能可靠传输，是否能正确，完整交付给接收方
- 数据丢失率低的更适用于电子邮件，文件传输等等。（这些一般都需要百分之一百的数据传输率）
吞吐量（throughput）
- 之前我们讲过吞吐量在一定时间内代表着就是持续的文件传输速率
- 一些应用（eg：多媒体，视频流）有着最低的吞吐量要求
延时（delay）
- 提供更严格的时间限制，适用于众多实时应用（例如近些年兴起的网课等等）
- 需要低延时来保持稳定性以及有效性
安全
- 提供数据加密、数据完整性和端点鉴别等安全服务。

（4）因特网提供的服务（也可以叫传输层提供的服务）

讲完了基本的指标，我们接下来就要讲一些具体的例子，具体有什么服务：

TCP
- 面向连接的服务（指的是要先连接成功我才会传消息）+ 可靠的传输服务
- 流量控制：发送方不会淹没接收方
- 拥塞控制，当网络出现拥塞的时候，能抑制发送方
- 缺点：无法保证时延，最小吞吐量，安全。
UDP
- 无连接的服务（指咔咔一顿传） + 不可靠的传输服务
- 缺点：无法保证可靠性，流量控制，拥塞控制，时延控制，最小吞吐量，，安全...
- 一句话解释就是：TCP有的UDP都没有，TCP没有的UDP也都没有

ps：那有人就会好奇了，为什么还需要UDP？

UDP是一种不提供不必要服务的协议，由于这个特点，其所需的算力等成本较小
同时缺少了TCP建立连接的过程，时延较小，实时性较强

当前因特网不提供的服务

之前我们讲的几个指标便是可靠性，吞吐量，延时，安全性。而对于TCP和UDP而言，TCP提供了可靠数据传输，同时TCP也能通过传输层安全协议 Transport Layer Security (TLS) 对TCP连接进行加密，因而较为安全。但还有两个指标我们都没有提及到，便是吞吐量和时延的保证。

从课本上来说，就是（大概理解就是当前的协议没法保证这两指标就是，~~虽然是要求提供的~~）

总之，今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

（5）应用层协议

从上面给出的这张图是流行的应用层协议，及传输层提供给这些应用层的协议~~（有点拗口）~~。传输层协议上面有粗略提及，而在第三章的传输层我们也会重点讲，这里主要讲应用层协议。

应用层协议：定义了运行在端系统的不同应用程序进程如何相互传递报文。下面是应用层协议定义的内容。

报文（message）类型：请求报文/应答报文等等
报文语法：报文上字段和描述
报文语义：字段中信息的含义
规定发送报文的时间以及规则。

按照有无公开可分为两种协议

①公开协议：由RFC文档定义；允许互操作，具有发放性（eg：HTTP，SMTP）

②私有协议：不公开，属于特定组织，厂商特有，具有定制性。（eg：Skype）

（6）本节中常见的网络应用以及对应的应用层协议

Web和HTTP
SMTP/POP3/IMAP
DNS
P2P
视频流和内容分发网络*

三：Web 和HTTP

（1）基本概念

首先我们先对这两个概念作基本的解释

什么是Web
- Web是一个因特网应用，即我们上面所说的应用层应用程序。web页面由一些对象（object）组成，可以称作一个基于互联网的信息系统，由许多互相链接的文档和其他资源组成（eg：HTML文件，JPEG图像，声音文件），可通过网络进行访问。
而什么是HTTP呢？
- HTTP是Web的应用层协议，其主要遵循的是客户/服务器模式
  - 客户：浏览器请求，接收（使用HTTP）以及显示Web对象（指的就是各种文件）
  - 服务器：Web服务器对请求进行响应+发送（使用HTTP）Web对象。
- HTTP的支撑运输协议从上面我们可以看是TCP，基本步骤如下（划重点）
  - 用户向服务器发送TCP连接请求（创建socket），port： 80
  - 服务器接收用户的TCP连接请求
  - 浏览器（HTTP用户）和服务器（HTTP服务器）交换HTTP报文/应用层报文（message）
  - TCP连接关闭
- HTTP是一个无状态协议
  - 服务器不维护客户端过去请求的状态
  - 当TCP连接关闭后就忘掉了之前的连接
  - 优点：能支持更多的客户端，不用费心维护历史信息。

（2）两种HTTP（持续&非持续）

非持续连接（Non-persistent HTTP）
- 一个具体的例子
- （几条路径从上到下我们标为①②③④），假设我们现在要申请一个页面，里面含有一个HTML文件和10个JEEG图像。
  - ①现在一个客户在端口号80（HTTP的默认端口）发起一个到服务器www.goodfuture.edu的TCP连接
  - ②而后服务端允许连接。
  - ③HTTP经过其本身的套接字A向该服务器发送一个HTTP请求报文（即请求连接啥的，该报文中还包含着自身主机的路径名，以及目的对象的地址）
  - ④而后HTTP服务器，通过其自身的套接字B接收该请求，同时检索出其申请的对象的文件地址（即HTML），在一个HTTP响应报文中封装，并通过套接字B向客户段发送响应报文。
  - HTTP接收响应报文，TCP连接关闭，而客户端会在HTML文件中提取到十个JPEG图像的引用，若要让所有的图片都在页面中显示出来，还得让服务器传输十张图片过来，因此还得经过十次上面的四步。（由于是无状态的，也就是说每一次需要一次TCP连接，再加文件请求）
- 响应时间（RTT）
  - 一个小分组从客户端到服务端再从服务端返回客户端所花费的时间【忽略传输时间——将报文推出去所花的时间】
  - 非持续连接（Non-persistent） HTTP响应时间包括
    - 一个RTT来进行TCP连接
    - 一个RTT发送TCP请求并等待HTTP响应
    - 目标文件传输时间（就我们之前讲的La/R就可以计算，不记得的可以回到第一章笔记看看）
  - 非持久HTTP响应时间=2RTT+文件传输时间

持续连接（persistent HTTP）
- 非持续连接的缺点
  - 每一个请求的对象都需要重新建立和维护一个全新的连接，假设一个页面有100张图片，那所花费的时间得2RTT×100，时延过长。
  - 必须为每一个请求的对象分配TCP的缓冲区和保持TCP变量，给Web服务器带来了大大的负担
- 持续HTTP（HTTP1.1）：
  - 服务器发送完对象后保持连接
  - 在相同的客户端和服务器之间的后续请求响应报文通过第一个连接进行传送
  - 比如在遇到上面的非持续连接的例子的10张图像的时候，可以只用一个RTT进行TCP连接。
  - 而对于同类型多对象的时候可以仅用一个RTT进行请求；例如下图
    - 首先第一个RTT进行TCP连接
    - 第二个RTT进行申请HTML文件
    - 第三个RTT进行对HTML引用的十个JPEG请求
    - 因此总共传输时间 = 3RTT + 文件传输时间

（3）HTTP报文格式

HTTP请求报文：
- 请求行：包含请求方法、请求目标和协议版本。
- 首部行：包含一些关于请求的附加信息，如Host、User-Agent等。
- 空行：用于分隔首部行和消息主体。
- 消息主体：可选的，包含请求的数据。

HTTP的请求方法常见的有GET，POST，PUT，DELETE，具体的作用和语义在这里就不多说了。（这里不算重点）

HTTP响应报文：
- 状态行：包含协议版本、状态码和状态描述。
- 首部行：包含一些关于响应的附加信息，如Server、Content-Type等。
- 空行：用于分隔首部行和消息主体。
- 消息主体：包含响应的数据。

这里常见的状态码：200（OK），301，400，404（这个很常见吧），505

（4）用户与服务器的交互：cookie

之前说过，HTTP请求/响应的交互是无状态的，这简化了服务器的设计，同时让服务器的负担大大减少。然而往往一个服务器也希望能识别用户，因而，HTTP使用了cookie，允许站点对用户跟踪，目前大多商务Web站点都使用了cookie。（简单来说就是比如一些购物软件为了知道你买了什么东西以后好推给你的作用差不多差不多，类似ID）

cookie的组件
- 在HTTP响应报文中有一个cookie的首部行
- 在HTTP请求报文中的一个cookie的首部行
- 在用户端系统中保留一个cookie文件，由用户的浏览器进行管理
- 位于Web站点的一个后端数据库
- 总之就是类似你的一个ID，在哪哪都有，只要你请求或者搜索什么的时候都会带上；具体什么时候用到这几个组件请看下面的具体实现
cookie的具体实现（如下图所示）
- 首先我们可以看到下图当没访问的时候，它只有ebay网站的一个cookie
- 而后当用户先访问amazon的服务器，该服务器会为其创造一个独特的识别码，用一个Set-cookie=1678的响应报文发送回给主机。同时也会用这个独特的识别码在后端数据库中添加一个索引。
- 主机在接受后，在自己特定的cookie文件中添加一行。
- 而当下次再次访问该网站的时候，用户的请求报文会带上这个cookie，而在服务器识别到这个cookie的时候，他会访问后端数据库，意识到你的身份后，提供给你它推荐给你的服务。
- 实际上cookie维持状态的办法便是：
  - 协议端节点：比如浏览器的cookie和后端数据库的数据
  - 报文携带：即请求报文和响应报文都会携带

HTTP cookies的作用
- 用户验证
- 购物车
- 推荐
- 用户状态
- （这个就是类似我们现在的购物软件的做法，首先你访问的商品的记录会被他们看到，在你下一次登上后便会趁机推荐给你；抖音快手啥视频的也是）
对于cookie的安全性思考
- 首先就是服务器站点可能将用户的信息泄露给第三方（即很久之前就有过在一个软件搜相关商品，在另外一个软件它给我推荐这商品）
- 跨多个网站的第三方持久性cookie可能对某一个用户分配同样的cookie值，综合分析用户在大量网络上的行为，对于安全而言这是个不好的信息。

（5）Web 缓存（caches）————代理服务器

目标：不访问原始服务器，就可以满足用户需求
通常用ISP安装（ISP：互联网服务提供商）
用户设置浏览器：通过缓存来访问Web
具体方式：浏览器将所有的HTTP请求发送给缓冲
- 缓存中存在对象，缓存直接返回对象【作为服务器】
- 缓存中不存在对象，缓存请求原始服务器，然后再将对象返回给客户端【作为用户】
- （实际上可以理解为一个中介，如果你想买的房子他们手上已经有了可以直接给你推荐，如果没有他们替你去谈）
好处
- 降低了客户端的请求响应时间
- 减少一个机构内部网络与Internet接入链路的流量
- 能让性能较弱的ICP也能够有效提供内容（ICP：互联网内容提供商）

Web缓存（caches）下时延（delay）的计算

eg：如上图所示，机构内的浏览器对这些初始服务器的平均访问速率为每秒15个请求（request），假设对象的长度为1Mb，RRT=2s，假设HTTP报文小到可以忽略（约等于传播时间可以忽略不计）

答：我们用之前的学过的La/R来计算，在机构网络之间

（15request/s）× （1Mb/requet）/（100Mbps）=0.15（时延较小）

在公共因特网和机构网络之间

（15request/s）× （1Mb/request）/（15Mbps）= 1（时延巨大）

而对于这个确实时延过大，因而有两种方案可以提高速率

①增加接入链路的速率

假设将15Mbps——>100Mbps

那这样接入链路减少到0.15，那么两台路由器之间的延时也可以忽略了，总的响应时间将大约为请求和响应的时间RTT也就是两秒。

average delay=2s

然而这种情况成本很高，所以我们来考虑另外一种方法

②安装一个Web缓存器

假设缓存命中率为0.4（40%通过缓存请求，60%通过原始服务器）

因此加上缓存器后，原来的15个请求每秒就变成了9个请求每秒。也就是说

（9request/s）× （1Mb/request）/（15Mbps）= 0.6

当流量强度小于0.8s时候对应的时延比较小，仅为几十毫秒，且加上只有百分之六十要响应

因此最后的平均时延

average delay=0.4×（≈0）s+0.6×（2s+0.01s）≈1.2s

从这可以看出平均时延比第一种方法的平均时延小很多，从这也可以看出Web缓存器的意义所在

四：Email电子邮件和SMTP/POP3/IMAP

（1）E-mail电子邮件

组成部分

用户代理
- 又名“邮件阅读器”
- 填写，编辑和阅读邮件
- 输入和输出邮件都保存在服务器上
邮件服务器
- 邮箱中管理和维护发送给用户的文件（比如重传，还有发送不过去通知发送端啥的）
- 输出报文队列保持待发送邮件报文（不让其丢失）
简单的邮件传输协议：SMTP（电子邮件中重要的应用层协议）
- 客户：发送方邮件服务器
- ”服务器“：接收方邮件服务器
- 在这里可能有点混，实际上就是自己如果要发送邮件，自己这一方就是我们之前一直提及的client，而发送报文过去的对方便是我们常提及的服务端，只是这次可能没有回应而已

（2）SMTP

实现
- 其仍然是使用TCP在客户端和服务器之间传送报文（port：25【HTTP是80】）
- 直接传输，从发送方服务器到接收方服务器
- SMTP传输的3个阶段
  - SMTP握手
  - SMTP报文传输
  - SMTP关闭
- 命令/响应交互
  - 命令：ASCII文本（7位————传递邮件前，需将二进制多媒体数据编码为ASCII码，发送完毕后到对方邮箱还需要还原；而HTTP不用）
  - 响应：状态码和状态信息
具体例子
- Alice写邮件并发送给bob的学校邮箱地址
- Alice的用户代理将邮件发送到Alice的邮件服务器，邮件放进报文队列
- SMTP的客户端打开Bob邮件服务器的TCP连接
- SMTP客户端通过TCP连接发送Alice的邮件
- Bob的邮件服务器将邮件发送到Bob的邮箱
- Bob调用其用户代理阅读邮件

特点
- SMTP一遍不使用中间邮件服务器发送邮件，哪怕两个服务器位于地球两端也是直接相连
- 如若一方邮件服务器没开机，另一方会一直尝试重新发送。
- SMTP用的是持续连接，如果又多个报文同时发往同一邮件服务器，会采用同一个TCP连接发送这些报文。

（3）与HTTP的对比

目的
- HTTP：用户拉（pull），用户想要什么对象，自己从服务器拉出来
- SMTP：用户推（push），用户想让对方接收邮件，自己发送过去
两者都是使用ASCII形式的命令/响应交互，状态码
- 但是SMTP要求报文（头部和主题）为7位ASCII码格式，如果某报文包含了非7bitASCII字符，则必须按照7比特ASCII码进行编码
- HTTP数据不受限制，什么格式都行
封装
- HTTP：每一个对象封装在各自的响应报文（例如html和JPEG对象在不同报文传输）
- SMTP：多个对象包含在一个报文里
连接方式
- HTTP既有持续连接也有非持续连接
- SMTP使用持续连接

（4）邮件报文格式

典型的报文首部如下（header：冒号前的内容；body：内容）

SMTP: RFC 5321（原RFC821）交换email报文的协议

SMTP: RFC 5322（原RFC822）定义文本报文的格式

（5）邮件访问协议

SMTP：主要是传送到接收方的邮件服务器【推】，而到了接收方的邮件服务器后，就需要下面这些邮件访问协议了
邮件访问协议：主要方便接收方查看的时候从邮件服务器拉出
- POP3（Post Office Protocol Version 3）：是一种简单的邮件传输协议，用于将邮件从邮件服务器传送到接收方的用户代理。它包括了用户身份确认、邮件下载和删除等基本操作，并通过TCP连接进行通信，服务无状态，不会保存东西等等【拉pull】
- IMAP（Internet Message Access Protocol）：与POP3类似，也是一个邮件访问协议，但比POP3功能更丰富和复杂。IMAP服务器将每封邮件与一个文件夹联系起来，允许用户创建文件夹、移动邮件以及在远程文件夹中查询邮件，因此属于有状态。【拉pull】
- 基于Web的电子邮件：越来越多的用户使用Web浏览器来收发电子邮件，通信通过HTTP进行。当用户打开浏览器，登录远程邮箱后，该电子邮件报文从接收方的邮件服务器发送到浏览器。同时当发送方要从浏览器发送一封邮件，也是依靠的HTTP发送到它的邮件服务器。【总而言之，不管是发送还是阅读，只要从Web浏览器，则用的就说HTTP，而其他都不是用的HTTP】

五：DNS

因特网上的主机有着两个名字：

①主机名：比如网址www.facebook.com

②IP地址（32bit）: 比如121.7.106.83（具体会等到第四章再来讨论）

那如何做到给你一个主机名，你能得知它的IP地址呢？

Domain Name System（DNS）：域名解析系统

分布式数据库
- 由有层次结构的域名服务器组成
- 采用分布式的原因是由于流量过大，容易单点故障，同时管理维护困难。
应用层协议：主机，DNS服务器互相通信来解析域名
- 属于Internet核心内容之一，在应用层实现
- 储存和计算的复杂度分散到网络的边缘（即主机，端系统啥的）

（1）DNS提供的服务

主机名——>IP地址
主机别名——>规范名字转换（当一个主机在不同网络环境运行，可能分配不同域名或别名，实际上指向同一个主机的IP地址）
邮件服务器别名——>规范名字转换
负载分配：多Web服务器系统；许多IP地址可以对应一个名字，实现分布式服务器提供相同服务（例如，一个大型电商网站可能同时部署了多台服务器来处理用户请求。这些服务器会共享同一个域名，比如www.example.com。当用户访问该网站时，他们的浏览器会发送一个DNS请求，请求www.example 的IP地址。DNS服务器将会返回所有服务器的IP地址，然后客户端会根据负载均衡算法选取其中的一台最空闲服务器来处理用户请求。）

（2）DNS工作机理概述

分布式、层次数据库
- 根DNS服务器（Root）
  - 有400多个根名字服务器遍及全世界。这些根名字服务器由13 个不同的组织管理。
- 顶级域DNS服务器（Top level Domain）
  - 通用域：对于每个顶级域(如com、org、net、edu和gov)
  - 国家域：和所有国家的顶级域(如cn--中国、uk、us和jp等等),
- 权威DNS服务器（Authoritative）
  - 因特网上具有公共可访问主机（如Web服务器和邮件服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。一个组织机构的权威DNS服务器收藏了这些DNS记录。现在比如一些大学和大公司都用的是自己的权威DNS服务器。
- 本地DNS服务器（local）
  - 本地DNS服务器可以看作是DNS查询的代理，严格意义不属于层次结构，但至关重要。
  - 比如一个居民区的ISP或者一个机构的ISP（类似中国移动提供的）
  - 当主机查询DNS信息时, 查询信息发送到本地DNS服务器

DNS地址解析方法
- 递归解析（recursive query）
  - 假设所知的域名在某个权威服务器中，过程如下图左图所示
  - 首先主机先委托本地DNS服务器查询
  - 而本地服务器从最高层的DNS根服务器出发
  - 一直递归往低层次移动发送，经过顶级域名服务器
  - 再发送到权威DNS服务器，得到想要的IP地址
  - 最后再原路返回一直到原来的主机
  - 缺点：如果所有的主机都这么查询，容易给上层DNS带来较大的负担
- 迭代解析（iterated query）
  - 假设所知的域名在某个权威服务器中，过程如下图右图所示
  - 首先主机先委托本地DNS服务器查询
  - 而本地服务器先访问根服务器，先从那得知了顶级域名服务器的IP地址
  - 而后本地服务器访问顶级域名服务器，再得知了权威域名服务器IP地址
  - 再访问权威DNS服务器，得到想要的IP地址
  - 最后再发送给目的主机即可

DNS缓存（DNS caching）
- 当一个服务器向另一个服务器请求DNS映射并得到回应时，将该DNS映射存储在高速缓存中，用于向之后的相同请求迅速提供查询服务
- 作用
  - 改善时延
  - 减少在Internet上到处传输的DNS报文数量
  - 本地DNS服务器一般都缓存有顶级域名服务器的IP映射（因此不需要再查询TLD服务器地址）
- 然而主机可能动态的改变IP地址，导致缓存的DNS无法访问
- 而当TTL过期后才会去查询新的IP地址（大概就说如果对方主机的IP地址改变，然而我现在缓存的是旧的IP地址，TTL又没过期，导致访问不成功，解决的办法只能是删除旧的记录）

DNS记录和报文
①分布式数据库保存着资源记录resource records (RR)
- RR 格式: (name, value, type, ttl）
  - ttl：该记录的生存时间————决定了资源记录应该从缓存中删除的时间
  - type：
    - =A：标准映射
      - name：主机名
      - value：IP地址
    - =NS：域——>权威DNS
      - name：域名（eg：foo.com）
      - Value：是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。
      - 这个记录用于沿着查询链来路由DNS查询。例如(foo.com, dns.foo.com, NS)就是一条类型为NS的记录
    - =CNAME：主机别名——>规范名
      - name：某个主机名的别名
      - value：某个主机的规范名
    - =MX：邮件服务器别名——>规范名
      - name：是别名
      - value：规范名

②DNS报文

分类：查询报文和回答报文（有着相同的格式）

六：对等体结构（peert-to-peer）P2P

到目前为止本章描述的应用（包括Web，电子邮件，DNS都用的客户-服务器体系结构，依赖于总是打开的服务器；而前面说过，对于P2P体系结构，没有一直打开的服务器，因而在这里我们来讨论一下P2P体系结构。

（1）特点

几乎没有一直运行的服务器
任何端系统都可以通信
既是服务器也是客户端
参与的主机间歇性连接且可以改变IP
例如BitTorrent，迅雷等

（2）文件分发：client-server模式vsP2P模式

question：从一台服务器分发大小为 F 的文件到N个peers需要多少时间?

cliengt-server模式
- 服务端：需要顺序传输N份文件————>t2=NF/v（v为速率）
- 用户端
  - 每个用户端都需要下载
  - t1为所有用户的最长时间
- total time=t2+t1

P2P模式
- 服务器传输：至少需要上传一个copy文件时间为
  - F/v
- 用户：每个用户下载一份copy
  - 最长时间为t1
- 系统：总体下载量为NF bits
  - 所有的节点都可以上传文件,则总体上传速率为
  - $\sum vi$ $+vs$
  - 即总体时间t2远小于c-s模式的t2

（3）BitTorrent

BitToiTent是一种用于文件分发的流行P2P协议。

请求文件块:
- 在任何时间，不同的peers拥有不同的文件块分组
- Alice节点周期性地向邻居询问他们拥有哪些文件块的信息
- Alice向peers请求它需要的文件块
- 稀缺性优先：平衡网络中文件块的数量
发送文件块:“一报还一报”tit-for-tat
- Alice向4个peer发送块，这些peer向自己提供最大带宽的服务
  - 其它peers被Alice阻塞 (将不会从Alice处获得服务)
  - 每隔10秒钟重新排出前4的peer
- 每隔30秒，随机选择其它一个peer节点，向这个节点发送文件块
  - “乐观地疏通”这个peer
  - 新加入的peer可能加入前4的列表（这就解释了刚刚加入的peer怎么获取资源进入P2P体系）
- 只向排名前4的peer（前20s）和试探性的peer（20-30s）发送文件

七：视频流和内容分发网络（由于这块不算重点，没有很详细介绍）

（1）视频流服务

视频流量：占据互联网大部分的带宽
因此得不断完善分布式，应用层面的基础设施

（2）多媒体：视频

视频：固定速率显示的图像序列
- eg：24 images/sec
数字化图像：像素的阵列
- 每个像素由若干bit表示
编码：使用图像内和图像间的冗杂来降低编码的比特数
- CBR：以固定速率编码
- VBR：视频编码速率随时间变化
存储视频的流化服务（如果实现边下边播）
- 主要的挑战：
  - 带宽可能会随着网络的拥塞程度随时间变化
  - 数据包的延迟和丢失会导致播放的延迟，或者导致较差的视频播放质量
- 流化服务：用户在播放视频前段部分，而服务器仍然在继续发送视频后段部分（即先缓存，然后播放缓存的意思）
- 具体的服务：DASH
  - 服务器
    - 将视频文件分割成为固定播放时长的块
    - 每一块单独存储，用不同码率编码（8-10种）
    - 文件复制存储在多个CDN节点
    - manifest file (告示文件): 提供不同块的 URLs
  - 用户:
    - 先获取告示文件
    - 周期性地测量服务器到用户端的带宽
    - 查询告示文件，在一个时刻请求一个块
      - 如果带宽足够好，选择最大码率的视频块
      - 会话中的不同时刻，可以切换请求不同的编码块（取决于当时的可用带宽）
  - 流化视频= 编码 + DASH + 播放缓存

(3)CDNS（内容分发网络）

挑战: 服务器如何向上百万用户同时发送流化视频内容

超级服务中心（其实从常识还有上面那些的经验就可以判断这个错，由于容易出风险，因此不用）
通过CDN：
- 在多个分布式的服务器上存储多个文件的拷贝，就近为用户服务，提高用户体验
- enter deep: 将CDN服务器深入到许多接入网
  - 比如直接部署在本地ISP内部
  - 更接近用户，数量多，离用户近，管理困难
- bring home：部署在少数（10个左右）关键位置，比如上层ISP的网络服务提供点
  - 便于管理和维护