1 HTTP / HTTPS 概述

1.1 什么是HTTP协议？

摘自百度百科:

(资料图)

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。目的是保证浏览器与服务器之间的通信、为了提供一种发布和接收HTML页面的方法。HTTP的工作方式是客户端与服务器之间的请求-应答协议。

• HTTP协议 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范
• HTTP属于OSI网络七层协议模型中的"最上层":应用层协议。由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议 ( HTTP无状态协议，是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快 ) 。
• HTTP默认端口号为80。它也可以承载在TLS和SSL之上，通过加密、认证的方式实现数据传输的安全，称为HTTPS，HTTPS默认端口号为443。
• 早期HTTP用于传输网页HTML文件，发展到现在，应用变得广泛，客户端软件（PC，Android,iOS等）大部分通过HTTP传输数据。

1.2 从浏览器输入地址URL到呈现页面中间发生了什么事情(通信过程)?

1.2.1 简述

• 浏览器（客户端）进行地址解析。
• 将解析出的域名进行dns解析。
• 通过ip寻址和arp，找到目标（服务器）地址。
• 进行tcp三次握手，建立tcp连接。
• 浏览器发送数据，等待服务器响应。
• 服务器处理请求，并对请求做出响应。
• 浏览器收到服务器响应，得到html代码。
• 渲染页面。

通过以上这些步骤，就完成了一次完整的http请求

1.2.2 [Step1] 浏览器（客户端）进行了地址解析。

当我们在浏览器中输入一个地址，按下回车后，浏览器获取到的是一个字符串。浏览器此时要对这个地址进行解析，获取协议，主机，端口，路径等信息。

URL的一般格式为(手记会自动过滤尖括号，所以只能上传图片了)：例如：

http://www.imooc.com/article/draft/id/430这个网址缺少了一些东西，端口号，用户名，密码，query和flag都没有。这些东西都是非必须的，甚至协议、路径都可以不要，最简洁的方式为imooc.com，浏览器会对一些默认的东西进行补齐。例如：互联网url默认端口号为80，浏览器默认补齐功能会补齐协议http，有些还会直接在域名前面补上www。所以，实际上，即使我们输入的是imooc.com，然而实际访问的却是http://www.imooc.com。

1.2.3 [Step2] 将解析出的域名进行dns解析。

第一步地址解析中我们已经获取到服务器的域名。此时就需要将域名换成对应的ip地址，这就是dns解析。dns解析分为以下几个步骤：

• 先查看浏览器dns缓存中是否有域名对应的ip。
• 如果没有，则查看操作系统dns缓存中是否有对应的ip（例如windows的hosts文件）。
• 依旧没有就对本地区的dns服务器发起请求，
• 如果还是没有，就直接到Root Server域名服务器请求解析。
• 这里面有几点需要关注：

• <1>、DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议；
• <2>、全球只有十三台逻辑根服务器，为什么是十三台，请参考https://www.zhihu.com/question/22587247?answer_deleted_redirect=true。其中任何一次解析成功就返回对应的ip地址。

1.2.4 [Step3] 通过ip寻址和arp，找到目标（服务器）地址

第二步获取到了ip，此时直接通过ip寻址找到ip对应的服务器，然后通过arp协议找到服务器的mac地址。

这里有几点需要注意：

• ip地址（ipv4， 32位）。ip地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。ip地址分为A、B、C、D、E五大类：

• A类地址：一个字节（8位）的网络地址和三个字节的主机地址。地址范围为：1.0.0.0~126.255.255.255。

• B类地址：二个字节的网络地址和二个字节的主机地址。地址范围为：128.0.0.0~191.255.255.255。

• C类地址：三个字节的网络地址和一个字节的主机地址。地址范围为：192.0.0.0~223.255.255.255。

• D类地址：D类地址用于多点广播（Multicast），D类IP地址第一个字节以“lll0”开始，它是一个专门保留的地址。地址范围为：224.0.0.0~239.255.255.255。

• E类地址：E类IP地址 以“llll0”开始，为将来使用保留。地址范围为：240.0.0.0~255.255.255.254。，255.255.255.255用于广播地址。

其中缺失了两部分，一个是0开头的，“0”表示该地址是本地主机，不能传送。一个是127开头的，127开头的是网卡自身，常用于测试。这里为什么是十进制的数字，为什么中间有‘.’，其实这都是为了方便人类而人为加上去的。转化为计算机语言就是二进制的，每一个字节八位，八位二进制能表示的最大数字就是255，这样ip地址就齐全了。可能有些人还发现ip地址为 10.170.8.61/23 ，这里涉及到局域网、保留地址和子网掩码。这里的意思是，前23位表示为该台主机的网络地址，该网络有 2^(32-23) = 512台主机。具体就不展开讲了，涉及的内容太深，太多。感兴趣的可以参考https://www.zhihu.com/question/56895036

• IP寻址如何工作？ip寻址主要有两种方式，一种是同一网段，一种是不同网段。要判断两个IP地址是不是在同一个网段，就将它们的IP地址分别与子网掩码做与运算，得到的结果一网络号，如果网络号相同，就在同一子网，否则，不在同一子网。

同一网段的情况：

主机A和主机B，首先主机A通过本机的hosts表或者wins系统或dns系统先将主机B的计算机名 转换为Ip地址，然后用自己的 Ip地址与子网掩码计算出自己所出的网段，比较目的主机B的ip地址与自己的子网掩码，发现与自己是出于相同的网段，于是在自己的ARP缓存中查找是否有主机B 的mac地址，如果能找到就直接做数据链路层封装并且通过网卡将封装好的以太网帧发送有物理线路上去：如果arp缓存中没有主机B的的mac地址，主机A将启动arp协议通过在本地网络上的arp广播来查询主机B的mac地址，获得主机B的mac地址厚写入arp缓存表，进行数据链路层的封装，发送数据。

不同网段的情况：

不同的数据链路层网络必须分配不同网段的Ip地址并且由路由器将其连接起来。和上面一样，主机A发现和主机B不在同一个网段，于是主机A将知道应该将次数据包发送给自己的缺省网关，即路由器的本地接口。主机A在自己的ARP缓存中查找是否有缺省网关的MAC地址，如果能够找到就直接做数据链路层封装并通过网卡 将封装好的以太网数据帧发送到物理线路上去，如果arp缓存表中没有缺省网关的Mac地址，主机A将启动arp协议通过在本地网络上的arp广播来查询缺省网关的mac地址，获得缺省网关的mac地址后写入arp缓存表，进行数据链路层的封装，发送数据。数据帧到达路由器的接受接口后首先解封装，变成ip数据包，对ip 包进行处理，根据目的Ip地址查找路由表，决定转发接口后做适应转发接口数据链路层协议帧的封装，并且发送到下一跳路由器，次过程继续直至到达目的的网络与目的主机。整个过程有点像dns解析，只是dns服务器换成了下一跳路由器，udp编程了tcp，其他差别不大。

• arp。arp就是地址转化协议，也就是把ip地址转化为mac地址。和dns很像，先查缓存，然后查路由器。
• mac地址。mac地址就是计算机的物理地址，每个网卡出厂时，被生产厂家烧制在网卡上。采用十六进制数表示，共六个字节（48位）。三个字节是由IEEE的注册管理机构RA负责给不同厂家分配的代码(高位24位），也称为“编制上唯一的标识符”（Organizationally Unique Identifier），后三个字节(低位24位)由各厂家自行指派给生产的适配器接口，称为扩展标识符（唯一性）。如何修改mac地址呢？一个方法就是直接修改网卡上烧制的mac地址，自己烧制。这个基本不靠谱，失误性也高。另一个方法就是修改注册表中的mac地址，因为网络中访问的mac地址都是访问的注册表中的mac地址，不会直接访问网卡。这个比较简单直接。
• 为什么有了ip地址，还要mac地址？这个问题很关键，就像是我有驾驶证了你非要让我提供身份证。这个涉及一些历史问题，因为一开始没有互联网的时候就只有mac地址，还不存在ip地址。后来互联网越来越大之后，发现mac地址找起来太麻烦，并且耗时也越来越久，就发明了ip地址。并且mac地址在一个局域网中还是很有用的，所以就两个一起存在了。详细的信息，大家可以参考https://www.zhihu.com/question/21546408。

进行tcp三次握手，建立tcp连接

简述一下，第三步我们找到了目标ip，并获得了服务器ip的mac地址。此时浏览器就会请求和服务器连接，用来传输数据。tcp 是稳定双向面向连接的，断开时也会分两边分别断开。面向连接不是说tcp一个双方一直开着的通道，而是维持一个连接的状态，让它看起来有连接。

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 参考文献

• HTTP/2做错了什么？刚刚辉煌2年就要被弃用了！？ - 1024搜
• https://http3-explained.haxx.se/
• https://baike.baidu.com/item/中间设备/3688874
• https://time.geekbang.org/column/article/150159
• https://juejin.cn/post/6844903853985366023
• https://time.geekbang.org/column/article/279164

Q 相关面试问题

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方法中，这样就不需要每次处理客户端的请求都要初始化与销毁资源。

Q13 如果客户端禁止 cookie 能实现 session 还能用吗？

• 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 参考文献

• 卧槽！牛皮了，头一次见有大佬把TCP/IP三次握手四次挥手解释的这么明白 - Zhihu
• 网络编程面试题（2020最新版） - CSDN
• HTTP/2做错了什么？刚刚辉煌2年就要被弃用了！？ - 1024搜
• 详解HTTP/1.0、HTTP/1.1、HTTP/2、HTTPS - 腾讯云社区