计算机网络基础 - 应用层 - 编程导航 | 一线开发者编程经验和技术实战分享

应用层

网络应用的体系结构

客户-服务器模式（C/S：client/server）
对等模式（P2P：Peer To Peer）
混合体：客户-服务器和对等体系结构

C/S 体系结构

服务器

一直运行
固定的 IP 地址和周知的端号（约定）
扩展性：服务器场（数据中心进行扩展、扩展性差）

客户端

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

注意：服务器 IP 也不一定是固定的，但是域名必须是固定的。可以通过 ddns 来刷新服务器的动态 ip

P2P 体系结构

（几乎）没有一直运行的服务器
任意端系统之间可以进行通信
每一个节点既是客户端又是服务器
参与的主机间歇性连接且可以改变 IP 地址
难以管理

例子：Gnutella、迅雷

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

Napster

文件搜索：集中
文件传输：P2P

即时通信

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

进程通信

概述

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

分为客户端进程、服务端进程
在同一个主机内，使用进程间通信机制通信
不同主机间，通过报文来通信

进程寻址

进程为了接收报文，必须有一个标识，即：SAP（发送也需要标识）

主机：唯一的 32位IP地址
所采用的传输层协议：TCP or UDP
端口号（Port Numbers）

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

要传输的报文（对于本层来说：SDU）
谁传的：对方的应用进程的标示：IP + TCP(UDP) 端口
传给谁：对方的应用进程的标示：对方的 IP + TCP(UDP) 端口号

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

套接字（Socket）

一个进程向另一个进程发送的报文必须通过下面的网络时候，进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文，因此套接字也称为应用程序和网络之间的应用程序编程接口 API

进程向套接字发送报文或从套接字接收报文（套接字 <=> 门户）
发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
接收进程从另外一端的门户收到报文（依赖于传输层设施）

TCP socket

TCP服务，两个进程之间的通信需要之前要建立连接
两个进程通信会持续一段时间，通信关系稳定
可以用一个整数表示两个应用实体之间的通信关系，本地标示

四元组：源端系统 ip 、源端系统 port 、目标端系统 ip 、目标端系统 port

UDP socket

UDP服务，两个进程之间的通信需要之前无需建立连接
- 每个报文都是独立传输的
- 前后报文可能给不同的分布式进程
穿过层间接口的信息大小最小
只能用一个整数表示本应用实体的标示

二元组：本机 ip、本机 port

注意：但是传输报文时，必须要提供对方 ip、port

应用层协议

运行在不同端系统上的应用进程如何相互交换报文（协议定义规范）

交换的报文类型：请求和应答报文
各种报文类型的语法：报文中的各个字段及其描述
字段的语义：即字段取值的含义
进程何时、如何发送报文及对报文进行响应的规则
应用协议仅仅是应用的一个组成部分

公开协议以及专用协议

公开协议：由RFC文档定义允许互操作，如 HTTP、SMTP
专用/私有协议：协议不公开，如 Skype

应用层需要传输层提供的服务

数据丢失率
- 有些应用则要求100%的可靠数据传输（如文件）
- 有些应用（如音频）能容忍一定比例以下的数据丢失
吞吐
- 一些应用出于有效性考虑，对数据传输有严格的时间限制（Internet 电话、交互式游戏）
延迟
- 一些应用（如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
- 一些应用能充分利用可供使用的吞吐(弹性应用)
安全性（机密、完整性、可认证性）

常见应用对传输服务的要求

应用	数据丢失率	吞吐	时间敏感性
文件传输	不能丢失	弹性	不
e-mail	不能丢失	弹性	不
Web 文档	不能丢失	弹性	不
实时音视频	容忍丢失	音频：5kbps ~ 1Mbps 视频：0kbps ~ 5Mbps	100 ms
存储音视频	容忍丢失	音频：5kbps ~ 1Mbps 视频：0kbps ~ 5Mbps	几秒之内
交互式游戏	容忍丢失	0 kbps ~ 10 kbps	100ms

Web 与 HTTP

概念

Web页由一些对象组成，对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等

多数Web页都含有一个 HTML 基本文件，该 HTML 基本文件又包含若干对象的引用（链接）
通过URL对每个对象进行引用：访问协议，用户名，口令字，端口等

Web 的应用层协议的核心是超文本传输协议 HTTP

定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式
使用传输层 TCP 协议建立连接
HTTP 是无状态的，服务器并不维护客户的信息

非持续连接和持续连接

在许多因特网应用程序中，客户和服务器在相当长的时间范围内通信，当这种客户-服务器的交互是经 TCP 进行的时候，应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经单独的 TCP 连接发送，还是所有的请求应经相同 TCP 连接发送呢?

前者就是非持续连接，后者就是持续连接（HTTP1.0 采用的是非持续连接；HTTP1.1 采用的是持续连接）

非持续连接存在的问题

必须为每一个请求的对象建立和维护一个全新的连接，对于每个这样的连接，在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量，这给 Web 服务器带来了严重的负担，因为 Web 服务器可能同时服务于数以百计不同的客户的请求
每一个对象经受两倍 RTT 的交付时延，即一个 RTT 用于创建 TCP ，另一个 RTT 用于请求和接收一个对象

响应时间模型

往返时间 RTT：一个小的分组从客户端到服务器，再回到客户端的时间
响应时间：发起TCP连接时间 + HTTP请求等待时间 + 传输时间 = 2RTT + 传输时间

HTTP报文格式

请求报文

请求报文第一行称为 请求行，后继的行称为 首部行，最后可能还有实体对象（实体对象会和首部行中间会有回车或者换行，注意是在特定的请求方法下才有内容，如 POST）

请求行有三个字段：方法字段、URL 字段、HTTP 版本字段
首部行指明了对象的主机域名/IP、是否继续连接、用户代理（比如浏览器版本）、语言类型等等
一个HTTP请求报文的通用格式

响应报文

它也是由三部分组成：一个初始状态行，首部行 , 然后是实体对象

状态行有 3 个字段：协议版本字段、状态码和相应状态信息
首部行指明了是否继续连接、服务器产生并发送该响应报文的日期和时间、用户代理（比如浏览器版本）、上次对象创建或者最后修改的日期和时间等等
一个HTTP 响应报文的通用格式

响应状态码

200 OK ：请求成功
301 Moved Permanently
- 请求的对象已经被永久转移了；新的URL在响应报文的 Location（首部行中指定）
- 客户端软件自动用新的 URL 去获取对象
400 Bad Request ：一个通用的差错代码，表示该请求不能被服务器理解
404 Not Found ：请求的文档在该服务上没有找到
505 HTTP Version Not Supported：服务器不支持请求报文使用的 HTTP 协议版本

Cookie

用于维护客户和服务器之间的状态（HTTP 是无状态的）

缺点

尽管 cookie 常常能简化用户的因特网活动，但是它的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害；如我们刚才所见，结合 cookie 和用户提供的账户信息，Web 站点可以知道许多有关用户的信息，并可能将这些信息卖给第三方

Web 缓存

Web 缓存器 (Web cache) 也叫代理服务器，不访问原始服务器，就能满足客户的请求

代理服务器既是服务器又是客户端
浏览器将所有的 HTTP 请求发给代理服务器
- 在缓存中的对象，直接返回对象
- 如果不在缓存中，代理服务器请求原始服务器，然后再将对象返回给客户端

如何判断放在代理服务器中的对象是否是陈旧的？

通过获取请求头的方式获取到 If-Modified-Since 信息（上次对象创建或者最后修改的日期和时间），进而可以判断出代理服务器中的对象在源服务器中是否有被修改过

FTP 与 EMail

文件传输协议 FTP

有状态的协议
向远程主机上传输文件或从远程主机接收文件
ftp服务器端口号为 21

FTP客户端与FTP服务器上传下载过程

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

注意：建立的控制连接和数据连接不在同一个进程端口上

建立数据连接的模式

主动模式时，服务器的20号端口主动与客户端的随机端口建立传递数据的连接
被动模式时，服务器告知客户端，让其与服务器的某一指定端口建立数据连接，但客户端的端口依然是随机的

电子邮件 EMail

电子邮件是一种异步通信媒介，现代电子邮件具有许多强大的特性，包括具有附件、超链接、 HTTP 格式文本和图片的报文

主要组成部分

用户代理 又名 “邮件阅读器”
- 撰写、编辑和阅读邮件如 Outlook、Foxmail
- 输出和输入邮件保存在服务器上
邮件服务器
- 邮箱中管理和维护发送给用户的邮件
- 输出报文队列保持待发送邮件报文
简单邮件传输协议 SMTP
- 客户：发送方邮件服务器
- 服务器：接收端邮件服务

SMTP

概述

SMTP 是因特网电子邮件的核心，用于从发送方的邮件服务器发送报文到接收方的邮件服务器

持久性连接
报文必须为7位 ASCII 码
使用TCP在客户端和服务器之间传送报文，端口号：25
直接传输：从发送方服务器到接收方服务器，传输的3个阶段
- 握手
- 传输报文
- 关闭

SMTP 与 HTTP1.1

相同点是两者都使用持续连接的方式

不同点：

HTTP 协议主要是一个 PULL 的协议，STMP 基本上是一个 PUSH 的协议
SMTP 要求每个报文采用7位 ASCII 码，而 HTTP 并没有这种限制
SMTP 可以将一个既包含文本又包含图片的文件放在同一个报文中，但是 HTTP 不行

邮件报文格式

报文格式

报文的首部行：每个首部必须含有一个 From 首部行和一个 To 首部行；一个首部也许包含一个 Subject（其他可选的首部行）

多媒体扩展 MIME

一种用于扩展电子邮件消息功能的标准，允许电子邮件不仅限于文本，还可以包含各种格式的内容如图像、音频、视频等

它在多媒体内容传输和Web应用中也被广泛应用
MIME定义了内容类型（如 text/html、image/png、audio/mpeg 等）以及内容编码方式，从而使得浏览器和其他应用程序能够正确处理和显示这些内容
报文的格式

邮件访问协议

概述

SMTP: 传送到接收方的邮件服务器
邮件访问协议：从服务器访问邮件
- POP3：邮局访问协议（Post Office Protocol），用户身份确认 (代理 <=> 服务器) 并下载
- IMAP：Internet 邮件访问协议（Internet Mail Access Protocol），在服务器上处理存储的报文
- HTTP

POP3

一个极为简单的邮件访问协议（本地管理文件夹）

工作过程

当用户代理打开了一个到邮件服务器(服务器)端口 110 上的 TCP 连接后， POP3就开始工作了

用户代理发送用户名和口令（以明文形式）以鉴别用户
用户代理取回报文，同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息
在客户发出了 quit 命令之后，目的是结束该 POP3 会话（这个时候该邮件服务器删除那些被标记为删除的报文）

注意

可以使用下载并删除、下载并保留两种模式
- 下载并删除模式：如果改变客户机，客户就不能阅读邮件
- 下载并保留模式：不同客户机上为报文进行拷贝
在用户代理与邮件服务器之间的POP3会话期间，该POP3服务器保留了一些状态信息，特别是记录了哪些用户报文被标记为删除了；然而，POP3服务器并不在POP3会话过程中携带状态信息，会话中不包括状态信息大大简化了POP3服务的实现（在会话中是无状态的）

IMAP

一种用于电子邮件客户端与邮件服务器之间通信的协议（远程管理文件夹）

它允许用户在服务器上管理和访问电子邮件，而不仅仅是下载到本地客户端；IMAP特别适合于需要在多个设备上访问相同邮箱的场景，例如在手机、电脑和其他设备上查看邮件

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

DNS

概述

为其他应用提供服务的应用

运行在UDP之上端口号为53的应用服务
核心的 Internet 功能，但以应用层协议实现，在网络边缘处理复杂性

DNS 主要用来做什么？

主要目的

ip 地址（ip 地址标识主机、路由器）不好记忆，不便人类使用，一般倾向于使用一些有意义的字符串来标识 Internet上的设备，例如：百度 https://www.baidu.com/baidu

然而路由器则喜欢定长的、有着层次结构的 ip 地址，例如：127.0.0.1

因此为了折中这些不同的方式，需要一种能进行主机名到 ip 地址转换的应用服务

其它目的

主机别名到规范名字的转换
邮件服务器别名到邮件服务器的正规名字的转换
负载均衡：当客户对映射到某地址集合的名字发出一个 DNS 请求时，即服务器用 ip 地址的整个集合进行响应，但在每个回答中循环这些地址次序

域名结构

每个(子)域下面可划分为若干子域，树叶是主机
域名：从本域往上，直到树根；中间使用 “.” 间隔不同的级别，例如：www.baidu.com

域与物理网络无关

域遵从组织界限，而不是物理网络
- 一个域的主机可以不在一个网络
- 一个网络的主机不一定在一个域
域的划分是逻辑的，而不是物理的

工作机理

集中式设计

客户直接将所有查询直接发往单一的 DNS 服务器，同时该 DNS 服务器直接对所有的查询客户做出响应。尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大的主机，存在如下问题

单点故障：如果该 DNS 服务器崩溃，整个因特网随之瘫痪
通信容量：单个 DNS 服务器不得不处理所有的 DNS 查询（上亿台）
远距离的集中式数据库：单个 DNS 服务器不可能"邻近"所有查询客户
维护：单个 DNS 服务器将不得不为所有的因特网主机保留记录

分布式、层次数据库

为了处理扩展性问题， DNS 使用了大量的 DNS 服务器，它们以层次方式组织，并且分布在全世界范围内。大致分成3种类型的 DNS 服务器，根 DNS 服务器、顶级域 DNS 服务器和权威 DNS 服务器

根 DNS 服务器

根名字服务器由 13个不同的组织管理（根名字服务器提供 TLD 服务器的 ip 地址）

顶级域 DNS 服务器

对于每个顶级域和所有国家的顶级域都有 TLD 服务器(或服务器集群) (TLD 服务器提供了权威 DNS 服务器的 ip 地址)

通用的（.com、.edu、.int 等等）
国家的（.cn、.us、.nl等等）

权威 DNS 服务器

组织机构的DNS服务器，提供组织机构服务器（如Web和mail）可访问的主机和 ip 之间的映射（组织机构可以选择实现自己维护或由某个服务提供商来维护）

本地DNS服务器

严格说来，一个本地DNS服务器并不属于该服务器的层次结构，但它对DNS层次结构是至关重要

主机的本地DNS服务器通常“邻近”本主机。当主机发出DNS请求时，该请求被发往本地DNS服器，它起着代理的作用，并将该请求转发到DNS服务器层次结构中，详细的调用过程如下两种

递归查询

名字解析负担都放在当前联络的名字服务器上，解决方式：迭代查询

迭代查询

根（及各级域名）服务器返回的不是查询结果，而是下一个 DNS 的地址
最后由权威名字服务器给出解析结果

DNS 缓存

为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术

DNS缓存的原理非常简单。在一个请求链中，当某DNS服务器接收一个DNS回答（包含某主机名到 ip 地址的映射）时，它能将映射缓存在本地存储器中
由于主机和主机名与 ip 地址间的映射并不是永久的，DNS服务器在一段时间后（通常设置为两天）将丢弃缓存的信息

记录和报文

资源记录

作用：维护域名 - ip 地址(其它)的映射关系
位置：Name Server的分布式数据库中
RR格式: （Domain_name，Ttl，Type，Class，Value）
- Domain_name: 域名
- Ttl: time to live : 生存时间，决定了资源记录应当从缓存中删除的时间
- Class 类别：对于Internet，值为 IN
- Value 值：可以是数字，域名或ASCII串
- Type 类别：资源记录的类型

对于不同的 Type 类型，转换的方式不同，如下

Type = A：Name 为主机；Value 为 ip 地址
Type = CHAME：Name 为规范名字的别名；Value 为规范名字
Type = NS：Name 为域名；Value 为该领域的权威服务器的域名
Type = MX：Name 为邮件服务器的规范名字的别名；Value 为邮件服务器的规范名字

报文

DNS 只有这两种报文，并且查询和回答报文有着相同的格式

前 12 个字节是首部区域。第一个字段(标识符)是一个 16 比特的数，用于标识该查询（类似于订单号的作用）
问题区域包含着正在进行的查询信息该区域包括：①名字字段 ②类型字段
回答区域包含了对最初请求的名字的资源记录
权威区域包含了其他权威服务器的记录

P2P 应用

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

例子

文件分发 (BitTorrent)
流媒体 (KanKan)
VoIP (Skype)

P2P 体系结构的扩展性

分发时间是所有对等方得到该文件的副本所需要的时间

如图所示，对于客户一服务器体系结构，随着对等方数量的增加，分发时间呈线性增长并且没有界。然而，对于P2P体系结构，最小分发时间不仅总是小于客户 - 服务器体系结构的分发时间，并且对于任意的对等方数量N，总是小于1小时（计算）

因此，具有P2P体系结构的应用程序能够是自扩展的。这种扩展性的直接成因是：对等方除了是比特的消费者外还是它们的重新分发者

BitTorrent 协议

BitTorrent是一种用于文件分发的流行P2P协议【Chao 2011】

torrenl 洪流

参与一个特定文件分发的所有对等方的集合

在一个洪流中的对等方彼此下载等长度的文件块 (chunk) ，典型的块长度为 256KB
当一个对等方首次加入一个洪流时，它没有块随着时间的流逝，它累积了越来越多的块当它下载块时，也为其他对等方上载了多个块。一旦某对等方获得了整个文件，它也许(自私地)离开洪流，或(大公无私地)留在该洪流中并继续向其他对等方上载块
任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中

BitTorrent 运行的过程

概述

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

当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中，假设当一个新的对等方 Alice 加入该洪流时，追踪器随机地从参与对等方的集合中选择对等方的一个子集，并将这些对等方的 ip 地址发送给 Alice

具体过程

在任何给定的时间，每个对等方将具有来自该文件的块的子集，并且不同的对等方具有不同的子集（文件被分成 256KB 的块，每个对等放会用 bitmap 来记录每个块的状态，并相互询问每个邻近对等方它们所具有的块列表）
将使用最稀缺优先技术（最稀缺的块就是那些在她的邻居中副本数量中最少的块）来优先请求哪些块，这样，最稀缺块得到更为迅速的重新分发，其目标是(大致地)均衡每个块在洪流中的副本数量
为了决定她响应哪个请求， BitTorrent 使用了一种机灵的对换算法。根据当前能够以最高速率向她提供数据的邻居，确定以最高速率流入的 4 个邻居并给出其主优先权
每过 10秒将重新确认该 4 个邻居（这 4 个对等方被称为疏通），重要的是，每过 30 秒，她也要随机地选择另外一个邻居并向其发送块，如果发现该块最高速率优于之前选择的 4 个邻居，将会在下个周期替代 4 个邻居中速率最低得那一个（除这 5 个之外，其他块都必须进入到阻塞的状态）

P2P文件共享应用

存在的问题

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

非结构化 P2P

集中化目录
完全分布式
混合体

集中化目录

最初的 Napster 设计，当对等方连接时，它告知中心服务器： ip 地址、内容

存在的问题：文件传输是分散的，而定位内容则是高度集中的

单点故障
性能瓶颈
侵犯版权

查询洪泛：Gnutella

全分布式，没有中心服务器
限制范围的洪泛查询（通常所连接的节点少于10个）
开放文件共享协议
许多 Gnutella 客户端实现了Gnutella协议（类似HTTP有许多的浏览器）

利用不匀称性：KaZaA

每个对等方要么是一个组长，要么隶属于一个组长
组长跟踪其所有的孩子的内容
组长与其他组长联系（转发查询到其他组长、获得其他组长的数据拷贝）

查询过程

客户端向其组长发送关键字匹配描述的方式查询（每个文件有一个散列标识码和一个描述符）
组长用匹配进行响应，对每个匹配：元数据、散列标识码和 ip 地址
如果组长将查询转发给其他组长，其他组长也以匹配进行响应
客户端选择要下载的文件，向拥有文件的对等方发送一个带散列标识码的 HTTP 请求

DHT 结构化 P2P（了解）

树形、环形等

视频流和内容分发网

视频流化服务

视频是一系列的图像，通常以种恒定的速率(如每秒 24、30 张图像)来展现；一幅未压缩、数字编码的图像由像素阵列组成（其中每个像素是由一些比特编码来表示亮度和颜色）

视频流量：占据着互联网大部分的带宽（例如：Netflix, YouTube: 占据37%, 16% 的ISP下行流量）
到目前为止，对流式视频的最为重要的性能度量是平均端到端吞吐量
不同用户拥有不同的能力（例如：有线接入和移动用户；带宽丰富和受限用户）

解决方案：分布式的，应用层面的基础设施

HTTP 流和 DASH

在HTTP 流中，视频只是存储在 HTTP 服务器中作为一个普通的文件、每个文件有一个特定的 URL （尽管 HTTP 流在实践中已经得到广泛部署，，但它具有严重缺陷，即所有客户接收到相同编码的视频）
出现了一种新型基于 HTTP 的流的研发，它常常被称为经 HTTP 的动态适应性流 DASH
在 DASH 中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应于不同的质量水平

服务器

将视频文件分割成多个块
每个块独立存储，编码于不同码率（8-10种）
告示文件：提供不同块的URL

客户端

先获取告示文件
周期性地测量服务器到客户端的带宽
查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
- 如果带宽足够，选择最大码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块（取决于当时的可用带宽）

动态适应性流 DASH 的优点

动态估计带宽、当前缓存情况，DASH 通常能够做到持续播放
减轻服务器的负担，可扩展性强

内容分发网 CDN

面临挑战

服务器如何通过网络向上百万用户同时流化视频内容？

建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频
- 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
- 单点故障点，性能瓶颈
评述：相当简单，但是这个方法不可扩展
通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
- 将CDN服务器深入到许多接入网（更接近用户，数量多，离用户近，管理困难）
- 部署在少数(10个左右)关键位置，如将服务器簇安装于 POP 附近

CDN 概述

CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储视频(和其他类型的 Web 内容，包括文档、图片和音频)的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置

CDN 可以是专用 CDN，即它由内容提供商自己所拥有
CDN 可以是第三方 CDN，它代表多个内容提供商分发内容

CDN 通常采用两种不同的服务器安置原则

深入，该原则是通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。其目标是靠近端用户，通过减少端用户和 CDN 集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量
邀请做客，该原则是通过在少量（例如10个）关键位置建造大集群来邀请到 ISP 做客。不是将集群放在接入ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点(XP)
与深入设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价

CDN 操作过程

用户访问位于 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 域的主机名，如 a11O5.kingedn.com
DNS 请求进入了 KingCDN 专用 DNS 基础设施。用户的 LDNS 则发送第二个请求，此时是对 a11O5.kingedn.com 的 DNS 请求，KingCDN 的DNS系统最终向LDNS 返回 KingCDN 内容服务器的 IP 地址。所以正是在这里，在 KingCDN 的 DNS 系统中，指定了 CDN 服务器，客户将能够从这台服务器接收到它的内容
LDNS 向用户主机转发内容服务 CDN 节点的 IP 地址
一旦客户收到 KingCDN 内容服务器的 IP 地址，它与具有该 IP 地址的服务器创建了一条直接的TCP连接，并且发出对该视频的 HTTP 请求。如果使用了DASH 服务器将首先向客户发送具有 URL 列表的告示文件，每个URL对应视频的每个版本，并且客户将动态地选择来自不同版本的块

集群选择策略

任何CDN部署，其核心是集群选择策略，即动态地将客户定向到 CDN 中的某个服务器集群或数据中心的机制

一种简单的策略是指派客户到地理上最为邻近的集群。使用商用地理位置数据库，每个 LDNS IP地址都映射到一个地理位置。此外，这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的客户指派相同的集群
为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量。例如，CDN能够让它的每个集群周期性地向位于全世界的所有 LDNS 发送探测分组（例如，ping报文或DNS请求）
给客户端一个CDN服务器的列表，让客户端来选择CDN服务器

套接字编程

Socket 编程

应用进程使用传输层提供的服务才能够交换报文，实现应用协议，实现应用

地点：界面上的 SAP (Socket）
方式：Socket API

套接字：分布式应用进程之间的门，传输层协议提供的端到端

传输层服务的 socket 类型

TCP：可靠的、字节流的服务
UDP：不可靠（数据UDP数据报）服务

UDP 套接字编程

为客户端和服务器提供不可靠的字节组的传送服务，在客户端和服务器之间没有连接，没有握手（传送的数据可能乱序，也可能丢失）

发送端在每一个报文中明确地指定目标的 IP 地址和端口号
服务器必须从收到的分组中提取出发送端的 IP 地址和端口号

演示 UDP 套接字编程

客户从其键盘读取一行字符（数据）并将该数据向服务器发送
服务器接收该数据并将这些字符转换为大写
服务器将修改的数据发送给客户
客户接收修改的数据并在其监视器上将该行显示出来

TCP 套接字编程

在客户端和服务器进程之间提供了可靠的、字节流（管道）

服务器首先运行，等待连接建立

创建 Welcome socket
和本地端口捆绑
在 Welcome socket 上阻塞式等待接收用户的连接

客户端主动和服务器建立连接

创建客户端本地套接字（隐式捆绑到本地port）指定服务器进程的 IP 地址和端口号，与服务器进程连接
连接API调用有效时，客户端 IP 与服务器建立了TCP连接

当与客户端连接请求到来时，服务器接受来自用户端的请求，解除阻塞式等待，返回一个新的socket（与 Welcome socket 不一样）

与客户端通信，允许服务器与多个客户端通信
使用源 IP 和源端口来区分不同的客户端

注意：区别下欢迎套接字和连接套接字

演示 UDP 套接字编程

客户从其键盘读取一行字符（数据）并将该数据向服务器发送
服务器接收该数据并将这些字符转换为大写
服务器将修改的数据发送给客户
客户接收修改的数据并在其监视器上将该行显示出来