您的位置: 首页  >  文章  >  网络应用

网络应用

分类: 文章 • 2024-05-04 08:15:52

网络应用

标签（空格分隔）： 计算机网络

网络应用的体系结构

常见有下面三种

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

服务器：

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

客户机：

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

网络应用

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

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

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

混合结构(Hybrid)

例子：Napster

  • 文件传输使用 P2P 结构
  • 文件的搜索使用 C/S 结构 - 集中式
    • 每个节点向中央服务器登记自己的内容
    • 每个节点向中央服务器提交查询请求，查找感兴趣的内容

网络应用

Socket：网络的 API

如何寻址进程

不同主机上的进程间通信，每个进程必须有一个标识符

  1. 如何寻址主机？ IP地址

    • Q: 主机有了 IP 地址后，是否足以定位进程？
    • A: 否，同一主机可能有同时有多个进程需要通信

  2. 端口号 / Port number

    • 为主机上每个需要通信的进程分配一个端口号（注意有些端口号是固定的，不能随便乱用）
    • 固定端口号如 HTTP Server: 80 ，Mail Server: 25

  3. 进程的标识符

    • IP 地址 + 端口号

应用层协议

  • 网络应用应该遵循应用层协议，为什么？

回答这个问题之前首先知道，常用很多是协议公开协议，这些公开协议又 RFC(Request For Comments) 定义，那么公开协议有什么作用呢，没错，作用就是为了让人们按着公开协议来进行网络编程。

比如说这边一个服务器，按照 Http 协议来编程，那么客户端也应该按照 Http 协议来编程，这样两个服务端和客户端才能够互相操作，相互理解对方请求什么需要什么。所以回答上面第一个问题，因为是为了互操作性。

  • 私有协议

有公开协议就有私有协议，而私有协议的应用场景常见就是 P2P 文件共享应用

  • 应该使用公开协议还是自己定制私有协议

这个问题应该根据应用场景来决定，使用公开协议的显著优点就是可以获取很多的资源，因为公开协议有着相当多的实际应用。而当当前的公开协议实在没有满足当前需求的时候，就应该大胆地定制私人协议

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

网络应用对传输服务的需求：

  1. 数据丢失(data loss)/可靠性(reliability)

    • 某些网络应用能够容忍一定的数据丢失：网络电话
    • 某些网络应用要求 100% 可靠的数据传输：文件传输，telnet

  2. 时间(timing)/延迟(delay)

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

  3. 带宽(bandwidth)

    • 某些应用只有在带宽达到最低要求时才 “有效” ：网络电视
    • 某些应用能适应任何带宽 - 弹性应用：Email

网络应用

Internet 提供的传输服务（传输层协议）

TCP 服务

  • 面向连接：客户机/服务器进程间需要建立连接
  • 可靠的运输
  • 流量控制：发送方不会发送速度过快，超过接收方的处理能力
  • 拥塞控制：当网络负载过重时能够限制发送方的发送速度
  • 不提供时间/延迟保障
  • 不提供最小带宽保障

UDP 服务

  • 无连接
  • 不可靠的数据传输
  • 不提供：
    • 可靠性保障
    • 流量控制
    • 拥塞控制
    • 延迟保障
    • 带宽保障

网络应用

web(World Wide Web) 应用

网页(Web Page) 包含多个对象

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

对象的寻址(addressing)

  • URL(Uniform Resource Locator): 统一资源定位器 RFC1738
  • 格式：Scheme://host:port/pah

网络应用

HTTP 协议

HTTP 概述

web 应用遵循什么协议？

超文本传输协议：HyperText Transfer Protocol

C/S 结构：

  • 客户 - Browser：请求、接受、展示 Web 对象
  • 服务器 - Web Server：相应客户的请求，发送对象

使用 TCP 传输层协议：

  • 服务器在 80 端口等待客户的请求
  • 浏览器发起到服务器的 TCP 连接(创建套接字 Socket)
  • 服务器接受来自浏览器的 TCP 连接
  • 浏览器(HTTP 客户端)与 Web 服务器(HTTP 服务器) 交换 HTTP 消息
  • 关闭 TCP 连接

无状态(stateless)：

无状态意味着服务器不维护任何有关客户端过去所发请求的信息

HTTP 连接的两种类型

非持久性连接：每个 TCP 连接最多允许传输一个对象 (HTTP 1.0)

非持久性连接例子：
网络应用
网络应用

相应时间分析建模：
网络应用

非持久性连接存在问题：
1. 每个对象需要 2 个 RTT
2. 操作系统需要为每个 TCP 连接开销资源
3. 浏览器会给每一个对象建立一个 TCP 连接，消耗服务端宝贵的 TCP 资源

持久性连接：每个 TCP 连接允许传输多个对象 (HTTP 1.1 default use)

  • 发送响应后。服务器保持 TCP 连接的打开
  • 后续的 HTTP 消息可以通过这个连接发送

无流水的持久性连接：

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

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

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

HTTP 请求消息

请求消息的例子：
网络应用

请求消息的格式：
网络应用

上传输入的方法：

  1. POST 方法：

    • 网页经常需要填写表格(form)
    • 在请求消息的消息体(entity body) 中上传客户端的输入

  2. URL 方法：

    • 使用 GET 方法
    • 输入信息通过 request 行的 URL 字段上传

请求消息的方法类型：
网络应用

HTTP 响应消息

网络应用

HTTP 响应状态代码（响应消息的第一行）

例示：

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

Cookie 技术

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

前因：HTTP 协议无状态，然而很多应用需要服务器掌握客户端的状态，如网上购物。这个时候单纯的 HTTP 协议已经不能满足需求了，这时 Cookie 技术派上用场了

Cookie 的组件

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

Cookie 的原理
网络应用

Cookie 的作用

  • 身份认证
  • 购物车
  • 推荐

Cookie 的问题

  • 隐私问题

Web 缓存 / 代理服务器技术

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

为什么要发明这种技术？

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

Web 缓存的/代理服务器技术

  • 用户设定浏览器通过缓存进行 Web 访问

  • 浏览器向缓存/代理服务器发送所有的 HTTP 请求

    • 如果所有对象在缓存中，缓存返回对象
    • 否则，缓存服务器向原始服务器发送 HTTP 请求，获取对象，然后返回给客户端并保存该对象

网络应用

  • 缓存即充当客户端，也充当服务器

  • 一般由 ISP(Internet 服务提供商) 架设

实例：
网络应用
网络应用
网络应用

上面例子表明了，使用 Web 缓存/代理技术可以有效地降低互联网上的访问延迟，但是还有一个问题需要解决，当服务器上面的数据更新了，Web 缓存下来的数据会变成不是最新的版本，解决这个问题需要用到 HTTP 的条件性 GET 方法

条件性 GET 方法的原理是，缓存服务器向原始服务器发送一个带有条件性的 GET 方法的消息，里面包含了缓存数据的版本信息 If-modified-since: <date> ，随后原始服务器根据实际情况返回 304 Not Modified ，如果版本更新了，则返回条件码 HTTP/1.0 200 OK 以及最新的数据

Email 应用

Email 应用的构成

邮件客户端

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

邮件服务器

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

SMTP 协议(Simaple Mail Transfer Protocol)

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

网络应用

命令/响应交互模式

  • 命令(command): ASCII 文本
  • 响应(response): 状态代码和语句

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

端口：25

传输过程的三个阶段：

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

Email 消息只能包含 7 位 ASCII 码

下面是 SMTP 的一个交互例示：(s: server, c: client)

网络应用

从上图可以看到 250 是一个成功的代码，而在 SMTP 协议中交互，首先我们要和服务器握手即 HELO ，随后使用 MAIL FROM，RCPT TO，DATA，.，来传输消息，最后 QUIT 来关闭传输

Email 消息格式

  • 头部行(header)

    • To
    • From
    • Subject

  • 消息体

    • 消息本身
    • 只能是 ASCII 字符

网络应用

MIME：多媒体邮件扩展

  • 通过在邮件头部增加额外的行以声明 MIME 的内容类型

实例：在 header 头部增加 MIME 的版本，数据编码格式，多媒体数据类型以及参数声明，以及编码后的数据，传输到目标服务器后按照对应的格式编码
网络应用

邮件访问协议

SMTP 协议只是用来进行简单的邮件传输，邮件接受方需要通过邮件访问协议来从服务器获取邮件

POP: Post Office Protocol

认证/授权(客户端–服务器) 和下载

认证过程
- 客户端命令
- User: 声明用户名
- Pass: 声明密码

  • 服务器响应
    • +OK
    • -ERR

事务阶段

  • List：列出消息数量
  • Retr：用编号获取信息
  • Dele：删除消息
  • Quit

网络应用
第一部分为认证阶段，第二部分为事务阶段

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

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

POP3 是无状态的

IMAP: Internet Mail Access Protocol

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

允许用户利用文件夹组织消息

IMAP 支持跨会话(Session)的用户状态
- 文件夹的名字
- 文件夹与消息 ID 之间的映射等

  • 更多功能
  • 更加复杂
  • 能够操纵服务器上储存的消息
HTTP: 163, QQ Mail 等

DNS 应用

DNS(Domain Name System) 概述

DNS 解决的是 Internet 上主机/路由器的识别问题
- IP 地址 （网络上实际使用）
- 域名： www.gdut.edu.cn （人类使用）

IP 地址是一个 32 位的二进制数，而我们使用的是可读性更高域名地址，那么很显然，我们需要解决的下一个问题就是域名和 IP 地址之间的映射

域名解析系统 DNS 到底是什么？

  1. 多层命名服务器构成的分布式数据库

  2. 应用层协议：完成名字的解析

    • Internet核心功能，用应用层协议实现
    • 网络边界复杂

DNS 服务

  • 域名向 IP 地址的翻译

  • 主机别名

  • 邮件服务器别名

  • 负载均衡：Web 服务器（如一个域名多个映射）

为什么不使用集中式的 DNS？

  • 单点失败问题（全球宕机）
  • 流量问题
  • 距离问题（全球时延）
  • 维护性问题

DNS 分布式层次式数据库如何实现

网络应用

如上图，全球共有 13 个根域名服务器，每个根域名服务器映射着若干个顶级域名服务器，然后顶级域名服务器再映射着相关的权威域名服务器，由权威域名服务器返回 IP 地址

比如，客户想要查询 www.amazon.com 的 IP ，流程应该是这样的：

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

DNS 根域名服务器

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

  • 根域名服务器

    • 如果不知道映射，访问权威域名服务器
    • 获得映射
    • 向本地域名服务器返回映射

TLD 和权威域名解析服务器

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

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

  • 权威(Authoritative)域名服务器：组织的域名解析服务器，提供组织内部服务器的解析服务

    • 组织负责维护
    • 服务提供商负责维护

本地域名解析服务器

  • 不严格属于层级体系

  • 每个 ISP 有一个本地域名服务器

    • 默认域名解析服务器

  • 当主机进行 DNS 查询时，查询被发送到本地的域名服务器

    • 作为代理(proxy)，将查询转发给层级式域名解析服务器系统

  • 只要域名解析服务器获得域名 - IP 映射，即缓存这一映射

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

DNS 查询示例

Cis.poly.edu 的主机想获得 gaia.cs.umass.edu 的 IP 地址

  • 迭代查询
    • 被查询服务器返回域名解析服务器的名字
    • “我不认识这个域名，但是你可以问这个服务器”

网络应用

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

网络应用

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 相对应的邮件服务器

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)
对照上面的 DNS 消息格式，可以解读出第一句的意思是在 com 顶级域名解析服务器中查询 networkutopia.com 将返回 “Network Utopia” 的权威域名解析服务器的名字 dns1.networkutopia.com 而第二句就是 “Network Utopia” 的权威域名解析服务器的名字对应的 212.212.212.1 的 IP 地址

  • 至此，别人已经可以通过 com 顶级域名服务器找到你的权威域名解析服务器，为了返回主页，还需要在权威域名解析服务器中为 www.networkuptopia.com 加入 Type A 记录以返回主页 IP 地址。有需要邮件功能还可以为 networkuptopia.com 加入 Type MX 记录

P2P

P2P 架构

  • 没有服务器

  • 任意端系统之间直接通信

  • 节点阶段性接入 Internet

  • 节点可能更换 IP

应用：文件分发

在客户 - 服务器文件中，该服务器必须向每个对等方发送该文件的一个副本，即服务器承受了极大的负担，并且消耗了大量的服务器带宽。在 P2P 文件分发中，每个对等方能够重新分发它所有的该文件的任何部分，从而在分发过程中协助该服务器。

网络应用

可以看到，C/S 的分发时间随着 N 的增大线性增长，对等方的数量增加 100 倍，将文件分发到所有对等方的时间就要多 100 倍

现在来对 P2P 体系结构进行简单的分析，其中 每个对等方能够帮助服务器分发该文件 。特别地，当一个对等方接收到某些文件数据，他能够使用自己的上载能力重新将数据分发给其他对等方。计算 P2P 体系结构的分发时间比 c/s 体系结构的更为复杂，因为分发时间取决于每个对等方如何向其他对等方分发该文件的各个部分。计算公式如下：

网络应用

两种结构的耗时对比:

网络应用

BitTorrent 协议

BitTorrent 是一种用于文件分发的流行 P2P 协议。参与一个特定文件分发的所有对等方的集合被成为一个洪流(torrent)。在一个洪流中的对等方彼此下载等长度的文件块(chunk)，典型的块长度为 256KB 。当一个对等方首次加入一个洪流中时，他没有块。随着时间的流逝他累积了越来越多的块。当他下载块时也为其他对等方上传了多个块。一旦某个对等方获得了整个文件，他也许自私地离开洪流，或大公无私地留在该洪流中并继续向其他对等方上传块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流。

细节：

  • 每个洪流有一个 tracker 追踪器，追踪洪流中的对等方

  • 获取 chunk

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

  • 发送 chunk: tit-for-tat

    • 向 4 个邻居发送 chunk ，这四个邻居是给自己发送 chunk 速率最快的四个（每10秒重新评估）
    • 每 30 秒随机选择一个其他节点，向其发送 chunk

网络应用

P2P 应用: 索引技术

在 P2P 应用中，虽然是两个端主机之间互相直接连接，但是我们却需要先找到这个要连接的主机的 IP 地址，更具体地是，我们想要在网络中寻找一个资源，需要根据这个资源的名字找到资源所在的主机 IP 和端口号。可参考 博文

相关推荐