第二章 应用层

目标：

• 网络应用的原理：网络应用协议的概念和实现方面
  • 传输层的服务模型
  • 客户-服务器模式
  • 对等模式（peer-to-peer）
  • 内容分发网络
• 网络应用的实例：互联网流行的应用层协议
  • HTTP
  • FTP
  • SMTP/POP3/IMAP
  • DNS
• 编程：网络应用程序
  • Socket API

---

1.应用层协议原理

1.1 客户-服务器（C/S）体系结构

• 服务器
  • 一直运行
  • 固定的IP地址和周知的端口号（约定）
  • 扩展性：服务器场
    • 数据中心进行扩展
    • 扩展性差
• 客户端
  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可能是动态IP地址
  • 不直接与其它客户端通信

1.2 对等体（P2P）体系结构

• （几乎）没有一直运行的服务器

• 任意端系统之间可以进行通信

• 每一个节点即是客户端又是服务器

  • 自扩展性：新peer节点带来新的服务能力，当然也带来新的服务请求

• 参与的主机间歇性连接且可以改变IP地址

  • 难以管理

例子：迅雷，Gnutella

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

Napster

• 文件搜索：几种

  • 主机在中心服务器上注册其资源
  • 主机向中心服务器查询资源位置

• 文件传输：P2P

  • 任意Peer节点之间

即时通讯

• 在线检测：集中

  • 当用户上线时，向中心服务器注册其IP地址
  • 用户与中心服务器联系，以找到其在线好友的位置

• 两个用户之间聊天：P2P

1.4 进程通信

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

• 在同一个主机内，使用进程间通信机制通信（操作系统定义）
• 不同主机，通过交换报文（Message)来通信

  • 使用OS提供的通信服务

  • 按照应用协议交换报文

    • 借助传输层提供的服务

  • 注意：P2P架构的应用也有客户端进程和服务器进程之分

客户端进程：发起通信的进程

服务器进程：等待连接的进程

分布式进程通信需要解决的问题

• 问题1：进程标识和寻址问题（服务用户）

• 问题2：传输层-应用层提供服务是如何实现的

  • 位置：层间界面的SAP（TCP/IP：socket）
  • 形式：应用程序接口API（TCP/IP：socket API）

• 问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）

  • 定义应用层协议：报文格式，解释，时序等
  • 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等

1.4.1 问题1：对进程进行编制（addressing）

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

  • 主机：唯一的32位IP地址
    • 仅仅有IP地址不能够唯一标识一个进程：在一台端系统上有很多应用进程在运行
  • 所采用的传输层协议：TCP or UDP
  • 端口号（Port Numbers）

• 一些知名端口号的例子：

  • HTTP：TCP 80 Mail：TCP25 ftp：TCP 2

• 一个进程：用IP+port标示端节点

• 本质上，一对主机进程之间的通信由2个端节点构成

1.4.2 问题2：传输层提供的服务-需要穿过层间的信息

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

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

• 传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段（UDP数据报）的封装

  • 源端口号，目标端口号，数据等
  • 将IP地址往下交IP实体，用于封装IP数据报：源IP，目标IP

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

• 用个代号标示通信的双方或者单方：socket

• 就像OS打开文件返回的句柄一样

  • 对句柄的操作，就是对文件的操作

TCP

• TCP socket：

  • TCP服务，两个进程之间的通信之前要建立连接

    • 两个进程通信会持续一段时间，通信关系稳定

  • 可以用一个整数表示两个应用实体之间的通信关系，本地标示

  • 穿过层间接口的信息量变小

  • TCP socket：源IP，源端口，目标IP，目标端口

TCP之上的套接字（socket）

• 对于使用面向连接服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的标示
  • 4元组：（源IP，源port，目标IP，目标port）
  • 唯一的指定了一个会话（2个进程之间的会话关系）
  • 应用使用这个标示，与远程的应用进程通信
  • 不必在每一个报文的发送都要指定这4元组
  • 就像使用操作系统打开一个文件，OS返回一个文件的句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名
  • 简单，便于管理

UDP

UDP socket

• UDP socket

  • UDP服务，两个进程之间的通信需要之前无需建立联系

    • 每个报文都是独立传输的
    • 前后报文可能给不同的分布式进程

  • 因此，只能用一个整数表示本应用实体的标示

    • 因为这个报文可能传给另一个分布式进程

  • 穿过层间接口的信息大小最小

  • UDP socket：本IP，本端口

  • 但是传输报文时：必须要提供对方IP、port

    • 接收报文时：传输层需要上传对方的IP、port

UDP之上的套接字（socket）

• 对于使用无连接服务（UDP）的应用而言，套接字是2元组的一个具有本地意义的标示
  • 2元组：IP，port（源端指定）
  • UDP套接字指定了应用所在的一个端节点（end point）
  • 在发送数据报时，采用创建好的本地套接字（标示ID），就不必在发送每个报文中指明自己所采用的ip和port
  • 但是在发送报文时，必须要指定对方的ip和udp port（另外一个段节点）

套接字

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

1.4.3 问题3：如何使用传输层提供的服务实现应用

• 定义应用层协议：报文格式、解释、时序等
• 编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

应用层协议

• 定义了：运行在不同端系统上的应用进程如何相互交换报文

  • 交换的报文类型：请求和应答报文
  • 各种报文类型的语法：报文中的各个字段及其描述
  • 字段的语义：即字段取值的含义
  • 进程何时、如何发送报文及对报文进行响应的规则

• 应用协议仅仅是应用的一个组成部分

  • Web应用：HTTP协议、web客户端、web服务器、HTML
  • 公开协议：由RFC文档定义、允许互操作、如：HTTP，SMTP
  • 专有协议：协议不公开、如：Skype

应用层需要传输层提供什么样的服务？

数据丢失率

• 有些应用则要求100％的可靠数据传输（如文件）
• 有些应用（如音频）能容忍一定比例以下的数据丢失

延迟

• 一些应用出于有效性考虑，对数据传输有严格的时间限制
  • Internet电话、交互式游戏

吞吐

• 一些应用（如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
• 一些应用能充分利用可供使用的吞吐（弹性应用）

安全性

• 机密性
• 完整性
• 可认证性（鉴别）

Internet传输层提供的服务

TCP服务

• 可靠的传输服务
• 流量控制：发送方不会淹没接收方
• 拥塞控制：当网络出现拥塞时，能抑制发送方
• 不能提供的服务：时间保证、最小吞吐保证和安全
• 面向连接：要求在客户端进程和服务器进程之间建立联系

UDP服务

• 不可靠数据连接
• 不提供的服务：可靠、流量控制、拥塞控制、时间、带宽保证、建立连接

UDP存在的必要性

• 能够区分不同的进程，而IP服务不能

  • 在IP提供的主机到主机，端到端功能的基础上，区分了主机的应用进程

• 无需建立连接，省去了建立连接时间，适合事务性的应用

• 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用

  • 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发）

• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

  • 而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

安全TCP

TCP&UDP

• 都没有加密
• 明文通过互联网传输，甚至密码

SSL

• 在TCP上面实现，提供加密的TCP连接
• 私密性
• 数据完整性
• 端到端的鉴别

SSL在应用层

• 应用采用SSL库，SSL库使用TCP通信

SSL socket API

• 应用通过API将明文交给socket，SSL将其加密在互联网上传输

---

2.Web and HTTP

一些术语：

• Web页：由一些对象组成
• 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
• Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接）
• 通过URL对每个对象进行引用
  • 访问协议、用户名、口令字、端口等
• URL格式：

2.1 HTTP概况

HTTP：超文本传输协议

• Web的应用层协议

• 客户/服务器模式

  • 客户：请求、接收和显示Web对象的浏览器
  • 服务器：对请求进行响应，发送对象的Web服务器

• HTTP 1.0:RFC 1945

• HTTP 1.1:RFC 2068

• 使用TCP：

  • 客户发起一个与服务器的TCP连接（建立套接字），端口号为80
  • 服务器接受客户的TCP连接
  • 在浏览器（HTTP客户端）与Web服务器（HTTP服务器server）交换HTTP报文（应用层协议报文）
  • TCP连接关闭

• HTTP是无状态的

  • 服务器并不维护关于客户的任何信息

维护状态的协议很复杂

• 必须维护历史信息（状态）
• 如果服务器/客户端司机，它们的状态信息可能不一致，二者的信息必须是一致的
• 无状态的服务器能够支持更多的客户端

2.2 HTTP连接

非持久HTTP

• 最多只有一个对象在TCP连接上发送
• 下载多个对象需要多个TCP连接
• HTTP/1.0使用非持久连接

持久HTTP

• 多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
• HTTP/1.1 默认使用持久连接

响应时间模型

• 往返时间RTT：一个小的分组从客户端到服务器，再回到客户端的时间（传输时间忽略）
• 响应时间：
  • 一个RTT用来发起TCP连接
  • 一个RTT用来HTTP请求并等待HTTP响应
  • 文件传输时间：共2RTT+传输时间

非持久HTTP的缺点

• 每个对象要2个RTT
• 操作系统必须为每个TCP连接分配资源
• 浏览器通过打开并行TCP连接，以获取资源

持久HTTP

• 服务器在发送响应后，仍保持TCP连接
• 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
• 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求

非流水方式的持久HTTP

• 客户端只能在收到前一个响应后才能发出新的请求
• 每个引用对象花费一个RTT

流水方式的持久HTTP

• HTTP/1.1的默认模式
• 客户端遇到一个引用对象就立即产生一个请求
• 所有引用（小）对象只花费一个RTT是可能的

2.3 HTTP请求报文

• 两种类型的HTTP报文：请求、响应
• HTTP请求报文：
  • ASCII（人能阅读）

提交表单输入

post方式：

• 网页通常包括表单输入
• 包含在实体主体（entity body）中的输入被提交到服务器

URL方式：

• 方法：GET
• 输入通过请求行的URL字段上载

2.4 HTTP响应报文

2.5 用户-服务器状态：cookies

大多数主要的门户网站使用cookies

4个组成部分：

1. 在HTTP响应报文中有一个cookie的首部行
2. 在HTTP请求报文含有一个cookie的首部行
3. 在用户端系统中保留有一个cookie文件，由用户的浏览器管理
4. 在Web站点有一个后端数据库

cookies能带来什么

• 用户验证
• 购物车
• 推荐
• 用户状态（Web e-mail）

如何维持状态

• 协议端节点：在多个事务上，发送端和接收端维持状态
• cookies：http报文携带状态信息

Cookies与隐私：

• Cookies允许站点知道许多关于用户的信息
• 可能将它知道的东西卖给第三方
• 使用重定向和cookies的搜索引擎还能知道用户的更多信息
• 广告公司从站点获取信息

2.6 Web缓存（代理服务器）

目标：不访问原始服务器，就满足客户的请求

• 用户设置浏览器：通过缓存访问Web

• 浏览器将所有的HTTP请求发给缓存

  • 在缓存中的对象：缓存直接返回对象
  • 如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端

• 缓存既是客户端又是服务器

• 通常缓存是由ISP安装（大学、公司、居民区ISP）

为什么要使用Web缓存？

• 降低客户端的请求响应时间
• 可以大大减少一个机构内部网络与Internet接入链路上的流量
• 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容

---

3.FTP*

FTP：文件传输协议

• 向远程主机上传输文件或从远程主机接收文件

• 客户/服务器模式

  • 客户端：发起传输的一方
  • 服务器：远程主机

• ftp：RFC 959

• ftp服务器：端口号为21

FTP：控制连接与数据连接分开

• FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
• 客户端通过控制连接获得身份确认
• 客户端通过控制连接发送命令浏览远程目录
• 收到一个文件传输命令时，服务器打开一个到客户端的数据连接
• 一个文件传输完成后，服务器关闭连接
• 服务器打开第二个TCP数据连接用来传输另一个文件
• 控制连接：带外（"out of band"）传送
• FTP服务器维护用户的状态信息：当前路径、用户账户与控制连接对应

---

4.Email

3个主要组成部分

• 用户代理
• 邮件服务器
• 简单邮件传输协议：SMTP

用户代理

• 又名“邮件阅读器”
• 撰写、编辑和阅读邮件
• 如Outlook、Foxmail
• 输出和输入邮件保存在服务器上

邮件服务器

• 邮箱中管理和维护发送给用户的邮件
• 输出报文队列保持待发送邮件报文
• 邮件服务器之间的SMTP协议：发送email报文
  • 客户：发送方邮件服务器
  • 服务器：接收端邮件服务器

SMTP

• SMTP使用持久连接
• SMTP要求报文（首部和主体）为7位ASCII编码
• SMTP服务器使用CRLF,CRLF决定报文的尾部

HTTP比较：

• HTTP：拉（pull）
• SMTP：推（push）
• 二者都是ASCII形式的命令/响应交互、状态码
• HTTP：每个对象封装在各自的响应报文中
• SMTP：多个对象包含在一个报文中

邮件报文格式

SMTP：交换email报文的协议 RFC 822：文本报文的标准

• 首部行：如
  • To:
  • From:
  • Subject:

与SMTP命令不同！

• 主体
  • 报文：只能是ASCII码字符

报文格式：多媒体扩展

• MIME：多媒体邮件扩展，RFC 2045,2056
• 在报文首部用额外的行申明MIME内容类型

邮件访问协议

• SMTP：传送到接收方的邮件服务器
• 邮件访问协议：从服务器访问邮箱
  • POP：邮局访问协议
  • IMAP：Internet邮件访问协议
  • HTTP：Hotmail，Yahoo! Mail等

---

5.DNS

• DNS的必要性
  • IP地址标识主机、路由器
  • 但IP地址不好记忆，不便人类使用
  • 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
  • 存在着“字符串”-IP地址的转换的必要性
  • 人类用户提供要访问机器的“字符串”名称
  • 由DNS负责转换成为二进制的网络地址

DNS系统需要解决的问题

• 问题1：如何命名设备

  • 用有意义的字符串：好记，便于人类使用
  • 解决一个平面命名的重名问题：层次化命名

• 问题2：如何完成名字到IP地址的转换

  • 分布式的数据库维护和响应名字查询

• 问题3：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作？

DNS（Domain Name System）的历史

• ARP ANET的名字解析解决方案

  • 主机名：没有层次的一个字符串（一个平面）
  • 存在着一个（集中）维护站：维护着一张主机名-IP地址的映射文件：Hosts.txt
  • 每台主机定时从维护站取文件

• ARP ANET解决方案的问题

  • 当网络中主句数量很大时：1、没有层次的主机名称很难分配 2、文件的管理，发布，查找都很麻烦

5.1 DNS总体思路和目标

• DNS的主要思路

  • 分层的、基于域的命名规则

  • 若干分布式的数据库完成名字到IP地址的转换

  • 运行在UDP之上端口号为53的应用服务

  • 核心的Internet功能，但以应用层协议实现

    • 在网络边缘处理复杂性

  • DNS主要目的：

  • 实现主机名-IP地址的转换

  • 其他目的：

    • 主机别名到规范名字的转换：Host aliasing
    • 邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing
    • 负载均衡：Load Distribution

5.2 问题1：DNS名字空间

• DNS域名空间
  • 一个层面命名设备会有很多重名
  • NDS采用层次树状结构的命名方法
  • Internet根被划为几百个顶级域
    • 通用的（generic）
      • .com;.edu;.gov;.int;.mil
    • 国家的（countries）
      • .cn;.us
  • 每个（子）域下面可划分为若干子域
  • 树叶是主机

• 域名（Domain Name）

  • 从本域往上，直到树根
  • 中间使用“.”间隔不同的级别
  • 例如：ustc.edu.cn,auto.ustc.edu.cn
  • 域的域名：可以用于表示一个域
  • 主机的域名：一个域上的一个主机

• 域名的管理

  • 一个域管理其下的子域

    • .jp被划分为ac.jp co.jp
    • .cn被划分为edu.cn com.cn

  • 创建一个新的域,必须征得它所属域的同意

• 域与物理网络无关

  • 域遵从组织界限，而不是物理网络

    • 一个域的主机可以不在一个网络
    • 一个网络的主机不一定在一个域

  • 域的划分是逻辑的，而不是物理的

5.3 问题2：解析问题-名字服务器（Name Server）

• 一个名字服务器的问题

  • 可靠性问题：单点故障
  • 扩展性问题：通信容量
  • 维护问题：远距离的集中式数据库

• 区域（Zone）

  • 区域的划分由区域管理者自己决定
  • 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
  • 名字服务器：
    • 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息
    • 名字服务器允许被放置在区域之外，以保障可靠性

名字划分为若干个区域：Zone

权威DNS服务器：组织机构的DNS服务器，提供组织机构服务器（如Web和mail）可访问的主机与IP之间的映射

组织机构可以选择实现自己维护或由某个服务器提供商来维护

TLD服务器

• 顶级域（TLD）服务器：负责顶级域名（如com,org,net,edu和gov）和所有国家级的顶级域名（cn,uk,ca）
  • Network solutions：公司维护com TLD服务器
  • Educause公司维护edu TLD服务器

区域名字服务器维护资源记录

• 资源记录（resource records）

  • 作用：维护域名-IP地址（其他）的映射关系
  • 位置：Name Server的分布式数据库中

• RR格式：（domain_name，ttl，type，class，Value）

  • Domain_name：域名
  • Ttl：time to live：生存时间（权威、缓冲记录）
  • Class类别：对于Internet，值为IN
  • Value值：可以是数字，域名或ASCII串
  • Type类型：资源记录的类型

DNS记录

DNS：保存资源记录（RR）的分布式数据库

• Type=A

  • Name为主机
  • Value为IP地址

• Type=NS

  • Name域名（如foo.com）
  • Value为该域名的权威服务器的域名

• Type=CName

  • Name为规范名字的别名
    • www.ibm.com的规范名字为servereast.backup2.ibm.com
  • value为规范名字

• Type=MX

  • Value为name对应的邮件服务器的名字

DNS（Domain Name System）

• DNS大致工作过程
  • 应用调用解析器（resolver）
  • 解析器作为客户，向Name Server发出查询报文（封装在UDP段中）
  • Name Server返回响应报文（name/ip）

本地名字服务器（Local Name Server）

• 并不严格属于层次结构

• 每个ISP（居民区的ISP、公司、大学）都有一个本地服务器

  • 也称为“默认名字服务器”

• 当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器

  • 起着代理的作用，将查询转发到层次结构中

名字服务器（Name Server）

• 名字解析过程
  • 目标名字在Local Name Server中
    • 情况1：查询的名字在该区域内部
    • 情况2：缓存（cashing）

当与本地名字服务器不能解析名字时，联系根名字服务器顺着根-TLD一直找到权威名字服务器

• 递归查询

  • 名字解析负担都放在当前联络的名字服务器上
  • 问题：根服务器的负担太重
  • 解决：迭代查询

• 迭代查询

  • 主机cis.poly.edu想知道主机gaia.cs.umass.edu的ip地址

• 根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址
• 最后由权威名字服务器给出解析结果
• 当前联络的服务器给出可以联系的服务器的名字
• “我不知道这个名字，但可以向这个服务器请求”

DNS协议、报文

DNS协议：查询和响应报文的报文格式相同

报文首部

• 标识符（ID）：16位
• flags：
  • 查询/应答
  • 希望递归
  • 递归可用
  • 应答为权威

提高性能：缓存

• 一旦名字服务器学到了一个映射，就将该映射缓存起来

• 根服务器通常都在本地服务器中缓存着

  • 使得根服务器不用经常被访问

• 目的：提高效率

• 可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致

• 解决方案：TTL（默认2天）

5.4 问题3：维护问题：新增一个域

• 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
• 在新增子域的名字服务器上运行名字服务器，负责本域的名字解释：名字->IP地址
• 到注册登记机构注册域名
• 在networkutopia.com的权威服务器中确保有
  • 用于Web服务器的www.networkutopia.com的类型为A的记录
  • 用于邮件服务器mail.networkutopia.com的类型为MX的记录

攻击DNS

DDos攻击

• 对根服务器进行流量轰炸攻击：发送大量ping

  • 没有成功
  • 原因1：根目录服务器配置了流量过滤器，防火墙
  • 原因2：Local DNS服务器缓存了TLD服务器的IP地址，因此无需查询根服务器

• 向TLD服务器流量轰炸攻击：发送大量查询

  • 可能更危险
  • 效果一般，大部分DNS缓存了TLD

重定向攻击

• 中间人攻击

  • 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点

• DNS中毒

  • 发送伪造的应答给DNS服务器，希望它能够缓存这个虚假的结果

• 技术上较困难：分布式截获和伪造利用DNS基础设施进行DDos

• 伪造某个IP进行查询，攻击这个目标IP

• 查询放大，响应报文比查询报文大

• 效果有限

---

6.P2P应用

纯P2P架构

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

例子：

• 文件分发
• 流媒体
• VoIP

文件分发：C/S vs P2P

问题：从一台服务器分发文件（大小F）到N个peer需要多少时间？

• Peer节点上下载能力是有限的资源

文件分发时间：C/S模式

• 服务器传输：都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝：

  • 发送一个copy：F/u
  • 发送N个copy：NF/u

• 客户端：每个客户端必须下载一个文件拷贝

  • d（min） = 客户端最小的下载速度
  • 下载带宽最小的客户端下载的时间：F/d（min）

文件分发时间：P2P模式

• 服务器传输：最少需要上载一份拷贝

  • 发送一个拷贝时间：F/u

• 客户端：每个客户端必须下载一个拷贝

  • 最小下载带宽客户单耗时：F/d（min）

• 客户端：所有客户端总体下载量NF

  • 最大上限带宽是：us + ∑ui
  • 除了服务器可以上载，其他所有的peer节点都可以上载

分子随着N线性变化，每个节点需要下载，整体下载量随着N增大；分母也是如此，随着peer节点的增多，每个peer也带来了服务能力

6.1 P2P文件共享

• 两大问题：

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

• 可能的方案：

  • 集中
  • 分散
  • 半分散

P2P：集中式目录

最初的“Napster”设计

1. 当对等方连接时，它告知中心服务器：IP地址、内容
2. Alice查询“双节棍.MP3”
3. Alice从Bob处请求文件

问题：

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

文件传输是分散的，而内容定位则是高度集中的

查询洪泛：Gnutella

• 全分布式

  • 没有中心服务器

• 开放文件共享协议

• 许多Gnutella客户端实现了Gnutella协议

  • 类似Http有许多的浏览器

覆盖网络：图

• 如果X和Y之间有一个TCP连接，则二者之间存在一条边
• 所有活动的对等方和边就是覆盖网络
• 边并不是物理链路
• 给定一个对等方，通常所连接的节点少于10个

协议：

• 在已有的TCP连接上发送查询报文
• 对等方转发查询报文
• 以反方向返回查询命中报文

利用不匀称性：KaZaA

• 每个对等方要么是一个组长，要么隶属于一个组长

  • 对等方与其组长之间有TCP连接
  • 组长对之间有TCP连接

• 组长跟踪其所有的孩子的内容

• 组长与其他组长联系

  • 转发查询到其他组长
  • 获得其他组长的数据拷贝

查询

• 每个文件有一个散列标识码和一个描述符

• 客户端向其组长发送关键字查询

• 组长用匹配进行响应

  • 对每个匹配：元数据、散列标识码和IP地址

• 如果组长将查询转发给其他组长，其他组长也以匹配进行响应

• 客户端选择要下载的文件

  • 向拥有文件的对等方发送一个带散列标识码的HTTP请求

6.2 P2P文件分发：BitTorrent

• 文件被分为一个个块256KB
• 网络中的这些peers发送接收文件块，互相服务

Peer加入torrent：

• 一开始没有块，但是将会通过其他节点处积累文件块
• 向跟踪服务器注册，获得peer节点列表，和部分peer节点构成邻居关系（“连接”）

1. 当peer下载时，该peer可以同时向其他节点提供上载服务
2. Peer可能会变换用于交换块的peer节点
3. 扰动churn：peer节点可能会上线或者下线
4. 一旦一个peer拥有整个文件，它会离开（自私的）或者保留（利他的）在torrent中

请求/发送文件块

请求块：

• 在任何给定时间，不同peer节点拥有一个文件块的子集
• 周期性的，Alice节点向邻居询问他们拥有哪些块的信息
• Alice向peer节点请求它希望的块、稀缺的块

发送块：一报还一报tit-for-tat

• Alice向4个peer发送块，这些块向它子集提供最大带宽的服务

  • 其他peer被Alice阻塞（将不会从Alice处获得服务）
  • 每10秒重新评估一次：前4位

• 每隔30秒：随机选择其他peer节点，向这个节点发送块

  • “优化疏通”这个节点
  • 新选择的节点可以加入这个top

---

7.CDN

视频流化服务和CDN：上下文

• 视频流量：占据着互联网大部分的带宽

• 挑战：规模性-如何服务着~1B用户

  • 单个超级服务器无法提供服务

• 挑战：异构性

  • 不同用户拥有不同能力（例如：有线接入和移动用户）

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

7.1 多媒体：视频

• 视频：固定速度显示的图像序列

  • e.g. 24images/sec

• 网络视频特点：

  • 高码率：>10x于音频，高的网络带宽需求
  • 可以被压缩
  • 90%以上的网络流量是视频

• 数字化图像：像素的阵列

  • 每个像素被若干bits表示

• 编码：使用图像内和图像间的冗余来降低编码的比特数

  • 空间冗余（图像内）
  • 时间冗余（相邻的图像间）

7.2 多媒体流化服务：DASH

• DASH:Dynamic,Adaptive Streaming over Http

• 服务器：

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

• 客户端

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

• “智能”客户端：客户端自适应决定

  • 什么时候去请求块
  • 请求什么编码速率的视频块
  • 哪里去请求块

7.3 内容分发网

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

选择1：单个的、大的超级服务中心“mega-server”

• 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
• “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
• 单点故障点，性能瓶颈
• 周边网络的拥塞

评述：相当简单，但是这个方法不可扩展

选择2：通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验

• enter deep：将CDN服务器深入到许多接入网

  • 更接近用户，数量多，离用户近，管理困难
  • Akamai，1700多个位置

• bring home：部署在少数（10个左右）关键位置，如将服务器簇安装于POP附近

  • 采用租用线路将服务器簇连接起来
  • Limelight

---

8.TCP套接字（Socket）编程

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

• TCP/IP：应用进程使用Socket API访问传输服务
• 地点：界面上的SAP（Socket） 方式：Socket API

目标：学习如何构建能借助sockets进行通信的C/S应用程序

socket：分布式应用进程之间的门，传输层协议提供的端到端服务接口

Socket编程

2种传输层服务的socket类型：

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

套接字：应用进程与端到端传输协议（TCP或UDP）之间的门户

TCP服务：从一个进程向另一个进程可靠地传输字节流

8.1 过程

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

1. 服务器进程必须先处于运行状态

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

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

2. 创建客户端本地套接字（隐式捆绑到本地port）

• 指定服务器进程的IP地址和端口号，与服务器进程连接

3. 当与客户端连接请求到来时

• 服务器接受来自用户端的请求，解除阻塞式等待，返回一个新的socket（与欢迎socket不同），与客户端通信
  • 允许服务器与多个客户端通信
  • 使用源IP和源端口来区分不同的客户端

4. 连接API调用有效时，客户端P与服务器建立了TCP连接

从应用程序的角度：TCP在客户端和服务器进程之间提供了可靠的字节流服务

8.2 C/S模式的应用样例

1. 客户端从标准输入装置读取一行字符，发送给服务器
2. 服务器从socket读取字符
3. 服务器将字符转换成大写，然后返回给客户端
4. 客户端从socket中读取行字符，然后打印出来

数据结构sockaddr_in

---

9.UDP套接字编程

UDP：在客户端与服务器之间没有连接

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

UDP：传送的数据可能乱序，也可能丢失