计算机网络之网络应用
网络应用体系结构
客户即/服务器结构(Client-Server,C/S)
点对点结构(Peer-to-Peer, P2P)
混合结构(Hybrid)
客户机/服务器结构
服务器
- 7*24小时提供服务
- 永久性访问地址/域名
- 利用大量服务器实现可拓展性
客户机
- 与服务器通信,使用服务器提供的服务
- 间歇性接入网络
- 可能使用动态IP地址
- 不会与其他客户机直接通信
纯P2P结构
- 没有永远在线的服务器
- 任意端系统/节点之间可以直接通讯
- 节点间歇息接入网络
- 节点可能改变IP地址
优点:高度可伸缩
缺点:难于管理
混合结构
混合结构的例子:
- 文件传输采用P2P结构
- 文件的搜索采用C/S结构 - 集中式
- 每个节点向中央服务器登记自己的内容
- 每个节点向中央服务器提交查询请求,查找感兴趣的内容
网络应用进程通信
进程:
- 主机上运行的程序
同一主机运行的进行之间如何通信:
- 进程间通信机制
- 操作系统提供
不同主机运行的进程间如何通信
- 消息交换(报文交换)
客户机进程:发起通信的进程
服务器进行:等待通信请求的进行
套接字Socket
进程间通信利用socket发送/接收消息实现
类似于寄信
- 发送方将消息送到门外邮箱
- 发送方依赖门外的传输设备将消息传到接收方所在主机,并送到接收方的门外
- 接收方从门外获取消息
传输基础设施向进程提供API
- 传输协议的选择
- 参数的设置
如何寻址进程?
不同主机的进程间通信,那么每个进程必须拥有标识符
如何寻址主机? IP地址
Q: 主机有了IP地址后,是否足以定位进程?
A: 否,同一主机可能同时有多个进程需要通信。
端口号/Port number
- 为主机上每个需要通信的进程分配一个端口号
- HTTP Server: 80
- Mail Server: 25
进程的标识符
- IP地址+端口号
应用层协议
网络应用需遵循应用层协议
公开协议
- 由RFC(Request For Comments)定义
- 允许互操作
- HTTP, SMTP, ……
私有协议
- 多数p2p文件共享应用
应用层协议的内容
消息的类型(type)
- 请求消息
- 响应消息
消息的语法(Syntax)格式
- 消息中有哪些字段(field)?
- 每个字段如何描述
字段的语义(semantics)
- 字段中消息的含义
规则(rules)
- 进程何时发送/响应消息
- 进程如何发送/响应消息
网络应用对传输服务的需求
数据丢失(data loss)/可靠性(reliability)
- 某些网络应用能够容忍一定的数据丢失:网络电话
- 某些网络应用要求100%可靠的数据传输:文件传输,telnet
时间(timing)/延迟(delay)
- 有些应用只有在延迟足够低时才能”有效”
- 网络电话/网络游戏
带宽
- 某些应用只有在带宽达到最低要求时才”有效”:网络视频
- 某些应用能够适应任何带宽 弹性应用:email
Internet提供的传输服务
TCP服务
- 面向连接:客户机/服务器进程间需要建立连接
- 可靠的传输
- 流量控制:发送方不会发送速度过快,超过接收方的处理能力
- 拥塞控制:当网络负载过重时能够限制发送方的发送速度
- 不提供时间/延迟保障
- 不提供最小带宽保障
UDP服务
无连接
不可靠的数据传输
不提供:
- 可靠性保障
- 流量控制
- 拥塞控制
- 延迟保障
- 带宽保障
Web应用
World Wide Web: Tim Berners-Lee
- 网页
- 网页互相链接
网页包含多个对象
- 对象:html文件,jpeg文件,视频文件,动态脚本
- 基本html文件:包含对其他对象引用的链接
对象的寻址(addressing)
URL(Uniform Resourse Locator): 统一资源定位器
Scheme://host:port/path
HTTP协议概述
万维网应用遵循什么协议?
超文本传输协议
- HyperText Transfer Protocol
C/S结构
- 客户-Brower: 请求,接收,展示web对象
- 服务器-Web Server: 响应客户的请求,发送对象
HTTP版本:
- 1.0 RFC 1945
- 1.1 RFC 2068
使用TCP传输服务
- 服务器在80端口等待客户的请求
- 浏览器发起到服务器的TCP连接请求(创建套接字Socket)
- 服务器接受来自浏览器的TCP连接
- 浏览器(HTTP客户端)与Web服务器(HTTP服务器)交换HTTP消息
- 关闭TCP连接
无状态(stateless)
- 服务器不维护任何有关客户端过去所请求的信息
HTTP连接的两种类型
非持久化连接(Nonpersistent HTTP)
- 每个TCP连接最多允许传输一个对象
- HTTP1.0版本使用非持久化连接
持久化连接(Persistent HTTP)
- 每个TCP连接允许传输多个对象
- HTTP1.1版本默认使用持久化连接
非持久性连接的问题
- 每个对象需要两个RTT
- 操作系统需要为每个TCP连接开销资源
- 浏览器会怎么做
- 打开多个并行的TCP连接以获取网页所需对象
- 给服务器端造成什么影响
持久性连接
- 发送响应后,服务器保持TCP连接的打开
- 后续的HTTP消息可以通过这个连接发送
无流水的持久性连接
- 客户端只有收到前一个响应后才发送新的请求
- 每个被引用的对象耗时1个RTT
带有流水机制的持久性连接
- HTTP1.1的默认选项
- 客户端只要遇到一个引用对象就尽快发出请求
- 理想情况下,收到所有的引用对象只需要耗时一个RTT
HTTP协议消息格式
HTTP协议有两类消息
- 请求消息(request)
- 响应消息(response)
请求消息
- ASCII:人直接可读
HTTP请求消息的通用格式
上传输入的方式
- POST方法
- 网页经常需要填写表格(form)
- 在请求消息的消息体(entity body)中上传客户端的输入
- URL方法
- 使用GET方法
- 输入信息通过request行的URL字段上传
方法的类型
HTTP/1.0
- GET
- POST
- HEAD
- 请Server不要将所请求的对象放入响应消息中
HTTP/1.1
- GET,POST,HEAD
- PUT
- 将消息体中的文件上传到URL字段所指定的路径
- DELETE
- 删除URL字段所指定的文件
HTTP响应消息
HTTP响应状态代码
- 响应消息的第一行
- 示例
- 200 OK
- 301 Moved Permanently
- 400 Bad Request
- 404 Not Found
- 505 HTTP Version Not Supported
Cookie技术
某些网站为了辨别用户身份,进行session跟踪而存储在用户本地终端上的数据(通常是经过加密的)
Cookie的组件
- HTTP响应消息的cookie头部行
- HTTP请求消息的cookie头部行
- 保存在客户端主机上的cookie文件,由浏览器管理
- Web服务器的后台数据库
Cookie的作用
- 身份认证
- 购物车
- 推荐
- Web e-mail
- ……
隐私问题
Web缓存/代理服务器技术
功能
- 在不访问服务器的前提下满足客户端的HTTP请求
为什么发明这种技术?
- 缩短客户请求的响应时间
- 减少机构/组织的流量
- 在大范围内(Internet)实现有效的内容分发
Web缓存/代理服务器
- 用户设定浏览器通过缓存进行Web访问
- 浏览器向缓存/代理服务器发送所有的HTTP请求
- 如果所请求对象在缓存中,缓存返回对象
- 否则,缓存服务器向原始服务器发送HTTP请求,获取对象,然后返回给客户端并保存对象
- 缓存即充当客户端,也充当服务器
- 一般由ISP(Internet服务提供商)架设
Email应用
Email应用的构成组件
- 邮件客户端(user agent)
- 邮件服务器
- SMTP协议(Simple Mail Transfer Protocol)
邮件客户端
- 读,写Email信息
- 与服务器交互,收,发Email信息
- Outlook,Foxmail,Thunderbird
- Web客户端
邮件服务器(Mail Server)
- 邮箱:存储发给该用户的Email
- 消息队列(message queue):存储等待发送的Email
SMTP协议
- 邮箱服务器之间传递消息所使用的协议
- 客户端:发送消息的服务器
- 服务器:接收消息的服务器
SMTP协议
- 使用TCP进行email消息的可靠传输
- 端口25
- 传输过程的三个阶段
- 握手
- 消息的传输
- 关闭
- 命令/响应交互模式
- 命令(command):ASCII文本
- 响应(response):状态代码和语句
- Email消息只能包含7位ASCII码
- 使用持久性连接
- 要求消息必须由7位ASCII码构成
- SMTP服务器利用CRLF.CRLF确定消息的结束
Email消息格式
文本消息格式标准
- 同步行
- To
- From
- Subject
- 消息体(body)
- 消息本身
- 只能是ASCII字符
MIME:多媒体邮件扩展
- 通过在邮件头部增加额外的行以声明MIME的内容类型
邮件访问协议
邮件访问协议:从服务器获取邮件
- POP:Post Office Protocol
- 认证/授权(客户端<->服务器)和下载
- IMAP:Internet Mail Access Protocol
- 更多功能
- 更加复杂
- 能够操作服务器上存储的消息
- HTTP:163,QQ Mail等
POP协议
认证过程
- 客户端命令
- User:声明用户名
- Pass:声明密码
- 服务器响应
- +OK
- -ERR
事务阶段
- List:列出消息数量
- Retr:用编号获取消息
- Dele:删除消息
- Quit
“下载并删除”模式
- 用户如果换了客户端软件,无法重读该邮件
“下载并保持”模式
- 不同客户端可以保存消息的拷贝
POP协议是无状态的
IMAP协议
所以消息统一保存在一个地方:服务器
允许用户利用文件夹组织消息
IMAP支持跨会话(Session)的用户状态:
- 文件夹的名字
- 文件夹与消息ID之间的映射等
DNS应用
DNS: Domain Name System
Internet上主机/路由器的识别问题
- IP地址
- 域名:www.hit.edu.cn
域名解析系统DNS
- 多层命名服务器构成的分布式数据库
- 应用层协议:完成名字的解析
- Internet核心功能,用应用层协议实现
- 网络边界复杂
DNS服务
- 域名向IP地址的翻译
- 主机别名
- 邮件服务器别名
- 负载均衡:web服务器
DNS根域名服务器
本地域名解析服务无法解析域名时,方位根域名服务器
根域名服务器
- 如果不知道映射,访问权威域名服务器
- 获得映射
- 向本地域名服务器返回映射
TLD和权威域名解析服务器
顶级域名服务器(TLD,top-level domain):负责com,org,net,edu等顶级域名和国家顶级域名,例如cn,uk,fr等
权威(Authoritative)域名服务器:组织的域名解析服务器,提供组织内部服务器的解析服务
- 组织负责维护
- 服务器提供商负责维护
本地域名解析服务器
不严格属性层级体系
每个ISP有一个本地域名服务器
- 默认域名解析服务器
当主机进行DNS查询时,查询被发送到本地域名服务器
- 作为代理(proxy),将查询转发给(层级式)域名解析服务器系统
DNS记录
资源记录(RR,resource records)
Type=A
- name:主机域名
- value:IP地址
Type=NS
- name:域(edu.cn)
- value:该域权威域名解析服务器的主机域名
Type=CNAME
- name:某一真实域名的别名
- value:真实域名
Type=MX
- value是与name相对应的邮件服务器
DNS协议与消息格式
DNS协议:
- 查询(query)和回复(reply消息)
- 消息格式相同
消息头部
- Identification: 16位查询编号,回复使用相同的编号
- flags
- 查询或回复
- 期望递归
- 递归可以
- 权威回答
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!