《计算机网络——自顶向下方法》学习笔记——应用层

应用层

应用层协议原理

网络应用程序体系结构

应用程序体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。
两种主流体系结构：
客户-服务器体系结构、对等（P2P）体系结构。

客户 — 服务器体系结构（client-server architecture）
有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。

特征：

客户相互之间不直接通信；
该服务器具有固定的、周知的地址，该地址称为IP地址。

具有该体系结构的应用程序包括：Web、FTP、Telnet和电子邮件。

配置大量主机的数据中心（data center）常被用于创建强大的虚拟服务器。

最为流行的因特网服务——如搜索引擎（谷歌、Bing、百度）、因特网商务（亚马逊、e-Bay、阿里巴巴）、基于Web的电子邮件（Gmail、雅虎邮件）、社交网络（脸书、Instagram、推特、微信），就应用了一个或多个数据中心。

P2P体系结构（P2P architecture）
对位于数据中心的专用服务器有最小的（或者没有）依赖。

应用程序在间断链接的主机对之间使用直接通信，这些主机对被称为对等方。

特性：自扩展性（self-scalability）。

P2P体系结构也是有成本效率的，因为它们通常不需要庞大的服务器基础和服务器带宽（这与具有数据中心的客户-服务器设计形成鲜明对比）。

进程通信

用操作系统的术语来说，进行通信的实际上是进程（process）而不是程序。

在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。
发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行响应。

1. 客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。

对每队通信进程，通常将这两个进程之一标识为客户（client），而另一个进程标识为服务器（server）。

定义客户和服务器进程如下：
在一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

2. 进程与计算机网络之间的接口

从一个进程向另一个进程发送的报文必须通过下面的网络。
进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。

套接字是同一台主机内应用层与运输层之间的接口。

由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface, API）。

3. 进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。

为了标识该接收进程，需要定义两种信息：主机的地址；在目的主机中指定接收进程的标识符。

在因特网中，主机由其IP地址（IP address）标识。

目的地端口号（port number）用于这个目的。

所有因特网标准协议的周知端口号的列表在http://www.iana.org找到。

可供应用程序使用的运输服务

可以从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。

1. 可靠数据传输

数据丢失可能会造成灾难性的后果。
为了支持这些应用，必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。
如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输（reliable data transfer）。

当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用（loss-tolerant application）所接收。如交谈式音频/视频，它们能够承受一定量的数据丢失。

2. 吞吐量

吞吐量就是发送进程能够向接收进程交付比特的速率。

具有吞吐量要求的应用称作被称为带宽敏感的应用（bandwidth-sensitive application）。

带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic aoolication）能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。
电子邮件、文件传送以及Web传送都属于弹性应用。

3. 定时

运输层协议也能提供定时保证。

比特传输时间保证。

4. 安全性

运输协议能够为应用程序提供一种或多种安全性服务。

运输协议还能提供除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别。

因特网提供的运输服务

因特网为应用程序提供两个运输层协议，即UDP和TCP。

1. TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务。

面向连接的服务：

在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。
在握手阶段后，一个TCP连接（TCP connection）就在两个进程的套接字之间建立了。

可靠的数据传送服务

通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。

TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。

2. UDP服务

UDP是一种不提供不必要服务的请量级运输协议，它仅提供最小服务。

UDP是无连接的，因此在两个进程通信没有握手过程。

UDP协议提供一种不可靠数据传输服务，也就是说，当进程将一个报文发送进UDP套接字，UDP协议并不保证该报文将到达接收进程。

UDP没有包括樱色控制机制，所有UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

3. 因特网运输协议所不提供的服务

不提供吞吐量或定时保证

应用层协议

应用层协议（application-layer protocal）定义了运行在不同端系统上的应用程序进程如何相互传递报文。

应用层协议定义了：

交换的报文类型，例如请求报文和响应报文。
各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
字段的语义，即这些字段中的信息的含义。
确定一个进程何时以及如何发送报文，对报文进行响应的规则。

应用层协议只是网络应用的一部分。

Web的应用层协议是HTTP，它定义了在浏览器和Web服务器之间传输的报文格式和序列。因此，HTTP只是Web应用的一个部分。

Web和HTTP

HTTP概况

Web的应用层协议是超文本传输协议（HyperText Transfer protocal, HTTP），它是Web的核心，在[ RFC 1945 ]和[ RFC 2616 ]中进行了定义。

HTTP由两个程序实现：一个客户程序和一个服务器程序。
客户程序和服务器 程序运行在不同的端系统中，通过交换HTTP报文进行会话。
HTTP定义了这些报文的结构以及客户和服务器进行报文交换的地方。

Web页面（Web page）（也叫文档）是由对象组成的。
一个对象（object）只是一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件，且它们可通过一个URL地址寻址。
多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。

HTML基本文件通过对象的URL地址引用页面中的其他对象。
每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

Web浏览器（Web browser）实现了HTTP的客户端，在Web环境中交替使用“浏览器”和“客户”这两个术语。
Web服务器（Web server）实现了HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。

HTTP使用TCP作为它的支撑运输协议（而不是在UDP上运行）。
HTTP客户首先发起一个服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。

服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。

非持续连接和持续连接

非持续连接（non-persistent connection）：每个请求/响应对是经一个单独TCP连接发送。

持续连接（persistent connection）：所有的请求及其响应经相同的TCP连接发送。

1. 采用非持续连接的HTTP

非持续连续有一些缺点：
第一，必须为每一个请求的对象建立和维护一个全新的连接。
第二，每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，两一个RTT用于请求和接收一个对象。

2. 采用持续连接的HTTP

在持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。

HTTP报文格式

HTTP报文有两种：
请求报文和响应报文。

1. HTTP请求报文

// 请求行
GET /somedir/page.html HTTP/1.1
// 指明对象所在主机。Web代理高速缓存要求
Host: www.someschool.edu
// 要求服务器发送完请求的对象后，关闭连接
Connection: close
// 用户代理
User-agent: Mozilla/5.0
// 语言版本
Accept-language: fr

HTTP请求报文的第一行叫作请求行（request line），其后继的行叫作首部行（header line）。
请求行有3个字段：方法字段、URL字段和HTTP版本字段。
方法字段的几种值：GET、POST、HEAD、PUT和DELETE。
在URL字段带有请求对象的标识。

2. HTTP响应报文

// 初始状态行
// 协议版本	状态码 状态信息
HTTP/1.1 200 OK
// 1
// 发送完报文后关闭该TCP连接
Connection: close
// 2
// 服务器产生并发送该响应报文的日期和时间
// 服务器从其文件系统检索到该对象，将其插入响应报文，发送该响应报文的时间
Date: Tue, 18 Aug 2015 15:44:04 GMT
// 3
// 该报文由xx服务器产生
Server: Apache/2.2.3 (CentOS)
// 4
// 对象创建或最后修改的日期和时间
// 对既可能在本地客户，也可能在网络缓存服务器的对象缓存非常重要
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
// 5
Content-Length: 6821
// 6
Content-Type: text/html
// entity
(data data data data data ...)

HTTP响应报文的三个部分：
初始状态行（status line）、首部行（header line），实体体（entity body）。
实体体部分是报文的主要部分，即它包含了所请求的对象本身。
状态行的3个字段：协议版本字段、状态码和相应状态信息。

用户与服务器的交互：cookie

cookie在[RFC 6265] 中定义，它允许站点对用户仅需跟踪。

cookie技术有4个组件：
（1）在HTTP响应报文中的一个cookie首部行；
（2）在HTTP请求报文中的一个cookie首部行；
（3）在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理；
（4）位于Web站点的一个后端数据库。

Web缓存

Web缓存器（Web cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。

Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。

条件GET方法

条件GET（conditional GET）方法：HTTP协议的一种机制，运行缓存器证实它的对象是最新的。

因特网中的电子邮件

电子邮件是一种异步通信媒介，即当人们方便时就可以收发邮件，不必与他人的计划进行协调。
电子邮件更为快速并且易于分发，而且价格便宜。
现代电子邮件具有许多强大的特性，包括具有附件、超链接、HTML格式文本和图片的报文。

因特网电子邮件有3个主要组成部分：用户代理（user agent）、邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocal, SMTP）。

用户代理允许用户阅读、回复、转发、保存和撰写报文。
邮件服务器形成了电子邮件体系结构的核心。每个接收方（如Bob）在其中的某个邮件服务器上有一个邮箱（mailbox）。
Bob的邮箱管理和维护着发送给他的报文。

SMTP 是因特网电子邮件中主要的应用层协议。
它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。

SMTP

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

SMTP一般不适用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。

与HTTP的对比

HTTP从Web服务器向Web客户（通常是一个浏览器）传送文件（也称为对象）；
SMTP从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。

HTTP与SMTP之间的重要的区别：

第一，HTTP主要是一个拉协议（pull protocal），即在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息。
SMTP基本上是一个推协议（push protocol），即发送邮件服务器把文件推向接收邮件服务器。

第二，SMTP要求每个报文（包括它们的体）采用7比特ASCII码格式。
HTTP数据则不受这种限制。

第三，HTTP把每个对象封装到它自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文之中。

邮件访问协议

目前流行的一些邮件访问协议，包括第三版的邮局协议（PostOffice Protocal-Version 3, POP3）、因特网邮件访问协议（Internet Mail Access Protocol, IMAP）以及HTTP。

1. POP3

POP3是一个极为简单的邮件访问协议，由RFC 1939进行定义。
POP3按照三个阶段进行工作：特许（authorization）、事务处理以及更新。
在第一个阶段即特许阶段，用户代理发送（以明文形式）用户名和口令以鉴别用户。
在第二个阶段即事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。
在第三个阶段即更新阶段，它出现在客户发出了quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文。

2. IMAP

IMAP是一个邮件访问协议。

IMAP服务器把每个报文与一个文件夹联系起来；
当报文第一次到达服务器时，它与收件人的INBOX文件夹向关联。收件人则能把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。

IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。
IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件取查询匹配的邮件。

IMAP的另一个重要特性是它具有允许用户代理获取报文某些部分的命令。

3. 基于Web的电子邮件

基于Web的电子邮件，使用这种服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。

当一个收件人【如Bob】，
从他的邮箱中访问一个报文时，
该电子邮件报文从Bob的邮件服务器发送到他的浏览器，使用HTTP。
当发件人要发送一封电子邮件报文时，该电子邮件报文从发件人的用户代理到其邮件服务器，使用HTTP。
邮件服务器间仍然为SMTP。

DNS：因特网的目录服务

主机的一种标识方法是用它的主机名（hostname），如www.facebook.com、www.google.com、gain.cs.umass.edu 以及cis.poly.edu 等，这些名字便于记忆也乐于被人们接受。

主机也可以使用所谓IP地址（IP address）进行标识。

DNS提供的服务

域名服务器（Domain Name System, DNS）的主要任务：能进行主机名到IP地址转换的目录服务。

DNS是：1）一个由分层的DNS服务器（DNS server）实现的分别式数据库； 2）一个使得主机能够查询分布式数据库的应用层协议。

DNS服务器通常是运行BIND（Berkeley Internet Name Domain）软件[ BIND 2012 ] 的UNIX机器。
DNS协议运行在UDP之上，使用53号端口。

DNS通常是由其他应用层协议所使用的，报价HTTP、SMTP和FTP，将用户提供的主机名解析为IP地址。

DNS还提供了一些重要的服务：

主机别名（host aliasing）。
邮件服务器别名（mail server aliasing）。
负载分配（load distribution）。

DNS工作机理概述

DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映射。
在这种集中式设计中，客户直接将所有查询直接发往单一的DNS服务器，同时该DNS服务器之间对所有的查询客户做出响应。

这种几种式设计的问题包括：

单点故障（a single point of failure）。
通信容量（traffic volume）。
远距离的集中式数据库（distant  centralized database）。
维护（maintenance）。

1. 分布式、层次数据库

3种类型的DNS服务器：根DNS服务器、顶级域（Top-Level Domain, TLD）DNS服务器和权威DNS服务器。

- 根DNS服务器，根名字服务器提供顶级域服务器的Ip地址
- 顶级域服务器，每个顶级域和所有国家的顶级域，都有顶级域服务器。顶级域服务器提供权威DNS服务器的Ip地址。
- 权威DNS服务器，在因特网上具有公共可访问主机的每个组织机构须提供公共可访问的DNS记录。

图2-18中，从请求主机到本地DNS服务器的查询是递归的
本地DNS服务器发出的查询是迭代的
图2-19中，所有查询都是递归的

2. DNS缓存

DNS缓存（DNS caching）。
在一个请求链中，当某DNS服务器接收一个DNS回答（例如，包含某个主机名到IP地址的映射）时，它能将映射缓存在本地存储器中。

缓存信息超过一定期限自动失效。

DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（Resource Record, RR），RR提供了主机名到IP地址的映射。

资源记录是一个包含了下列字段的4元组：

(Name, Value, Type, TTL) TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。

1. DNS报文

DNS报文：查询和回答报文。

前12个字节是首部区域。
问题区域包含着正在进行的查询信息。
在来自DNS服务器的回答中，回答区域包含了对最初请求的名字的资源记录。
权威区域包含了其他权威服务器的记录。
附加区域包含了其他有帮助的记录。

2. 在DNS数据库中插入记录

注册登记机构（registrar）是一个商业实体，它验证该域名的唯一性，将该域名输入DNS数据库，对提供的服务收取少量费用。

http://www.internic.net上可找到授权的注册登记机构的列表。

P2P文件分发

最为流行的P2P文件分发协议是BitTorrent。

在P2P文件分发中，每个对等方能向任何其他对等方重新分发它已经收到的该文件的任何部分，从而在分发过程协助服务器

1. P2P体系结构的扩展性

将一个文件分发给一个固定对等方集合。

服务器和对等方使用接入链路与因特网相连。
u_{s}表示服务器接入链路的上载速率。
u_{i}表示第ｉ对等方接入链路的上载速率。
d_{i}表示第ｉ对等方接入链路的下载速率。
Ｆ表示被分发的文件长度，以比特计，Ｎ表示要获得的该文件副本的对等方的数量。
分发时间是所有Ｎ个对等方得到该文件的副本所需要的时间。

2. BitTorrent

BitTorrent是一种用于文件分发的流行P2P协议。

参与一个文件分发的所有对等方的集合被称为一个洪流。
在一个洪流中的对等方彼此下载等长度的文件块，典型的块长度为256KB。
一个对等方首次加入洪流时，没有块。
随着时间流逝，它累积了越来越多的块。
当他下载块时，也为其它对等方上载了多个块。

每个洪流有一个基础设施节点，称为追踪器。
一个对等方加入洪流时，它向追踪器注册自己，周期性地通知追踪器它仍在该洪流中。
追踪器跟踪参与在洪流中的对等方。

例：
一个新的对等方Alice加入该洪流时，追踪器随机地从参与对等方集合中选择对等方的一个子集，将子集中每个对等方IP地址发给Alice，
Alice试图与所有对等方建立并行TCP连接。
称所有这样与Alice成功创建一个TCP连接的对等方为"邻近对等方"。
随着时间流逝，这些对等方中的某些可能离开，其他对等方可能试图创建与Alice的TCP连接。

任何时间，每个对等方具有来自该文件的块的子集，且不同对等方有不同子集。
Alice周期性地询问每个邻近对等方它们所具有的块列表。
如Alice有L个不同的邻居，她将获得L个块列表。
有了此信息，Alice将对她当前还没有的块发出请求。

Alice依据已经具有的块的子集和邻居块的信息，做决定：

• 应当从她的邻居请求那些块
  使用最稀缺优先。
  针对她没有的块在她的邻居中决定最稀缺的块【在邻居中副本最少的块】
  先请求最稀缺的块。

• 应当向哪些向她请求块的邻居发送块
  Alice依据当前能够以最高速率向她提供数据的邻居，给出其优先权。
  Alice对她的每个邻居都持续测量接收到比特的速率，并确定以最高速率流入的４个邻居，
  每过１０秒，重新计算该速率并可能修改这４个对等方的集合。

这４个对等方被称为疏通。
每过30秒，她要随机地选择另外一个邻居并向其发送块。将这个被随机选择的对等方称为Bob。因为Alice向Bob发送数据，她可能称为Bob前４位上载者之一，这样的话，Bob将开始向Alice发送数据。如Bob向Alice发送数据的速率足够高，Bob接下来也能称为Alice的前４位上载者。

每过30秒，Alice随机选择一名新的对换伴侣并开始与那位伴侣对换。
如两名对等方都满足此对换，它们将对方放入其前4位列表并继续与对方进行对换，直到该对等方之一发现一个更好的伴侣为止。
除了这５个对等方【前４个对等方和一个试探的对等方】的所有其他相邻对等方均被阻塞，它们不能从Alice接收任何块。

视频流和内容分发网

因特网视频

在流式存储视频应用中，基础的媒体是预先录制的视频，例如电影、电视节目、录制好的体育事件或录制好的用户生成的视频。
这些预先录制好的视频放置在服务器上，用户按需向这些服务器发送请求来观看视频。
一些提供流式视频的因特网公司：包括Netflix、YouTube（谷歌）、亚马逊和优酷。

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

视频的一个重要特征是它能够被压缩，因而可用比特率来权衡视频质量。

网络的观点看，视频最为突出的特征是它的高比特率。
压缩的因特网视频的比特率范围通常从用于低质量视频的100kbps，到用于流式高分辨率电影的超过3Mbps，再到用于4K流式展望的超过10Mbps。

对流式视频的最为重要的性能度量是平均端到端吞吐量。

HTTP 流和 DASH

在HTTP流中，视频只是存储在HTTP服务器中作为一个普通的文件，每个文件有一个特定的URL。

用户要看该视频时，

客户与服务器创建一个TCP连接并发送对该URL的HTTP GET请求。
服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个HTTP响应报文中发送该视频文件。
在客户一侧，字节被收集在客户应用缓存中。
一旦该缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放。

流式视频应用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩且在用户屏幕上展现。因此，流式视频应用接收到视频就播放，同时缓存该视频后面部分的帧。

HTTP流缺陷：

所有客户接收到相同编码的视频，尽管对不同的客户或者对于相同客户的不同时间而言，客户可用的带宽大小有很大不同。

经HTTP的动态适应性流（Dynamic Adaptive Streaming over HTTP , DASH）

在DASH中，视频编码为几个不同的版本，其中每个版本有不同的比特率，对应于不同的质量水平。
客户动态地请求来自不同版本且长度为几秒的视频段数据块。
当可用带宽量较高时，客户选择高速率版本的块。
可用带宽量较低时，客户自然地选择来自低速率版本的块。
客户用HTTP GET请求报文一次选择一个不同的块。

ＤASH允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频。

使用DASH后，每个视频版本存储在HTTP服务器中，每个版本有一个不同的URL。

HTTP服务器也有一个告示文件（manifest file），为每个版本提供了一个URL及其比特率。

客户先请求该告示文件且得知各个版本。
客户通过在HTTP GET请求报文中对每块指定一个URL和一个字节范围，一次选择一块。
在下载块的同时，客户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。

如客户缓存的视频很多，且测量的接收带宽较高，它将选择一个高速率的版本。
如客户缓存的视频少，测量的接收带宽较低，它将选择一个低速率的版本。

内容分发网

对因特网视频公司，
提供流式视频服务最为直接的方法是建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频。

这种方法存在三个问题：

• 如客户远离数据中心，因为链路多，总吞吐量有最低链路吞吐量决定，因而造成服务时延长。
• 流行的视频可能经过相同的通信链路发送了多次，浪费了网络带宽，视频公司也将向ISP运营商支付更多费用。
• 如数据中心或其向因特网链路崩溃，整个服务崩溃

内容分发网（Content Distribution Network, CDN）

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

CDN 可以专用CDN（private CDN），即由内容提供商自己拥有。
另一种CDN可以是第三方CDN（third-party CDN），它代表多个内容提供商分发内容。

内容分发网通常采用两种不同的服务器安置原则[ Huang 2008]：

• 深入。
  通过在遍及全球的接入ISP中部署服务器集群你来深入到ISP的接入网中。
  目标是靠近端用户，通过减少端用户和内容分发网集群之间链路和路由器的数量，从而改善时延和吞吐量。
  高度分布式设计，维护和管理集群的任务称为挑战。
• 邀请做客
  通过少量关键位置构造大集群你来邀请到ISP做客。
  不是将集群放在接入ISP中。
  这些内容分发网通常将它们的集群放置在因特网交换点。
  维护和管理开销低。
  对端用户可能产生较高时延和较低吞吐量。

一旦CDN集群准备就绪，就可跨集群复制内容。
CDN可能不希望将每个视频的副本放在每个集群中，

许多CDN没有将视频推入它们的集群，而是使用一种简单的拉策略：
如客户向一个未存储该视频的集群请求某视频，则该集群检索该视频，向客户流式传输视频的同时在本地存储一个副本。
类似因特网缓存，集群存储器变满时，删除不经常请求的视频。

1. CDN操作

用户主机中的一个浏览器指令检索一个特定的视频时，
CDN必须截获该请求，以便能：

• 确定此时适合用于该客户的CDN服务器集群
• 将客户的请求重定向到该集群的某台服务器

大多数CDN利用DNS来截获和重定向请求，
例：
假定一个内容提供商NetCinema,雇佣了第三方CDN公司KingCDN来向其客户分发视频。
在NetCinema的Web网页上，它的每个视频都被指派了一个URL，该URL包括了字符串"video"及该视频本身的独特标识符；

如转换器7可以指派为 http://video.netcinema.com/6y7b23v
接下来出现以下６步：

- 用户访问位于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域的主机名，如a1105.b.com
	
- 从这时起，DNS请求进入了KingCDN专用DNS基础设施。
	用户的LDNS则发送第二个请求，此时是对a1105.b.com的DNS请求，
	KingCDN的DNS系统最终向LDNS返回KingCDN内容服务器的IP地址。
	
- LDNS向用户主机转发内容服务CDN节点的IP地址

- 一旦客户收到KingCDN内容服务器的IP地址，
	它与具有该IP地址的服务器创建了一条直接的TCP连接，且发出对该视频的HTTP GET请求，
	如使用了DASH，服务器将首先向客户发送具有URL列表的告示文件，
	每个URL对应视频的每个版本，且客户将动态选择来自不同版本的块。

2. 集群选择策略

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

经过客户的DNS查找，CDN得知了该客户的LDNS服务器的IP地址。
得知该IP地址后，CDN需要基于该IP地址选择一个适当的集群。
CDN一般采用专用的集群选择策略。

一种简单的策略是指派客户到地理上最为邻近（geographically closest）的集群。

每个LDNS IP地址映射到一个地理位置。

从一个特殊的LDNS接收到一个DNS请求时，CDN选择地理上最为接近的集群，即离LDNS最少几千米远的集群。

为了基于当前流量条件为客户决定最好的集群，CDN能对其集群和客户之间的时延和丢包性能执行周期性的实时测量（real-time measurement）。

学习案例：Netflix、YouTube 和“看看”

Netflix

Netflix视频分发两个主要部件：亚马逊云和它自己的专用CDN基础设施。

Netflix有一个网站来处理用户登录，注册，计费，浏览，搜索，电影推荐。

这个网站及其关联的后端数据库完全运行在亚马逊云中的亚马逊服务器上。

亚马逊云处理下列关键功能：

• 内容摄取
  在向用户分发某电影前，需先获取和处理该电影。
  接收电影母带，将其上载到亚马逊云的主机上。
• 内容处理
  亚马逊云中的机器为每部电影生成许多不同格式。
  每种格式和比特率都生成一种不同的版本，允许使用DASH经HTTP适应性播放流
• 向其CDN上载版本
  一旦某电影的所有版本均已生成，在亚马逊云中的主机向其CDN上载这些版本

YouTube

YouTube应用HTTP流，经常使少量的不同版本为一个视频可用，每个具有不同的比特率和对应的指令等级。

YouTube没有应用适应性流（例如DASH），而要求用户人工选择一个版本。

为了节省那些被重定位或提前终止而浪费的带宽和服务器资源，YouTube在获取视频的目标量之后，使用HTTP字节范围请求来现在传输的数据流。

看看

由专用CDN运行的专用服务器以流的方式向客户发视频。
内容提供商需要支付服务器硬件和分发视频的带宽付费，因此代价较大。

P2P流式视频非常类似于 BitTorrent 文件下载。
一个对等方要看一个视频时，它联系一个跟踪器，以发现在系统中具有该视频副本的其他对等方。
请求的对等方并行地从具有该文件的其他对等方请求该视频的块。

综合，CDN-P2P，利用P2P足够时，CDN不参与。
不足够时，CDN参与视频分发，内容提供。
经因特网大规模按需提供视频。

套接字编程：生成网络应用

网络应用程序有两类。
一类由协议标准（如一个RFC或某种其他标准文档）中所定义的操作的实现。
服务器－客户端由不同团队开发。
采用标准协议通信，采用协议规定端口

另一类，专用网络应用程序。
服务器－客户端由同一团队开发。
采用自定义协议通信，采用自定义端口

UDP套接字编程

应用程序开发者在套接字的应用层一侧可控制所有东西，然而，它几乎无法控制运输层一侧。

当生成一个套接字时，为它分配一个称为端口号（port number）的标识符。

发送进程为分组附上目的地址，由目的主机的IP地址和目的地套接字的端口号组成。
发送方的源地址也是由源主机的IP地址和源套接字的端口号组成，该源地址也要附在分组之上。

将源地址附在分组上通常由操作系统自动完成。

使用下列简单的客户-服务器应用程序来演示对于UDP和TCP的套接字编程：

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

TCP套接字编程

TCP是一个面向连接的协议。
在客户和服务器能够开始互相发送数据之前，它们先要握手和创建一个TCP连接。

客户具有向服务器发起接触的任务。
服务器需准备好。
即：
服务器在客户试图接触前需运行起来
服务器程序需有一扇特殊的门【套接字】

随着服务器进程的运行，客户进程能向服务器发起一个TCP连接。
客户程序通过创建一个TCP套接字完成。
客户生成其TCP套接字时，指定了服务器中欢迎套接字的地址，即服务器主机的IP地址和其套接字端口号。
生成其套接字后，客户发起三次握手，创建与服务器的一个TCP连接。
发生在运输层的三次握手，对客户和服务器程序是完全透明的。

三次握手期间，客户进程敲服务器进程的欢迎之门。
服务器听到敲门声，生成一扇新门（一个新套接字），专门用于特定的客户。

欢迎之门是一个称为 serverSocket 的TCP套接字对象；它是专门对客户进行连接的新生成的套接字，称为连接套接字（connectionSocket）。

欢迎套接字【与服务器通信的客户的起始接触点】
连接套接字【为与每个客户通信而生成的套接字】

学习参考资料：

《计算机网络——自顶向下方法》 第7版