第二章 应用层

第二章 应用层

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

与网络体系结构相区别

• 客户-服务器体系结构

  • 服务器与客户

    服务器是：总是打开的主机，服务于来自客户的主机的请求

  • 特点

    • 客户相互之间不直接通信
    • 服务器具有固定的、周知的地址

  • 常用应用程序

    Web、FTP、Telnet和电子邮件

  • 存在的问题

    • 常常会出现一台单独的服务器主机跟不上它所有客户请求的情况

• 对等(P2P)体系结构

  对位于数据中心的专用服务器有最小的（或者没有）依赖，应用程序在间断连接的主机对（对等方）之间直接通信

  • 特点

    自扩展性：随着用户数量的增加而增强系统的资源和容量，从而更好地满足用户的需求。

  • 存在的问题

    用由于高度非集中式结构，面临安全性、性能和可靠性等挑战

• 混合体系结构

  结合了客户－服务器和 P2P 元素

2.1.2 进程通信

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

1.客户和服务器进程

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

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

2.进程与计算机网络之问的接口
套接字：同一台主机内应用层与运输层之间的接口。是用于建立网络应用程序的可编程接口。

3.进程寻址

标识接收进程的信息：

• 主机的地址——IP地址
• 在目的主机中指定接收进程的标识符——端口号(port number)

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

1.可靠数据传输

必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。

• 对于某些应用，数据丢失可能会造成灾难性的后果，所以必须要进行可靠数据传输。

• 有些应用可以容忍数据的丢失，发送进程发送的某些数据可能到达不了接收进程。

2.吞吐量

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

运输层协议能够以某种特定的速率提供确保的可用吞吐量。

• 带宽敏感应用

  具有吞吐量要求的应用程序

  如果遇到了运输协议不能提供所需吞吐量的情况，那么应用程序将：

  • 较低的速率进行编码(也就是每秒传输的比特减少，传输数据的质量下降)，采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码
  • 放弃发送

• 弹性应用

  根据当时可用的带宽或多或少地利用可供使用的吞吐量

3.定时

• 交互式实时应用程序

  对数据交付有严格的时间限制

• 非实时应用

4.安全性

• 机密性
• 数据完整性
• 端点鉴别

2.1.4 因特网提供的运输服务

1.TCP服务

• 面向连接的服务

  在应用层数据报文开始流动之前， TCP 让客户和服务器互相交换运输层控制信息。 ——握手过程。

  握手完成后，一个TCP连接就成功建立。然后就可以开始进行报文收发。

  结束了报文收发时，必须拆除连接。

  握手建立连接→TCP连接成功建立→报文收发→连接拆除

• 可靠的数据传送服务

  依靠 TCP 将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。

• 拥塞控制机制

  当发送方和接收方之间的网络出现拥塞时，TCP 的拥塞控制机制会抑制发送进程（客户或服务器）。

2.UDP服务

不提供不必要服务的轻量级运输协议，它仅提供最小服务。

• 无连接服务
• 不可靠数据传送服务
• 无拥塞控制机制

3.安全性

安全套接字层(SSL)，SSL并非第三种因特网运输协议，而是对TCP的加强。SSL 加强后的 TCP 不仅能够做传统的 TCP 所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。

发送进程发送明文数据→SSL接收到数据，对数据进行加密并将加密的数据传递给TCP套接字→套接字将加密数据传递给SSL→SSL对加密数据进行解密→SSL通过SSL套接字将加密数据传递给接收进程。

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

• 吞吐量
• 定时保证

2.1.5 应用层协议

定义了运行在不同端系统上的应用程序进程如何相互传递报文。

• 交换的报文类型
• 各种报文类型的语法
• 字段的语义
• 确定一个进程何时以及如何发送报文，对报文进行响应的规则

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

2.1.6 网络应用

Web 、文件传输、电子邮件、目录服务、流式视频和 P2P

2.2 Web 和 HTTP

2.2.1 HTTP概况

1.概况

• Web页面

  由对象组成，比如：一个 HTML 文件 、一个 JPEG 图形 一个 Java 小程序或一个视频片段这样的文件，且它们可通过一个 RL 地址寻址

  • 一个HTML基本文件

    HTML基本文件通过对象的URL 地址引用页面中的其他对象

  • 几个引用对象

• Web浏览器

  HTTP客户端

• Web服务器

  HTTP服务器端，存储Web对象

2.应用层协议——超文本传输协议(HTTP)

(1) HTTP由两个程序实现：

• 客户程序
• 服务器程序
• HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式(Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送Web 页面的方式)。

(2)支撑运输协议：

• TCP

(3)HTTP请求流程

HTTP客户发起一个与服务器的TCP连接→连接建立→客户向套接字接口发送HTTP请求报文→套接字访问TCP→服务器从套接字接口接收HTTP请求报文

(4) 无状态协议

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

2.2.2 非持续连接和持续连接

1.非持续连接

每个请求/响应对经一个单独的 TCP 连接发送

2.持续连接

所有的请求及其响应经相同的 TCP 连接发送

3.HTTP的不同连接方式

• 非持续连接
  (注：在建立TCP连接时，客户端和服务器都需要知道彼此的端口号，以确保连接的双向通信。客户端将其源端口号发送到服务器，以便服务器知道将响应发送到哪个端口。)

在请求数据的时候可以采用多线程的方式进行并行的TCP连接，每一条连接处理一个请求响应事物。

===>请求时间

• 往返时间(RTT)：一个短分组从客户到服务器然后再返回客户所花费的时间。
  • 分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延
• “三次握手”：
  • 客户向服务器发送一个小 TCP 报文段，服务器用一个小 TCP 报文段做出确认和响应，最后，客户向服务器返回确认并发送请求报文。
• 总time：
  • 两个 RTT 加上服务器传输 HTML 文件的时间

缺点：

• 必须为每一个请求的对象建立和维护一个全新的连接

• 每一个对象经受两倍 RTT 的交付时延，即一个 RTT 用于创建 TCP， 另一个RTT 用于请求和接收一个对象

• 持续连接

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

  如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用， HTTP 服务器就关闭该连接。

2.2.3 HTTP报文格式

1.HTTP请求报文

通用格式如下：

• 请求行：HTTP请求报文的第一行

  • 方法字段
    • GET POST HEAD PUT DELETE
  • URL字段
    • 带有请求对象的标识
  • HTTP版本字段

• 首部行：后继的行

  • Host
    • 指明了对象所在的主机
  • Connection
    • close：非持续连接
  • User-agent
    • 用户代理: 即向服务器发送请求的浏览器的类型
    • 服务器可以有效地为不同类型的用户代理实际发送相同对象的不同版本（每个版本都有相同的 URL 寻址）
  • Accept-language
    • 首部行表示用户想得到该对象的×语版本，如果服务器中有这样的对象的话）；否则，服务器应当发送它的默认版本。

• 实体体

  • GET方法——为空
  • POST方法——为用户在表单字段中的输入值

  除了在实体体中使用POST方法传输数据之外，还可以使用GET方法在所请求的URL中包括输入的数据。

2.HTTP响应报文

• 状态行

  • 协议版本字段

  • 状态码
    

  • 相应状态信息

• 首部行

  • Connection

    • close：非持续连接，发送完报文之后将关闭该TCP连接。
    • keep-alive：说明为持续连接。

  • Data

    • 首部行指示服务器产生并发送该响应报文的日期和时间

      是服务器从它的文件系统中检索到该对象，将该对象插入响应报文，并发送该响应报文的时间

  • Server

    • 产生报文的服务器

  • Last- Modified

    • 首部行指示了对象创建或者最后修改的日期和时间

  • Content-Length

    • 首部行指示了被发送对象中的字节数

  • Content- Type

    • 首部行指示了实体体中的对象是HTML文本

• 实体体

  报文的主要部分，即它包含了所请求的对象本身(表示为 data data data data data · · ·)

2.2.4 用户与服务器的交互：cookie

cookie的作用：HTTP服务器是无状态的，但是站点有时需要识别用户，cookie就是用来允许站点对用户进行跟踪的技术。

1.cookie技术的组件：

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

2.cookie的工作过程：

当某客户主机第一次访问到某个站点时，该站点将会为该客户主机创建一个唯一识别码，并以此为索引在后端数据库中创建一个表项。然后服务器汇给客户主机发送一个响应报文，响应报文中会包含Set-cookie，浏览器接收到响应报文之后就会在特定的报文中添加一行，包含了主机名以及识别码。之后再次访问该站点时，就会抽取识别码，并将这个识别码发送给服务器主机，这样就能完成对用户的识别。

2.2.5 Web缓存(代理服务器)

1.功能：

拥有自己的磁盘存储空间，在存储空间中保存最近请求的对象的副本。可以配置用户的浏览器，使得用户的所有 HTTP 请求首先指向Web 缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该 Web 缓存器。

2.请求流程：

3.Web缓存器的优点：

• Web 缓存器可以大大减少对客户请求的响应时间
• Web 缓存器能够大大减少一个机构的接人链路到因特网的通信量

4.应用

• 内容分发网络(CDN)

2.2.6 条件GET方法

如何保证缓存器中的对象是最新的？——条件GET方法

• 缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象，当用户再次访问请求该对象时，需要执行最新检查，通过在请求报文中包含If-Modified-Since首部行来执行。
  

• 该条件 GET 报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。
  

• 如果没有被修改，那么就会继续使用缓存器中的对象，否则就使用Web服务器中更新的对象，并将缓存一个新更新对象的副本。

2.3 电子邮件

1.组成

• 用户代理

  用户代理允许用户阅读、回复、转发、 保存和撰写报文

• 邮件服务器

  发送方：邮件代理向其邮件服务器发送邮件，此时邮件放在邮件服务器的外出报文队列中

  接收方：用户代理在其邮件服务器的箱中取得该报文

• 简单邮件传输协议

  SMTP：它使用 TCP 可靠数据传输服务

2.3.1 SMTP

SMTP 用于从发送方的邮件服务器发送报文到接收方的邮件服务器

基本操作：
注：

SMTP一般不使用中间邮件服务器发送邮件，而是发送方和接收方的邮件服务器直接相连。

发送流程：

• 客户SMTP建立到服务器SMTP的TCP连接
• 如果连接失败，会在稍后继续尝试连接
• 连接建立，应用层握手，客户指定发送方和接收方的邮件地址
• 客户发送报文

连接方式——持续连接

如果发送邮件服务器有几个报文法网同一个接收邮件服务器，那么它可以通过同一个TCP连接发送所有的报文，而不需要再次进行TCP连接。

2.3.2 SMTP与HTTP的对比

1.相同

• 都用于从一台主机向另一台主机传送文件
• 持续的HTTP和SMTP都使用持续连接

2.差别

• HTTP为拉协议，SMTP为推协议

  拉协议：某些人在Web服务器上装载信息，用户使用HTTP从该服务器上装载信息。TCP连接由想接收文件的机器发起。

  推协议：发送邮件服务器把文件推向接收邮件服务器。TCP连接由想要发送文件的机器发起。

• SMTP要求每个报文采用7比特的ASCII码格式，如果包含了非7比特的ASCII字符或二进制数据，那该报文必须按照7比特ASCII码进行编码。而HTTP没有该限制。

• HTTP将每个对象封装到它自己的HTTP响应报文中，SMTP将所有的报文对象放在一个报文之中。

2.3.3 邮件报文格式

注： 邮件报文格式与SMTP相区别

邮件报文和SMTP（Simple Mail Transfer Protocol）命令是电子邮件系统中的两个关键概念，它们具有不同的作用和属性：

1. 邮件报文：

• 作用：邮件报文是实际的电子邮件内容，包括邮件的文本、附件、发件人、收件人、主题等信息。它是用户编写的邮件内容，用于传达消息和信息。
• 属性：邮件报文包括邮件头部和邮件正文。邮件头部包含元数据，如发件人、收件人、主题、日期等信息，而邮件正文包含实际的邮件内容。邮件报文可以是纯文本、HTML格式或多媒体格式。

2. SMTP命令：

• 作用：SMTP是用于在计算机之间传输电子邮件的协议，它定义了邮件传输的规则和过程。SMTP命令是用于控制电子邮件传输的指令，包括发送、接收、路由、排队等操作。
• 属性：SMTP命令用于管理邮件的传输过程，例如，EHLO（扩展问候）、MAIL FROM（指定发件人地址）、RCPT TO（指定收件人地址）、DATA（发送邮件数据）、QUIT（结束会话）等。这些命令用于将邮件报文从发件人的邮件服务器传递到收件人的邮件服务器，最终将邮件投递到收件人的邮箱。

总之，邮件报文是电子邮件的实际内容，包含了要传递的消息，而SMTP命令是用于管理和控制电子邮件传输的协议命令，用于将邮件报文从一个邮件服务器传递到另一个邮件服务器，以确保邮件能够被正确地投递到收件人的邮箱。邮件报文和SMTP命令共同构成了电子邮件系统的核心。

格式：

• 首部行

  From: 首部行

  To: 首部行

  Subject： 首部行（可选）

  在报文首部之后，紧接着一个空白行，然后是报文体。

• 报文体

2.3.4 邮件访问协议

1.邮件访问体系结构

客户-服务器体系结构：在用户端系统上运行的客户程序来阅读电子邮件

2.直接从用户代理发送邮件或直接发送到用户代理

• 直接从用户代理发送邮件

  通常Alice 的用户代理和 Bob 的邮件服务器之间并没有一个直接的 SMTP 对话。如果不通过 Alice 的邮件服务器进行中继， Alice 的用户代理将没有任何办法到达 一个不可达的目的地接收服务器。因为Alice服务器在没有成功发送时会进行重复尝试。

• 直接发送到用户代理

  PC需时刻在线来接收可能在任何时刻到达的新邮件。

3.邮件访问协议

用来将邮件从接收方的邮件服务器传送到接收方的用户代理

• 第三版的邮局协议（POP3）

  • TCP连接阶段

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

  • 工作阶段

    • 特许

      用户代理发送（以明文形式）用户名和口令以鉴别用户

    • 事务处理

      用户代理取回报文以及进行一些操作：对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息

      • 下载并删除
      • 下载并保留

    • 更新

      客户发出了 quit 命令之后，目的是结束该 POP3 会话；这时，该邮件服务器删除那些被标记为删除的报文

• 因特网邮件访问协议（IMAP）

  解决了使用一个在远程服务器上 的层次文件夹，这样就可以从任何一台机器上对所有报文进行访问

  特点：

  • 每个报文与一个文件夹联系，报文第一次到达服务器时，将其与收件人的INBOX想关联。
  • IMAP 协议为用户提供 了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令
  • IMAP 还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件
  • IMAP 服务器维护了 MAP 会话的用户状态信息
  • 允许用户代理获取报文某些部分的命令

• HTTP——基于Web的电子邮件

  用户代理就是普通的浏览器，用户和他远程邮箱 之间的通信则通过 HTTP进行

2.4 DNS: 因特网的目录服务

对主机的识别方式：

• 主机名

  便于人们记忆

• IP地址

  便于识别主机

2.4.1 DNS提供的服务

1.域名系统(DNS)的主要任务

进行主机名到 IP 地址转换的目录服务

2.DNS

• 一个由分层的 DNS 服务器 （DNS server）实现的分布式数据库；
• 一个使得主机能够查询分布式数据库的应用层协议 --> 允许应用程序通过网络与多个数据库进行通信和数据查询

3.使用DNS的工作过程

请求 www.someschool.edu 流程如下：
通常会将IP地址缓存在一个“附近的”DNS服务器中。减少DNS的网络流量以及DNS的平均时延。

4.提供服务

• 主机名到IP地址的转换

• 主机别名

  主机别名（当存在时）比主机规范名更加容易记忆。应用程序可以调用 DNS 来获得主机别名对应的规范主机名以及主机的IP 地址。

  当用户或开发人员需要访问相同的主机时，他们可以使用更短、更易记的别名

• 邮件服务器别名

  电子邮件应用程序可以调用 DNS, 对提供的主机名别名进行解析，以获得该主机的规范主机名及其 IP 地址

• 负载分配

  DNS 也用千在冗余的服务器（如冗余的 Web 服务器等）之间进行负载分配。

2.4.2 DNS工作机理概述

1.集中式DNS服务器存在的问题：

• 单点故障
• 通信容量
• 远距离的集中式数据库
• 维护

2.分布式、层次数据库

• 根DNS服务器

  根服务器管理根名字服务器，根名字服务器的全部清单连同管理它们的组织及其 IP 地址可以在 Root Servers 2016 中找到。根名字服务器提供 TLD 服务器的 IP 地址。

• 顶级域DNS服务器

  对于每个顶级域（如 com org net edu gov) 和所国家的顶级域（如 uk fr ca jp)都有 TLD 服务器 （或服务器集群）。

• 权威DNS服务器

  提供了公共可访问的DNS记录，将这些主机名映射为IP地址 。

• (本地DNS服务器)

  当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 服务器层次结构中。

3.查询方式

• 递归查询
• 迭代查询

从请求主机到本地DNS 服务器的查询是递归的、其余的查询是迭代的

4.查询过程

• 请求主机向本地DNS服务器发送DNS查询报文
• 本地DNS服务器将该报文转发到根DNS服务器
• 根DNS服务器根据前缀，向本地DNS服务器返回负责edu的TLD的IP地址列表
• 本地DNS服务器向返回的TLD服务器之一发送查询报文
• TLD服务器注意到其前缀，返回负责该前缀的权威DNS服务器的IP地址。
• 本地DNS服务器直接向返回的权威DNS服务器重回发查询报文
• 权威DNS返回对应的IP地址

对于TLD 服务器只是知道中间的某个 DNS 服务器，该中间 DNS 服务器依次才能知道用于该主机的权威 DNS 服务器的情况，需要再增加一层查询。先查询到中间这一层，由中间这一层返回权威DNS服务器的IP地址，再由本地DNS服务器查询到最终的权威DNS服务器。

5.DNS缓存

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

注：由于主机和主机名与IP 地址间的映射并不是永久的， DNS 服务器在一段时间后（通常设置为两天）将丢弃缓存的信息

2.4.3 DNS记录和报文

在所有的DNS服务器中存储了资源记录（RR），RR提供了主机名到IP地址的映射。

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

(Name, Value, Type, TTL)

• TTL

  TTL 是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间

• Type

  • Type = A
    • Name: 主机名
    • Value: 主机名对应的IP地址
    • 提供了标准的主机名到IP地址的映射
  • Type = NS
    • Name: 域
    • Value: 知道如何获得该域中主机IP地址的权威DNS服务器的主机名
    • 用于沿着查询链来路由 DNS查询
  • Type = CNAME
    • Name: 别名
    • Value: 主机对应的规范主机名
    • 能够向查询的主机提供一个主机名对应的规范主机名
  • Type = MX
    • Name: 别名
    • Value: 邮件服务器的规范主机名
    • 通过使用 MX 记录，一个公司的邮件服务器和其他服务器（如它的 Web 服务器）可以使用相同的别名

权威DNS服务器

• 用于提供主机名到IP地址映射的A记录

非权威服务器

• NS记录：域到权威DNS主机名
• A记录：权威DNS主机名到IP地址

1.DNS报文

​ DNS有两种报文：查询报文和回答报文，具有相同的格式。

• 前12字节：首部区域。

  • 标识符字段(第一个字段：16bit)

    有客户用来匹配发送的请求和接收到的回答的标识符，标志字段有若干标志。

  • 四个有关数量的字段，指出了在首部后的4类数据区域出现的数量

• 问题区域

  正在进行的查询信息

  • 名字字段
  • 类型字段

• 回答区域

  包含了对最初请求的名字的资源记录

  • (Name, Value, Type, TTL)

• 权威区域

  权威区域在DNS报文中用于包含其他权威DNS服务器的记录，以便客户端或其他DNS服务器可以获取有关特定域名的权威信息。

• 附加信息

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

注册域名–>验证域名的唯一性–>输入DNS数据库

• 注册域名

  需要向该机构提供你的基本和辅助权威 DNS 服务器的名字和 IP 地址

• 输入数据库

  注册登记机构确保将一个类型 NS和一个类型A的记录输入 TLD com 服务器

2.5 P2P文件分发

1. P2P体系结构的扩展性

   直接成因：对等方除了是比特的消费者外还是它们的重新分发者

2. BitTorrent——文件分发流行P2P协议

   对等方首次加入洪流→进行块的上载和下载→完成了整个文件下载→离开或为其他对等方上载块

   注：任何对等方可在任何时候离开，完成整个文件的下载并非必要条件。

   ​ (1) 追踪器

   • 每个洪流具有一个基础设施节点
   • 对等方加入→追踪器注册→周期性通知
   • 在对等方首次加入时，随机选取50个对等方ip发送给它

   ​ (2) BitTorrent分发文件过程

   ① 客户端应向其他对等方请求什么块？

   ② 客户端作为所有对等方的一员，有其他的对等方向它请求块时，应该向哪些对等方发送块？

   • 已有的前提：通过TCP连接知晓了邻近对等方所具有的块列表

   • 块的下载——最稀缺优先原则

     最稀缺的块就是那些在邻居中副本数量最少的块，首先请求最稀缺的块。

   • 块的上载——对换算法

     根据当前能够以最高速率向客户端提供数据的邻居，给出其优先权

     关于交换的激励机制 “一报还一报” （tit-for-tat）

     • 一个最高速率向客户端提供数据的对等方集合，集合动态变化
     • 隔一段时间随机选择另外一个对等方发送
     • 其他对等方被阻塞

2.6 视频流和内容分发网

2.6.1 因特网视频

1. 流式视频

   一种在线视频播放的方式，其中视频数据在用户观看的同时不需要完全下载到本地设备

   • 原理

     将视频文件分成小块（通常是几秒钟的视频片段），按需下载和播放这些片段。

2. 视频的特征（网络角度）

   高比特率，因此对流式视频对重要的性能度量是平均端到端吞吐量。

2.6.2 HTTP流和DASH

1. HTTP流

   HTTP流（HTTP streaming）是通过HTTP协议传输音频、视频或其他媒体内容的一种方法。它与传统的下载方式不同，它允许媒体内容在下载的同时即时播放，而无需等待整个文件下载完成。

   缺陷：

   → 所有客户接收到相同编码的视频

2. DASH——经HTTP的动态适应流（是对HTTP流的改进）

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

   服务器：

   • 视频文件分割成了多块
   • 每一块视频文件独立存储
   • 在HTTP服务器中存有一个告示文件，提供了不同块的URL，不同的URL对应于不同的质量水平的文件

   客户端：

   • 先获取告示文件
   • 周期性的测量服务器与客户端的带宽
   • 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围

   客户端可以决定：① 什么时候请求数据块？② 什么编码速率请求？ ③ 去哪里请求？

2.6.3 内容分发网(CDN)

1. 流式视频服务提供的方式

   ① 建立单一的大规模数据中心(×)

   ​ 思路： 数据中心存储所有视频，直接从数据中心向世界范围的客户传输流式视频。

   ​ 问题：a. 如果客户远离数据中心，服务器到客户的分组将跨越许多通信链路并很可能通过许多 ISP，可能导致停滞时延；b. 流行的视频很可能经过相同的通信链路发送许多次。网络带宽浪费以及为相同字节支付费用；c. 单个数据中心代表一个单点故障，如果数据中心或其通向因特网的链路崩溃，它将不能够分发任何视频流了。

   ② 内容分发网

   ​ 思路：CDN服务器分布地理位置广泛，存储视频或其他数据的副本(一部分数据)，且试图将每个用户请求定向到一个将提供最好的用户体验的 CDN位置。

   ​ 类型： a. 专用CDN；b. 第三方CDN

   ​ 服务器安置原则：

   • 深入（enter deep）

     通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接入网中。目标是尽可能地接近端用户。

   • 邀请做客（bring home）

     通过在少量关键位置（例如10个）建立大型集群，以邀请ISP到集群中，减少了维护和管理成本。

   ​ 视频请求策略：（拉策略） 如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向客户流式传输视频时的同时在本地存储一个副本。某集群存储器变满时，它删除不经常请求的视频。

   ​ CDN操作：通过DNS截获和重定向请求（详见教材P100~101），主要步骤是：访问DNS服务器返回了CDN服务器的主机名

   ​ 集群选择策略： 动态地将客户定向到 CDN 中的某个服务器集群或数据中心的机制

   • 地理上最近

     问题：就网络路径的长度或跳数而言 ，地理最邻近的集群可能并不是最近的集群。

   • 基于当前流量条件决定集群

     CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量

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

网络应用程序有两类，一类是由协议标准（如一个 RFC 或某种其他标准文档）中所定义的操作的实现，不同开发者编写的程序因为遵循着相同的规则，能够进行交互操作；另一类网络应用程序，是专用的网络应用程序，（应用层协议不公开）。

2.7.* 套接字编程

1. UDP套接字编程
   

# UDP-Client

from socket import *
serverName = 'localhost'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)  # socket(地址簇,套接字类型)
message = input('Input lowercase sentense:')
clientSocket.sendto(message.encode(),(serverName,serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048) # serverAddress 服务器的 IP 地址和服务器的端口号，2048指接收数据缓冲区的大小
print(modifiedMessage.decode())
clientSocket.close()

# UDP-Server

   from socket import*

   serverPort = 12000
   serverSocket = socket(AF_INET, SOCK_DGRAM)
   serverSocket.bind(('',serverPort)) # 将端口号与该服务器的套接字绑定
   print("The server is ready to receive")
   while True:
       message, clientAddress = serverSocket.recvfrom(2048)
       modifiedMessage = message.decode().upper()
       serverSocket.sendto(modifiedMessage.encode(),clientAddress) # 服务器地址会被自动附在分组中

2. TCP套接字编程

欢迎套接字是所有要与服务器通信的客户的起始接触点，客户进行的三次握手与服务器的欢迎套接字进行。连接套接字是为每个客户通信而生成的套接字。

# TCP-Client
from socket import *

serverName = 'localhost'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort)) # 进行TCP连接，执行三次握手
sentence = input('Input lowercase sentense:')
clientSocket.send(sentence.encode())
modifiedSentence = clientSocket.recv(1024)
print("From Server: ",modifiedSentence.decode())
clientSocket.close()

# TCP-Server

from socket import*

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(('',serverPort)) # 将服务器的端口号与套接字关联，serverSocket为欢迎套接字
serverSocket.listen(1) # 服务器聆听来自客户的TCP连接请求，参数定义了请求连接的最大数，将连接请求加入等待队列
print('The server is ready to receive')
while True:
    connectionSocket, addr = serverSocket.accept() # 创建连接套接字
    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode())
    connectionSocket.close() # 连接套接字关闭，欢迎套接字仍打开