计算机网络基础
大家好呀！我是小笙，本章我主要分享计算机网络基础 - 应用层(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_141">内容分发网 CDN
面临挑战
服务器如何通过网络向上百万用户同时流化视频内容？
-
建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频
- 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
- 单点故障点，性能瓶颈
评述：相当简单，但是这个方法不可扩展
-
通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
CDN__160">CDN 概述
CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储视频(和其他类型的 Web 内容，包括文档、图片和音频)的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置
- 深入，该原则是通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。其目标是靠近端用户，通过减少端用户和 CDN 集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量
- 邀请做客，该原则是通过在少量（例如10个）关键位置建造大集群来邀请到 ISP 做客。不是将集群放在接入ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点(XP)
- 与深入设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价
CDN__173">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请求）
套接字编程
Socket 编程
应用进程使用传输层提供的服务才能够交换报文，实现应用协议，实现应用
- 地点：界面上的 SAP (Socket）
- 方式：Socket API
套接字：分布式应用进程之间的门，传输层协议提供的端到端
传输层服务的 socket 类型
- TCP：可靠的、字节流的服务
- UDP：不可靠（数据UDP数据报）服务
UDP 套接字编程
为客户端和服务器提供不可靠的字节组的传送服务，在客户端和服务器之间没有连接，没有握手（传送的数据可能乱序，也可能丢失）
- 发送端在每一个报文中明确地指定目标的 IP 地址和端口号
- 服务器必须从收到的分组中提取出发送端的 IP 地址和端口号
演示 UDP 套接字编程
TCP 套接字编程
在客户端和服务器进程之间提供了可靠的、字节流（管道）
服务器首先运行，等待连接建立
- 创建 Welcome socket
- 和本地端口捆绑
- 在 Welcome socket 上阻塞式等待接收用户的连接
客户端主动和服务器建立连接
当与客户端连接请求到来时，服务器接受来自用户端的请求，解除阻塞式等待，返回一个新的socket（与 Welcome socket 不一样）
- 与客户端通信，允许服务器与多个客户端通信
- 使用源 IP 和源端口来区分不同的客户端
演示 UDP 套接字编程
