面试官：这波HTTP究极combo，你顶得住吗？

基本概念

问题：HTTP 是什么？描述一下：

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

问题：能否详细解释「超文本传输协议」？

HTTP的名字「超文本协议传输」，它可以拆成三个部分：

• 协议

  针对 HTTP 协议，我们可以这么理解。

  HTTP 是文个⽤在计算机世界⾥的协议。它使⽤计算机能够理解的语⾔确⽴了⼀种计算机之间交流通信

  的规范（两个以上的参与者），以及相关的各种控制和错误处理方式式（为约定和规范）。

• 传输

  针对传输，我们可以进⼀步理解了 HTTP。

  HTTP 是⼀个在计算机世界⾥专⻔⽤来在两点之间传输数据的约定和规范

• 超文本

  「文本」，在互联⽹早期的时候只是简单的字符⽂字，但现在「文本」的涵义已经可以扩

  展为图⽚、视频、压缩包等，在 HTTP 眼⾥这些都算作「文本」。

  再来理解「超文本」，它就是超越了普通文本的文本，它是文字、图文、视频等的混合体，最关键有超

  链接，能从一个超文本跳转到另外一个超文本

综上，HTTP 是⼀个在计算机世界里专门在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超文本」数据

的「约定和规范」。

问题：那「HTTP 是用于从互联网服务器传输超文本到本地浏览器的协议 ，这种说法正确吗？

这种说法是不正确的。因为也可以是「服务器< -- >服务器」，所以采⽤两点之间的描述会更准确。

问题：HTTP 常见的状态码，有哪些？

• 1xx

  1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少。

• 2xx

  2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

  「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会

  有 body 数据。

  「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

  「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源

  的全部，⽽是其中的⼀部分，也是服务器处理成功的状态。

• 3xx

  3xx 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL ᯿新发送请求获取资源，也

  就是重定向。

  「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次

  访问。

  「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。

  301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的

  URL。

  「304 Not Modifified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲⽂件，也称缓存重定

  向，⽤于缓存控制。

• 4xx

  4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。

  「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。

  「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。

  「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端。

• 5xx

  5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误

  码。

  「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并

  不知道。

  「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。

  「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器自身⼯作正常，访问

  后端服务器发⽣了错误。

  「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应服务器，类似“网络服务正忙，请稍

  后重试”的意思。

问题：OSI七层模型和TCP/IP的四/五层模型知道吗？

• 应用层 ：为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。
• 传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。
• 网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。
• 数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
• 物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异

问题:数据的传输流程是怎么样的？

数据封装过程（快件打包）

• 应用层传输

  这里可以理解为翻译的过程，当然这是属于计算机的翻译过程，应用层便是将数据进行二进制编码。

• 传输层传输（数据段） 传输层将上层数据分割成诸多数据段（方便解决传输出错问题），并且为每个分段后的数据 封装—— TCP报文头部。其中TCP报文头部有一个关键的字段信息——端口号（保证上层应用数据通信）。

• 网络层传输 （数据包） 网络层将上层数据再度添加封装——IP头部，其头部包含一个关键的字段信息——IP地址，用于标识网络 的逻辑地址。

• 数据链路层传输（数据帧） 数据链路层将上层数据再次添加封装——MAC头部，其包含一个关键的字段信息——MAC地址， 可以理解 为固化在硬件中的物理地址，和我们的个人银行卡号一样具有唯一性。 该封装过程中的尾部封装暂不讨论。

• 物理层传输（比特流） 物理层将上层二进制数据转成电信号在网络中传输。

问题: 那么HTTP的报文结构是怎么样的？

请求报文：

响应报文：

需要注意的是，请求报文中请求方式为GET的时候，是没有body的。body只存在于POST中。

问题: HTTP都有什么请求方式？

• GET

  ⽤于获取资源

  对服务器数据不进⾏修改

  不发送 Body

  GET把参数包含在URL

  GET /users/1 HTTP/1.1
  Host: api.github.com
  

• POST

  ⽤于增加或修改资源

  发送给服务器的内容写在 Body ⾥⾯

  POST /users HTTP/1.1
  Host: api.github.com
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 13
  name=mlx&age=10
  

  PUT

  用于修改资源

  发送给服务器的内容写在 Body ⾥⾯

  PUT /users/1 HTTP/1.1
  Host: api.github.com
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 13
  name=mlx
  

  DELETE

  ⽤于删除资源

  不发送 Body

  DELETE /users/1 HTTP/1.1
  Host: api.github.com
  

  HEAD

  和 GET 使⽤⽅法完全相同

  和 GET 唯⼀区别在于，返回的响应中没有 Body

问题: HTTP这么多请求方法有什么区别呢？

url描述了一个网络上资源，而post、get、put、delete就是对这个资源进行增、删、改、查的操作！

需要引入新的名词:安全和幂等

安全和幂等的概念：

• 在 HTTP 协议⾥，所谓的「安全」是指请求⽅法不会「破坏」服务器上的资源。
• 所谓的「幂等」，意思是多次执⾏相同的操作，结果都是「相同」的。

GET ⽅法就是安全且幂等的，因为它是「只读」操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

PUT，DELETE操作是幂等的。

重点说一下GET和POST的区别：

• GET在浏览器回退时是无害的，而POST会再次提交请求。(也就是上文的幂等)
• GET产生的URL地址可以被Bookmark，而POST不可以。
• GET请求会被浏览器主动cache，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制的，而POST么有。
• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
• GET参数通过URL传递，POST放在Request body中。

但是，凡是都有但是，HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。只不过因为语义化以及服务器或者浏览器的限制导致出现了区别。还有一个最重要的区别：

GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

GET产生一个TCP数据包；POST产生两个TCP数据包。

问题: 创建了报文以后如何建立的连接呢？

HTTP是基于TCP/IP的，所以HTTP的请求就是TCP/IP的连接过程。

TCP是什么？

• TCP 提供一种面向连接的、可靠的字节流服务
• 在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP
• TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
• TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

TCP 并不能保证数据一定会被对方接收到，因为这是不可能的。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说 TCP 也不是 100% 可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知。

TCP链接需要经过三次握手，断开连接需要经过四次挥手

三次握手

所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。在 socket 编程中，客户端执行 connect() 时。将触发三次握手

• 第一次握手(SYN=1, seq=x):

  客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。

  发送完毕后，客户端进入 SYN_SEND 状态。

• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

  服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。

• 第三次握手(ACK=1，ACKnum=y+1)

  客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1

  发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。

四次挥手

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作，在 socket 编程中，任何一方执行 close() 操作即可产生挥手操作

• 第一次挥手(FIN=1，seq=x)

  假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。

  发送完毕后，客户端进入 FIN_WAIT_1 状态。

• 第二次挥手(ACK=1，ACKnum=x+1)

  服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。

  发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

• 第三次挥手(FIN=1，seq=y)

  服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。

  发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

• 第四次挥手(ACK=1，ACKnum=y+1)

  客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。

  服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

  客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。

三次握手的原因

• 第一次握手：客户端发送网络包，服务端收到了。 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据。

问题: 能通俗的讲一下吗？

计算机通讯与人的通讯本质上没什么区别。我们日常发微信也是通讯，理解了你自己是如何发微信的你就理解了TCP三次握手。

如上图，小明欠我钱，我在微信上找小明要钱，这是步骤

1. 我发出：小明，你在吗？我是Mlx。(第一次握手，确认对方在不在，并且发送序号Seq为Mlx)
2. 小明回复：我是小明，我在，干啥？(第二次握手，接收方确认对方在，并且知道对方能找到自己了，收到了这个Seq的序号，并且发送自己的发送序号为小明)
3. 我回复：在就行，接下来聊还钱的事！(第三次握手，确认对方在，并且确认对方能收到自己消息这个时候就可以谈还钱的事了。并且第三次握手就可以携带数据了)

两次握手可以吗？

显然不行。为啥？

还是上面的例子，你发微信的最后一句话 在就行，聊聊还钱的事一直转圈圈发不出去，你等了很久也没发出去，你想，啊这不对啊， 你又发送了一次。小明看到以后开始和你聊还钱的事情了，正当你们因为关系要好而决定小明过几日在还钱的时候，这句话又发出来了，你说小明这时候看见是啥心理？肯定是觉得刚才不还谈的好好的么，怎么又催一次，决定还钱，和你这个朋友绝交。

四次挥手

你和女朋友聊天，已经晚上十一点了， 你想睡觉了，于是你想停止聊天。

1. 你: 亲爱的，我想睡觉了(第一次挥手，发送FIN，进入等待女朋友批复的过程也就是FIN_WAIT_1)
2. 女朋友:知道了，等我把这部剧玩看就睡(第二次挥手，回复ACK),女朋友也知道快睡觉了，倍速播放(进入CLOSE_WAIT状态)，收到消息的你此时处于等待女朋友看剧结束的状态(FIN_WAIT_2 )
3. 过了一会女朋友看完剧了: 亲爱的我看完了，可以睡觉了,晚安哦(第三次挥手，服务器进入等待你说晚安就可以睡觉的阶段)
4. 你: 好的亲爱的，晚安(第四次挥手，女朋友收到消息知道你也要睡了，然后两个人进入梦乡)

上文说到，客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。那么什么是等待2MSL呢？

对应于上面的第四步，你发送了晚安以后，有两个情况

1. 你发送的晚安没发出去，这个时候女朋友见你迟迟不发消息会在通知你一次她可以睡觉了
2. 你发送的晚安发出去了，女朋友看到以后也不回你了直接就去睡了。

面对上面这两种情况，你都得需要等待，等多久呢？假设微信发消息五分钟发不出去就不发了

那么对于第一种情况，你发送的消息是最迟5分钟会送达对方，否则就送不到，女朋友给你发消息也是5分钟，那么你最长只需要等10分钟就能确认消息是发送成功还是失败了。10分钟正好是最长消息的两倍,即MSL*2 ,2MSL。

问题: 你说TCP是可靠传输，是如何保证可靠的呢？

TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

问题: 你用的HTTP是什么版本的？有什么区别吗？

HTTP有这么几个重要的版本 HTTP1.0 HTTP1.1 HTTP2.0

目前HTTP1.1用的比较多，2.0则用的比较少。

http1.0特性

• 无状态：服务器不跟踪不记录请求过的状态
• 无连接：浏览器每次请求都需要建立tcp连接

无状态

对于无状态的特性可以借助cookie/session机制来做身份认证和状态记录

无连接

无连接导致的性能缺陷有两种：

1. 无法复用连接

每次发送请求，都需要进行一次tcp连接（即3次握手4次挥手），使得网络的利用率非常低

2. 队头阻塞

http1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞，后面的请求也给阻塞的

http1.1特性

为了解决http1.0的性能缺陷，http1.1出现了

http1.1特性：

• 长连接：新增Connection字段，可以设置keep-alive值保持连接不断开
• 管道化：基于上面长连接的基础，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回
• 缓存处理：新增字段cache-control
• 断点传输

长连接

http1.1默认保持长连接，数据传输完成保持tcp连接不断开,继续用这个通道传输数据

管道化

基于长连接的基础，我们先看没有管道化请求响应：

tcp没有断开，用的同一个通道

请求1 > 响应1 --> 请求2 > 响应2 --> 请求3 > 响应3

管道化的请求响应：

请求1 --> 请求2 --> 请求3 > 响应1 --> 响应2 --> 响应3

即使服务器先准备好响应2,也是按照请求顺序先返回响应1

虽然管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题

缓存处理

当浏览器请求资源时，先看是否有缓存的资源，如果有缓存，直接取，不会再发请求，如果没有缓存，则发送请求

通过设置字段cache-control来控制

断点传输

在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率

在 Header 里两个参数实现的，客户端发请求时对应的是 Range 服务器端响应时对应的是 Content-Range

host域

HTTP1.0 不支持，因为之前觉得一台服务器只有一个地址 HTTP2.0 支持，请求消息和响应消息都支持

http2.0特性

• 二进制分帧
• 多路复用： 在共享TCP链接的基础上同时发送请求和响应
• 头部压缩
• 服务器推送：服务器可以额外的向客户端推送资源，而无需客户端明确的请求

二进制分帧

将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码

多路复用

基于二进制分帧，在同一域名下所有访问都是从同一个tcp连接中走，http消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来

区别

1. http1.0 到http1.1的主要区别，就是从无连接到长连接
2. http2.0对比1.X版本主要区别就是多路复用

问题：HTTP有哪些优点和缺点呢？

优点

1. 简单

HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式，易于理解，降低了学习和使⽤的⻔槛。

2. 灵活和易于扩展

HTTP协议⾥的各类请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发⼈员⾃定义和扩充。

3. 应⽤⼴泛和跨平台

缺点

1. ⽆状态双刃剑

⽆状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务。

⽆状态的坏处，既然服务器没有记忆能⼒，它在完成有关联性的操作时会⾮常麻烦。例如登录->添加购物⻋->下单->结算->⽀付，这系列操作都要知道⽤户的身份才⾏。但服务器不知道这些请求是有关联的，每次都要问⼀遍身份信息。

2. 明文传输双刃剑

明⽂意味着在传输过程中的信息，是可⽅便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以

直接⾁眼查看，为我们调试⼯作带了极⼤的便利性。但是这正是这样，HTTP 的所有信息都暴露在了光天化⽇下，相当于信息裸奔。在传输的漫⻓的过程中，信息的内容都毫⽆隐私可⾔，很容易就能被窃取

3.HTTP是不安全的，无法验证通信双方的身份

问题：那该如何解决你所说的缺点呢？

对于无状态：

HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销。

对于明文传输和安全性

HTTPS 则解决 HTTP 不安全的 缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

问题: 那你说说HTTPS是什么？和HTTP有什么区别呢？

• HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的 缺陷，在 TCP 和 HTTP 网络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
• HTTP 连接建⽴相对简单， TCP 三次握手之后便可进行HTTP 的报⽂传输。而HTTPS 在 TCP 三 次握手之后，还需进行 SSL/TLS 的握手过程，才可进⼊加密报文传输。
• HTTP 的端口号是 80，HTTPS 的端⼝号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTPS 是如何解决风险的？

• 混合加密的⽅式实现信息的机密性，解决了窃听的⻛险。
• 摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整 性，解决了篡改的⻛险。
• 将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。

问题:那么什么是混合加密？

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：

• 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
• 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。

什么是对称加密和非对称加密？

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。简而言之，就是你和小伙伴提前准备好了一模一样的密码本，对着密码本解密就行，缺点是你如何把密码本给你的小伙伴。主流的有DES、AES-GCM等

• 优点：运算速度快；
• 缺点：无法安全地将密钥传输给通信方。

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。主流的有RSA、DSA等

• 优点：可以更安全地将公开密钥传输给通信发送方；
• 缺点：运算速度慢。

很多人不理解公钥和私钥的意思。其实我换个说法，大家一下子就理解了。非对称加密就是公开锁和私钥共同配合的加密方式。

公开锁就对应着公钥，其实我个人觉得公钥这个称呼不是很好，用公开锁比较好。

比如说我有许多锁，这些锁就是公钥，而这些锁对应着的是一个钥匙，这个钥匙就是私钥。谁想给我发送加密内容，只需要从我这里拿走锁，把他要发送的内容锁住，然后就可以光明正大给我传递消息了，而只有我有钥匙，也就代表只有我能打开锁看到里面的内容。

对称加密运算快，但是密码本很难安全给对方。非对称加密可以安全的发送消息给对方，但是运算慢。HTTPS拍脑袋一想，哎，我把你们俩结合一下不就好了吗？你非对称加密安全是吧，那我用你安全的把密码本发送给对方不就行了？

其实非对称加密主要的原理在于单向陷门函数

单向陷门函数是有一个陷门的一类特殊单向函数。单向陷门函数包含两个明显特征：一是单向性，二是存在陷门。所谓单向性，也称不可逆性，即对于一个函数y=f(x)，若已知x要计算出y很容易，但是已知y要计算出x=f ^(-1) (y)则很困难。单向函数的命名就是源于其只有一个方向能够计算。所谓陷门，也成为后门。对于单向函数，若存在一个z使得知道z则可以很容易地计算出x=f ^(-1) (y)，而不知道z则无法计算出x=f ^(-1) (y)，则称函数y=f(x)为单向陷门函数，而z称为陷门。

所以基于此，HTTPS是使用非对称加密的方式将对称加密的密钥传送过去，也就是把密码本锁上给了对方。然后对方得到密文用它自己的钥匙打开锁得到密码本之后，随后就可以用对称加密的方式通信了。

问题:HTTP2.0都具体做了哪些优化工作呢？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会 帮你消除重复的部分。这就是所谓的 HPACK 算法

HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是 ⼆进制，并且统称为帧（frame）：头信息帧和数据帧也就是上面说的二进制分帧

HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必 须要对数据包做标记，指出它属于哪个回应。 每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编 号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数

HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。 移除了 HTTP/1.1 中的串⾏请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟， ⼤幅度提⾼了连接的利⽤率。

HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动 向客户端发送消息。 举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给 客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

问题: HTTP2.0你说的这么好，那么它有什么缺陷呢？

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的᯿传机制，这样在⼀个 TCP 连接中的所有 的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了

HTTP/2 多个请求复⽤⼀个TCP连接，⼀旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。

问题: 那么HTTP报文中的请求头都有哪些呢？

通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制不再转发给代理的首部字段、管理持久连接
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与 If-Modified-Since 相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP 服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的 HTTP 方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小
Content-Location	替代对应资源的 URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改日期时间

文末

作者：Mlx
链接：https://juejin.im/post/6877362691350986766

对文章有何见解，或者有何技术问题，都可以在评论区一起留言讨论，一定会回复的。
也欢迎大家来我的B站找我玩，各类Android架构师进阶技术难点的视频讲解，任君白嫖~
B站直通车：https://space.bilibili.com/484587989

喜欢文章的小伙伴别忘了点个关注，留个赞再走呀，一个专注Android面试的小喵喵~