2 应用层

2.1 基本原理

2.1.1 网络应用的体系结构

• 客户机/服务器结构(Client-Server, C/S)

  服务器：7*24小时提供服务；永久性访问地址/域名；利用大量服务器实现可扩展性

  客户机：与服务器通信，使用服务器提供的服务；间歇性接入网络；可能使用动态IP地址；不会与其他客户机直接通信

  Web应用

• 点对点结构(Peer-to-peer, P2P)

  没有永远在线的服务器，任意端系统/节点之间可以直接通讯，节点间歇性接入网络，节点可能改变IP地址

  优点在于高度可伸缩，缺点在于难于管理

  文件传输应用

• 混合结构(Hybrid)

  文件传输使用P2P结构，文件的搜索采用C/S结构——集中式

  每个节点向中央服务器登记自己的内容，而在查找感兴趣的内容时向中央服务器提交查询请求

  Napster

2.1.2 网络应用进程通信

同一主机上运行的进程之间由操作系统提供进程间通信机制

不同主机上运行的进程间靠消息交换通信，进程间通信利用socket发送/接收消息实现

• 进程寻址：通过标识符(IP地址+端口号)在不同主机上的进程间通信

  • 使用IP地址对主机寻址

  • 为主机上每个需要通信的进程分配一个端口号，使用端口号对主机上的进程寻址

    • HTTP Server: 80
    • Mail Server：25

• 应用层协议：网络应用需遵循应用层协议

  • 公开协议：由RFC定义的，允许互操作的协议(HTTP、SMTP)

• 私有协议：多数P2P文件共享应用

• 应用层协议内容

  • 消息的类型(type)：请求消息、响应消息
  • 消息的语法(syntax)/格式：消息中有哪些字段(field)、每个字段如何描述
  • 字段的语义(semantics)：字段中信息的含义
  • 规则(rules)：进程何时发送/响应消息、进程如何发送/响应消息

2.1.3 网络应用的服务需求

• 数据丢失(data loss)/可靠性(reliability)
  • 某些网络应用能够容忍一定的数据丢失：网络电话
  • 某些网络应用要求100%可靠的数据传输：文件传输，telnet
• 时间(timing)/延迟(delay)
  • 有些应用只有在延迟足够低时才“有效”，如：网络电话/网络游戏
• 带宽(bandwidth)
  • 某些应用只有在带宽达到最低要求时才“有效”：网络视频
  • 某些应用能够适应任何带宽——弹性应用：email

2.2 web应用

2.2.1 HTTP连接

• HTTP连接使用TCP传输服务：

  1. 服务器在80端口等待客户的请求

  2. 浏览器发起到服务器的TCP连接(创建套接字Socket)

  3. 服务器接受来自浏览器的TCP连接

  4. 浏览器(HTTP客户端)与Web服务器(HTTP服务器)交换HTTP消息

  5. 关闭TCP连接

• HTTP协议是无状态的，服务器不维护任何有关客户端过去所发请求的信息。

  有协议的更复杂，需要维护每个用户的历史信息状态，而且当客户或者服务器失效会产生状态的不一致，解决这种不一致代价高

• RTT(Round Trip Time)：从客户端发送一个很小的数据包到服务器并返回所经历的时间

• 响应时间 = 建立TCP连接的1个RTT + 发送HTTP请求消息到HTTP响应消息的前几个字节到达的1个RTT + 响应消息中所含的文件/对象传输时间 = 2RTT + 文件发送时间

2.2.2 HTTP消息格式

2.2.2.1 请求消息(request)

• HTTP 1.0
  • GET方法： 输入信息通过request行的URL字段上传
  • POST方法：网页经常需要填写表格(form)，在请求消息的消息体(entity body)中上传客户端的输
  • HEAD方法：请Server不要将所请求的对象放入响应消息中
• HTTP 1.1
  • GET, POST, HEAD
  • PUT：将消息体中的文件上传到URL字段所指定的路径
  • DELETE：删除URL字段所指定的文件

2.2.2.2 响应消息(response)

HTTP响应状态代码，响应消息的第一行：

• 200 OK
• 301 Moved Permanently
• 400 Bad Request
• 404 Not Found
• 505 HTTP Version Not Supported

2.2.3 Cookie技术

HTTP协议无状态，但很多应用需要服务器掌握客户端的状态

Cookie技术：某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。

Cookie的组件：

• TTP响应消息的cookie头部行
• HTTP请求消息的cookie头部行
• 保存在客户端主机上的cookie文件，由浏览器管理
• Web服务器端的后台数据库

Cookie能够用于：身份认证、购物车、推荐、Web e-mail、……

但是cookie存在用户隐私泄露的问题

2.2.4 Web缓存/代理服务器技术：条件GET

为了缩短客户请求的响应时间、减少机构/组织的流量、在大范围内(Internet)实现有效的内容分发，所以提出了在不访问服务器的前提下满足客户端的HTTP请求的技术——Web缓存/代理服务器技术。

浏览器向缓存/代理服务器发送所有的HTTP请求：如果所请求对象在缓存中，缓存返回对象；否则，缓存服务器向原始服务器发送HTTP请求，获取对象，然后返回给客户端并保存该对象。所以缓存既充当客户端，也充当服务器，一般由ISP(Internet服务提供商)架设。

条件性GET方法

目标：如果缓存有最新的版本，则不需要发送请求对象

缓存：在HTTP请求消息中声明所持有版本的日期(在HTTP请求消息有 If-modified-since: <date>)

服务器：如果缓存的版本是最新的，则响应消息中不包含对象(响应消息为 HTTP/1.0 304 Not Modified)，如果不是最新的，正常返回请求对象

在HTTP响应消息中有一行 Last-Modified header line，表明最后一次的修改时间

2.3 Email应用

Email应用的构成组件

• 邮件客户端(user agent)：Client应用或者Web页面

• 邮件服务器

• SMTP协议(Simple Mail Transfer Protocol)：在邮件服务器之间传递消息使用的协议

  • 客户端：发送消息的服务器
  • 服务器：接收消息的服务器

2.3.1 SMTP协议

使用TCP在25端口建立持久性连接进行email消息的可靠传输，传输过程的三个阶段：握手、消息的传输、关闭。

命令/响应交互模式：

• 命令(command)：ASCII文本

• 响应(response)：状态代码和语句

Email消息只能包含7位ASCII码

SMTP服务器利用CRLF.CRLF确定消息的结束。

SMTP与HTTP对比：

• HTTP是拉式(pull)，而SMTP是推式(push)

• HTTP的每个对象封装在独立的响应消息中，SMTP的多个对象在由多个部分构成的消息中发送

• 都使用命令/响应交互模式

• 命令和状态代码都是ASCII码

2.3.2 Email消息格式

Email消息由三部分组成：

• 头部行(header)
  • To
  • From
  • Subject
• 空白行
• 消息体：消息本身，只能是ASCII字符

而为了传输非文本类型的数据，对如上的消息做出了扩展。

MIME：多媒体邮件扩展。通过在邮件头部增加额外的行以声明MIME的内容类型。

2.3.3 邮件访问协议

邮件访问协议：从服务器获取邮件

• POP (Post Office Protocol)：认证/授权(客户端<---->服务器)和下载
• IMAP (Internet Mail Access Protocol)：更多功能、更加复杂、能够操纵服务器上存储的消息
  • 所有消息统一保存在一个地方：服务器
  • 允许用户利用文件夹组织消息
  • 支持跨会话(Session)的用户状态：文件夹的名字、文件夹与消息ID之间的映射等
• HTTP：163, QQ Mail等(网页版使用)

2.3.3.1 POP3协议

• 认证过程
  • 客户端命令
    • User：声明用户名
    • Pass：声明密码
  • 服务器响应
    • +OK
    • -ERR
• 事务阶段
  • List：列出消息数量
  • Retr：用编号获取消息
  • Dele：删除消息
  • Quit

POP协议有两种模式：

• “下载并删除”模式：用户如果换了客户端软件，无法重读该邮件

• “下载并保持”模式：不同客户端都可以保留消息的拷贝

POP3是无状态的

2.3.3.2 IMAP协议

所有消息统一保存在一个地方：服务器

允许用户利用文件夹组织消息，支持跨会话(Session)的用户状态：文件夹的名字、文件夹与消息ID之间的映射等

2.4 DNS应用

DNS：Domain Name System 域名解析系统

• 多层命名服务器构成的分布式数据库
• 应用层协议：完成名字的解析。Internet核心功能，用应用层协议实现

DNS服务：域名向IP地址的翻译；主机别名；邮件服务器别名；Web服务器负载均衡

2.4.1 分布式层次式数据库

根域名服务器：本地域名解析服务器无法解析域名时，访问根域名服务器。

顶级域名服务器(TLD, top-level domain)：负责com, org, net,edu等顶级域名和国家顶级域名，例如cn, uk, fr等。

权威(Authoritative)域名服务器：组织的域名解析服务器，提供组织内部服务器的解析服务。组织或服务提供商负责维护。

本地域名解析服务器：不严格属于层级体系，每个ISP有一个本地域名服务器，是默认域名解析服务器。

当主机进行DNS查询时，查询被发送到本地域名服务器，作为代理(proxy)，将查询转发给(层级式)域名解析服务器系统。

• 迭代查询：被查询服务器返回域名解析服务器的名字。“我不认识这个域名，但是你可以问题这服务器”
• 递归查询：将域名解析的任务交给所联系的服务器

只要域名解析服务器获得域名—IP映射，即缓存这一映射，一段时间过后，缓存条目失效(删除)

本地域名服务器一般会缓存顶级域名服务器的映射，因此根域名服务器不经常被访问

2.4.2 DNS记录

资源记录(RR, resource records)，RR format: (Name, Value, Type, TTL)

• Type=A

  • Name：主机域名
  • Value：IP地址

• Type=NS

  • Name：域(edu.cn)
  • Value：该域权威域名解析服务器的主机域名

• Type=CNAME

  • Name：某一真实域名的别名，如 www.ibm.com – servereast.backup2.ibm.com
  • Value：真实域名

• Type=MX

  • Value是与name相对应的邮件服务器

2.4.3 DNS协议和消息格式

DNS协议：查询 (query) 和回复 (reply) 消息，消息格式相同

消息头部：

• Identification：16位查询编号，回复使用相同的编号
• flags：查询或回复、期望递归、递归可用、权威回答
  

为公司 “Network Utopia”注册域名：

• 在域名管理机构(如Network Solutions)注册域名networkutopia.com。向域名管理机构提供你的权威域名解析服务器的名字和IP地址，域名管理机构向com顶级域名解析服务器中插入两条记录

  (networkutopia.com, dns1.networkutopia.com, NS)

  (dns1.networkutopia.com, 212.212.212.1, A)

• 在权威域名解析服务器中为www.networkuptopia.com加入Type A记录，为networkutopia.com加入Type MX记录

2.5 FTP

file transfer protocol，基于C/S架构。

FTP有两个连接，一个用于控制，一个用于数据传输。FTP客户端使用TCP在端口21联系FTP服务器，通过控制连接授权客户端，客户端浏览远程目录，通过控制连接发送命令，当服务器接收文件传输命令时，服务器打开第二个TCP数据连接(用于文件)到客户端，传输一个文件后，服务器关闭数据连接。

控制连接被称为带外传输

2.6 P2P应用

2.6.1 原理

• 没有服务器
• 任意端系统之间直接通信
• 节点阶段接入Internet
• 节点可能更换IP地址

问题：从一个服务器向N个节点分发一个文件F需要多长时间？

• 设：

  • u_s ——服务器上传带宽
  • u_i ——节点i的上传带宽
  • d_i ——节点i的下载带宽

• C/S架构

  • 服务器发送N个副本的时间：NF/u_s
  • 客户机i的下载时间：F/d_i
  • 分发N个F所需时间：d_cs=max{ NF/u_s , F/min{d_i} }——时间关于N是线性增长的

• P2P

  • 服务器必须发送一个副本(最小的消耗时间)：F/u_s
  • 客户机i的下载时间：F/d_i
  • 下载总量：NF bits
  • 最快的上传速率(服务器和所有的节点都在上传)：u_s + Σu_i
  • 分发N个F所需要的时间：d_P2P = max { F/u_s, F/min(d_i) , NF/(u_s + Σu_i) }——非线性的

2.6.2 文件分发：BitTorrent

• 洪流(torrent)：参与一个特定文件分发的所有对等方的集合
• 文件块(chunk)：一个洪流中的对等方下载等长度的文件块，典型长度256KB
• 追踪器(tracker)：一个对等方加入一个洪流时，它向追踪器注册自己并周期性地通知追踪器它还在线

BitTorrent

• 文件划分为256KB的chunk

• 节点加入torrent时没有chunk，但是会逐渐积累；每个节点向tracker注册以获得节点清单，与某些节点(“邻居”)建立连接

• 下载的同时，节点需要向其他节点上传chunk

• 节点可能加入或离开：一旦节点获得完整的文件，它可能(自私地)离开或(无私地)留下

• 获取chunk

  • 给定任一时刻，不同的节点持有文件的不同chunk集合
  • 节点(Alice)定期查询每个邻居所持有的chunk列表
  • 节点发送请求，请求获取缺失的chunk：稀缺优先

• 发送chunk：tit-for-tat

  • Alice向正在向其发送Chunk且速率最快的4个邻居发送chunk：每10秒重新评估top 4
  • 每30秒随机选择一个其他节点，向其发送chunk：新选择节点可能加入top 4，“optimistically unchoke”

2.6.3 索引技术

2.6.3.1 集中式索引

1. 节点加入时，通知中央服务器：IP地址和内容

2. Alice查找“Hey Jude”

3. Alice从Bob处请求文件

存在的问题：内容和文件传输是分布式的，但是内容定位是高度集中式的

• 单点失效问题
• 性能瓶颈
• 版权问题

2.6.3.2 洪泛式查询：Query flooding

完全分布式架构(Gnutella采用这种架构)——每个节点对它共享的文件进行索引，且只对它共享的文件进行索引、

覆盖网络(overlay network)：Graph

• 节点X与Y之间如果有TCP连接，那么构成一个边

• 所有的活动节点和边构成覆盖网络

• 边：虚拟链路

• 节点一般邻居数少于10个

查询消息通过已有的TCP连接发送，节点转发查询消息，如果查询命中，则利用反向路径发回查询节点。

2.6.3.3 层次是覆盖网络

介于集中式索引和洪泛查询之间的方法

每个节点或者是一个超级节点，或者被分配一个超级节点

节点和超级节点间维持TCP连接

某些超级节点对之间维持TCP连接

超级节点负责跟踪子节点的内容