计算机网络基础知识之应用层篇
目录
一、应用层协议原理编辑
1.网络应用程序体系结构
1）客户-服务器体系结构（client- server architecture）
2）对等体体系结构（p2p architecture）
3） C/S和P2P体系结构的混合体
2.进程通信
3.套接字
4.进程寻址
5.TCP&UDP socket
1）TCP socket
2）UDP socket
6.应用层协议
1）概述
2）可提供的运输服务
3） Internet传输层提供的服务
7.补充说明
1）UDP存在必要性
2）安全TCP
二、Web和HTTP
1.HTTP概述
2.HTTP连接
1）非持久HTTP
2）持久HTTP
3.HTTP报文
1）HTTP请求报文
2）请求报文格式
3）HTTP响应报文
４）HTTP响应状态码
2）Cookie维护状态
3）隐私问题
5.Web缓存
1）为什么使用Web缓存器
6.条件Get方法
三、电子邮件
1.邮件服务器
2.SMTP
3.HTTP比较
4.邮件报文格式
5.邮件访问协议
1）pop
2）IMAP
四、DNS（因特网的目录服务）
1.DNS必要性
2.DNS系统需要解决的问题
3.DNS总体思路和目标
1）DNS的主要思路
2）DNS主要目的
3）运作过程
5.分布式、层次数据库
1）单个DNS服务器的问题
2）三类DNS服务器
3）本地DNS服务器
4）递归查询&迭代查询
6.DNS缓存
7.DNS域名
1）结构
2）域名管理
3）域与物理网络无关
4）区域
8.DNS记录与报文
1）记录
2）DNS协议
3）报文
9.攻击DNS
1）DDoS 攻击
2）重定向攻击
五、p2p （peer to pee）
1.纯p2p架构
2.文件分发：C/S vs P2P
1）C/S模式
2）p2p模式
3）函数图
3.BitTorrent
1）BitTorrent协议特点
4.Gnutella协议编辑
5.KaZaA协议
1）KaZaA协议概述
2）KaZaA协议查询
3）KazaA补充说明
六、CDN（Content Distribution Network）
1.DASH（Dynamic adaptive Streaming over HTTP）
2.内容分发网（CDN）
1）两种不同的服务器安置原则：
2）用户访问
3）流程图：
一、应用层协议原理
研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通过进程通信的程序
- 在Web应用程序中，有两个相互通信的不同程序: 一个是运行在用户主机上的浏览器程序
- 在p2p文件共享系统中，另一个参与文件共享的社区中的每台主机中都有一个程序。
网络核心设备并不在应用层上起作用，而仅网络层及下面层次起作用, 特别是在网络层及下面层次其作用.。这种基本设计，即将应用软件限制在端系统的方法，促进了大量网络应用程序的迅速研发和部署
1.网络应用程序体系结构
应用程序的体现结构明显不同于网络的体系结构。网络体系结构是固定的，并且为应用程序提供了特定的服务集合 。应用程序体系结构，有程序研发者设计，规定了如何在各种端系统上组织该应用程序。
目前的两种主流体系与一种混合体：
- 客户-服务体系结构（C/S）
- 对等体系结构（p2p）
- C/S与P2P混合体
1）客户-服务器体系结构（client- server architecture）
服务器：
- 一直运行
C/S模式
- 固定的IP地址和周知的端口号（约定）
- 扩展性: 数据中心进行扩展、扩展性差
客户端
- 主动与服务器通信
- 与互联网有间歇性的链接
- 可能是动态IP地址
- 不直接与其他客户端通信
2）对等体体系结构（p2p architecture）
- （几乎）没有一直运行的服务器
p2p模式
- 任意端系统间可以进行通信
- 每一个节点即使客户端又是服务器
- 自扩展性：新的peer节点带来的新的服务能力，当然也带来新的服务请求
- 参与的主机间歇性链接且可以改变IP地址
- 难以管理
- 例子：迅雷、Gnutella
3） C/S和P2P体系结构的混合体
用两个例子说明：
Napster〔旧时一项免费因特网音乐下载服务,1999年被法庭判令关闭〕
- 文件搜索：集中
- 任意Peer节点之间
即时通信
- 在线检测：集中
- 当用户上线时，想中心服务注册其IP地址
- 当用户与中心服务器联系，以找到其在线好友的位置
- 两个用户之间聊天：P2P
2.进程通信
进程：在主机上运行的应用程序
- 在同一个主机内，使用进程间通信机制通信（操作系统定义）
- 不同主机，通过交换报文（Message）来通信
3.套接字
从一个进程向另一个进程发送报文必须通过下面层的网络。进程之间通过一个称为：套接字（socket）的软件接口向网络发送报文和从网络接收报文。
Socket可以看成在两个进程进行通讯连接中的一个端点，一个进程将一段信息写入Socket中，该Socket将这段信息发送给另外一个Socket套接字是应用程序进程和运输层协议之间的接口，在发送端的应用程序将报文推进该套接字。在该套接字的另一端，运输层协议负责从接收进程的套接字得到该报文
应用程序开发者对于运输的控制权仅限于：①选择传输层协议 ②设定传输层参数，例如最大缓存和最大报文段长度
4.进程寻址
进程为了接收报文，必须有一个标示，即：SAP（发生也需要标示）
- 主机：唯一的32位IP地址
- 所采用的传输层协议：TCP or UDP
- 进序运行端口号（Port Numbers）
5.TCP&UDP socket
1）TCP socket
- 套接字是四元组的一个具有本地意义的标示
- 四元组：(源IP，源port，目标IP，目标port)
- 不必每个报文的发送都要指定这四元组，使用这个标示就可以找到对应数据，就像使用操作系统打开一个文件，OS返回一个文件句 柄一样，以后使用这个文件句柄，而不是使用这个文件 的目录名、文件名
2）UDP socket
- 用一个整数表示本应用实体的标示
- 传输报文时：必须提供对方IP，port
6.应用层协议
1）概述
- 应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文，
- 交换的报文类型，例如请求报文和响应报文
- 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的
- 字段的语义，即这些字段中的信息的行业
- 确定一个进程何时以如何发送报文，对报文进行响应的规则
- 应用层协议仅仅是应用的一个组成部分
2）可提供的运输服务
数据丢失率
由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。当运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。
定时
运输层协议能提供定时保证，如发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。这种服务队交互式实时应用程序具有很大的吸引力，如网络电话、网络交互游戏等，这些应用为了有效性而要求数据交付有严格的时间限制。
吞吐量
在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付的比特速率。因为其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。这就要求运输层协议能够以某种特定的速率提供确保的可用吞吐量，及吞吐量服务。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是至少为r比特/秒。
安全性
运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在数据交付给接收进程之前解密这些数据。运输协议还能提供机密性以外的其他安全性服务，包括数据完整性和端点鉴别。
3） Internet传输层提供的服务
TCP服务
- 可靠的传输服务
- 流量控制：发送方不会淹没接收方
- 阻塞控制：当网络出现拥塞时，能抑制发送方
- 不能提供的服务：时间保证、最小吞吐保证和安全
- 面向连接：要求在客户端进程和服务进程之间建立来连接
UDP服务
- 不可靠的数据传输
- 不提供的服务：可靠流量控制、拥塞控制、时间、宽带保证、建立连接
7.补充说明
1）UDP存在必要性
- 无需建立连接：省去了建立连接（三次握手）的时间，适合事务性的应用
- 不做可靠性的工作：省去检查重发的工作时间，适合那些对实时性要求比较高而对正确性要求不高的应用
- 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
2）安全TCP
二、Web和HTTP
web是由一些对象组成的，这些对象可以是HTML文件、JPEG图像、Java程序等。含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（连接），通过URL对每个对象进行引用
URL格式：访问协议，用户名，口令字，端口等
1.HTTP概述
HTTP使用TCP作为它的支撑运输协议（而不是UDP上运行)。HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP
HTTP是一个无状态协议，HTTP服务器不保存任何客户的任何信息
2.HTTP连接
1）非持久HTTP
最多只能一个对象在TCP连接上发送，下载多个对象需要多个来连接
下面实例流程
响应时间模型 ：
往返时间RTT（round-triptime）：一个小的分组从客户端到服务器，在回到客户端到服务器。
响应时间：一个RTT用来发起TCP连接，一个RTT用来HTTP请求并等待HTTP响应，文件传输时间
缺点：
- 每个对象要2个RTT
- 操作系统必须位每个TCP连接分配资源
- 浏览器通常打开并行TCP连接，以获得引用对象
2）持久HTTP
多个对象可以在一个（客户端和服务器之间的）TCP连接上传输
特点
- 服务器再发送响应之后，仍然能保持TCP连接
- 非流水方式的持久HTTP
- 客户端只能在收到前一个响应后才能发出新的请求
- 每个引用对象花费一个RTT
- 流水方式的持久HTTP
- HTTP/1.1的默认模式
- 客户端遇到一个引用对象就立即产生一个请求
- 所有引用（小）对象只花费一个RTT是可能的
- 在相同客户端和服务器之后的后续请求和响应报文通过相同的连接进行传送
- 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
3.HTTP报文
两种类型的HTTP报文：请求、响应
1）HTTP请求报文
首部行内容含义：
- Host: 对象所在主机
- Connection: close说明浏览器告诉服务器在发送完被请求的对象后就关闭链接
- User-agent: 指明用户代理，即向服务器发送请求的浏览器的类型
- accept－language：语言版本，英语......
2）请求报文格式
3）HTTP响应报文
首部行内容含义：
- Connection close：发完后关闭TCP连接
- Date：指示服务器产生并发送响应报文的日期和时间
- Server：产生报文的服务器
- Last－Modified：指示了对象创建或者最后修改的日期和时间
- Content－Length：报文长度
- Content-Type：指示实体体的对象类型，例子中是HTML文本
４）HTTP响应状态码
200 OK
- 请求成功，请求对象包含在响应报文的后续部分
301 Moved Permanently
- 请求的对象已经被永久转移了；新的URL在响应报文的Location；
- 首部行中指定客户端软件自动用新的URL去获取对象
400 Bad Request
- 一个通用的差错代码，表示该请求不能被服务器解读
404 Not Found
- 请求的文档在该服务上没有找到
505 HTTP Version Not Supported
- 服务器不支持请求报文使用HTTP协议版本
4.用户－服务器的交互：cookie
前面提到HTTP服务器是无状态的，也就是不保存客户信息。为了能让Web识别到用户或则是把内容和用户身份联系起来。为此，HTTP使用了cookie。
1）cookie技术组件
- 在HTTP响应报文中有一个cookie的首部行
- 在HTTP请求报文含有一个cookie的首部行
- 在用户端系统中保留有一个cookie文件，由用 户的浏览器管理
- 在Web站点有一个后 端数据库
2）Cookie维护状态
协议端节点：在多个事务上发送端和接收端维持状态cookies: http报文携带状态信息
例子：
Susan总是用同一个PC使用Internet Explore上网，她第一次访问了一个用了Cookie的电子商务网站。当最初的HTTP请求到达服务器时，该Web站点产生一个唯一的ID，并以此作为索引在它的后端数据库中产生一个项
图示：
3）隐私问题
在获取便利的同时，也避免不了隐私问题。站点允许知道用户信息，使用重定向和cookie的搜索引擎还能找到用户更多的信息。
5.Web缓存
Web缓存器也叫做代理服务器，顾名思义，就是用来代初始服务器处理事务的。Web缓存器又自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。
- 用户设置浏览器通过缓存访问Web。
- 浏览器将所有的HTTP请求发给缓存
- 在缓存中的对象：缓存之间返回
- 如果对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端
1）为什么使用Web缓存器
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与Internent接入链路上的流量
- 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容
6.条件Get方法
尽管高速缓存能减少用户感受到的响应时间，但也引入另一个问题，即存放的缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。HTTP协议的条件GET方法，可以允许缓存器证实它的对象是最新的
请求报文使用GET方法，并且请求报文中包含一个“if-modified-since：” 首部行。那么这个请求报文就是一个条件GET请求报文。
当请求报文包含这条语句时，到达缓冲区，缓冲区会把其中的GET首部行、Host首部行、if-modified-since首部行，报装成请求报文发送到服务器端进行对象求证，假如对象没有改变，则回一个响应报文包含HTTP版本：304 Not Modified 首部行、Date：首部行、Server：首部行，不返回对象，因为对象没有更新，发了也是占用带宽，相反，缓存器的对象已经陈旧，服务器响应报文会携带新对象
三、电子邮件
1.邮件服务器
- 邮箱中管理和维护发送给用户的邮件
- 客户：发送方邮件服务器
- 服务器：接收端邮件服务器
2.SMTP
- 使用TCP在客户端和服务器之间传送报文，端口号为25
- 持久链接
- 直接传输：从发送方服务器到接收方服务器
- 传输的3个阶段
- 握手
- 传输报文
- 关闭
- 命令/响应交互
- 命令：ASCII文本
- 响应：状态码和状态信息
- 报文必须为7位ASCII码
3.HTTP比较
- HTTP：拉（pull）即：从服务器中拉去信息
- SMTP：推（push）即：发送端将信息推进接收端
- 二者都是ASCII形式的命令/ 响应交互、状态码
- HTTP：每个对象封装在各自的响应报文中
- SMTP：多个对象包含在一个报文中
4.邮件报文格式
SMTP：交换email报文的协议RFC 822: 文本报文的标准：
- 首部行：如,
- To:
- From:
- Subject:
- 与SMTP命令不同 ！
- 主体
- 报文，只能是ASCII码字符
5.邮件访问协议
- SMTP: 传送到接收方的邮件服务器
- 邮件访问协议：从服务器访问邮件
- POP：邮局访问协议（Post Office Protocol）[RFC 1939]
- 用户身份确认 (代理<-->服务器) 并下载
- IMAP：Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]
- 更多特性 (更复杂)
- 在服务器上处理存储的报文
- HTTP：Hotmail , Yahoo! Mail等
- 方便
1）pop
用户确认阶段
- 客户端命令：
- user: 申明用户名
- pass: 口令
- 服务器响应
- +OK
- -ERR
事物处理阶段, 客户端：
- list: 报文号列表
- retr: 根据报文号检索报文
- dele: 删除
- quit
访问模式：本地管理文件夹
- 下载并删除：删除后其他设备就无法访问
- 下载并保留：方便不同机器访问下载 ）
会话无状态
2）IMAP
四、DNS（因特网的目录服务）
域名系统（Domain Name System,DNS）是一种能够进行主机名到IP地址转换的目录服务
1.DNS必要性
- IP地址标识主机、路由器
- 但IP地址不好记忆，不便人类使用(没有意义)
- 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
- 例如：[email protected] 所在的邮件服务器www.ustc.edu.cn 所在的web服务器
- 存在着“字符串”—IP地址的转换的必要性
- 人类用户提供要访问机器的“字符串”名称
- 由DNS负责转换成为二进制的网络地址
2.DNS系统需要解决的问题
问题1：如何命名设备用有意义的字符串：好记，便于人类用使用解决一个平面命名的重名问题：层次化命名问题2：如何完成名字到IP地址的转换分布式的数据库维护和响应名字查询问题3：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作
3.DNS总体思路和目标
1）DNS的主要思路
- 分层的、基于域的命名机制
- 若干分布式的数据库完成名字到IP地址的转换
- 运行在UDP之上端口号为53的应用服务
- 核心的Internet功能，但以应用层协议实现
- 在网络边缘处理复杂性
2）DNS主要目的
- 实现主机名-IP地址的转换(name/IP translate)
- 其它目的
- 主机别名到规范名字的转换：Host aliasing
- 一台机器可能有一个或者多个别名，用户可以调用DNS来获取其规范主机名以及IP地址
- 邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing
- 负载均衡：Load Distribution
3）运作过程
假如客户端请求URL：www.someschool.edu/index.html，为了使用户的主机能够将一个HTTP请求报文发送到Web服务器www.someschool.edu，用户必须得到该主机的地址，将会进行如下操作
- 同一台用户主机上运行这DNS应用的客户端。
- 、浏览器从上述URL中抽取出主机名，www.someschool.edu，并将这台主机主机名传输DNS应用的客户端
- DNS客户向DNS服务器发送一个包含主机名的请求
- DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址
- 一旦浏览器接收来自DNS的该IP地址，它能够向位于IP地址80 端口的HTTP服务器进程发起一个TCP连接
在这个例子中，我们可以看到DNS给使用它的因特网应用带来了额外的时延。幸运的是，想获得的IP地址通常就缓存在“附件的”DNS服务器中，这有助于减少DNS的网络流量和DNS的平均时延
5.分布式、层次数据库
为了处理扩展问题，DNS使用了大量的DNS服务器，它们以层次的方式组织，并且分布在全世界范围，没有一台DNS服务器拥有因特网上所以主机映射。相反，这些映射分布在所有的DNS服务器上
1）单个DNS服务器的问题
- 可靠性问题：单点故障->如果该DNS服务器崩溃，整个因特网随之瘫痪
- 扩展性问题：通信容量->单个DNS服务器不得不处理所有的DNS查询
- 维护问题：远距离的集中式数据库->单个DNS为所有因特网主机保留记录，，使得中央数据库十分庞大
基于以上问题，DNS实际上使用了分布式数据库，也就是局部和总体的概念
2）三类DNS服务器
- 根DNS服务器：根DNS服务器提供TLD服务器的IP地址
- 顶级DNS服务器（TLD ）：负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）
- 权威DNS服务器：在因特网上具有公共可访问主机（如Web服务器和邮件优秀服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。
为了理解三种类型的服务器之间的交互，我们举个例子（在无本地DNS服务器的情况下）
假定一个 DNS 客户要决定主机名 www . amazon . com 的 IP 地址。粗略说来，将发生下列事件。客户首先与根服务器之一联系，它将返回顶级域名 com 的 TLD 服务器的地址。该客户则与这些 TLD 服务器之一联系，它将为 amazon . com 返回权威服务器的 IP 地址，最后，该客户与 amazn . com 权威服务器之一联系，它为主机名 www . amazon . com 返回其 IP 地址。
3）本地DNS服务器
严格来说，本地DNS服务器不属于该服务器的层次结构，但是它对DNS层次结果是至关重要
当主机与某个 ISP 连接时，该 ISP 提供一台主机的 IP 地址，该主机具有一台或多台其本地 DNS 服务器的 IP 地址。通过访问 Windows 或 UNIX 的网络状态窗口，用户能够容易地确定他的本地 DNS 服务器的 IP 地址。主机的本地 DNS 服务器通常“邻近”本主机。
我们来看一个简单的例子，该例子是建立在本地DNS服务器没有缓存的情况下运行
假设主机 cis . poly . edu 想知道主机 gaia . cs . umass . edu 的 IP 地址。同时假设纽约大学（ NYU ）的 cis . poly . edu 主机的本地 DNS
服务器为 dns . ploy . edu ，并且 gaia . cs . umass . edu 的权威 DNS 服务器为 dns . umass . edu 。如图2-18所示，主机 cse . nyu . edu 首先向它的本地 DNS 服务器 dns . ploy . edu发送一个 DNS 查询报文。该查询报文含有被转换的主机名 gaia . cs . umass . edu 。本地 DNS 服务器将该报文转发到根 DNS 服务器。该根 DNS 服务器注意到其 edu 前缀并向本地 DNS 服务器返回负责 edu 的 TLD 的 IP 地址列表。该本地 DNS 服务器则再次向这些 TLD 服务器之一发送查询报文。该 TLD 服务器注意到 umass . edu 前缀，并用权威 DNS 服务器的 IP 地址进行响应，该权威 DNS 服务器是负责马萨诸塞大学的 dns . umass . edu 。
最后，本地 DNS 服务器直接向 dns . umass . edu 重发查询报文，dns.umass.edu 和 gaia.cs.umass.edu的IP地址进行响应。
在本例中，为了获得一台主机名的映射，共发送了8份报文：四份查询报文和四份回答报文。后面将结束利用DNS缓存来减少这种查询流量的方法
4）递归查询&迭代查询
上面例子中，从cie . poly . edu 到dns . ploy . edu发出 的查询都是递归查询，其余3个查询都是迭代查询，前者因为该查询以自己的名义请求dns . ploy . edu来获得该映射，后者因为所有回答都是直接给出目标IP地址
递归查询面临的问题：
名字解析负担都 放在当前联络的名字服务器上问题：根服务器 的负担太重
迭代查询：
主机cis.poly.edu 想知道主机 gaia.cs.umass.edu的IP地址根（及各级域名）服务器 返回的不是查询结果，而 是下一个NS的地址，最后由权威名字服务器给 出解析结果，当前联络的服务器给出可以联系的服务器的名字 ，类似于“我不知道这个名字，但可以向这个服务器请求”
迭代与递归结合：
6.DNS缓存
实际上，为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术。在一个请求链中，当某DNS服务器接收一个DNS回答（例如：包含某主机到IP地址的映射）时，它能将映射缓存到本地存储器中。
如果在DNS服务器中缓存了一台主机名/IP地址对，另一台对相同主机名的查询到达该DNS服务器时，该DNS服务器就能够提供所要求的的IP地址，即使它不是主机名的权威服务器。由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间（通常被设置为两天后）后将丢弃缓存的信息。
事实上，因为缓存，除了少数DNS查询以外，根服务器都被绕过了
7.DNS域名
1）结构
- 一个层面命名设备会有很多重名
- NDS采用层次树状结构的 命名方法
- Internet 根被划为几百个顶级域(top lever domains)
- 通用的(generic)
- .com; .edu ; .gov ; .int ; .mil ; .net ; .org .firm ; .hsop ; .web ; .arts ; .rec ;
- 国家的(countries) .cn ; .us ; .nl ; .jp
- 每个(子)域下面可划分为若干子域(subdomains)
- 树叶是主机
从本域往上，直到树根中间使用“.”间隔不同的级别 例如：ustc.edu.cn、 auto.ustc.edu.cn、 www.auto. ustc.edu.cn域的域名：可以用于表示一个域主机的域名：一个域上的一个主机
2）域名管理
- 一个域管理其下的子域
- .jp 被划分为 ac.jp co.jp
- .cn 被划分为 edu.cn com.cn
- 创建一个新的域，必须征得它所属域的同意
3）域与物理网络无关
- 域遵从组织界限，而不是物理网络
- 一个域的主机可以不在一个网络
- 一个网络的主机不一定在一个域
- 域的划分是逻辑的，而不是物理的
4）区域
- 区域的划分有区域管理者自己决定
- 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
- 名字服务器：
- 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息(authoritative record)
- 名字服务器允许被放置在区域之外，以保障可靠性
8.DNS记录与报文
1）记录
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（Resource Record）,RR提供了主机名到IP地址的映射
- 资源记录(resource records)
- 作用：维护 域名-IP地址(其它)的映射关系
- 位置：Name Server的分布式数据库中
- RR格式: (name, value, type, ttl)
- name: 主机名
- Value 值：可以是数字，域名或ASCII串
- Type 类别：资源记录的类型—见下页Ttl:
- time to live : 生存时间，决定了资源记录应当从缓存中删除的时间
2）DNS协议
DNS协议：查询和响应报文的报文格式相同
3）报文
报文格式如下：
9.攻击DNS
1）DDoS 攻击
- 对根服务器进行流量轰炸攻击：发送大量ping
- 没有成功
- 原因１：根目录服务器配置了流量过滤器，防火墙
- 原因２：Local DNS 服务器缓存了TLD服务器的IP地址, 因此无需查询根服务器
- 向TLD服务器流量轰炸攻击：发送大量查询
- 可能更危险
- 可能效果一般，大部分DNS缓存了TLD
2）重定向攻击
- 中间人攻击
- 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点
- DNS中毒
- 发送伪造的应答给DNS服务器，希望它能够缓存这个虚假的结果
- 技术上较困难：分布式截获和伪造利用DNS基础设施进行DDoS
- 伪造某个IP进行查询， 攻击这个目标IP
- 查询放大，响应报文比查询报文大
- 效果有限
五、p2p （peer to pee）
1.纯p2p架构
- 没有（或极少）一直运行的服务器
- 任意端系统都可以直接通信
- 利用peer的服务能力
- Peer节点间歇上网，每次IP地址都有可能变化
2.文件分发：C/S vs P2P
1）C/S模式
服务器传输： 都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝:
- 发送一个copy: F/us
- 发送N个copy： NF/us
客户端: 每个客户端必须下载一个文件拷贝
- dmin = 客户端最小的下载速率
- 下载带宽最小的客户端下载的时间：F/dmin
2）p2p模式
服务器传输： 最少需要上载一份拷贝
- 发送一个拷贝的时间：F/u
客户端: 每个客户端必须下载一个拷贝
- 最小下载带宽客户单耗时：:F/dmin
客户端: 所有客户端总体下载量NF
- 最大上载带宽是：us + Sui
- 除了服务器可以上载，其他所有的peer节点都可以上载
3）函数图
3.BitTorrent
BitTorrent 是一种用于文件分发的流行P2P协议 。用 BitTorrent 的术语来讲，参与一个特定文件分发的所有对等方的集合被称为一个洪流（ torrent )。在一个洪流中的对等方彼此下载等长度的文件块（ chunk )，典型的块长度为256KB。
当一个对等方首次加人一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。
当它下载块时，也为其他对等方上载了多个块。一但某对等方获得了整个文件，它也许（自私地）离开洪流，或（大公无私地）留在该洪流中并继续向其他对等方上载块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加人该洪流中。
每个洪流具有一个基础设施节点，称为追踪器（ tracker )。当一个对等方进入人某洪流时，它向追踪器注册自已，并周期性地通知追踪器它仍在该洪流中。以这种式，追踪器跟踪参与在洪流中的对等方。
1）BitTorrent协议特点
下面以一个例子说明BitTorrent协议的特点：
Peer加入torrent:
- 一开始没有块，但是将会通过其他节点处累积文件块
- 向跟踪服务器注册，获得peer节点列表，和部分peer节点构成邻居关系 (“连接”)
当peer下载时，该peer可以同时向其他节点提供上载服务
- Peer可能会变换用于交换块的peer节点
- 扰动churn: peer节点可能会上线或者下线
- 一旦一个peer拥有整个文件，它会（自私的）离开或者保留（利他主义）在torrent中
请求块：
- 在任何给定时间，不同peer节点拥有一个文件块的子集
- 周期性的，Alice节点向 邻居询问他们拥有哪些块的信息
- Alice向peer节点请求它希望的块，稀缺的块
发送块：一报还一报tit- for-tat
- Alice向4个peer发送块，这些块向它自己提供最大带宽的服 务
- 其他peer被Alice阻塞 (将不会从Alice处获得服务)
- 每10秒重新评估一次：前4位
- 每个30秒：随机选择其他peer节点，向这个节点发送块
- “优化疏通” 这个节点
- 新选择的节点可以加入这个top
一报还一报
4.Gnutella协议
- 在已有的TCP连接上发送查询报文
- 对等方转发查询报文
- 以反方向返回查询命中报文
Gnutella运行逻辑
有点类似于深度优先搜索
- 对等方X必须首先发现某些已经在覆盖网络中的其他对等方：使用可用对等方列表
- 自己维持一张对等方列表（经常开机的对等方的IP）
- 联系维持列表的Gnutella站点
- X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接
- X向Y发送一个Ping报文，Y转发该Ping报文
- 所有收到Ping报文的对等方以Pong报文响应IP地址、共享文件的数量及总字节数
- X收到许多Pong报文，然后它能建立其他TCP连接
5.KaZaA协议
1）KaZaA协议概述
- 每个对等方要么是一个组长，要么隶属于一个组长
- 对等方与其组长之间有TCP连接
- 组长对之间有TCP连接
- 组长跟踪其所有的孩子的内容
- 组长与其他组长联系
- 转发查询到其他组长
- 获得其他组长的数据拷贝
2）KaZaA协议查询
- 每个文件有一个散列标识码和一个描述符
- 客户端向其组长发送关键字查询
- 组长用匹配进行响应：
- 对每个匹配：元数据、散列标识码和IP地址
- 如果组长将查询转发给其他组长，其他组长也以匹配进行响应
- 客户端选择要下载的文件
- 向拥有文件的对等方发送一个带散列标识码的HTTP请求
3）KazaA补充说明
- 请求排队
- 限制并行上载的数量
- 确保每个被传输的文件从上载节点接收一定量的带宽
- 激励优先权
- 鼓励用户上载文件
- 加强系统的扩展性
- 并行下载
- 从多个对等方下载同一个文件的不同部分
- HTTP的字节范围首部
- 更快地检索一个文件
六、CDN（Content Distribution Network）
1.DASH（Dynamic adaptive Streaming over HTTP）
DASH被称为经HTTP的动态适应性流，用于向客户提供更好的视频流服务，相比于HTTP流，它的块是根据当下带宽来进行变化，而不是一直一成不变，对于带宽的不一样的用户会，根据他们的带宽情况提供好的服务
- 服务器:
- 将视频文件分割成多个块
- 每个块独立存储，编码于不同码率（8-10种）
- 告示文件（manifest file）: 提供不同块的URL
- 客户端:
- 先获取告示文件
- 周期性地测量服务器到客户端的带宽
- 查询告示文件,在一个时刻请求一个块，HTTP头部指定字 节范围
- 如果带宽足够，选择最大码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)
问题：
问：请求 什么编码速率 的视频块答：当带宽够用时，请求高质量的视频块问 ：哪里 去请求块答：可以向离自己近的服务器发送URL，或 者向高可用带宽的服务器请求
2.内容分发网（CDN）
CDN 是将源站内容分发 最接近用户的节点，使用户可就近歌得所需内容 提高用户访问响应速度和成功率解决因分布、带宽、服务器性能带来的访迟问题，适用于站点加速点播、直播等场景。
为了解决服务器通过网络向上百万用户同时提供流化视频内容带来的性能问题，几乎所有的视频流公司都利用CDN。CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频（还有其他文件音频文档图片）的副本，并且试图将每个用户请求重定向到一个将提供最好的用户体验的CDN位置。
1）两种不同的服务器安置原则：
- 深入:
- 其目标是靠近端用户，通过减少端用户和 CDN 集群之间（内容从这里收到）链路和路由器的数量，从而改善了用户感受的时 和吞吐量。因为这种高度分布式设计，维护和管理集群的任务成为挑战
- 邀请做客:
- 通过在少量（例如10个）关键位置建造大集群来邀请到 ISP 做客。不是将集群放在接人 ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点（ IXP )
- 与深人设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。
多 CDN 没有将视频推人它们的集群，而是使用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向家户流式传输视频时的同时在本地存储一个副本。类似于因特网缓存（ 业某集群存储器变满时，它删除不经常请求的视频。
2）用户访问
3）流程图：
感谢观看owo