四种网络应用模式，网络应用层

四种网络应用模式，网络应用层Napster是一款可以在网络中下载自己想要的MP3文件的软件。它同时能够让自己的机器也成为一台服务器，为其它用户提供下载。1.3、混合结构1.2、P2P优点：高度可伸缩缺点：难于管理

1、网络应用体系结构

1.1、客户机/服务器

1.1.1、服务器

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

1.1.2、客户机

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

1.2、P2P

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

优点：高度可伸缩

缺点：难于管理

1.3、混合结构

Napster是一款可以在网络中下载自己想要的MP3文件的软件。它同时能够让自己的机器也成为一台服务器，为其它用户提供下载。

文件传输使用P2P结构

文件的搜索采用C/S结构——集中式

每个节点向中央服务器登记自己的内容

每个节点向中央服务器提交查询请求， 查找感兴趣的内容

1.4、网络应用的基础：进程间通信（进程的标识符：IP地址 端口号）

• 进程间通信机制
• 操作系统提供

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

服务器进程: 等待通信请求的进程

1.4.1、套接字: Socket

• 进程间通信利用socket发送/接收消息实现
• 传输基础设施向进程提供API

• 传输协议的选择
• 参数的设置

1.4.2、应用层协议

公开协议

HTTP、SMTP。。。。。。

私有协议

多数P2P文件共享应用

协议内容

消息的类型

请求消息

响应消息

消息的语法/格式

消息中有哪些字段

每个字段如何描述

字段的语义

字段中信息的含义

规则

进程何时发送/响应消息

进程如何发送/响应消息

2、网络应用的服务需求

2.1、数据丢失/可靠性

某些网络应用能够容忍一定的数据丢失：网络电话

某些网络应用要求100%可靠的数据传输：文件传输，telnet

2.2、时间/延迟

有些应用只有在延迟足够低时才“有效”

网络电话/网络游戏

2.3、带宽

某些应用只有在带宽达到最低要求时才“有效”：网络视频

某些应用能够适应任何带宽——弹性应用：Email

3、Internet传输层服务模型

3.1、TCP服务

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

可靠的传输

流量控制: 发送方不会发送速度过快，超过接收方的处理能力

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

不提供时间/延迟保障

不提供最小带宽保障

3.2、UDP服务

无连接

不可靠的数据传输

不提供：

• 可靠性保障
• 流量控制
• 拥塞控制
• 延迟保障
• 带宽保障

4、协议

4.1、HTTP协议

超文本传输协议：HyperText Transfer Protocol

客户—Browser：请求、接收、展示Web 对象

服务器—Web Server：响应客户的请求 ，发送对象

使用TCP传输服务

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

无状态

有 因为有状态的协议更复杂:

需维护状态(历史信息)

如果客户或服务器失效，会产生状态的不 一致，解决这种不一 致代价高

服务器不维护任何有关客户端过去所发请求的信息

Http连接

非持久性连接(Nonpersistent HTTP)

每个TCP连接最多允许传输一个对象

HTTP 1.0版本使用非持久性连接

持久性连接(Persistent HTTP)

每个TCP连接允许传输多个对象

HTTP 1.1版本默认使用持久性连接

响应时间

发起、建立TCP连接：1个RTT

发送HTTP请求消息到HTTP响应消息的前 几个字节到达：1个RTT

响应消息中所含的文件/对象传输时间

非持久连接的缺点

• 每个连接，TCP得在客户端和服务端分配TCP缓冲区，并维持TCP变量。 对于同时为来自数百个不同客户的请求提供服务的web服务器来说，这会严重增加其负担。
• 每个对象都有2个RTT的延迟。
• 每个对象都遭受TCP缓启动，因为每个TCP连接都起始于缓启动阶段。

持久性连接

发送响应后，服务器保持TCP连接的打开

后续的HTTP消息可以通过这个连接发送

无流水的持久性连接

客户端只有收到前一个响应后才发送新的请求

每个被引用的对象耗时1个RTT

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

HTTP 1.1的默认选项

客户端只要遇到一个引用对象就尽快发出请求

理想情况下，收到所有的引用对象只需耗时约1个RTT

HTTP消息格式

HTTP协议有两类消息

请求消息

响应消息

请求消息：包括三个部分，请求方法URL协议、请求头、请求体

第一行是请求方法URL协议，里面包括请求方法是 GET、POST还是PUT等 URL HTTP版本

第二部分是请求头，包括主机host，请求的浏览器user-agent，连接，接受的语言换行

第三部分请求体，比如post一般都会把参数放入到请求体中，PUT将消息体中的文件上传到url中指定的路径。

响应消息：状态行、消息报头，响应正文

状态行：HTTP版本 200/404等（代表返回的结果）。

消息报头：data（web服务器产生响应消息的时间）、server服务器的类型、内容长度

空行

响应正文：html代码等

Cookie技术

因为HTTP协议无状态，很多应用需要服务器掌握客户端的状态，某些网站为了辨别用户身份、进行session跟踪而存储在用户本地终端上的数据（通常经过加密）

Cookie的实现原理

Cookie定义了一些HTTP请求头和HTTP响应头，通过这些HTTP头信息使服务器可以与客户进行状态交互。

客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。

Web缓存/代理服务器技术

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

优点：

缩短客户请求的响应时间

减少机构/组织的流量

在大范围内实现有效的内容分发

Web缓存/代理服务器

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

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

如果所请求对象在缓存中，缓存返回对象

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

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

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

4.2、Email应用

Email应用的构成组件

邮件客户端

邮件服务器

SMTP协议(Simple Mail Transfer Protocol)

邮件客户端

读、写Email消息

与服务器交互，收、发Email消息

客户端工具Outlook Foxmail Thunderbird

Web客户端

邮件服务器

邮箱：存储发给该用户的Email

消息队列(message queue)：存储等待发 送的Email

SMTP协议

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

使用TCP进行email消息的可靠传输（使用持久性连接）

端口25

传输过程的三个阶段

握手

消息的传输

关闭

命令/响应交互模式

命令(command): ASCII文本

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

Email消息只能包含7位ASCII码

SMTP与HTTP对比:

HTTP: 拉式(pull)

SMTP: 推式(push)

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

命令和状态代码都是ASCII码

HTTP: 每个对象封装在独立的响应消息中

SMTP: 多个对象在由多个部分构成的消息中发送

Email消息格式与POP3协议

文本消息格式标准

头部行(header)

To

From

Subject

消息体(body)

消息本身

只能是ASCII字符

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

POP: Post Office Protocol

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

认证过程

客户端命令

User：声明用户名

Pass: 声明密码

服务器响应

OK

-ERR

事务阶段

List：列出消息数量

Retr：用编号获取消息

Dele: 删除消息

Quit

“下载并删除”模式

用户如果换了客户端软件，无法重读该邮件

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

POP3是无状态的

IMAP: Internet Mail Access Protocol

更多功能

更加复杂

能够操纵服务器上存储的消息

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

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

IMAP支持跨会话(Session)的用户状态:

文件夹的名字

文件夹与消息ID之间的映射等

4.3、DNS服务

域名向IP地址的翻译

主机别名

邮件服务器别名

负载均衡：Web服务器

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

单点失败问题

流量问题

距离问题

维护性问题

DNS查询

迭代查询

递归查询

DNS消息主要由五部分组成

4.4、P2P应用：原理与文件分发

没有服务器

任意端系统之间直接通信

节点阶段性接入Internet

节点可能更换IP地址

文件划分为256KB的chunk

节点加入torrent

没有chunk，但是会逐渐积累

向tracker注册以获得节点清单，与某些节点（ “邻居”）建立连接

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

节点可能加入或离开

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

获取chunk

给定任一时刻，不同的节点持有文件的不同chunk集合

节点(Alice)定期查询每个邻居所持有的chunk列表

节点发送请求，请求获取缺失的chunk

稀缺优先

发送chunk: tit-for-tat

Alice向4个邻居发送chunk：正在向其发送Chunk，速率最快的4个

每10秒重新评估top 4

每30秒随机选择一个其他节点，向其发送chunk

新选择节点可能加入top 4

“optimistically unchoke”

P2P应用：索引技术

P2P系统的索引：信息到节点位置(IP地址 端口号)的映射

文件共享(电驴)

利用索引动态跟踪节点所共享的文件的位置

节点需要告诉索引它拥有哪些文件

节点搜索索引，从而获知能够得到哪些文件

即时消息(QQ)

索引负责将用户名映射到位置

当用户开启IM应用时，需要通知索引它的位置

节点检索索引，确定用户的IP地址