一文入手计算机网络——应用层

最新推荐文章于 2022-10-18 13:40:15 发布

CCCZEDH

最新推荐文章于 2022-10-18 13:40:15 发布

阅读量321

点赞数

分类专栏：计算机网络文章标签： udp http tcp/ip

本文链接：https://blog.csdn.net/CCCZEDH/article/details/120025380

版权

计算机网络专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1 应用层

思维导图见结尾

应用层协议原理

应用程序体系结构

客户—服务器体系结构
- 客户请求要通过服务器，两个客户不能直接通信
P2P体系结构
- 两个客户可以直接通信，不依赖数据中心的专用服务器

进程通信

这里关注运行在不同端系统上的进程间的通信！端系统之间通过计算机网络交换报文进行通信
通过IP找到目的主机，通过Port找到主机上的目标进程

应用程序使用的传输服务要求

可靠数据传输
- 有确保数据交付服务的协议
吞吐量
定时
- 时延
  - 时效性
安全性
- 机密性
  - 加密/解密
- 数据完整性（窃改）
  - 校验

因特网的传输服务

TCP
- 面向连接、可靠
UDP
- 无连接、不可靠
吞吐量取决于链路的传播速率，定时跟吞吐量也息息相关，这两个不是应用层就能够做好的

应用层对报文的定义

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

应用层协议

图示

应用层协议图示
TCP、UDP

TCP

SMTP\Telnet\HTTP\FTP

UDP

DNS\SNMP

HTTP

HTTP请求报文

图示

HTTP响应报文

图示

Cookie

HTTP服务器本身是无状态的（不保存用户相关的数据）
使用Cookie，可以在Cookie中存放一个唯一标识，以此区别客户端
- 示例
在第一次请求报文的时候，服务器就会创建一个ID，然后发送给客户端，之后客户端就持有这个ID，并且之后的每次请求都会携带这个ID。
这个ID可以被设置过期时间，服务器再次创建并给客户端发一个新ID

Web缓存

Web缓存器也叫代理服务器，它是能够代表初始服务器来满足HTTP请求的网络实体
作用：如果缓冲器里面有客户端所需的信息，那么就可以直接返回缓存器的信息；如果没有，就去访问初始服务器，然后自己缓存一份，再返回给客户端（有点类似redis跟DB）
图示
部署Web缓存器的好处
- 减少初始服务器的访问压力
- 降低客户端请求的响应时间
通过使用内容分发网络（CDN），Web缓存正在因特网中发挥越来越重要的作用，CDN公司在因特网上安装了许多地理上分散的缓存器，因而大量流量实现了本地化。
- 动静分离，将静态资源分布在地理上的多个位置

SMTP

电子邮件

电子邮件是一种异步通信媒介
因特网电子邮件系统三个主要组成部分
- 用户代理
  - 例如微软的Outlook和Apple Mail
- 邮件服务器
  - 电子邮件体系结构的核心
  - 每个接收方在其中的某个邮件服务器上有一个邮箱（mailbox），邮箱负责管理和维护接收接收方的报文
- 简单邮件传输协议（SMTP）
电子邮件发送过程
- 从发送方的代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，再被分发到接收方的邮箱中。接收方之后就可以通过代理阅读报文
  - 发送方发送->发送方代理->发送方邮件服务器->接收方邮件服务器->接收方邮箱->接收方通过代理阅读
- 如果发送方的服务器不能将邮件发送到接收方的服务器，那么发送方的邮件服务器会在一个报文队列中保持该报文，并在以后有限的时间内以一定频率重发多次，如果超出时间限制，那么服务器会删除该报文，并以电子邮件的形式通知发送方

SMTP的细节

SMTP一般不使用中间邮件服务器发送邮箱，邮件并不会在中间邮件服务器留存
发送方的邮件服务器和接收方的邮件服务器会建立一个TCP连接，并且这个连接是直接连接

SMTP发送报文的过程

1、发送方服务器SMTP在25号端口建立一个到接收方服务器SMTP的TCP连接，然后进行SMTP握手。
- 如果接收方服务器没有响应则会继续尝试连接，连接一旦建立则开始握手
- 这个过程有点像人和人，两个人只有发现对方要跟自己说话才会说话，你打招呼对方没注意到，如果你想跟他交流，那么你继续打招呼直到对方发现（建立连接），然后开始寒暄交流（发送报文）
2、发送方服务器发送报文
3、如果有其它邮件发送到同一个接收方服务器，那么发送方服务器重复使用该TCP连接发送报文，否则指示TCP关闭连接

与HTTP的比较

不同点
- HTTP是客户端向服务端发请求，服务器传输文件给客户端，拉协议
  SMTP是发送方服务器发送报文给接收方服务器，推协议
- SMTP要求每个报文采用7bitASCII码格式；
  HTTP没有这种限制
- 对于即包含文本又包含媒体类型的文档：
  HTTP将每个对象封装到自己的HTTP响应报文中；
  SMTP将所有报文对象放在一个报文中
相同点
- 都使用TCP

邮件报文格式

https://blog.csdn.net/qq_35644234/article/details/68961603

http://blog.sina.com.cn/s/blog_65bda7120100ht91.html

https://blog.csdn.net/qq_35644234/article/details/68961603
http://blog.sina.com.cn/s/blog_65bda7120100ht91.html

邮件访问协议

接收方服务器是如何将SMTP报文交给接收方的呢？
SMTP是一个推协议，而获取报文是一个拉操作，因此引入三个协议解决这个矛盾：
1、第三版的邮局协议（POP3）
2、因特网邮件访问协议（IMAP）
3、基于Web的电子邮件（HTTP）

https://support.microsoft.com/en-us/office/what-are-imap-and-pop-ca2c5799-49f9-4079-aefe-ddca85d5b1c9
- POP3
  - POP 的工作原理是联系您的电子邮件服务并从中下载所有新邮件。一旦它们被下载到您的 PC 或 Mac 上，它们就会从电子邮件服务中删除。
  - 子主题 1
- IMAP
  - IMAP 允许您随时随地从任何设备访问您的电子邮件；当您使用 IMAP 阅读电子邮件时，您实际上并不是在将其下载或存储在您的计算机上；相反，您正在通过电子邮件服务阅读它；不会自动下载附件
  - 子主题 2
- HTTP
  - 用户代理就是Web浏览器
    用户代理<–>服务器之间使用的HTTP
    发送方服务器–>接收方服务器使用的还是SMTP

DNS

主机名比IP地址好记，所以要做一个主机名到IP地址的映射，这个映射全部存在本机是不现实的，而是存在域名解析服务器上，也就是DNS。DNS是一个由分层的DNS服务器实现的分布式数据库。DNS协议运行在UDP之上，53端口

DNS服务器层次结构

根DNS服务器
- 根名字服务器提供TLD服务器的IP地址
顶级域（DNS）服务器
- 顶级域：com\org\net\edu\gov
  国家顶级域：cn\uk\us\ca
- TLD服务器提供了权威DNS服务器的IP地址
- 如图，com的DNS服务器有着多个.com的DNS服务器
权威DNS服务器
- 存储主机名字映射到IP地址的记录
本地DNS服务器不属于该层次结构，但是它对改层次结构非常重要。在后面会体现它的重要性

DNS缓存

在一个请求链中，当某DNS服务器接收一个DNS应答，它能将映射缓存在本地存储器中，当下次对一个相同主机名的查询到达该DNS服务器时，DNS服务器就能提供所要求的IP地址
- 此映射是有期限的
有了缓存，本地DNS服务器可以立即返回目标域名映射的IP地址
DNS也能缓存TLD服务器的IP地址，可以让DNS查询绕过根DNS服务器

DNS请求过程

https://www.zhihu.com/appview/p/58108010

基本的DNS请求过程
- 步骤
  - 1、请求主机cis.poly.edu发送一个域名为gaia.cs.umass.edu的DNS查询报文
  - 2、本地DNS服务器发送报文给根DNS服务器，来查找 .edu 顶级域服务器的地址
  - 3、根DNS服务器返回负责 .edu的顶级域服务器的地址列表
  - 4、本地服务器根据根DNS返回的 .edu顶级域服务器的地址，向其中之一发请求报文
  - 5、TLD(.edu)DNS服务器经过查询后，得知权威DNS服务器为dns.umass.edu，然后返回它的地址
  - 6、本地DNS服务器发送请求给dns.umass.edu（权威DNS服务器）
  - 7、权威DNS服务器经查询后将gaia.cs.umass.edu对应的IP地址返回
  - 8、本地DNS服务器接收到后，返回给请求主机
- 注意
  - TLD并不总是直接知道权威DNS服务器的地址，TLD服务器只是知道中间的某个DNS服务器，该中间DNS服务器依次才能知道用于该主机的权威DNS服务器
- 其中，第1步请求是递归查询；第2、4、6是迭代查询，因为所有的回答都是直接返回给本地DNS服务器
使用缓存

DNS报文

图示
wireshark测试
- DNS请求
- DNS响应

P2P

假设我们要下载一个大小为10G的视频文件

如果安装客户-服务器文件来分发，那么服务器将为每个客户发送该文件的副本，服务器承受了极大的负担，消耗了大量服务器带宽。
而采用P2P文件分发，每个对等方能够向其它对等方重新分发它已经收到的该文件的任何部分，并且在这个过程中对等方可以随时退出，并在之后再次加入

P2P体系结构的拓展性

分发时间是所有N个对等方得到该文件副本所需时间
P2P 分发问题
分发时间比较

BitTorrent

定义
- 洪流：参与一个特定文件分发的所有对等方的集合
- 文件块：在一个洪流中所有对等方下载等长度的文件块，典型的长度为256KB
- 追踪器：每个洪流都有的一个基础设施节点，当一个对等方加入某洪流时，它向追踪器注册自己，并周期性通知追踪器自己仍在洪流中
作用过程
- 当一个新的对等方A加入洪流，它会向追踪器注册自己，并且追踪器随机从对等方的集合中选择一个子集的IP地址发送给A
- A持有子集IP后，尝试与它们创建并行的TCP连接，成功创建连接的对等方称为“临近对等方”
  - 临近对等方随时可能离开，因此一个对等方的临近对等方将随时间而波动
- 当A需要自身没有的块时，A通过TCP连接周期性询问每个临近对等方拥有的块列表，此时A就可以知道它的邻居有哪些块，在决定请求哪些块的时候，采用最稀缺优先的技术
  - 最稀缺技术：最稀缺指的是块在临近对等方中最稀缺的块，然后首先请求哪些最稀缺的块，这样子可以让每个对等方都有比较均衡的块副本数量
- 当A响应请求的时候，BitTorrent协议采用了对换算法
  - 基本思想是：A根据谁给自己的块的速度更快，就先向谁响应
  - A会对每个流入的速率做测量，并且确定n个最高速率的对等方集合，这个n个对等方称为疏通
  - 每过t秒，A会随机选一个不在n中的一个临近对等方发送块，我们称这个随机的对等方为B
  - 如果从B流入的速率比n个其中的块，那么B替换其中之一，反之亦然。否则A将继续上一步
BitTorrent现在将很可能不复存在了，因为大多数用户将成为搭便车者
- 由于频宽通常会有不对称的情况，文档经常在对等端（peer）能够上传等量的字节（档案）之前用户就已经完成了下载

视频流和内容分发网

因特网视频

HTTP流和DASH
- 在HTTP流中，视频只是存储在HTTP服务器中作为一个普通的文件，每个文件有特定的URL，用户想观看的时候打开URL即可，客户端与服务器会创建一个TCP连接，并且这是一个GET请求。用户根据自己带宽的情况决定观看多清晰的视频
  - 视频质量
  - 视频的帧质量
  - 8k视频部分信息
- 服务器会以尽可能快的速率向客户端发送该视频文件。客户端收到的字节被收集在客户应用缓存中，一旦缓存的数量超过一定门限（如5秒的字节数量），应用程序就会播放视频，并且应用程序周期性从缓存中抓取帧，对帧解压缩后播放，同时继续缓存接下来的帧
- DASH，Dynamic Adaptive Streaming over HTTP，基于HTTP的动态适应流。
  在DASH中，视频被分为不同比特率的版本，根据用户的带宽动态请求来自不同版本且长度几秒的视频段数据块。带宽好则视频质量高，反正则低。
  - HTTP服务器的告示文件为每个视频版本提供了一个URL及其比特率。
    客户首先请求告示文件，然后通过HTTP GET请求报文中对每块分别指定一个 URL和字节范围，一次一块，根据接收带宽决定块的版本
  - 时间与视频质量的问题

内容分发网

直接从数据中心获取流式视频的问题
- 1、用户距离数据中心的通信链路长短不一，造成体验差距大
- 2、视频可能经过相同的通信链路发送多次，浪费带宽，视频提供商也会向ISP提供更多的费用
- 3、可靠性低，数据中心一旦出现单点故障，那么就GG了
为了应对以上的问题，几乎所有主要的视频流公司都利用内容分发网，即CDN
- CDN管理多个地理位置上的服务器，在服务器中存储视频（及其它内容）副本
- 用户请求资源的时候，试图重定向到体验最好的CDN位置
CDN通常采用的安置原则
- 1、深入，通俗来说就是尽量接近用户，减少用户和CDN服务器之间的链路和路由器的数量。高度分布式设计
- 2、邀请做客，通过少量关键位置建造大集群到 ISP，而不是将集群放在接入ISP中。通常是在IXP。
CDN集群的内容不是采用推，而是采用拉策略，因为并不是每个视频都是有人看的，所以没必要每个服务器都要有这个视频。在有客户请求的时候，再向客户流式传输视频的同时在本地存储一个副本。当集群存储器剩余空间紧迫时，会删除不常请求的视频