计算机网络基础

应用层
- P2P 应用
- - P2P 体系结构的扩展性
  - BitTorrent 协议
  - - torrenl 洪流
    - BitTorrent 运行的过程
  - P2P文件共享应用
  - - 非结构化 P2P
    - DHT 结构化 P2P（了解）
- 视频流和内容分发网
- - 视频流化服务
  - HTTP 流和 DASH
  - 内容分发网 CDN
  - - 面临挑战
    - CDN 概述
    - CDN 操作过程
    - 集群选择策略
- 套接字编程
- - Socket 编程
  - UDP 套接字编程
  - TCP 套接字编程

大家好呀！我是小笙，本章我主要分享计算机网络基础 - 应用层(3)学习总结，希望内容对你有所帮助！！

应用层

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头部指定字节范围
- 如果带宽足够，选择最大码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)

内容分发网 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请求）