1 HTTP / HTTPS 概述

2 HTTP/2

2.1 HTTP/2 辉煌不在？

虽然HTTP/2标准在2015年5月就以RFC 7540正式发表了，并且多数浏览器在2015年底就支持了。
但是，真正被广泛使用起来要到2018年左右，但是也是在2018年，11月IETF给出了官方批准，认可HTTP-over-QUIC成为HTTP/3。
2018年的时候，我写过一篇文章介绍《HTTP/2到底是什么？》，那时候HTTP/2还是个新技术，刚刚开始有软件支持，短短两年过去了，现在HTTP/3已经悄然而至了。
根据W3Techs的数据，截至2019年6月，全球也仅有36.5%的网站支持了HTTP/2。所以，可能很多网站还没开始支持HTTP/2，HTTP/3就已经来了。
所以，对于很多网站来说，或许直接升级HTTP/3是一个更加正确的选择。

2.2 回顾 HTTP/2

在阅读本文之前，强烈建议大家先阅读下《HTTP/2到底是什么？》这篇文章，这里面介绍了HTTP的历史，介绍了各个版本的HTTP协议的诞生的背景。
当你读到这里的时候，我默认大家对HTTP/2有了一定的基本了解。
我们知道，HTTP/2的诞生，主要是为了解决HTTP/1.1中的效率问题，HTTP/2中最核心的技术就是多路复用技术，即允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。

同时还实现了二进制分帧、header压缩、服务端推送等技术。

从HTTP/1.0诞生，一直到HTTP/2，在这24年里，HTTP协议已经做过了三次升级，但是有一个关键的技术点是不变的，那就是这所有的HTTP协议，都是基于TCP协议实现的。

流水的HTTP，铁打的TCP。这是因为相对于UDP协议，TCP协议更加可靠。

虽然在HTTP/1.1的基础上推出HTTP/2大大的提升了效率，但是还是有很多人认为这只是个"临时方案"，这也是为什么刚刚推出没多久，业内就开始大力投入HTTP/3的研发与推广了。
而这背后的深层次原因也正是因为他还是基于TCP协议实现的。TCP协议虽然更加可靠，但是还是存在着一定的问题，接下来具体分析下。

2.3 HTTP/2 问题 : 队头阻塞问题

队头阻塞翻译自英文head-of-line blocking，这个词并不新鲜，因为早在HTTP/1.1时代，就一直存在着队头阻塞的问题。
但是很多人在一些资料中会看到有论点说HTTP/2解决了队头阻塞的问题。但是这句话只对了一半。

只能说HTTP/2解决了HTTP的队头阻塞问题，但是并没有解决TCP队头阻塞问题！

如果大家对于HTTP的历史有一定的了解的话，就会知道。

2.3.1 HTTP/1.1 引入【持久连接/请求管道(keep-alive)】 => 仍遗留【HTTP队头阻塞问题】

HTTP/1.1相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接（keep-alive）。
所谓的持久连接就是：

在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

引入了持久连接之后，在性能方面，HTTP协议有了明显的提升。

另外，HTTP/1.1允许在持久连接上使用请求管道，是相对于持久连接的又一性能优化。

所谓请求管道，就是在HTTP响应到达之前，可以将多条请求放入队列，当第一条HTTP请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。

但是，对于管道连接还是有一定的限制和要求的，其中一个比较关键的就是：

服务端必须按照与请求相同的顺序回送HTTP响应。

这也就意味着：

如果一个响应返回发生了延迟，那么其后续的响应都会被延迟，直到队头的响应送达。这就是所谓的HTTP队头阻塞。

2.3.2 HTTP/2 多路复用(引入【帧/消息/数据流】): 解决【HTTP队头阻塞】 => 仍依赖【TCP队头阻塞】

但是HTTP队头阻塞的问题在HTTP/2中得到了有效的解决。
HTTP/2废弃了管道化的方式，而是创新性的引入了帧、消息和数据流等概念。
客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。

因为没有顺序了，所以就不需要阻塞了，就有效的解决了HTTP队头阻塞的问题。

但是，HTTP/2仍然会存在TCP队头阻塞的问题，那是因为HTTP/2其实还是依赖TCP协议实现的。

TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。

但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。

HTTP/1.1的管道化持久连接，也是使得同一个TCP连接可以被多个HTTP连接使用，但是HTTP/1.1中规定一个域名可以有6个TCP连接。
而HTTP/2中，同一个域名只是用一个TCP连接。

所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的，那如果某一个请求造成了TCP队头阻塞，那么多个请求都会受到影响。

2.4 TCP握手时长

一提到TCP协议，大家最先想到的一定是它的三次握手与四次关闭的特性。

因为TCP是一种可靠通信协议，而这种可靠就是靠三次握手实现的，通过三次握手，TCP在传输过程中可以保证接收方收到的数据是完整，有序，无差错的。

但是，问题是三次握手是需要消耗时间的，这里插播一个关于网络延迟的概念。

网络延迟又称为 RTT（Round Trip Time）。

它是指一个请求从客户端浏览器发送一个请求数据包到服务器，再从服务器得到响应数据包的这段时间。

RTT 是反映网络性能的一个重要指标。

我们知道，TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。

另外，如果使用的是安全的HTTPS协议，就还需要使用TLS协议进行安全数据传输，这个过程又要消耗1个RTT（TLS不同版本的握手机制不同，这里按照最小的消耗来算）

那么也就是说，一个纯HTTP/2的连接，需要消耗1.5个RTT，如果是一个HTTPS连接，就需要消耗3-4个RTT。

而具体消耗的时长根据服务器和客户端之间的距离则不尽相同，如果比较近的话，消耗在100ms以内，对于用来说可能没什么感知，但是如果一个RTT的耗时达到300-400ms，那么，一次连接建立过程总耗时可能要达到一秒钟左右，这时候，用户就会明显的感知到网页加载很慢。

2.5 升级TCP是否可行？

2.5.1 网络中间设备僵化 => 协议僵化

基于上面我们提到的这些问题，很多人提出来说：既然TCP存在这些问题，并且我们也知道这些问题的存在，甚至解决方案也不难想到，为什么不能对协议本身做一次升级，解决这些问题呢？

其实，这就涉及到一个"协议僵化"的问题。

这样讲，我们在互联网上浏览数据的时候，数据的传输过程其实是极其复杂的。

我们知道的，想要在家里使用网络有几个前提，首先我们要通过运行商开通网络，并且需要使用路由器，而路由器就是网络传输过程中的一个中间设备。

中间设备是指插入在数据终端和信号转换设备之间，完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。

在我们看不到的地方，这种中间设备还有很多很多，一个网络需要经过无数个中间设备的转发才能到达终端用户。

如果TCP协议需要升级，那么意味着需要这些中间设备都能支持新的特性，我们知道路由器我们可以重新换一个，但是其他的那些中间设备呢？尤其是那些比较大型的设备呢？更换起来的成本是巨大的。

而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协议需要通过操作系统内核来实现，而操作系统的更新也是非常滞后的。

所以，这种问题就被称之为"中间设备僵化"，也是导致"协议僵化"的重要原因。这也是限制着TCP协议更新的一个重要原因。

所以，近些年来，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用！

2.6 放弃TCP？

上面提到的这些问题的根本原因都是因为HTTP/2是基于TPC实现导致的，而TCP协议自身的升级又是很难实现的。

那么，剩下的解决办法就只有一条路，那就是放弃TCP协议。

放弃TCP的话，就又有两个新的选择，是使用其他已有的协议，还是重新创造一个协议呢？

看到这里，聪明的读者一定也想到了，创造新的协议一样会受到中间设备僵化的影响。近些年来，因为在互联网上部署遭遇很大的困难，创造新型传输层协议的努力基本上都失败了！

所以，想要升级新的HTTP协议，那么就只剩一条路可以走了，那就是基于已有的协议做一些改造和支持，UDP就是一个绝佳的选择了。

2.Y 小结

因为HTTP/2底层是采用TCP协议实现的，虽然解决了HTTP队头阻塞的问题，但是对于TCP队头阻塞的问题却无能为力。

TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。

但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了 TCP队头阻塞。

另外，TCP这种可靠传输是靠三次握手实现的，TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。如果是HTTPS那么消耗的RTT就更多。

而因为很多中间设备比较陈旧，更新换代成本巨大，这就导致TCP协议升级或者采用新的协议基本无法实现。

所以，HTTP/3选择了一种新的技术方案，那就是基于UDP做改造，这种技术叫做QUIC。

那么问题来了，HTTP/3是如何使用的UDP呢？做了哪些改造？如何保证连接的可靠性？UDP协议就没有僵化的问题了吗？

2.X 参考文献

Q 相关面试问题

Q1 什么是HTTP？

HTTP协议是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

说道GET和POST，就不得不提HTTP协议，因为浏览器和服务器的交互是通过HTTP协议执行的，而GET和POST也是HTTP协议中的两种方法。

HTTP全称为Hyper Text Transfer Protocol，中文翻译为超文本传输协议，目的是保证浏览器与服务器之间的通信。HTTP的工作方式是客户端与服务器之间的请求-应答协议。

Q2 HTTP 与 HTTPS 的区别?

Q3 常用HTTP状态码？

HTTP状态码表示客户端HTTP请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。
状态码的类别：

Q4 GET和POST区别？

[1] HTTP 协议的请求方法
HTTP协议中定义了浏览器和服务器进行交互的不同方法，基本方法有4种，分别是GET，POST，PUT，DELETE。这四种方法可以理解为，对服务器资源的查，改，增，删。

GET：从服务器上获取数据，也就是所谓的查，仅仅是获取服务器资源，不进行修改。
POST：向服务器提交数据，这就涉及到了数据的更新，也就是更改服务器的数据。
PUT：英文含义是放置，也就是向服务器新添加数据，就是所谓的增。
DELETE：从字面意思也能看出，这种方式就是删除服务器数据的过程。

[1] HTTP 协议中GET与POST的区别？

Get是不安全的。

因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的。但是这种做法也不时绝对的，大部分人的做法也是按照上面的说法来的，但是也可以在get请求加上 request body，给 post请求带上 URL 参数。

Get请求提交的url中的数据最多只能是2048字节

这个限制是浏览器或者服务器给添加的，http协议并没有对url长度进行限制，目的是为了保证服务器和浏览器能够正常运行，防止有人恶意发送请求。Post请求则没有大小限制。

Get限制Form表单的数据集的值必须为ASCII字符；而Post支持整个ISO10646字符集。
Get执行效率却比Post方法好。Get是form提交的默认方法。
GET产生一个TCP数据包；POST产生2个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

Q5 什么是对称加密与非对称加密?

对称密钥加密是指加密和解密使用同一个密钥的方式。这种方式存在的最大问题就是密钥发送问题，

即：如何安全地将密钥发给对方

而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，非常的慢

Q6 什么是HTTP2?

HTTP2 可以提高了网页的性能。

在 HTTP1 中浏览器限制了同一个域名下的请求数量（Chrome 下一般是六个），当在请求很多资源的时候，由于队头阻塞当浏览器达到最大请求数量时，剩余的资源需等待当前的六个请求完成后才能发起请求。

HTTP2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。

多路复用可以绕过浏览器限制同一个域名下的请求数量的问题，进而提高了网页的性能。

Q7 Session、Cookie和Token的主要区别?

HTTP协议本身是无状态的。什么是无状态呢，即服务器无法判断用户身份。
什么是cookie?

cookie是由Web服务器保存在用户浏览器上的小文件（key-value格式），包含用户相关的信息。
客户端向服务器发起请求，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。
客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户身份。

什么是Session？

session是·依赖Cookie·实现的。session是服务器端的用户会话对象
session 是浏览器和服务器会话过程中，服务器分配的一块储存空间。
服务器默认为浏览器在cookie中设置 sessionid，浏览器在向服务器请求过程中传输 cookie 包含 sessionid ，服务器根据 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。

cookie与session区别?

存储位置与安全性：cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高；

存储空间：单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，session无此限制

占用服务器资源：session一定时间内保存在服务器上，当访问增多，占用服务器性能，考虑到服务器性能方面，应当使用cookie。

Q8 什么是Token？

Token的引入：Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。

Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

使用Token的目的：Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位

Q9 session与token区别？

session机制存在服务器压力增大，CSRF跨站伪造请求攻击，扩展性不强等问题；
session存储在服务器端，token存储在客户端
token提供认证和授权功能，作为身份认证，token安全性比session好；
session这种会话存储方式方式只适用于客户端代码和服务端代码运行在同一台服务器上，token适用于项目级的前后端分离（前后端代码运行在不同的服务器下）

Q10 Servlet是线程安全的吗？

Servlet不是线程安全的，多线程并发的读写会导致数据不同步的问题。
解决的办法是尽量不要定义name属性，而是要把name变量分别定义在doGet()和doPost()方法内。虽然使用synchronized(name){}语句块可以解决问题，但是会造成线程的等待，不是很科学的办法。

注意：多线程的并发的读写Servlet类属性会导致数据不同步。但是如果只是并发地读取属性而不写入，则不存在数据不同步的问题。因此Servlet里的只读属性最好定义为final类型的。

Q11 Servlet接口中有哪些方法?

在Java Web程序中，Servlet主要负责接收用户请求HttpServletRequest，在doGet()，doPost()中做相应的处理，并将回应HttpServletResponse反馈给用户。Servlet可以设置初始化参数，供Servlet内部使用。

Servlet接口定义了5个方法，其中前三个方法与Servlet生命周期相关：

void init(ServletConfig config) throws ServletException
void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
void destory()
java.lang.String getServletInfo()
ServletConfig getServletConfig()

Q12 Servlet的生命周期?

Web容器加载Servlet并将其实例化后，Servlet生命周期开始，容器运行其init()方法进行Servlet的初始化；
请求到达时调用Servlet的service()方法，service()方法会根据需要调用与请求对应的doGet或doPost等方法；
当服务器关闭或项目被卸载时服务器会将Servlet实例销毁，此时会调用Servlet的destroy()方法。

init方法和destory方法只会执行一次，service方法客户端每次请求Servlet都会执行。
Servlet中有时会用到一些需要初始化与销毁的资源。因此，可以把初始化资源的代码放入init方法中，销毁资源的代码放入destroy方法中，这样就不需要每次处理客户端的请求都要初始化与销毁资源。

Cookie 与 Session，一般认为是两个独立的东西，Session采用的是在服务器端保持状态的方案，而Cookie采用的是在客户端保持状态的方案。
但为什么禁用Cookie就不能得到Session呢？因为Session是用Session ID来确定当前对话所对应的服务器Session，而Session ID是通过Cookie来传递的，禁用Cookie相当于失去了Session ID，也就得不到Session了。

假定用户关闭Cookie的情况下使用Session，其实现途径有以下几种：

手动通过URL传值、隐藏表单传递Session ID。
用文件、数据库等形式保存Session ID，在跨页过程中手动调用。

X 参考文献

标签：协议,HTTP,请求,队头,TCP,HTTPS,服务器,应用层
From： https://www.cnblogs.com/johnnyzen/p/17305813.html

[网络]应用层协议：HTTP / HTTPS