为什么需要有应用层?
应用层协议定义了什么?
应用层的具体内容就是精确定义上面的通信规则。具体来说,应用层协议应当定义:
应用层协议与网络应用并不是同一个概念。应用层协议只是网络应用的一部分。例如,万维网应用是一种基于客户服务器体系结构的网络应用。万维网应用包含很多部件,有万维网浏览器、万维网服务器、万维网文档的格式标准,以及一个应用层协议。万维网的应用层协议是HTTP,它定义了在万维网浏览器和万维网服务器之间传送的报文类型、格式和序列等规则。而万维网浏览器如何显示一个万维网页面,万维网服务器是用多线程还是用多进程来实现,则都不是HTTP所定义的内容。
应用层产生的报文是遵循某种协议的可读数据,比方说浏览器向服务器请求页面,发送HTTP请求报文,遵循HTTP协议;向邮件服务器发送的包含电子邮件的报文,遵循SMTP协议
应用层有什么功能?
C/S
客户端
服务器
工作流程
主要特点
P2P
P2P模型中,所有主机是平等的,任意一对计算机称为对等方(Peer),直接相互通信
优点
缺点
域名系统DNS能够把互联网上的主机名字转换为IP地址。
互联网的域名系统DNS被设计成为一个联机分布式数据库系统,采用客户服务器方式
当某一个应用进程需要把主机名解析为IP地址时,该应用进程就调用解析程序(resolver),成为DNS的一个客户,把待解析的域名放在DNS请求报文中,以UDP用户数据报方式发给本地域名服务器(使用UDP是为了减少开销)。本地域名服务器在查找域名后,把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。
域名
区 zone
根域名服务器 root name server
顶级域名服务器 TLD server
授权域名服务器
本地域名服务器 local name server
访问 qq.com 过程
如果找不到域名的对应信息,那只能说明一个问题:这个域名本来就不存在,它没有在网上正式注册过。或者域名过期了。
这也就是为什么有时候打开一个新页面会有点慢,因为如果本地没什么缓存,查找域名的过程要这样递归地查询下去,查找完还要一层层的向上返回。
概述
万维网是一个资料空间,提供分布式服务
万维网用链接的方法从互联网上的一个站点访问另一个站点,从而主动地按需获取丰富的信息
超文本
C/S方式工作
主页 homepage
网站一定是www开头的,如果不是的话,那它就不是主页(home page)
概述
互联网上的资源的地址
互联网上的所有资源,都有一个唯一确定的URL
URL格式
其它
概述
HTTP,超文本传输协议。这个协议详细规定了浏览器和万维网服务器之间互相通信的规则。
HTTP就是一个通信规则,通信规则规定了客户端发送给服务器的内容格式,也规定了服务器发送给客户端的内容格式。客户端发送给服务器的格式叫“请求协议”;服务器发送给客户端的格式叫“响应协议”。
HTTP协议本身是无连接的(通信双方在交换HTTP报文之前不需要先建立HTTP连接),但采用TCP作为运输层协议,是面向连接的
无状态协议:HTTP是无状态协议(没有记忆)。同一个用户两次访问提供完全相同的服务,服务器并不知道是否服务过这个用户,但是在实际作中一些网站常常希望能够识别用户,例如:淘宝,于是就有了cookie
两种连接方式
非持久连接
HTTP/1.0,每请求一个文档就要有两倍RTT的开销。若一个主页上有很多如图片需要依次链接,那么每一次链接下载都导致2RTT的开销(TCP连接+请求和接收文档)
持久连接
HTTP/1.1,万维网服务器在发送响应后仍然(在一段时间内,可以在服务器软件中设定这个时间)保持这条连接,使得双方能够继续在这条连接上传送报文。
工作流程
HTTP报文是面向文本的,报文中的每一个字段都是ASCII码串,因此我们在发送和得到的内容都是字节流的数据,需要进行编/解码
报文格式
请求协议的格式如下:
请求首行; // 请求方式 请求路径 协议和版本,例如:GET /index.html HTTP/1.1
请求头信息;// 请求头名称:请求头内容,即为key:value格式,例如:Host:localhost
空行; // 用来与请求体分隔开
请求体。 // GET没有请求体,只有POST有请求体。
响应协议的格式与请求相当
响应首行;
响应头信息;
空行;
响应体。
HTTP 默认的请求方法是 GET
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
数据不会出现在地址栏中
数据的大小没有上限
有请求体
请求体中如果存在中文,会使用 URL 编码
使用场景:如果要对服务器产生影响,那么使用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下载基本都是一个个片断,而且片断不一定连续,如果是机械硬盘,那么在写入硬盘的过程中就会导致硬盘频繁的调头,会造成磁盘高速马达的损耗。
上传,你的主机做种,当下载人数愈多,同一时间读取你的硬盘的人亦愈多,硬盘大量进行重复读写的动作。
对于固态硬盘来首,不存在磁头磨损,考虑擦除次数,作为基于EEPROM的Flash Memory,擦除次数大概在 1 0 5 10^5 105 级别,而且不是说使用这些次后就坏了,而是每个存储单元可达 1 0 5 10^5 105 次,一个闪存芯片有很多存储单元,而主控芯片会自动给不同的存储单元分配数据,以便分担寿命风险。p2p的这点影响,不会对固态盘造成太大影响。
不知道为什么网上这种声音很大,我反正是觉得影响没那么大,正常来说硬盘根本没法寿终正寝就该退休了。但确实P2P通信让链路承受比着C/S模式大得多的负载,所以ISP是非常反对P2P方式的。