应用层续(中)

简介: 应用层续(中)

问题二: 解析问题-名字服务器(Name Server)


一个名字服务器存在的相关问题

可靠性问题:单点故障


扩展性问题:通信容量


维护问题:远距离的集中式数据库


分布式解决一个名字服务器的问题: ‘划分’ 区域(zone)


  1. 区域的划分有区域管理者自己决定
  2. 将DNS名字空间划分为互不相交的区域,每个区域都是 树的一部分
  3. 名字服务器:


每个区域都有一个名字服务器:维护着它所管辖区域的权威信息 (authoritative record)


权威名字服务器允许被放置在区域之外,以保障可靠性


将互联网名字空间划分为若干区域(Zone)

1689854586089-58673bd3-fbb4-4d88-a1f0-ffad38879973.png


权威DNS服务器:组织机构的DNS服务器, 提供组织机构服务器(如 Web和mail)可访问的主机和IP之间的映射


组织机构可以选择实现自己维护或由某个服务提供商来维护


TLD服务器:


1.顶级域(TLD)服务器:

负责顶级域名(如com, org, net, edu和gov)和所有国家级的顶级域名(如cn, uk, fr, ca, jp )


比如: Network solutions 公司维护com TLD服务器


Educause公司维护edu TLD服务器


1.顶级域名字服务器需要 维护资源的记录

DNS :保存资源记录(RR)的分布式数据库


1689855152694-74ff1b35-d5c4-46f8-b2d0-7621b713f99e.png


资源记录(resource records)


  • 作用:维护 域名-IP地址(其它)的映射关系
  • 位置:Name Server的分布式数据库中


RR格式: (domain_name, ttl, type,class,Value)


  • Domain_name: 域名
  • ttl: time to live : 生存时间(权威,缓冲记录)
  • Class 类别 :对于Internet,值为IN
  • Value 值:可以是数字,域名或ASCII串(服务器的别名)
  • Type 类别:资源记录的类型—见下页

1689855163416-2b93b98a-64fe-4293-9723-ef0f69656ad2.png


key:子域, value:该子域的子域服务器


key:子域服务器, value:该子域服务器IP地址


举例:



1689855750185-3ca3728a-2a10-4853-84da-de6483f2cdec.png


DNS大致工作过程


  1. 应用调用解析器(resolver)
  2. 解析器作为客户 向Name Server发出查询报文 (封装在UDP段中)
  3. Name Server返回响应报文(name/ip)


1689855339031-e912c7d4-294e-44de-b5a7-7ce2b8d8303e.png

一个机器上线之后必须具备以下的几个信息 :


IP,掩码,网关,DNS


1.ip地址是什么

2.子网掩码是什么 ()

3.localname server本地服务器() 是什么(名字的问题去解析 需要问哪个ip名字服务器.)

4.default getway默认网关(就是在一个局域网内部, 我的ip是这个,如果我想要出去这个局域网该走哪个路由器。 )


本地名字服务器(Local Name Server)


获取名字到ip的对应关系。


  • 并不严格属于层次结构
  • 每个ISP (居民区的ISP、公司、大学)都有一 个本地DNS服务器


也称为“默认名字服务器”


  • 当一个主机发起一个DNS查询时,查询被送到 其本地DNS服务器


起着代理的作用,将查询转发到层次结构中


名字服务器(Name Server)


名字解析的过程:


目标名字在本地服务器中(有缓存)


  1. 查询的名字在该区域内部
  2. 缓存(cashing)


没有缓存的话:


当与本地名字服务器不能解析 名字时,联系根名字服务器 顺着根-TLD 一直找到 权威名字服务器


也就是向上查询


www.ustc.edu.cn :


假设一个他国的公司的一台设备需要解析上述的域名所对应的ip地址


  1. 首先查询本地name server 有没有缓存(不在一个局域网八成是没有的。)
  2. 如果没有那么就向上递归查找, 看 .cn
  3. .cn知道 .edu.cn的域名服务器。
  4. .edu.cn 又知道 ustc.edu.cn 的域名服务器。
  5. 到最后一直找打最终的域名对应的ip地址。


1689856426562-ae1610b1-d1eb-44f5-989b-ca28de85e026.png

上述的查询方式是递归查询方式


还有一种查询方式是****迭代查询


1689856781019-fb3a188f-e7c5-4910-8408-595bbdfdbe5d.png


假设 : 主机cis.poly.edu 想知道 主机 gaia.cs.umass.edu 的IP地址


  1. 根(及各级域名)服务器 返回的不是查询结果,而 是下一个NS的地址
  2. 最后由权威名字服务器给 出解析结果
  3. 当前联络的服务器给出可 以联系的服务器的名字
  4. “我不知道这个名字,但 可以向这个服务器请求”


DNS协议、 报文


DNS协议:查询和响应报文的报文格式相同



1689856882215-3b27ad70-3074-4892-8af5-cb35fb20cf3d.png1689856911033-63f64dd5-7c4f-4660-8f30-6e48a8701245.png


提高性能 : 缓存


一旦名字服务器学到了一个映射,就将该映射 缓存起来


根服务器通常都在本地服务器中缓存着


使得根服务器不用经常被访问


目的:提高效率


可能存在的问题:如果情况变化,缓存结果和 权威资源记录不一致


解决方案:TTL(默认2天)


问题三:维护问题:新增一个域


  1. 在上级域的名字服务器中增加两条记录,指向这个新增 的子域的域名 和 域名服务器的地址
  2. 在新增子域 的名字服务器上运行名字服务器,负责本域 的名字解析: 名字->IP地址


例子:在com域中建立一个“Network Utopia”


1.到注册登记机构注册域名networkutopia.com

1.1. 需要向该机构提供权威DNS服务器(基本的、和辅助的)的名字 和IP地址


1.2. 登记机构在com TLD服务器中插入两条RR记录: (networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)


1.在networkutopia.com的权威服务器中确保有

  • 用于Web服务器的www.networkuptopia.com的类型为A的记录
  • 用于邮件服务器mail.networkutopia.com的类型为MX的记录


攻击DNS


1689857270966-ad02bab2-2f0f-4508-ad2e-3ab252c88091.png


P2P应用


之前介绍的例子都是CS模型的, 但是CS模型存在很多问题 。


比如: 可扩展性、可靠性等。 随着用户数量的不断增多, 用户都从服务器去获取服务(文件、视频检波等), 一旦服务挂了。 所有应用都无法服务


什么是P2P?


大概就是一个节点既是服务器又是客户端。


纯P2P架构


  • 没有(或极少)一直运行的 服务器
  • 任意端系统都可以直接通信
  • 利用peer的服务能力
  • Peer节点间歇上网,每次IP 地址都有可能变化


1690075109752-61f9fad2-d84c-44f9-b5b2-50c309db660b.png

例子:


  1. 文件分发(BitTorrent)
  2. 流媒体(KanKan)【从其他的节点获取流量,不需要从其他的服务器去获取信息】
  3. VoIP(Skype)【互联网打电话】


文件分发(BitTorrent)


[C/S vs P2P]


在cs模式中, 一般都是由服务器提供上载, 客户端提供下载,有些客户端也能够提供上载服务 ,但是速率十分慢, 所以可以忽略不记。


而p2p模式则不是。 它是将一个节点既是客户端又是服务器端


1.问题: 从一台服务器分发文件(大小F)到N个peer 需要多少时间?

从peer节点上下载能力是有限的

1690075419788-26f1ed44-197c-4cc5-b9d5-b8bbcc447cc1.png



下载下线就是说下载最慢的时间


文件分发时间: C/S模式


服务器传输: 都是由服务器 发送给peer,服务器必须顺序 传输(上载)N个文件拷贝:


  • 发送一个copy: F/us
  • 发送N个copy: NF/u

1690075638103-c8909d51-5397-418f-93e6-ea3a00b8ca87.png


客户端: 每个客户端必须下 载一个文件拷贝


  • dmin = 客户端最小的下载速率
  • 下载带宽最小的客户端下载的 时间:F/dmin


1690075647233-c9ddf255-5f98-4112-95fd-37e88d5eae4c.png

文件分发时间: P2P模式

服务器传输:最少需要上载一份拷贝


  • 发送一个拷贝的时间:F/u

1690075885007-1ed3293e-bb6c-4b74-b18c-9b5f99b7b430.png


客户端: 每个客户端必须下载一 个拷贝


  • 最小下载带宽客户单耗时:: F/dmin


所有客户端总体下载量NF (N是要下载n份, 一个文件的大小是F,所以总的下载量是NF****)


  • 最大上载带宽是:Us + Σui (Us: 服务器的上载带宽 + 每个peer节点的上载带宽)
  • 除了服务器可以上载,其他所有的peer节点都可以上载


1690075892603-fb53b0da-b29e-4514-a70b-172dcce23798.png


举例:

Client-server VS P2P的例子


如果说当服务器充足的时候,想要提高效率的话, 客户端的下载能力是瓶颈, 但是如果当服务器数量不能再增加,但是客户端又要增加的时候, 那么此时服务器的上载能力则是瓶颈。 毕竟客户端的数量是远远大于服务器端的数量的。


客户端上载速率 = u, F/u = 1 小时, Us = 10u, dmin ≥ Us


1690075936172-01857519-e868-4e01-9b9d-29a9a3745233.png


从上述可以看出。 纯clent-server模式, 一旦客户端的数量达到一定的程度, 他的速率就完全定格了(因为服务器的数量有限, 所以此时决定速率的就是服务器的上载速率。 )


而我们使用的p2p(peer to peer) 也就是我们常说的人人为我我为人人。每个peer ,它既可以上载也可以作为clent进行下载。 效率会随着机器数量的add 而不断的 add。 效率完全取决于用户数量。 十分适合现在的体系



相关实践学习
基于函数计算快速搭建Hexo博客系统
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
6天前
|
缓存 网络协议 前端开发
深入了解常见的应用层网络协议
深入了解常见的应用层网络协议
深入了解常见的应用层网络协议
|
9月前
|
网络协议 网络架构
一文搞定网络层协议
本文详细的介绍了网络层的所有的细节,学习完本章小白将打下坚实的基础。
YI
|
10月前
|
网络协议 API
计算机网络-应用层(上)
计算机网络-应用层
YI
102 0
|
6天前
|
网络协议
网络层有哪些常见协议
网络层有哪些常见协议
|
7月前
|
网络协议
应用层报文怎么传输到另一个应用层的?
应用层报文怎么传输到另一个应用层的?
|
8月前
|
缓存 网络协议 算法
【计算机网络】应用层和运输层网络协议分析
【计算机网络】应用层和运输层网络协议分析
|
9月前
|
缓存 网络协议 网络安全
网络层协议与应用(二)
网络层协议与应用(二)
162 0
|
9月前
|
网络协议 网络性能优化 网络架构
网络层协议与应用(一)
网络层协议与应用(一)
58 0
|
9月前
|
存储 缓存 网络协议
应用层(下)
应用层(下)
63 0
|
9月前
|
网络协议 安全 小程序
应用层(中)
应用层(中)
51 0