前言

HTTP(HyperText Transfer Protocal) 是超文本传输协议，http开始被打造出来便是为了传输文本内容，用作学术交流，将html文本布局传来传去，那个时分是没有后端的概念的，数据全是写死的，相似电子书。本期就带大家回忆下http的开展历程，认清咩个版别的优缺陷~

HTTP/0.9

  1. 客户端发送get恳求，比方恳求一个/index.html
  2. 服务端接纳恳求，读取对应的html文件，以ASCII的字符流回来给客户端

特色

  1. 只要恳求行，没有恳求头和恳求体，因而0.9版别的http也被称之为单行协议
  2. 因而也没有呼应头
  3. 传输的内容是以ASCII的字符流

推进0.9到1.0的开展是网景公司，世界上第一款阅读器便是网景公司开发的，自从他推出阅读器后，万维网（World Wide Web）就不再是仅仅做学术交流了，互联网高速开展，万维网联盟（W3C）树立，http工作组一起树立，这个工作组专门致力于http协议的更新，以前查html,css,js便是在w3c上查找，相似现在的mdn

跟着互联网需求的添加，0.9不再满足，1.0诞生

0.9只能传文本格局，用户接触阅读器不仅仅要看文本，还需求看图片，音频等格局

HTTP/1.0

  1. 相比较0.9，支撑多种类型文件的传输，且不限于ASCII编码办法

  2. 已然多种文件，那么就需求信息告知阅读器怎么加载这些文件，因而引进恳求头，呼应头来让客户端和服务端愈加深化的交流，而且是key-value的办法

为什么有了恳求头和呼应头就能支撑多种文件的数据传输

恳求头

accept: text/html 告知服务端我期望接纳到一个html的文件

accept-encoding: gzip, deflate, br 告知服务端以这种办法紧缩

accept-language: zh-CN 告知服务端以中文的格局回来

呼应头

content-encoding: br 告知阅读器紧缩办法是br

content-type: text/html; charset=utf-8 告知阅读器以这种办法，编码加载

1.0时，比方展现一个页面，用到几个js文件，css文件，用一次就会单独用http恳求一次，文件不多还好，可是跟着需求添加，一个页面可能会用到许多js文件，以及第三方库，或许说图片资源，展现一个页面会发许多次恳求，十分影响性能

HTTP/1.1

  1. 耐久衔接，一个tcp衔接树立，能够传输多个http恳求，减少了许多的tcp衔接和断开衔接带来的开支

    耐久衔接带来了队头堵塞的问题，这个问题没办法处理

  2. Chunk transfer机制处理动态数据包的长度

1.0时一个页面展现每用到一个js脚本，图片等都需求从头树立一次衔接，做无畏的重复，因而1.1推出了耐久衔接或许长衔接来处理这个问题

1.1能够树立一次tcp衔接后，发送多个http恳求，最终tcp封闭衔接，耐久衔接在1.1是默认开启的，当然你也能够经过改恳求头中的Connection字段，Connection: keep-alive || close ，close便是封闭的

实践开发中，页面一切的资源不可能悉数一次性恳求回来，比方有个按钮，点击后才会发恳求，假设我页面初度加载的tcp恳求还没有封闭，就点击了按钮，所以就会再次树立一次耐久衔接，这种树立是有数量约束的，通常为6-8个keep-alive，也便是tcp耐久衔接

凡事有利有弊，这种办法能够1次tcp衔接 n 次http恳求，咱们设想一个情形，如果 n 个http恳求有个http恳求的数据许多，形成很慢，后边的http还会过来吗？不能，当年的http恳求需求次序，因而这就导致了http的队头堵塞

队头堵塞

  • 管线化：批量化发恳求（放弃）

针对这个http队头堵塞问题，http工作组想过一个处理计划，管线化，一次性把http恳求悉数发出去，这些http恳求都会打上次序符号，确保接纳的次序，谷歌和火狐以前采用过这个计划，可是不清楚出于什么原因放弃了这个计划

后边恳求头中添加了一个host字段，这就导致了虚拟机技能的老练，阅读器的同源战略便是经过host字段判断域名是否一致，虚拟机也会被分配ip，虚拟机和主机的ip是不同的，host最初便是用来差异虚拟机的域名地址的

别的，1.0时，需求在呼应头中设置数据的巨细，字段content-Length: 1024 比方这个便是1024个字节的巨细，可是有时分后端也不清楚自己发送的数据多大，因为数据可能是动态的，这就导致了客户端不清楚自己是否接纳结束，1.1所以推出片段化数据，将数据分割成若干个恣意巨细的数据块，每个数据块发送时带有自身的长度，最终会发送一个长度为0的数据块来标志发送结束，这就有点像是柯里化函数，最终不传参数才会履行函数

阅读器的cookie也是这个时分加入的，cookie尽管是阅读器的存储可是大部分是归于后端负责的，前端能够读取cookie的内容，别的cookie的内容也能够被设置为可读取和不可读取，一般为了安全性会设置不可读取，这便是为了避免脚本攻击

HTTP/2.0

1.1的问题

  1. 带宽用不满，多条tcp衔接竞赛带宽导致每条tcp衔接中能被分配的带宽大大降低
  2. tcp的慢发动：拥塞操控导致一定会慢发动，可是会推延页面关键资源加载时间
  3. http队头堵塞问题，堵塞时会糟蹋带宽

1.1存在队头堵塞问题，以及6个耐久衔接，也便是说一个阅读器只能一起存在6个tcp的树立，一个tcp树立有多个http恳求，其实这6个耐久衔接会共享网络速度，假设1000M宽带，网速最终便是1000/6M的效果，也便是说对网速的利用率很低，其实形成网速低的原因还有个便是tcp的慢发动，到达抱负速度有个进程，这个慢发动便是为了处理网络拥塞问题

tcp慢发动有个问题便是，对于很小的css，js文件，就没必要耗时这么久，文件大还好，文件小可是文件又很重要就很难受

多路复用

  1. 一个域名只运用一个tcp长衔接
  2. 将每个恳求分成一帧一帧的数据进行传输并打上符号，一起发送给服务端，且能够在重要资源恳求中符号为加急，服务端接纳到带有各种编号的数据帧后，能够差异哪个数据帧加急，优先处理和呼应该恳求的数据帧（经过引进了二进制分帧层完成多路复用）

首要，tcp的慢发动咱们必定无法进行优化的，只能进行躲避，因而我就尽可能的少点tcp的树立衔接，2.0的多路复用便是一个域名只运用一个tcp的长衔接，6个变1个，这样就不会发生多个keep-alive占用带宽问题，因而网速大大提高

别的，多路复用还将每个恳求都划分成一帧一帧的姿态，每帧都会符号一些数据，比方符号加急，这样就能够处理http队头堵塞问题，里边便是因为引进了二进制分帧层

2.0一起引进了https

HTTP/HTTPS

首要一个恳求行大概如下这样

GET /image/logo.png HTTP/1.1

这儿提到get，顺带带大家认清get和post的差异

GET vs POST

get和post本质上没有许多差异，真要说差异需求从用法上来说

get没有加密效果！

要从用法上说就得扯上 副作用 和 幂等

  • 副作用：对服务器上的资源有变更

    比方，搜索是不会对数据发生变更的，注册会有

  • 幂等：注册10次和20次不是幂等，新增了数据，可是更改文章10次和20次是幂等，改来改去仍是那么多数据

get多作用于无副作用，幂等的场景，比方搜索

post多作用于有副作用，无幂等的场景，比方注册

从技能角度来说，get恳求能缓存，post不能缓存

阅读器阅读页面会有前史页面的，前史页面就有url，get恳求的数据放在url中，因而，get恳求会被阅读器缓存住

要说安全，post恳求确实是会安全一点，post恳求放在恳求体中，get恳求拼接在url中

别的url的长度是有限的，所以get恳求数据有约束，而post不会

post恳求支撑更多的编码类型，而且不对数据类型做约束

用过koa的小朋友都清楚，koa默认是不支撑post的，需求别的安装依靠，便是因为post的数据类型太多了，不支撑

总结

  1. get用于无副作用幂等的场景，post用于有副作用不幂等的场景
  2. get恳求能缓存，post不能
  3. post相对安全一点，post的参数是在恳求体中，get的参数是拼接在url中
  4. url的长度有约束，所以get恳求会受影响
  5. post支撑更多的编码类型，且不对数据类型做约束

这儿也顺带放下面试官喜欢问你的状况码

http状况码

200 恳求成功，恳求在服务端被正确处理

204 呼应成功，没有数据

205 服务器处理成功，阅读器应重置文档视图

206 服务器成功处理了部分get恳求

301 资源永久重定向 资源 后端换当地不作任何操作便是404

302 资源临时重定向

303 让你查看其他地址

304 恳求的资源没有修正，服务端不会回来任何资源

400 恳求语法过错，服务器看不懂

401 恳求没有携带信息，比方token认证失利

403 恳求被回绝 敏感词

404 找不到资源

500 服务器内部过错，无法完结恳求

501 服务器不支撑当时恳求所需的功用

503 服务器系统维护或许超载，暂时无法处理客户端的恳求

回到http/https的比较

https是加密后的http，这个s便是TLS

因而https = http + tls

TLS位于传输层之上，应用层之下，TLS中包含了对称加密和非对称加密

对称加密

对称加密需求客户端，服务端两边都知道加密的办法，以及解密的办法，或许说两边都有相同的密钥，都知道怎么加密和解密

对称加密有个很大问题，两边怎么清楚一起的密钥？经过传输的办法，密钥也是经过网络传输，这个进程要是被截取就完蛋了

非对称加密

非对称加密不同，非对称加密会有个公钥和私钥，公钥用于加密，私钥用于解密，比方服务端发送一个公钥给客户端，客户端会用这个公钥进行加密，创建一个密钥，用公钥来加密这个密钥，给到服务端，服务端用独有的私钥进行解密得到密钥，两个进程都不怕被截取

聊聊http开展史

tls是先用非对称加密让两边都有密钥，再对称加密进行数据传输

http2.0自身是没有问题的，问题首要存在tcp身上，因为这些版别的http都是根据tcp，tcp自身就有慢发动问题，不够高效

HTTP/3.0

http2.0的问题在于tcp，因为tcp有个慢发动问题，其实tcp还有个问题便是tcp的队头堵塞，因为tcp需求确保数据包传输的次序，数据在传输的进程会出现丢包的问题，tcp有个超时重传的机制，为确保次序就需求等待，这个进程就导致了队头堵塞

因而2.0的问题便是tcp的慢发动和“队头堵塞`

这个时分你必定想，已然tcp有问题就去处理tcp的问题，实则不可，因为tcp作用于物理层，比方交换机便是物理层，里边的tcp要是变更了，全球的交换机就需求筛选掉，就像是js的null被作为obj相同，改不了了

像是这种tcp的问题无法处理，被称之为tcp死板

其实导致tcp死板的原因还有一点是操作系统，tcp协议是经过操作系统的内核完成的，应用程序只能运用不能修正

因而http工作组十分无法，想要处理这些问题就只能不必tcp协议了

3.0根据的协议是QUIC协议

quic协议相同面临着tcp相同的挑战，因为quic协议需求硬件的支撑，比较费事，可是又比更新tcp好，因为新增个quic协议至少不会让设备崩掉，更新tcp会很费事

这也便是为何3.0目前还没有遍及的原因

QUIC协议

quic协议不是从0打造的，它是根据udp协议，udp的特色是高效，尽管不可靠，quic协议在udp上完成了相似于tcp的多路复用，可靠性传输等功用

聊聊http开展史

  1. 完成了相似于tcp的流量操控和可靠性传输
  2. 集成了TLS加密
  3. 完成了HTTP2中的多路复用

缺陷：需求阅读器，服务器，操作系统支撑quic协议，遍及开还需求一段时间

最终

一段话总结下http开展史：

0.9是开始版别，此时的http被称之为单行协议，因为只要恳求行，没有恳求头恳求体，以ASCII码的办法传输，只能支撑html文件类型，后边跟着文件类型的添加，1.0诞生，能够支撑多种文件类型的传输，而且不仅仅只支撑ASCII这一种编码，引进了恳求头呼应头，因为里边的字段信息才能够差异文件类型等操作，可是1.0有个缺陷便是一个文件对应一个tcp的树立，后边1.1诞生，推出了keep-alive长衔接，一个tcp的树立与断开之间能够有多个http恳求，可是keep-alive的数量有限，6-8个，而且keep-alive带来了http队头堵塞的问题，便是一个http恳求如果很慢，会堵塞后边的http恳求，以前推出过管线化办法去处理，可是因为某些原因不采用了，至今无果，此时1.1还推出了host字段，导致后边虚拟机技能的老练，而且1.0时的数据包会包含content-Length字段，可是有时分后端的数据是动态的，因而1.1推出Chunk transfer机制来处理动态数据，它是经过切片的办法进行传输，最终发送一个长度为0的数据块来标志发送结束，因为1.1的队头堵塞问题，以及6个keep-alive一起占用网速的原因，对带宽的利用率很低，2.0诞生，2.0的多路复用，将6个keep-alive变成了一个，有效提高宽带利用率，而且经过二进制分帧层完成了对数据帧的传输次序办理，处理了http队头堵塞问题，可是因为tcp死板问题，比方无法处理它的慢发动和队头堵塞问题，3.0摒弃了tcp协议，采用了quic协议，这个协议根据udp，udp高效可是不可靠，所以quic又完成了相似于tcp的流量操控和可靠性传输，而且还有加密，完成了多路复用，总之很强大，仅仅目前还没有遍及开

如果你对春招感兴趣，能够加我的个人微信：Dolphin_Fung，我和我的小伙伴们有个面试群，能够进群讨论你面试进程中遇到的问题，咱们一起处理

别的有不懂之处欢迎在评论区留言，如果觉得文章对你学习有所帮助，还请”点赞+评论+收藏“一键三连，感谢支撑！