计算机网络基础
大家好呀!我是小笙,本章我主要分享计算机网络基础 - 应用层(1)学习总结,希望内容对你有所帮助!!
应用层
网络应用的体系结构
- 客户-服务器模式(C/S:client/server)
- 对等模式(P2P:Peer To Peer)
- 混合体:客户-服务器和对等体系结构
C/S 体系结构
服务器
- 一直运行
- 固定的 IP 地址和周知的端号(约定)
- 扩展性:服务器场(数据中心进行扩展、 扩展性差)
客户端
- 主动与服务器通信
- 与互联网有间歇性的连接
- 可能是动态 IP 地址
- 不直接与其它客户端通信
注意:服务器 IP 也不一定是固定的,但是域名必须是固定的。可以通过 ddns 来刷新服务器的动态 ip
P2P 体系结构
- (几乎)没有一直运行的服务器
- 任意端系统之间可以进行通信
- 每一个节点既是客户端又是服务器
- 参与的主机间歇性连接且可以改变 IP 地址
- 难以管理
例子:Gnutella、迅雷
C/S 和 P2P 体系结构的混合体
Napster
- 文件搜索:集中
- 文件传输:P2P
即时通信
- 在线检测:集中
- 当用户上线时,向中心服务器注册其IP地址
- 用户与中心服务器联系,以找到其在线好友的位置
- 两个用户之间聊天:P2P
进程通信
概述
进程(在主机上运行的应用程序)
- 分为客户端进程、服务端进程
- 在同一个主机内,使用进程间通信机制通信
- 不同主机间,通过报文来通信
进程寻址
进程为了接收报文,必须有一个标识,即:SAP(发送也需要标示)
- 主机:唯一的 32位IP地址
- 所采用的传输层协议:TCP or UDP
- 端口号(Port Numbers)
层间接口必须要携带的信息
- 要传输的报文(对于本层来说:SDU)
- 谁传的:对方的应用进程的标示:IP + TCP(UDP) 端口
- 传给谁:对方的应用进程的标示:对方的 IP + TCP(UDP) 端口号
如果Socket API 每次传输报文,都携带如此多的信息,太繁琐易错,不便于管理
套接字(Socket)
一个进程向另一个进程发送的报文必须通过下面的网络时候,进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文,因此套接字也称为应用程序和网络之间的应用程序编程接口 API
- 进程向套接字发送报文或从套接字接收报文(套接字 <=> 门户)
- 发送进程将报文推出门户,发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
- 接收进程从另外一端的门户收到报文(依赖于传输层设施)
TCP socket
-
TCP服务,两个进程之间的通信需要之前要建立连接
-
两个进程通信会持续一段时间,通信关系稳定
-
可以用一个整数表示两个应用实体之间的通信关系,本地标示
四元组:源端系统 ip 、源端系统 port 、目标端系统 ip 、目标端系统 port
UDP socket
-
UDP服务,两个进程之间的通信需要之前无需建立连接
- 每个报文都是独立传输的
- 前后报文可能给不同的分布式进程
-
穿过层间接口的信息大小最小
-
只能用一个整数表示本应用实体的标示
二元组:本机 ip、本机 port
注意:但是传输报文时:必须要提供对方ip、port
应用层协议
运行在不同端系统上的应用进程如何相互交换报文(协议定义规范)
- 交换的报文类型:请求和应答报文
- 各种报文类型的语法:报文中的各个字段及其描述
- 字段的语义:即字段取值的含义
- 进程何时、如何发送报文及对报文进行响应的规则
- 应用协议仅仅是应用的一个组成部分
公开协议以及专用协议
- 公开协议:由RFC文档定义允许互操作,如:HTTP、SMTP
- 专用(私有)协议:协议不公开,如:Skype
应用层需要传输层提供的服务
- 数据丢失率
- 有些应用则要求100%的可靠数据传输(如文件)
- 有些应用(如音频)能容忍一定比例以下的数据丢失
- 吞吐
- 一些应用出于有效性考虑,对数据传输有严格的时间限制 (Internet 电话、交互式游戏 )
- 延迟
- 一些应用(如多媒体)必须需要最小限度的吞吐,从而使得应用能够有效运转
- 一些应用能充分利用可供使用的吞吐(弹性应用)
- 安全性(机密、完整性、可认证性)
常见应用对传输服务的要求
![image-20240815222317474](https://img-blog.csdnimg.cn/img_convert/e7944ec572e60611e4c76d68e72590f7.png)
Web 与 HTTP
概念
Web页由一些对象组成,对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
- 多数Web页都含有一个 HTML 基本文件,该 HTML 基本文件又包含若干对象的引用(链接)
- 通过URL对每个对象进行引用:访问协议,用户名,口令字,端口等
Web 的应用层协议的核心是超文本传输协议 HTTP
- 定义了 Web 客户向 Web 服务器请求 Web 页面的方式,以及服务器向客户传送 Web 页面的方式
- 使用传输层 TCP 协议建立连接
- HTTP 是无状态的,服务器并不维护客户的信息
![](https://img-blog.csdnimg.cn/img_convert/4a49b08a9c74f065813f5f911288a312.png)
非持续连接和持续连接
概述
在许多因特网应用程序中,客户和服务器在 个相当长的时间范围内通信,当这种客户一服务器的交互是经 TCP 进行的,应用程序的研制者就需要做一个重要决定 ,即每个请求/响应对是经个单独的 TCP 连接发送,还是所有的请求及其应经相同 TCP 连接发送呢?
前者就是非持续连接,后者就是持续连接(HTTP1.0 采用的是非持续连接;HTTP1.1 采用的是持续连接)
非持续连接存在的问题
- 必须为每一个请求的对象建立和维护一个全新的连接,对于每个这样的连接,在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量,这给 Web 服务器带来了严重的负担,因为 Web 服务器可能同时服务于数以百计不同的客户的请求
- 每一个对象经受两倍 RTT 的交付时延,即一个 RTT 用于创建 TCP ,另一个 RTT 用于请求和接收一个对象
响应时间模型
- 往返时间 RTT:一个小的分组从客户端到服务器,再回到客户端的时间
- 响应时间:发起TCP连接时间 + HTTP请求等待时间 + 传输时间 = 2RTT + 传输时间
![](https://img-blog.csdnimg.cn/img_convert/8ed714629c94efcf70c4b0200910a357.png)
HTTP报文格式
请求报文
请求报文第一行称为 请求行,后继的行称为 首部行,最后可能还有实体对象(实体对象会和首部行中间会有回车或者换行,注意是在特定的请求方法下才有内容,如 POST)
-
请求行有三个字段:方法字段、URL 字段、HTTP 版本字段
-
首部行指明了对象的主机域名/IP、是否继续连接、用户代理(比如浏览器版本)、语言类型等等
-
一个HTTP请求报文的通用格式
响应报文
它也是由三部分组成:一个初始状态行,首部行 , 然后是实体对象
-
状态行有 3 个字段:协议版本字段、状态码和相应状态信息
-
首部行指明了是否继续连接、服务器产生并发送该响应报文的日期和时间、用户代理(比如浏览器版本)、上次对象创建或者最后修改的日期和时间等等
-
一个HTTP 响应报文的通用格式
响应状态码
- 200 OK :请求成功
- 301 Moved Permanently
- 请求的对象已经被永久转移了;新的URL在响应报文的 Location(首部行中指定)
- 客户端软件自动用新的 URL 去获取对象
- 400 Bad Request :一个通用的差错代码,表示该请求不能被服务器理解
- 404 Not Found :请求的文档在该服务上没有找到
- 505 HTTP Version Not Supported:服务器不支持请求报文使用的 HTTP 协议版本
Cookie
用于维护客户和服务器之间的状态(HTTP 是无状态的)
![image-20240817221119552](https://img-blog.csdnimg.cn/img_convert/ae3a2e355b0fae6617d4814f68dcef1d.png)
缺点
尽管 cookie 常常能简化用户的因特网活动,但是它的使用仍具有争议,因为它们被认为是对用户隐私的一种侵害;如我们刚才所见,结合 cookie 和用户提供的账户信息,Web 站点可以知道许多有关用户的信息,并可能将这些信息卖给第三方
Web 缓存
Web 缓存器 (Web cache) 也叫代理服务器,不访问原始服务器,就能满足客户的请求
- 代理服务器既是服务器又是客户端
- 浏览器将所有的 HTTP 请求发给代理服务器
- 在缓存中的对象,直接返回对象
- 如果不在缓存中,代理服务器请求原始服务器,然后再将对象返回给客户端
如何判断放在代理服务器中的对象是否是陈旧的?
通过获取请求头的方式获取到 If-Modified-Since 信息(上次对象创建或者最后修改的日期和时间),进而可以判断出代理服务器中的对象在源服务器中是否有被修改过