http的开展史

在学习网络之前，了解它的前史能够帮助我了解为何它会开展为现在这个姿态，能让我有探究它的爱好。下面的这张图片就展示了“互联网”诞生至今的开展历程

http是什么？

HyperTextTransferProtocol 直译为“超文本传输协议”。

1.超文本：指文字、图片、视频、音频等的混合体，比方最了解的html。

2.传输：http是一个“双向协议”，传输的是恳求方和呼应方之间的数据，不约束恳求方和呼应方之间的人物，传递的进程中能够存在恣意“中心人”。

3.协议：协是两个或多个参与者之间的沟通，议是指对参与者之间的约好和规范。所以，http协议能够了解为作用在核算机之间，运用核算机能够了解的言语树立核算机之间沟通通讯的规范，以及相关的各种操控和过错处理办法。

所以关于以上的问题能够有这样的总结：http是一个在核算机世界里专门在两点之间传递文字、图片、音频、视频等超文本数据的约好和规范。

与http相关的一些概念

阅览器（web Browser）：阅览器的实质是http中的恳求方，运用http协议取得网络上的各种资源。在HTTP协议里，阅览器的人物被称为”User Agent”即用户署理，意思是作为拜访者的”署理来建议HTTP恳求。下图是一些主流阅览器及其内核。

服务器（web Server)：硬件意义便是物理办法或“云”办法的机器。软件意义的 Web 服务器便是供给 Web 服务的运用程序，一般会运行在硬件意义的服务器上。它运用强大的硬件才干呼应海量的客户端 HTTP 恳求，回来动态的信息。常见的web服务器有Apache、Nginx。

CDN（Content Delivery Network）：CDN是为了处理长距离网络拜访速度慢的问题而诞生的一种网络运用服务，全称为“内容分发网络”。CDN最中心的原则是“就近拜访”，运用HTTP协议里的署理和缓存技能，用户在上网的时分不直接拜访原网站，而是拜访离他最近的一个CDN节点，节约了拜访进程中的时刻本钱。（负载均衡，安全防护，边缘核算）。

爬虫（Crawler）：“机器人”办法的用户署理，是一种能够自动拜访Web资源的运用程序。

HTML(Hyper Text Markup Language)：超文本符号言语，用于描绘超文本页面，用标签界说图片、文字、排版布局，终究由阅览器渲染。

web Service：由W3C界说的运用服务开发规范，运用client-server主从架构。是一个根据Web（HTTP）的服务架构技能。

WAF：网络运用防火墙，坐落Web服务器之前，专门检测http流量，是防护web运用安全的技能。能够阻挠SQL注入，跨站脚本进犯，能够彻底集成进Apache或Nginx。

TCP/IP：一系列网络通讯协议的统称，其间最中心的是TCP和IP协议。其他的还有UDP，ICMP，ARP等，一起构成一个杂乱但有层次的协议栈。IP（Internet Protocol）协议首要处理寻址和路由问题，以及怎么在两点之间传输数据包。TCP（Transmission Control Protoco）协议坐落IP协议之上，意思是“传输操控协议”，根据IP协议供给牢靠的、字节流办法的通讯，是HTTP协议完成的根底。互联网上的 HTTP 协议运行在 TCP/IP 上，HTTP 也就能够更准确地称为“HTTP over TCP/IP”。

DNS（Domain Name System）：域名体系，用有意义的姓名来作为 IP 地址的等价替代。在 DNS 中，“域名”（Domain Name）又称为“主机名”（Host）。域名用“.”分隔成多个单词，等级从左到右逐级升高，最右边的被称为“尖端域名”。但想要运用 TCP/IP 协议来通讯仍然要运用 IP 地址，所以需求把域名做一个转化，“映射”到它的实在 IP，这便是所谓的“域名解析”。

URI/URL：URI（Uniform Resource Identifier）中文名称是一致资源标识符。DNS 和 IP 地址仅仅符号了互联网上的主机，URI能够仅有地符号互联网上资源。URI 另一个更常用的表现办法是 URL（Uniform Resource Locator）， 一致资源定位符，也便是咱们俗称的“网址”，它实践上是 URI 的一个子集，一般不会做严厉的区别。

URI 首要有三个底子的部分构成：

1.协议名：即拜访该资源应当运用的协议

2.主机名：即互联网上主机的符号，能够是域名或 IP 地址

3.途径：即资源在主机上的方位，运用“/”分隔多级目录

HTTPS：全称是“HTTP over SSL/TLS”，也便是运行在 SSL/TLS 协议上的 HTTP。它是一个负责加密通讯的安全协议，树立在 TCP/IP 之上，所以也是个牢靠的传输协议，能够被用作 HTTP 的下层，相当于“HTTP+SSL/TLS+TCP/IP”。

署理（Proxy）: 是 HTTP 协议中恳求方和应对方中心的一个环节，作为“中转站”，既能够转发客户端的恳求，也能够转发服务器的应对。

署理有许多的品种，常见的有：

1.匿名署理：彻底“隐匿”了被署理的机器，外界看到的仅仅署理服务器；

2.通明署理：顾名思义，它在传输进程中是“通明敞开”的，外界既知道署理，也知道客户端；

3.正向署理：接近客户端，代表客户端向服务器发送恳求；

4.反向署理：接近服务器端，代表服务器呼应客户端的恳求；

网络的分层模型

网络分层模型层级是从下往上数的，一般咱们比较常接触到的是TCP/IP四层模型，也是比较早呈现的分层模型。

第一层是链路层(link layer),负责在底层网络上发送原始数据包，作业在网卡这个层次，运用 MAC 地址来符号网络上的设备，所以有时分也叫 MAC 层。对应的是ISO模型的”数据链路层”。

第二层叫网络层(internet layer)，IP协议就处在这一层。因为IP协议界说了”IP 地址”的概念，所以就能够在”链路层”的根底上，用IP地址替代MAC地址，在这个网络里找设备时只需把IP 地址再翻译成MAC地址就能够了。对应的是ISO模型的”网络层”。

第三层叫”传输层”(transport layer)，这个层次协议的责任是确保数据在IP地址符号的两点之间牢靠地传输，是TCP协议和UDP协议作业的层次。对应的是ISO模型的”传输层”。

第四层叫”运用层”(application layer),因为下面的三层把根底打得十分好，所以在这一层就”百花齐放”了，有各种面向具体运用的协议。例如 Telnet、SSH、FTP、SMTP 等等，当然还有咱们的 HTTP。 对应的是ISO模型的”会话层”，”标明层”，”运用层”。

运用TCP/IP协议族进行网络通讯时，会经过分层次第与对方进行通讯（发送端从运用层往下走，接纳端从运用层往上走）。

域名

域名是一个有层次的结构，是一串用“.”分隔的多个单词，最右边的被称为“尖端域名”，然后是“二级域名”，层级联系向左顺次下降。最左面的是主机名，一般用来标明主机的用途，比方“www”标明供给万维网服务、“mail”标明供给邮件服务，不过这也不是绝对的。

能够经过下面的比方了解一下协议 主机 域名之间的层次联系。域名就像人的姓名相同，姓名的关键是要让咱们简略回忆。除了标识身份之外，域名还能够替代ip地址。

DNS

咱们经常会运用域名拜访网站，但其实在网络查找的工程傍边是运用ip定位资源的，域名有必要解析为ip地址才干够正确的拿到资源。DNS便是用来将域名变为ip的协议。

DNS 的中心体系是一个三层的树状、分布式服务，底子对应域名的结构：

1.根域名服务器（Root DNS Server）：办理尖端域名服务器，回来”com”,”net”,”cn”等尖端域名服务器的 IP 地址。

2.尖端域名服务器（Top-level DNS Server）：办理各自域名下的威望域名服务器，比方 cn 尖端域名服务器能够回来 123.cn域名服务器的 IP 地址。

3.威望域名服务器（Authoritative DNS Server）：办理自己域名下主机的 IP 地址，比方 123.cn 威望域名服务器能够回来 www.123.cn 的 IP 地址。

尽管DNS的服务，遍布全球，服务才干也很厉害，可是全世界的网民都在运用这个服务，也会对服务器造成很大的压力。在中心 DNS 体系之外，还有两种手法用来减轻域名解析的压力，并且能够更快地获取成果，底子思路便是“缓存”。

DNS的解析成果能够保存在大公司自己的DNS服务器里，或许操作体系缓存、hosts 文件傍边，许多域名解析的作业就都不必恳求根DNS服务器了，直接在本地或本机就能处理，不只便利了用户，也减轻了各级 DNS 服务器的压力，效率就大大提升了。

根据域名和DNS服务器，咱们能够完成重定向。因为域名替代了ip地址，所以能够对外域名不变，而主机IP能够恣意改变。当主机有情况需求下线、搬迁时，能够更改 DNS 记载，让域名指向其他的机器。

咱们应该都听说过负载均衡吧，DNS在域名解析阶段就能够进行负载均衡的操作。

第一种办法，因为域名解析能够回来多个 IP 地址，所以一个域名能够对应多台主机，客户端收到多个 IP 地址后，就能够自己运用轮询算法顺次向服务器建议恳求，完成负载均衡。

第二种办法，域名解析能够装备内部的战略，回来离客户端最近的主机，或许回来当时服务质量最好的主机，这样在 DNS 端把恳求分发到不同的服务器，完成负载均衡。

HTTP/1.X

前面咱们说了HTTP便是“超文本传输协议”，是一个在核算机世界里专门在两点之间传递文字、图片、音频、视频等超文本数据的约好和规范。在学习过网络的层次模型之后咱们又了解了HTTP是一个运用层的协议。在这个环节咱们开端正式深化HTTP的世界（根据http/1.1）。

（一）HTTP报文

HTTP 协议的恳求报文和呼应报文的结构底子相同，由三大部分组成：

1.起始行（start line）：描绘恳求或呼应的底子信息；

2.头部字段集合（header）：运用 key-value 办法更具体地说明报文；

3.音讯正文（entity）：实践传输的数据，它不必定是纯文本，能够是图片、视频等二进制数据。

• 恳求行

恳求行一般用来描绘客户端要怎样操作服务端的资源，一般由三个部分组成。一般运用空格（space）来分隔，终究要用 CRLF 换行标明完毕。

• 状况行

状况行一般用来描绘服务端关于客户端的恳求回复的状况，一般也是由三个部分组成。

• 头部字段

恳求行或状况行再加上头部字段集合就构成了 HTTP 报文里完好的恳求头或呼应头。除了起始行以外，恳求头和呼应头的结构底子相同。HTTP 头字段十分灵敏，不只能够运用规范里的 Host、Connection 等已有头，也能够恣意添加自界说头。不过运用头字段需求注意下面几点：

1.字段名不区别巨细写，例如“Host”也能够写成“host”，但首字母大写的可读性更好。

2.字段名里不答应呈现空格，能够运用连字符“-”，但不能运用下划线“_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名。

3.字段名后边有必要紧接着“:”，不能有空格，而“:”后的字段值前能够有多个空格。

4.字段的次第是没有意义的，能够恣意摆放不影响语义。

5.字段原则上不能重复，除非这个字段自身的语义答应，例如 Set-Cookie。

（二）HTTP恳求办法

现在 HTTP/1.1 规则了八种办法，单词都有必要是大写的办法，下面就来看看这些办法：

1.GET：获取资源，能够了解为读取或许下载数据。

2.HEAD：获取资源的元信息。

3.POST：向资源提交数据，相当于写入或上传数据。

4.PUT：相似 POST。

5.DELETE：删去资源。

6.CONNECT：树立特别的衔接隧道。

7.OPTIONS：列出可对资源实行的办法。

8.TRACE：追寻恳求 – 呼应的传输途径。

这几个是咱们比较常用的办法，有必要好好学习一下。

GET和HEAD

1. GET适用于向服务器恳求资源，一般将数据带着于url上。

2. HEAD相似于简化版的GET恳求，服务端收到HEAD恳求时只回来呼应头并且呼应头与GET彻底一致。

POST和PUT

1. POST 适用于向服务端发送数据，将数据带着在body傍边，一般标明的是“create”的意义。

2. PUT 相似于POST办法，也能够向服务器提交数据，是“update”的意义。

GET和POST的区别

在这儿特别简略被问到的问题是GET和POST的区别，我也想在这块具体的写一下。以下是根据我个人的了解

1. 巨细：GET一般将数据带在URL傍边而POST将数据放在body里(是RFC在语义上的要求，语法上GET也能够运用body传输数据而POST相同能够把参数放在URL里)，因而因为阅览器关于URL长度的约束，GET恳求能带着的数据巨细一般不超越2KB。值得一提Chrome阅览器对URL的长度约束现已增加到2MB，可是咱们考虑到兼容性，URL的长度应该以最大约束的最小规范为主（IE阅览器约束为2KB），除了阅览器的约束，还应该考虑到服务端的约束。

2. 安全：安满是指恳求的办法是否会对服务器傍边的资源造成影响，因为GET办法是只读的，只需服务器没有“曲解”客户端的恳求，服务端上的数据便是安全的。而POST会对服务端的数据进行“增删改”的操作，因而是不安全的。

3. 幂等：幂等的意思是说屡次重复履行操作，产生的作用是否相同。显然因为GET办法只对服务器上的资源做只读操作，因而是幂等的。POST在RFC中的界说是“新增或提交数据”，屡次提交数据会创立多个资源，所以不是幂等的（而 PUT 是“替换或更新数据”，屡次更新一个资源，所所以幂等的）。

4. 缓存：便是说这个办法的可缓存性，绝大多数的阅览器的完成里仅仅支撑GET缓存。因为GET由所以读取，就能够对GET恳求的数据做缓存。而POST不幂等也就意味着不能随意屡次履行。因而也就不能缓存。

（三）URI是什么

URI，也便是一致资源标识符（Uniform Resource Identifier）。因为它经常呈现在阅览器的地址栏里，所以俗称为“网络地址”，简称“网址”。URI 不彻底等同于网址，它包括有 URL 和 URN 两个部分，在 HTTP 世界里用的网址实践上是 URL——一致资源定位符（Uniform Resource Locator）。但因为 URL 实在是太遍及了，所以常常把这两者简略地视为相等。

URI 实质上是一个字符串，这个字符串的作用是仅有地符号资源的方位或许姓名。

上面这个图片便是一个完好的URI，下面具体拆解一下它的结构。

scheme 协议名，标明资源应该运用哪种协议来拜访。最常见的当然便是“http”了，标明运用 HTTP 协议。别的还有“https”，标明运用经过加密、安全的 HTTPS 协议。此外还有其他不是很常见的 scheme，例如 ftp、ldap、file、news 等。

:// 分隔符，在 scheme 之后，有必要是三个特定的字符“://”，它把 scheme 和后边的部分分脱离。没有特定的意义。

user:passwd@ 身份信息，标明登录主机时的用户名和暗码，但现在现已不引荐运用这种办法了，因为它把灵敏信息以明文办法暴露出来，存在严峻的安全隐患。

host:port主机名，标明资源所在的主机名，一般的办法是“host:port”，即主机名加端口号。

path 途径,标明资源所在方位,选用了相似文件体系“目录”的标明办法，一般以‘/’开端

query 查询参数，用一个“?”开端，但不包括“?”，标明对资源附加的额定要求。path是多个“key=value”的字符串，这些字符串用字符“&”衔接，阅览器和服务器都能够依照这个格局把长串的查询参数解析成可了解的字典或关联数组办法。

#fragment 片段标识符，它是 URI 所定位的资源内部的一个“锚点”，阅览器能够在获取资源后直接跳转到它指示的方位。但片段标识符仅能由阅览器这样的客户端运用，服务器是看不到的。

在 URI 里只能运用 ASCII 码，关于 ASCII 码以外的字符集和特别字符做一个特别的操作，把它们转化成与 URI 语义不冲突的办法。这在 RFC 规范里称为“escape”和“unescape”，俗称“转义”。URI 转义的规则有点“简略粗暴”，直接把非 ASCII 码或特别字符转化成十六进制字节值，然后前面再加上一个“%”。

（四）状况码

在HTTP报文部分咱们说了HTTP的状况行,咱们在这个部分就来看看状况行中的状况码。

状况码是一个十进制的数字，RFC 规范把状况码分红了五类，用数字的第一位标明分类，而 0 ～ 99 不必，这样状况码的实践可用规模就变成了 100~599。这五类的具体意义是：

• 1：提示信息，标明现在是协议处理的中心状况，还需求后续的操作。

• 2：成功，报文现已收到并被正确处理。

• 3：重定向，资源方位产生改变，需求客户端从头发送恳求。

• 4：客户端过错，恳求报文有误，服务器无法处理。

• 5：服务器过错，服务器在处理恳求时内部产生了过错。

1

1 类状况码归于提示信息，是协议处理的中心状况，实践能够用到的时分很少。

“100 Continue”应该是比较常接触到的,会在POST恳求发送大文件给服务器时询问服务器是否能够承受时运用，需求带上恳求头Expect: 100-continue。这个进程也便是咱们常说的POST发送两个TCP包给服务器的说法的来源，不过客户端不需求一向等候服务端的回应，在必定时刻内没有收到否定的答复仍是会将数据主体发送给服务器。

2

2 类状况码标明服务器收到并成功处理了客户端的恳求，这也是客户端最愿意看到的状况码。

“200 OK”是最常见的成功状况码，标明一切正常，服务器如客户端所期望的那样回来了处理成果，假如对错 HEAD 恳求，一般在呼应头后都会有 body 数据。

“204 No Content”是另一个很常见的成功状况码，它的意义与“200 OK”底子相同，但呼应头后没有 body 数据。所以关于 Web 服务器来说，正确地区别 200 和 204 是很必要的。

“206 Partial Content”是 HTTP 分块下载或断点续传的根底，在客户端发送“规模恳求”、要求获取资源的部分数据时呈现，它与 200 相同，也是服务器成功处理了恳求，但 body 里的数据不是资源的悉数，而是其间的一部分。状况码 206 一般还会伴随着头字段Content-Range，标明呼应报文里 body 数据的具体规模，供客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计 2000 个字节的前 100 个字节。

3

3类状况码标明客户端恳求的资源产生了改变，客户端有必要用新的 URI 从头发送恳求获取资源，也便是一般所说的“重定向”，包括著名的 301、302 跳转。

“301 Moved Permanently” 俗称“永久重定向”，意义是此次恳求的资源现已不存在了，需求改用改用新的 URI 再次拜访。

“302 Found”，曾经的描绘短语是“Moved Temporarily”，俗称“暂时重定向”，意思是恳求的资源还在，但需求暂时用另一个 URI 来拜访。

“304 Not Modified” 是一个比较有意思的状况码，它用于 If-Modified-Since 等条件恳求，标明资源未修正，用于缓存操控。它不具有一般的跳转意义，但能够了解成“重定向已到缓存的文件”（即“缓存重定向”）。

4

4类状况码标明客户端发送的恳求报文有误，服务器无法处理，它便是真实的“过错码”意义了。

“400 Bad Request” 是一个通用的过错码，标明恳求报文有过错，仅仅一个笼统的过错，没有清晰意义的状况码。

“403 Forbidden” 实践上不是客户端的恳求犯错，而是标明服务器制止拜访资源。

“404 Not Found” 本意是资源在本服务器上未找到，所以无法供给给客户端。但现在现已被“用滥了”，只需服务器“不高兴”就能够给出个 404，而咱们也无从得知后边到底是真的未找到，仍是有什么别的原因，某种程度上它比 403 还要令人讨厌。

5

5类状况码标明客户端恳求报文正确，但服务器在处理时内部产生了过错，无法回来应有的呼应数据，是服务器端的“过错码”。

“500 Internal Server Error” 与 400 相似，也是一个通用的过错码，服务器究竟产生了什么过错咱们是不知道的。不过关于服务器来说这应该算是好事，一般不应该把服务器内部的具体信息，例如犯错的函数调用栈告知外界。尽管不利于调试，但能够防止黑客的窥探或许剖析。

“501 Not Implemented” 标明客户端恳求的功能还不支撑，这个过错码比 500 要“温和”一些，和“行将开业，敬请期待”的意思差不多，不过具体什么时分“开业”就不好说了。

“502 Bad Gateway” 一般是服务器作为网关或许署理时回来的过错码，标明服务器自身作业正常，拜访后端服务器时产生了过错，但具体的过错原因也是不知道的。

“503 Service Unavailable” 标明服务器当时很忙，暂时无法呼应服务，咱们上网时有时分遇到的“网络服务正忙，请稍后重试”的提示信息便是状况码 503。503 是一个“暂时”的状况，很可能过几秒钟后服务器就不那么忙了，能够持续供给服务，所以 503 呼应报文里一般还会有一个“Retry-After”字段，指示客户端能够在多久今后再次尝试发送恳求。

（五）HTTP的特点

1.灵敏可扩展：HTTP在诞生之初只规则了报文的底子格局，比方用空格分隔单词，用换行分隔字段，“header+body”等，报文里的各个组成部分都没有做严厉的语法语义约束，能够由开发者恣意定制。而那些 RFC 文档，实践上也能够了解为是对已有扩展的“承认和规范化”，完成了“从实践中来，到实践中去”的良性循环。

2.牢靠传输: 因为 HTTP 协议是根据 TCP/IP 的，而 TCP 自身是一个“牢靠”的传输协议，所以 HTTP 自然也就承继了这个特性，能够在恳求方和应对方之间“牢靠”地传输数据。

3.运用层的协议: HTTP 凭借着可带着恣意头字段和实体数据的报文结构，以及衔接操控、缓存署理等便利易用的特性，只需不太苛求功能，HTTP 几乎能够传递一切东西，满意各种需求，称得上是一个“全能”的协议。

4.恳求 – 应对:恳求 – 应对方法是 HTTP 协议最底子的通讯模型，通俗来讲便是“一发一收”。恳求 – 应对方法也清晰了 HTTP 协议里通讯两边的定位，永远是恳求方先建议衔接和恳求，是自动的，而应对方只需在收到恳求后才干答复，是被迫的，假如没有恳求时不会有任何动作。

5.无状况: “状况”其实便是客户端或许服务器里保存的一些数据或许标志，记载了通讯进程中的一些改变信息。HTTP在整个协议里没有规则任何的“状况”，但不要忘了 HTTP 是“灵敏可扩展”的，尽管规范里没有规则“状况”，但彻底能够在协议的结构里给它“打个补丁”，增加这个特性(cookie)。

6.明文传输: “明文”意思便是协议里的报文（准确地说是 header 部分）不运用二进制数据，而是用简略可阅览的文本办法。

7.不安全: 安全有许多的方面，明文仅仅“秘要”方面的一个缺陷，在“身份认证”和“完好性校验”这两方面 HTTP 也是短缺的。

（六）HTTP的实体数据

• 数据类型

Accept

在TCP/IP协议栈里，数据的传输都是Header+body的办法。在传输层协议中，不需求关怀数据是什么，但在运用层有必要要告知上层数据的类型，不然上层就不知该怎么处理。最早的HTTP协议中，并没有附加的数据类型信息，一切传送的数据都被客户程序解释为HTML文档，而为了支撑多媒体数据类型，HTTP协议中就运用了附加在文档之前的MIME(Multipurpose Internet Mail Extensions 多用途互联网邮件扩展类型)指定的数据类型信息来标识数据类型。MINE将数据分为七大类（video、image、application、text、audio、multipart、message），再以type/subtype的格局细分出其下的子类。例如咱们常用到的text/html 、text/css 、image/jpeg 、 applaction/json等。

Accept-encoding

此外HTTP协议还拟定了数据的紧缩格局：

gzip：GNU zip 紧缩格局，也是互联网上最盛行的紧缩格局；

deflate：zlib（deflate）紧缩格局，盛行程度仅次于 gzip；

br：一种专门为 HTTP 优化的新紧缩算法（Brotli）。

Accept-Language

符号了客户端可了解的自然言语，也答运用“,”做分隔符列出多个类型，例如：Accept-Language: zh-CN, zh, en

• 数据类型在恳求头中的表现

在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等恳求头字段进行内容洽谈的时分，还能够用一种特别的“q”参数标明权重来设定优先级，这儿的“q”是“quality factor”的意思。权重的最大值是 1，最小值是 0.01，默认值是 1，假如值是 0 就标明拒绝。具体的办法是在数据类型或言语代码后边加一个“;”，然后是“q=value”。服务器会在呼应头里多加一个 Vary 字段，记载服务器在内容洽谈时参考的恳求头字段。

（七）HTTP怎么传输大文件

1.数据紧缩

前面提到的accept-encoding恳求头能够算是是一种传输大文件的处理办法，服务器能够挑选一种阅览器支撑的数据紧缩办法放进content-encoding呼应头里，再把原数据紧缩后回来给客户端。缺陷是这种办法只对文本有较好地紧缩率，关于图片音频等自身就现已高度紧缩的多媒体数据束手无策。

2.分块传输
在HTTP头部标明为Transfer-Encoding: chunked,指报文里的body部分不是一次性发过来的，而是分为许多chunked分块发送。Transfer-Encoding: chunked和Content-Length这两个字段是互斥的，也便是说呼应报文里这两个字段不能一起呈现，一个呼应报文的传输要么是长度已知，要么是长度不知道（chunked），这一点你必定要记住。

3.规模恳求
假如想获取某个大文件其间的片段，分块传输就没办法满意这样的需求。HTTP协议提出了规模恳求这样的概念，答应客户端只获取文件的某一部分。客户端先发个HEAD恳求看看服务器是否支撑规模恳求，服务器有必要在Accept-Ranges呼应头中告知客户端是否具有规模恳求的才干。恳求头Ranges是HTTP规模恳求的专用字段，值的格局是bytes=x-y标明x ~ y之间的规模。服务端在收到 Ranges恳求头时，首要验证x-y的规模是否合法（x和y能够省掉，省掉x则标明从后往前，省掉y则标明早年往后），其次核算读取偏移量，回来206状况码和所读取的文件 ，终究在呼应头加上Content-Range标明实践回来的偏移量和总数,格局为bytes x-y/length。

规模恳求还支撑在一个头里界说多个x-y,这种情况需求一种特别的MIME类型multipart/byteranges,标明报文是有多段组成。

（八）HTTP衔接办理

http的通讯进程采取恳求/应对方法，在http0.9/1.0时期，每次建议恳求都需求树立衔接->发送数据->断开衔接，因为整个恳求的进程十分时刻短，早上的http也称为短链接无链接的协议。因为TCP简历衔接要经过三次握手四次挥手，整个进程需求3个RTT，而HTTP的一次简略恳求一般只需求2个RTT，那么被糟蹋掉的时刻有60%。

• Connection：keep-alive

HTTP1.1提出了长衔接的概念，也便是Keep-alive。在长衔接上树立一次TCP衔接能够发送多个HTTP恳求。但因为衔接是alive的，假如一向不封闭，就会占用很多的服务器资源，导致服务无法及时呼应真实的恳求，所以咱们也需求及时封闭衔接。能够经过在客户端恳求头添加Connection: close字段自动封闭衔接。服务端一般不会自动封闭衔接，但咱们也能够经过设置时长、恳求数等办法约好断开衔接的条件。

• 队头堵塞

根据恳求-应对方法的http协议，构成了串行的恳求队列（http1.1还提出了管道机制，即在同一个TCP衔接上不必等候上一个恳求的呼应即可宣布下个恳求，不过客户端仍是依照正常次第承受呼应，这种做法并没带来任何功能上的改善，所以默认坚持封闭），假如队首的恳求处于堵塞状况，那么后边的恳求也无法正常呼应成果便是更长时刻的功能糟蹋。

并发衔接和域名分片是对队头堵塞的针对性优化战略，阅览器约束每个客户端能够并发树立6～8个衔接，又能够将多个域名指向同一个服务器，这样实践的衔接数量就更多了，是一种用数量处理质量的思路。

• 重定向

当咱们在阅览器输入一个url再按下回车，页面跳转到咱们输入的地址中，这种行为便是自动跳转。阅览器还支撑被迫跳转，也便是HTTP的重定向。

状况码

在前面了解过HTTP状况码，3XX即标明为重定向。下面具体介绍下各个状况码的意义。

301指永久重定向，可能是域名下线，域名搬迁等原因，原地址不再保护。此刻阅览器在重定向的一起记载重定向后的地址，下次拜访该域名就自动拜访新的URI了。

302指暂时重定向，可能是服务器保护、暂时封闭等原因，暂时跳转到新的地址上，此刻阅览器不会记载重定向的地址，以为原地址仍是有用的，下次拜访时仍是优先拜访原地址。

303相似 302，但要求重定向后的恳求改为 GET 办法，拜访一个成果页面，避免 POST/PUT 重复操作。

307相似 302，但重定向后恳求里的办法和实体不答应改变，意义比 302 更清晰。

308相似 307，不答应重定向后的恳求改变，但它是 301“永久重定向”的意义。

能够在地址栏输入bing.com,阅览器操控台中的状况如下图所示：

客户端是怎么处理重定向的

在阅览器地址栏输入bing.con咱们能够看到，状况码如下图所示：

咱们阅览器收到呼应之后根据呼应头中的Location字段判别重定向的地址，然后进行被迫跳转。

尽管重定向的用途很广，可是随之而来的也有更多问题。

第一个问题是“功能损耗”。很明显，重定向的机制决议了一个跳转会有两次恳求 – 应对，比正常的拜访多了一次。尽管 301/302 报文很小，但很多的跳转对服务器的影响也是不行忽视的。站内重定向能够长衔接复用，站外重定向就要开两个衔接。

第二的问题是循环重定向，比方 A->B->C->A,当咱们拜访A时就会产生无限跳转。所以HTTP协议特别规则，阅览器有必要具有检测“循环跳转”的才干，在发现这种情况时应当停止发送恳求并给出过错提示。

（九）cookie

HTTP 是“无状况”的，这既是长处也是缺陷。长处是服务器没有状况差异，能够很简略地组成集群，而缺陷便是无法支撑需求记载状况的业务操作。好在 HTTP 协议是可扩展的，后来创造的 Cookie 技能，给 HTTP 增加了“回忆才干”。

cookie相同存在于HTTP头部字段里。服务端能够运用set-cookie标识客户端身份，客户端则在恳求时带着cookie告知服务端自己的信息。cookie字段以key=value的格局保存，阅览器在一个cookie字段里能够寄存多对数据，用;切割。

Cookie 首要用于以下三个方面：

1.会话状况办理（如用户登录状况、购物车、游戏分数或其它需求记载的信息）

2.个性化设置（如用户自界说设置、主题等）

3.阅览器行为跟踪（如跟踪剖析用户行为等）

• 相关特点

生存周期

Expires俗称“过期时刻”，用的是绝对时刻点，能够了解为“截止日期”（deadline）。

Max-Age用的是相对时刻，单位是秒，阅览器用收到报文的时刻点再加上 Max-Age，就能够得到失效的绝对时刻。

Expires 和 Max-Age 能够一起呈现，两者的失效时刻不一致时阅览器会优先选用Max-Age核算失效期。假如服务器不设置Max-Age、Expries或许字段值为0指不能缓存cookie，但在会话期间是可用的，阅览器会话封闭之前能够用cookie记载用户的信息。

作用域

Domain和Path指定了 Cookie 所属的域名和途径，阅览器在发送 Cookie 前会从 URI 中提取出 host 和 path 部分，对比 Cookie 的特点。假如不满意条件，就不会在恳求头里发送 Cookie。一般 Path 就用一个“/”或许直接省掉，标明域名下的恣意途径都答应运用 Cookie。

安全性

HttpOnly标明此 Cookie 只能经过阅览器 HTTP 协议传输，制止其他办法拜访。这也是预防“跨站脚本”（XSS）进犯的有用手法。

SameSite能够防备“跨站恳求假造”（XSRF）进犯，SameSite = strict标明制止cookie在跳转链接时跨域传输。SameSite = lax略微宽松一点，答应在GET、HEAD等安全恳求办法中跨域带着。默认值为none,标明不约束cookie的带着和传输。

Secure标明这个cookie仅能用HTTPS协议加密传输，明文的HTTP协议会制止发送。但Cookie自身不是加密的，阅览器里仍是以明文的办法存在。

（十）HTTP缓存操控

• 服务器的缓存操控

阅览器在拜访页面资源时首要会查找缓存数据，假如没有再发送恳求，向服务器获取资源；服务器呼应恳求，回来资源，一起符号资源的有用期；阅览器缓存资源，等候下次重用。这便是客户端缓存。服务器符号资源有用期运用的头字段是Cache-Control，里边的值max-age=xxx便是资源的有用时刻（与cookie的max-age不同，这儿的max-age时刻的核算起点是呼应报文的创立时刻）。

此外在呼应报文里还能够用其他的值来更精确地指示阅览器应该怎么运用缓存：
no-store: 不答应缓存，用于某些改变十分频频的数据，例如秒杀页面。
no-cache: 能够缓存，但在运用之前有必要要去服务器验证是否过期。
must-revalidate: 假如缓存不过期就能够持续运用，但过期了就有必要去服务器验证。

• 客户端的缓存操控

阅览器也能够发Cache-Control，也便是说恳求 – 应对的两边都能够用这个字段进行缓存操控，相互洽谈缓存的运用战略。在阅览器行进、后退、重定向时cache-control就生效了，呼应头里有from disk cache字样，就说明阅览器未发送恳求，而是直接运用了本地缓存。

条件恳求

阅览器在改写页面时相当于在恳求头中添加了Cache-Control:no-cache,这样在改写页面时，仍是向服务端发送了恳求，并没有很好的运用到缓存。所以HTTP协议又界说了一系列“If”开头的“条件恳求”字段，专门用来检查验证资源是否过期。

条件恳求一共有 5 个头字段，咱们最常用的是if-Modified-Since和If-None-Match这两个。需求第一次的呼应报文预先供给Last-modified（终究修正时刻）和ETag（资源仅有标识），然后第二次恳求时就能够带上缓存里的原值，验证资源是否是最新的。假如资源没有变，服务器就回应一个“304 Not Modified”，标明缓存仍然有用，阅览器就能够更新一下有用期，然后放心大胆地运用缓存了。

• 署理缓存

署理服务器

署理服务器便是客户端和服务端之间的中心商，在中心的方位转发上游的恳求和下流的呼应。署理服务器在核算机领域有十分重要的功能：

1.负载均衡：面向客户端时屏蔽原服务器，署理服务器能够经过轮询、哈希等算法将流量分发，提高全体的功能。

2.健康检查：运用‘心跳’等机制监控服务器，确保服务器的可用性。

3.安全防护：保护被署理服务端的IP和流量，防止网络进犯或负载问题。

4.加密卸载：对外和对内运用不同的加密战略，节约加密本钱

5.内容缓存：暂存/复位服务器的呼应。

缓存署理

HTTP的服务端缓存首要由署理服务器来完成，署理服务器收到源服务器的呼应之后将报文转发给客户端的一起也存入自己的cache里，下次再有相同的恳求就能够直接发送304或许缓存数据，节约源服务器的本钱。

因为署理服务器既是服务端，又是客户端的特性，有一些特别的cache-control特点：

1.服务端

private: 标明只能客户端缓存，不答应署理服务器上缓存。
punlic:标明彻底揭露，客户端和署理服务器都能够缓存。
proxy-revalidate:要求署理服务器缓存过期后有必要回源验证。
s-maxage: 署理服务器缓存的有用期
no-transform: 不答应署理服务器转化数据格局。

2.客户端

max-stale: 假如署理上的缓存过期了也能够承受，但不能过期太多，超越 x 秒也会不要。
min-flash: 标明缓存少于x有用期就不要了。
only-if-cached:标明只承受署理缓存的数据，不承受源服务器的呼应。假如署理上没有缓存或许缓存过期，就应该给客户端回来一个 504。

HTTPS

因为 HTTP 天然生成“明文”的特点，整个传输进程彻底通明，任何人都能够在链路中截获、修正或许假造恳求 / 呼应报文，数据不具有可信性。只需具有秘要性、完好性、身份认证和不行否认性，咱们才以为这个恳求是安全的。HTTPS为HTTP增加了以上四个特性。

HTTPS实践上就指的是HTTP over TLS/SSl。是在本来的HTTP协议上加了一层TLS/SSL协议。

（一）SSL/TLS

SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层），由网景公司于 1994 年创造。SSL 开展到 v3 时现已证明晰它自身是一个十分好的安全通讯协议，所以在 1999 年它改名为 TLS（传输层安全， Transport Layer Security），现在运用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都现已被以为是不安全的。

• 秘要性（根据TLS1.2）

SSL/TLS经过加密（encrypt）来传输密文（cipher text）确保数据传输的安全性，只需具有密钥(key)的人才干够经过解密(decrypt)取得明文（plain text/clear text），加密解密的操作进程便是加密算法。所以“密钥”是一长串的数字，约好俗成的度量单位是“位”（bit）。比方，说密钥长度是 128，便是 16 字节的二进制串，密钥长度 1024，便是 128 字节的二进制串。依照密钥的运用办法，加密能够分为两大类：对称加密和非对称加密。

对称加密

顾名思义，加密解密都运用相同的密钥就叫做对称加密。TLS里现在常用的有 AES 和 ChaCha20。

AES 的意思是“高档加密规范”（Advanced Encryption Standard），密钥长度能够是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，功能也很好，并且有的硬件还会做特别优化，所以十分盛行，是运用最广泛的对称加密算法。

ChaCha20 是 Google 规划的另一种加密算法，密钥长度固定为 256 位，纯软件运行功能要超越 AES，曾经在移动客户端上比较盛行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势。

非对称加密

对称加密看上去很好的完成了秘要性，可是还有一个问题便是怎么安全的传输密钥。因为在加密算法中,只需具有密钥就能够解密，假如密钥在传输进程中被盗取，也就无秘要性可言。为了处理这个问题，又有了非对称加密算法。他具有两个密钥,别离是公钥（public key）和私钥（private key）,公钥是揭露的，而私钥是严厉保密的。公钥和私钥有个特别的“单向”性，尽管都能够用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。非对称加密能够处理密钥交流的问题。网站秘密保管私钥，在网上恣意分发公钥，你想要登录网站只需用公钥加密就行了，密文只能由私钥持有者才干解密。而黑客因为没有私钥，所以就无法破解密文。

非对称加密算法的规划要比对称算法难得多，在 TLS 里只需很少的几种，比方 DH、DSA、RSA、ECC 等。

RSA 可能是其间最著名的一个，几乎能够说对错对称加密的代名词，它的安全性根据“整数分解”的数学难题，运用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是十分困难的。

ECC对错对称加密里的“后起之秀”，它根据“椭圆曲线离散对数”的数学难题，运用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交流，ECDSA 用于数字签名。相对RSA，ECC在安全和功能上都有更明显的优势，160位的ECC相当于1024位的RSA，260位的ECC相当于2048位的RSA。

混合加密

尽管非对称加密没有密钥交流的难题，但因为它们都是根据杂乱的数学难题，运算速度很慢，即使是 ECC 也要比 AES 差上好几个数量级。所以现在TLS运用混合加密，使二者扬长避短，既能高效加密解密，又能安全的进行数据传输。

在树立衔接之初先运用非对称加密的办法传递密钥，然后用随机数产生对称算法运用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，一般只需 16 字节或 32 字节，所以慢一点也无所谓。对方拿到密文后用私钥解密，取出会话密钥。这样，两边就完成了对称密钥的安全交流，后续就不再运用非对称加密，全都运用对称加密。

• 完好性

摘要算法

完成完好性的手法首要是摘要算法（Digest Algorithm），也便是常说的散列函数、哈希函数（Hash Function）。能够把摘要算法近似地了解成一种特别的加密算法，它能够把恣意长度的数据加密成固定长度、并且绝无仅有的“摘要”字符串，且不能从紧缩后的密文中推导出原文。MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1便是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不行安全，在 TLS 里现已被制止运用了。现在TLS运用的是SLA-2。摘要算法确保了“数字摘要”和原文是彻底等价的。所以，咱们只需在原文后附上它的摘要，就能够确保数据的完好性。不过摘要算法不具有秘要性，所以真实的完好性仍是需求树立在秘要性之上。

• 身份认证&不行否认

数字签名

数字签名的原理其实很简略，便是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，并且得到的数字签名也很小，便利保管和传输。

数字证书和CA

因为公钥是任何人都能够发布的，所以咱们需求引进第三方来确保公钥的可信度，这个“第三方”便是咱们常说的 CA（Certificate Authority，证书认证机构），CA 对公钥的签名认证也是有格局的，要包括公钥的序列号、用途、颁布者、有用时刻等等，把这些打成一个包再签名，完好地证明公钥关联的各种信息，构成“数字证书”（Certificate）。小一点的 CA 能够让大 CA 签名认证，但链条的终究，也便是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或许“根证书”（Root Certificate）。你有必要相信，不然整个证书信赖链就走不下去了。

（二）TLS1.2树立衔接的进程

• TLS协议的组成

记载协议（Record Protocol）: 规则了 TLS 收发数据的底子单位：记载（record）。一切的其他子协议都需求经过记载协议宣布，但多个记载数据能够在一个 TCP 包里一次性宣布。

警报协议（Alert Protocol）: 的责任是向对方宣布警报信息，有点像是 HTTP 协议里的状况码。比方，protocol_version 便是不支撑旧版本，bad_certificate 便是证书有问题，收到警报后另一方能够挑选持续，也能够立即停止衔接。

握手协议（Handshake Protocol）: 是 TLS 里最杂乱的子协议，要比 TCP 的 SYN/ACK 杂乱的多，阅览器和服务器会在握手进程中洽谈 TLS 版本号、随机数、暗码套件等信息，然后交流证书和密钥参数，终究两边洽谈得到会话密钥，用于后续的混合加密体系。

改变暗码规范协议（Change Cipher Spec Protocol）: 是一个“通知”，告知对方，后续的数据都将运用加密保护。那么反过来，在它之前，数据都是明文的。

• 根据ECDHE 的 TLS1.2 握手

（三）TLS1.3

HTTP/2

HTTP1.X引进了Cookie处理了无状况的问题、经过引进TLS/SSL处理了明文传输不安全的问题。那接下来HTTP2的发力点就放在功能层面了。Google首要创造了SPDY协议，随后互联网规范化安排IETF以SPDY 为根底发布了HTTP2。HTTP2关于功能上的优化首要由以下几点动身：1. 包头过大 2. 队头堵塞 。

（一）功能优化

• 包头过大(头部紧缩)

在HTTP1.x时期，许多恳求恳求体和呼应体的巨细远远小于头部字段的巨细，比方GET恳求，301/302/204呼应。并且许多头部字段是重复的，HTTP/1.x糟蹋了很多的带宽在传输重复的头字段上，所以，HTTP/2 把“头部紧缩”作为功能改善的一个重点。

HPACK算法是专门为紧缩 HTTP 头部定制的算法，与 gzip、zlib 等紧缩算法不同，它是一个“有状况”的算法，需求客户端和服务器各自保护一份“索引表”，紧缩宽和紧缩便是查表和更新表的操作。为了便利办理和紧缩，HTTP/2 废除了原有的起始行概念，把起始行里边的恳求办法、URI、状况码等一致转化成了头字段的办法, 为了与“真头字段”区别开来，这些“伪头字段”会在姓名前加一个“:”，比方“:authority” “:method” “:status”，别离标明的是域名、恳求办法和状况码。废除了起始行里的版本号和过错原因短语。用索引号标明重复的字符串，还釆用哈夫曼编码来紧缩整数和字符串，能够到达 50%~90% 的高紧缩率。

下面的这个表格列出了“静态表”的一部分，这样只需查表就能够知道字段名和对应的值，比方数字“2”代表“GET”，数字“8”代表状况码 200。

新增的头字段或许值保存在动态表（Dynamic Table）里，它添加在静态表后边，结构相同，但会在编码解码的时分随时更新。比方说，第一次发送恳求时的“user-agent”字段长是一百多个字节，用哈夫曼紧缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时分就不必再重复发那么多字节了，只需用一个字节发送编号就好。

• 队头堵塞(二进制分帧、流式传输)

根据恳求-应对方法的http协议存在队头堵塞的问题，前面提到的并发衔接和域名分片都是牺牲数量处理质量的思路。而HTTP2选用了二进制分帧➕流式传输的办法来处理这个问题。

二进制分帧

HTTP/2把本来的Header+Body的音讯“打散”为数个小片的二进制“帧”（Frame），用HEADER帧寄存头数据、DATA帧寄存实体数据。

流式传输

HTTP/2还界说了一个“流”（Stream）的概念，它是二进制帧的双向传输序列，同一个音讯往复的帧会分配一个仅有的流 ID。你能够把它幻想成是一个虚拟的“数据流”，在里边活动的是一串有先后次第的数据帧，这些数据帧依照次第组装起来便是HTTP/1里的恳求报文和呼应报文。HTTP/2 能够在一个 TCP 衔接上用“流”一起发送多个“碎片化”的音讯，这便是常说的“多路复用”（ Multiplexing）,多个往复通讯都复用一个衔接来处理。在“流”的层面上看，音讯是一些有序的“帧”序列，而在“衔接”的层面上看，音讯却是乱序收发的“帧”。多个恳求 / 呼应之间没有了次第联系，不需求排队等候，也就不会再呈现“队头堵塞”问题，下降了推迟，大幅度提高了衔接的运用率。

帧开头是帧长度(不包括报文头的9个字节)，默认上限是2^14，最大是2^24，也便是说 HTTP/2的帧一般不超越16K，最大是 16M。

后边的一个字节是帧类型，大致能够分红数据帧和操控帧两类，HEADERS帧和DATA帧归于数据帧，寄存的是 HTTP 报文，而 SETTINGS、PING、PRIORITY 等则是用来办理流的操控帧。

第 5 个字节是十分重要的帧标志信息，能够保存 8 个标志位，带着简略的操控信息。常用的标志位有 END_HEADERS 标明头数据完毕，END_STREAM 标明单方向数据发送完毕（即 EOS，End of Stream）。

报文头里终究 4 个字节是流标识符，也便是帧所属的“流”，接纳方运用它就能够从乱序的帧里辨认出具有相同流 ID 的帧序列(在 HTTP/2 衔接上，尽管帧是乱序收发的，但只需它们都具有相同的流 ID，就都归于一个流，并且在这个流里帧不是无序的，而是有着严厉的先后次第。)，按次第组装起来就完成了虚拟的“流”。流标识符尽管有 4 个字节，但最高位被保留不必，所以只需 31 位能够运用，也便是说，流标识符的上限是 2^31，大约是 21 亿。

流的特点

1.流是可并发的，一个 HTTP/2 衔接上能够一起宣布多个流传输数据，也便是并发多恳求，完成“多路复用”。

2.客户端和服务器都能够创立流，两边互不搅扰。

3.流是双向的，一个流里边客户端和服务器都能够发送或接纳数据帧，也便是一个“恳求 – 应对”来回。

4.流之间没有固定联系，互相独立，但流内部的帧是有严厉次第的。

5.流能够设置优先级，让服务器优先处理，比方先传 HTML/CSS，后传图片，优化用户体验。

6.流 ID 不能重用，只能次第递加，客户端建议的 ID 是奇数，服务器端建议的 ID 是偶数。

7.在流上发送“RST_STREAM”帧能够随时停止流，撤销接纳或发送。

8.第 0 号流比较特别，不能封闭，也不能发送数据帧，只能发送操控帧，用于流量操控。

• 协议栈

HTTP/3

HTTP/2 尽管运用“帧”、“流”、“多路复用”，没有了“队头堵塞”，但这些手法都是在运用层里，而在 TCP 协议里，仍是会产生“队头堵塞”。Google 在推 SPDY 的时分就现已认识到了这个问题，所以就又创造了一个新的QUIC协议，让 HTTP 跑在 QUIC 上而不是 TCP 上。而这个HTTP over QUIC便是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的根底上又完成了质的腾跃，真实完美地处理了队头堵塞问题。

（一）QUICK

QUIC 根据 UDP，而 UDP 是“无衔接”的，不需求“握手”和“挥手”，所以天然生成就要比 TCP 快。QUIC 全面选用加密通讯,它运用自己的帧“接收”了 TLS 里的“记载”，握手音讯、警报音讯都不运用 TLS 记载，直接封装成 QUIC 的帧发送，省掉了一次开销。QUIC 的底子数据传输单位是包（packet）和帧（frame），一个包由多个帧组成，包面向的是“衔接”，帧面向的是“流”。

QUIC 运用不通明的“衔接 ID”来符号通讯的两个端点，客户端和服务器能够自行挑选一组 ID 来符号自己，这样就解除了 TCP 里衔接对“IP 地址 + 端口”（即常说的四元组）的强绑定，支撑“衔接搬迁”（Connection Migration）。

（二）HTTP/3

因为 QUIC 自身就现已支撑了加密、流和多路复用，所以HTTP/3不需求界说流，而是直接运用 QUIC 的流。因为流办理被“下放”到了 QUIC，所以 HTTP/3 里帧的结构也变简略了。帧头只需两个字段：类型和长度，并且相同都选用变长编码，最小只需求两个字节。

引荐阅览

快保藏！最全GO言语完成规划方法

可能是最全的数据仓库全景科普和开发办法论！

深化浅出带你走进Redis！

CPU怎么与内存交互？

阅览原文