Dying Memory

Keep moving

0%

计算机网络应用层01

Posted on In
Symbols count in article: 5.5k Reading time ≈ 5 mins.
计算机网络应用层

网络应用的体系结构

客户机/服务器结构

Client Server C/S （比如 WEB 应用）

服务器

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

客户机

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

点对点结构

Peer to Peer P2P （BT 文件下载）

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

优点：高度可伸缩，缺点：实现起来复杂，难于管理

混合结构

Hybrid

Napster

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

每个节点向中央服务器登记自己的内容，每个节点向中央服务器提交查询请求。

网络应用进程通信

端口号

进程寻址=端口号

主机寻址= IP 地址

应用层协议

  • 网络应用需遵循应用层协议
  • 公开的协议
    • 由 RFC （Request for Comments）定义
    • 允许互操作
    • HTTP、SMTP…
  • 私有协议
    • 多数 P2P 文件共享应用

应用层协议内容

消息的类型（type）

  • 请求消息
  • 响应消息

消息的语法（syntax）/格式

  • 消息中有哪些字段
  • 每个字段如何描述

字段的语义（semantics）

  • 字段中信息的含义

规则（rules）

  • 进程何时发送/响应消息
  • 进程如何发送/响应消息

网络应用的需求与传输层服务

网络应用的需求

数据丢失（data loss）/可靠性（reliability）

  • 某些网络应用能够容忍一定的数据丢失：网络电话、在线视频
  • 某些网络应用要求 100% 可靠的数据传输：文件传输、网络银行

时间（timing）/延迟（delay）

  • 有些应用只有在延迟足够低时才有效：网路电话/网络游戏

带宽（bandwidth）

  • 某些应用只有在带宽达到最低要求时才有效：网络视频
  • 某些应该能够适应任何带宽，弹性应用。如 email

安全性

Application Data loss Bandwidth Time Sensitive
file transfer no loss elastic no
e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant hard require yes, 100 msec
stored audio/video loss-tolerant hard require yes, few secs
interactive games loss-tolerant few kbps up yes, 100 msec
instant messaging no loss elastic yes and no

Internet 提供的传输服务

TCP服务

面向连接

客户机/服务器进程间需要建立连接

可靠的传输
流量控制

发送方不会发送速度过快，超过接收方的处理能力

拥塞控制

当网络负载过重时能够限制发送方的发送速度

不提供时间/延迟保障
不提供最小带宽保障

UDP 服务

无连接
不可靠的数据传输
不提供可靠性保障
不提供流量控制
不提供拥塞控制
不提供延迟保障
不提供带宽保障
Application Application layer protocol Underlying transport protocol
e-mail SMTP TCP
remote terminal access Telnet TCP
WEB HTTP TCP
file transfer FTP TCP
streaming multimedia proprietary（RealNetWorks） TCP or UDP
internet telephony proprietary（Vonage、Dialpad） typically UDP

WEB 与 HTTP

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

有状态的协议往往更复杂，需要维护状态（历史信息），如果客户和服务器失效，会产生状态的不一致，解决这种不一致代价高。

HTTP 连接的两种类型

非持久性连接（Nonpersistent HTTP）

如一张网页包含10个图片链接，此时网速很慢的话，图片会一个接一个显示。

  • HTTP 1.0 版本使用
非持久性连接存在的问题
  • 每个对象需要两个 RTT
  • 操作系统需要为每个 TCP 连接开销资源（overhead）

持久性连接（Persistent HTTP）

  • HTTP 1.1 版本默认使用

无流水（pipelining）的持久性连接

  • 客户端只有收到前一个响应后才发送新的请求
  • 每个被引用的对象耗时一个 RTT

带有流水机制的持久性连接

  • HTTP 1.1 的默认选项
  • 客户端只要遇到一个引用对象就尽快发出请求
  • 理想情况下，收到所有的引用对象只需耗时约一个 RTT

RTT（Round Trip Time）

从客户端发送一个很小的数据包到服务器并返回所经历的时间。

HTTP 协议无状态，但是很多应用需要服务器掌握客户端的状态，如网上购物。

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

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

不限于如下应用：

  • 身份认证
  • 购物车
  • 推荐
  • Web e-mail

隐私问题

Web缓存/代理服务器技术

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

  • 缩短客户请求的响应时间
  • 减少机构/组织的流量
  • 在大范围内（Internet）实现有效的内容分发（CDN）

与 Cookie 技术不同，Cookie 旨在解决功能上的问题，而缓存技术是在性能上进行优化处理。一个面向功能一个面向性能。

缓存既充当客户端也充当服务器。一般由 ISP 架设。

一致性问题

条件性 GET 请求，request header if-modified-since，response 304 Not Modified。

E-mail

SMTP

  • 使用 TCP 进行 email 消息的可靠传输
  • 传输过程的三个阶段
    • 握手
    • 消息的传输
    • 关闭
  • 命令/响应交互模型
    • 命令（command）ASCII 文本
    • 响应（response）状态代码和语句
  • email 消息只能包含 7 位 ASCII 码

SMTP VS HTTP

  • HTTP 拉式 （pull）
  • SMTP 推式 （push）
  • 都使用命令/响应交互模型
  • 命令和状态码都是 ASCII 码
  • HTTP：每个对象封装在独立的响应消息中
  • SMTP：多个对象在由多个部分构成的消息中发送

E-mail 消息格式

  • SMTP：消息的传输/交换协议
  • 文本格式消息
    • 头部行 （header）
      • to
      • from
      • subject
    • 消息体 （body）
      • 消息本身
      • 只能是 ASCII 字符

Email 消息格式：多媒体扩展

MIME

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

邮件访问协议 access protocol

从服务器获取邮件的协议，SMTP 是传输协议。

  • POP Post Office Protocol 认证/授权（客户端-服务器）和下载
  • IMAP Internet Mail Access Protocol
    • 更多的功能
    • 更加复杂
    • 能够操纵服务器上存储的消息
  • HTTP （基于 web 的客户端）

POP 协议

  • 认证过程
    • 客户端命令
      • User：声明用户名
      • Pass：声明密码
    • 服务器响应
      • +OK
      • -ERR
  • 事务阶段
    • List：列出消息数量
    • Retr：用编号获取消息
    • Dele：删除消息
    • Quit
  • 下载并删除模式 （用户如果换了客户端软件，无法重读该消息）
  • 下载并保持模式 （不同客户端都可以保留消息的拷贝）
  • POP3 是无状态的

IMAP 协议

有状态的

  • 所有消息统一保存在一个地方：服务器
  • 允许用户利用文件夹组织消息
  • IMAP 支持跨会话（Session）的用户状态
    • 文件夹的名字
    • 文件夹与消息 ID 之间的映射

DNS

Domain Name System。主要解决 Internet 上主机/路由器的识别问题。 IP 地址与域名的映射。

域名解析系统：多层命名服务器构成的分布式数据库，是一个应用层协议完成名字的解析。

DNS服务

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

为什么不使用集中式 DNS

  • 单点失败问题
  • 流量问题
  • 距离问题
  • 维护性问题

分布式层次式数据库

  1. 根域名服务器 13个
  2. 顶级和权威域名解析服务器
  3. 权威（Authoritative）域名服务器
  4. 本地域名解析服务器 （不属于层级体系）

根域名服务器

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

顶级和权威域名解析服务器

顶级域名服务器（TLD top-level domain），负责com、org、net、edu等

顶级域名和国家顶级域名 （cn、uk）

  • Network Solutions 维护顶级域名服务器
  • Educause 维护 edu 顶级域名服务器

权威（Authoritative）域名服务器

组织的域名解析服务器，提供组织内部服务器的解析服务，由组织负责维护、服务提供商负责维护。自治的。

本地域名解析服务器

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

迭代查询

  • 被查询服务器返回域名解析服务器的名字
  • 我不知道这个名字但你可以问这个服务器

递归查询

  • 将域名解析的任务交给所联系的服务器

DNS 记录缓存和更新

只要域名解析服务器获得域名-IP映射，就要缓存这一映射，一段时间过后，缓存条目失效（删除）。

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

记录的更新/通知机制

  • RFC 2136
  • Dynamic Updates in the Domain Name System (DNS UPDATE)

DNS 记录和消息格式

资源记录（RR resource records）

RR format: (name, value, type, ttl)

type

  • Type=A
    • Name=主机域名
    • Value=IP 地址
  • Type=NS
    • Name=域（edu.cn）
    • Value=该域权威域名解析服务器的主机域名 指定了这个域的解析服务器是谁
  • Type=CNAME
    • Name=某一真实域名的别名
    • Value=真实域名
  • Type=MX
    • Value是与name相对应的邮件服务器

DNS 协议

  • 查询（query）和回复（repaly）的协议

  • 消息格式相同

  • 消息头部

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

如何注册域名

在域名管理机构（如 Network Solutions）注册域名。

  • 向域名管理机构提供权威域名解析服务器的名字和 IP 地址
  • 域名管理机构向 com 顶级域名解析服务器中插入两条记录
    (xxx.com, xxx.xxx.com, NS),(xxx.xxx.com, 111.111.111.111, A)

P2P

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

BitTorrent 协议

  • tracker 跟踪参与 torrent 的节点
  • torrent 交换同一个文件的文件块的节点组
  • 文件划分为 256 KB 的 chunk
  • 节点加入 torrent
    • 开始没有 chunk，会逐渐积累
    • 向 tracker 注册以获得节点清单，与某些节点（邻居）建立连接
  • 下载的同时，节点需要向其他节点上传 chunk
  • 节点可能加入或离开
  • 一旦节点获得完整的文件，它可能（自私的）离开或（无私的）留下
  • 获取 chunk
    • 给定任一时刻，不同的节点持有文件的不同 chunk 集合
    • 节点定期查询每个邻居所持有的 chunk 列表
    • 节点发送请求，请求获取缺失的 chunk
      • 稀缺优先
  • 发送 chunk： tit-for-tat
    • 向正在向自己发送 chunk 速率最快的四个节点发送，每10秒重新评估 top4
    • 每 30 秒随机选择一个其他节点，向其发送 chunk
      • 新选择节点可能加入 top4
      • optimistically unchoke

上传速率高，则能找到更好的交易伙伴，从而更快的获取文件。

P2P 索引

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

文件共享（电驴）

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

即时消息（QQ）

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

集中式索引

中央目录服务器 centralized directory server，内容和文件传输是分布式的，但是内容定位是高度集中式的。

  • 单点失效问题
  • 性能瓶颈
  • 版权问题（容易被发现，被打击）

洪范式查询 Query flooding

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

覆盖网络（overlay network）Graph 逻辑网络

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

洪范式查询流程

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

层次式覆盖网络

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

p2p层次集中索引