计算机网络:应用层(上篇)

简介: 计算机网络:应用层(上篇)



前言

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

总结

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

相关文章
|
19天前
|
存储 分布式计算 监控
应用层---网络模型
应用层---网络模型
19 3
|
2天前
|
域名解析 存储 网络协议
一次读懂网络分层:应用层到物理层全解析
**网络五层模型简介:** 探索网络服务的分层结构,从应用层开始,包括HTTP(网页传输)、SMTP(邮件)、DNS(域名解析)和FTP(文件传输)协议。传输层涉及TCP(可靠数据传输)和UDP(高效但不可靠)。网络层由IP(路由数据包)、ICMP(错误报告)和路由器构成。数据链路层处理MAC地址和帧传输,物理层规定了电缆、连接器和信号标准。了解这些基础,有助于深入理解网络运作机制。
11 5
|
19天前
计算机网络学习记录 应用层 Day6(2)
计算机网络学习记录 应用层 Day6(2)
14 0
|
19天前
|
网络协议
计算机网络学习记录 应用层 Day6(1)
计算机网络学习记录 应用层 Day6(1)
16 0
|
19天前
|
存储 缓存 网络协议
计算机网络网--应用层
计算机网络网--应用层
17 0
|
1月前
|
网络协议 API
【计算机网络概述】第二章:应用层:2.1 应用层原理
【计算机网络概述】第二章:应用层:2.1 应用层原理
|
1月前
|
域名解析 存储 缓存
【基础计算机网络】应用层
【基础计算机网络】应用层
|
2月前
|
传感器 数据可视化 JavaScript
物联网架构:感知层、网络层和应用层
【5月更文挑战第30天】物联网(IoT)由感知层、网络层和应用层构成。感知层利用传感器(如DHT11)收集环境数据;网络层通过ESP8266等设备将数据传输至云端;应用层提供用户服务,如Node-RED实现数据可视化。示例代码展示了Arduino读取温湿度,ESP8266连接Wi-Fi及Node-RED数据可视化流程。物联网架构为数据处理与服务提供全面支持,预示其在各领域广阔的应用前景。
56 2
|
24天前
|
机器学习/深度学习 前端开发 JavaScript
【计算机网络】深度学习使用应用层的HTTP协议
【计算机网络】深度学习使用应用层的HTTP协议
37 0
|
2月前
|
存储 缓存 网络协议
计算机网络 第三章 应用层(习题)
计算机网络 第三章 应用层(习题)
38 1