版权声明:本文为博主原创文章,未经博主允许不得转载。
第二章 应用层
Tags: 计算机网络
2.1 应用层协议原理
- 应用层协议只能运行在端系统,这种限制促进了应用程序的开发,即不用考虑底层网络核心的实现。
2.1.1 网络应用程序体系结构
-
两种主流 应用程序体系结构:
-
客户-服务器体系结构(CS)
- 有一个总是打开的主机称为服务器,它服务于来自许多其他称为客户的主机的请求。
- 客户之间不直接通信。
- 该服务器具有固定的 IP 地址。
-
P2P 体系结构
- 应用程序在间断的主机对之间进行直接通信,这些主机对被称为对等方。
-
2.1.2 进程通信
-
客户和服务器进程
- 网络应用程序有成对的进程组成,在两个不同端系统上的 进程,通过跨越计算机网络交换 报文(message)。
- 通常将两个进程之一标识为 客户,另一个标识为 服务器。
- 在给定的一对进程之间的通信会话场景中,发起通信的进程被标识为 客户,在会话开始时等待联系的进程是 服务器。
-
进程与计算机网络之间的接口
- 进程必须通过一个称为 套接字(socket) 的软件接口向网络发送和接收报文。
- 在发送端的应用程序将报文推进该套接字,在套接字另一侧,运输层协议负责使该报文进入接收进程的套接字。
- 套接字也被称为应用程序和网络之间的应用程序编程接口。
- 开发者可以控制套接字在应用层端的一切,但是对该套接字的运输层端几乎没有控制权,除了:1. 选择运输层协议(如果可供选择的话);2. 也许能设定几个运输层参数,如最大缓存和最大报文段长度。
-
进程寻址
- 一台主机的进程向另一台主机的进程发送分组,接收进程需要一个地址。为了标识该进程,需要定义两种信息:
-
- 主机的地址:用 IP地址 标识;
-
- 定义在目标主机中的接收进程的标识符:用目的地 端口号 标识。
2.1.3 可供应用程序使用的运输服务
- 根据运输层协议为应用层程序提供的服务,按下列要求进行分类:
-
可靠数据传输
是否容忍数据丢失 -
吞吐量
应用程序是否对吞吐量有特定的要求,若是,则称为带宽敏感的应用,否则称为弹性应用。 -
定时
对时延的要求 - 安全性
-
可靠数据传输
2.1.4 因特网提供的运输服务
-
TCP 服务
- TCP 服务模型包括:
- 面向连接的服务:在应用层数据报文开始流动之前,TCP 让客户和服务器互相交换运输层控制信息,即握手阶段。之后,一条 全双工 的 TCP 连接 就在两个进程的套接字之间建立了。应用程序结束发送报文时,则拆除该连接。
- 可靠的数据传送服务:通信进程能够依靠 TCP,无差错、按适当顺序交付所有发送的数据。
- TCP 协议还具有 拥塞控制机制:
- 当发送方和接收方之间的网络出现拥塞时,TCP 的拥塞控制机制会抑制发送进程。
- TCP 拥塞控制机制也试图限制每个 TCP 连接,使他们达到公平共享网络带宽的目的。
- 这种服务不一定为通信进程带来直接好处,但是能为因特网带来整体好处。
- TCP 服务模型包括:
-
UDP 服务
- UDP 是一种不提供不必要服务的轻量级运输协议,它仅提供最小服务。
- UDP 是无连接的,因此在两个进程通信之前无握手。
- UDP 协议提供一种不可靠数据传送服务,也就是说,当进程将一个报文发送进 UDP 套接字时,UDP 并不 保证该报文到达接收进程。不仅如此,到达接收进程的报文也可能是乱序到达的。
- UDP 没有包括拥塞控制机制,所以 UDP 的发送端可以用它选定的任何速率向其下层(网络层)注入数据。
-
因特网运输协议所不提供的服务
- TCP 能提供可靠的数据传输服务,也能通过 SSL 来加强以提供安全服务。
- 今天的因特网通常能够为时间敏感应用提供满意的服务,但不能提供任何定时或带宽保证。
2.1.5 应用层协议
- 应用层协议定义了运行在不同端系统上的进程如何相互传递报文。
- 交换报文的类型,例如请求报文和响应报文。
- 各种报文类型的语法,如报文中各个字段及这些字段是如何描述的。
- 字段的语义,即这些字段中包含的信息的含义。
- 一个进程何时以及如何发送报文,对报文进行响应的规划。
2.2 Web 和 HTTP
2.2.1 HTTP 概况
- Web 的应用层协议是 超文本传输协议(HTTP),它是 Web 的核心。
- HTTP 由两个程序实现:一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中,通过交换 HTTP 报文进行会话。
- HTTP 使用 TCP 作为它的支撑运输协议。
客户首先发起一个与服务器的 TCP 连接。一旦该连接建立,该浏览器和服务器进程就可以通过套接字接口访问 TCP。 - HTTP 是一个 无状态协议。服务器向客户发送被请求的文件,而 不存储 任何该客户的状态信息。
- Web 使用了 客户-服务器应用程序体系结构。
2.2.2 非持续连接和持续连接
-
非持续连接
- 应用程序在采用非持续连接的情况下,客户的每个请求都要建立一个单独的 TCP 连接。
- 简单估算一下从客户请求 HTML 文件到客户收到文件为止所花费的时间。
- 下图中,往返时间(RTT):一个短分组从客户到服务器然后再返回客户所花费的时间。
- 因此,粗略的讲,总的响应时间就是两个 RTT 加上服务器传输 HTML 文件的时间。
- 下图中,往返时间(RTT):一个短分组从客户到服务器然后再返回客户所花费的时间。
-
持续连接
- 在采用持续连接的情况下,服务器再发送响应后保持该 TCP 连接打开。再相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。
- 一般来说,如果一条连接经过一定的时间间隔(一个可配置的时间间隔)仍未被使用,HTTP 服务器就关闭该连接。
- HTTP 的默认模式是使用带流水线的持续连接。
2.2.3 HTTP 报文格式
- HTTP 请求报文
GET /boyfriend/memory.html HTTP/1.1
Host: www.xinxin.org
Connection: close
User-agent: Chrome/57.0
Accept-language: ch
- 1
- 2
- 3
- 4
- 5
- 一个请求报文可以具有更多的行或者至少位一行。
-
第一行叫做 请求行,其后继的行叫做 首部行。
- 请求行有三个字段:
-
方法字段:包括
GET
、POST
、HEAD
、PUT
和DELETE
。绝大部分报文使用GET
方法。 - URL 字段
- HTTP 版本字段
-
方法字段:包括
- 首部行
Host: www.xinxin.org
指明了对象所在的主机。 - 首部行
Connection: close
要求服务器发送完请求的对象后就关闭该连接。 - 首部行
User-agent: Chrome/57.0
用来指明用户代理,即向服务器发送请求的浏览器的类型。 - 首部行
Accept-language: ch
指明了用户想要得到该对象的中文版本。
- 请求行有三个字段:
-
下图是请求报文的通用格式
-
首部行后面的 实体体(Entity body),在使用
GET
方法时为空,使用POST
方法时才使用该实体体。- HTTP 响应报文
对前一个栗子的响应报文:
- HTTP 响应报文
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ......)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 响应报文分为三个部分:
-
- 一个初始 状态行
- 状态行有三个字段:版本协议字段、状态码和相应状态信息。
- 下表包括了一些常用的状态码和相关短语
- 一个初始 状态行
-
状态码 | 状态信息 | 含义 |
---|---|---|
200 | OK | 请求成功,信息在返回的响应报文中 |
301 | Moved Permanetly | 请求的对象已经被永久转移了,新的 URL 定义在相应报文的 Location:首部行中。客户软件将自动获取新的 URL。 |
400 | Bad Request | 一个通用差错代码,指示该请求不能被服务器理解 |
404 | Not Found | 请求的文档不在服务器上 |
505 | HTTP Version Not Supported | 服务器不支持请求报文使用的 HTTP 协议版本 |
- 6 个 首部行
就是字面意思,参考上一个栗子的解释。 - 实体体
下图是响应报文的通用格式
2.2.4 用户与服务器的交互:cookie
- HTTP 是无状态的,但是 Web 站点通常希望能够识别用户,为此,HTTP 使用了 cookie,它允许站点对用户进行跟踪。
- cookie 有 4 个技术组件:
- 在 HTTP 响应报文中的一个 cookie 首部行;
- 在 HTTP 请求报文中的一个 cookie 首部行;
- 在用户端系统中保留有一个 cookie 文件,并由用户的浏览器进行管理;
- 位于 Web 站点的一个后端数据库。
-
cookie 的工作过程如下图
2.2.5 Web 缓存
- Web 缓存器也叫 代理服务器,是能够代表 Web 服务器来满足 HTTP 请求的网络实体。
- Web 服务器有自己的磁盘存储空间,并在存储空间中保存着最近存储过的对象的副本。
- 可以配置用户的浏览器,使得用户所有的 HTTP 请求首先指向 Web 缓存器。
- 客户与 Web 缓存器之间的速度通常比较快,所以可以提高访问的速度,降低时延。
- 客户通过 Web 缓存器请求对象
2.2.6 条件 GET 方法
- 用来解决 Web 缓存器中的副本可能是旧的的问题。
- 若同时满足一下两点的则称为 条件 GET 方法:
-
- 请求报文使用 GET 方法。
-
- 请求报文中包含一个
If-Modified-Since:
首部行。
- 请求报文中包含一个
-
- 举个栗子,当一个条件 GET 的首部中包含
If-Modified-Since:wed,7,Sep 2011 09:23:24
,该条件 GET 告诉服务器,仅当自该日期后该对象被修改过,才发送该对象。若没有被修改过,服务器仍发送一个响应报文,但并不会在报文中包含所请求的对象,它告诉缓存器可以使用其本地的对象。
2.4 因特网中的电子邮件
- 电子邮件系统有 3 个主要组成部分:
- 用户代理
- 邮件服务器
-
简单邮件传输协议
2.4.1 SMTP
- SMTP 是因特网中电子邮件中主要的应用层协议。它使用 TCP 可靠数据传输。
- SMTP 限制所有的邮件报文只能采用简单的 7 比特 ASCII 表示。
- 一个简单的邮件发送过程是:从发送方的用户代理开始,传输到发送方的邮件服务器,再传输到接收方的邮件服务器,然后在这里被分发到接收方的邮箱上。如下图。
-
如果 Bob 的邮件服务器没有开机,该报文会保留在 Alice 的邮件服务器上并尝试进行新的尝试。这意味着邮件并不会在中间的某个邮件服务器存留。 - 注意:SMTP 一般不使用中间服务器发送邮件,即使这两个邮件服务器位于地球的两端也一样。
- SMTP 用的是 持续链接:如果发送邮件服务器有几个报文发往同一个接收邮件服务器,它可以通过同一个 TCP 连接发送所有的的报文。
2.4.2 与 HTTP 的对比
- 相同点:
- 都用于从一台主机向另一台主机传送文件。
- 都使用持续连接。
- 不同点:
- HTTP 是一个 拉协议,TCP 连接是由想要接收文件的机器发起的。SMTP 是一个 推协议,TCP连接是由想要发送文件的机器发起的。
- SMTP 要求报文必须按照 7 比特 ASCII 码进行编码。HTTP 则没有这种限制。
- 在处理包含多种不同类型的文档时。HTTP 把每个对象封装到它自己的 HTTP 响应报文中,SMTP 则把所有报文对象放在一个报文中。
2.4.4 邮件访问协议
- POP3
- IMAP
- 基于 Web 的电子邮件
2.5 DNS:因特网的目录服务
2.5.1 DNS 提供的服务
- 主机可以使用 主机名 和 IP 地址 进行标识。
- DNS 提供从主机名到IP地址的目录服务。
- DNS 即 域名系统是:
- 一个由分层的 DNS 服务器 实现的分布式数据库。
- 一个使得主机能够查询分布式数据库的应用层协议。
- DNS 协议运行在 UDP 上,使用 53 端口。
- DNS 通常是由其他应用层协议所使用的,包括 HTTP,SMTP 和 FTP,将用户的主机名解析为 IP 地址。
- DNS 还提供了一些重要的服务:
- 主机别名
- 邮件服务器别名
- 负载分配
2.5.2 DNS 工作机理概述
-
分布式、层次数据库
- 有三种类型的 DNS 服务器:
- 根 DNS 服务器
-
因特网上的主机的标识有2种方式
1、 主机名,如www.baidu.com
2、 IP地址,如xxx.xxx.xxx.xxx这两种标识其实指代的是同一样东西,就如你父亲叫你全名和叫你儿子是一样的一个道理。那为什么需要2种标识呢?
因为我们人类喜欢主机名这种便于记忆的标识,而对路由器来说,它更喜欢定长的、有层次结构的IP地址。我们在浏览器的地址上输入网址时都是输入其主机号。所以我们需要一种能进行主机名到IP地址转换的服务,也就是域名系统(Domain Name System,DNS)。DNS协议运行在UDP上,使用53号端口。
DNS也是应用层协议,它通常会被其他应用层协议所使用,包括HTTP、SMTP和FTP。
DNS除了将主机名转换为IP地址,还有以下服务
1、识别主机别名(用于HTTP、FTP)
2、识别邮件服务器别名(用于SMTP)
3、负载分配DNS服务器采用分布式、层次数据库
DNS缓存
与Web缓存器一样,DNS服务器同样有缓存器。
P2P体系结构
相比于客户-服务器体系结构,P2P具有自扩展性,表现在对等方N越大,最小分发时间也趋于平缓。这种自扩展性的直接成因是:对等方除了是比特的消费者外还是它们的重新分发者。
安全性
- DDoS(分布式拒绝服务)带宽泛洪攻击:向处理如.com域的域名服务器发送大量DNS请求,使得大部分合法请求无法获得响应
- DNS毒害(污染):给你返回假的或不能用的IP地址。比如中国的『墙』。所以如果你能拿到google的当前IP地址(百度搜的到),手动在hosts里配置,是可以做到直接访问谷歌服务器的。说到*,一般大家都是用某种方法配置一台海外服务器当做中转(国家一般不墙这种个人服务器),来访问墙外服务器的,比如*,shadowrocket之类的软件可以用来配置中转服务器。
- DNS反射攻击:请求中冒充目标主机源地址,大量请求DNS服务器,DNS就大量向源地址主机发送回答,淹没目标主机
P2P应用
P2P文件分发
- 在P2P文件分发中,每个对等方能重新分发它所有的该文件的任何部分,可以协助服务器分发
-
P2P体系结构的扩展性
- 最小分发时间,对等方N越大,P2P的最小分发时间越小
- 对等方除了是比特的消费者外还是他们的重新分发者
-
BitTorrent(没错就是你们老用的种子)
- P2P文件共享协议,参与一个特定文件分发的所有对等方结合被称为一个洪流(torrent),在一个洪流的对等方彼此下载等长度的文件块,可以随时离开洪流,也可继续向其他对等方上载
- Alice加入某洪流时,会在追踪器里进行注册,周期性通知追踪器它仍在洪流中。
- 洪流随机从参与对等方的结合中选择一个子集,将他们的IP地址发给Alice,Alice维护这张对等方列表,视图与所有对等方建立并行的TCP连接。
- Alice周期询问每个邻近对等方(连上的)他们有的文件块列表,她随时知道邻居有哪些文件块
- Alice使用最稀缺优先技术,首先请求那些邻居们副本数量最少的块,使该文件块迅速分发,以均衡每个块在洪流中的副本数量
- BitTorrent使用一种算法,Alice优先从像她传时速度最快的邻居(4个,每10s修改一次)那里获取文件块。
- 每过30s,Alice也要随机选择另外一个对等方Bob,向他发送块。若Alice是Bob最快的前四快,Bob也是Alice的前4快,则Bob和Alice互相发送数据。
- 每过30s换一个新的对象,互相交换数据(一报还一报),为了使对等方能够找到彼此协调的速率上传
-
BitTorrent其他机制和变种
- 片、流水线、随机优先选择、残局模型、反怠慢等机制
- 变种:P2P直播流式应用,如PPLive和PPstream
分布式散列表(DHT)
- 分布式、P2P版本的key-value数据库,在大量对等方上存储key-value值(键值对)
- 分布式数据库用来定位拥有某key-value的对等方,然后向查询方返回该键值对
- 环形DHT、对等方扰动(了解即可)
微信公众号【黄小斜】大厂程序员,互联网行业新知,终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」 等关键字可以获取对应的免费学习资料。