二、应用层

在这里插入图片描述

2.1 应用层协议原理

在这里插入图片描述
可能用的应用架构：

1.C/S模式：用户增加，性能断崖式下降
在这里插入图片描述
2.P2P体系结构

3.混合体

进程通信：
进程—在主机上运行的应用程序
在同一个主机内，使用进程间通信机制通信（操作系统）
不同主机，通过交换报文（Message）来通信：客户端发起通信得进程，服务器等待连接进程。
P2P架构中也有客户端与服务器进程之分。

分布式进程通信需要解决得问题：
Q1：进程标识和寻址问题（服务用户）
Q2：传输层-应用层提供服务时如何（服务）
位置：层间界面得SAP
形式：应用程序接口API
Q3：如果使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
定义应用层协议：报文格式，解释，时序等
编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等。

Q1：对进程进行编址
进程为了接收报文，必须有一个标识：主机IP地址，传输层协议（TCP、/UDP），端口号
一个进程：用IP+port表示；
本质上，一对主机进程之间的通信由两个段节点构成

Q2：传输层提供的服务-需要穿过层间得信息
层间接口必须携带得信息：
1.

如果Socket API每次传输报文，都携带如此多得信息，太繁琐易错，不便于管理
用个代号表示通信得双方或者单方：socket
就像OS打开文件返回得句柄一样：对句柄的操作就是对文件的操作
TCP socket：

TCP服务，两个进程之间的通信需要建立连接，两个进程通信会持续一段时间，通信关系稳定
可以用一个整数表示两个应用实体之间的通信关系，本地表示
穿过层间接口的信息量最小
TCP socket：源IP，源端口，目标IP，目标端口

对于使用面向连接服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的表示：

四元组：源IP，源端口，目标IP，目标端口
唯一指定了一个会话
应用使用这个标识，与远程的应用进程通信
不必再每一个报文的发送都指定这4元组
就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名。
简单、便于管理

UDP socket：

在这里插入图片描述

Q3. 如何使用传输层提供的服务实现应用

在这里插入图片描述

2.2 Web和HTTP

Web页：有一些对象组成；
对象可以是HTML文件，图像，小程序等
Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用
通过URL对每个对象进行引用
在这里插入图片描述

HTTP：
超文本传输协议；Web应用层协议；C/S模式；
在这里插入图片描述
使用TCP：

客户发起一个与服务器的TCP连接（建立套接字），端口号为80
服务器接受客户的TCP连接
再浏览器与Web服务器交换HTTP报文
TCP连接关闭

HTTP是无状态的：服务器并不维护关于客户的任何信息
在这里插入图片描述
HTTP连接
非持久HTTP：最多只有一个对象再TCP连接上发送；下载多个对象需要更多个TCP连接；HTTP/1.0使用非持久连接
持久HTTP：多个对象可以在一个TCP连接上传输；HTTP/1.1默认使用持久连接

HTTP请求报文：
两种类型的HTTP报文：请求、响应
在这里插入图片描述

提交表单输入：
1.post方式：网页通常包括表单输入，包含在实体主体中的输入被提交到服务器
2.URL方式：方法-get，输入通过请求行的URL字段上载

HTTP/1.1：GET、PSOT、HEAD
HTTP/1.1：GET、POST、HEAD、PUT、DELETE
在这里插入图片描述

HTTP响应状态码：位于服务器-客户端的响应报文中的首行
在这里插入图片描述

用户-服务器状态：cookies
大多数主要的门户网站使用cookies
四个组成部分：

在HTTP响应报文中有一个cookis的首部行
在HTTP请求报文还有一个cookie的首部行
在用户端系统保留有一个cookie文件，由用户的浏览器管理
在Web站点有一个后端数据库

在这里插入图片描述

Web缓存（代理服务器）
目标：不访问原始服务器，就满足客户请求
用户设置浏览器，通过缓存访问Web
浏览器将所有的HTTP请求发给缓存：在缓存中的对象，缓存直接返回对象；如果对象不再缓存，缓存请求原始服务器，然后再将对象返回给客户端。
缓存既是客户端又是服务器
通常缓存是有ISP安装
为什么Web缓存：降低客户端的请求响应时间；可以大大减少一个机构内部网络与Internet接入链路上的流量；互联网大量采用了缓存，可以是较弱的ICP也能够有效提供内容。
在这里插入图片描述
解决方案：

正确解决方法：

2.3 FTP

文件传输协议：向远程主机上传输文件或从远程主机接受文件
C/S模型；ftp：RDC 959；port：21
在这里插入图片描述

2.4 Email

三个主要组成部分：用户代理；邮件服务器；简单邮件传输协议：SMTP
用户代理：又名邮件阅读器。撰写、编辑和阅读邮件。输出和输入邮件保存在服务器上
在这里插入图片描述
邮件服务器：邮箱中管理和维护发送给用户的邮件。输出报文队列保持待发送邮件报文。邮件服务器之间的SMTP协议：发送email报文

在这里插入图片描述

SMTP使用持久连接
SMTP要求报文为7位ASCII
SMTP服务器使用CRLF。CRLF决定报文的尾部

在这里插入图片描述
邮件报文格式：SMTP交换email报文的协议；RFC 822-文本报文的标准
1.首部行：To，From，Subject；与SMTP命令不同
2.主题：报文，只能是ASCII码字符

2.5 DNS

域名解析
必要性：

IP地址标识主机、路由器
但IP地址不好记忆，不便人类使用
人类一般倾向于使用一些有意义的字符串来标识设备
存在着“字符串”——IP地址得转换得必要性
人类用户提供要访问机器的“字符串”名称
由DNS负责转换成二进制得网络地址

在这里插入图片描述
DNS的主要思路：

分层的，基于域的命名机制
若干分布式的数据库完成名字到IP地址的转换
运行在UDP之上端口号为53的应用服务
核心的Internet功能，但以应用层协议实现
DNS的主要目的：
实现主机名——IP地址的转换
其他：主机别名到规范名字的转换；邮件服务器别名到邮件服务器的正规名字的转换；负载均衡

如果命名设备？
用有意义得字符串：好记、便于人类使用；层次化命名
域名结构：一个层面命名设备会有很多重名；DNS采用层次树状结构的命名方法；Internet根被划为几百个顶级域：通用的/国家的；每个域下面可划分为若干子域；树叶是主机。
在这里插入图片描述
域名：从本域往上，直到树根；中间使用“.”间隔不同的级别
域的域名：可以用于表示一个域
主机的域名：一个域上的一个主机
域名的管理：一个域管理其下的子域；创建一个新的域，必须征得他所属域的同意

域与物理网络无关：域遵从组织界限，而不是物理网络：一个域的主机可以不在一个网络，一个网络的主机不一定在一个域；域的划分是逻辑的，而不是物理的。

如何完成名字到IP地址得转换
分布式得数据库维护和相应名字查询
一个名字服务器的问题：可靠性问题-单点故障；扩展性问题-通信容量；维护问题-远距离的集中式数据库；
区域：区域的划分由区域管理者自己决定；将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分；名字服务器：每个区域都有一个名字服务器，维护它所管辖区域的权威信息。名字服务器允许被放置在区域之外，以保障可靠性。
在这里插入图片描述

（顶级域）TLD服务器：负责顶级域名和所有国家级顶级域名
区域名字服务器维护资源记录：
资源记录：-作用：维护域名IP地址的映射关系；-位置：分布式数据库中；
RR格式：

Domain_name：域名
TTl：time to live：生存时间（权威，缓冲记录）
Class类别：对于Internet，值为IN
Value值：可以是数字，域名或ASCII串
Type类别：资源记录的类型

DNS大致工作过程：

应用调用解析器
解析器作为客户向Name Server发出查询报文（封装在UDP段中）
Name Server返回响应报文（name/ip）

在这里插入图片描述
本地名字服务器（Local Name Server）：

并不严格属于层次结构
每个ISP都有一个本地DNS服务器
当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器

在这里插入图片描述

在这里插入图片描述
即本地名字服务器缓存没有的话，向上级DNS服务器查询，依次向上，然后将查询结果递归返回。

还有一种迭代查询：即，让主机自己去查询上一级DNS服务器，之前递归是，服务器一层一层往上查，这里递归是，服务器不查，只告诉主机我没有，你去上级服务器查。
在这里插入图片描述

在这里插入图片描述

提供性能：缓冲
一旦名字服务器学到了一个映射，就将该映射缓存起来；根服务器通常都在本地服务器中缓存这；如果情况变化，缓存结果和权威资源记录不一致——TTL（默认两天）也就是删除，保持一致性。

如何维护
增加或者删除一个域
在这里插入图片描述

在这里插入图片描述

2.6 P2P

纯P2P架构，没有或极少一直运行的服务器
任何端系统都可以直接通信
利用peer的服务能力
peer节点间歇上网，每次IP地址都可能变化

文件分发：C/S vs P2P
问题:从一台服务器分发文件到N个peer需要多少时间？
在这里插入图片描述

随着N线性增大

在这里插入图片描述

1。非结构化P2P
a。集中化目录
在这里插入图片描述

在这里插入图片描述
两大问题：

如何让定位所需资源
如何处理对等方的加入和离开

可能的方案：集中；分散；半分散

集中式目录存在的问题：单点故障；性能瓶颈；侵犯版权

b。完全分布式
在这里插入图片描述

c。混合体

P2P文件分发：BitTorrent
文件被分为一个个块256KB
网络中的这些peers发送接受文件块，相互服务
tracker：跟踪torrent中参与节点
torrent：节点的组，之间交换文件块

2 。结构化（DHT）P2P
哈希表；DHT方案；唤醒DHT以及覆盖网络；Peer波动；

2.7CDN

在这里插入图片描述

CBR：以固定速率编码
VBR：视频编码速率随时间变化而变化

存储视频的流化服务：
多媒体流化服务：DASH-在HTTP上的动态自适应流化服务
服务器：将视频文件分割成多个块。每个块单独存储，编码于不同码率。告示文件：提供不同块的URL。
客户端：先获取告示文件。周期性地测量服务器到客户端的带宽。查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围：如果带宽足够，选择最大码率的视频快，会话中的不同时刻，可以切换请求不同的编码块
在这里插入图片描述
Q1：服务器如何通过网络向上百万用户同时流化视频内容？
1—单个的、大的超级服务中心？

2----通过CDN，全网部署缓存节点，存储服务内容，就近为用户体统服务，提高用户体验。

2.8 TCP套接字编程

Socket编程：
应用进程使用传输层提供的服务才能够交换报文，实现应用协议，实现应用
TCP/IP：应用进程使用Socket API访问传输服务
地点：界面上的SAP（Socket）方式：Socket API
目标：学习如何构建能够借助sockets进行通信的c/S应用程序
socket：分布式应用进程之间的门，传输层协议提供的端到端服务接口
在这里插入图片描述
两种传输层服务的socket类型：
tcp：可靠的、字节流的服务
ucp：不可靠（数据UDP数据报）服务

TCP套接字编程：
套接字：应用进程与端到端传输协议之间的门户
TCP服务：从一个进程向另一个进程可靠的传输字节流

服务器首先运行，等待连接建立
1：服务器进程必须先处于运行状态：
创建欢迎socket
和本地端口捆绑
在欢迎socket上阻塞式等待接收用户的连接
客户端主动和服务器建立连接
2：创建客户端本地套接字（隐式捆绑到本地port）
指定服务器进程地IP地址和端口号，与服务器进程连接
3：当与客户端连接请求到来时
服务器接受来自用户端的请求，解除阻塞式等待，返回一个新的socket（与欢迎socket不一样），与客户端通信
允许服务器与多个客户端通信
使用源IP和源端口来区分不同的个客户端
4：连接API调用有效时，客户端与服务器建立了TCP连接

从应用程序的角度：TCP在客户端和服务器进程之间提供了可靠的，字节流（管道）服务
在这里插入图片描述