第六章 计算机网络-应用层

1.网络应用概述

1. 网络应用体系结构
   ① 客户机/服务器 ② P2P ③ 混合结构
2. 网络应用的服务需求
   ① 可靠性 ② 带宽 ③ 时延
3. Internet传输层服务模型
   ① TCP ② UDP
4. 特定网络应用及协议
   ① HTTP ② SMTP POP IMAP ③ DNS ④ P2P应用
5. Socket编程
   ① TCP ② UDP

2.网络应用基本原理

2.1. 网络应用的体系结构

1. 网络应用：百度、QQ、Email、迅雷、支付宝、微信、百度云、淘宝网、网易
2. 网络应用的体系结构：客户机/服务器结构（Client/Sever）、点对点结构（PeerToPeer）、混合结构

• 服务器：持续提供服务、永久性访问地址/域名、利用大量服务器实现可扩展性
• 客户机：使用服务器的服务、可能使用动态IP地址、不会与其他客户机直接通信
• C/S举例——Web
  计算机客户端运行IE或者Sarari等浏览器，服务器运行Web服务器软件
• P2P举例——BT文件共享
  没有永远在线的服务器，任意端系统/节点直接可以直接通讯，节点可能改变IP地址
• 混合结构举例——Napster
  文件传输使用P2P结构，文件的搜索采用C/S结构（集中式）

2.2. 网络应用进程通信（网络应用的基础）

• 进程：主机上运行的程序
• 同一主机上运行的进程之间通信：进程间通信机制、操作系统提供
• 不同主机上运行的进程之间通信：消息交换/报文交换
  客户机进程：发起通信的进程
  服务器进程：等待通信请求的进程
• 套接字：Socket
  进程间通信利用socket发送/接收消息实现
  类似于寄信
  传输基础设施向进程提供API（传输协议的选择、参数的设置）
• 如何寻址进程
  进程有标识符：IP地址+端口号
  寻址主机——IP地址
  某一主机具体进程——端口号：每个需要通信的进程分配一个端口号
• 应用层协议
  公开协议：由RFC定义、允许互操作、HTTP、SMTP、...
  私有协议：多数P2P文件共享应用
• 应用层协议的内容
  消息类型：请求消息、响应消息
  消息的语法格式：字段、字段如何描述
  字段的语义：字段中信息的含义
  规则

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

1. 网络应用的需求：数据丢失/可靠性（网络电话容忍一定的数据丢失，文件传输要求100%可靠）、时间延迟、带宽
2. Internet提供的传输服务：TCP服务（面向连接、可靠传输、流量控制、拥塞控制、不提供时间/延迟保障、不提供最小带宽保障）、UCP服务（无连接、不可靠数据传输、不提供可靠性保障+流量控制+拥塞控制+延迟保障+带宽保障）

3.Web应用

3.1Web应用概述

1. WorldWideWeb：网页、网页互相链接
2. 网页包含多个对象：

• 对象：HTML文件、JEPG图片、视频文件、动态脚本等
• 基本HTML文件：包含对其他对象引用的链接
• 对象的寻址：URL（协议://主机:端口号/路径）

3. HTTP协议概述：万维网应用遵循HTTP协议；C/S结构；使用TCP传输服务（80端口）；是无状态协议（服务器不维护过去所发请求的信息）

3.2 HTTP连接类型

1. HTTP连接的两种类型

• 非持久性连接：每个TCP连接最多传输一个对象
• 持久性连接：每个TCP连接允许传输多个对象

2. 响应事件分析与建模

• 非持久性连接：2RTT+文件发送时间（一个对象）
• 持久性连接：无流水的持久性连接（一个对象1RTT）、带有流水机制的持久性连接（所有引用对象1RTT）

3.3 HTTP消息格式

1. 两类消息：请求消息、响应消息
2. 请求消息消息格式：

• 请求行+头部行（可扩展）+换行+entity body
• 请求消息通用格式：method、url、version、header field name、value、entity body..
• 上传输入的方法：
  （1） POST方法：网页填写表格（在请求消息的消息体entity body中上传客户端的输入）
  （2） URL方法：使用GET方法（输入信息通过request行的URL字段上传）
• 方法的类型：
  HTTP/1.0：GET、POST、HEAD
  HTTP/1.1：GET、POST、HEAD、GET、DELETE

3. 响应消息消息格式：

• 状态行+头部行+空行+data

3.4 Cookie技术

1. Cookie技术：为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（RFC6265）
2. Cookie的组件：

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

3. Cookie的原理：客户端第一次访问服务器，服务器会为其创建ID，以后客户端请求消息里会有cookie id
4. Cookie的作用：能用于身份认证,购物车,推荐,Web e-mail
5. 隐私问题

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

1. 功能：不访问服务器的前提下满足客户端HTTP请求。可以缩短客户请求的响应时间；减少机构/组织的流量；在大范围内实现有效的内容分发
2. Web缓存/代理服务器技术：

• 浏览器通过缓存进行Web访问。如果请求对象在缓存中，缓存返回对象；否则向原始服务器发送HTTP请求，获取对象，返回给客户端并保存该对象
• 缓存即充当客户端也充当服务器
• 一般由ISP（Internet服务提供商）架设

3. Web缓存实例

• 性能对比：原始服务器、提升互联网接入带宽、安装Web缓存

4. 条件性GET方法

• 目标：缓存有最新版本，则不需要发送请求对象
• 缓存：在HTTP请求消息中声明所持有版本的日期
• 服务器：如果版本是最新的，则响应消息中不包含对象

4.Email应用

4.1Email应用概述

1. Email应用的构成：邮件客户端、邮件服务器、SMTP协议

• 邮件客户端：如Foxmail、Web客户端
• 邮件服务器：
  （1）邮箱：存储发给该用户的Email
  （2）消息队列：存储等待发送的Email
• SMTP协议：邮件服务器之间传递消息使用的协议（邮件服务器既充当客户端又充当服务器)

2. SMTP协议：RFC 2821

• 使用TCP进行email消息的可靠传输
• 端口25
• 传输过程的三个阶段：握手、消息的传输、关闭
• 命令/响应交互模式

3. Email应用实例
4. SMTP协议特点：

• 使用持久性连接
• 利用CRLF.CRLF确定消息的结束

5. 与HTTP对比

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

4.2 Email消息格式与POP协议

1. Email消息格式

• SMTP协议：头部行header（To、From、Subject）+消息体body
  这里的头部行与SMTP命令不同
• 多媒体邮件扩展： MIME
  邮件头部增加额外的行声明MIME的内容类型

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

• POP协议
• IMAP协议
• HTTP协议（Web浏览器收发邮件）

3. POP协议

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

4. IMAP协议

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

5.DNS应用

5.1DNS概述

1. Internet上主机/路由器的识别问题：IP地址、域名
2. 域名解析系统DNS

• 多层命名服务器构成的分布式数据库
• 应用层协议：完成名字的解析
• Internet核心功能，用应用层协议实现
• 网络边界复杂

不适用集中式的DNS原因：单点失败问题、流量问题、距离问题、维护性问题

3. DNS服务：域名向IP地址的翻译、主机别名、邮件服务器别名、负载均衡（web服务器）
4. 分布式层式数据库：Root DNS servers—com DNS serves—Amazon.com DNS servers

• 根域名服务器
• 顶级域名服务器TLD：负责顶级域名com、org、net、edu等和国家顶级域名cn、uk、fr等
• 权威域名解析服务器：提供组织内部服务器的解析服务（组织负责维护或者服务提供商负责维护）
• 本地域名解析服务器：不属于层级体系；每个ISP有一个本地域名服务器；当主机进行DNS查询时，查询被发送到本地域名服务器（作为代理将查询转发给层级式）

5. DNS查询示例

• 迭代查询（平等询问）：主机先访问本地域名服务器——>本地域名服务器访问根域名服务器——>我不认识这个域名，但是你可以问这个服务器——>根域名服务器继续访问com域名服务器——>...
• 递归查询（被指示）：主机先访问本地域名服务器——>本地域名服务器访问根域名服务器——>我帮你去问这个服务器——>根域名服务器访问com域名服务器——>...

6. DNS记录缓存和更新

• 只要域名解析服务器获得域名IP映射，即缓存这一映射（一段时间后缓存条目删除；本地域名服务器一般会缓存顶级域名服务器的映射）

5.2 DNS记录和消息

1. DNS记录： 资源记录RR

• Type=A
• Type=NS
• Type=CNAME
• Type=MS

2. DNS协议与消息

• 查询和回复（消息格式相同）
• 消息头部：Identification、flag

3. 如何注册域名
4. 找出那些在应用层实现的Internet核心服务，调研他们的协议、消息格式

6.P2P应用

6.1 原理与文件分发

1. 纯P2P架构

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

2. 文件分发（客户机/服务器 VS P2P）：随着节点数目增加CS架构文件分发所需时间呈线性增长，P2P逐渐趋于水平
3. 应用：BitTorrent（比特流）协议

6.2 索引技术

1. 搜索信息

• P2P系统的索引：信息到节点位置（IP地址+端口号）的映射
• 文件共享（电驴）：利用索引动态跟踪节点所共享的文件的位置；节点告诉索引它拥有哪些文件；节点搜索索引，从而获知能够得到哪些文件
• 即时消息（QQ）：索引负责将用户名映射到位置；当用户开启IM应用时，需要通知索引它的位置；节点检索索引，确定用户的IP地址

2. 集中式索引

• Napster最早采用这种设计：节点加入时，通知中央服务器IP地址和内容；其他节点查找时，从其他主机处获取文件
• 问题：单点时效问题、性能瓶颈、版权问题

3. 洪泛式查询：Query flooding

• 完全分布式架构
• Gnutella采用这种架构：查询消息通过已有的TCP连接发送；节点转发查询消息；如果查询命中，则利用反向路径发回查询节点

4. 层次式覆盖网络

• 介于集中式索引和洪泛查询之间的方法：节点和超级节点间维持TCP连接；某些超级节点间维持TCP连接
• Skype采用这种架构：本质上是P2P的（用户/节点对之间直接通信）；私有应用层协议；索引负责维护用户名和IP地址之间的映射（类似QQ）；索引分布在超级节点上

还涉及到了Socket编程部分，作相关了解请查阅资料

附：本文内容出于哈尔滨工业大学聂兰顺老师的计算机网络课程