在学习的时候找到几个十分好的工程和个人博客，先码一下，内容都摘自其中，有些重难点做了补充！
才鲸 / 嵌入式软件笔试题汇总
嵌入式与Linux那些事
阿秀的学习笔记
小林coding
百问网linux
嵌入式软件面试合集
2022年春招实习十四面（嵌入式面经）

文章目录

一、TCP/UDP
- 1.1 区别和优缺点
- - 1.1.1 区别
  - 1.1.2 优缺点
- 1.2 TCP怎么保证可靠性？
- 1.3 TCP的建立连接和断开连接的过程
- - 1.3.1 TCP建立连接
  - - 1.3.1.1 三次握手过程
    - 1.3.1.2 为什么是三次握手？
    - 1.3.1.3 为什么每次建立 TCP 连接时，初始化的序列号都要求不一样呢？
    - 1.3.1.4 初始序列号 ISN 是如何随机产生的？
    - 1.3.1.5 什么是 SYN 攻击？如何避免 SYN 攻击？
  - 1.3.2 TCP断开连接
  - - 1.3.2.1 四次挥手过程
    - 1.3.2.2 为什么挥手需要四次？
    - 1.3.2.3 为什么 TIME_WAIT 等待的时间是 2MSL？
    - 1.3.2.4 为什么需要 TIME_WAIT 状态？
    - 1.3.2.5 TIME_WAIT 过多有什么危害？
- 1.3 ISO/OSI模型、TCP/IP协议和模型
二、HTTP
- 2.1 HTTP概念
- 2.2 GET 与 POST
- - 2.2.1 GET 和 POST 有什么区别？
  - 2.2.2 GET 和 POST 方法都是安全和幂等的吗？
- 2.3 HTTP 缓存技术
- - 2.3.1 HTTP 缓存有哪些实现方式？
  - 2.3.2 什么是强制缓存？
  - 2.3.3 什么是协商缓存？
- 2.4 HTTP 特性(HTTP/1.1 )
- - 2.4.1 HTTP/1.1 的优点有哪些？
  - 2.4.2 HTTP/1.1 的缺点有哪些？
  - 2.4.3 HTTP/1.1 的性能如何？
- 2.5 HTTP 与 HTTPS
- - 2.5.1 HTTP 与 HTTPS 有哪些区别？
  - 2.5.2 HTTPS 解决了 HTTP 的哪些问题？
  - 2.5.3 HTTPS 是如何建立连接的？其间交互了什么？
  - 2.5.4 HTTPS 的应用数据是如何保证完整性的？
  - 2.5.5 HTTPS 一定安全可靠吗？

一、TCP/UDP

1.1 区别和优缺点

1.1.1 区别

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是两种网络传输协议，它们在数据传输时有以下区别：

连接方式不同：TCP是面向连接的协议，传输数据之前需要先建立连接，而UDP是无连接的协议，数据传输可以直接发送，不需要先建立连接。
可靠性不同：TCP是可靠的协议，它通过数据确认、重传等机制保证数据的可靠传输。而UDP是不可靠的协议，它并不保证数据的可靠传输，数据包可能会丢失或者乱序。
传输效率不同：由于TCP需要建立连接、确认数据、重传等机制，所以传输效率相对较低；而UDP没有这些机制，传输效率相对较高。
数据大小不同：TCP传输的数据大小没有限制，可以传输任意大小的数据；而UDP传输的数据大小有限制，每个数据包的大小不能超过64KB。
适用场景不同：TCP适合传输一些重要的数据，例如文件、邮件等，因为它可以保证数据的可靠传输；而UDP适合传输一些时间敏感、实时性要求较高的数据，例如视频、音频等，因为它可以提高传输效率，减少延迟。

1.1.2 优缺点

TCP的优点：

可靠性高：TCP采用数据确认、重传等机制，保证数据的可靠传输，数据不容易丢失或损坏。
顺序性好：TCP保证数据顺序传输，数据不会乱序。
流量控制：TCP可以根据网络情况进行流量控制，避免过多的数据流入，导致网络拥塞。
适合传输大量数据：TCP可以传输任意大小的数据，适合传输文件、邮件等大量数据。

TCP的缺点：

连接建立慢：TCP需要进行三次握手建立连接，连接建立的时间相对较长。
传输效率低：TCP采用确认、重传等机制，传输效率相对较低，不适合传输实时性要求较高的数据。
数据量控制：TCP采用流量控制机制，可能会导致数据传输速度过慢，不适合传输大量数据时的性能要求。

UDP的优点：

传输效率高：UDP采用无连接、不可靠的传输方式，传输效率较高，适合传输实时性要求较高的数据。
简单快速：UDP没有连接建立和断开的过程，传输速度相对较快。
数据量控制：UDP没有流量控制机制，可以传输任意大小的数据。

UDP的缺点：

可靠性低：UDP没有确认、重传等机制，数据传输不可靠，数据包可能丢失或者乱序。
顺序性差：UDP传输的数据包可能会乱序，需要在应用层进行处理。
不适合传输大量数据：UDP传输的数据包大小有限制，不适合传输大量数据。
容易导致网络拥塞：UDP没有流量控制机制，容易导致网络拥塞，影响网络性能。

总之，TCP和UDP各有优缺点，在实际应用中需要根据具体的需求进行选择。如果需要传输大量的数据或保证数据的可靠传输，应该选择TCP；如果需要传输实时性要求较高的数据，或者需要提高传输效率，应该选择UDP。

1.2 TCP怎么保证可靠性？

序列号和确认号
TCP使用序列号和确认号来保证数据的可靠传输。发送方给每个数据包分配一个唯一的序列号，接收方通过确认号告知发送方已经成功接收了数据包。当发送方收到接收方的确认信息后，就知道数据包已经成功传输。如果发送方没有收到确认信息，则会重新发送数据包，直到接收方成功接收为止。
数据包重传
如果发送方没有收到确认信息，或者接收方发现数据包有丢失或损坏，TCP会自动重传数据包，以确保所有数据都被正确传输。在接收方发现数据包丢失或损坏后，会发送一个重复的确认信息告诉发送方需要重传数据包。发送方接收到重复的确认信息后，就知道需要重新发送数据包，以确保数据的可靠传输。
拥塞控制
TCP使用拥塞控制机制来避免网络拥塞。当网络出现拥塞时，TCP会自动降低发送速率，以避免过多的数据包堵塞网络。TCP使用拥塞窗口（Congestion Window）来控制发送速率，当网络出现拥塞时，TCP会减小拥塞窗口的大小，以减缓发送速率。当网络恢复正常时，TCP会逐渐增大拥塞窗口的大小，以提高发送速率。
流量控制
TCP使用流量控制机制来避免接收方被发送方的数据包淹没。接收方会发送窗口信息告诉发送方可以接收多少数据，发送方根据窗口信息控制发送速率。如果接收方的窗口大小为0，则发送方会停止发送数据，直到接收方的窗口大小变为非0为止。
超时重传
TCP会对每个数据包设置一个超时时间，如果在超时时间内没有收到确认信息，则会重新发送数据包。当发送方发送数据包后，会启动一个超时计时器，在超时时间内如果没有收到确认信息，则会认为数据包丢失，需要重新发送。如果接收方收到了重复的数据包，则会忽略这些数据包，并发送一个重复的确认信息告诉发送方数据包已经正确接收。

1.3 TCP的建立连接和断开连接的过程

三次握手与四次挥手面试题
TCP三次握手、四次挥手时序图

1.3.1 TCP建立连接

1.3.1.1 三次握手过程

参考链接：TCP的三次握手与四次挥手

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态;
TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号seq=x ，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

三次握手

1.3.1.2 为什么是三次握手？

主要从以下三个方面分析：

三次握手才可以阻止重复历史连接的初始化（主要原因）；
三次握手才可以同步双方的初始序列号；
三次握手才可以避免资源浪费。

原因一：避免历史连接
TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。
如果是两次握手连接，就无法阻止历史连接。主要是因为在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。
因此，要解决这种现象，最好就是在服务端发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

原因二：同步双方初始序列号
TCP 协议的通信双方，都必须维护一个「序列号」，序列号是可靠传输的一个关键因素，它的作用：

接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中，哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

原因三：避免资源浪费
如果只有「两次握手」，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接。
如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

小结:
TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因：

「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

1.3.1.3 为什么每次建立 TCP 连接时，初始化的序列号都要求不一样呢？

主要原因有两个方面：

为了防止历史报文被下一个相同四元组的连接接收（主要方面）(并不是完全避免了，因为序列号会有回绕的问题，所以需要用时间戳的机制来判断历史报文)；
为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收；

1.3.1.4 初始序列号 ISN 是如何随机产生的？

起始 ISN 是基于时钟的，每 4 微秒 + 1，转一圈要 4.55 个小时。

RFC793 提到初始化序列号 ISN 随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

M 是一个计时器，这个计时器每隔 4 微秒加 1。
F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。

可以看到，随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号

1.3.1.5 什么是 SYN 攻击？如何避免 SYN 攻击？

假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务端不能为正常用户服务。
在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；
全连接队列，也称 accept 队列；

SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。

避免 SYN 攻击方式，可以有以下四种方法：

调大 netdev_max_backlog；
当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数，默认值是 1000，我们要适当调大该参数的值，比如设置为 10000：

net.core.netdev_max_backlog = 10000

增大 TCP 半连接队列；
增大 TCP 半连接队列，要同时增大下面这三个参数：
(1)增大 net.ipv4.tcp_max_syn_backlog
(2)增大 listen() 函数中的 backlog
(3)增大 net.core.somaxconn
开启 tcp_syncookies；
开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接，相当于绕过了 SYN 半连接来建立连接。
减少 SYN+ACK 重传次数

1.3.2 TCP断开连接

1.3.2.1 四次挥手过程

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

1.3.2.2 为什么挥手需要四次？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。

1.3.2.3 为什么 TIME_WAIT 等待的时间是 2MSL？

MSL （Maximum Segment Lifetime）报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

1.3.2.4 为什么需要 TIME_WAIT 状态？

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。需要 TIME-WAIT 状态，主要是两个原因：

防止历史连接中的数据，被后面相同四元组的连接错误的接收；
保证「被动关闭连接」的一方，能被正确的关闭；

1.3.2.5 TIME_WAIT 过多有什么危害？

过多的 TIME-WAIT 状态主要的危害有两种：

第一是占用系统资源，比如文件描述符、内存资源、CPU 资源、线程资源等；
第二是占用端口资源，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过 net.ipv4.ip_local_port_range参数指定范围。

1.3 ISO/OSI模型、TCP/IP协议和模型

在这里插入图片描述

二、HTTP

2.1 HTTP概念

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web）服务器传输超文本到本地浏览器的传送协议。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件，图片文件，查询结果等）。
HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。
它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG（Next Generation of HTTP）的建议已经提出。
HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

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

2.2 GET 与 POST

2.2.1 GET 和 POST 有什么区别？

根据 RFC 规范，GET 的语义是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。
根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

2.2.2 GET 和 POST 方法都是安全和幂等的吗？

安全和幂等的概念：

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

如果从 RFC 规范定义的语义来看：

GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。
POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。
可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

2.3 HTTP 缓存技术

2.3.1 HTTP 缓存有哪些实现方式？

对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话 HTTP/1.1 的性能肯定肉眼可见的提升。

所以，避免发送 HTTP 请求的方法就是通过缓存技术，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

2.3.2 什么是强制缓存？

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。
在这里插入图片描述
强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires 。

Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下：

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

2.3.3 什么是协商缓存？

协商缓存可以基于两种头部来实现。

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，这两个字段的意思是：

响应头部中 Etag：唯一标识响应资源；
请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头 If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

2.4 HTTP 特性(HTTP/1.1 )

2.4.1 HTTP/1.1 的优点有哪些？

HTTP 最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

简单
HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
灵活和易于扩展
HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化，比如：
HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议。
应用广泛和跨平台
互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

2.4.2 HTTP/1.1 的缺点有哪些？

HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

无状态双刃剑
无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。
Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
明文传输双刃剑
明文意味着在传输过程中的信息，是可方便阅读的，比如 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利。
但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。
不安全
HTTP 比较严重的缺点就是不安全：

通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。
HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

2.4.3 HTTP/1.1 的性能如何？

长连接

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。
为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

管道网络传输

HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。那么，管道机制则是允许浏览器同时发出 A 请求和 B 请求，

但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。
所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

注意:
实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，有这个功能，但是没有被使用.

队头阻塞
「请求 - 应答」的模式会造成 HTTP 的性能问题。为什么呢？
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。

2.5 HTTP 与 HTTPS

2.5.1 HTTP 与 HTTPS 有哪些区别？

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

2.5.2 HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

混合加密
通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法 + 数字签名

为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。

对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。

那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。

通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：

一个是公钥，这个是可以公开给所有人的；
一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

流程的不同，意味着目的也不相同：

公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。
一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。

所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

数字证书

在这里插入图片描述

2.5.3 HTTPS 是如何建立连接的？其间交互了什么？

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。TLS 的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法和 ECDHE 算法。

HTTPS建立连接的过程如下：

客户端向服务器发送一个HTTPS请求。
服务器将其公钥和数字证书发送给客户端。数字证书通常是由可信任的证书颁发机构（CA）签发的，用于证明服务器的身份。
客户端验证证书的有效性，如果证书有效且可信，则生成随机的对称加密密钥，并使用服务器公钥进行加密，发送给服务器。
服务器使用私钥解密客户端发送的数据，获取对称加密密钥，并将其用于后续通信的加密和解密。
双方使用对称加密密钥进行加密和解密数据的通信，保证通信过程的安全性和保密性。

在HTTPS建立连接的过程中，客户端和服务器之间进行了以下交互：

客户端向服务器发送请求，请求建立HTTPS连接。
服务器发送数字证书和公钥给客户端。
客户端验证证书的有效性，并使用服务器公钥加密生成的对称加密密钥，发送给服务器。
服务器使用私钥解密客户端发送的数据，获取对称加密密钥。
双方使用对称加密密钥进行加密和解密数据的通信。

2.5.4 HTTPS 的应用数据是如何保证完整性的？

具体过程如下：

首先，消息被分割成多个较短的片段,然后分别对每个片段进行压缩。
接下来，经过压缩的片段会被加上消息认证码（MAC 值，这个是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。通过附加消息认证码的 MAC 值，可以识别出篡改。与此同时，为了防止重放攻击，在计算消息认证码时，还加上了片段的编码。
再接下来，经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。
最后，上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。

记录协议完成后，最终的报文数据将传递到传输控制协议 (TCP) 层进行传输。