计算机网络第二章-应用层(上)

🎈应用层

目标

网络应用的原理:网络应用协议的概念和实现方面

• 传输层的服务模型
• 客户-服务器模式
• 对等模式(peer-to-peer)
• 内容分发网络

网络应用的实例:互联网流行的应用层协议

• HTTP
• FTP
• SMTP/POP3/IMAP
• DNS

编程:网络应用程序

• Socket API

一些网络应用的例子

E-mail,Web,文本消息,远程登录,P2P文件共享,即时通信,多用户网络游戏,流媒体(YouTube,Hulu,Netflix),Internet电话,实时电视会议,社交网络,搜素等等

创建一个新的网络应用

编程

• 在不同的端系统上运行
• 通过网络基础设施提供的服务,应用进程彼此通信
• 如Web:
  1.Web服务器软件与浏览器软件通信

网络核心中没有应用层软件

• 网络核心没有应用层功能
• 网络应用只在端系统上存在,快速网络应用开发和部署

🎈应用层协议原理

网络应用的体系结构

可能的应用架构:

• 客户-服务器模式(C/S:client/server)
• 对等模式(P2P:peer to peer)
• 混合体:客户-服务器和对等体系结构

客户-服务器模式(C/S:client/server)

服务器:

• 一直运行
• 固定的IP地址和周知的端口号(约定)
• 扩展性:服务器场
  1.数据中心进行扩展
  2.扩展性差

客户端:

• 主动与服务器通信
• 与互联网有间歇性的连接
• 可能是动态IP地址
• 不直接与其他客户端通信

对等模式(P2P:peer to peer)

• (几乎)没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每一个节点既是客户端也是服务器(自扩展性-新peer节点带来新的服务能力,当然也带来新的服务请求)
• 参与的主机间歇性连接且可以改变IP地址(难以管理)
• 例子:Gnutella,迅雷

混合体:客户-服务器和对等体系结构

Napster

• 文件搜索:集中
  1.主机在中心服务器上注册其资源
  2.主机向中心服务器查询资源位置
• 文件传输:P2P
  1.任意peer节点之间

即时通信

• 在线检测:集中
  1.当用户上线时,向中心服务器注册其IP地址
  2.用户与中心服务器联系,以找到其在线好友的位置
• 两个用户之间聊天:P2P

进程通信

进程:在主机上运行的应用程序

• 在同一个主机内,使用进程间通信机制通信(操作系统定义)
• 不同主机,通过交换报文(Message)来通信
  1.使用os提供的通信服务
  2.按照应用协议交换报文(借助传输层提供的服务)

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

服务器进程:等待连接的进程

注意:P2P架构的应用也有客户端进程和服务器进程之分

分布式进程通信需要解决的问题

• 问题1:进程标示和寻址问题(服务用户)

• 问题2:传输层-应用层提供服务是如何(服务)
  1.位置:层间界面的SAP(TCP/IP:socket)
  2.形式:应用程序接口API(TCP/IP:socket API)

• 问题3:如何使用传输层提供的服务,实现应用进程之间的报文交换,实现应用(用户使用服务)
  1.定义应用层协议:报文格式,解释,时序等
  2.编制程序,使用OS提供的API,调用网络基础设施提供通信服务传报文,实现应用时序等

问题1:对进程进行编址(addressing)

• 进程为了接收报文,必须有一个标识(即:SAP[发送也需要标示])
  1.主机:唯一的32位IP地址(仅仅有IP地址不能唯一标示一个进程;在一台端系统上有很多应用进程在运行)
  2.所采用的传输层协议:TCP or UDP
  3.端口号(Port Numbers)

• 一些知名端口号的例子:HTTP:TCP 80 Mail;TCP25ftp;TCP 2

• 一个进程:用IP+port标示 端节点

• 本质上:一对主机进程之间的通信由两个端节点构成

问题2:传输层提供的服务-需要穿过层间的信息

• 层间接口必须要携带的信息
  1.要传输的报文(对于本层来说:SDU)
  2.谁传的:对方的应用进程的标示:IP+TCP(UDP)端口
  3.传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号

• 传输层实体(tcp或者udp实体)根据这些信息进行TCP报文端(UDP数据报)的封装
  1.源端口号,目标端口号,数据等
  2.将IP地址往下交IP实体,用于封装IP数据报:源IP,目标IP

问题2:传输层提供的服务-层间信息的代表

• 如果Socket API每次传输报文,都携带如此多的信息,太繁琐易错,不便于管理
• 用个代号标示通信的双方或者单方:socket
• 就像OS打开文件返回的句柄一样
  1.对句柄的操作,就是对文件的操作
• TCP socket:
  1.TCp服务,两个进程之间的通信需要之前要建立连接(两个进程通信会持续一段时间,通信关系稳定)
  2.可以用一个整数表示两个应用实体之间的通信关系,本地标示
  3.穿过层间接口的信息量最小
  4.TCP socket:源IP,源端口,目标IP,目标端口

TCP之上的套接字(socket)

• 对于使用面向连接服务(TCP)的应用而言,套接字是4元组的一个具有本地意义的标示
  1.4元组:(源IP,源port,目标IP,目标port)
  2.唯一的指定了一个会话(2个进程之间的会话关系)
  3.应用使用这个标示,与远程的应用进程通信
  4.不必在每个报文的发送都要指定这4元组
  5.就像使用操作系统打开一个文件,OS返回一个文件句柄一样,以后使用这个文件句柄,而不是使用这个文件的目录名,文件名
  6.简单,便于管理

问题2:传输层提供的服务-层间信息代码

UDP socket

• UDP服务,两个进程之间的通信需要之前无需建立连接
  1.每个报文都是独立传输的
  2.前后报文可能给不同的分布式进程
• 因此,只有用一个整数表示本应用实体的标示
  1.因为这个报文可能传给另外一个分布式进程
• 穿过层间接口的信息大小最小
• UDP socket:本IP,本端口
• 但是传输报文时:必须要提供对方IP,port
  1.接收报文时:传输层需要上传对方的IP,port

UDP之上的套接字(socket)

• 对于使用无连接服务(UDP)的应用而言,套接字是2元组的一个具有本地意义的标示
  1.2元组:IP,port(源端指定)
  2.UDP套接字指定了应用所在的一个端节点(end piont)
  3.在发送数据报时,采用创建好的本地套接字(标示ID),就不必在发送每个报文中指明自己所采用的IP和port
  4.但是在发送报文时,必须要指定对方的IP和UDP port(另外一个段节点)

套接字(socket)

• 进程向套接字发送报文或从套接字收报文
• 套接字<->门户
  1.发送进程将报文推出门户,发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
  2.接收进程从另外一端的门户收到报文(依赖于传输层设施)

问题3:如何使用传输层提供的服务实现应用

• 定义应用层协议:报文格式,解释,时序等
• 编制程序,通过API调用网络基础设施提供通信服务传报文,解析报文,实现应用时序等

应用层协议

定义了:运行在不同端系统上的应用进程如何相互交换报文

• 交换的报文类型:请求和应答报文
• 各种报文类型的语法:报文中的各个字段及其描述
• 字段的语义:即字段取值的含义
• 进程何时,如何发送报文及对报文进行响应规则

应用协议仅仅是应用的一个组成部分

• Web应用:HTTP协议,web客户端,web服务器,HTML

公开协议:

• 由RFC文档定义
• 允许互操作
• 如HTTP,SMTP

专用(私有)协议:

• 协议不公开
• 如:Skype

应用需要传输层提供什么样的服务

数据丢失率

• 有些应用则要求100%的可靠数据传输(如文件)
• 有些应用(如音频)能容忍一定比例以下的数据丢失

吞吐

• 一些应用(如多媒体)必须需要最小限度的吞吐,从而使得应用能够有效运转
• 一些应用能充分利用可供使用的吞吐(弹性应用)

延迟

• 一些应用出于有效性考虑,对数据传输有严格的时间限制
  1.Internet电话,交互式游戏
  2.延迟,延迟差

安全性

• 机密性
• 完整性
• 可认证性(鉴别)

常见应用对传输服务的要求

Internet传输层提供的服务

TCP服务:

• 可靠的传输服务
• 流量控制:发送方不会淹没接受方
• 拥塞控制:当网络出现拥塞时,能抑制发送方
• 不能提供的服务:时间保证,最小吞吐保证和安全
• 面向连接:要求在客户端进程和服务器进程之间建立连接

UDP服务:

• 不可靠数据传输
• 不提供的服务:可靠,流量控制,拥塞控制,时间,带宽保证,建立连接

那为什么要UDP呢?

那么我们接下来介绍UDP存在的必要性

• 能够区分不同的进程,而IP服务不能
  1.在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程
• 无需建立连接,省去了建立连接时间,适合事务性的应用
• 不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用
  1,因为为了实现可靠性(准确性,保序等),必须付出时间代价(检错重发)
• 没有拥塞控制和流量控制,应用能够按照设定的速度发送数据
  1.而在TCP上面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一样的,因为有流量控制和拥塞控制

Internet应用及其应用层协议和传输协议

安全TCP

TCP&UDP

• 都没有加密
• 明文通过互联网传输,甚至密码

SSL

• 在TCP上面实现,提供加密的TCP连接
• 私密性
• 数据完整性
• 端到端的鉴别

SSL在应用层

• 应用采用SSL库,SSL库使用TCP通信

SSL socket API

• 应用通过API将明文交给socket,SSL将其加密在互联网上传输

🎈Web和HTTP

Web页：由一些对象组成

对象可以是HTML文件，JPEG图像，Java小程序，声音剪辑文件等

Web页含有一个基本的HTML文件，该基本HTML文件又包含诺干对象的引用（链接）

通过URL对每个对象进行引用

• 访问协议，用户名，口令字，端口等

URL格式：

HTTP概况

HTTP:超文本传输协议

• Web的应用层协议
• 客户/服务器模式
  1.客户：请求、接收和显示Web对象的浏览器
  2.服务器：对请求进行响应，发送对象的Web服务器
• HTTP 1.0：RFC 1945
• HTTP 1.1：RFC 2068

使用TCP：

• 客户发起一个与服务器的TCP连接（建立套接字），端口号为80
• 服务器接受客户的TCP连接
• 在浏览器（HTTP客户端）与Web服务器（HTTP服务器server）交换报文（应用层协议报文）
• TCP连接关闭

HTTP是无状态的

• 服务器并不维护关于客户的任何信息

维护状态的协议很复杂！

• 必须维护历史信息（状态）
• 如果服务器/客户端死机，它们的状态信息可能不一致，二者的信息必须一致
• 无状态的服务器能够支持更多的客户端

HTTP连接

非持久HTTP

• 最多只有一个对象在TCP连接上发送
• 下载多个对象需要多个TCP连接
• HTTP/1.0使用非持久连接

持久HTTP

• 多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
• HTTP/1.1默认使用持久连接

非持久HTTP连接

响应时间模型

持久HTTP

非持久HTTP的缺点

• 每个对象要2个RTT
• 操作系统必须为每个TCP连接分配资源
• 但浏览器通常打开并行TCP连接，以获取引用对象

持久HTTP

• 服务器在发送响应后，仍保持TCP连接
• 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
• 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求

非流水方式的持久HTTP

• 客户端只能在收到前一个响应后才能发出新的请求
• 每个引用对象花费一个RTT

流水方式的持久HTTP

• HTTP/1.1的默认模式
• 客户端遇到一个引用对象就立刻产生一个请求
• 所有引用（小）对象只花费一个RTT是可能的

HTTP请求报文

两种类型的HTTP报文：请求，响应

HTTP请求报文

HTTP请求报文：通用格式

提交表单输入

Post方式：

• 网页通常包括表单输入
• 包含在实体主题（entity body）中的输入被提交到服务器

URL方法：

• 方法：GET
• 输入通过请求行的URL字段上载

方法类型

HTTP/1.0

• GET
• POST
• HEAD
  1.要求服务器在响应报文中不包含请求对象->故障跟踪

HTTP/1.1

• GET,POST,HEAD
• PUT
  1.将实体主体中的文件上载到URL字段规定的路径
• DELETE
  1，删除URL字段规定的文件

HTTP响应报文

HTTP响应状态码

位于服务器->客户端的响应报文中的首行

用户-服务器状态：cookies

大部分主要的门户网站使用cookies

4个组成部分：

1.在HTTP响应报文中有一个cookie的首部行

2.在HTTP请求报文含有一个cookie的首部行

3.在用户端系统中保留有一个cookie文件，由用户浏览器管理

4.在Web站点有一个后端数据库

例子：

cookies：维护状态

cookies能带来什么：

• 用户验证
• 购物车
• 推荐
• 用户状态（Web-e-mail）

如何维持状态

• 协议端节点：在多个事务上，发送端和接收端维持状态
• cookies：http报文携带状态信息

cookies与隐私：

• cookies允许站点知道许多关于用户的信息
• 可能将它知道的东西卖给第三方
• 使用重定向和cookie的搜索引擎还能知道用户更多的信息
  1.如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式
• 广告公司从站点获得信息

Web缓存（代理服务器）

目标:不访问原始服务器,就满足客户的请求

• 用户设置浏览器:通过缓存访问Web
• 浏览器将所有的HTTP请求发给缓存
  1.在缓存中的对象:缓存直接返回对象
  2.如对象不在缓存,缓存请求原始服务器,然后再将对象返回客户端
• 缓存既是客户端又是服务器
• 通常缓存是由ISP安装(大学,公司,居民区ISP)

为什么要用Web缓存?

• 降低客户端的请求响应时间
• 可以大大减少一个机构内部网络与Internet接入链路上的流量
• 互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容

缓存示例

ppt里的四张图解释:

以及怎么用流量强度I算那个等待时间

条件GET方法

🎈FTP:文件传输协议

• 向远程主机上传输入文件或从远程主机接收文件
• 客户/服务器模式
  客户端:发起传输的一方
  服务器:远程主机
• ftp:RFC 959
• ftp服务器:端口号为21

FTP:控制连接与数据连接分开

• FTP客户端与FTP服务器通过端口21联系,并使用TCP为传输协议
• 客户端通过控制连接获得身份确认
• 客户端通过控制连接发送命令浏览远程目录
• 收到一个文件传输命令时,服务器打开一个到客户端的数据连接
• 一个文件传输完成后,服务器关闭连接
• 服务器打开第二个TCP数据连接用来传输另一个文件
• 控制连接,带外("out of band")传送
• FTP服务器维护用户的状态信息:当前路径,用户账号与控制连接对应
  有状态

FTP命令和响应

🎈电子邮件(EMail)

3个主要组成部分:

• 用户代理
• 邮件服务器
• 简单邮件传输协议:SMTP(Simple Mail Transfer Protocol)

用户代理

• 又名"邮件阅读器"
• 撰写,编辑和阅读邮件
• 如Outlook,foxmail
• 输出和输入邮件保护在服务器上

EMail:邮件服务器

邮件服务器:

• 邮箱中管理和维护发送给用户的邮件
• 输出报文队列保持待发邮件报文
• 邮件服务器之间的SMTP:发送email报文
  1.客户:发送方邮件服务器
  2.服务器:接收端邮件服务器

EMail:SMTP[RFC 2821]

• 使用TCP在客户端和服务器之间传送报文,端口号为25
• 直接传输:从发送方服务器到接收方服务器
• 传输的3个阶段:
  1.握手
  2.传输报文
  3.关闭
• 命令/响应交互
  1.命令:ASCII文本
  2.响应:状态码和状态信息
• 报文必须为7位ASCII码

举个🌰

举例:A给B发送报文
1)A使用用户代理撰写邮件并发送B@someschool.edu
2)A的用户代理将邮件发送到他的邮件服务器;邮件在报文队列中
3)SMTP的客户端打开到B邮件服务器的TCP连接
4)SMTP客户端通过TCP连接发送A的邮件
5)B的邮件服务器将邮件放到B的邮箱
6)B调用他的用户代理阅读邮件

简单的SMTP和尝试SMTP自己互动

SMTP:总结

• SMTP使用持久连接
• SMTP要求报文(首部和主体)为7位ASCII编码
• SMTP服务器使用
  CRLF.CRLF决定报文的尾部

HTTP比较:

• HTTP:pull
• SMTP:push
• 二者都是ASCII形式的命令/响应交互,状态码
• HTTP:每个对象封装在各自的响应报文中
• SMTP:多个对象包含在一个报文中

邮件报文格式

SMTP:交换email报文的协议

RFC 822:文本报文的标准:

• 首部行:如,
  1.to:
  2.form:
  3.subject:
  与SMTP命令不同
• 空行
• 主体
  1.报文,只能是ASCII码

报文格式:多媒体扩展

MIME:多媒体邮件扩展(Multipurpose Internet Mail Extensions)
RFC 2045,2056

邮件访问协议

• SMTP:传送到接收方的邮件服务器
• 邮件访问协议:从服务器访问邮件
  1.POP:邮局访问协议(Post Office Protocol)RFC 1939
  2.IMAP:Internet邮件访问协议(Internet Mail Access Protocol)[RFC 1730](更多特性,更复杂 && 在服务器上处理存储的报文)
• HTTP:Hotmail,Yahoo!Mail等(方便)

POP3协议与IMAP

POP3

本地管理文件夹

• 先前的例子使用"下载并删除"模式
  1.如果改变客户机,B不能阅读邮件
• "下载并保留":不同客户机上位报文的拷贝
• pop3在会话中是无状态的

IMAP

远程管理文件夹

• IMAP服务器将每个报文与一个文件夹联系起来
• 允许用户目录来组织报文
• 允许用户读取报文组件
• IMAP在会话过程中保留用户状态:
  1.目录名,报文ID与目录名之间映射

https解决方案和优化