应用层小结(1万多字+50张图)

目录

概念

两种格式

应用层协议的定义

应用层体系结构

客户-服务器体系结构

对等体系结构

万维网

概述

URL

万维网文档

html

 css

Javascript

HTTP

HTTP连接行为

HTTP1.0

HTTP1.1

HTTP报文格式

请求报文

 响应报文

HTTP协议特征

cookie和session

Web缓存

DNS协议

概述

DNS系统结构

域名结构

域名服务器

DNS查询步骤

iee.com.cn/

 DNS查询类型

递归查询

迭代查询

缓存查询

DHCP

概述

流程

HTTP2.0/3.0

最初的HTTP

1.0的问题

 SPDY

HTTP2.0

HTTP3.0

结束语


概念

应⽤层是计算机⽹络体系结构的最顶层,是设计和建⽴计算机⽹络的最终⽬的,也是计算机⽹络中 发展最快的部分。

两种格式

文本格式:将值作为字符后存入其字符编码的二进制。

二进制格式:二进制文件格式存储数据时直接保存该值在二进制下的值。

关于文本格式、二进制格式建议看看这篇

为什么要有这两种格式呢?

我们考虑,在网络传输过程中,用文本格式现不现实。

如果我为了表达信息size:1234       用文本格式则需要将每个字符表示出来。

一共有9个字符   需要9个字节(B)

而如果用二进制表示出该数1234,并且我们定义格式,某某某位置就是size。

那么2的16次方(也就是2个字节)能表示65535个数。

此时空间大大节省。

由于我们的数据在传输上需要考虑传输的效率--》大小和速度。采用二进制可以更快传输。

最小单位适合bit。

而我们的应用层,是给人看的,是业务数据,文本格式居多,最小单位适合字节。

Telnet:远程登录协议      SSH

FTP:文件传输协议         SFTP

HTTP:超文本传输协议   HTTPS

应用层协议的定义

应⽤层协议 (application layer protocol) 定义了在不同端系统上应⽤程序是如何相互传输报⽂的。 ⼀般来说,应⽤层协议会规定如下内容:

交换的报⽂类型:交换的是请求报⽂还是响应报⽂。

报⽂字段的解释:对报⽂中各个字段的详细描述。

报⽂字段的语义:报⽂各个字段的含义是什么。

报⽂交换时间、⽅式:程序何时、以什么⽅式发送报⽂以及响应。

直⽩⼀点来说,应⽤层只是产⽣和使⽤数据的逻辑层,在这⼀层次我们并不会关⼼它们是如何发送 数据的以及数据发到哪⾥。应⽤层有两种层次结构。

应用层体系结构

应⽤层体系结构 (Application Architecture)定义了应⽤层端系统之间数据交换的⽅式,开发⼀种新 的⽹络应⽤,⾸先要考虑的问题就是⽹络应⽤程序在各种端系统上的组织⽅式和它们之间的关系⼀般来 说,主流的体系结构有两种:

客户-服务器体系结构 (client-server architecture)

对等体系结构 (P2P architecture)

客户-服务器体系结构

在客户-服务器体系结构中,分为请求⽅和服务⽅。有⼀个总是打开的主机称为服务端 (Server),它 向客户端 (client) 提供服务。客户端会发送请求给服务端,服务端会根据客户端的请求做出响应。

体系特点

客户和服务器是指通信中所涉及的两个应⽤进程。

客户/服务器⽅式所描述的是进程之间服务和被服务的关系

客户是服务请求⽅,服务器是服务提供⽅。

服务器总是处于运⾏状态,并等待客户的服务请求。

最常见的就是web服务器,Web服务器提供于来⾃浏览器的请求。我们⽇常访问百度、 ⾕歌,其实就是在访问它们的Web服务器。 ⼀般常⻅的 Web 服务器主要有Apache、IIS、Jboss、Tomcat、WebSphere、WebLogic 等。

在客户 - 服务器模式下,通常客户彼此之间是并不互相通信的。

服务器通常具有固定的、周知的 IP 地址可以提供访问。

客户 - 服务器模式通常会出现随着客户数量的急剧增加导致单台服务器⽆法满⾜⼤量请求的情况。 为此,通常需要配备⼤量的数据中⼼ (data center) ,⽤来跟踪所有的⽤户请求。

C/S模式的通信,鲁棒性极差。

对等体系结构

在P2P⽅式中,没有固定的服务请求者和服务提供者,分布在⽹络边缘各端系统中的应⽤进程是对 等的,被称为对等⽅。对等⽅相互之间直接通信,每个对等⽅既是服务的请求者,⼜是服务的提供者。

在因特⽹上流⾏的P2P应⽤主要包括P2P⽂件共享、即时通信、P2P流媒体、分布式存储等。

 P2P ⼀个最⼤的特点就是扩展性 (self-scalability),因为 P2P ⽹络的⼀个重要的⽬标就是让所有 的客户端都能提供资源、获取资源,共享带宽,存储空间等。因此,当有更多节点加⼊且对系统请求增 多,整个系统的容量也增⼤。这是具有⼀组固定服务器的客户 - 服务器结构不具备的,这也就是 P2P 的 优势。P2P⽅式具有成本上的优势,因为它通常不需要庞⼤的服务器设置和服务器带宽。为了降低成 本,服务提供商对于将P2P⽅式⽤于应⽤的兴趣越来越⼤。

万维网

概述

万维⽹(World Wide Web,WWW)并⾮某种特殊的计算机⽹络。它是⼀个⼤规模的、联机式的信 息储藏所,是运⾏在因特⽹上的⼀个分布式应⽤。万维⽹利⽤⽹⻚之间的超链接将不同⽹站的⽹⻚链接 成⼀张逻辑上的信息⽹。

通过浏览器,我们⽆需关注想要访问的内容在哪个服务器上, 我们只需要知道我们想访问的内容就可以了。

 浏览器接收到一堆数据,利用数据的格式解析,渲染到浏览器界面

web协议:

        传输协议                HTTP

        数据解析协议         HTML、CSS、JavaScript        pdf        rstp 等等

WWW 定义了三个⽐较重要的概念,这些概念主要有:

URI定义了访问信息的⼿段和位置 ;

⽂档规范 ;

HTTP 定义了 WWW 的访问规范。

URL

URI (Uniform Resource Identifier) 中⽂名称是统⼀资源标识符,使⽤它就能够唯⼀地标记互联⽹ 上资源。

URL (Uniform Resource Locator) 中⽂名称是统⼀资源定位符,也就是我们俗称的⽹址,它实际 上是URI 的⼀个⼦集。

 URI 已经不局限于标识互联⽹资源,它可以作为所有资源的识别码。URL的⼀般形式由以下四个部 分组成:

我们来看京东的URI

https://passport.jd.com/uc/login?ReturnUrl=https%3A%2F%2Forder.jd.com%2Fcenter%2Flist.action

https为协议

主机和端口之间的冒号省略了,所以主机加端口是passport.jd.com

我们的路径是/uc/login,也就是URL的一部分,加上问号后面的,是整个URL。

至于?号后面,是被http解析器来解析的。是http的请求参数。

我们观察发现,问号后面也有相应的格式,=号、%号。

这里我在D盘题库里建立a文件,我们看到浏览器对文本文件的解析

 

文本格式只能表示文本,我们希望文本好看些,不再是普通的文字,有一定的样式

所以,超文本问世。

万维网文档

html

超⽂本标记语⾔ (HyperText Markup Language,HTML),使⽤多种“标签”来描述⽹⻚的结构和内 容。HTML 称为超⽂本标记语⾔,是⼀种标识性的语⾔。它包括⼀系列标签.通过这些标签可以将⽹络 上的⽂档格式统⼀,使分散的Internet资源连接为⼀个逻辑整体。HTML⽂本是由HTML命令组成的描述 性⽂本,HTML命令可以说明⽂字,图形、动画、声⾳、表格、链接等。

 css

层叠样式表 (Cascading Style Sheets,CSS),从审美的⻆度来描述⽹⻚的样式。

Javascript

⼀种脚本语⾔,控制⽹⻚的⾏为。

比如你点击某些地方,进行某些行为。

这些东西很简单,不多赘述。

HTTP

 目的:实现数据传输

HTTP 是⼀个在计算机世界⾥专⻔在两点之间传输⽂字、图⽚、⾳频、视频等超⽂本数据的约定和 规范。HTTP 是⼀种应⽤层协议,它使⽤TCP作为运输层协议,因为⽂档、数据这些信息在我们看来是 ⼀种重要的信息,不可丢失。

HTTP连接行为

HTTP1.0

HTTP/1.0采⽤⾮持续连接⽅式。在该⽅式下,每次浏览器要请求⼀个⽂件都要与服务器建⽴TCP连接,当收到响应后就⽴即关闭连接。

我们考虑到,第三次握手不发送报文,那么由于我的服务器是被动的,需要等到你发送数据时,才响应报文,那么如果要等很久呢?

所以,我们在第三次握手的时候HTTP请求报文,节省时间资源,提高效率。

 客户端代码非常好写,功能很简单。

每请求⼀个⽂档就要有两倍的RTT的开销。若⼀个⽹⻚上有很多引⽤对象(例如图⽚等),那么请 求每⼀个对象都需要花费2RTT的时间。

为了减⼩时延,浏览器通常会建⽴多个并⾏的TCP连接同时请求多个对象。但是,这会⼤量占⽤万 维⽹服务器的资源,特别是万维⽹服务器往往要同时服务于⼤量客户的请求,这会使其负担很重。

HTTP1.1

目前常用协议

HTTP/1.1采⽤持续连接⽅式。在该⽅式下,万维⽹服务器在发送响应后仍然保持这条连接,使同⼀ 个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报⽂和响应报⽂。这并不局限 于传送同⼀个⻚⾯上引⽤的对象,⽽是只要这些⽂档都在同⼀个服务器上就⾏。

为了进⼀步提⾼效率,HTTP/1.1的持续连接还可以使⽤流⽔线⽅式⼯作,即浏览器在收到HTTP的响 应报⽂之前就能够连续发送多个请求报⽂。这样的⼀个接⼀个的请求报⽂到达服务器后,服务器就发回 ⼀个接⼀个的响应报⽂。这样就节省了很多个RTT时间,使TCP连接中的空闲时间减少,提⾼了下载⽂ 档的效率。

下图可以看到,

发送,返回都是http1.1

 在下图,可以看到我与百度的连接,处于keep-alive的状态。

content-length为了解决粘包问题。

 cookie不能看哦~

HTTP报文格式

首先,报文分为请求报文和响应报文。

格式理应不同,但为了统一化管理,格式相同,但内容不同。

请求报文

 HTTP 协议主要由三⼤部分组成:

起始⾏(start line) :描述请求或响应的基本信息。

(但是,我计算机怎么知道是行呢,内存里都是一堆二进制数,怎么解决呢,c语言中的\r\n!!!!)

顺便提一嘴,我们的回车换行是两个东西,回车——回到第一个位置,换行——换下一行

CR和CRLF请自行了解。

头部字段(header) :使⽤ key-value 形式更详细地说明报⽂。

图中的白色,其实是协议头与正文的分割标志。为什么需要呢?

这些东西在计算机中就是一堆二进制,我怎么知道你这是数据这是协议头呢。

所以规定分割标志。

消息正⽂(entity) :实际传输的数据,它不⼀定是纯⽂本,可以是图⽚、视频等⼆进制数 据。

其中起始⾏和头部字段并称为请求头或者响应头,统称为 Header;消息正⽂也叫做实体,称为 body。

HTTP 协议规定每次发送的报⽂必须要有 Header,但是可以没有 body,也就是说头信息是必须 的,实体信息可以没有。⽽且在 header 和 body 之间必须要有⼀个空⾏(CRLF)。

 这幅图需要注意⼀下,如果使⽤ GET ⽅法,是没有实体体的,如果你使⽤的是 POST ⽅法,才会 有实体体。当⽤户提交表单时,HTTP 客户端通常使⽤ POST ⽅法;与此相反,HTML 表单的获取通常 使⽤ GET ⽅法。HEAD ⽅法类似于 GET ⽅法,只不过 HEAD ⽅法不会返回对象。

 最常用的:GET和POST。

 响应报文

大家应该都见过404吧,没错nofound,就是状态码。

 

 对3进行一下接受。

假设我们的服务器用了新的URL,但是用户不知道,用户访问已经过期的URL,如果收到404,解决不了用户想要访问的需求。

所以我们状态码用302,转向新的URL

如HTTP/1.1  302  Move .....

        redirect:http://.........

缓存问题。

我的服务器的a.html文件我记录它最新的更新时间,3月1号。

你的请求报文来了,同时带着文件在你那里是什么时间来的,比如3月3号。

那么你的文件一定是最新的,所以服务器不用再加a.html,在响应报文状态码标记307。

你不用再更新了。

3的动作很多。

4是客户的问题。

5是服务器的问题。

HTTP协议特征

从上⾯整个过程中我们可以总结出 HTTP 进⾏分组传输是具有以下特征:

1.⽀持客户 - 服务器模式

2.简单快速 :客户向服务器请求服务时,只需传送请求⽅法和路径。请求⽅法常⽤的有 GET、 HEAD、POST。每种⽅法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单,使得 HTTP 服务器的程序规模⼩,因⽽通信速度很快。

3.灵活 :HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

4.⽆连接 :⽆连接的含义是限制每次连接只处理⼀个请求。服务器处理完客户的请求,并收到客 户的应答后,即断开连接。采⽤这种⽅式可以节省传输时间。

5.⽆状态 :HTTP 协议是⽆状态协议。⽆状态是指协议对于事务处理没有记忆能⼒。缺少状态意 味着如果后续处理需要前⾯的信息,则它必须重传,这样可能导致每次连接传送的数据量增 ⼤。另⼀⽅⾯,在服务器不需要先前信息时它的应答就较快。

cookie和session

首先,我们每个请求都是独立的。

HTTP 协议是⼀种⽆状态协议,即每次服务端接收到客户端的请求时,都是⼀个全新的请求,服务 器并不知道客户端的历史请求记录;Session 和 Cookie 的主要⽬的就是为了弥补 HTTP 的⽆状态特 性

是什么?

HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie,它是服务器发送到 Web 浏览器的⼀ ⼩块数据。服务器发送到浏览器的 Cookie,浏览器会进⾏存储,并与下⼀个请求⼀起发送到服务器。通 常,它⽤于判断两个请求是否来⾃于同⼀个浏览器,例如⽤户保持登录状态。

Cookie 主要⽤于下⾯三个⽬的:

会话管理: 登陆、购物⻋、游戏得分或者服务器应该记住的其他内容。

个性化: ⽤户偏好、主题或者其他设置。

追踪: 记录和分析⽤户⾏为。(类比大家总说的“可怕的大数据”)

客户端请求服务端,服务端会为这次请求开辟⼀块内存空间,这个对象便是 Session 对象,存储结 构是⼀个 Map 映射,具体⼀点是 ConcurrentHashMap。Session 弥补了 HTTP ⽆状态特性,服务器可 以利⽤ Session 存储客户端在同⼀个会话期间的⼀些操作记录。

 有两种类型的 Cookies,⼀种是 Session Cookies,⼀种是 Persistent Cookies,如果 Cookie 不 包含到期⽇期,则将其视为会话 Cookie。会话 Cookie 存储在内存中,永远不会写⼊磁盘,当浏览器关 闭时,此后 Cookie 将永久丢失。如果 Cookie 包含有效期 ,则将其视为持久性 Cookie。在到期指定的 ⽇期, Cookie 将从磁盘中删除。

 服务器第⼀次接收到请求时,开辟了⼀块 Session 空间(创建了 Session 对象),同时⽣成⼀个 sessionId ,并通过响应头的 Set-Cookie:JSESSIONID=XXXXXXX 命令,向客户端发送要求设置 Cookie 的响应; 客户端收到响应后,在本机客户端设置了⼀个 JSESSIONID=XXXXXXX 的 Cookie 信 息,该 Cookie 的过期时间为浏览器会话结束;

接下来客户端每次向同⼀个⽹站发送请求时,请求头都会带上该 Cookie信息(包含 sessionId), 然 后服务器通过读取请求头中的 Cookie 信息,获取名称为 JSESSIONID 的值,得到此次请求的 sessionId。 session 机制有个缺点,⽐如 A 服务器存储了 session,就是做了负载均衡后,假如⼀段时间内 A 的访问量激增,会转发到 B 进⾏访问,但是 B 服务器并没有存储 A 的 session,会导致 session 的失 效。

Web缓存

万维⽹缓存⼜称为Web缓存(Web Cache),可位于客户机,也可位于中间系统上,位于中间系统 上的Web缓存⼜称为代理服务器(Proxy Server)。

Web 缓存 (Web cache) 也叫做代理服务器缓存,它是代表 HTTP 服务器来满⾜⽤户需求的⽹络实 体。 Web 缓存器有⾃⼰的磁盘存储空间,并会在存储空间内保存最近请求过的对象

 那么为什么需要代理服务器的存在呢?相信你看完上⾯的描述应该能⼤致猜到它的作⽤。

⾸先,代理服务器可以⼤⼤减少对客户请求的响应时间,能够更快给⽤户响应。

其次,代理服务器可以减少⼀个机构接⼊链路到⽹络的通信量,降低⽹络带宽,降低运营商成 本。

然后,代理服务器可以分担初始服务器的压⼒,改善应⽤程序的性能。

DNS协议

概述

试想⼀个问题,我们⼈类可以有多少种识别⾃⼰的⽅式?可以通过身份证来识别,可以通过社保卡 号来识别,也可以通过驾驶证来识别,尽管有多种识别⽅式,但在特定的环境下,某种识别⽅法会⽐其 他⽅法更为适合。因特⽹上的主机和⼈类⼀样,可以使⽤多种⽅式进⾏标识。互联⽹上主机的⼀种标识 ⽅法是使⽤它的主机名(hostname),⽐如 www.baidu.com、www.google.com 等。这是我们⼈类习惯 的记忆⽅式,因特⽹中的主机却不会这么记忆,它们喜欢定⻓的、有层次结构的 IP 地址。

DNS 的全称是 Domain Name System,DNS ,它是⼀个由分层的 DNS 服务器(DNS server)实 现的分布式数据库;它还是⼀个使得主机能够查询分布式数据库的应⽤层协议。DNS 服务器通常是运⾏ BIND(Berkeley Internet Name Domain) 软件的 UNIX 机器。DNS 协议可以运⾏在 UDP 之上,也可以 运⾏在 TCP 之上,使⽤ 53 端⼝。

DNS 通常不是⼀⻔独⽴的协议,它通常为其他应⽤层协议所使⽤,这些协议包括 HTTP、SMTP 和 FTP,将⽤户提供的主机名解析为 IP 地址。

DNS系统结构

 因特⽹是否可以只使⽤⼀台DNS服务器?

这种做法并不可取。因为因特⽹的规模很⼤,这样的域名服务器肯定会因为超负荷⽽⽆法正常 ⼯作,⽽且⼀旦域名服务器出现故障,整个因特⽹就会瘫痪。

早在1983年,因特⽹就开始采⽤层次结构的命名树作为主机的名字(即域名),并使⽤分布式 的域名系统DNS。

DNS使⼤多数域名都在本地解析,仅少量解析需要在因特⽹上通信,因此系统效率很⾼。

由于DNS是分布式系统,即使单个计算机出了故障,也不会妨碍整个系统的正常运⾏。

集中式的设计会存在以下⼏个问题:

单点故障(a single point of failure),如果 DNS 服务器崩溃,那么整个⽹络随之瘫痪。

通信容量(traaffic volume),单个 DNS 服务器不得不处理所有的 DNS 查询,这种查询级别可 能是上百万上千万级。

远距离集中式数据库(distant centralized database),单个 DNS 服务器不可能 邻近 所有的⽤ 户,假设在美国的 DNS 服务器不可能临近让澳⼤利亚的查询使⽤,其中查询请求势必会经过低 速和拥堵的链路,造成严重的时延。

维护(maintenance),维护成本巨⼤,⽽且还需要频繁更新。

域名结构

 

域名系统既不规定⼀个域名需要包含多少个下级域名,也不规定每⼀级的域名代表什么意思。

各级域名由其上⼀级的域名管理机构管理,⽽最⾼的顶级域名则由因特⽹名称与数字地址分配机构 ICANN进⾏管理。

顶级域名(Top Level Domain,TLD)分为以下三类:

国家顶级域名nTLD

采⽤ISO 3166的规定。如cn表示中国,us表示美国,uk表示英国、等等。

通⽤顶级域名gTLD

最常⻅的通⽤顶级域名有七个,即:com(公司企业)、net(⽹络服务机构)、org(⾮ 营利性组织)、int(国际组织)、edu(美国教育机构)、gov(美国政府部⻔)、mil (美国军事部⻔)。

反向域arpa :

⽤于反向域名解析,即IP地址反向解析为域名。


在国家顶级域名下注册的⼆级域名均由该国家⾃⾏确定。例如,顶级域名为jp的⽇本,将其教育和企 业机构的⼆级域名定为ac和co,⽽不⽤edu和com。

我国则将⼆级域名划分为以下两类:

类别域名 共七个:ac(科研机构)、com(⼯、商、⾦融等企业)、edu(教育机构)、gov(政府 部⻔)、net(提供⽹络服务的机构)、mil(军事机构)和org(⾮营利性组织)。

⾏政区域名 共34个,适⽤于我国的各省、⾃治区、直辖市。例如:bj为北京市、sh为上海市、js为江 苏省,等等。

 这种按等级管理的命名⽅法便于维护名字的唯⼀性,并且也容易设计出⼀种⾼效的域名查询机制。 需要注意的是,域名只是个逻辑概念,并不代表计算机所在的物理地点。

域名服务器

域名和IP地址的映射关系必须保存在域名服务器中,供所有其他应⽤查询。显然不能将所有信息都 储存在⼀台域名服务器中。

DNS使⽤分布在各地的域名服务器来实现域名到IP地址的转换。

⼤致来说有三种 DNS 服务器:根 DNS 服务器、 顶级域(Top-Level Domain, TLD) DNS 服务器 和 权威 DNS 服务器 。

 根域名服务器是最⾼层次的域名服务器。 每个根域名服务器都知道所有的顶级域名服务器的域名及其IP地址。

尽管我们将这13个根域名服务器中的每⼀个都视为单个的服务器,但“每台服务器”实际上是由许多 分布在世界各地的计算机构成的服务器群集。

当本地域名服务器向根域名服务器发出查询请求时,路由器就把查询请求报⽂转发到离这个 DNS客户最近的⼀个根域名服务器。 这就加快了DNS的查询过程,同时也更合理地利⽤了因特⽹的资源。

根域名服务器通常并不直 接对域名进⾏解析,⽽是返回该域名所属顶级域名的顶级域名服务器的IP地址。

顶级域名服务器负责管理在该顶级域名服务器注册的所有⼆级域名。

当收到DNS查询请求时就给出相应的回答,可能是最后的结果,也可能是下⼀级权限域名服务器的 IP地址。

权限域名服务器负责管理某个区的域名。

每⼀个主机的域名都必须在某个权限域名服务器处注册登记因此权限域名服务器知道其管辖的域名与IP地址的映射关系。

另外,权限域名服务器还知道其下级域名服务器的地址。

本地域名服务器不属于上述的域名服务器的等级结构。

当⼀个主机发出DNS请求报⽂时,这个报⽂就⾸先被送往该主机的本地域名服务器。

本地域名服务器起着代理的作⽤,会将该报⽂转发到上述的域名服务器的等级结构中。 (看本地有没有)

每⼀个因特⽹服务提供者ISP,⼀个⼤学,甚⾄⼀个⼤学⾥的学院,都可以拥有⼀个本地域名服务 器,它有时也称为默认域名服务器

本地域名服务器离⽤户较近,⼀般不超过⼏个路由器的距离,也有可能就在同⼀个局域⽹中。本地 域名服务器的IP地址需要直接配置在需要域名解析的主机中。

DNS查询步骤

iee.com.cn/

第一步,本地。第二步,根。第三步,cn。第四步,com

 DNS查询类型

递归查询

迭代查询

缓存查询

 由于域名到IP地址的映射关系并不是永久不变,为保持⾼速缓存中的内容正确,域名服务器应为每 项内容设置计时器并删除超过合理时间的项(例如,每个项⽬只存放两天)。

不但在本地域名服务器中需要⾼速缓存,在⽤户主机中也很需要。许多⽤户主机在启动时从本地域 名服务器下载域名和IP地址的全部数据库,维护存放⾃⼰最近使⽤的域名的⾼速缓存,并且只在从缓存 中找不到域名时才向域名服务器查询。同理,主机也需要保持⾼速缓存中内容的正确性

DHCP

概述

DHCP 的全称是 Dynamic Host Configuration Protocol 动态主机配置协议。使⽤ DHCP 就能实 现⾃动设置 IP 地址、统⼀管理 IP 地址分配。也就是不管你是在开会还是在⼯位⼲活,都省去了⼿动配 置 IP 地址这⼀步繁琐的操作,同时 DHCP 也⼤⼤减少了可能由于你⼿动分配 IP 地址导致错误的⼏率。

DHCP 与 IP 密切相关,它是 IP ⽹络上所使⽤的协议。如果你想要使⽤ DHCP 提供服务的话,那么 在整条通信链路上就需要 DHCP 服务器的存在,连接到⽹络的设备使⽤ DHCP 协议从 DHCP 服务器请 求 IP 地址。DHCP 服务器会为设备分配⼀个唯⼀的 IP 地址。

 由于 IP 地址是动态的(临时分配)⽽不是静态的(永久分配),因此不再使⽤的 IP 地址会⾃动返回 IP 地址池中进⾏重新分配。

DHCP 服务器通常为每个客户端分配⼀个唯⼀的动 态 IP 地址,当该 IP 地址的客户端租约到期时,该地址就会更改。

虽然 DHCP 服务器能提供 IP 地址,但是他怎么知道哪些 IP 地址空闲,哪些 IP 地址正在使⽤呢?

实际上,这些信息都配置在了数据库中,下⾯我们就来⼀起看⼀下 DHCP 服务器维护了哪些信息。

⽹络上所有有效的 TCP/IP 配置参数:

这些参数主要包括主机名(Host name)、DHCP 客户端(DHCP client)、域名(Domain name)、IP 地址IP address)、⽹关(Netmask)、⼴播地址(Broadcast address)、默认路由 (default rooter)。

DHCP 报⽂共有以下⼏种:

DHCP DISCOVER :客户端开始 DHCP 过程发送的包,是 DHCP 协议的开始

DHCP OFFER :服务器接收到 DHCPDISCOVER 之后做出的响应,它包括了给予客户端的 IP 租约 过期时间、服务器的识别符以及其他信息

DHCP REQUEST 客户端对于服务器发出的 DHCPOFFER 所做出的响应。在续约租期的时候同 样会使⽤。

DHCP ACK :服务器在接收到客户端发来的 DHCPREQUEST 之后发出的成功确认的报⽂。在建⽴ 连接的时候,客户端在接收到这个报⽂之后才会确认分配给它的 IP 和其他信息可以被允许使⽤。

DHCP NAK :DHCPACK 的相反的报⽂,表示服务器拒绝了客户端的请求。

DHCP RELEASE :⼀般出现在客户端关机、下线等状况。这个报⽂将会使 DHCP 服务器释放发出 此报⽂的客户端的 IP 地址

DHCP INFORM :客户端发出的向服务器请求⼀些信息的报⽂

DHCP DECLINE :当客户端发现服务器分配的 IP 地址⽆法使⽤(如 IP 地址冲突时),将发出此报 ⽂,通知服务器禁⽌使⽤该 IP 地址。

流程

 

 

 

 

 

HTTP2.0/3.0

最初的HTTP

HTTP 刚刚诞⽣之初只⽤于 web 端的内容获取,⼀般就是⽤于⻚⾯访问,那个时候的⻚⾯内容还不 如现在这样丰富,交互场景也不是很多,也没有庞⼤繁杂的 CSS、JS ,⻚⾯加载速度⾮常快。但是随 着 web 2.0 的出现以及更多的内容被展示、更精美的排版、更多的⽤户交互场景⼀起出现,导致⻚⾯的 内容越来越⼤,使得⻚⾯加载速度越来越慢。

1.0的问题

已大量使用。

影响⼀个 HTTP ⽹络请求的因素主要有两个:带宽和延迟

⾸先来说⼀下带宽,如果我们还停留在拨号上⽹阶段的话,带宽很容易出现瓶颈,因为单位时间内 传输的数据量很⼩。但是现在随着光纤等通信技术的不断发展,10Mbps、100Mbps、甚⾄ 1000 Mbps 进⼊了每个家庭,我们不⽤再担⼼带宽成为⽹络请求的瓶颈了,那么剩下的就只剩下延迟了。

延迟主要有下⾯三个⽅⾯:

浏览器阻塞(HOL blocking):浏览器会因为⼀些原因阻塞请求。浏览器对于同⼀个域名,同时只 能有 6 个连接(这个根据浏览器内核不同可能会有所差异),超过浏览器最⼤连接数限制,后续请 求就会被阻塞。

DNS 查询(DNS Lookup):浏览器需要知道⽬标服务器的 IP 才能建⽴连接。将域名解析为 IP 的 这个系统就是 DNS。这个通常可以利⽤ DNS 缓存结果来达到减少这个时间的⽬的。

建⽴连接(Initial connection):HTTP 是基于 TCP 协议的,浏览器最快也要在第三次握⼿时才能 捎带 HTTP 请求报⽂,达到真正的建⽴连接,但是这些连接⽆法复⽤会导致每次请求都经历三次握 ⼿和慢启动。三次握⼿在⾼延迟的场景下影响较明显,慢启动则对⽂件类⼤请求影响较⼤。

HTTP 1.0 有⼀个被抱怨最多的是连接⽆法复⽤,当每次有新的请求时都会重新经历⼀次三次握⼿和 四次挥⼿过程,并且连接的建⽴和释放需要耗费⼤量的服务器资源,在请求少的⻚⾯还尚能应对,不过 随着请求的不断增多,HTTP 1.0 越来越难顶。

HTTP 还有⼀个被抱怨最多的问题就是它的队头阻塞(head of blocking),队头阻塞问题会导致带宽 ⽆法充分利⽤,导致后续的请求被阻塞。

假如有五个请求被同时发出,如果第⼀个请求没有处理完成,就会导致后续的请求也⽆法得到处 理,如下图所示:

 

如果第⼀个请求没有被处理,那么 2 3 4 5 这四个请求会直接阻塞在客户端,等到请求 1 被处理完 毕后,才能逐个发出。⽹络通畅的时候性能影响不⼤,不过⼀旦请求 1 因为某些原因没有抵达服务器, 或者请求因为⽹络阻塞没有及时返回,影响的就是所有后续请求,导致后续请求⽆限阻塞下去,问题就 变得⽐较严重了。

不过在 HTTP 1.1 中,也提出了流⽔线(pipelining)的设计,pipelining 就被⽤来解决队头阻塞的问 题,如下图所示:

 

 SPDY

 

基础功能:

多路复⽤(multiplexing),多路复⽤通过多个请求共⽤⼀个连接的⽅式,降低了 TCP 连接建⽴和释 放的开销,同时提⾼了带宽的利⽤率。

请求优先级(request prioritization),多路复⽤带来的⼀个问题是,在共享连接的基础上会存在⼀些 关键请求被阻塞,SPDY 允许给每个请求设置优先级,这样重要的请求就会优先得到响应。

header 压缩,前⾯提到的 HTTP 1.x 的 header 很多时候都是重复⽽且多余的。选择合适的压缩算法可以减⼩包的⼤⼩和数量。SPDY 对 header 的压缩率可以达到 80% 以上。

高级功能:

服务端推送,HTTP 只能由客户端发送,服务器只能被动发送响应。不过在开启服务端推送后,服务端通过 X-Associated-Content header 会告知服务器会有新的内容被推送过来。

服务端暗示,和服务端推送所不同的是,服务端暗示不会推送内容,只是告诉客户端有新的内容产 ⽣,,内容的下载还是需要客户端主动发起请求。服务端暗示通过 X-Subresources header 来通 知,⼀般应⽤场景是客户端需要先查询服务端状态,然后再下载资源,可以节约⼀次查询请求。

HTTP2.0

HTTP 2.0 在设计之初就有⼀些重要的前提:

1.客户端向服务器发送请求的这种基本模型不会改变。

2.原有的协议头不会改变,使⽤ http:// 和 https:// 的服务和应⽤不会做任何修改,不会有 http2://。

3.使⽤ HTTP 1.x 的客户端和服务器可以平滑升级到 HTTP 2.0 上。

4.不识别 HTTP 2.0 的代理服务器可以将请求降级到 HTTP 1.x。

HTTP 1.x 的诞⽣使⽤的是明⽂协议,它的格式主要由三部分构成:请求⾏(request line) 、请求头 (header) 和报⽂体(body),要识别这三部分必须要做协议解析,⽽协议解析是基于⽂本的,基于⽂本的 解析存在多样性的缺陷,⽽⼆进制格式只能识别 0 和 1 ,⽐较固定,基于这种考量,HTTP 2.0 决定采 ⽤⼆进制格式,实现⽅便⽽且健壮性强。

 

在 HTTP 2.0 报⽂中,length 定义了整个 frame 的开始到结束,type 定了 frame 的类型,⼀种有 ⼗种,flags 定义了⼀些重要的参数,stream id ⽤作流控制,剩下的 payload 就是 request 的正⽂。

虽然 HTTP 2.0 报⽂格式看上去和 HTTP 1.x 的完全不同,但是实际上 HTTP 2.0 并没有改变 HTTP 1.x 的语义,它只是在 HTTP 1.x 的基础上封装了⼀层,如下图所示:

 

 

HTTP 2.0 带给我们最惊艳的莫过于多路复⽤了,虽然多路复⽤有种种好处,但是⼤家可以想⼀下, 多路复⽤虽然好,但是它是建⽴在 TCP 连接的基础上,在连接频繁的情况下,是不是会对 TCP 连接造 成压⼒,这个⻆度来讲,TCP 很容易成为性能瓶颈。

还有⼀点,使⽤ HTTP 2.0 会增加⼀次 TLS 握⼿过程,增加 RTT,这个我们上⾯也说到了。

在 HTTP 2.0 中,多个请求是在同⼀个 TCP 管道中,这样当 HTTP 2.0 出现丢包时,整个 TCP 都 要开始等待重传,那么就会阻塞该 TCP。连接中的所有请求。

HTTP3.0

HTTP 3.0 于 2022 年 6 ⽉ 6 ⽇正式发布,IETF 把 HTTP 3.0 标准制定在了 RFC 9114 中,HTTP 3.0 其实相较于 HTTP 2.0 要⽐ HTTP 2.0 相较于 HTTP 1.1 的变化来说⼩很多,最⼤的提升就在于效 率,替换 TCP 协议为 UDP 协议,HTTP 3.0 具有更低的延迟,它的效率甚⾄要⽐ HTTP 1.1 快 3 倍以 上。

Google 就更起炉灶搞了⼀个基于 UDP 协议的 QUIC 协议,并且使⽤在了 HTTP/3 上,HTTP/3 之前名为 HTTP-over-QUIC,从这个名字中我们也可以发现,HTTP/3 最⼤的改 造就是使⽤了 QUIC

 

 

结束语

多看书、多运动、打会游戏、吃好饭、睡好觉、弹会儿琴~~~~~~~~

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

每天写bug的屑闲鱼

请我杯饮料吧

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值