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

文章目录

前言
一、应用层协议原理
- 1.网络应用的体系结构
- 2.进程通信
二、Web与HTTP
- 1.HTTP概况
- 2.HTTP连接
- 3.HTTP请求报文
- 4.用户-服务器状态：cookies
- 5.Web缓存（代理服务器）
三、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

应用进程要自己区分报文的边界，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：（注意这里是响应报文）