计算机网络（六）应用层

应用层概述

概览

为什么需要有应用层？

• 运输层仅为应用进程提供了端到端的通信服务。但不同的网络应用的应用进程之间，还需要有不同的通信规则，因此还需要有应用层协议

应用层协议定义了什么？

• 应用层的具体内容就是精确定义上面的通信规则。具体来说，应用层协议应当定义：

  • 应用进程交换的报文类型，如请求报文和响应报文
  • 各种报文类型的语法，如报文中的各个字段及其详细描述
  • 字段的语义，即包含在字段中的信息的含义。
  • 进程何时、如何发送报文，以及对报文进行响应的规则。

• 应用层协议与网络应用并不是同一个概念。应用层协议只是网络应用的一部分。例如，万维网应用是一种基于客户服务器体系结构的网络应用。万维网应用包含很多部件，有万维网浏览器、万维网服务器、万维网文档的格式标准，以及一个应用层协议。万维网的应用层协议是HTTP，它定义了在万维网浏览器和万维网服务器之间传送的报文类型、格式和序列等规则。而万维网浏览器如何显示一个万维网页面，万维网服务器是用多线程还是用多进程来实现，则都不是HTTP所定义的内容。

应用层产生的报文是遵循某种协议的可读数据，比方说浏览器向服务器请求页面，发送HTTP请求报文，遵循HTTP协议；向邮件服务器发送的包含电子邮件的报文，遵循SMTP协议

应用层有什么功能？

• 文件传输、访问和管理
• 电子邮件
• 虚拟终端
• 查询服务和远程作业登录
• ……

网络应用模型

C/S

• 客户端

  • 与服务器通信，使用服务器提供的服务
  • 间歇性接入网络
  • 可能使用动态IP地址
  • 客户程序必须知道服务器程序的地址

• 服务器

  • 永久提供服务
  • 永久性访问地址/域名
  • 服务器程序不需要知道客户程序的地址

• 工作流程

  • 服务器处于接收请求的状态
  • 客户机发出服务请求，并等待接收结果。
  • 服务器收到请求后，分析请求，进行必要的处理，得到结果并发送给客户机。

• 主要特点

  • 网络中各计算机的地位不平等，服务器可以通过对用户权限的限制来达到管理客户机的目的。
  • 客户机相互之间不直接通信。
  • 可扩展性不佳。受服务器硬件和网络带宽的限制，服务器支持的客户机数有限。

P2P

P2P模型中，所有主机是平等的，任意一对计算机称为对等方(Peer)，直接相互通信

• 优点

  • 减轻了服务器的计算压力，消除了对某个服务器的完全依赖，大大提高了系统效率和资源利用率
  • 多个客户机之间可以直接共享文档
  • 可扩展性好，传统服务器有响应和带宽的限制，因此只能接受一定数量的请求
  • 网络健壮性强，单个结点的失效不会影响其他部分的结点

• 缺点

  • 在获取服务的同时，还要给其他结点提供服务，会占用较多的内存影响整机速度

DNS

概述

域名系统DNS能够把互联网上的主机名字转换为IP地址。

互联网的域名系统DNS被设计成为一个联机分布式数据库系统，采用客户服务器方式

当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序(resolver)，成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器(使用UDP是为了减少开销)。本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。

• 若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。

域名解析

域名

域名服务器

• 区 zone

  • 一个域名服务器所负责管辖的（或有权限的）范围称为区，区可能小于等于域，但一定不能大于域。

  • qq.com，下属划分了 v.qq.com, news.qq.com 等区

  • DNS划分区的举例

    

• 根域名服务器 root name server

  • 根域名服务器是最高层次的域名服务器，也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。不管是哪一个本地域名服务器，只要自己无法解析，就首先要求助于根域名服务器。假定所有的根域名服务器都瘫痪了，那么整个互联网中的DNS系统就无法工作。
  • 根域名服务器却只使用13个不同IP地址的域名，即 a. rootservers.net, b. rootservers net，， m.rootservers net。现在世界上大部分DNS域名服务器，都能就近找到一个根域名服务器查询IP地址
  • https://www.iana.org/domains/root/servers

• 顶级域名服务器 TLD server

  • 这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS查询请求时，就给出相应的回答（可能是最后的结果，也可能是下一步应当找的域名服务器的IP地址）

• 授权域名服务器

  • 每台主机都必须在授权域名服务器处登记。 当一个权限域名服务器还不能给出最后的查询回答时，就会告诉发出查询请求的 DNS 客户，下一步应当找哪一个权限域名服务器
  • 在哪注册，授权域名服务器就由谁负责配置管理

• 本地域名服务器 local name server

  • 本地域名服务器对域名系统非常重要。 当一个主机发出 DNS 查询请求时，这个查询请求报文就发送给本地域名服务器。 每一个因特网服务提供者 ISP，或一个大学，甚至一个大学里的系，都可以拥有一个本地域名服务器， 这种域名服务器有时也称为默认域名服务器。
  • 本地域名服务器离用户较近，一般不超过几个路由器的距离。当所要査询的主机也属于同一个本地ISP时，该本地域名服务器立即就能将所查询的主机名转换为它的IP地址，而不需要再去询问其他的域名服务器。

解析过程

访问 qq.com 过程

1. 浏览器缓存：浏览器会按照一定的频率缓存DNS记录。
2. 操作系统缓存：hosts的文件，如果在这里指定了一个域名对应的ip地址，那浏览器会首先使用这个ip地址。
3. 至此还没有命中，才会请求本地域名服务器来解析这个域名，这台服务器一般在你的城市的某个角落，距离你不会很远，并且这台服务器的性能都很好，一般都会缓存域名解析结果，大约80%的域名解析到这里就完成了。
4. 如果本地域名服务器然没有命中，就直接跳到根域名服务器域名服务器请求解析
5. 根域名服务器返回给本地域名服务器 com 顶尖域名服务器的地址
6. 接受请求的 com 顶尖域名服务器查找并返回存储 qq.com 域名的权限域名服务器地址，网站在哪注册，这权限域名服务器就是谁负责部署管理，本地域名服务器再去找到这个权限域名服务器
   • 如果是 news.qq.com ，则有多步权限域名服务器，最后一层权限域名服务器的查询工作就由负责 qq.com 的部门来完成
7. 权限域名服务器根据映射关系表找到目标ip，返回给LDNS
8. LDNS缓存这个域名和对应的ip
9. LDNS把解析的结果返回给用户，用户将值缓存到本地系统缓存中，域名解析过程至此结束

如果找不到域名的对应信息，那只能说明一个问题：这个域名本来就不存在，它没有在网上正式注册过。或者域名过期了。

这也就是为什么有时候打开一个新页面会有点慢，因为如果本地没什么缓存，查找域名的过程要这样递归地查询下去，查找完还要一层层的向上返回。

FTP

电子邮件

万维网

万维网 WWW

概述

• 万维网是一个资料空间，提供分布式服务

• 万维网用链接的方法从互联网上的一个站点访问另一个站点，从而主动地按需获取丰富的信息

• 超文本

  • 指包含指向其他文档的链接的文本
  • 超文本是万维网的基础

• C/S方式工作

  • 浏览器是客户程序。万维网文档所驻留的主机称为万维网服务器
  • 客户程序向服务器程序发出请求，服务器程序向客户程序送回客户所要的万维网文档。在一个客户程序主窗口上显示出的万维网文档称为页面（page）

主页 homepage

• 网站一定是www开头的，如果不是的话，那它就不是主页(home page)

  • 腾讯主页 www.qq.com
  • 腾讯视频主页 v.qq.com
  • 腾讯新闻主页 news.qq.com

统一资源定位符 URL

概述

• 互联网上的资源的地址

  • 只有知道了这个资源在互联网上的什么地方，才能对它进行操作

• 互联网上的所有资源，都有一个唯一确定的URL

URL格式

• <协议>://<主机>:<端口>/<路径>

其它

• 端口、路径、协议、甚至www一般可省略
• 协议一般就是HTTP、FTP
• URL里面的字母不分大小写，但为了便于阅读，有时故意使用一些大写字母。

超文本传输协议 HTTP

HTTP概述

概述

• HTTP，超文本传输协议。这个协议详细规定了浏览器和万维网服务器之间互相通信的规则。

• HTTP就是一个通信规则，通信规则规定了客户端发送给服务器的内容格式，也规定了服务器发送给客户端的内容格式。客户端发送给服务器的格式叫“请求协议”；服务器发送给客户端的格式叫“响应协议”。

• HTTP协议本身是无连接的（通信双方在交换HTTP报文之前不需要先建立HTTP连接），但采用TCP作为运输层协议，是面向连接的

• 无状态协议：HTTP是无状态协议（没有记忆）。同一个用户两次访问提供完全相同的服务，服务器并不知道是否服务过这个用户，但是在实际作中一些网站常常希望能够识别用户，例如：淘宝，于是就有了cookie

两种连接方式

• 非持久连接

  HTTP/1.0，每请求一个文档就要有两倍RTT的开销。若一个主页上有很多如图片需要依次链接，那么每一次链接下载都导致2RTT的开销（TCP连接+请求和接收文档）

• 持久连接

  HTTP/1.1，万维网服务器在发送响应后仍然（在一段时间内，可以在服务器软件中设定这个时间）保持这条连接，使得双方能够继续在这条连接上传送报文。

工作流程

• 浏览器分析URL
• 浏览器向DNS请求解析IP地址
• DNS解析出IP地址
• 浏览器与服务器建立TCP连接
• 浏览器发出HTTP请求：GET/chn/index.htm
• 服务器通过HTTP响应把文件index.htm发送给浏览器
• 释放TCP连接
• 浏览器解析文件 index htm，并将Web页显示给用户

HTTP报文

HTTP报文是面向文本的，报文中的每一个字段都是ASCII码串，因此我们在发送和得到的内容都是字节流的数据，需要进行编/解码

报文格式

请求协议的格式如下：

请求首行； // 请求方式 请求路径 协议和版本，例如：GET /index.html HTTP/1.1
请求头信息；// 请求头名称:请求头内容，即为key:value格式，例如：Host:localhost
空行； // 用来与请求体分隔开
请求体。 // GET没有请求体，只有POST有请求体。

响应协议的格式与请求相当

响应首行；
响应头信息；
空行；
响应体。

一点探究

使用Chrome开发者工具测试 GET 与 POST 请求

GET请求

HTTP 默认的请求方法是 GET

1. 没有请求体

2. 数据必须在 1K 之内

3. GET 请求数据会显示在 URL（地址栏）中，get请求传参是放在ur1中，并且是通过？'的形式来指定key和 value的

   

GET 请求常用的操作：

1. 在浏览器的地址栏中直接给出 URL，那么就一定是 GET 请求
2. 点击页面上的超链接也一定是 GET 请求
3. 提交 Form 表单时，表单默认使用 GET 请求，但可以设置为 POST【如果只对服务器获取数据，并没有对服务器产生任何影响，那么这时候使用get请求】

客户端请求

访问 www.baidu.com 在 Chrome 中看到的请求报文如下：

GET / HTTP/1.1 #GET请求 协议为 HTTP 1.1
Host: www.baidu.com # 请求的主机名（服务器）为 www.baidu.com
Connection: keep-alive # 连接方式：持续连接
Cache-Control: max-age=0 
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36 # 用户代理，浏览器相关信息
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9  #告诉服务器，当前客户端可以接收的文档类型，这里包含了*/*，就表示什么都可以接收
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br #支持的压缩格式。数据在网络上传递时，可能服务器会把数据压缩后再发送
Accept-Language: zh-CN,zh;q=0.9 #当前客户端支持的语言，可以在浏览器的工具选项中找到语言相关信息
Cookie: BAIDUID=7A21E206C60C7B89DC863B8A19225C56:FG=1; BIDUPSID=7A21E206C60C7B89DC863B8A19225C56; PSTM=1586681198; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; BD_UPN=12314753; BDUSS=ms5N2pmQkRvalNPeHZGNW1rSkswc0lqYzFZMzNta1ZKTS1BQzRkS2FWWHoyUUZmSVFBQUFBJCQAAAAAAAAAAAEAAAADxrAzX7bAsK7j8ePxX-PxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPNM2l7zTNpee; yjs_js_security_passport=e36790683834f1443eeb3ad0523cbe26c1fe90cc_1594631274_js; bdindexid=jjiujtk4559r2oqkt9nht20p30; ispeed_lsm=0; BD_HOME=1; H_PS_PSSID=1445_31326_32140_31254_32046_32231_31322_32297_31640 # 因为不是第一次访问这个地址，主机返回给服务器 Cookie

服务器响应

响应内容是由服务器发送给浏览器的内容，浏览器会根据响应内容来解析显示

响应头

HTTP/1.1 200 OK # 协议为HTTP1.1 状态码为200，表示请求成功，OK是对状态码的解释
Bdpagetype: 2
Bdqid: 0x99338ed500202c0c
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Tue, 14 Jul 2020 07:52:42 GMT #响应的时间 格林尼治时间
Expires: Tue, 14 Jul 2020 07:52:41 GMT
Server: BWS/1.1 # 服务器的版本信息
Set-Cookie: BDSVRTM=563; path=/ # 响应给客户端的Cookie
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=1445_31326_32140_31254_32046_32231_31322_32297_31640; path=/; domain=.baidu.com 
Strict-Transport-Security: max-age=172800
Traceid: 1594713162050663834611039324157096504332
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

POST请求

1. 数据不会出现在地址栏中

2. 数据的大小没有上限

3. 有请求体

4. 请求体中如果存在中文，会使用 URL 编码

5. 使用场景：如果要对服务器产生影响，那么使用post请求。

   传参：post请求传参不是放在url中，是通过 form data的形式发送给服务器的。

客户端请求

在百度翻译进行如下测试

Request Headers

:authority: fanyi.baidu.com
:method: POST
:path: /v2transapi?from=en&to=zh
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
content-length: 118 #表单的数据长度
content-type: application/x-www-form-urlencoded; charset=UTF-8 #POST请求方式中表单的数据类型
cookie: ...
origin: https://fanyi.baidu.com
referer: https://fanyi.baidu.com/?aldtype=16047 #请求来自哪个页面，如果是在浏览器的地址栏中直接输入的地址，那么就没有Referer这个请求头了，可以用来做统计工作和防盗链
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
x-requested-with: XMLHttpRequest

Form Data

from: en
to: zh
query: python
simple_means_flag: 3
sign: 477811.239938
token: 17bd3eee96d5d8602249b5a123eb281c
domain: common

服务器响应

响应头

响应实体

P2P下载损伤硬盘？

在网络上看到的观点如下：

• 关于下载，因为有很多人给你做种，P2P下载基本都是一个个片断，而且片断不一定连续，如果是机械硬盘，那么在写入硬盘的过程中就会导致硬盘频繁的调头，会造成磁盘高速马达的损耗。

  • 我不是很认可这个观点，因为磁盘对于普通文件采取的是离散分配方式，就是说文件一般不会存储在物理上连续的磁盘块，正常写入一个文件，磁头都是要跑来跑去的

• 上传，你的主机做种，当下载人数愈多，同一时间读取你的硬盘的人亦愈多，硬盘大量进行重复读写的动作。

  • 这个是合理的，但是只要我不24小时挂P2P就没那么大影响

• 对于固态硬盘来首，不存在磁头磨损，考虑擦除次数，作为基于EEPROM的Flash Memory，擦除次数大概在 $10^5$ 级别，而且不是说使用这些次后就坏了，而是每个存储单元可达 $10^5$ 次，一个闪存芯片有很多存储单元，而主控芯片会自动给不同的存储单元分配数据，以便分担寿命风险。p2p的这点影响，不会对固态盘造成太大影响。

• 不知道为什么网上这种声音很大，我反正是觉得影响没那么大，正常来说硬盘根本没法寿终正寝就该退休了。但确实P2P通信让链路承受比着C/S模式大得多的负载，所以ISP是非常反对P2P方式的。