21-05-07-计网自顶向下方法

第 2 章 应用层

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

1.客户 - 服务器体系结构

  • 浏览器与web服务器是典型的结构

  • 这种结构客户之间不直接通信

  • 服务器具有固定的、周知的地址

  • 服务器总是打开的

  • 典型应用：web、FTP、Telnet、电子邮件

两种网络应用体系结构

2.P2P体系结构

  • 使用应用程序的主机之间使用直接通信，主机被称为对等方

  • 典型应用：文件共享、迅雷、因特网电话和视频会议

  • 自扩展性

3.某些应用具有混合的体系结构，结合了客户 - 服务器和P2P的元素

2.1.2 进程通信

网络应用之间的通信

在不同端系统的进程，通过计算机网络交换报文而相互通信

1.客户和服务器进程

在客户 - 服务器体系结构中，自然有一对进程，客户端与服务器端在进行通信

在P2P体系结构中，进程既可以是客户，也可以是服务器，不同的场景进行不同的判断

2.进程和计算机网络之间的接口

进程通过套接字的软件接口向网络发送报文和从网络接收报文，进程类比房子，套接字类比门

套接字：同一台主机内应用层与运输层之间的接口；建立网络应用程序的可编程接口，因此也称应用程序编程接口

应用层开发者对运输层的控制仅限于：

  • 选择运输层协议
  • 设定几个运输层参数，如最大缓存和最大报文段长度

应用进程、套接字及运输层协议

3.进程寻址

发送进程发送分组，接收进程接收分组，需要有两种信息：

  • 主机的地址

IP地址

  • 目的主机中指定接收进程的标识符

端口号

2.1.3 可供应用程序使用的运输服务

从四个方面对应用程序服务要求进行分类：

  • 可靠数据传输
  • 吞吐量
  • 定时
  • 安全性

1.可靠数据传输

大部分应用都不能接受分组丢失，所以运输层协议需要能够提供进程到进程的可靠数据传输，于是发送进程只要将数据传递进套接字就完全相信该数据能无差错到达接收进程

部分应用是容忍丢失的应用，能承受一定量的数据丢失，如多媒体应用，丢失的数据引起音频/视频出现小干扰

2.吞吐量

运输层协议需要能够以某种特定的速率提供确保的可用的吞吐量总是为至少 r bit / s

带宽敏感的应用：具有吞吐量要求的应用，当其接收的吞吐量是需要吞吐量的一半时是几乎没有用处的，如因特网电话

多媒体应用：能够根据当时可用的带宽利用可供使用的吞吐量，如电子应用、文件传输、web传送

3.定时

如：发送方注入套接字的每个bit到达接收方的套接字不迟于 100 ms

4.安全性

毋庸置疑，肯定不能让第三方观察到发送方与接收方的数据

2.1.4 因特网提供的运输服务

1.TCP服务

  • 面向连接

在应用层数据报文流动前，客户端和服务器交换运输层控制信息

在握手阶段后，一个TCP连接在两个进程的套接字之间建立了，全双工的，双方可同时进行报文的收发，结束后必须拆除该连接

  • 可靠数据传输

依靠TCP可无差错、按适当顺序交付所有发送数据

  • 拥塞控制

当网络出现拥塞时，会抑制发送进程，试图控制每个TCP连接来达到公平共享网络带宽

SSL(Secure Sockets Layer)安全套接字层：TCP的加强版，能做TCP的一切，且提供了关键的进程到进程的安全性服务，如加密、数据完整性和端点鉴别，在应用层实现

2.UDP服务

不提供不必要服务的轻量级运输协议，仅提供最小服务，无连接的，不可靠的，不保证该报文会到达接收进程，到达顺序可能是乱序的

3.因特网运输协议所不提供的服务

吞吐量和定时保证

部分应用及其应用层协议和支撑的运输协议

2.1.5 应用层协议

定义了运行在不同端系统上的应用程序进程如何相互传递报文，如：

  • 交换的报文类型，如请求报文和响应报文
  • 各种报文的语法，如字段及其如何描述
  • 字段的语义，及字段信息的含义
  • 确定一个进程何时以及如何发送报文，对报文进行响应的规划

应用层协议至少网络应用的一部分

2.2 web和HTTP

2.2.1 HTTP 概况

HTTP请求响应

服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息，假设某个特定客户在几秒内两次请求一个为对象，服务器不会因为刚刚提供了该对后不作出反应，而是重新发出该对象，像完全忘记不久前做过的信息，因为HTTP服务器不存储关于客户的任何信息，所以HTTP协议是一个无状态协议

2.2.2 非持续连接和持续连接

非持续连接：每个请求/响应对是经过一个单独的TCP连接发送

持续连接：所有请求及其响应经相同的TCP连接发送

1.采用非持续连接的HTTP

假设从服务器向客户端传送一个web页面（一个HTML文件和10JPEG图像，11个对象在同一台服务器上），设url为"http://www.someSchool.edu/someDepartment/home.index"

  • HTTP客户端在端口号80发起一个TCP连接（80是HTTP默认端口），在服务器和客户上分别有一个套接字与该连接相关连

  • HTTP客户经套接字向该服务器发送一个HTTP请求报文

  • HTTP服务器进程经套接字接收该请求报文，从其存储器取出对象 www.someSchool.edu/someDepartment/home.index ，在一个HTTP响应报文中封装，并通过套接字向客户发送响应报文

  • HTTP服务器进程通知TCP断开该连接，直到确认客户收到响应报文后中断连接

  • HTTP客户接收响应报文，TCP连接关闭，报文指出封装的对象是HTML文件，客户从报文中取出，检查，得到10个JPEG图形的引用

  • 对每个图像重复前 4 个步骤

每个TCP连接只传输一个请求报文和响应报文，于是在例子中需要产生 11 个连接

客户与服务器之间可以使用串行连接和并行连接

往返时间Round-Trip Time,RTT：

一个短分组从客户到服务器然后再返回客户所花费的时间，包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延

请求和接收一个 HTML 文件的时间估算

用户点击超链接时：

发起一个TCP连接，三次握手，客户向服务器发送一个小TCP报文段，服务器用一个TCP报文段确认和响应，最后客户返回确认，前两个部分则占用了一个RTT，客户结合三次握手的第三部分向该TCP连接上发送一个HTML文件请求报文，当该报文到达服务器，服务器则在该TCP连接上发送HTML文件，该HTTP请求/响应用去了一个RTT，于是总的响应时间是两个RTT加上服务器传输HTML文件的时间

缺点：

  • 必须为每一个请求的对象建立和维护一个全新的连接，而每个连接客户和服务器都要分配TCP缓冲区和保持TCP变量
  • 每一个对象经受两倍RTT交付时延，一个用于创建TCP，一个用于请求和接收一个对象

2.采用持续连接的HTTP

服务器在发送响应后保持该TCP连接打开，在相同的客户和服务器之间，后续的请求和响应报文能够在相同的连接进行传送

在上述例子中，一个完整web页面可以用单个持续连接进行传送，甚至多个web页面

一般来说，一条连接经过一定时间间隔（可配置）仍未被使用时，HTTP服务器则关闭该连接

2.2.3 HTTP报文格式

1.HTTP请求报文

典型的HTTP请求报文：

典型HTTP报文

第一行为请求行

  • 方法字段：get、post、head、put、delete

  • URL字段

  • HTTP版本字段

其余行为首部行，为web代理高速缓存要求

  • Connection:close 告诉服务器不需要使用持续连接
  • User-agent：用户代理，浏览器类型
  • Accept-language：语言版本，否则则是默认版本

请求报文通用格式：

HTTP请求报文通用格式

  • 实体体

使用POST时才使用，如提交表单、向搜索引擎提供关键词

当然使用get方法也可以使用表单，如以下url：

www.somesite.com/animalserch?monkeys&bananas

  • HEAD方法：

类似GET方法，但服务器用HTTP报文响应时不返回请求对象，开发者常用此方法进行调试跟踪

  • PUT方法：

允许用户上传对象到指定web服务器上的指定路径

  • DELETE方法：

允许用户删除web服务器上的对象

2.HTTP响应报文

为上述请求报文的响应报文:

典型HTTP响应报文

三个部分：

  • 一个初始状态行

    • 协议版本字段：如HTTP/1.1
    • 状态码
    • 相应状态信息

  • 6 个首部行

    • Connection:cloe 发送报文后关闭该连接
    • Date：指示该服务器产生并发送该响应报文的日期和时间，不是对象的，而是响应报文
    • Server：指示是什么服务器所产生的，类型请求报文中的User-agent
    • Last-Modified：对象创建或者最后修改的日期和时间
    • Content-Length：被发送对象中的字节数
    • Content-Type：实体体中的对象是什么格式

  • 实体体：报文主要部分，包含了所请求的对象本身

通用格式：

HTTP响应报文通用格式

常见状态码和短语：

  • 200 OK：请求成功，信息在返回的响应报文中

  • 301 Moved Permanently：请求的对象被永久地转移，新的URL定义在响应报文的Location中，客户软件将自动获取新的URL

  • 400 Bad Request：一个通用差错代码，该请求不能被服务器理解

  • 404 Not Found：被请求的文档不在服务器上

  • 500 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本

2.2.4 用户和服务器的交互：cookie

HTTP使用cookie，它允许站点对用户的身份进行跟踪

用cookie跟踪用户状态

cookie有 4 个组件

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

cookie用于标识一个用户，用户首次访问一个站点时，看吧需要提供一个用户标识，而在后继的会话中，浏览器向服务器传递一个cookie首部，从而向服务器标识了用户

于是cookie可以在无状态的HTTP之上建立了一个用户会话层

2.2.5 web缓存

也叫代理服务器，能代表初始web服务器来满足HTTP请求的网络实体，有其自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的实体

客户通过web缓存器请求对象、

可以将浏览器设置为用户的所有HTTP请求首先指向web缓存器，设置了以后：

  • 浏览器会创建一个到web缓存器的TCP连接，并向web缓存器中的对象发送一个HTTP请求

  • web缓存器进行检查，查看本地是否存储了该对象的副本，有则向客户浏览器用HTTP响应报文返回该对象

  • 没有则打开一个与该对象的初始服务器的TCP连接，web缓存器则发送一个对该对象的HTTP请求，在收到该请求后初始服务器向该web缓存器发送具有该对象的HTTP响应

  • web缓存器收到响应后，在本地存储一份副本，并向客户的浏览器用HTTP响应报文发送给副本，通过原先的TCP连接

web缓存器既是客户又是服务器，通常由ISP购买

使用原因

  • 减少对客户的请求响应时间，当客户与初始服务器的瓶颈带宽远低于客户和web缓存器的带宽
  • 能减少一个机构的接入链路到因特网的通信量，可以不必增加带宽

通过内容分发网络CDN，web缓存器发挥巨大作用

2.2.6 条件GET方法

使用web缓存器带来一个问题，存放在web缓存器上的对象副本可能是陈旧的，而此时HTTP的条件GET方法来允许缓存器证实它的对象是最新的

条件请求GET请求报文：

  • 如果请求报文使用GET方法
  • 请求报文包含一个"If-Modified-Since:"首部行

当客户经过一段时间再次请求一个对象且这对象在web缓存器中时，缓存器通过发送一个条件GET方法执行最新检查，即在"If-Modified-Since:"首部行中添加上一次得到该对象的响应报文的Last-Modified的时间和日期

web服务器收到该请求后，发现该对象在Last-Modified的时间后没有修改，则发送一个响应报文，在状态行中添加 304 Not Modified信息，且在响应中没有包含此对象，省略带宽，该响应报文告诉web缓存器可以向客户转发该对象副本

web缓存器收到该响应报文后则向客户浏览器转发该对象

2.3 因特网中的电子邮件

异步通信

组成部分：

  • 用户代理：user-agent

允许用户阅读、回复、转发、保存、撰写报文

  • 邮件服务器：mail server
  • 简单邮件传输协议：SMTP

电子邮件总体描述

A完成邮件撰写，其邮件代理向邮件服务器发送邮件，此邮件存放在邮件服务器的外出报文队列中，当B要阅读时，其用户代理在其邮件服务器的邮箱中取得该报文

每个接收方在邮件服务器上有一个邮箱，维护着接收方发给他的报文

邮件发送过程：

发送方的用户代理发送邮件到其邮件服务器，再传输到接收方的邮件服务器，最后被转发到接收方的用户代理，接收方要查看邮件时，需要使用用户名和口令来鉴别，当接收方的邮件服务器故障时，发送方的服务器不能将邮件交付给接收方的服务器，此邮件在发送方的服务器发报文队列中保持，并每30分钟左右尝试，若几天后不超过，则删除并以邮件形式通知发送方

SMTP是电子邮件的主要应用层协议，由TCP提供可靠数据传输服务

SMTP有两个部分

发送方邮件服务器上的客户端，接收方邮件服务器上的服务器端

即每个邮件服务器既有客户端又有客户端，从收发方面判断为哪端

posted @ 2021-05-08 00:10  zephxu  阅读(74)  评论(0)    收藏  举报