计算机网络——应用层（二）

Web 与 HTTP

网页包含多个对象

• 对象：HTML文件、JPEG图片、视频文件、动态脚本等
• 基本HTML文件：包含对其他对象引用的链接

对象的寻址

• URL：资源定位器
• Scheme://host:port/path
  

HTTP协议概述

• HTTP（HyperText Transfer Protocol） Web 的应用层协议。
• 使用 C/S结构
  • 客户 —— Browser：请求、接收、展示 Web 对象。
  • 服务器 —— Web Server：响应客户的请求，发送对象
• HTTP 版本： 1.0，1.1
• 使用 TCP 传输服务
  • 服务器在 80 端口等待客户的请求
  • 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）
  • 服务器接受来自浏览器的 TCP 连接
  • 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息
  • 关闭 TCP 连接。
• 无状态 ：服务器不维护任何有关客户端过去所发请求的信息

HTTP 连接

• 非持久性连接

  • 每个 TCP 连接最多允许传输一个对象
  • HTTP 1.0版本使用非持久性连接
    

• 响应时间分析与建模

  • RTT：从客户端发送一个很小的数据报到服务器并返回所经历的时间。
  • 响应时间：
    • 发起、建立 TCP 连接：1 个 RTT
    • 发送 HTTP 请求消息到 HTTP 响应消息的前几个字节到达： 1 个 RTT
    • 响应消息中所含的文件/对象传输时间
    • Total = 2RTT + 文件发送时间

• 非持久性连接的问题
  • 每个对象需要 2 个 RTT
  • 操作系统需要为每个 TCP 连接开销资源
  • 浏览器需要打开并行的 TCP 连接以获取网页所需对象
• 持久性连接
  • 每个 TCP 连接允许传输多个对象
  • HTTP 1.1版本默认使用持久性连接
  • 发送响应后，服务器保持 TCP 连接的打开
  • 后续的 HTTP 消息可以通过这个连接发送
  • 无流水的持久性连接
    • 客户端只有收到前一个响应后才发送新的请求
    • 每个被引用的对象耗时 1 个 RTT
  • 带流水机制的持久性连接
    • HTTP 1.1 的默认选项
    • 客户端只要遇到一个引用对象就尽快发出请求
    • 理想情况下，收到所有的引用对象只需耗时约 1 个 RTT

HTTP 消息格式

请求消息

• 直接可读，ASCII码
  
• 请求消息的通用格式
  

  HTTP 方法

• 上传输入

  • POST方法

    • 网页经常需要填写表单（form）
    • 在请求消息的消息体中上传客户端的输入

  • GET(URL 方法)

    • 输入信息通过 request 行的 URL 字段上传，会显示在 URL 中
      
• 方法的类型

  • HTTP 1.0

    • GET
    • POST
    • HEAD ：请 Server不要将所请求的对象放入响应消息中。

  • HTTP 1.1

    • GET, POST, HEAD
    • PUT：将消息体中的文件上传到 URL 字段所指定的路径
    • DELETE：删除 URL 字段所指定的文件

HTTP 响应消息

HTTP 响应状态代码

• 成功响应：
  这类状态代码表明服务器成功地接受了客户端请求。

状态码	解释
200 OK	服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 Created	请求成功并且服务器创建了新的资源。
202 Accepted	请求已经接收到，但处理尚未完成

• 重定向
  客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。

状态码	解释
300 Mutiple Choice	被请求的资源有一系列可供选择的回馈信息
301 Moved Permanently	被请求的资源已永久移动到新位置
302 Found	请求的资源在现状临时从不同的URI响应请求
307 Temporary Redirect	请求的资源现状临时从不同的URI响应请求
308 Permanent Redirect	请求的资源永久移动到另一个URI

• 客户端响应
  发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。

状态码	解释
400 Bad Request	服务器看不懂客户端传来的请求
403 Forbidden	服务器已理解请求但拒绝执行
404 Not Found	请求的资源不存在服务器上

• 服务端响应
  服务器由于遇到错误而不能完成该请求。

状态码	解释
500 Internal Server Error	服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。
501 Not Implemented	此请求方法不被服务器支持且无法被处理
502 Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503 Service Unavailable	由于临时的服务器维护或者过载，服务器当前无法处理请求。
504 Gateway Timeout	作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
505 HTTP Version Not Supported	服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。

Cookie

HTTP 协议无状态，很多应用需要服务器掌握客户端的状态，如一个 Web 站点通常希望能够识别用户，希望与用户身份和内容联系起来，为此 HTTP 使用了 Cookie。

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

Cookie 的组件

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

Cookie 的原理

Cookie 的作用

• 身份认证
• 购物车
• 推荐
• …
• Cookie 的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害。

Web 缓存 / 代理服务器技术

在不访问服务器的前提下满足客户端的 HTTP 请求。

• 缩短客户请求的响应时间
• 减少机构/组织的流量
• 在大范围内实现有效的内容分发
  
• 用户设定浏览器通过缓存进行 Web 访问
• 浏览器向缓存 / 代理服务器发送所有的 HTTP 请求
  • 如果所请求对象在缓存中，缓存返回对象
  • 否则，缓存服务器向原始服务器发送 HTTP 请求，获取对象，然后返回给客户端并保存该对象。
• 缓存一般充当客户端，也充当服务器
• 一般由 ISP 架设

条件GET

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

• 缓存：

  • 在 HTTP 请求消息中生命所持有版本的时间
  • If-modified-since:<date>

• 服务器：
  • 如果缓存的版本不是最新的，则响应消息中不包含对象
  • HTTP/1.0 304 Not Modified

Email 应用

Email 应用的构成：

• 邮件服务器

  • 邮箱：存储发给该用户的 Email
  • 消息队列：存储等待发送的 Email

• 用户代理（邮件客户端）

  • 读写 Email 消息
  • 与服务器交互，收发 Email 消息
  • Outlook, Foxmail, Web 客户端

• SMTP 协议

  • 邮件服务器之间传递消息所使用的协议
  • 客户端：发送消息的邮件服务器
  • 服务器：接收消息的邮件服务器

SMTP 协议

• 使用 TCP进行 Email 消息的可靠传输

• 端口号：25

• 传输过程的三个阶段：

  • 握手
  • 消息的传输
  • 关闭

• 命令 / 响应交互模式

  • 命令：ASCII 文本
  • 响应：状态代码和语句

• Email 消息只能包含 7 位 ASCII码

• 实例
  

1. Alice调用她的邮件代理程序并提供Bob的邮件地址（例如bob@ homeschool.edu),撰写报文，然后指示用户代理发送该报文。
2. Alice的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。
3. 运行在 Alice 的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就创建一个到运行在 Bob 的邮件服务器上的 SMTP 服务器的 TCP 连接。
4. 在经过一些初始 SMTP 握手后，SMTP 客户通过该 TCP 连接发送 Alice 的报文
5. 在 Bob 的邮件服务器上，SMTP 的服务器端接收该报文。Bob 的邮件服务器然后将该报文放入 Bob 的邮箱中。
6. 在Bob方便的时候，他调用用户代理阅读该报文

SMTP 协议总结

• 使用持久性连接
• 要求消息必须由 7 位 ASCII 码构成
• SMTP服务器利用 CRLF.CRLF确定消息的结束。
• 与 HTTP 对比：
  • HTTP：拉取（PULL）SMTP：推送（PUSH）
  • 都使用 命令 / 响应 交互模式
  • 命令和状态代码都是 ASCII 码
  • HTTP：每个消息封装在独立的响应消息中。 SMTP：多个对象在由多个部分构成的消息中发送。

Email 消息格式

• SMTP：Email 消息的传输 / 交换协议
  
  

邮件访问协议

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

• POP：Post Office Protocol
  认证 / 授权 （客户端 —— 服务器）和下载
• IMAP：Internet Mail Access Protocol
  更多功能，更加复杂，能够操纵服务器上存储的消息。
• HTTP：163，QQ邮箱 Web端

POP

• 下载并删除模式：用户如果换了客户端软件，无法重读该邮件。
• 下载并保持模式：不同客户端都可以保留消息的拷贝
• POP3 是无状态的

IMAP

• 所有消息统一保存在服务器
• 允许用户利用文件夹组织消息
• IMAP 支持跨会话（Session）的用户状态：
  • 文件夹的名字
  • 文件夹与消息 ID 之间的映射等
  • 即：可以在服务器上建立文件夹，不同客户端保持同步。

DNS

DNS 概述

域名解析系统 DNS：将域名 和 IP 地址之间建立映射。

• 多层明明服务器构成的分布式数据库
• 应用程协议：完成名字的解析
  • Internet 核心功能，用应用层协议实现
  • 网络边界复杂

DNS 服务

• 域名向 IP 地址的翻译
• 主机别名
• 邮件服务器别名
• 负载均衡：Web 服务器，在冗余的服务器之间进行负载分配。

为什么不使用集中式 DNS?

• 单点故障
• 通信容量
• 远距离的集中式数据库：单个 DNS 服务器在现实中不可能邻近所有查询客户，中间可能要经过低速和拥塞的链路。
• 维护：单个 DNS 服务器不得不为所有的主机保留记录。

DNS 工作机理概述

分布式层次式数据库

客户端想要查询 www.amazon.com 的 IP

• 客户端查询根服务器，找到 com 域名解析服务器
• 客户端查询 com 域名解析服务器，找到 amazon.com 域名解析服务器
• 客户端查询 amazon.com 域名解析服务器，获得 www.amazon.com 的 IP 地址

DNS 根域名服务器

• 本地域名解析服务器无法解析域名时，访问根域名服务器
• 根域名服务器
  • 如果不知道映射，访问顶级域名服务器
  • 获得映射
  • 向本地域名服务器返回映射

TLD 和权威域名解析服务器

• 顶级域名服务器（TLD）：负责 com, org, net, edu 等顶级域名和国家顶级域名，如：cn, uk等
• 权威域名服务器：组织的域名解析服务器，提供组织内部服务器的解析服务
  • 组织负责维护
  • 服务提供商负责维护

本地域名解析服务器

• 不严格属于层级体系
• 每个 ISP 有一个本地域名服务器（默认域名解析服务器）
• 当主机进行 DNS 查询时，查询被发送到本地域名服务器
• 作为代理，将查询转发给（层级式）域名解析服务器系统

DNS查询示例

迭代查询：

1. 当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。
2. 然后让本地服务器进行后续的查询。
3. 根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。
4. 顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。
5. 最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机
   

递归查询
所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。
因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

上图中：2，3，4，5，6，7属于迭代查询；1，8，属于递归查询。

例题

DNS 缓存

只要域名解析服务器获得域名——IP 之间的映射，即缓存这一映射。

• 一段时间过后，缓存条目失效（删除）
• 本地域名服务器一般会缓存顶级域名服务器的映射
  • 因此根域名服务器不经常被访问

DNS 记录和报文

DNS记录

资源记录（RR）：提供了主机名到 IP 地址的映射。

• Type = A
  • Name：主机域名
  • Value：IP 地址
• Type = NS
  • Name：域（edu.cn）
  • Value：该域权威域名解析服务器的主机域名
• Type = CNAME
  • Name：某一真实域名的别名，如：(foo.com, relay1.bar.foo.com,CNAME)
• Type = MX
  • Value 是与 name 相对应的邮件服务器。

DNS 协议与消息

DNS 协议

• 查询(query)和回复(reply消息)
• 消息格式相同

消息头部

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

P2P 应用

P2P 文件分发

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

变量解释：

• $u_s$：服务器接入链路的上载速率
• $u_i$：第 i 对等方接入链路的上载速率
• $d_i$：表示了第 i 对等方接入链路的下载速率
• $F$：被分发的文件长度(/bit)
• $N$：表示要获得的该文件副本的对等方数量。
• 分发时间：是所有 N 个对等放得到文件的副本所需要的时间。

文件分发：客户机 / 服务器（C/S）

• 服务器必须向 N 个 对等方的每个传输该文件的一个副本，大小为 $NF$ 比特。该服务器的上载速率是$u_s$，分发该文件的时间至少为$NF/u_s$
• 令$d_{min}$表示具有最小下载速率的对等方的下载速率： d m i n = m i n { d 1 , d 2 , . . . , d N } d_{min} = min\{d_1,d_2,...,d_N\} dmin​=min{d1​,d2​,...,dN​}。
• 具有最小下载速率的对等方不可能在少于 $F/d_{min}$的时间内获得该文件的所有比特，因此最小分发时间至少为$F/d_{min}$
  总结：
• 上传时间：$NF/u_s$
• 客户机 i 下载时间：$F/d_i$

文件分发：P2P

• 在分发的开始，只有服务器具有文件。
• 该服务器必须经其接入链路至少发送该文件的每个比特一次，时间至少为 $F/u_s$
• 客户机最小分发时间至少为 $F/d_{min}$
• 系统整体的总上载能力等于服务器的上载速率加上每个单独的对等方的上载速率：$u_{total}=u_s+u_1+u_2+...+u_N$
• 共需交付（上载 F 比特），最小分发时间至少为 $NF/u_{total}$

总结：

• 服务器必须发送一个副本，时间：$F/u_s$
• 客户机 $i$ 需要 $F/d_i$的时间下载
• 总共需要下载$NF$比特
• 最快的可能上传速率：$NF/u_{total}$
• P2P的最小分发时间： m a x { F / u s , F / d m i n , N F / u t o t a l } max\{F/u_s,F/d_{min},NF/u_{total}\} max{F/us​,F/dmin​,NF/utotal​}

BitTorrent

• 文件划分位 256KB 的块(chunk)

• 节点加入 torrent

  • 没有块，但是会逐渐积累
  • 向追踪器(tracker)注册以获得节点清单，与某些邻居节点建立连接。

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

• 节点可能加入或离开

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

• 获取块

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

• 发送块：一报还一报（tit-for-tat）

  • Alice 向 4 个邻居发送块：选择正在向Alice 发送块，且速率最快的4个，每10秒重新评估 top 4
  • 每 30 秒随机选择一个其他节点（试探），向其发送块：新选择节点可能加入 top 4
  • 上传速率高，则能找到更好的交易伙伴，从而更快地获取文件。

P2P：搜索信息

P2P系统的索引： 信息到节点位置（IP + 端口号）的映射

文件共享（电驴）

• 利用索引动态跟踪节点所共享的文件的位置
• 节点需要告诉索引它拥有那些文件
• 节点搜索索引，从而获知能够得到那些文件。

即时消息（QQ）

• 索引负责将用户名映射到位置
• 当用户开启即时通讯应用时，需要通知索引它的位置
• 节点检索索引，确定用户的 IP 地址

集中式索引

Napster 最早采用

1. 节点加入时，通知中央服务器：IP 地址，内容
2. Alice 查找 “Hey Jude”
3. Alice 从 Bob 处请求文件（P2P）

问题：

内容和文件传输时分布式的，但是内容定位是高度集中式的。

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

洪泛式查询

• 完全分布式架构
• Gnutella 使用这种架构
• 每个节点对它共享的文件进行索引，且只对它共享的文件进行索引。

覆盖网络：

• 节点 X与 Y之间如果有 TCP 连接，那么构成一个边
• 所有活动节点和边构成覆盖网络
• 边：虚拟链路
• 节点一般邻居数小于 10 个

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

层次式覆盖网络

• 介于集中式索引和洪泛查询之间
• 每个节点或是一个超级节点，或是被分配一个超级节点
  • 节点和超级节点间维持 TCP 连接
  • 某些超级节点对之间维持 TCP 连接
• 超级节点负责跟踪子节点的内容

案例：Skype

• 本质上是 P2P：用户/节点对之间直接通信
• 私有应用层协议
• 采用层次式覆盖网络架构
• 索引负责维护用户名与 IP 地址之间的 映射
• 索引分布在超级节点上。

Socket 编程