21-05-08-计网自顶向下方法

2.3.1 SMTP

SMTP的基本操作：

• A调用邮件代理并提供B的邮件地址，输入报文，使用用户代理发送报文
• A的用户代理把报文发送给A的邮件服务器，该报文被存放在邮件服务器的报文队列中
• A邮件服务器上的SMTP客户端发现了该报文，则创建一个到运行B的邮件服务器上的SMTP服务器上的TCP连接
• 初始的SMTP握手，SMTP通过该TCP连接发送A的报文
• B的邮件服务器上，SMTP的服务器接收该报文，再将其放入B的邮箱中
• B在方便时调用用户代理阅读报文

SMTP一般不使用中间邮件服务器发送邮件，即使两个邮件服务器相隔非常远，TCP连接也是连接这两个地方，如果B的邮件服务器没有开机，则该报文会保留在A的邮件服务器上进行尝试，则邮件并不在中间某个邮件服务器存留

SMTP使用的是持续连接：

如果发送服务器有几个报文发往同一个接收邮件服务器，则可以通过同一个TCP连接发送这些所有的报文，每个报文用一个新的MAIL FROM:crepes.fr开始，以一个独立句点指示该邮件的结束，并且当所有邮件发送完才发送QUIT

2.3.2 与HTTP的对比

（1）

HTTP是一个拉协议，用户使用HTTP从web服务器拉取对象，TCP连接是由想接收文件的机器发起的

SMTP是一个推协议，发送邮件服务器把对象推向接收服务器，TCP是由想发送文件的机器发起的

（2）

SMTP采用 7 比特ASCII格式，如果报文中包含了非 7 比特的ASCII字符或二进制数据，则该报文必须按照 7 比特的ASCII码进行编码

HTTP不受限制

（3）

对于一个有文本和图像的文档

HTTP把每个对象封装到HTTP响应报文中

SMTP把所有报文对象放在一个报文中

2.3.3 邮件报文格式

需要包含一个各种环境的首部信息，在一系列首部行中

每个首部行必须包含 From: 和 To:

典型的报文首部如下：

一个空白行后是以ASCII格式的报文体

2.3.4 邮件访问协议

存在问题：

接收方的邮件服务器不总是在线的，除非总是不间断地运行

解决：

用户在本地运行代理程序，而访问存储总是保持在开机共享的邮件服务器上的邮箱，该邮件服务器与其他用户共享，通常由用户的ISP进行维护

接收方如何得到SMTP的报文，因为SMTP是推协议，于是有了新的邮件访问协议，如POP3，IMAP，HTTP

1.POP3

协议简单、功能有限，用户代理打开一个到邮件服务器端口110上的TCP连接后，POP3开始运行

• 特许阶段

用户代理发送用户名和口令鉴别用户

• 事务处理阶段

用户代理取回报文，同时用户代理可以对报文做删除标记，取消删除标记，获取邮件的统计信息

• 更新阶段

用户退出且结束该POP3会话，邮件服务器则删除被标记删除的报文

事务处理过程，对于用户的命令服务器有两种回答：

• + OK（有时跟着数据）：前面的命令正常
• + ERR，前面命令差错

特许阶段两个主要命令

• user

• pass

• 下载并删除方式

• 下载并保留方式

2.IMAP

解决报文无法在服务器分类浏览问题

IMAP服务器把每个报文和一个文件夹联系起来，当报文第一次到达服务器时，与收件人的INBOX文件夹相关联

IMAP提供能为用户创建新文件夹、文件移动、远程查询命令，还维护了IMAP会话的用户状态信息

允许用户代理获取报文某些部分，当低带宽连接时有益处

3.基于web的电子邮件

此时用户代理则是普通的服务器，与远程邮箱之间的通信则是通过HTTP运行，当然邮件服务器和邮件服务器之间使用的仍是SMTP

2.4 DNS：因特网的目录服务

识别主机的两种方式，主机名和IP地址

2.4.1 DNS提供的服务

域名系统：主机名到IP地址转换的目录服务

DNS：

• 一个由分层的DNS服务器实现的分布式数据库
• 一个使得主机能够查询分布式数据库的应用层协议

DNS服务器通常是运行BIND软件的UNIX机器

DNS协议运行在UDP之上，使用 53 端口

DNS是应用层协议，

• 使用客户 - 服务器模式运行在通信的端系统之间
• 通过端到端的运输协议来传送DNS报文

DNS并不是和用户直接交流，为用户应用程序及其他软件提供核心功能，即将主机名转换为对应的IP地址

DNS被其他应用层协议所使用，如HTTP、SMTP和FTP

当浏览器请求URL时

• 同一用户主机上运行着DNS应用的客户端
• 浏览器从上述URL抽取主机名，将主机名传给DNS应用的客户端
• DNS客户向DNS服务器发送一个包含主机名的请求
• DNS客户最终收到来自DNS的该IP地址，于是进行TCP连接

其他重要服务

• 主机别名：比主机规范名更加容易记忆

• 邮件服务器别名

• 负载均衡：可用于web服务器和邮件服务器

2.4.2 DNS工作原理概述

用户主机上的DNS收到请求后，向网络中发送一个DNS查询报文，使用UDP和53端口，在经过毫秒或秒的时延后，用户主机上的DNS接收到一个提供所希望映射的DNS回答报文

简单设计：只使用一个DNS服务器，包含所有映射

存在问题：

• 单点故障
• 通信容量
• 远距离的集中式数据库：单个DNS服务器不可能邻近所有查询客户，严重时延
• 维护：数据巨大，更新频繁

1.分布式、层次数据库

3种类型的DNS服务器：

• 根DNS服务器

400多个根名字服务器遍及全世界，根名字服务器提供TLD服务器的IP地址

• 顶级域(TLD)DNS服务器

对于顶级域，如com，org，net，edu，gov和所有的国家顶级域，都有其TLD服务器（集群），TLD服务器提供权威DNS服务器的IP地址

• 权威DNS服务器

因特网上具有公共访问的主机需要提供DNS记录，来映射为IP地址

还有一个本地DNS服务器，其实不属于该服务器的层次结构

每个ISP都有其本地DNS服务器，当主机与ISP连接时，通过DHCP提供本地DNS服务器的IP地址

主机的DNS服务器通常“邻近”本主机

根DNS服务器 --> edu

TLD DNS访问 --> umass.edu

权威DNS服务器 --> IP地址

例子中发送了 4 粉查询报文， 4 份回答报文

当TLD服务器不知道权威DNS服务器的IP地址，而需要通过一台中间DNS服务器时，则需要增加了 2 份DNS报文

实际中都采用上图的模式，从请求主机到本地DNS服务器的查询是递归的，其余查询是迭代的

2.DNS缓存

在一个请求链中，当某DNS服务器接收到一个DNS回答（即包含某主机名到IP地址的映射）时，则将映射缓存在本地存储器中，映射时间不是永久的，一般设置为 2 天

2.4.3 DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录RR，RR提供了主机名到IP地址的映射

每个DNS回答报文包含了一条或多条RR

RR是一个包含了下列字段的 4 元组

（Name，Value，Type，TTL）

TTL：记录生存的时间，资源记录应当从缓存中删除的时间

Name和Value的值取决于Type

• Type = A：Name是主机名，Value是对应的IP地址
• Type = NS：Name是个域（如foo.com），Value是如何知道获得该域中主机IP地址的权威DNS服务器的主机名
• Type = CHAME：Value是别名为Name的主机对应的规范主机名
• Type = MX：Value是别名为Name的邮件服务器的规范主机名

用于某特定主机名的权威DNS服务器：有一条A类型的RR（普通DNS服务器也可以拥有）

不是用于某特定主机名的权威DNS服务器，则有一条NS类型的RR，对应主机名的域；还有一条A记录，提供NS记录的Value字段中的DNS服务器IP地址

如edu TLD服务器不是主机gaia.cs.umass,edu的权威DNS服务器，则它拥有一条包括主机cs.umass.edu的域记录，即(umass.edu, dns.umass.edu, NS) ;还有一条A类型(dns.umass.edu，128.119.40.111，A)

1.DNS报文

两种报文格式一致：

• 标识符：16 bit，标识该查询，会被复制到对查询的回答报文中，匹配请求和回答
• 标志：
  • 1bit表示查询(0)还是回答(1)
  • 1bit表示当DNS服务器是请求名字的权威DNS服务器时，当没有某记录时是否递归查询，是(1)，否(0)
  • 4个字段表示问题、回答、权威、附加信息的长度
• 问题：包含正在查询的信息
  • 名字字段：正在被查询的主机名字
  • 类型字段：A，MA等
• 回答：对最初请求的名字的资源记录，有多条RR，因此主机名有多个IP地址
• 权威：包含了其他权威服务器的记录
• 附加：其他有帮助的记录

2.5 P2P 文件分发

1.P2P体系结构的扩展性

由图可知P2P体系结构最小分发时间不仅总是小于客户 - 服务器的分发时间，并且对于任意的对等方数量N，总是小于 1 小时，因此P2P体系结构是自扩展的，原因：对等方除了是消费者还是重新分发者

2.BitTorrent

洪流：参与一个特定文件分发的所有对等方发集合，彼此下载等长度的文件块，一般256KB

每个洪流有一个基础设施节点，称为追踪器

当一个对等方加入洪流，则向追踪器注册自己，并周期性向追踪器通知仍在洪流中

当A加入洪流时，追踪器给其一个子集，并将全部对等方IP发给A，A根据子集创建并行TCP连接

每时刻A周期性询问邻近对等方有哪些块，然后使用最稀缺优先技术，A没有的块，邻近对等方中拥有此块，但数量最少，于是请求这块，使此块更快分发，为了均衡每块的副本数量

响应请求时，对能向A请求放以最高速率提供数据的邻居给出优先权，10秒后再重新计算

每过30秒，A也要随机选择邻居向其发送块

一报还一报

2.6 视频流和内容分发网

单一数据中心缺陷

• 巨大的时延
• 经过相同的链路多次发送，浪费带宽与额外费用

利用内容分发网CDN，分布在多个地理位置

CDN两种安置原则

• 深入：靠近端用户
• 邀请做客：放置在因特网交换点IXP

简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索给视频（某中心仓库或者另外一个集群），向客户流式传输视频的同时在本地存储一个副本，当满存储时删除不经常请求的视频

1.CDN操作

CDN需要截获特定视频的请求，以便：

• 确定此时适合用于该客户的CDN服务器集群
• 将客户的请求重定向到该集群的某台服务器

截获和重定向机制：

利用DNS

• 用户访问位于NetCinema的Web网页
• 当用户点击链接http//video.netcinema.com/6Y7B23V 时，该用户主机发送了一个对于video.netcinema.com 的DNS请求
• 用户的本地DNS服务器(LDNS)将该DNS请求中继到一台用于NetCinema的权威DNS服务器，该服务器观察到主机名video.netcinema.com中的字符串“video”，将该DNS请求移交给KingCDN, NetCinema权威DNS服务器并不返回一个IP地址，而是向LDNS返回一个KingCDN域的主机名，如al105.kingcdn.com
• 从这时起，DNS请求进入了KingCDN专用DNS基础设施，用户的LDNS则发送第二个请求，此时是对al105.kingcdn.com的DNS请求KingCDN的DNS系统最终向LDNS返回KingCDN内容服务器的IP地址，所以正是在这里，在KingCDN的DNS系统中，指定了CDN服务器，客户将能够从这台服务器接收到它的内容
• LDNS向用户主机转发内容服务CDN节点的IP地址
• 一旦客户收到KingCDN内容服务器的IP地址，它与具有该IP地址的服务器创建了一条直接的TCP连接，并且发出对该视频的HTTP GET请求。如果使用了DASH，服务器将首先向客户发送具有URL列表的告示文件，每个URL对应视频的每个版本，并且客户将动态地选择来自不同版本的块

2.集群选择策略

简单策略：地理上最邻近的集群，但不代表着网络路径或跳数是如此

实际策略：对集群和客户之间的时延和丢包进行实时的测量，ping报文或者DNS请求