应用层

应用层原理

网络应用的体系结构

可能的应用架构:

  • 客户-服务器模式(C/S:Client / Server)

  • 对等模式(P2P:Peer To Peer)

  • 混合体:客户-服务器和对等体系结构

客户-服务器(C/S)体系结构

服务器:

  • 一直运行
  • 固定的 IP 地址和周知的端口号(约定)
  • 扩展性:服务器场数据中心进行扩展,扩展性差

客户端:

  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可能是动态 IP 地址
  • 不直接与其它客户端通信

缺点 :可拓展性差 达到一定能限(阈值),性能暴跌 (断崖式)可靠性差

对等体(P2P)体系结构

  • (几乎)没有一直运行的服务器
  • 任意端系统之间可以进行通信
  • 每一个节点既是客户端又是服务器
    • 自扩展性-新peer节点带来新的
      服务能力,当然也带来新的服务请求
  • 参与的主机间歇性连接且可以改变地址
    • 难以管理(缺点)
  • 例子:Gnutella,迅雷

C/S和P2P体系结构的混合体

Napster

  • **文件搜索:集中 **
    • 主机在中心服务器上注册其资源
    • 主机向中心服务器查询资源位置
  • 文件传输:P2P
    • 任意 Peer 节点之间

即时通信

  • 在线检测:集中
    • 当用户上线时,向中心服务器注册其 IP 地址
    • 用户与中心服务器联系,以找到其在线好友的位置
  • 两个用户之间聊天:P2P

进程通信

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

  • 在同一个主机内,使用
    进程间通信机制通信(操作系统定义)
  • 不同主机,通过交换报文(Message)来通信
    • 使用OS提供的通信服
    • 按照应用协议交换报文
      • 借助传输层提供的服务

客户端进程:发起通信的进程,服务器进程:等待连接的进程

注意:P2P 架构的应用也有客户端进程和服务器进程之分

分布式进程通信需要解决的问题(应用进程如何使用传输层提供的服务交换报文)

image-20211124092145619

  • 问题1:进程标示和寻址问题(服务用户)
  • 问题2:传输层-应用层提供服务是如何(服务)
    • 位置:层间界面的 SAP (TCP/IP :socket)
    • 形式:应用程序接口 API (TCP/IP :socket API)
  • 问题3:如何使用传输层提供的服务,实现应用进 程之间的报文交换,实现应用(用户使用服务)
    • 定义应用层协议:报文格式,解释,时序等
    • 编制程序,使用 OS 提供的 API ,调用网络基础设施提 供通信服务传报文,实现应用时序等;

问题1:对进程进行编址(addressing)

  • 进程为了接收报文,必须有一个标识

    即: SAP (发送也需要标示)

    • 主机:唯一的 32 位 IP 地址
      仅仅有 IP 地址不能够唯一标示一个进程;在一台端系统上有很多应用进程在运行
    • 所采用的传输层协议:TCP or UDP
    • **端口号(Port Numbers) 用来区分不同的应用进程 **
  • 一些知名端口号的例子:

    • HTTP: TCP 80 ,Mail: TCP 25 ,ftp: TCP 2
  • 一个进程:用 IP+port 标示端节点

  • 本质上,一对主机进程之间的通信由 2 个端节点构成

问题2:传输层提供的服务-需要穿过层间的信息

层间接口必须要携带的信息

  • 要传输的报文(对于本层来说:SDU) (SDU——未经本层封装的) (发的什么)
  • 谁传的:对方的应用进程的标示:IP + TCP (UDP)端口 (谁发的)
  • 传给谁:对方的应用进程的标示:对方的 IP + TCP (UDP)端口号 (发给谁)

传输层实体(tcp 或者 udp 实体)根据这些信息进行 TCP 报文段 (UDP 数据报)的封装

  • 源端口号,目标端口号,数据等
  • 将 IP 地址往下交 IP 实体,用于封装 IP 数据报:源 IP,目标 IP

如果Socket API 每次传输报文,都携带如此多 的信息,太繁琐易错,不便于管理

用个代号标示通信的双方或者单方:socket

就像OS打开文件返回的句柄一样 (对句柄的操作,就是对文件的操作)

TCP socket
  • TCP 服务,两个进程之间的通信需要之前要建立连扫
    两个进程通信会持续一段时间,通信关系稳定
  • 可以用一个整数表示两个应用实体之间的通信关系
    ,本地标示
  • 穿过层间接口的信息量最小
  • TCP socket: 源 IP,源端口,目标 IP,目标 IP,目标

TCP socket 是一个整数(类似文件描述符)代表一个四元组(我的IP和端口号 对方的IP和端口号)便于管理使得穿过层间的信息量最小是应用层和传输层的一个约定本地会话的标识

对于使用面向连接服务(TCP)的应用而言,套接字是4元组的一个具有本地意义的标识

  • 4元组: (源 IP,源 port,目标 IP,目标 port)

  • 唯一的指定了一个会话(2个进程之间的会话关系)o应用使用这个标示,与远程的应用进程通信

  • 不必在每一个报文的发送都要指定这4元组

  • 就像使用操作系统打开一个文件,OS返回一个文件句柄一样,以后使用这个文件句柄,而不是使用这个文件的目录名、文件名

  • 简单,便于管理

image-20211124093510780

穿过层间接口的包括 ICI 和 SDU

UDP socket
  • UDP服务,两个进程之间的通信需要之前无需建立连接
    每个报文都是独立传输的
    前后报文可能给不同的分布式进程

  • 因此,只能用一个整数表示本应用实体的标示
    因为这个报文可能传给另外一个分布式进程·1○穿过层间接口的信息大小最小

  • UDP socket:本IP,本端口

    • 但是传输报文时:必须要提供对方 IP,port
    • 接收报文时:传输层需要上传对方的 IP,port

对于使用无连接服务(UDP)的应用而言,套接字是2元组的一个具有本地意义的标识

  • 2元组: IP,port (源端指定)
  • UDP 套接字指定了应用所在的一个端节点(end point)
  • 在发送数据报时,采用创建好的本地套接字 (标示ID),就不必在发送每个报文中指明自己所采用的 ip 和 port
  • 但是在发送报文时,必须要指定对方的 ip 和 udpport (另外一个段节点)

image-20211124093802473

套接字(Socket)

进程向套接字发送报文或从套接字接收报文

套接字<->门户

  • 发送进程将报文推出门户,发送进程依赖于传输层设施在另外一侧的
    门将报文交付给接受进程
  • 接收进程从另外一端的门户收到报文(依赖于传输层设施)

问题3:如何使用传输层提供的服务实现应用

  1. 定义应用层协议:报文格式,解释,时序等
  2. 编制程序,通过 API 调用网络基础设施提供通信服务传报文,解析报文,实现应用时序等

应用层协议

定义了:运行在不同端系统上的应用进程如何相互交换报文

  • 交换的报文类型:请求和应答报文
  • 各种报文类型的语法:报文中的客个字段及其描述
  • 字段的语义:即字段取值的含义进程何时、如何发送报文及对报文进行响应的规则

应用协议仅仅是应用的一个组成部分
Web应用:HTTP协议,web客户端,web服务器,HTML(超文本标记语言)

公开协议: 由RFC文档定义,允许互操作 如 HTTP, SMTP
专用(私有)协议:协议不公开 如:Skype

Internet 传输层提供的服务

TCP 服务

可靠的传输服务
流量控制:发送方不会淹没接受方
拥塞控制:当网络出现拥 塞时,能抑制发送方
不能提供的服务:时间保证、最小吞吐保证和安全
面向连接:要求在客户端 进程和服务器进程之间建 立连接

UDP 服务

不可靠数据传输
不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立 连接

为什么要有 UDP?

UDP 存在的必要性

  • 能够区分不同的进程,而 IP 服务不能

    • 在 IP 提供的主机到主机端到端功能的基础上,区分了主机的应用进程
  • 无需建立连接,省去了建立连接时间,适合事务性的应用

  • 不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用

    • 因为为了实现可靠性(准确性、保序等),必须付出时间代价(检错重发〉
  • 没有拥塞控制和流量控制,应用能够按照设定的速度发送数据

    • 而在 TCP上 面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一致的,因为有流量控制和拥塞控制

安全 TCP

TCP & UDP

都没有加密;明文通过互联网传输 ,甚至密码

SSL

在TCP上面实现,提供加密的 TCP 连接
私密性
数据完整性
端到端的鉴别

SSL在应用层:应用采用 SSL 库,SSL 库使用 TCP 通信

SSL socket API

应用通过 API 将明文交给 socket,SSL 将其加密在互联网上传输

常见的例子:Https –> Http + SSL(Https 跑在 SSL + TCP 上)

image-20211124100125798

Web and Http

一些术语

  • Web页:由一些对象组成

  • 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等

  • Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)

  • 通过URL对每个对象进行引用
    访问协议,用户名,口令字,端口等;

  • URL 格式

    image-20211125211225105

HTTP 概况

HTTP:超文本传输协议

  • Web 的应用层协议
  • 客户 / 服务器模式
    • 客户: 请求、接收和显示 Web 对象的浏览器
    • 服务器: 对请求进行响应,发送对象的 Web 服务器
  • HTTP 1.0: RFC 1945
  • HTTP 1.1: RFC 2068

使用 TCP:

客户发起一个与服务器的 TCP 连接 (建立套接字) ,端口号为 80 –>
服务器接受客户的 TCP 连接 –>
在浏览器(HTTP客户端) 与 Web 服务器(HTTP 服务器 server)交换 HTTP 报文 (应用层协议报文) –>
TCP 连接关闭

HTTP是无状态的:服务器并不维护关 于客户的任何信息

HTTP 连接

非持久 HTTP:最多只有一个对象在 TCP 连接上发送、下载多个对象需要多个 TCP 连接、HTTP/1.0 使用非持久连接

持久 HTTP:多个对象可以在一个(在客户端和服务器之间的)TCP 连接上传输、HTTP/1.1 默认使用持久连接

响应时间模型

image-20211125212244794

**往返时间 RTT (round-trip time)**:一个小的分组从客户端到服务器,在回到客户端的时间(传输时间忽略)

响应时间:一个 RTT 用来发起 TCP 连接、一个 RTT 用来 HTTP 请求并等待 HTTP 响应、文件传输时间

共:2RTT+ 传输时间

非持久 HTTP 的缺点:

  • 每个对象要2个 RTT
  • 操作系统必须为每个TCP连接分 配资源
  • 但浏览器通常打开并行TCP连接 ,以获取引用对象

持久 HTTP:

  • 服务器在发送响应后,仍保持 TCP 连接
  • 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
  • 客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求

非流水方式的持久 HTTP:

  • 客户端只能在收到前一个响应后才能发出新的请求
  • 每个引用对象花费一个 RTT

流水方式的持久 HTTP:

  • HTTP/1.1 的默认模式
  • 客户端遇到一个引用对象就立即 产生一个请求
  • 所有引用(小)对象只花费一个 RTT 是可能的

HTTP 请求报文

两种类型的 HTTP 报文:请求、响应

HTTP 请求报文:ASCII (人能阅读)

image-20211125213556865

HTTP 请求报文:通用格式

image-20211125213646487

提交表单输入

  1. Post 方式:网页通常包括表单输 入、包含在实体主体 (entity body )中的 输入被提交到服务器
  2. URL 方式:方法:GET、输入通过请求行的 URL 字段上载

HTTP 响应报文

image-20211125213840289

HTTP 响应状态码

位于服务器 → 客户端的响应报文中的首行一些状态码的例子:

  1. 200 OK
    • 请求成功,请求对象包含在响应报文的后续部分
  2. 301 Moved Permanently
    • 请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定客户端软件自动用新的URL去获取对象
  3. 400 Bad Request
    • 一个通用的差错代码,表示该请求不能被服务器解读
  4. 404 Not Found
    • 请求的文档在该服务上没有找到
  5. 505 HTTP version Not supported

用户-服务器状态:cookies

大多数主要的门户网站使 用 cookies 4个组成部分:

  1. 在 HTTP 响应报文中有一个 cookie 的首部行
  2. 在 HTTP 请求报文含有一个 cookie 的首部行
  3. 在用户端系统中保留有一个 cookie 文件,由用户的浏览器管理
  4. 在 Web 站点有一个后端数据库

例子

Susan 总是用同一个 PC 使用 Internet Explore 上网,她第一次访问了一个使用了 Cookie 的电子商务网站,当最初的 HTTP 请求到达服务器时,该 Web 站点 产生一个唯一的 ID,并以此作为索引在它的后端数据库中产生一个项

Cookies: 维护状态

image-20211125214438927

Cookies能带来什么:用户验证、购物车、推荐、用户状态 (Web e-mail)

如何维持状态:协议端节点:在多个事务上 ,发送端和接收端维持状态。cookies: http 报文携带状态信息

Web缓存 (代理服务器)

不访问原始服务器,就满足客户的请求

  • 用户设置浏览器:通过缓存访问 Web
  • 浏览器将所有的 HTTP 请求发给缓存
    • 在缓存中的对象:缓存直接返回对象
    • 如对象不在缓存,缓存请求原始服务器,然后再将对象返回给客户端

缓存既是客户端又是服务器,通常缓存是由 ISP 安装 (大学、公司、居民区 ISP)

使用 Web 缓存带来的好处:1. 降低客户端的请求响应时间。2. 可以大大减少一个机构内部网络与 Internent 接入链路上的流量。3、互联网大量采用了缓存:可以使较弱的 ICP 也能够有效提供内容

缓存示例

假设平均对象大小 = 100 kb,机构内浏览器对原始服务器的平均请求率为 = 15 请求/s,平均到浏览器的速率:1.5 Mbps,机构内部路由器到原始服务器再返回到路由器的的延时( Internet 延时)= 2s,接入链路带宽:1.54 Mbps

假设:平均对象大小 = 100kb、机构内浏览器对原始服务器的 平均请求率为 = 15请求/s,平均到浏览器的速率:1.5Mbps,机构内部路由器到原始服务器 再返回到路由器的的延时 ( Internet 延时)= 2s,接入链路带宽:1.54Mbps。接入链路宽带:1.54 Mbps –> 154 Mbps

结果:LAN 的流量强度 = 15%,接入链路上的流量强度 = 99%、总延时 = LAN延时 + 接入延时 + Internet 延时 = ms + 分 + 2s

代价: 增加了接入链路带宽(非常昂贵!)

排队延迟降低

t (queue) = I/(1 - I) * L / R
I —— 流量强度, L/R —— 一个分组的传输时间排队延迟非常大

缓存例子:安装本地缓存

假设平均对象大小 = 100kb 机构内浏览器对原始服务器的平均请求率为 = 15请求/s 平均到浏览器的速率:1.5Mbps 机构内部路由器到原始服务器再返回到路由器的的延时 (Internet 延时)= 2s,接入链路带宽:1.54Mbps

结果:LAN 利用率: 15% 。接入网络利用率: ?。 总体延迟 = ? How to compute link utilization, delay? 代价: web缓存(廉价!)

计算链路利用率,有缓存的延迟:

  • 假设缓存命中率 0.4,40%请求在缓存中被满足,其他60%的请求需要被原始服务器满足(也就是说重新请求原始服务器发送数据)

  • 接入链路利用率: 60%的请求采用接入链路

  • 进过接入链路到达浏览器的数据速率 = 0.6 * 1.50 Mbps = 0.9 Mbps,利用率= 0.9/1.54 = 0.58

  • 总体延迟:总体延迟 = 0.6 * (从原始服务器获取对象的延迟) + 0.4 * (从缓存获取对象的延迟) = = 0.6 (2.01) + 0.4 (~msecs) = = ~ 1.2 secs

比安装 154Mbps 链路还来得小 (而且比较便宜!)

条件GET方法(对象版本和服务器版本一致性问题)

目标:如果缓存器中的对 象拷贝是最新的,就不要发送对象

缓存器: 在HTTP请求中指 定缓存拷贝的日期 If-modified-since: <date>

服务器: 如果缓存拷贝陈 旧,则响应报文没包含对象: HTTP/1.0 304 Not Modified

FTP*

FTP: 文件传输协议

image-20211128092429764

向远程主机上传输文件或从远程主机接收文件
客户/服务器模式,客户端:发起传输的一方,服务器:远程主机
ftp: RFC 959
ftp 服务器:端口号为21

FTP:控制连接与数据连接分开

FTP 客户端与 FTP 服务器啊通过端口 21 联系,并使用 TCP 为传输协议。客户端通过控制连接获得身份确认。客户端通过控制连接发送命令浏览远程目录。收到一个文件传输命令时,服务器打开一个到客户端的数据连接。一个文件传输完成后,服务器关闭连接。

服务器打开第二个 TCP 数据连接用来传输另一个文件
控制连接:外带(“out of band:)传送
FTP服务器维护用户的状态信息: 当前路径、用户帐户与控制连接对应
有状态的协议

FTP 命令、响应

命令样例

在控制连接上以 ASCII 文本方式传送
USER username
PASS password
LIST:请服务器返回远程主机当前目录的文件列表
RETR filename:从远程主 机的当前目录检索文件 (gets)
STOR filename:向远程主 机的当前目录存放文件 (puts)

返回码样例

状态码和状态信息 (同HTTP)
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file

EMail

**三个主要组成部分: ** 用户代理,邮件服务器,简单邮件传输协议:SMTP

用户代理:又名”邮件阅读器“,撰写、编辑和阅读邮件,如:Outlook、Foxmail。输入和输入邮件保存在服务器上

image-20211128151734152

邮件服务器

邮箱中管理和维护发送给用户的邮件
输出报文队列保持待发送邮件报文
邮件服务器之间的SMTP协议 :发送email报文
客户:发送方邮件服务器
服务器:接收端邮件服务器

EMail: SMTP [RFC 2821] 原理

使用 TCP 在客户端和服务器之间传送报文,端口号为 25
直接传输:从发送方服务器到接收方服务器
传输的3个阶段:握手、传输报文、关闭
命令/相应交互:命令:ASCII 文本;响应:状态码和状态信息
报文必须为 7 位 ASCII 码

举例:Alice 给 Bob 发送报文

Alice 使用用户代理撰写邮件并发送给 bob@someschool.edu。Alice的用户代理将邮件发送到她的邮件服务器;邮件放在报文队列中
SMTP 的客户端打开到 Bob 邮件服务器的 TCP 连接。SMTP 客户端通过 TCP 连接发送 Alice 的邮件
Bob 的邮件服务器将邮件放到 Bob 的邮箱,Bob调用他的用户代理阅读邮件

简单的 SMTP 交互

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP:总结

  • SMTP使用持久连接
  • SMTP要求报文(首部和主体)为7位ASCII编码
  • SMTP服务器使用 CRLF.CRLF 决定报文的尾部

HTTP比较:

  • HTTP:拉(pull)
  • SMTP:推(push)
  • 二者都是ASCII形式的 命令/响应 交互、状态码
  • HTTP:每个对象封装在各自的响应报文中
  • SMTP:多个对象包含在一个报文中

邮件报文格式

image-20211128153744928

报文格式:多媒体扩展

MIME:多媒体邮件扩展(multimedia mail extension), RFC 2045, 2056

在报文首部用额外的行申明MIME内容类型

image-20211128154303599

常用 Base64 对 STMP 的 ASCII 码进行拓展,传输更多内容

Base64 常用于在处理文本数据的场合,表示、传输、存储一些二进制数据,包括 MIME 的电子邮件及 XML 的一些复杂数据。在 MIME 格式的电子邮件中,base64 可以用来将二进制的字节序列数据编码成 ASCII 字符序列构成的文本。使用时,在传输编码方式中指定 base64。使用的字符包括大小写拉丁字母各 26 个、数字 10 个、加号 + 和斜杠 /,共 64 个字符,等号 = 用来作为后缀用途。

邮件访问协议

image-20211128154334007

两推一拉

SMTP: 传送到接收方的邮件服务器
邮件访问协议:从服务器访问邮件

  • POP:邮局访问协议(Post Office Protocol)[RFC 1939]
    • 用户身份确认 (代理<–>服务器) 并下载
  • IMAP:Internet 邮件访问协议(Internet Mail Access Protocol)[RFC 1730]
    • 更多特性 (更复杂)
    • 在服务器上处理存储的报文
  • HTTP:Hotmail , Yahoo! Mail等

POP3协议

用户确认阶段:

image-20211128155613140

客户端命令:user–>申明用户名; pass –> 口令
服务器响应:+OK;-ERR

事务处理阶段,客户端:

image-20211128155647279

list: 报文号列表
retr: 根据报文号检索报文
dele: 删除
quit

POP3

先前的例子使用 “下载并删除”模式。
如果改变客户机,Bob 不能阅读邮件
“下载并保留”:不同客户机上为报文的拷贝
POP3在会话中是无状态的

IMAP

IMAP服务器将每个报文 与一个文件夹联系起来
允许用户用目录来组织 报文
允许用户读取报文组件
IMAP在会话过程中保留 用户状态:
目录名、报文ID与目录名 之间映射

DNS(Domain Name System)

DNS 的必要性

  • IP 地址标识主机、路由器
  • 但 IP 地址不好记忆,不便人类使用(没有意义)
  • 人类一般倾向于使用一些有意义的字符串来标识 Internet 上的设备。如:www.google.com
  • 存在着“字符串”— IP 地址的转换的必要性
  • 人类用户提供要访问机器的“字符串”名称
  • 由 DNS 负责转换成为二进制的网络地址

DNS 系统需要解决的问题

  1. 如何命名设备
    • 用有意义的字符串:好记,便于人类用使用
    • 解决一个平面命名的重名问题:层次化命名
  2. 如何完成名字到 IP 地址的转换
    • 分布式的数据库维护和响应名字查询
  3. 如何维护:增加或者删除一个域,需要在域名系统中做哪些工作

DNS 总体思路和目标

DNS 的主要思路

分层的、基于域的命名机制
若干分布式的数据库完成名字到IP地址的转换
运行在 UDP 之上端口号为 53 的应用服务
核心的 Internet 功能,但以应用层协议实现
在网络边缘处理复杂性 (互联网最核心的功能(DNS)在边缘系统实现的)

DNS 的目的

实现主机名 — IP 地址的转换(name/IP translate) (主要功能/主要目的)
主机别名到 规范名字 的转换:Host aliasing
邮件服务器别名到邮件服务器的 正规名字 的转换:Mail server aliasing
负载均衡:Load Distribution(分配具体的服务器提供服务)

问题1:DNS名字空间(The DNS Name Space)

DNS域名结构

  • 一个层面命名设备会有很多重名

  • NDS采用层次树状结构的命名方法

  • Internet 根被划为几百个顶级域(top lever domains)

    通用的(generic)
    .com、 .edu 、 .gov 、 .int 、 .mil 、 .net 、 .org 、 .firm 、 .hsop 、 .web 、 .arts 、 .rec

    国家的(countries)
    .cn 、 .us 、 .nl 、 .jp

  • 每个(子)域下面可划分为若干子域(subdomains)

  • 树叶是主机

DNS 名字空间

image-20211129213356708

域名(Domain Name)

  • 从本域往上,直到树根

  • 中间使用“.”间隔不同的级别

    • 如:ustc.edu.cn

      ​ auto.ustc.edu.cn

      www.auto. ustc.edu.cn

  • 域的域名:可以用于表示一个域

  • 主机的域名:一个域上的一个主机

  • 域名的管理

    • 一个域管理其下的子域

      如:.jp 被划分为 ac.jp co.jp

      ​ .cn 被划分为 edu.cn com.cn

    • 创建一个新的域,必须征得它所属域的同意

  • 域与物理网络无关

    • 域遵从组织界限,而不是物理网络

      一个域的主机可以不在一个网络;一个网络的主机不一定在一个域

    • 域的划分是逻辑的,而不是物理的

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

一个名字服务器的问题

  • 可靠性问题:单点故障
  • 扩展性问题:通信容量
  • 维护问题:远距离的集中式数据库

区域(zone)

  • 区域的划分有区域管理者自己决定
  • 将 DNS 名字空间划分为互不相交的区域,每个区域都是树的一部分
  • 名字服务器:
    • 每个区域都有一个名字服务器:维护着它所管辖区域的权威信息 (authoritative record)
    • 名字服务器允许被放置在区域之外,以保障可靠性

名字空间划分为若干区域

image-20211129215524387

权威DNS服务器:组织机构的DNS服务器, 提供组织机构服务器(如 Web和mail)可访问的主机和IP之间的映射
组织机构可以选择实现自己维护或由某个服务提供商来维护

TLD 服务器

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

Network solutions 公司维护 com TLD 服务器

Educause公司维护edu TLD服务器

区域名字服务器维护资源记录

资源记录(resource records)

作用:维护 域名-IP地址(其它)的映射关系

位置:Name Server的分布式数据库中

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

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

DNS 记录

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

RR 格式:(name, value, type, ttl)

Type Name Value
A Name 为主机 Value 为 IP 地址
NS Name 域名(如foo.com) Value 为 为该域名的权威服务器的域名
CNAME Name 为规范名字的别名 Value 为规范名字
MX ————————– Value为name对应的邮件服务器的名字

TTL:生存时间,决定了资源记录应当从缓存中删除的时间

信息1 (叫什么)
TYPE = NS Name放的是子域的名字
Value 子域名字服务器(权威 DNS 服务器)的名字

信息2 (在哪)
Type = A Name放的是名字(子域的名字)
Value 对应服务器的 IP 地址

DNS 大致工作过程

一台设备上网必备的IP信息
我的IP地址 我的子网掩码 我的local name serve 我的default getway(路由器)

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

image-20211129221054857

并不严格属于层次结构
每个ISP (居民区的ISP、公司、大学)都有一 个本地DNS服务器
也称为“默认名字服务器”
当一个主机发起一个DNS查询时,查询被送到 其本地DNS服务器
起着代理的作用,将查询转发到层次结构中

名字服务器(Name Server)

名字解析过程
目标名字在Local Name Server中
情况1:查询的名字在该区域内部
情况2:缓存(cashing)

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

递归查询

名字解析负担都 放在当前联络的 名字服务器上
问题:根服务器 的负担太重
解决: 迭代查询 (iterated queries)

image-20211129221409344

迭代查询

主机cis.poly.edu 想知道主机 gaia.cs.umass.edu 的 IP 地址
根(及各级域名)服务器返回的不是查询结果,而 是下一个 NS 的地址
最后由权威名字服务器给出解析结果
当前联络的服务器给出可以联系的服务器的名字
“我不知道这个名字,但可以向这个服务器请求

image-20211129221420914

DNS 协议、报文

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

image-20211129221439349

image-20211129221501466

提高性能:缓存

一旦名字服务器学到了一个映射,就将该映射 缓存起来
根服务器通常都在本地服务器中缓存着
使得根服务器不用经常被访问
目的:提高效率
可能存在的问题:如果情况变化,缓存结果和 权威资源记录不一致
解决方案:TTL(默认2天)

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

  • 在上级域的名字服务器中增加两条记录,指向这个新增的子域的域名和域名服务器的地址
    (Type = NS、 Type = A 相当于指针)

  • 在新增子域的名字服务器上运行名字服务器,负责本域
    的名字解析:名字->IP地址
    例子:在com域中建立一个“Network Utopia”

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

    • 需要向该机构提供权威 DNS 服务器(基本的、和辅助的)的名字和IP地址
    • 登记机构在com TLD 服务器中插入两条 RR 记录:
      ( networkutopia.com,dns1.networkutopia.com,NS )( dns1.networkutopia.com,212.212.212.1,A)
  • 在networkutopia.com的权威服务器中确保有

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

P2P 应用

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

例如(括号里的为实例):文件分发 (BitTorrent)、流媒体 (KanKan)、VoIP (Skype)

文件分发: C/S vs P2P

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

C/S 模式

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

  • 发送一个copy: F/u(s)(上载)
  • 发送N个copy: NF/u(s) (上载)

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

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

采用 C/S 方法 将一个 F 大小的文件 分发给 N 个客户端耗时 D(c/s) >= max{ NF / u(s)(随着 N 线性增长 ),F / d(min) }(瓶颈却决于服务器的性能和客户端性能的相对强弱)

文件分发时间: P2P模式

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

  • 发送一个拷贝的时间:F/u(s)(上载)

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

  • 最小下载带宽客户单耗时: F/d(min)(下载)

客户端: 所有客户端总体下载量 NF

  • 最大上载带宽是:u(s)(服务器的)+ ∑u(i) (所有客户端的)(上载)
  • 除了服务器可以上载,其他所有的 peer 节点都可以上载

采用P2P方法 将一个F大小的文件 分发给N个客户端耗时 D(p2p) > max{ F / u(s), F / d(min),NF / (u(s) + ∑u(i)) }

C/S vs. P2P: 例子

image-20211130162013544

C/S 线性
P2P 非线性, 性能高可拓展性强, 难管理(动态性强)

非结构化 P2P 任意连接
DHT 结构化 P2P 如:环形、树 节点哈希 内容哈希, 按一定规律存内容

P2P 文件共享

例子
Alice 在其笔记本电脑上运行 P2P 客户端程序间歇性地连接到 Internet,每次从其 ISP 得到新的 IP 地址。请求“双截棍.MP3”应用程序显示其他有“ 双截棍.MP3” 拷贝的对等方

Alice 选择其中一个对等方, 如Bob。文件从Bob’s PC传送到 Alice的笔记本上:HTTP 当 Alice下载时,其他用户也可以从Alice处下载 Alice 的对等方既是一个 Web 客户端,也是一个瞬时 Web 服务器

所有的对等方都是服务器 –> 可扩展性好!

两大问题

  1. 如何定位所需资源
  2. 如何处理对等方的加入与离开

可能的方案

  1. 集中 2. 分散 3. 半分散

P2P:集中式目录

最初的“Napster”设计

  1. 当对等方连接时,它告知中心服务器: IP地址、内容
  2. Alice查询 “双截棍 .MP3”
  3. Alice 从 Bob处请求文件

image-20211130164535185

集中式目录中存在的问题

  1. 单点故障 2. 性能瓶颈 3. 侵犯版权

文件传输是分散的,而定位内容则是高度集中的

查询洪泛:Gnutella(完全分布式)

特点:

全分布式
没有中心服务器
开放文件共享协议
许多Gnutella客户端 实现了Gnutella协议
类似HTTP有许多的 浏览器

覆盖网络:图

如果X和Y之间有一个 TCP连接,则二者之间存在一条边
所有活动的对等方和边就是覆盖网络
边并不是物理链路
给定一个对等方,通常 所连接的节点少于10个

泛洪查询 flooding

我的客户端向所有邻居发出查询 所有邻居的客户端向其邻居发出查询 …
拥有资源的节点通过反向的方法将查询的结果发回来

我的客户端就知道那个节点有资源——解决目录的问题——再向拥有资源的节点发出请求,得到资源

image-20211130165050278

Gnutella:对等方加入(网络的建立)

  1. 对等方X必须首先发现某些已经在覆盖网络中的其他对 等方:使用可用对等方列表 自己维持一张对等方列表(经常开机的对等方的IP、死党列表) 联系维持列表的Gnutella站点
  2. X接着试图与该列表上的对等方建立TCP连接,直到与某个对等方Y建立连接
  3. X向Y发送一个Ping报文,Y转发该Ping报文
  4. 所有收到Ping报文的对等方以Pong报文响应 IP地址、共享文件的数量及总字节数
  5. X收到许多Pong报文,然后它能建立其他TCP连接

利用不匀称性:KaZaA(混合体)

每个对等方要么是一个组长,要么隶属于一个组长

  • 对等方与其组长之间有 TCP连接
  • 组长对之间有TCP连接

组长跟踪其所有的孩子的内容

组长与其他组长联系

  • 转发查询到其他组长
  • 获得其他组长的数据拷贝

image-20211130165244625

KaZaA:查询

每个文件有一个散列标识码(唯一Hash,上载时赋予)和一个描述符
客户端向其组长发送关键字查询
组长用匹配(描述)进行响应:
对每个匹配:元数据、散列标识码和IP地址
如果组长将查询转发给其他组长,其他组长也 以匹配进行响应
客户端选择要下载的文件
向拥有文件的对等方发送一个带散列标识码的 HTTP请求

Kazaa小技巧

请求排队

  • 限制并行上载的数量
  • 确保每个被传输的文件从上载节点接收一定量的带宽

激励优先权

  • 鼓励用户上载文件
  • 加强系统的扩展性

并行下载

  • 从多个对等方下载同一个文件的不同部分
    • HTTP的字节范围首部
    • 更快地检索一个文件

Distributed Hash Table (DHT)

哈希表 、DHT 方案、 环形 DHT 以及覆盖网络 Peer 波动

(实际的例子)P2P文件分发: BitTorrent

文件被分为一个个块 256KB 每个节点有一个bit map(hash),用map标记是否具备,有则标识为1否则为0

网络中的这些peers发送接收文件块,相互服务

image-20211130165643404

Peer 加入torrent:
一开始没有块(吸血鬼),但是将会通 过其他节点处累积文件块
向跟踪服务器注册,获得 peer节点列表,和部分peer 节点构成邻居关系 (“连接 ”)
当peer下载时,该peer可以同时向其他节点提供上载服务
Peer可能会变换用于交换块的peer节点
扰动churn: peer节点可能会上线或者下线
一旦一个peer拥有整个文件(种子),它会(自私的)离开或者保留(利他主义)在torrent中

BitTorrent: 请求,发送文件块

请求块:
在任何给定时间,不同 peer节点拥有一个文件块 的子集
周期性的,Alice节点向 邻居询问他们拥有哪些块 的信息
Alice向peer节点请求它 希望的块,稀缺的块(稀缺优先,对集体有利)

1、(集体提出)客户端优先请求稀缺的(稀缺优先,对集体有利)
2、(集体定的规则)优先向提供服务好的客户端服务(个人利益与集体利益绑定)
3、(造成个人遵守)客户端优先请求稀缺的 (利他等于利己)

发送块:一报还一报 titfor-tat
Alice向4个peer发送块,这些块向它自己提供最大带宽的服务
其他peer被Alice阻塞 (将不会 从Alice处获得服务)
每10秒重新评估(谁对它好)一次:前4位
每个30秒:随机选择其他peer 节点,向这个节点发送块
“优化疏通” 这个节点
新选择的节点可以加入这个top 4

(1) Alice “优化疏通” Bob
(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice
(3) Bob 变成了Alice的前4提供者

更高的上载速率: 发现更好的交易伙伴,获得更快的文件传输速率!