应用层概述

参考模型中的各层一般都满足“应用下层的服务，为上层提供服务”，但应用层较为特殊，因为应用层没有上层，所以应用层直接为模型外的用户提供服务，应用层是最靠近用户的一层

应用层特点

• 没有应用层，就没有网络通信支持
• 参考模型中唯一的一层，不需为它的上层服务
• 它向参考模型之外的用户提供服务
• 网络应用程序可被分为两大类
  • 直接网络应用程序 Browser , e-mail ,FTP , Telnet
  • 间接网络应用程序 Word , resource manager , (via Redirector)

创建一个网络应用

• 通过程序设计语言（Java，C，python）使应用在不同的端系统上运行
• 通过网络基础设施提供的服务，使网络应用进程彼此间可以通信（以应用层视角来看，其下的所有层级均为基础设施为其提供服务）
• 网络核心中没有网络应用（以路由器交换机和链路组成的网络核心并不在应用层上起作用，主要利用网络层等，所以其上没有网络应用的存在）
• 网络应用只在端系统上部署，这有助于网络应用的快速开发和部署

主要的直接应用

• 传统经典的应用：DNS，，电子邮件E-mail，万维网World wide web，文件传输ftp，远程登陆telnet
• 新应用：微信，多媒体，App

重定向器(Redirector)

• 置于应用中的一种小软件
• 是透明的
• 间接网络应用都是通过重定向器实现网络功能

网络应用的体系结构

网络应用程序体系结构是由应用程序开发者研发，规定如何在各种端系统上组织该应用程序（应用程序体系结构独立于TCP/IP协议栈，是由程序开发者使用的体系结构），目前主流的体系结构有以下几种

客户-服务器体系结构（C/S）

客户-服务器体系结构将端系统分为客户机（Client）和服务器（Server）两种

服务器特点：

• 服务器主机始终处于运行的状态
• 拥有固定的IP地址和端口号（端口号一般使用约定俗成：例如Web应用的服务器采用80端口，ftp服务器的端口采用21…）
• 扩展性较差，一般只能通过升级部分硬件和服务器迁移的方式进行扩展
• 当客户端访问增加时，服务器的服务性能不是平滑的下降，而是在访问数量达到某一程度后呈指数下跌

客户端特点：

• 主动与服务器通信
• 与互联网有间歇性的连接
• 可能是动态IP地址
• 不直接与其它客户端通信（例如两个web应用之间不能直接进行通信）

P2P体系结构/对等体系结构

除了位于数据中心的专用服务器外，几乎没有是中运行的服务器存在，并且对钟信服务器依赖很小，任意端系统之间可以直接进行连接，这些相互直接连接的主机对被称为对等方，每一个节点既是客户端又是服务端，即请求服务，又提供服务（因此P2P体系结构，具有自扩展性，新节点会带来新请求同时带来新的服务），参与的主机间歇性连接并且可以改变IP地址（程间实例有迅雷，BitTorrent等等）

由于P2P体系结构允许参与主机随时进行连接或结束连接，所以该体系结构难以管理，并且在未来可能面临安全性可靠性等的挑战

C/S和P2P混合体系结构

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

进程通信概述

进程：一段程序的执行过程，一个应用程序可能有一个或多个进程（例如当浏览器中打开多个网页时，每个单独的网页就是一个进程）

进程通信就是两个进程之间进行数据的传输或交换，位于同一台主机上的两个进程，可以通过操作系统指定的方式不经过网络进行进程的通信，而位于不同主机上的不同进程之间想要实现通信就需要通过交换报文（Message）的方式实现通信

我们将进行进程通信的双方分成：

• 客户端进程：发送通信的进程
• 服务器进程：等待通信的进程

分布式进程通讯需要解决的问题

进程标识和寻址问题

两台主机之间企图进行通讯首先至少需要两台目标主机的IP地址，以保证报文能够顺利到达目标主机并且能够根据IP响应报文，并且由于是进程间的通信，还需要两个进程的端口号，并且，最后，还需要用到所采用的传输层协议，以保证能够正确的解析数据

• 一个进程：用IP+port标示 端节点
• 本质上，一对主机进程之间的通信由2个端节点构成

传输层如何为应用层提供服务

应用层需要向传输层传递的信息

• 层间接口必须要携带的信息
  • 要传输的报文（对于本层来说：SDU）
  • 发送方信息：对方的应用进程的标示：IP+TCP(UDP) 端口
  • 接收方信息：对方的应用进程的标示：对方的IP+TCP(UDP)端口号
• 传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段（UDP数据报）的封装
  • 源端口号，目标端口号，数据等
  • 将IP地址往下交IP实体，用于封装IP数据报：源IP,目标IP

层间信息的代表-Socket

如果每次通信/对话都需要携带如此多的信息，无疑会加剧管理难度，并且容易出错，所以可以采用一个代号来指代通信双方/单方的信息，这个信息就是socket（与我们通过文件操作打开文件OS会返回一个句柄一样，对句柄的操作就是对文件的操作，这里我们对socket的操作就是对通信双方交换数据的操作），所谓套接字(Socket)，就是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象。

TCP上的套接字（流套接字）

流套接字用于提供面向连接、可靠的数据传输服务。该服务将保证数据能够实现无差错、无重复送，并按顺序接收。流套接字之所以能够实现可靠的数据服务，原因在于其使用了传输控制协议，即TCP协议，对于使用面向连接服务（TCP）的应用而言，套接字是4元组：(源IP，源port，目标IP，目标port)的一个具有本地意义的标示

• 唯一的指定了一个会话（2个进程之间的会话关系）
• 应用使用这个标示，与远程的应用进程通信
• 不必在每一个报文的发送都要指定这4元组
• 简单，便于管理

UDP上的套接字（数据报套接字）

数据报套接字提供一种无连接的服务。该服务并不能保证数据传输的可靠性,数据有可能在传输过程中丢失或出现数据重复，且无法保证顺序地接收到数据。数据报套接字使用UDP协议进行数据的传输。由于数据报套接字不能保证数据传输的可靠性，对于有可能出现的数据丢失情况，需要在程序中做相应的处理对于使用无连接服务（UDP）的应用而言，套接字是2元组的一个具有本地意义的标示

• 2元组：IP，port （源端指定）
• UDP套接字指定了应用所在的一个端节点（end point）
• 但是在发送报文时，必须要指定对方的ip和udp port(另外一个端节点)

如何使用传输层提供的服务实现应用通信

• 定义应用层协议
  • 换的报文类型：请求和应答报文
  • 各种报文类型的语法：报文中的各个字段及其描述
  • 字段的语义：即字段取值的含义
  • 进程何时、如何发送报文及对报文进行响应的规则
• 编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

可供应用程序使用的传输层服务

• 是否可靠的数据传输率
• 能够提供的吞吐量大小
• 延迟/定时
• 数据的安全性

TCP安全

无论是TCP还是UDP都没有提供任何的加密机制，也就是进程通信过程中其套接字数据与经过网络传送到目的进程的数据相同（即明文传送）

为了解决这种安全性问题，遂研制出了TCP的加强版即安全套接字层（SSL：Secure Sockets Layer）,其位于应用层（应用采用SSL库，SSL库使用TCP通信），能够完成传统TCP的一切功能，并且最关键的提供了进程到进程的安全性服务，包括加密，数据完整性与端点的鉴别

万维网WWW与Http

Web即万维网，是World Wide Web的简称。

Web 是web网页的集合（ collection of web pages）,其由许多对象组成，这些对象可以是HTML文件，JPEG图象，Java程序等等，每个页面包含了指向其他页面的链接（超级链接），浏览器 –显示阅读web页面的程序

组成部分

• 资源，web页面，Resource (html)
• 统一资源定位器：URL
• 通信协议HTTP

常见协议

客户端

Web页面由 URL (Uniform Resource Locators)标识 (i.e.http://www.abcd.com/products.html)

• 协议：http
• 页面所在的机器的DNS 域名：www.abcd.com
• 包含web页面的文件的名字：products.html

当用户单击一个超级链接（URL）时：

• 浏览器检查URL (读取浏览器的输入)
• 浏览器向 DNS 服务器询问域名的IP地址
• DNS 返回对应的 IP 地址
• 浏览器和Web服务器建立TCP 连接（在端口 80）
• 浏览器发送请求，要求获取文件products.html
• Web服务器返回被请求的文件
• TCP 连接被释放
• 浏览器解释显示下载到本地的文件

一个web页面可能由PDF文件、GIF图标、MPEG视频、MP3歌 曲，或者其他数百种文件类型的任何一种组成

浏览器可能在解释这些文件的时候会遇到问题，不是让浏览 器越来越大，而是采用了一个更加通用的解决方案

当服务器返回一个页面，它通常也返回一些有关该页面的附 加信息，包含了页面的MIME类型，以决定如何显示该页面

Cookie

• 一个小于4kB的命名串
• 当客户请求时，web服务器除了应答外，附送一个cookie，存
• 储存在客户机磁盘
• 客户再访问同一个web服务器时，同时发送cookie
• 服务器辨识出该用户，并得到它关心的一些信息

问题在于可能暴露客户隐私数据，存在安全隐患

有两种可能的扩展浏览器的方式

Plug-ins：代码模块，运行在浏览器的内部

Helper applications：独立的程序，浏览器只是把参数传入

两种扩展方式各有优劣，插件可以增强浏览器的功能，应用则不能，插件启动时更加迅速，但是当插件过多就会占用过多资源，导致浏览器使用缓慢

服务器端

典型的web 服务器的操作：

• 接收来自客户的TCP连接
• 获取所需文件的名字
• 从本地磁盘上获取文件（静态页面）
• 将文件返回给客户
• 释放TCP连接

改进

• 在内存维护一个缓存，保存最近用过的 n个文件，避免每次查找文件都要读取磁盘
• 采用多线程服务器

如上图，客户的TCP连接中止于前端，所以应答也必须经过前端，一种解决的方法是TCP移交，TCP端点被传递给处理节点 ，所以应答可以直接向客户端发送 。

代理服务器-万维网高速缓存

代理服务器(proxy server)又称为万维网高速缓存(Web cache)，它代表浏览器发出 HTTP 请求。

万维网高速缓存把最近的一些请求和响应暂存在本地磁盘中。

当与暂时存放的请求相同的新请求到达时，万维网高速缓存就把暂存的响应发送出去，而不需要按 URL 的地址再去因特网访问该资源。

如果没有代理服务器，假定在内网内的不同客户端请求同一个数据，就需要同时大量传送完全相同的内容，浪费带宽资源。如果有代理服务器，在第一个客户端查询相关数据内容后，数据就暂时被保存在服务器中，后续客户端如果再次请求这组数据就可以直接从代理服务器获取，甚至不需要进入公网，十分高效快捷

代理流程

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

特点

• 缓存既是客户端又是服务器
• 通常缓存是由ISP安装(大学、公司、居民区ISP)
• 可以大大减少一个机构内部网络与Internent接入链路上的流量
• 目标：不访问原始服务器，就满足客户的请求

条件GET方法

由于代理服务器并不能确定客户请求的资源在代理服务器中是否是最新版本，所以在用户请求资源且资源在代理服务器中存在时，代理服务器会首先向目标服务器发送一个简单报文，其中在报文头部加上IF-MODIFIED-SINCE: <SINCE>属性表示询问自该事件起，所请求的资源是否有被修改过，服务器会根据所给时间响应资源状态，代理服务器就可以判断是否需要更新资源

Http协议

超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。

HTTP是基于客户/服务器模式，且面向连接的。典型的HTTP事务处理有如下的过程：

1. 客户与服务器建立连接
2. 客户向服务器提出请求
3. 服务器接受请求，并根据请求返回相应的文件作为应答
4. 客户与服务器关闭连接

从上文可以看出，HTTP协议是无状态的，即服务器并不维护关于客户的任何信息（从上文的流程可以看到，事务处理结束后客户与服务器直接关闭连接，对客户的信息不进行处理）

无状态协议的优点

• 减轻了服务器的压力
• 能够支持更多的客户端连接
• 不需要维护历史信息

非持续连接HTTP

非持续连接HTTP表示请求/响应都经过建立一个单独的TCP连接进行

非持续连接与持续连接区别

非持续连接HTTP特点

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

非持续连接的缺点

• 每个对象都需要两个RTT
• 必须为每个请求的对象建立并维护一个全新的连接，增加了服务器的负担

非持续连接情况下的往返时间模型

• 往返时间RTT：round-trip-time表示一个分组从客户端到服务器端后又返回客户端所消耗的时间（RTT假设分组较小，数据的传输时间很短忽略不计）
• 从图中可以看出响应时间分为三部分，总共是两个RTT与一段传输时间（这里加传输时间是因为服务器响应的数据一般较大需要单独计算，不可以忽略不计），第一个RTT是发起TCP连接，第二个RTT是发送HTTP请求并获取响应

持续连接HTTP

持续连接HTTP表示一段时间内所有请求/响应都经过同一个TCP连接进行

持续连接HTTP的是通过服务器在发送响应后，仍保持TCP连接实现的，这保证了在相同的客户端和服务器之间的后续请求和响应报文是通过相同的TCP连接进行传送的，并且客户端在于导一个引用对象的时候，就可以尽快发送该对象的请求

根据客户端发送请求的方式可以将持续连接的HTTP分为两种

• 非流水式持久HTTP：
  • 客户端在收到服务器关于上一个请求的响应后才会发送下一个请求
  • 每个请求消耗一个RTT
• 流水式持久HTTP：
  • 客户端遇到一个引用对象就立即产生一个请求
  • 所有引用对象消耗的时间理论上远小于非流水式
  • HTTP/1.1 默认采用这种方式

持续连接HTTP特点

• 多个对象可以在一个TCP连接上传送
• HTTP/1.1 默认使用持续连接

HTTP报文格式

HTTP请求报文数据格式

1. 请求行
   • 请求方式：HTTP协议种规定了7种请求方式，常用的由两种
     • GET：请求的参数在请求行中（即跟在URL后面），且请求的长度有限制，有安全隐患
     • POST：请求的参数在请求体中，请求的URL没有限制，相对安全
   • 请求url：发出请求的URL
   • 请求协议/版本：例如HTTP/1.1
2. 请求头
   • 格式：请求头名称:请求头值
   • User-Agent：当前浏览器的相关版本信息（可以在服务器端获取该信息，以解决浏览器兼容问题）
   • Referer：当前网页的来源网址（从哪个网页跳转而来）可用于防盗链或进行一些统计工作
   • Accept：允许接收的数据格式
   • Accept-Language：允许接收的语言类型
   • Coonection：连接状态（是否存活）
3. 请求空行：一段空行，用于分割各组成部分
4. 请求体：正文内容

解析前的请求头

解析后的请求头

HTTP响应报文数据格式

1. 响应行
   • 组成：协议/版本 响应状态码 状态码描述（例如HTTP/1.1 200 OK）
2. 响应头
   • 格式：头名称:值
   • 常见响应头
     • Content-Type：服务器告知客户端，响应体数据的格式以及编码方式
     • Content-Disposition：服务器告知客户端响应体数据的打开方式
3. 响应空行
4. 响应体

捕获的本地HTTP报文

响应状态码分类

cookies：实现用户与服务器的交互

类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息

组成部分

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

电子邮件

电子邮件系统通常由三部分组成

• 用户代理(UA)：让用户能够阅读和发送邮件，又名邮件阅读器
  • 本地程序，提供命令行或图形界面，让用户和电子邮件系统交互（如outlook和foxmail）
• 邮件服务器，消息传输代理 (MTA)：将消息从源端送到目标端
  • 通常是系统守护进程，即运行在后台的进程，在系统中传递电子邮件，又被称为邮件服务器
• 简单邮件传输协议：SMTP

电子邮件的体系结构

用户首先在UA编辑好邮件然后提交，接下来邮件会被提交到发方的邮件服务器（MTA），接下来发方的邮件传输代理将会把邮件传输到收方的MTA上，最终，当对方从UA阅读相应邮件时，该邮件会被从对方的邮件服务器发送到对方本地的UA

用户代理－UA

UA通常是一个程序，一般称为电子邮件阅读器，常见的UA有： Gmail,outlook,foxmail…

用户代理完成的功能

• 入境邮件的显示
• 归档：垃圾邮件、某重要人物的邮件
• 邮件处置：回复、转发、删除、保存……
• 自动响应
• 签名块
• 邮件列表（mailing-list）：本地、传输代理

电子邮件消息格式

ASCII 电子邮件信息通常采用 RFC 822，注意：SMTP是交换Email报文的协议，RFC 822是文本报文的标准

• 消息由一个基本的信封(RFC821)、一些头域、一个空行和消息体组成。
• 每个头域（逻辑地）由一行ASCII文本组成，包括域名、一个冒号，对于大多数头域来说，还包括一个值
• RFC822是几十年前设计的，没有区分信封域和头域
• 虽然 RFC 5322作了修正，但是因为RFC822已经广泛使用，完全重新设计是不可能的
• 用户可以发明新的消息头以供自己私人使用，只要这些消息头以 X-开头

消息头 (RFC 822)

RFC 5322新增

MIME 多用途互联网邮件扩展 (the Multipurpose Internet Mail Extensions)

RFC5322无法处理带有重音符的语言（如法语）、非拉丁字母（如俄语）、不带字母的语言（如汉语，日语）、完全不包含文本的消息（如视频）的邮件，为此提出了MIME来解决此问题

MIME的基本思想是继续使用 RFC822格式，但是在消息体中 增加了结构，且为非ASCII消息定义了编码规则

• 由于没有偏离 RFC822，MIME消息可以使用现有的程序和协议来发送
• 只有接收和发送的程序必须要改变

MIME增加的消息头

简单邮件传输协议SMTP（Simple Mail Transfer Protocol）

上文讲述了如何编写邮件，接下来进行的就是邮件的传输，邮件的传输通过简单邮件传输协议实现，这是一个简单的 ASCII 协议

源机与目标机（SMTP守护进程在监听）的25端口建立TCP连接 。如果消息不能被投递，则向消息的发送方返回一个错误报告（包含了不能投递消息的第一部分）

SMTP传输步骤

1. 连接建立 在端口 25
2. 数据交换
   • 客户机（作为客户）等待服务器（作为服务器）首先开始通话
   • 服务器首先发送一行文本，给出它自己的标识，并且告诉客户机是否已准备好接收邮件
   • 如果服务器没有准备好，则客户机释放连接，以后再重试(5-30min)
   • 如果服务器愿意接收电子邮件，则客户机申明发信人和收信人
   • 如果服务器确实存在这样的收信人，则服务器指示客户可以发送了
   • 客户发送消息，服务器回发确认
3. 连接释放

SMTP存在的问题

• 没有认证，导致容易接收垃圾邮件
• 传输的是ASCII消息而不是二进制数据，需要编码，效率低下
• 邮件是明文，涉及邮件安全问题

通过上述流程不难发现，保证邮件发送成功的前提是发送端与接收端成功建立TCP连接，这就需要接收端与发送端设备需要在发送时都保持开机状态，但这是不现实的，收方不可能一直在线，而如果收方不在线，发方就无法发送邮件

最后的投递

为解决上述问题，就需要在邮件服务提供商ISP的一台机器上运行一个消息传输代理（message transferagent）； 这台机器可以一天24小时运行，随时都可以接收邮件

然后设计一个协议，允许用户在上线后和消息传输代理MTA联系，然后把邮件从ISP那里拷贝到用户，早期使用的协议是POP-3协议，即邮局协议3版本，改进版本为IMAP。协议的作用范围在接收端用户和代理服务器之间

POP3

• 当用户启动邮件阅读器的时候，POP3开始工作
• 用户呼叫ISP（除非已有一个连接），然后与MTA在110端口 建立TCP连接
• 一旦连接建立， POP3协议按顺序经历三种状态
  • 授权（Authorization）处理用户登录的过程
  • 事务（Trnsactions）用户收取电子邮件，并将邮件标记为删除
  • 更新（Update）将标为删除的电子邮件删除

POP3协议不适合应用于移动端收发邮件，因为在移动端收发邮件会导致POP3将邮件标记为删除，无法在其他客户端查看(采用下载并删除模式)，这个问题，在IMAP中得到了解决

IMAP

• IMAP 假设所有的电子邮件都永久地保存在服务器上的多个邮箱中（解决了移动端删除的问题）
• IMAP 提供了阅读消息或阅读部分消息的机制
• IMAP 服务器在143端口监听而不是110端口
• IMAP 也可以接收外发的邮件 (这点跟 POP3不同)
• IMAP 有更多的命令，更复杂

WebMail优点

• 无需安装专用的UA，只要能够上网登录浏览器，就可以使用
• 无需配置，打开浏览器即可
• 收发双方无需同时在线，只需通过浏览器登录各自代理服务器，使用HTTP
• 两个代理服务器之间邮件的传递仍然采用SMTP

其他应用

应用层是开放的，以TCP/IP为核心，向两端开放。应用层出不穷文件传输FTP，远程登录TELNET，多媒体，微信……

文件传输（FTP）

一种可靠的面向连接的服务，采用TCP在支持FTP的系统间传 输文件（在远程主机上传输文件或接收文件），它支持双向二进制文件和ASCII文件传输。

上载：

将文件从自己的计算机中拷贝到远程计算机上(upload)

下载：

将文件从远程计算机上拷贝到自己的计算机上。 (download)

FTP文件传输流程

1. FTP客户端与服务器通过端口21进行联系，并使用TCP为传输协议（建立控制连接）
2. 客户端通过控制连接获得身份认证（用户名与口令）
3. 客户端通过控制连接发送命令浏览远程目录
4. 收到一个文件传输命令
   1. 服务器打开一个到客户端的数据连接
   2. 利用数据连接进行文件数据传输
   3. 服务器关闭当前数据连接
5. 以后每收到一个文件传输命令，服务器都会重新建立一条数据连接

从上面的流程不难看出，FTP是有状态的协议，其需要维护用户的状态信息，当前路径以及用户账户等等

FTP命令

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

FTP返回码

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

TFTP：

一种无连接的不可靠的服务，采用UDP在支持TFTP的系统间传输文件。

Telnet

不要求远地系统创建众多的服务器，只需为每个远程登陆用 户建立一个进程，这个进程再通过创建子进程为远程登陆用 户提供各种允许的服务。

远程登陆的另外一个优点，它提供与本地登陆几乎完全相同 的用户界面

本地用户在本地终端对远地系统进行远程登陆，该远程登陆 的内部视图实际上是一个TCP连接（服务器端口：23）；

将本地终端上的键盘输入逐键传到远地机；将远地机输出送回本地终端。

• FTP和TELNET的传输层都用的是TCP

域名系统DNS概述

在互联网中，直接使用IP地址作为机器的绝对地址是行不通的，具体原因有2点：1.计算机可能常常地更换IP地址，所以，通过IP地址去访问某台机器就会发生问题。2.IP地址难于记忆，且毫无规律。因此，我们只需要通过一个有规律性且永久不会更换的名字来标识某个IP地址，就可以解决上述问题，这就是我们所说的域名。

但是在传输数据的过程中，或是为数据加上MAC地址，或是为文件加上IP地址，却从来没有为数据加上过域名，只有IP地址可以起到标示主机与路由器的功能，因此我们必须使用域名系统DNS，来将一个个名字映射到对应的IP地址

ARPANET时代，有一个文件hosts.txt，列出了当时网络上所 有的主机和它们对应的IP地址（当网络很小的时候，可以工 作得很好），这份文件如今依然存在于电脑的 “C:\Windows\System32\drivers\etc\hosts” 路径下。但是随着互联网发展，用一份文件映射所有IP地址和域名变得不现实，因此才产生了如今的域名系统

域名系统DNS(Domain Name System)

• DNS是分层次的，基于域的命名方案
• 采用了分布式数据库系统来实现
• 运行在UDP之上端口号为53的应用服务
• 是核心的Internet功能，但以应用层协议实现（为其他应用提供服务）

DNS的主要目的

• 实现主机-IP地址的转换
• 其他目的
  • 主机别名到规范名字的转换
  • 邮件服务器别名到邮件服务器正规名字的转换
  • 一定程度上实现负载均衡

DNS首先将整个互联网分成250个顶级域，每个顶级域被分为多个子域，子域仍可以继续划分出更多子域，所有这些域最终将会形成一棵树，树上的叶子代表没有子域的域

顶级域由ICANN负责管理运行，顶级域分为两类：通用域（.com,.edu…）以及国家域（.jp,.cn,.nl…）

中国（.cn）二级域名

(获得一个二级域名无需到ICANN申请)，只需要到运行顶级域名的注册机构去检查带申请名字是否可用，并且不是别人商标即可申请

DNS的工作流程

1. 应用调用解析器（resolver）
2. 解析器作为客户向名字服务器（Name Server）发出查询报文（封装在UDP段中）
3. Name Server返回响应报文（Name/Ip）

本地名字服务器（Local Name Server）

• 不严格属于层次结构内
• 每个ISP（居民区，学校，企业）都有本地DNS服务器（也称为默认名字服务器）
• 当一个主机发起DNS查询时，查询首先被送到本地DNS服务器（高速），若本地没有缓存，则转发到层次结构中进行查询（起代理作用）

DNS查询方式

• 递归查询
• 迭代查询

域名（Domain Names）

每个域的名字是：从它向上到根（未命名）的路径，各个部分间用圆点隔开

• 域名可以是绝对的，也可以是相对的，绝对域名总是以圆点 结束（如： eng.sun.com. ）
  • 相对域名必须在一定的上下文环境中被解释出来才有意义，从而唯一地确定其真实的含义
  • 绝对域名和相对域名都引用了域名树中一个特定的节点，以及它下面的所有节点
• 域名是大小写无关的（ case insensitive ）
• 各组成部分的名字最多有 63 个字符长，整个路径不超过 255个字符
• 没有规则限制同时在两个或多个顶级域名下的注册 (如： sony.com and sony.nl)—这可能导致域名抢注
• 每个域自己控制它下面的域（子域）的划分
  • 例如：日本的 ac.jp 和 co.jp 分别对应于 edu 和com
  • 荷兰却不这样区分，它把所有的都放在nl之下
  • 要创建一个新的域，创建者必须得到该新域的上级域的许可，一旦创建成功，该新域可以创建子域，而无需征得上级域的同意
• 域名遵循的是组织的边界而不是物理网络的边界
  • 一个域的主机可以不在同一个网络
  • 一个网络中的主机不一定在同一个域

域名服务器

资源记录存储在资源服务器中，整个互联网需要多台而不是一台域名服务器，DNS名字空间被分割成不相交的区域（zones），每个区域包含域名树的一部分，也包含一台主域名服务器（ primary name server ）。

主域名服务器从自己硬盘的一个文件中读取信息，次域名服 务器（ secondary name servers ）分享这些信息

根域名服务器

最重要的域名服务器；存储所有顶级域名的名字和IP

• 无论是哪个本地域名服务器，无论何时，只要它无法回答一个查询请求，它都会向根域服务器求救 (for help)
• 全球有 13 根域服务器，它们的名字分别是a to m（前13 个字母）
• 全球还有多台根域名服务器的镜像，以便各个国家就近找到一个根域名服务器救急

权威DNS服务器

组织机构的DNS服务器，提供组织机构服务器（如web，email）可访问的主机和IP之间的映射

TLD服务器

顶级域（TLD）服务器：负责顶级域名（com，org，net）和所有国家级的顶级域名（cn，uk，fr）

资源记录

每个域无论是单主机域还是顶级域，都有一组跟它相关联的资料记录，当一个解析器将域名传递给DNS时，DNS返回的是与这个资源相关联的资源记录，所以DNS的主要功能，是将域名映射到资源记录上去

资源记录的组成-RR格式

• 域名（Domain name）：
  • 指出这条记录适用于哪个域，通常每个域有多条记录，而数据库则保存了多个域的信息
  • 域名字段是匹配查询条件的主要关键字
  • 记录在数据库中的顺序是无关紧要的
• 生存期（Time to Live，TTL）：生存时间，指示该条记录的稳定程度
  • 极稳定的信息会被分配一个很大的值，可以用于记录权威记录
  • 非常不稳定的信息会被分配一个很小的值，可以用于记录缓冲记录
• 类别（Class）：对于互联网信息，它总是 IN
• 值（Value）：类型对应的值，可以是数字，可以是ASCII码，域名等等
• 类型（Type）：资源记录的类型
  • A：Domain Name为主机，Value为IP地址
  • CNAME：Domain Name为规范名字的别名，Value为规范名字
  • NS：Domain Name为域名，Value为该域名的权威服务器的域名
  • MX：Value为Domain Name对应的邮件服务器的名字

P2P应用

对等式网络（英语：peer-to-peer， 简称P2P），又称点对点技术，是无中心服务器、依靠用户群（peers）交换信息的互联网体系，它的作用在于，减低以往网路传输中的节点，以降低资料遗失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。

P2P应用架构

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

C/S模式在文件分发中暴露的劣势

实际场景

以文件（文件大小为F）下载为例，在文件下载过程中C/S模式下，始终都是服务器负责进行文件的上载（上载能力$U_s$），各个客户端负责文件的下载（下载能力$D_i$），此时下载所消耗的时间取决于客户端下载单个文件所花费的时间，与服务器上载N个相同文件所花费时间中的最大值，即： $D_{c/s}\geq max\{\frac{N*F}{U_s},\frac{F}{D_1},...,\frac{F}{D_N}\}$

而P2P应用在进行文件传输的时候，不依赖与上传的服务器，所有peer在下载文件后都可以成为文件的提供方进行数据的上载，所以其下载所消耗最长时间取决于三个因素：

• 服务器传输：最少需要上载一份拷贝，发送一个拷贝的时间：$\frac{F}{U_S}$
• 客户端: 每个客户端必须下载一个拷贝,下载拷贝所需时间：$\frac{F}{D_i}$
• 客户端: 所有客户端总体下载量NF
  • 最大上载带宽是：$U_S+U_i+...+U_N$
  • 除了服务器可以上载，其他所有的peer节点也都可以上载
  • 所以总体时间：$\frac{N*F}{U_S+U_i+...+U_N}$

$D_{P2P}\geq max\{\frac{F}{U_s},\frac{N*F}{U_S+U_i+...+U_N},\frac{F}{D_1},...,\frac{F}{D_N},\}$

随用户数量变化C/S与P2P两种模式下载消耗时间变化如图

P2P文件分发应用：BitTorrent

BitTorrent协议是架构于TCP/IP协议之上的一个P2P文件传输通信协议，处于TCP/IP结构的应用层。

根据BitTorrent协议，文件发布者会根据要发布的文件生成提供一个.torrent文件，即种子文件，也简称为“种子”。

种子文件本质上是文本文件，包含Tracker信息和文件信息两部分。Tracker信息主要是BT下载中需要用到的Tracker服务器的地址和针对Tracker服务器的设置，文件信息是根据对目标文件的计算生成的，计算结果根据BitTorrent协议内的Bencode规则进行编码。它的主要原理是需要把提供下载的文件虚拟分成大小相等的块，块大小必须为2k的整数次方（由于是虚拟分块，硬盘上并不产生各个块文件），并把每个块的索引信息和Hash验证码写入种子文件中；所以，种子文件就是被下载文件的“索引”。

下载时，BT客户端首先解析种子文件得到Tracker地址，然后连接Tracker服务器。Tracker服务器回应下载者的请求，提供下载者其他下载者（包括发布者）的IP。下载者再连接其他下载者，根据种子文件，两者分别告知对方自己已经有的块，然后交换对方所没有的数据。此时不需要其他服务器参与，分散了单个线路上的数据流量，因此减轻了服务器负担。

下载者每得到一个块，需要算出下载块的Hash验证码与种子文件中的对比，如果一样则说明块正确，不一样则需要重新下载这个块。这种规定是为了解决下载内容准确性的问题。

• 扰动：peer节点可能会上线或者下线

P2P文件共享

面临的问题：

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

方案一：集中式目录

• 存在一个中心服务器始终运行，负责存储各个Peer的IP地址和可提供的内容
• 一旦某个Peer上线就需要向中心服务器提供自己的IP地址和可以提供的内容
• 一旦某个Peer下线，同样需要向服务器说明自己将不再提供服务

这种集中式目录的共享方法存在如下的问题：

• 单点故障：中心服务器的故障会导致整个文件共享瘫痪
• 性能瓶颈：中心服务器存在瓶颈，文件传输是分散的，而定位内容则是高度集中的
• 侵犯版权

方案二：查询泛洪Gnutella

Gnutella是一种全分布式的（没有中心服务器）开放文件共享协议，Gnutella协议以TCP连接作为边，两个Peer间 如果存在一条TCP连接，则看作存在一条边（不是物理链路的连接），所有活动的对等方和边构成覆盖网络

查询过程：

1. 在已有的TCP连接上发送查询报文（向所有边）
2. 对等方转发查询报文（同样向对等方自己的所有边）
3. 如果发现查询内容，则以反方向返回查询命中报文

如何实现对等方的加入

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连接
• 组长跟踪其所有的孩子的内容（IP地址与所能提供的文件内容）
  • 此时小组内部就是通过集中式目录进行文件共享的，组长就是中心服务器
• 组长与其他组长联系
  • 转发查询到其他组长
  • 获得其他组长的数据拷贝
  • 此时组长间就是通过全分布式进行文件共享，所有查询在组长间进行泛洪

CDN与视频流化服务

在当下互联网环境中，视频流量占据了互联网的大部分带宽（例如网飞，油管等），单个超级服务器已经难以再为这些应用提供服务（扩展性差，难以处理高并发情况），所以需要通过分布式的，应用层面的基础设施解决这些流媒体服务

对流媒体视频的处理

要解决视频流量占据大量带宽的问题，首先可以基于用户的角度进行解决，避免用户加载不必要的资源，对视频流量进行合理的取舍

编码

视频是以固定速度显示的图片序列，而图片又是像素的阵列，这些都保证了视频是可以被压缩的，而这种压缩方式就是编码：使用图像内和图像间的冗余来降低编码的比特数（空间冗余是因每幅图片中临近的相近色块而产生，时间冗余则是由于相邻图像间相近而产生）

编码方式：

• CBR：constant bit rate，以固定速率编码
• VBR：variable bit rate，视频编码速率随时间的变化而变化

多媒体流化服务：DASH

DASH：Dynamic Adaptive Streaming over Http

首先由服务器将视频文件分割成多个小块，每个块独立存储，并且都用不同的码率编码，同时服务器会生成告示文件（mainfest file）以提供不同的URL

当客户端请求视频文件时，首先会获取到告示文件，并且周期性的测试服务器到客户端的带宽，通过查询告示文件在每个时刻请求一个块，如果带宽足够大，则尽量请求高码率视频，会话中不同时刻，可以切换码率不同的编码块（客户端自适应）

CDN-内容分发网络

内容分发网络（英语：Content Delivery Network或Content Distribution Network，缩写：CDN）是指一种透过互联网互相连接的电脑网络系统，利用最靠近每位用户的服务器，更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户，来提供高性能、可扩展性及低成本的网络内容传递给用户。

单个超级服务器多面临的问题

• 服务器到客户端路径上跳数较多，瓶颈链路限制带宽大小
• 二八定律导致网络内充满相同视频的拷贝，效率低
• 具有单点故障新，超级服务器出现问题影响所有用户
• 单个超级服务器有性能瓶颈，难于升级
• 由于服务用户众多，会导致周边网络的拥塞

而CDN在全球全网部署节点，存储服务内容，与用户直线距离更近，可以就近为用户提供服务，提升用户体验，起到加速网络的作用

CDN两种部署方式

• enter deep：将服务器深入许多接入网，更接近用户，数量多，离用户近，但难于管理
• bring home：部署在少数关键位置（例如将服务器簇安装于POP处），再利用租用线路将服务器簇连接起来

CDN流程

视频资源会被进行多次拷贝存储在CDN各个服务器中，用户通过告示文件重定向到最近的拷贝，进行内容的请求，过程中，如果当前请求的网络路径阻塞，可能会选择不同的拷贝进行请求