计算机网络：应用层（上篇）

前言

应用层协议原理、Web与HTTP、FTP。

一、应用层协议原理

1.网络应用的体系结构

可能的应用架构:

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

客户-服务器（C/S）体系结构

• 服务器:

• 一直运行
• 固定的IP地址和周知的端口号(约定)
• 扩展性:服务器场

• 数据中心进行扩展
• 扩展性差

• 客户端:

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

对等体（P2P）体系结构

• （几乎）没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每一个节点既是客户端又是服务器

• 自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求

• 参与的主机间歇性连接且可以改变P地址

• 难以管理

• 例子:Gnutella，迅雷

C/S和P2P体系结构的混合体

• Napster

• 文件搜索:集中

• 主机在中心服务器上注册其资源
• 主机向中心服务器查询资源位置

• 文件传输:P2P

• 任意Peer节点之间

• 即时通信

• 在线检测:集中

• 当用户上线时，向中心服务器注册其IP地址
• 用户与中心服务器联系，以找到其在线好友的位置

• 两个用户之间聊天:P2P

2.进程通信

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

• 在同一个主机内，使用进程间通信机制通信（操作系统定义）
• 不同主机，通过交换报文（Message）来通信

• 使用OS提供的通信服务
• 按照应用协议交换报文

• 借助传输层提供的服务

• 客户端进程:发起通信的进程
• 服务器进程:等待连接的进程
• 注意:P2P架构的应用也有客户端进程和服务器进程之分

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

问题1:进程标示和寻址问题（服务用户）

对进程进行编址：

• 进程为了接收报文，必须有一个标识即:SAP（发送也需要标示）

• 主机:唯一的32位IP地址

• 仅仅有IP地址不能够唯一标示一个进程;在一台端系统上有很多应用进程在运行

• 所采用的传输层协议:TCP or UDP
• 端口号(Port Numbers)

• 一些知名端口号的例子:

• HTTP: TCP 80 Mail: TCP25 ftp:TCP 2

• 一个进程:用IP + port 标示端节点
• 本质上，一对主机进程之间的通信由2个端节点构成

问题2:传输层-应用层提供服务是如何（服务）

• 位置:层间界面的SAP ( TCP/IP: socket)
• 形式:应用程序接口APT ( TCP/IP : socket API)

传输层提供的服务-需要穿过层间的信息：

• 层间接口必须要携带的信息

• 要传输的报文（对于本层来说:SDU）
• 谁传的:对方的应用进程的标示:IP+TCP(UDP)端口
• 传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号

• 传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段（UDP数据报）的封装

• 源端口号，目标端口号，数据等
• 将IP地址往下交IP实体，用于封装IP数据报：源IP,目标IP

传输层提供的服务-层间信息的代表：

• 如果Socket APT每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理
• 用个代号标示通信的双方或者单方: socket
• 就像OS打开文件返回的句柄一样

• 对句柄的操作，就是对文件的操作

• TCP socket:

• TCP服务，两个进程之间的通信需要之前要建立连接

• 两个进程通信会持续一段时间，通信关系稳定

• 可以用一个整数表示两个应用实体之间的通信关系，本地标示
• 使穿过层间接口的信息量最小
• TCP socket:源IP,源端口，目标IP，目标IP,目标端口
• 总而言之：Tcp socket是本地端口和目标端口的一个标识，与端口号的概念不同，便于管理，使穿过层级的信息量减少，tcp socket利用四元组的形式来标识端口:源ip，源端口，目标ip，目标端口。
• 是本地应用层和传输层的约定，只有他俩自己知道。

TCP之上的套接字（socket）：

• 对于使用面向连接服务(TCP）的应用而言，套接字是4元组的一个具有本地意义的标示

• 4元组:(源IP，源port，目标IP，目标port)
• 唯一的指定了一个会话（2个进程之间的会话关系)o应用使用这个标示，与远程的应用进程通信
• 不必在每一个报文的发送都要指定这4元组
• 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名
• 简单，便于管理

传输层提供服务-层间信息代表：

• UDP socket：

• UDP服务，两个进程之间的通信需要之前无需建立连接

• 每个报文都是独立传输的
• 前后报文可能给不同的分布式进程

• 因此，只能用一个整数表示本应用实体的标示

• 因为这个报文可能传给另外一个分布式进程

• 穿过层间接口的信息大小最小
• UDP socket:本IP,本端口
• 但是传输报文时:必须要提供对方IP，port

• 接收报文时:传输层需要上传对方的IP，port

UDP之上的套接字（socket）：

• 对于使用无连接服务（UDP）的应用而言，套接字是2元组的一个具有本地意义的标示

• 2元组:IP，port(源端指定〉
• UDP套接字指定了应用所在的一个端节点（end point)
• 在发送数据报时，采用创建好的本地套接字（标示ID），就不必在发送每个报文中指明自己所采用的ip和port
• 但是在发送报文时，必须要指定对方的ip和udp port(另外一个段节点)

套接字（socket）：

• 进程向套接字发送报文或从套接字接收报文
• 套接字<–>门户

• 发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
• 接收进程从另外一端的门户收到报文（依赖于传输层设施）

问题3:如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）

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

应用层协议：

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

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

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

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

公开协议：

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

专用（私有）协议:

• 协议不公开
• 如:Skype

应用需要传输层提供什么样的服务?如何描述传输层的服务?

• 数据丢失率

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

• 延迟

• 一些应用出于有效性考虑，对数据传输有严格的时间限制

• Internet电话、交互式游戏
• 延迟、延迟差

• 吞吐

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

• 安全性

• 机密性完整性
• 可认证性（鉴别）

Internet传输层提供的服务：

• TCP服务:

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

• UDP服务:

• 不可靠数据传输
• 不提供的服务:可靠，流量控制、拥塞控制、时间、带宽保证、建立连接
• Q:为什么要有UDP?

UDP存在的必要性：

• 能够区分不同的进程，而IP服务不能

• 在IP提供的主机到主机端到端功能的基础上，区分了主机的应用进程

• 无需建立连接，省去了建立连接时间，适合事务性的应用
• 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用

• 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发）

• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

• 而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

安全TCP：

• TCP & UDP

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

• SSL

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

• SSL在应用层

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

• SSL socket APT

• 应用通过API将明文交给socket，SSL将其加密在互联网上传输
• 详见第8章

二、Web与HTTP

介绍一些术语

• Web页:由一些对象组成
• 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
• Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接）
• 通过URL对每个对象进行引用
• 访问协议，用户名，口令字，端口等
• URL格式：
  

1.HTTP概况

• HTTP:超文本传输协议

• Web的应用层协议
• 客户/服务器模式

• 客户:请求、接收和显示Web对象的浏览器
• 服务器:对请求进行响应，发送对象的Web服务器

• HTTP 1.O: RFC 1945
• HTTP 1.1: RFC 2068

• 使用TCP:

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

• HTTP是无状态的

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

• 维护状态的协议很复杂!

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

2.HTTP连接

（1）非持久HTTP连接

响应时间模型：

往返时间RTT (round-triptime)：一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略）

响应时间：

• 一个RTT用来发起TCP连接
• 一个RTT用来HTTP请求并等待HTTP响应
• 文件传输时间共:2RTT+传输时间

（2）持久HTTP

3.HTTP请求报文

通信格式：

提交表单输入：

方法类型：

• HTTP/1.0

• GET
• POST
• HEAD

• HTTP/1.1

• GET、POST、HEAD
• PUT

• 将实体主体中的文件上载到URL字段规定的路径

• DELETE

• 删除URL字段规定的文件

HTTP响应报文：

HTTP响应状态码：

位于服务器–>客户端的响应报文中的首行一些状态码的例子：

• 200 OK

• 请求成功，请求对象包含在响应报文的后续部分

• 301 Moved Permanently

• 请求的对象已经被永久转移了;新的URL在响应报文的Location:首部行中指定
• 客户端软件自动用新的URL去获取对象

• 400 Bad Request

• 一个通用的差错代码，表示该请求不能被服务器解读

• 404 Not Found

• 请求的文档在该服务上没有找到

• 505 HTTP version Not supported

应用进程要自己区分报文的边界，TCP向上层提供的服务是不区分边界的，你发两段15K内容，但是实际上TCP收到的是一个30K内容。

4.用户-服务器状态：cookies

大多数主要门户使用cookies。cookie也弥补了HTTP无状态的问题。

四个组成部分：

• 在HTTP响应报文中有一个cookie的首部行
• 在HTTP请求报文含有一个cookie的首部行
• 在用户端系统中保留有一个cookie文件，由用户的浏览器管理
• 在Web站点有一个后端数据库

Cookies：维护状态

在第一次向服务器请求时是没有Cookie值的，第一次请求后，服务器会生成一个cookie响应给客户端。

Cookies能带来什么：

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

如何维持状态：

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

Cookies与隐私：

• Cookies允许站点知道许多关于用户的信息
• 可能将它知道的东西卖给第三方
• 使用重定向和cookie的搜索引擎还能知道用户更多的信息

• 如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式

• 广告公司从站点获得信息

5.Web缓存（代理服务器）

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

• 用户设置浏览器:通过缓存访问Web
• 浏览器将所有的HTTP请求发给缓存

• 在缓存中的对象:缓存直接返回对象
• 如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端

• 缓存既是客户端又是服务器
• 通常缓存是由ISP安装(大学、公司、居民区ISP)

为什么要使用Web缓存?

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

缓存示例：

服务器中数据修改，缓存器与服务器数据不一致？

在对比缓存生效时，状态码为304，并且报文大小和请求时间大大减少。

原因是，服务端在进行标识比较后，只返回header部分，通过状态码通知客户端使用缓存，不再需要将响应报文体部分返回给客户端。

对于对比缓存来说，缓存标识的传递是我们着重需要理解的，它在请求header和响应header间进行传递，一共分为两种标识传递。

Last-Modified：（注意这里是响应报文）

• 服务器在响应请求时，告诉浏览器资源的最后修改时间。

If-Modified-Since：（注意这里是请求报文）

• 再次请求服务器时，通过此字段通知服务器上次请求时，服务器返回的资源最后修改时间。
• 服务器收到请求后发现有头If-Modified-Since 则与被请求资源的最后修改时间进行比对。
• 若资源的最后修改时间大于If-Modified-Since，说明资源又被改动过，则响应整片资源内容，返回状态码200；
• 若资源的最后修改时间小于或等于If-Modified-Since，说明资源无新修改，则响应HTTP 304，告知浏览器继续使用所保存的cache。

Expires

• Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。
  不过现在一般不是用这个参数：
  
• Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略；
  
• 到期时间是由服务端生成的，但是客户端时间可能跟服务端时间有误差，这就会导致缓存命中的误差。
  

所以HTTP 1.1 的版本，使用Cache-Control替代。

Cache-Control

• Cache-Control是最重要的规则。常见的取值有private、public、no-cache、max-age，no-store，默认为private。
  

图中Cache-Control仅指定了max-age，所以默认为private，缓存时间为31536000秒（365天）也就是说，在365天内再次请求这条数据，都会直接获取缓存数据库中的数据，直接使用。

注意：

如果Expires和Cache-Control同时存在，Cache-Control会覆盖Expires。建议两个都写，Cache-Control是http1.1的头字段，Expires是http1.0的头字段，都写兼容会好点。

三、FTP：文件传输协议

• 向远程主机上传输文件或从远程主机接收文件
• 客户/服务器模式

• 客户端:发起传输的一方
• 服务器:远程主机

• ftp: RFC 959
• ftp服务器:端口号为21

1.FTP：控制连接与数据连接分开

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

控制命令和刷数据传输分别在两个TCP进行。

2.FTP命令、响应

命令样例：

• 在控制连接上以ASCII文本方式传送
• USER usernamePAss password
• LIST:请服务器返回远程主机当前目录的文件列表
• RETR filename:从远程主机的当前目录检索文件(gets)
• STOR filename:向远程主机的当前目录存放文件(puts)

返回码样例：

• 状态码和状态信息(同HTTP)
• 331 Username OK,password required
• 125 data connectionalready open;transfer starting
• 425 can’t open dataconnection
• 452 Error writingfile

总结

以上就是应用层的一些讲解，分为两篇，上篇下篇，下篇后续会发。