2_application

网络应用体系结构

网络应用需要网络的基础环境，一部分软件在本机上运行，另一部分软件在其他计算设备上运行，网络应用的运行就是这两部分软件进行的交互过程。

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

image-20200923113159909

服务器：对外提供服务的软硬件

  • 7*24小时提供服务
  • 具有永久性访问地址/域名
  • 利用大量服务器实现可扩展性（需要提供带宽多时，增大服务器功效，反之降低）

客户机：使用服务器提供的服务

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

例子

image-20200923113059502

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

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

P2P比C/S有较高的可伸缩性，但是更难于管理。

混合结构(Hybrid)

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

网络应用进程通信

进程：主机上运行的程序

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

不同主机上运行的进程的通信：消息交换

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

服务器进程：等待通信的进程

采用P2P的进行架构的进程也存在客户机进程与服务器进程，这一点是依据其二者的定义就可以得到判断。

套接字(socket)：是对于网络硬件以及网络协议栈的抽象，进程使用套接字进行发送和接受消息，可以认为是传输基础设施向进程提供的API。

进程的寻址

不同主机上的进程进行通信，每个进程必须拥有标识符。

  • IP地址：进行不同主机的区分

  • 端口号(Port number)：进行主机上不同进程的区分

  • IP地址 + 端口号 = 进程的寻址

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

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

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

时间(timing)/延迟(delay)

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

带宽(bandwidth)

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

常见网络应用对于传输服务的需求，以及所使用的协议

image-20200923155745663

image-20200923160417683

应用层服务与协议总述

应用层定义应用在不同主机上的交流机制，依凭传输层服务完成数据的交流。

The application layer only standardizes communication and depends upon the underlying transport layer protocols to establish host-to-host data transfer channels and manage the data exchange in a client-server or peer-to-peer networking model.

the TCP/IP application layer does not describe specific rules or data formats that applications must consider when communicating.

应用层协议的分类

  • 公开协议，由RFC(Request For Comments)定义，允许互操作，Eg：HTTP, SMTP...
  • 私密协议，Eg：多数P2P文件共享应用都会使用私密协议来获得经济效益

应用层协议的内容

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

World Wide Web

网页（Web Page）

  • 网页包含多个对象（objects）
  • 对象：HTML文件、JPEG图片、视频文件、动态脚本等
  • 基本HTML文件：包含对其他对象引用的链接
  • 寻址：uniform Resource Locater (统一资源定位器，URL)。

URL的基本格式：

HTTP协议

HyperText Transfer Protocol(HTTP)协议也就是超文本传输协议。

特点

  • 采用请求/响应模式，采用80端口
  • C/S架构：
    • 客户(Browser)：请求、接收、展示Web 对象
    • 服务器(Web Server)：响应客户的请求 ，发送对象
  • 无状态

无状态(stateless)：服务器不维护任何有关客户端过去所发请求的信息
使用无状态的协议的优点（有状态的协议更复杂）：

  • 需维护状态(历史信息)
  • 如果客户或服务器失 效，会产生状态的不 一致，解决这种不一 致代价高

HTTP连接类型（规则）

非持久性连接

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

image-20200923205217194

image-20200923205237299

image-20200923205538089

注意：时间计算所给图示的括号，发送文件所需时间是粗线的宽度，第二个RTT不包括粗线的宽度。

问题：

  • 每个对象需要两个RTT。
  • 操作系统需要为每个TCP连接开销资源(overhead)。
  • 为了快速发送文件，会并行发送文件，这会造成服务器的巨大载荷。

持久性连接

持久性连接(Persistent HTTP) ，每个TCP连接允许传输多个对象。

  • 无流水(pipelining)的持久性连接：
    • 客户端只能收到前一个响应后才发送新的请求。
    • 每个被引用对象耗时1个RTT。
  • 带有流水机制的持久性连接
    • 客户端只要遇到一个引用对象就尽快发出请求。
    • 理想情况下，收到所有引用对象只需耗时1个RTT。

HTTP/1.0 使用非持久连接。

HTTP/1.1 默认使用持久连接。

HTTP消息格式（语法，语义）

请求消息

请求消息的一般格式：

image-20200924084315677

  • 请求行(requset line)：命令(command) + URL + 协议以及协议版本。

  • 头部行(header line)：包含多种信息，例子中包含的信息有：主机地址，浏览器类型以及版本，连接状态，接受语言。

  • 回车换行(cr lf)，表示消息的指令部分已经完毕。

  • 消息体(Entity Body)：该请求消息的数据部分。

Eg：

image-20200924084410948

例子中的头部行第二行为主机地址行。其实，只有在在使用缓存和代理服务器，才会使用头部行中的Host主机地址行。因为在其他情况中，客户机已经与与目的服务器建立起相应的TCP连接，没有必要再使用主机地址行。

Get方法：请求指定的页面信息，并返回实体主体。

Post方法，将需要输入信息放在请求消息的消息体（Entity Body）中，进行数据的传送。（可以向服务器上传输入数据）

URL方法，仍然使用GET方法，输入信息通过请求行（request line）的URL字段（http://www.somesite.com/animalsearch?monkeys&banana）进行上传。（可以向服务器上传输入信息）

HEAD方法：请Server不要将所请求的对象放入响应消息中。（一般测试会采用）

PUT方法：将消息体中的文件上传到URL字段所指定的路径。

DELETE方法：删除URL字段所指定的文件

HTTP 1.0包含GET，POST，HEAD方法。

HTTP 1.1包含GET，POST，HEAD，PUT，DELETE方法。

响应消息

  • 状态行(status line)：协议以及版本，状态代号(status code)，状态表示(status phrase)

  • 头部行(header line)：包含多种信息。

  • 回车换行(cr lf)，表示消息的指令部分已经完毕。

  • 消息体(Entity Body)：该响应消息的数据部分。

Eg：

image-20200924090503891

Date：web服务器生成这个响应消息的时间

Last-Modified：上次网页的修改时间

状态代号(status code):

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

Cookie技术

问题

HTTP协议无状态，但是许多应用需要服务器掌握客户端与服务器之前对话的信息，这就产生了问题。

概念

某些网站为了辨别用户身份，进行session跟踪而存储再用户本地终端上的数据。

组件

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

工作原理

image-20200924100019975

应用角度

身份鉴别，构造购物车，个性化推荐，Web e-mail，用户会话状态信息维护 ....

web缓存/代理服务器技术

原因

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

概念

通过一个代理机器，在不访问服务器的前提下满足客户端的HTTP请求。

工作原理

  • 用户设定浏览器通过缓存进行Web访问。
  • 浏览器向缓存/代理服务器发送所有的HTTP请求。
    • 如果所请求对象在缓存中，缓存返回对象。
    • 否则，缓存服务器向原始服务器发送HTTP 请求，获取对象，然后返回给客户端并保存该对象。

例子

image-20200924101702852

其中，互联网上的延迟就是客户端发送一个很小的消息到服务器返回消息的时间，也就是RTT。

而访问延迟也就是数据传输所造成的延迟。

image-20200924102034976

image-20200924103041235

存在一个问题，代理服务器上缓存的数据是否是远端服务器上当前的数据。

image-20200924102743191

注意图中的If-modified-since，以及返回304。

Email应用

总体架构

采用邮件服务端，邮件客户端，SMTP协议架构的方便之处

  • 用户不需要7*24小时全部在线，也可以接收到所有发给该用户的邮件

  • 当用户发送邮件不成功时，不需要进行等待，而是直接将邮件发送的服务直接交付给邮件服务器完成。

邮件客户端(user agent)

  • 读，写Email消息
  • 与服务器进行交互，收发Email消息
  • eg：Outlook，Foxmail，Thunderbird，Web客户端

邮件服务器(Mail Server)

  • 为每一个用户申请一个邮箱，邮箱：存储发给该用户的Email
  • 为每一个用户保存一个消息队列，消息队列(Message queue)：存储等待发送的Email

SMTP协议：这一部分由大标题说明

SMTP协议

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

特点

  • 命令/响应的交互模式

  • 传输过程的三个阶段：握手，消息的传输，关闭

  • C/S架构：

    • 客户(Browser)：发送消息的服务器
    • 服务器(Web Server)：接受消息的服务器

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

交互流程以及消息格式（语法&&语义&&规则）

image-20200924151322515

其消息格式颇像人的交互

显然其交互流程具有以下特点：

  • 连接为持久性连接
  • SMTP服务器利用"CRLF . CRLF"确定消息的结束。CRLF为回车换行。
  • 要求消息必须由7为ASCII码构成

SMTP协议中常见的命令行格式

image-20200928083235980

SMTP协议与HTTP协议的交互流程的比较

  • HTTP：拉式，客户端将需要的文件拉；SMTP：推式，客户端将需要的文件推送
  • 命令和状态代码都是ASCII码
  • HTTP：每个对象封装在独立的响应消息中；SMTP，多个对象由多个部分构成的消息中发送。

Email消息的格式

image-20200924152915100

  • 头部行(Header)，To，From，Subject
  • 消息体(body)，只能是ASCII字符构成的消息本身

MIME：多媒体邮件扩展

通过在邮件头部增加额外的行以声明MIME的内容类型，以增加对于多媒体文件的传输支持

image-20200924153051194

邮件访问协议

邮件访问协议(access protocol)作用为：支持从服务器获取文件

image-20200924153517867

  • POP(Post Office Protocol):认证/授权(客户端与服务器匹配)，下载

  • IMAP(Internet Mail Access Protocol) :较POP协议，更多功能，更加复杂，能够操纵服务器上存储的消息。

  • HTTP：HTTP协议也可以作为邮件访问协议

POP协议

消息命令说明（语义）

认证过程：

客户端命令 服务器响应
User，声明用户名 +OK，成功
Pass，声明密码 -ERR，失败

事务阶段：

名称 作用
List 列出消息数量
Retr 用编号获取消息
Dele 删除消息
Quit 退出会话

交互过程（语法和规则）

image-20200924154349356

模式

  • “下载并删除”模式，客户端从服务端下载邮件后，客户端而后删除该邮件，用户如果换了客户端软件，无法重读该邮件
  • “下载并保持”模式：客户端从服务端下载邮件后，客户端而后会继续保存该邮件，不同客户端都可以保留消息的拷贝

POP协议是无状态的，而IMAP是一个有状态的协议

IMAP协议

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

DNS(Domain Name System)

解决问题

解决Internet上主机/路由器的识别问题，一般而言，主机和路由器的识别使用两套标识：IP地址和域名，而域名解析系统(DNS)所完成的工作就是域名与IP地址之间的相互映射。

DNS所完成的是Internet的核心功能，但是其是使用应用层进行实现的，而并非在底层。

组成

  • 多层命名服务器构成的分布式层次式数据库。
  • 应用层协议：完成名字的解析。

提供的服务

  • 域名向IP地址翻译
  • 主机，邮件服务器别名(别名即，将对人类不友好的名字转换为对人类友好的名字)
  • 负载均衡：Web服务器。当进行域名向IP地址翻译时，为一个域名提供多个IP地址的映射，将众多的服务分配到不同的主机上，进行负载均衡。

分布式层次式数据库

采用分布式的数据库，而不采用集中式的数据库的问题：单点失败问题，流量问题，距离问题，维护性问题。

但是对于分布式数据库也带来访问的花销较大的问题。

image-20200924175823463

当需要查找某个域名的IP地址时，本地域名解析服务器无法解析域名时，访问根域名服务器，在从根节点服务器开始，逐级向下访问服务器。

  • 根域名服务器：如果不知道映射，访问权威域名服务器，获得映射，向本地域名服务器返回映射，否则直接返回IP映射。

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

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

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

    • 可以由组织负责维护
    • 可以委托服务提供商负责维护

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

查询方式（规则）

  • 迭代查询：被查询服务器返回域名解析服务器的名字
  • 递归查询：将域名解析的任务交给所联系的服务器

例子

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

迭代查询

image-20200924181011676

递归查询：

image-20200924181350944

DNS记录缓存和更新

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

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

DNS记录格式（语法，语义）

资源记录(RR,reource records)：(name, value，type，ttl)

type name value
A 主机域名 IP地址
NS 域(edu.cn) 该域权威域名解析服务器的主机域名
CNAME 某一真实域名的别名 真实域名
MX Value是与name相对应的邮件服务器的别名

DNS协议

  • 查询（query）和回复（reply）
  • 消息格式相同

消息结构说明

image-20200924183401356

  • Identification：16位查询编号，回复使用相同的编号
  • flags（标识消息的类型）： 查询或回复，期望递归，递归可用，权威回答

文件分发应用:BitTorrent

组成

  • P2P架构
  • tracker：跟踪参与torrent的节点
  • torrent：交换同一个文件的文件块的节点组

交互过程

其交互形式如下图：

image-20200926152743900

  • 新节点加入torrent
    • 没有chunk，但是会逐渐积累
    • 向tracker注册以获得节点清单，与某些节点（ “邻居”）建立连接
  • 获取chunk(文件所拆分成的包)
    • 给定任一时刻，不同的节点持有文件的不同chunk的集合
    • 节点定期查询每个邻居所持有的chunk列表
    • 节点发送请求，请求获取缺失的chunk(稀缺优先)

对于稀缺的chunk（即拥有chunk的用户数量较少），用户会优先下载它们

  • 发送chunk: tit-for-tat（一报还一报）
    • 用户会先向其自身发送文件速率的几个用户发送文件，对于这些用户会在固定的时间后进行重新评定。

特点

  • 下载的同时，节点需要向其他节点上传 chunk
  • 节点可能加入或离开
  • 一旦节点获得完整的文件，它可能（自私 地）离开或（无私地）留下

文件分发应用：Distributed Hash Table(DHT)

特点：

  • DHT：a distributed P2Pdatabase.
  • assign (key, value) pairs to peers.
  • convert each key to an integer. （将每一个资源的键值映射为一个整数）
    • assign integer to each peer.（将每一个节点也映射为一个整数）
    • put (key, value ) pair in the peer that is closet to the key.（将键值对存放于离其键值最近的一个节点上）

对于上述分配资源的思想，可以给出一个粗略的例子

  • assign integer identifier to each peer in range [0,2n-1] for some n, each identifier represented by n bits.

  • require each key to be an integer in same range

  • to get integer key, hash original key.

  • assign key to the peer that has the clost ID. Closest is immediate successor of the key.

当然了上面许多地方的细节处理上都存在问题。

交互流程（粗略介绍）

这里贴几张PPT了事，本身而言，讲的很粗略，暂时没时间进行拓展

mmexportf055bdf629de6ea0844fefcab329503d

mmexportf4b5152ad1de4b6ca8d5d34257d8ae44

mmexport20289d8ddf32304c726a0fab31ea1b98

mmexport9d19654c79cd56954e152a126f99a799

文件分发应用之索引

索引

信息到节点位置 (IP地址+端口号) 的映射。

这些信息对于不同的应用有不同内容：

  • 对于文件共享应用，这些信息包括节点所有的文件
  • 对于即时消息，每个节点对应的的用户名

集中式索引

交互流程

  • 任何节点加入时，都需要再服务器中记录：信息以及IP。
  • 用户A需要查找用户B或者文件A，访问中央服务器查询。
  • 而后直接建立联系进行搜索。

问题

  • 单点时效问题，集中服务器可能出现问题
  • 性能瓶颈，集中服务器的性能会成为整个网络的速度的瓶颈
  • 版权问题，易于被破坏

洪范式查询 Query flooding

特点

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

覆盖网络(overlay network)：Graph

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

交互流程

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

问题

  • 消息可能泛滥，会给网络带来较大的负担

层次式覆盖网络

特点

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

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

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

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

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

例子：Skype

image-20200926163011147

posted @ 2020-09-24 18:47  zqybegin  阅读(202)  评论(0)    收藏  举报