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

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(协议://主机:端口号/路径)
  1. HTTP协议概述:万维网应用遵循HTTP协议;C/S结构;使用TCP传输服务(80端口);是无状态协议(服务器不维护过去所发请求的信息)

3.2 HTTP链接类型

  1. HTTP链接的两种类型
  • 非持久性链接:每一个TCP链接最多传输一个对象
  • 持久性链接:每一个TCP链接容许传输多个对象
  1. 响应事件分析与建模
  • 非持久性链接: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
  1. 响应消息消息格式:
  • 状态行+头部行+空行+data

3.4 Cookie技术

  1. Cookie技术:为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(RFC6265)
  2. Cookie的组件:
  • HTTP响应消息的cookie头部行
  • HTTP请求消息的cookie头部行
  • 保存在客户端主机上的cookie文件,有浏览器管理
  • Web服务器端的后台数据库
  1. Cookie的原理:客户端第一次访问服务器,服务器会为其建立ID,之后客户端请求消息里会有cookie id
  2. Cookie的做用:能用于身份认证,购物车,推荐,Web e-mail
  3. 隐私问题

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

  1. 功能:不访问服务器的前提下知足客户端HTTP请求。能够缩短客户请求的响应时间;减小机构/组织的流量;在大范围内实现有效的内容分发
  2. Web缓存/代理服务器技术:
  • 浏览器经过缓存进行Web访问。若是请求对象在缓存中,缓存返回对象;不然向原始服务器发送HTTP请求,获取对象,返回给客户端并保存该对象
  • 缓存即充当客户端也充当服务器
  • 通常由ISP(Internet服务提供商)架设
  1. Web缓存实例
  • 性能对比:原始服务器、提高互联网接入带宽、安装Web缓存
  1. 条件性GET方法
  • 目标:缓存有最新版本,则不须要发送请求对象
  • 缓存:在HTTP请求消息中声明所持有版本的日期
  • 服务器:若是版本是最新的,则响应消息中不包含对象

4.Email应用

4.1Email应用概述

  1. Email应用的构成:邮件客户端、邮件服务器、SMTP协议
  • 邮件客户端:如Foxmail、Web客户端
  • 邮件服务器:
    (1)邮箱:存储发给该用户的Email
    (2)消息队列:存储等待发送的Email
  • SMTP协议:邮件服务器之间传递消息使用的协议(邮件服务器既充当客户端又充当服务器)
  1. SMTP协议:RFC 2821
  • 使用TCP进行email消息的可靠传输
  • 端口25
  • 传输过程的三个阶段:握手、消息的传输、关闭
  • 命令/响应交互模式
  1. Email应用实例
  2. SMTP协议特色:
  • 使用持久性链接
  • 利用CRLF.CRLF肯定消息的结束
  1. 与HTTP对比
  • HTT是拉式;SMTP是退式
  • 都使用命令/响应交互模式
  • 命令和状态码都是ASCII码
  • HTTP:每一个对象封装在独立的响应消息中
  • SMTP:多个对象在由多个部分构成的消息中发送

4.2 Email消息格式与POP协议

  1. Email消息格式
  • SMTP协议:头部行header(To、From、Subject)+消息体body
    这里的头部行与SMTP命令不一样
  • 多媒体邮件扩展: MIME
    邮件头部增长额外的行声明MIME的内容类型
  1. 邮件访问协议:从服务器获取邮件
  • POP协议
  • IMAP协议
  • HTTP协议(Web浏览器收发邮件)
  1. POP协议
  • 认证过程:客户端命令(User声明用户名、Pass声明密码)、服务器响应(+OK、-ERR)
  • 事务阶段:List、Retr、Dele、Quit
  • “下载并删除”模式:换了客户端软件没法重读邮件
  • “下载并保持”模式:不一样客户端均可以保留消息的拷贝
  • POP3是无状态的
  1. IMAP协议
  • 全部消息统一保存在一个地方:服务器
  • 容许用户利用文件夹组织消息
  • IMAP支持跨会话(session)的用户状态:文件夹名字、文件夹与消息ID之间的映射等

5.DNS应用

5.1DNS概述

  1. Internet上主机/路由器的识别问题:IP地址、域名
  2. 域名解析系统DNS
  • 多层命名服务器构成的分布式数据库
  • 应用层协议:完成名字的解析
  • Internet核心功能,用应用层协议实现
  • 网络边界复杂

不适用集中式的DNS缘由:单点失败问题、流量问题、距离问题、维护性问题web

  1. DNS服务:域名向IP地址的翻译、主机别名、邮件服务器别名、负载均衡(web服务器)
  2. 分布式层式数据库:Root DNS servers—com DNS serves—Amazon.com DNS servers
  • 根域名服务器
  • 顶级域名服务器TLD:负责顶级域名com、org、net、edu等和国家顶级域名cn、uk、fr等
  • 权威域名解析服务器:提供组织内部服务器的解析服务(组织负责维护或者服务提供商负责维护)
  • 本地域名解析服务器:不属于层级体系;每一个ISP有一个本地域名服务器;当主机进行DNS查询时,查询被发送到本地域名服务器(做为代理将查询转发给层级式)
  1. DNS查询示例
  • 迭代查询(平等询问):主机先访问本地域名服务器——>本地域名服务器访问根域名服务器——>我不认识这个域名,可是你能够问这个服务器——>根域名服务器继续访问com域名服务器——>...
  • 递归查询(被指示):主机先访问本地域名服务器——>本地域名服务器访问根域名服务器——>我帮你去问这个服务器——>根域名服务器访问com域名服务器——>...
  1. DNS记录缓存和更新
  • 只要域名解析服务器得到域名IP映射,即缓存这一映射(一段时间后缓存条目删除;本地域名服务器通常会缓存顶级域名服务器的映射)

5.2 DNS记录和消息

  1. DNS记录: 资源记录RR
  • Type=A
  • Type=NS
  • Type=CNAME
  • Type=MS
  1. DNS协议与消息
  • 查询和回复(消息格式相同)
  • 消息头部:Identification、flag
  1. 如何注册域名
  2. 找出那些在应用层实现的Internet核心服务,调研他们的协议、消息格式

6.P2P应用

6.1 原理与文件分发

  1. 纯P2P架构
  • Peer-To-Peer
  • 特色:没有服务器;任意端系统之间直接通讯;节点阶段性接入Internet、节点可能更换IP地址
  1. 文件分发(客户机/服务器 VS P2P):随着节点数目增长CS架构文件分发所需时间呈线性增加,P2P逐渐趋于水平
  2. 应用:BitTorrent(比特流)协议

6.2 索引技术

  1. 搜索信息
  • P2P系统的索引:信息到节点位置(IP地址+端口号)的映射
  • 文件共享(电驴):利用索引动态跟踪节点所共享的文件的位置;节点告诉索引它拥有哪些文件;节点搜索索引,从而获知可以获得哪些文件
  • 即时消息(QQ):索引负责将用户名映射到位置;当用户开启IM应用时,须要通知索引它的位置;节点检索索引,肯定用户的IP地址
  1. 集中式索引
  • Napster最先采用这种设计:节点加入时,通知中央服务器IP地址和内容;其余节点查找时,从其余主机处获取文件
  • 问题:单点时效问题、性能瓶颈、版权问题
  1. 洪泛式查询:Query flooding
  • 彻底分布式架构
  • Gnutella采用这种架构:查询消息经过已有的TCP链接发送;节点转发查询消息;若是查询命中,则利用反向路径发回查询节点
  1. 层次式覆盖网络
  • 介于集中式索引和洪泛查询之间的方法:节点和超级节点间维持TCP链接;某些超级节点间维持TCP链接
  • Skype采用这种架构:本质上是P2P的(用户/节点对之间直接通讯);私有应用层协议;索引负责维护用户名和IP地址之间的映射(相似QQ);索引分布在超级节点上

还涉及到了Socket编程部分,做相关了解请查阅资料数据库

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