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

文章目录

前言
一、应用层协议原理
- 1.网络应用的体系结构
- 2.进程通信
二、Web与HTTP
三、FTP：文件传输协议
- 1.FTP：控制连接与数据连接分开
- 2.FTP命令、响应
总结

前言

应用层协议原理、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