计网(二):应用层(上)

系列文章目录


文章目录


前言

中科大计网笔记,教材《自定向下方法》

(一)应用层协议原理

1.目标

在这里插入图片描述
创建一个新的网络应用

  • 编程:
    • 在不同的端系统上运行
    • 通过网络基础设施提供的服务,应用进程彼此通信
    • 如Web:Web 服务器软件与浏览器软件通信
  • 网络核心中没有应用层软件
    • 网络核心没有应用层功能
    • 网络应用只在端系统上存在,快速网络应用开发和部署

因为应用部署的简便以及网络核心部署的快速,网络得以发展地很快

2.网络应用体系结构

2.1. 客户-服务器(C/S)

服务器
  • 一直运行
  • 固定的IP地址和周知的端口号(约定)
  • 资源(软、硬、数据等)全部在服务器,客户端向服务器申请资源
  • 扩展性:服务器场数据中心进行扩展的扩展性差
客户端
  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可以是动态IP地址
  • 不直接与其它客户端通信
缺点
  • 可拓展性差
  • 达到一定能限(阈值),性能暴跌(理想情况下,希望性能随着用户数量增多线性下降,但实际上会断崖式下降)
  • 可靠性差(服务器宕机就完蛋了)
    在这里插入图片描述

2.2. 对等体(P2P)

每个节点,既请求其他P2P的服务,同时就它所拥有的资源,又可以向其他的节点提供服务。在这个session上是客户端,在另一个session上是服务器。新的请求节点的数量增加的同时,提供服务的节点的数量也在增加,所以很容易就可以平滑的扩展。

  • (几乎)没有一直运行的服务器
  • 任意端系统之间可以进行通信
  • 每一个节点既是客户端又是服务器
  • 自扩展性:新peer节点带来新的服务能力,当然也带来新的服务请求(因此随着用户规模的增长,性能不一定是下降,而是维持在一定的程度)

因此迅雷类似的服务可以很容易的将用户扩大到很多

  • 参与的主机间歇性连接且可以改变地址。例子:Gnutella,迅雷

缺点:难以管理,节点间歇性连接,要随时追踪连接情况。

2.3.C/S和P2P混合

例如Napster(一个文件分发系统)

  • 文件搜索:集中(目录服务器)
    • 主机(客户端)在中心服务器上注册其资源
    • 主机(客户端)向中心服务器查询资源位置
  • 文件传输:P2P
    • 任意Peer节点之间

注册和目录的查询是集中式的,文件的传输是P2P

即时通信

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

微信和QQ可以这么认为,但实际上更加复杂

2.4.分布式架构

这里没有细讲,在分布式系统课程中有讲

3.进程通信及问题

3.1.基本概念

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

  • 在同一个主机内,使用进程间通信机制通信(操作系统定义,不需要网络,如管道、消息队列等)
  • 不同主机,通过交换报文(Message)来通信
    • 使用OS提供的通信服务
    • 按照应用协议交换报文
    • 借助传输层提供的服务

客户端进程:发起通信的进程
服务器进程:等待连接的进程

注意:P2P架构的应用也有客户端进程和服务器进程之分,主动发起请求的是客户端进程,被动接收请求的是服务器进程

3.2.相关问题

分布式进程通信需要解决的问题(应用进程如何使用传输层提供的服务交换报文
在这里插入图片描述

  • 问题1:进程标示寻址问题 (对于进程谁发/谁收,对等层实体之间) (就是如何标识自己,标识要求是唯一的,而且有寻址功能)
  • 问题2:传输层-应用层是如何提供服务 (上下层间)
    • 位置:层间界面的SAP (TCP/IP :socket)
    • 形式:应用程序接口API (原语)(TCP/IP :Socket API)
  • 过程:应用通过层间接口(SAP),以应用程序接口API的形式借助传输层的服务对对方发送报文。
  • 问题3:(以上两点达成后)如何使用传输层提供的服务,实现应用进程之间的报文交换,实现应用 (本层间)
    • 定义应用层协议:报文格式,解释,时序等
    • 编制程序,使用OS提供的API ,调用网络基础设施提供通信服务传报文,实现应用时序等

总的来说,就是

  • 进程的标识和寻址
  • 应用层如何使用传输层的服务
  • 应用层定义协议

3.3.进程编址(标识)

解决问题1:对进程进行编址(addressing)
进程为了接收报文,必须有一个标识即: SAP(发送也需要标示, S A P → P I D SAP\rightarrow PID SAPPID)这里以TCP/IP协议为例

  • 主机:唯一的32位IP地址,仅仅有IP地址不能够唯一标示一个进程。在一台端系统上有很多应用进程在运行。
  • 所采用的传输层协议:TCP or UDP
  • 端口号(Port Numbers) 用来区分不同的应用进程

一个进程用主机IP + TCP/UDP + 端口号来标识

一些知名端口号的例子:HTTP: TCP(Web应用) 80 Mail: TCP 25 ftp: TCP 21

本质上,一对主机进程之间的通信由2个端节点(EndPoint)构成

3.4 应用层向传输层提供的数据

解决问题2:传输层-应用层是如何提供服务 (上下层间)

3.4.1.提供的数据
  • 层间接口必须要携带的信息
    • 发什么: 要传输的报文(本层的SDU) (SDU----未经本层封装的)
    • 谁发的:我方的应用进程的标示:IP+TCP(UDP)端口
    • 发给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号

发什么,谁发的,发给谁,也就是发送端应用进程的标识 + 接收端应用进程的标识 + 数据

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

如果Socket API(原语)每次传输报文(穿过层间),都携带如此多的信息,太繁琐易错,不便于管理。用个代号标示通信的双方或者单方:socket
就像OS打开文件返回的句柄一样,对句柄的操作,就是对文件的操作。总之,发送端应用进程的标识 + 接收端应用进程的标识 + 数据每次都发太麻烦了,所以建立socket连接之后就不用再传了

3.4.2.socket
TCP socket
  • TCP服务,两个进程之间的通信需要之前要建立连接,两个进程通信会持续一段时间,通信关系稳定,可以用一个整数表示两个应用实体之间的通信(会话)关系,即socket。
  • 对于使用面向连接服务(TCP)的应用而言,TCP socket 是一个具有本地意义的标识(类似文件描述符)
  • socket逻辑上表示一个四元组:源IP,源port,目标IP,目标port;
  • 从物理上看,TCPsocket实质就是一个整数,唯一的标记了一个会话(2个进程之间的会话关系)
  • 应用使用这个标示,与远程的应用进程通信,这个标记址只有本地的应用层和传输层知道,传输层以下的网络层等和对方端系统都不知道。
  • 不必在每一个报文的发送都要指定这四元组,而是用socket来指代。就像使用操作系统打开一个文件,OS返回一个文件句柄一样,以后使用这个文件句柄,而不是使用这个文件的目录名、文件名。
  • 便于管理。
  • 使得穿过层间的信息量最小。

socket用一个本地意义整数代表的本地的ip+端口地址,对方的ip+端口地址
使用socket后,应用层-传输层层间在传输数据的时候不需要发送四元组,只需要发数据(SDU)加一个整数即可
socket就是将四元组映射到整数,用一个整数代表四元组在层间传输,并没有建立什么复杂的内容,比如内存之类的,这些都是底层做的 ,只需要维护一张映射表即可。
socket仅仅是保存(标记)这些寻址识别信息,传输是由传输层负责的
在TCP,也就是面向连接的传输中,socket是一个本地标识。

在这里插入图片描述
在这里插入图片描述

TCP socket代表的是一个会话关系,而不仅仅只是一个分布式进程的标识,如上图在中间的主机80端口上就有两个socket的值,代表不同的会话关系,表示它在和两个进程进行会话。

UDP socket
  • UDP服务,两个进程之间的通信需要之前无需建立连接,每个报文都是独立传输的,前后报文可能给不同的分布式进程,因此,只能用一个整数表示本应用实体的标示(并不代表一个会话关系,因为它是无连接的)

  • 对于使用无连接服务(UDP)的应用而言,套接字是二元组的一个具有本地意义的标识。

  • UDP socket:逻辑上表示源IP,源端口二元组。

  • 从物理上看,UDPsocket实质也是一个整数,唯一的标记了一个应用主体。
    -因为UDP是表示源IP,源端口二元组。所以传输报文时:还必须要提供目标IP,目标端口;接收报文时:传输层需要上传对方IP,对方端口。

  • 使得穿过层间接口的信息大小最小

UDP的socket表示一个二元组: IP,port(源端指定)
UDP套接字指定了一个会话关系(应用)的一个端节点(endpoint),在发送数据报时,采用创建好的本地套接字(标示ID),就不必在发送每个报文中指明自己所采用的ip和port,但是在发送报文时,还是必须要指定对方的ip和udp port(另外一个端节点)
即使用UDP的时候,应用层要向数据层传递数据本身 + 对方ip + 对方的端口+UDP socket。
在这里插入图片描述

3.4.3.总结 + 比较
套接字(Socket)

进程向套接字发送报文或从套接字接收报文。

  • 套接字就像门户一样:
  • 发送进程将报文推出门户,发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程。
  • 接收进程从另外一端的门户收到报文(依赖于传输层设施)
  • 套接字在物理上就是一个整数
  • 逻辑上表示:
  • TCP socket:指定了一个会话,表示一个四元组(源IP,源port,目标IP,目标port)
    • UDP socket:指定了一个应用所在的一个端节点,表示一个二元组(源IP,源port)
  • 优点:
    • 便于管理
    • 使得穿过层间的信息量最小
      在这里插入图片描述

这里的socket就像两个任意门,对于应用层来说,这个进程只要一打开socket,对面就是另一个会话进程,想要发什么东西直接向里面发就行,对于任意门是如何实现的并不关心。任意门的实现就是基础设施提供的服务。我们也可以暂时将其视为黑匣子。
到此为止,我们在第五层应用层,可以通过传输层提供的socket服务建立socket,通过这个socket进行发送和接收。而传输层如何应用socket进行传输这是传输层要做的事情。现在的问题是如何在传输层提供的服务的基础上来实现应用需要的业务逻辑、传输协议。

3.5.定义应用层协议

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

  • 定义应用层协议:报文格式,解释,时序等
  • 编制程序,通过API调用网络基础设施提供通信服务传报文,解析报文,实现应用时序等
应用层协议说明
  • 定义了:运行在不同端系统上的应用进程如何相互交换报文(分布式的应用进程在通信工程当中要遵循的规则的集合。)
  • 交换的报文类型:请求和应答报文
  • 各种报文类型的语法:报文中的客个字段及其描述
  • 字段的语义:即字段取值的含义进程何时、如何发送报文及对报文进行响应的规则
  • 应用协议仅仅是应用的一个组成部分,如Web应用包括:HTTP协议,web客户端,web服务器,HTML

应用还包含了其他的内容,比如用户界面,IO,内部的业务逻辑等与网络交互无关的部分
实体是实现网络协议的软件模块和硬件模块(运行中)

  • 应用协议分为两类:
  • 公开协议:协议是开放的,由RFC文档定义,允许互操作,任何一个厂商考研遵照其规范实现自己的应用,如HTTP, SMTP。
  • 专用(私有)协议:协议不公开,如:Skype(通过网络打电话)

3.传输层服务要求

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

3.1.传输层服务指标

3.1.1.指标
数据丢失率
  • 有些应用则要求100%的可靠数据传输(如文件、电子邮件)
  • 有些应用(如音频)能容忍一定比例以下的数据丢失
延迟
  • 一些应用出于有效性考虑,对数据传输有严格的时间限制,如多媒体应用:Internet电话、交互式游戏等
吞吐
  • 一些应用(如多媒体)必须需要最小限度的吞吐,从而使得应用能够有效运转
  • 一些应用能充分利用可供使用的吞吐(弹性应用)

所谓能充分利用可供使用的吞吐也就是有的应用对吞吐量要求不高,如果吞吐量高,那么就能充分应用,吞吐量低也能运行,只不过速率比较慢而已
吞吐量:在源端和目标端之间传输的速率(数据量/单位时间),可以理解为带宽

安全性
  • 机密性
  • 完整性
  • 可认证性(鉴别)
3.1.2.举例
应用数据丢失率吞吐时间敏感性
文件传输不能丢失弹性
e-mail不能丢失弹性
Web文档不能丢失弹性
实时音视频容忍丢失(丢失了一块不影响整体的信息)音频: 5kbps-1Mbps;视频: 100kbps-5Mbps是,100ms
存储音视频(点播)容忍丢失同上是,几秒
交互式游戏容忍丢失几kbps-10kpbs是,100ms
即使讯息不能丢失弹性是或不是

3.2.传输层提供的服务

3.2.1.TCP服务
  • 可靠的传输服务(发的什么,收到就是什么)
  • 流量控制:发送方不会淹没接受方,当发送端发送速度太快,接收端接收较慢,则接收端会给发送端发出反馈,发送端及时调整。
  • 拥塞控制:当网络出现拥塞时,TCP协议实体能感知到网络堵塞,然后能抑制发送方。
  • 不能提供的服务:时间保证、最小吞吐保证和安全的保证
  • 面向连接:要求在客户端进程和服务器进程之间建立连接(三次握手)

为什么叫面向连接? 因为这种连接只体现在端系统上,与有连接进行区别,有连接是指整个链路上的所有节点都要维护这个连接关系

3.2.2.UDP服务
  • 不可靠数据传输
  • 不提供的服务:可靠,流量控制、拥塞控制、时间保证、带宽保证、建立连接
为什么要有UDP?
  • 能够区分不同的进程,而IP服务不能,在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程
  • 无需建立连接,省去了建立连接时间,适合事务性的应用
  • 不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用,因为为了实现可靠性(准确性、保序等),必须付出时间代价(检错重发)、复杂性的代价。
  • 没有拥塞控制和流量控制,应用能够按照设定的速度发送数据,而在TCP上面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一致的,因为有流量控制和拥塞控制。
3.2.3.举例
应用应用层协议下层的传输协议
e-mailSMTP(RFC 2821)TCP
远程终端访问Telnet(RFC 854)TCP
WebHTTP(RFC 2616)TCP
文件传输FTP(RFC 959)TCP
流媒体专用协议(如RealNetworks)TCP或UDP(大多UDP,但是有些大厂设计防火墙等问题如,会过滤UDP,必须使用TCP,尽管效率低)
Internet电话专用协议(如Net2Phone)TCP或UDP(大多UDP)
3.2.4.安全TCP(SSL)

TCP & UDP 共有的性质:都不提供安全保证

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

如Telent应用远程登陆服务器,账号密码都是明文。

SSL 提供安全性

  • 在TCP上面实现,提供加密的TCP连接
    • 私密性
    • 数据完整性
    • 端到端的鉴别
  • SSL在应用层,应用采用SSL库(SSL采用库的形式与应用程序一起运行,所以说在应用层上),SSL库使用TCP通信。
  • SSL socket API
    • 应用通过API将明文交 给socket,SSL将其加密在互联网上传输

(二)Web and HTTP

写在开头:本章内容仅仅是基础的内容,实际上Web和HTTP还有很多扩展的知识

1.一些术语

1.1.web

  • Web页:由一些对象组成
  • Web页本身就是一个对象,内部嵌入了一些对象,嵌入的不是对象本身,而是对象的链接
  • Web页面有一个最基础的 base html,然后html通过链接其他的对象构成了一个网状结构
  • 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
  • Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
  • 通过URL(通用资源定位服务)对每个对象进行引用,包括访问协议用户名,口令字,端口等;
  • 任何对象都可以采用URL来访问,任何对象也可以采用URL来唯一标识
  • Web应用的代理软件:浏览器

1.2.URL

  • URL格式:
Port://user:psw@www.someSchool.edu/someDept/pic.gif:port
路径元素含义
Port协议名
user:psw用户名:口令
www.someSchool.edu主机名
someDept/pic.gif路径名
port端口

用户名:口令可以不提供,即匿名访问
http协议默认端口是80,如果不指定端口则默认访问80端口。

1.3.Web页面解析流程

对于一个网页:

  • 首先拿到网页的base html
  • 浏览器根据HTML协议解析html文件,画出页面结构
  • 拿出网页中的链接,访问该链接,将响应的文件嵌入到页面中

2.HTTP协议

2.1.基本概念

2.1.1.HTTP
  • HTTP: 超文本传输协议,非线性文本,指的是文本与文本之间相互的任意的指向关系。
  • 网络架构:客户/服务器模式(C/S)
    • 客户: 请求、接收和显示 Web对象的浏览器
    • 服务器: 对请求进行响应, 发送对象的Web服务器
  • 版本
    • HTTP 1.0: RFC 1945
    • HTTP 1.1: RFC 2068
      在这里插入图片描述
2.1.2.连接方式:TCP

HTTP协议使用的都是TCP连接方式

过程
  • 服务器运转在固定端口80上开启一个守护端口(TCP socket),等待来自客户端的TCP建立请求。
  • 客户发起一个与服务器的TCP连接(建立套接字),端口号为80(默认是80)
  • 服务器同意客户端的TCP连接建立请求,此时web服务器就有了一个socket表示和这个客户端的会话关系,原守护端口依旧用来监听请求。
  • 在浏览器(HTTP客户端)与Web服务器(HTTP服务器server)交换HTTP报文(应用层协议报文)
  • TCP连接关闭

2.2.HTTP连接

HTTP 1.0和HTTP1.1的区别
在这里插入图片描述

2.2.1.非持久HTTP
  • 最多只有一个对象在 TCP连接上发送
  • 下载多个对象需要多个TCP连接
  • 当服务端响应了文件之后,HTTP就关闭了TCP连接,也就是每次发出请求都需要先建立TCP连接,响应之后直接关闭连接。
    在这里插入图片描述
    在这里插入图片描述
  • HTTP1.0使用非持久连接

对象指的是请求或响应的文件内容,比如请求一个视频,服务器响应回来的视频就是对象

  • HTTP1.0 连接是无状态的

无状态:服务器不维护客户端的状态,结束一次响应后就断开TCP,不保存客户端任何信息。之前传过的内容,接下来要继续申请的内容,服务器都不知道。

  • 无状态连接的好处:
  • 简单,不需要维护一些状态(它是一个没有记忆的人,所有也就没有痛苦),来什么请求,就给什么响应。
  • 同样的资源,无状态的服务器能够支持更多的客户端

维护状态的协议很复杂!

  1. 必须维护历史信息(状态)
  2. 如果服务器/客户端死机,它们的状态信息可能不一致, 二者的信息必须是一致。
  • .非持久连接缺点:
  • 每个对象要2个 RTT
  • 操作系统必须为每个TCP连接分配资源
  • 但浏览器通常打开并行TCP连接 ,以获取引用对象
2.2.2.持久HTTP
  • 多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输
  • HTTP/1.1 默认使用持久连接
    -服务器在发送响应后,仍保持TCP连接
    -在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
  • 客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求

在这里插入图片描述

流水/非流水的持久HTTP
  • 非流水方式的持久HTTP:
    • 客户端只能在收到前一个响应后,才能发出新的请求
    • 每个引用对象花费一个RTT
  • 流水方式的持久HTTP:
    • HTTP/1.1的默认模式
    • 客户端遇到一个引用对象就立即产生一个请求,不必等待前一个请求的响应完成。
  • 所有引用(小)对象只花费一个RTT是可能的
2.2.3. 往返时间RRT和响应时间
  • 往返时间RTT(round-trip time):一个小的分组从客户端到服务器,再回到客户端的时间(传输时间忽略)
  • 响应时间:2RTT+传输时间
    • 一个RTT用来发起TCP连接
    • 一个RTT用来HTTP请求并等待HTTP响应
    • 文件传输时间
      在这里插入图片描述

RTT不包含传输时间,响应时间包含,响应时间 = 2RTT+传输时间

2.3.HTTP报文

  • 两种类型的HTTP报文:请求、响应
  • 报文都是ASCII可读的,即打印出来是可以直接读的,早期的协议通常都是这样的
2.3.1.HTTP请求报文
请求报文格式
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
部分举例说明
请求行GET /somedir/page.html HTTP/1.1命令: GET:获取数据;POST:上载数据;HEAD:仅仅获取相应头部,搜索引擎使用改命令得到头部之后建立索引;资源路径:/somedir/page.html协议/协议版本:HTTP/1.1
首部行Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:frhost:主机名;User-agent:用户代理的程序/浏览器的第几个版本;Connection:是否关连接
实体

请求报文通常没有实体行,所有实体行为空

在这里插入图片描述

  • sp是space空格
  • cr是回车
  • if是有可能有,有可能没有
提交表单输入

用于添加请求时向服务器提交的信息,服务端可以根据信息选择性响应信息

  • Post方式:
    • 网页通常包括表单输入
    • 包含在实体主体 (entity body )中的输入被提交到服务器
  • URL方式:
  • 方法:GET
  • 输入通过请求行的URL字段作为参数的形式上载
http://www.somesite.com/animalsearch?monkeys&banana 
参数:monkeys&banana 
http://www.baidu.com/s?wd=xx+yy+zzz&cl=3
参数:wd=xx+yy+zzz  cl=3
请求方法类型
协议版本请求方式说明
HTTP/1.0GET获取数据
POST上载数据
HEAD要求服务器在响应报文中 不包含请求对象 -> 故障跟踪;仅仅获取相应头部,搜索引擎使用该命令,得到头部之后建立索引
HTTP/1.1GET
POST
HEAD
PUT将实体主体中的文件上载到URL字段规定的路径
DELETE删除URL字段规定的文件
2.3.2. HTTP响应报文
响应报文格式
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998... 
Content-Length: 6821
Content-Type: text/html


data data data data data ...
部分举例说明
状态行HTTP/1.1 200 OK包括协议版本、状态码和相应状态信息。HTTP/1.1是协议及版本,200是状态码,OK是状态码相应状态信息
首部行Connection close // Date: Thu, 06 Aug 1998 12:00:15 GMT // Server: Apache/1.3.0 (Unix) // Last-Modified: Mon, 22 Jun 1998 …… // Content-Length: 6821 // Content-Type: text/html
数据data data data data data …请求的数据,如HTML文件
部分首部行信息
  • Last-Modified:最后修改的日期(相当于一个版本号)
  • Content-Length:6921内容长度,表示在首部部之后读6821个单位的内容,TCP向应用层传播的仅仅是字节流的服务,并不维护报文的边界,需要应用层自己维护区分,HTTP协议通过Content-Length区分
部分状态码

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

部分举例说明
200OK请求成功,请求对象包含在响应报文的后续部分
301Moved Permanently请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定;客户端软件自动用新的URL去获取对象
400Bad Request一个通用的差错代码,表示该请求不能被服务器解读
404Not Found请求的文档在该服务上没有找到
505HTTP version Not supported版本不支持

2.4. 用户-服务器状态:cookies

如上述,HTTP协议是一格无状态的协议,即服务器不维护客户端的状态。

2.4.1.cookie的组成成分

大多数主要的门户网站使用cookies
4个组成部分:

  • 在HTTP响应报文中有一个cookie的首部行
  • 在HTTP请求报文含有一个cookie的首部行
  • 在用户端系统中保留有一个cookie文件,由用户的浏览器管理
  • 在Web站点有一个后端数据库
2.4.2. cookie流程
  • 客户端第一次发送请求的时候通常没有cookie
  • 服务器第一次响应的时候为客户端生成cookie,保存这个cookie,然后将cookie号放在respond报文头部返回。
  • 客户端收到相应之后将cookie保存到本地,由浏览器管理

之后的每次请求都会发送这个cookie

2.4.3.举例
  • Susan总是用同一个PC使用Internet Explore上网
  • 她第一次访问了一个使用了Cookie的电子商务网站
  • 当最初的HTTP请求到达服务器时,该Web站点产生一个唯一的ID,并以此作为索引在它的后端数据库中产生一个项。
    在这里插入图片描述
2.4.4. cookie的应用和原理

Cookies能带来什么:

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

如何维持状态:

  • 协议端节点:在多个事务上,发送端和接收端维持状态
  • cookies: http报文携带状态信息
2.4.5. Cookies与隐私
  • Cookies允许站点知道许多关于用户的信息
  • 可能将它知道的东西卖给第三方
  • 使用重定向和cookie的搜索引擎还能知道用户更多的信息
  • 如通过某个用户在大量站点上的行为,了解其个人浏览方式的大致模式
  • 广告公司从站点获得信息

有些网站就要求发送cookie,从而收集到用户的信息进行推荐等用处

3.Web缓存 (代理服务器proxy)

3.1.目标

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

3.2.描述
  • 用户设置浏览器:通过缓存访问Web (这是需要设置的)

  • 浏览器将所有的HTTP 请求发给缓存

  • 缓存命中,即请求的对象在缓存中:缓存直接返回对象

  • 缓存不命中,即请求对象不在缓存中,缓存请求原始服务器,然后 再将对象返回给客户端

  • 缓存既是客户端又是服务器

  • 通常缓存是由ISP安装 (大学、公司、居 民区ISP)
    在这里插入图片描述

3.3.优点
  • 降低客户端的请求响应时间(用户快)
  • 减少服务器收到的请求,降低服务器的负载(服务器轻)
  • 可以大大减少一个机构内部网络(局域网)与Internent接入链路上的流量(网络轻)
  • 互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容
3.4.缓存示例

在这里插入图片描述

原始情况:
假设
  • 平均对象大小 = 100kb(也就是请求的文件的平均大小是100kb)
  • 机构网络(局域网)内浏览器对原始服务器的平均请求率为 = 15请求/s
  • 平均到浏览器的速率:1.5Mbps(100kb * 15请求/s)
  • 机构内部路由器到原始服务器路由器再返回到路由器的时延(internet时延) = 2s
  • 接入链路带宽:1.544Mbps
相关数据计算
  • Internet延时:公共网(public Internet)路由器到原始服务器 再返回到路由器的的延时 ( Internet 延时)=2s
  • 接入网流量强度 I = 平均到达浏览器的速率 / 接入链路宽带 = 1.5Mbps/1.544Mbps = 97%
  • L/R:一个分组的传输时间
  • 接入网排队延时 = t q u e u e = I 1 − I × ( L / R ) t_{queue} = \frac{I}{1-I} \times( L / R) tqueue=1II×(L/R),此时延迟非常非常大,假设为2min。
  • LAN延时:客户端到LAN路由器再返回客户端的时间,局域网带宽足够大,这里假设为10ms
结果

LAN的流量强度 = 15%
接入链路上的流量强度 = 97% (排队延迟会非常大,排队延迟会随着分组的流量强度越接近于1趋近于无穷,此时排队延迟会非常大)
总延时= LAN延时(忽略不计)+ 接入延时+ Internet 延时(忽略不计) = 2min

优化一: 提高接入链路带宽
假设
  • 接入链路带宽:154.4Mbps
  • 其他与原来一样
相关数据计算
  • 接入链路上的流量强度 = 0.9%
  • 接入网排队延时 = t q u e u e = I 1 − I × ( L / R ) t_{queue} = \frac{I}{1-I} \times( L / R) tqueue=1II×(L/R),此时延迟非常非常小,假设为1ms。
  • 其余没变
结果
  • 总延时 = LAN延时(忽略不计) + 接入延时(忽略不计) + Internet 延时 = 2s
代价:

增加了接入链路带宽(非常昂贵!)

优化二:安装本地缓存
假设

与原始条件一致。

相关数据计算
  • 缓存命中率:假设为0.4,即40%请求在缓存中被满足,其他60%的请求需要被原始服务器满足
  • 接入链路利用率: 60%的请求采用接入链路
  • 进过接入链路到达浏览器的数据速率 = 0.6*1.50 Mbps = 0.9 Mbps
  • 流量强度I= 0.9/1.54 = 58%
  • 接入网排队延时 = t q u e u e = I 1 − I × ( L / R ) t_{queue} = \frac{I}{1-I} \times( L / R) tqueue=1II×(L/R),约为一个分组的传输时间。
结果
  • t 1 t_1 t1 :从原始服务器获取对象的延迟,也就是接入延时 + Internet延时
  • t 2 t_2 t2:本地访问时间,10ms
  • 总体延迟 = 0.6 x t 1 t_1 t1 +0.4 x t 2 t_2 t2 (忽略不计) + 一个分组传输时间(忽略不计)= 1.2 s
代价

比安装154Mbps链路还来得小 (而且比较便宜!)

3.5.缓存与服务器一致性问题

如果服务器中的文件修改了,那么缓存需要向服务器请求新的内容

条件GET方法(对象版本和服务器版本一致性问题)
  • 目标:如果缓存器中的对象拷贝是最新的,就不要发送对象
  • 缓存器: 在HTTP请求中指定缓存拷贝的日期 If-modified-since:<date>
  • 服务器: 如果缓存拷贝陈旧,则响应报文没包含对象: HTTP/1.0 304 Not Modified
    在这里插入图片描述

(三)FTP

1.FTP: 文件传输协议

在这里插入图片描述

项目说明
用处向远程主机上传输文件或从远程主机接收文件
网络架构客户/服务器模式 // 客户端:发起传输的一方;服务器:远程主机
协议ftp: RFC 959
端口号ftp服务器:端口号为21
  • FTP服务器维护用户的状态信息: 当前路径、用户帐户与控制连接对应,即FTP是有状态的协议
  • 控制连接: 带外( “out of band” )传送 ,就是客户端可以向服务端发送连接请求或控制信息。
  • 数据连接: 带内( “in of band” )传送 ,就是服务器可以向客户端发送其请求的数据。

2.流程

FTP: 控制连接与数据连接分开,在两个TCP上进行。

控制连接
  • FTP客户端与FTP服务器通过21端口建立联系,并使用TCP为传输协议
  • 客户端通过控制连接获得身份确认
  • 客户端通过控制连接发送命令浏览远程目录(或者其他信息)
数据连接
  • 服务端收到一个文件传输命令时,服务器主动和客户端的20端口建立数据连接(协议规定但是违反常理的动作)
  • 一个文件传输完成后,服务器关闭数据连接
继续控制连接

客户端继续通过控制连接发送命令:下载文件

重新开启数据连接
  • 服务器打开第二个TCP 数据连接用来传输另一个文件(服务器主动)
  • 然后又关闭连接

客户端向服务端发送并保持控制连接,通过控制连接来向服务端发送命令
服务端接受命令之后,向客户端请求建立数据连接,通过数据连接来发送文件

3. FTP命令、响应

3.1.命令样例

在控制连接上以ASCII文本方式传送

命令说明
USER username发送用户名
PASS password发送命令
LIST请服务器返回远程主机当前目录的文件列表
RETR filename从远程主机的当前目录检索文件 (gets)
STOR filename向远程主机的当前目录存放文件 (puts)

3.2. 返回码示例

状态码说明
331Username OK, password required
125data connection already open; transfer starting
425Can’t open data connection
452Error writing file

4.FTP协议 vs HTTP协议

  • FTP协议是有状态的,HTTP协议是无状态的
  • FTP协议的控制命令和数据传输分别在两个TCP上进行,HTTP协议在一个TCP上进行

(四)Email

1.应用组成

3个主要组成部分

  • 用户代理
  • 邮件服务器
  • 简单邮件传输协议:发送协议:SMTP;拉取协议:POP3,IMAP(HTTP也可以)

1.1.用户代理 (客户端软件)

  • 又名 “邮件阅读器” ,用于撰写、编辑和阅读邮件
  • 如Outlook、Foxmail
  • 输出和输入邮件保存在服务器上

Web应用的代理,就是浏览器
FTP应用的代理,就是FTP的客户端软件

1.2.邮件服务器

  • 邮箱(即每个用户的邮件队列)中管理和维护发送给用户的邮件
  • 输出报文队列保持待发送邮件报文
  • 邮件服务器之间的SMTP协议 :发送email报文
    • 客户:发送方邮件服务器
    • 服务器:接收端邮件服务器

1.3.邮件发、收流程

  • 代理发送:发邮件的用户使用用户代理配置好邮件服务器的ip和端口号,将邮件发到用户的邮件服务器的队列当中。
  • 邮件服务器发送(通过SMTP):原始邮件服务器从队列当中依次取邮件,向相应的目标邮件服务器发走。目标邮件服务器收到别的邮件服务器发的邮件后,放在相应的用户的目录中(即邮件箱)
  • 代理拉取(通过POP3或者IMAP):收邮件的用户使用用户代理从相应的邮件服务器的自己的邮箱当中把别人发送给他的邮件拉取过来。

在这里插入图片描述

2.SMTP

2.1.基本信息

项目内容
使用协议TCP
网络架构C/S
端口号25
  • 直接传输:从发送方服务器到接收方服务器
  • 传输的3个阶段
    • 握手
    • 传输报文
    • 关闭
  • 命令/响应交互
    • 命令:ASCII文本
    • 响应:状态码和状态信息
  • 要求:报文必须为7位ASCII码 (规范传输内容)

也就是说,邮件的内容也必须在7位ASCII码之内,最开始连中文也不能传输;后来有了补丁才可以

2.2.流程

举例:Alice给Bob发送报文

在这里插入图片描述

  • Alice使用用户代理撰写邮件并发送给 bob@someschool.edu
  • Alice的用户代理将邮件发送到她的邮件服务器;邮件放在报文队列中
  • SMTP的客户端打开到Bob邮件服务器的TCP连接(建立TCP连接)
  • SMTP客户端通过TCP连接发送Alice的邮件
  • Bob的邮件服务器将邮件放到Bob的邮箱(POP3,IMAP)
    Bob调用他的用户代理阅读邮件
简单的SMTP交互

以下是两个右键服务器进行SMTP交互的流程

  • C:客户,发送方邮件服务器
  • S:服务器,接收方邮件服务器
S: 220 hamburger.edu #回复连接建立状态码220,然后将邮件服务器的名称告诉客户端
C: HELO crepes.fr #向服务器传递的第一个命令是HELO.该命令包含一个参数,即你的邮箱名。
S: 250 Hello crepes.fr, pleased to meet you # 如果命令成功,服务器会返回一个代码为250的回应。
C: MAIL FROM: <alice@crepes.fr> #用MAILFROM命令告诉服务器你想发一封邮件。该命令以发信人的邮件地址为参数。
S: 250 alice@crepes.fr... Sender ok #接受成功
C: RCPT TO: <bob@hamburger.edu> #收信人邮箱名
S: 250 bob@hamburger.edu ... Recipient ok #  如果你想将邮件发给多个收件人的话。你需要多次使用RCPTTO命令,对每个命令,服务器都会返回代码为250的回应。

C: DATA  # 现在你可以向服务器发送邮件正文了。用DATA命令告诉服务器以下的内容为邮件正文。在你从服务器收到代码为354的回应后,你就可以发送邮件正文了。
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?#邮件按行发送,每行邮件以一个无回车的换行符结束
C: How about pickles?
C: .  #注意最后一个字符是一个小数点。这是正文结束的标志。
S: 250 Message accepted for delivery #服务器收到这个标志后,就会立即向你返回一个代码为250的回应以及该邮件的唯一ID号。
C: QUIT #断开同服务器的连接就用QUIT命令
S: 221 hamburger.edu closing connection #服务器会返回一个代码为221的回应并断开连接

只要按照这个格式就可以在邮件服务器通信,因此可以伪造邮件

2.3.SMTP总结

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

与HTTP比较:

  • HTTP:拉(pull)
  • SMTP:推(push)
  • 二者都是ASCII形式的命令/ 响应交互、状态码
  • HTTP:每个对象封装在各自的响应报文中,一个相应只包含一个对象(比如如果HTML页面中有链接,并不会将连接和页面都放在一个报文中)
  • SMTP:多个对象包含在一个报文中(如果传输10张照片,也会放在一个文件中)

2.4.邮件报文格式

2.4.1.基本格式
  • SMTP:交换email报文的协议
  • RFC 822: 文本报文的标准。
  • 首部行:如,
    • To:
    • From:
    • Subject:
  • 主体
    • 报文,只能是ASCII码字符

在这里插入图片描述

2.4.2.多媒体扩展

原先只允许使用ASCII码字符,弦子语义扩展

  • MIME:多媒体邮件扩展(multimedia mail extension), RFC 2045, 2056
  • 在报文首部用额外的行申明MIME内容类型

常用Base64对STMP的ASCII码进行拓展传输更多内容

Base64常用于在处理文本数据的场合,表示、传输、存储一些二进制数据,包括MIME的电子邮件及XML的一些复杂数据。
在MIME格式的电子邮件中,base64可以用来将二进制的字节序列数据(即不能用ASCII表示的字符序列)编码成ASCII字符序列构成的文本

在这里插入图片描述

3. 邮件访问协议

邮件访问协议就是用户代理从邮件服务器拉取邮件
在这里插入图片描述

两推出一拉取
  • SMTP: 传送到接收方的邮件服务器
  • 邮件访问协议:从服务器访问邮件 (3种方式)
    • POP3:邮局访问协议(Post Office Protocol)[RFC 1939]
      用户身份确认 (代理<–>服务器) 并下载,能够区分收件箱和发件箱。
    • IMAP:Internet邮件访问协议(Internet Mail Access Protocol)[RFC 1730]
      更多特性和功能 (更复杂) :在服务器上处理存储的报文,远程的邮件服务器上创建目录,将邮件从一个目录半岛另一个目录(远程目录维护)
    • HTTP:Hotmail , Yahoo! Mail等
      方便

4.POP3

用户确认阶段

  • 客户端命令:
    • user: 申明用户名
    • pass: 口令
  • 服务器响应
    • +OK
    • -ERR

事物处理阶段

  • 客户端
    • list: 报文号列表
    • retr: 根据报文号检索报文
    • dele: 删除
    • quit:关闭连接
# 用户确认阶段
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on
# 事物处理阶段
C: list #列出报文号列表
S: 1 498
S: 2 912
S: .
C: retr 1 #从邮箱当中将1号邮件拉取下来
S: <message 1 contents>#邮件1的内容
S: .
C: dele 1#从邮箱当中将1号删掉
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off

上面的例子使用 “下载并删除”模式。 如果改变客户机,Bob不能阅读邮件,因为已经被删除了
“下载并保留”:不同客户机上为报文的拷贝

POP3在会话中是无状态的
POP3不支持远程目录维护,不允许客户端在邮件服务器建立目录,不允许邮件在目录间跳来跳去。

4.IMAP

  • IMAP服务器将每个报文与一个文件夹联系起来
  • 允许用户用目录来组织报文
  • 允许用户读取报文组件
  • IMAP在会话过程中保留用户状态:
    • 目录名、报文ID与目录名之间映射
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值