2023-11-27 10:11 门头沟学院 Java

关注

计算机网络|HTTP篇

HTTP基础知识

1. 什么是HTTP

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

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

超文本：它就是超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本。
传输：HTTP 协议是一个双向协议。
协议：HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。

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

2. HTTP 是用于服务器和本地浏览器的协议？

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

3. 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 Modified：不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。
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：表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

4. HTTP常见字段有哪些？

Host 字段

客户端发送请求时，用来指定服务器的域名。有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。
Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。告诉浏览器，本次服务器回应的数据长度，后面的字节就属于下一个回应了。
Connection

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。
Accept 字段

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。
accept-encoding 字段

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。
Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。告知客户端需要用此方式解压。

5. 说一下一次完整的HTTP请求过程包括哪些内容？

一次完整的HTTP请求过程通常包括以下内容：

URL（Uniform Resource Locator）：请求开始时，客户端（通常是浏览器）指定要访问的资源的URL。URL包括协议（例如http://或https://）、主机名（服务器的域名或IP地址）、端口号（默认为80或443，可以省略），路径（指定服务器上的具体资源），以及可选的查询字符串和片段标识符。
DNS解析：如果主机名在DNS（Domain Name System）中没有缓存，客户端会发起DNS查询来获取服务器的IP地址。
建立TCP连接：客户端与服务器之间建立一个TCP连接，通常使用三次握手来确保双方都准备好通信。
发起HTTP请求：客户端构建一个HTTP请求，包括请求方法（GET、POST、PUT、DELETE等）、HTTP版本（通常是HTTP/1.1或HTTP/2.0）、请求头（包括用户代理、Accept、Accept-Language、Cookie等信息），以及可选的请求正文（例如POST请求中的表单数据）。
服务器处理请求：服务器接收HTTP请求，解析请求头和正文，然后根据请求的内容执行相应的操作，例如获取请求的资源或处理POST请求中的数据。
服务器响应：服务器构建一个HTTP响应，包括HTTP状态码（例如200 OK、404 Not Found、500 Internal Server Error）、响应头（包括服务器信息、响应类型、内容长度等），以及可选的响应正文（通常是请求的资源的内容）。
数据传输：服务器将HTTP响应数据通过TCP连接发送回客户端。
客户端接收响应：客户端接收HTTP响应数据。
渲染页面或处理数据：如果请求的资源是HTML页面，客户端将解析HTML并加载相关资源（如CSS、JavaScript、图像），然后渲染页面。如果请求的资源是其他数据，客户端将根据需要处理数据。
关闭TCP连接：一旦数据传输完成，客户端和服务器之间的TCP连接可以根据HTTP头中的"Connection"字段来关闭或保持打开。

这些是一次完整的HTTP请求过程中的关键步骤，它们允许客户端和服务器之间交换数据和资源。HTTP是一种无状态协议，每个请求和响应之间相互独立，客户端不会保持关于之前请求的状态信息，需要使用会话管理技术（如Cookies）来维护状态。

6 HTTP的缺点有哪些？

使用明文进行通信，内容可能会被窃听；
不验证通信方的身份，通信方的身份有可能遭遇伪装；
无法证明报文的完整性，报文有可能遭篡改。

6 为什么有HTTP协议了?还要用RPC？

1.从项目实践的角度上来讲,使用HTTP协议规定的协议码对于RPC框架提供的异常信息返回的角度来说,HTTP所蕴含的信息不够丰富,不够直观,比如说通信双方的执行状态只能够通过状态码来描述,而RPC框架可以返回完整的异常信息

2.从编码的角度上来看,HTTP的编码比较冗余,也就是说需要通过定义一大堆的状态码来定义当前的状态,对于不同的服务,这些编码可能还有不同的含义,不合适

3.HTTP通常来说前端和后端通信使用的,包含了大量的浏览器跳转状态定义,这些状态对于后端服务器之间的联调是没有意义的,因此在这样的情况下,而RPC自定义的协议,可以免去这些冗余的状态,更加定制化地是设定这个后端服务联调

补充

RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。 RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。 HTTP/2.0在 HTTP/1.1的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。

8 说一下一次完整的HTTP请求过程包括哪些内容？

域名解析->TCP连接->发送http请求->服务器响应请求->客户端接收响应->解析响应并请求代码中的资源->渲染页面呈现给用户。

9 在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？

第一种回答

建立起客户机和服务器连接。
建立连接后，客户机发送一个请求给服务器。
服务器收到请求给予响应信息。
客户端浏览器将返回的内容解析并呈现，断开连接。

第二种回答

域名解析
发起TCP的3次握手
建立TCP连接后发起http请求
服务器响应http请求，浏览器得到html代码
浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
浏览器对页面进行渲染呈现给用户。

第三种回答

1、查浏览器缓存，看看有没有已经缓存好的，如果没有

2 、检查本机host文件，

3、调用API，Linux下Socket函数 gethostbyname

4、向DNS服务器发送DNS请求，查询本地DNS服务器，这其中用的是UDP的协议

5、如果在一个子网内采用ARP地址解析协议进行ARP查询如果不在一个子网那就需要对默认网关进行DNS查询，如果还找不到会一直向上找根DNS服务器，直到最终拿到IP地址（全球400多个根DNS服务器，由13个不同的组织管理）

6、这个时候我们就有了服务器的IP地址以及默认的端口号了，http默认是80 https是 443 端口号，会，首先尝试http然后调用Socket建立TCP连接，

7、经过三次握手成功建立连接后，开始传送数据，如果正是http协议的话，就返回就完事了，

8、如果不是http协议，服务器会返回一个5开头的的重定向消息，告诉我们用的是https，那就是说IP没变，但是端口号从80变成443了，好了，再四次挥手，完事，

9、再来一遍，这次除了上述的端口号从80变成443之外，还会采用SSL的加密技术来保证传输数据的安全性，保证数据传输过程中不被修改或者替换之类的，

10、这次依然是三次握手，沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的CA安全证书。

11、确认无误后，开始通信，然后服务器就会返回你所要访问的网址的一些数据，在此过程中会将界面进行渲染，牵涉到ajax技术之类的，直到最后我们看到色彩斑斓的网页

第四种回答

浏览器检查域名是否在缓存当中（要查看 Chrome 当中的缓存，打开 chrome://net-internals/dns）。
如果缓存中没有，就去调用 gethostbyname 库函数（操作系统不同函数也不同）进行查询。如果 gethostbyname 没有这个域名的缓存记录，也没有在 hosts 里找到，它将会向 DNS 服务器发送一条 DNS 查询请求。DNS 服务器是由网络通信栈提供的，通常是本地路由器或者 ISP 的缓存 DNS 服务器。
查询本地 DNS 服务器
如果 DNS 服务器和我们的主机在同一个子网内，系统会按照下面的 ARP 过程对 DNS 服务器进行 ARP查询
如果 DNS 服务器和我们的主机在不同的子网，系统会按照下面的 ARP 过程对默认网关进行查询

10 在浏览器中输入url地址后显示主页的过程?

根据域名，进行DNS域名解析；
拿到解析的IP地址，建立TCP连接；
向IP地址，发送HTTP请求；
服务器处理请求；
返回响应结果；
关闭TCP连接；
浏览器解析HTML；
浏览器布局渲染；

HTTP请求方法

1 HTTP请求方法你知道多少？

GET：用于请求服务器获取指定资源，通常用于获取网页、图像、文档等。GET请求不应该对服务器数据进行修改。
POST：用于向服务器提交数据，通常用于在服务器上创建新资源或更新现有资源。POST请求可以包含请求正文，用于传输数据。
PUT：用于请求服务器更新指定的资源，或在服务器上创建指定的资源，如果资源已存在，则将其替换为请求的数据。
DELETE：用于请求服务器删除指定的资源。
PATCH：用于请求服务器对指定资源进行部分修改。
HEAD：类似于GET请求，但服务器不返回资源的正文内容，只返回响应头信息。通常用于获取资源的元数据，如文件大小、修改日期等。
OPTIONS：用于请求服务器提供有关支持的请求方法、头信息、CORS（跨域资源共享）等信息。
CONNECT：用于请求建立网络连接，通常在代理服务器上使用。
TRACE：用于请求服务器返回一个针对请求的诊断信息，通常用于调试和测试。
CONNECT：用于将当前连接转换为透明的TCP/IP隧道，通常在代理服务器上使用。

2 说一下 GET 和 POST 的区别？

get是获取数据，post是修改数据
get把请求的数据放在url上，以?分割URL和传输数据，参数之间以&相连，所以get不太安全。而post把数据放在HTTP的包体内（request body 相对安全）
get提交的数据最大是2k（限制实际上取决于浏览器）， post理论上没有限制。
GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。
GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
本质区别：GET是幂等的，而POST不是幂等的

这里的幂等性：幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

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

先说明下安全和幂等的概念：

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

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

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

4 GET 方法参数写法是固定的吗？

在约定中，我们的参数是写在 ? 后面，用 & 分割。

我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。

比如header请求头中添加token，来验证用户是否登录等权限问题。

也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，万变不离其宗。

5 GET 请求方法的路径长度有限制吗？最大长度能够达到多少？

网络上都会提到浏览器地址栏输入的参数是有限的。

首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

GET与POST传递数据的最大长度能够达到多少呢？

get 是通过URL提交数据，因此GET可提交的数据量就跟URL所能达到的最大长度有直接关系。

很多文章都说GET方式提交的数据最多只能是1024字节，而实际上，URL不存在参数上限的问题，HTTP协议规范也没有对URL长度进行限制。

这个限制是特定的浏览器及服务器对它的限制，比如IE对URL长度的限制是2083字节(2K+35字节)。对于其他浏览器，如FireFox，Netscape等，则没有长度限制，这个时候其限制取决于服务器的操作系统；即如果url太长，服务器可能会因为安全方面的设置从而拒绝请求或者发生不完整的数据请求。

post 理论上讲是没有大小限制的，HTTP协议规范也没有进行大小限制，但实际上post所能传递的数据量大小取决于服务器的设置和内存大小。

因为我们一般post的数据量很少超过MB的，所以我们很少能感觉的到post的数据量限制，但实际中如果你上传文件的过程中可能会发现这样一个问题，即上传个头比较大的文件到服务器时候，可能上传不上去。

以php语言来说，查原因的时候你也许会看到有说PHP上传文件涉及到的参数PHP默认的上传有限定，一般这个值是2MB，更改这个值需要更改php.conf的post_max_size这个值。这就很明白的说明了这个问题了。

6 有人数POST 方法比 GET 方法安全？你认可吗？

不认可！

有人说POST 比 GET 安全，因为数据在地址栏上不可见。

然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。

要想安全传输，就只有加密，也就是 HTTPS。

7 POST 方法会产生两个 TCP 数据包？你了解吗？

有些文章中提到，POST 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。

HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送。

所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

HTTP/1.1的特点

1 HTTP（1.1）的优点有哪些，怎么体现的？

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

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

2. 灵活和易于扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。

3. 应用广泛和跨平台：互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

2 HTTP（1.1）的缺点有哪些，怎么体现的？

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

1. 无状态双刃剑

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

无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

2. 明文传输双刃剑

明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。

但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，

3. 不安全

HTTP 比较严重的缺点就是不安全：

通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

3 如何解决HTTP（1.1）的缺点？

1. 无状态双刃剑

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了，

2. 安全问题

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

4 说下 HTTP/1.1 的性能如何？

HTTP 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。

1. 长连接

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。

为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

2. 管道网络传输

HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。

即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为**「队头堵塞」。**

3. 队头阻塞

「请求 - 应答」的模式加剧了 HTTP 的性能问题。

因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。

5 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

6 HTTP/1.1 还是有性能瓶颈？

请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。

7 HTTP/1.1如何优化？

使用缓存
将重定向任务交给代理服务器
将多个资源的多个请求合并成一个，减少头部的相对比重。
延迟请求某些暂时不需要的资源。

8 针对HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

头部压缩：HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
二进制格式：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。
数据流：HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数

客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。
服务器推送：HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

9 HTTP/2 有哪些缺陷？

队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了；
TCP 和 TLS 握手时延，TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延；
连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WIFI 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；
HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

10 针对HTTP/2的性能瓶颈，HTTP/3做了什么优化？

HTTP/2 的缺陷都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的一个丢包全部重传问题。

基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；
建立连接速度快，因为 QUIC 内部包含 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

11 HTTP/2相比HTTP/1.1，异步传输体现在什么地方？

HTTP/2 相比于 HTTP/1.1 引入了多路复用（Multiplexing）的特性，这是异步传输的一个关键方面。在 HTTP/1.1 中，请求和响应是按顺序处理的，一个请求必须等待前一个请求完成后才能开始。这导致了一些性能瓶颈，尤其是在高延迟网络环境中。

HTTP/2 引入了以下方式来实现异步传输：

多路复用：HTTP/2 允许多个请求和响应在单个 TCP 连接上并行传输，而不像 HTTP/1.1 那样需要等待一个请求的响应才能发送下一个请求。这意味着多个请求和响应可以同时传输，减少了请求等待时间，提高了页面加载速度。
二进制分帧：HTTP/2 使用二进制协议，将数据分为小的二进制帧。每个帧都有一个唯一的标识符，这些帧可以异步传输和重新组装，而不会阻塞其他帧的传输。这允许更高效的数据传输，而不像 HTTP/1.1 那样使用文本协议。
流（Stream）：HTTP/2 中的流是虚拟的、独立的双向通信通道，可以在单个连接上同时传输多个流。每个流可以包含一个或多个帧，这些帧可以异步传输。这使得浏览器可以同时请求多个资源，并且服务器可以以任意顺序发送响应数据。

通过这些特性，HTTP/2 在网络传输中实现了异步性，允许多个请求和响应同时传输，提高了性能，减少了页面加载时间，尤其对于高延迟网络环境来说，它带来了显著的改进。这些异步传输机制是 HTTP/2 相对于 HTTP/1.1 的一个重要优势之一。

12 HTTP/2的特点

HTTP/2 是 HTTP 协议的一个重要升级，旨在提高性能、效率和安全性。以下是 HTTP/2 的主要特点：

多路复用（Multiplexing）：HTTP/2 允许多个请求和响应同时在单个 TCP 连接上传输，而不像 HTTP/1.1 那样需要按顺序一个一个传输。这提高了页面加载速度，减少了延迟，允许并行传输多个资源。
二进制分帧（Binary Framing）：HTTP/2 使用二进制协议，将数据分为小的二进制帧。每个帧都有唯一的标识符，可以异步传输和重新组装，而不会阻塞其他帧的传输。这使得数据传输更高效，减少了协议头的开销。
首部压缩（Header Compression）：HTTP/2 使用 HPACK 压缩算法来压缩请求和响应头，减少了数据传输的大小，降低了带宽消耗。这有助于减少网络延迟和提高性能。
服务器推送（Server Push）：HTTP/2 允许服务器在客户端请求之前主动向客户端推送资源。这可以提前发送相关资源，以提高页面加载速度。例如，服务器可以在客户端请求 HTML 页面时，同时推送与该页面相关的 CSS 和 JavaScript 文件。
优化的流控制（Stream Prioritization）：HTTP/2 允许客户端为不同的流设置优先级，以确保重要的资源得到更快的响应。这有助于改善用户体验，尤其是在有限带宽条件下。
安全性：HTTP/2 鼓励使用加密，通常通过TLS/SSL来保护数据传输。这有助于提高通信的安全性，防止中间人攻击和数据窃取。
兼容性：HTTP/2 被设计成与 HTTP/1.1 兼容，因此旧的 HTTP/1.1 客户端和服务器仍然可以正常工作。但对于支持 HTTP/2 的客户端和服务器，可以协商使用 HTTP/2 来提高性能。

总的来说，HTTP/2 通过引入多路复用、二进制分帧、首部压缩等特性，显著提高了网络传输的性能和效率，使网页加载更快、更高效，并提供更好的用户体验。它是 HTTP 协议的一次重大改进。

13 http1.0 / 1.1 / 2 / 3的区别

HTTP 1.0、1.1、2.0和3.0的区别如下：

HTTP 1.0是一种无状态，无连接的应用层协议。浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接(无连接),服务器不跟踪也每个客户单，也不记录过去的请求(无状态) 。
HTTP 1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了网络延迟。
HTTP 2.0是基于二进制流的，可以分解为独立的帧，交错发送，从而提高了网络传输效率。
HTTP/3是最新的版本，它使用了QUIC协议来提高网络传输效率。

缓存

1 HTTP 的缓存机制？

缓存技术能够免发送 HTTP 请求。

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

2 HTTP是如何实现缓存的？

客户端会把第一次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，而响应作为 value，两者形成映射关系。

这样当后续发起相同的请求时，就可以先在本地磁盘上通过 key 查到对应的 value，也就是响应，如果找到了，就直接从本地读取该响应。毋庸置疑，读取本地磁盘的速度肯定比网络请求快得多。

3 HTTP如何应对缓存过期？

服务器在发送 HTTP 响应时，会估算一个过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，一旦发现缓存的响应是过期的，则就会重新发送网络请求。

客户端在重新发送请求时，在请求的 Etag 头部带上第一次请求的响应头部中的摘要，这个摘要是唯一标识响应的资源，当服务器收到请求后，会将本地资源的摘要与请求中的摘要做个比较。

如果不同，那么说明客户端的缓存已经没有价值，服务器在响应中带上最新的资源。

如果相同，说明客户端的缓存还是可以继续使用的，那么服务器仅返回不含有包体的 304 Not Modified 响应，告诉客户端仍然有效。

4 HTTP中有个缓存机制，但如何保证缓存是最新的呢？

max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

Cache-Control: max-age=31536000

Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。

Expires: Wed, 04 Jul 2012 08:26:05 GMT

在 HTTP/1.1 中，会优先处理 max-age 指令；
在 HTTP/1.0 中，max-age 指令会被忽略掉。

5 HTTP中缓存的私有和共有字段？知道吗？

private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

Cache-Control: private

public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

Cache-Control: public

连接和请求

1 什么是重定向

服务器上的一个资源可能由于迁移、维护等原因从 url1 移至 url2 后，而客户端不知情，它还是继续请求 url1，这时服务器不能粗暴地返回错误，而是通过 302 响应码和 Location 头部，告诉客户端该资源已经迁移至 url2 了，于是客户端需要再发送 url2 请求以获得服务器的资源。

如果重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了

2 如何减少HTTP请求次数

如果把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。

另外由于 HTTP/1.1 是请求响应模型，如果第一个发送的请求，未收到对应的响应，那么后续的请求就不会发送，于是为了防止单个请求的阻塞，所以一般浏览器会同时发起 5-6 个请求，每一个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因而省去了 TCP 握手和慢启动过程耗费的时间。

有的网页会含有很多小图片、小图标，有多少个小图片，客户端就要发起多少次请求。那么对于这些小图片，我们可以考虑使用 CSS Image Sprites 技术把它们合成一个大图片，这样浏览器就可以用一次请求获得一个大图片，然后再根据 CSS 数据把大图片切割成多张小图片。

这种方式就是通过将多个小图片合并成一个大图片来减少 HTTP 请求的次数，以减少 HTTP 请求的次数，从而减少网络的开销。

3 延迟请求是什么？

一般 HTML 里会含有很多 HTTP 的 URL，当前不需要的资源，我们没必要也获取过来，于是可以通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数。

请求网页的时候，没必要把全部资源都获取到，而是只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。

4 HTTP长连接和短连接的区别

http1.0默认使用短连接。客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。每次tcp连接在一次请求响应后断开。
http1.1默认使用长连接，用以保持连接特性。。每次tcp连接后，可以又多次请求响应。

5 一个TCP连接可以对应几个HTTP请求？

如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。
如果是非持久连接，可以发送一个HTTP请求。

6 一个TCP连接中HTTP请求发送可以一起发送么？

http1.1中，默认是长链接，但是默认一次只能处理一个请求响应。
如果使用管道化方式通信，可以一次发送多个请求，服务器会按序返回响应，有可能造成队头堵塞。

7 HTTP长连接怎么保活

TTP长连接保活的方法有很多，以下是一些常见的方法：

在服务器端设置一个保活定时器，当定时器开始工作后就定时的向网络通信的另一端发出保活探测的TCP报文，如果接收到了ACK报文，那么就证明对方存活，可以继续保有连接；否则就证明网络存在故障。
通过在客户端发送心跳包来检测服务器是否存活。如果服务器在一定时间内没有收到客户端的心跳包，则认为服务器已经宕机了，需要重新建立连接。
通过在服务器端设置keep-alive参数来实现长连接保活。keep-alive参数指定了客户端与服务器之间的长连接超时时间，超过这个时间后，如果没有数据传输，则自动断开连接。如果在这个时间内有数据传输，则重置超时时间。

Cookie和Session

1. HTTP请求和响应报文有哪些主要字段？

简单来说：

请求行：Request Line
请求头：Request Headers
请求体：Request Body

响应报文

简单来说：

状态行：Status Line
响应头：Response Headers
响应体：Response Body

2. Cookie是什么？有什么用途？

HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务，HTTP/1.1 引入 Cookie 来保存状态信息。

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

Cookie 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。

新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

cookie 的出现是因为 HTTP 是无状态的一种协议，换句话说，服务器记不住你，可能你每刷新一次网页，就要重新输入一次账号密码进行登录。这显然是让人无法接受的，cookie 的作用就好比服务器给你贴个标签，然后你每次向服务器再发请求时，服务器就能够 cookie 认出你。

抽象地概括一下：一个 cookie 可以认为是一个「变量」，形如 name=value，存储在浏览器；一个 session 可以理解为一种数据结构，多数情况是「映射」（键值对），存储在服务器上。

用途

会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

3. Session知识大总结

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

过程使用 Session 维护用户登录状态的过程如下：

用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

注意：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

4. Session 的工作原理是什么？

session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，session 创建完之后，会把 session 的 id 发送给客户端，客户端再存储到浏览器中。

这样客户端每次访问服务器时，都会带着 sessionid，服务器拿到 sessionid 之后，在内存找到与之对应的 session 这样就可以正常工作了。

5. Cookie与Session的对比

HTTP作为无状态协议，必然需要在某种方式保持连接状态。这里简要介绍一下Cookie和Session。

Cookie是客户端保持状态的方法。

Cookie简单的理解就是存储由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器可以在响应客户端请求时将Cookie字符串放在Set-Cookie下，客户机收到Cookie之后保存这段字符串，之后再请求时候带上Cookie就可以被识别。

除了上面提到的这些，Cookie在客户端的保存形式可以有两种，一种是会话Cookie一种是持久Cookie，会话Cookie就是将服务器返回的Cookie字符串保持在内存中，关闭浏览器之后自动销毁，持久Cookie则是存储在客户端磁盘上，其有效时间在服务器响应头中被指定，在有效期内，客户端再次请求服务器时都可以直接从本地取出。需要说明的是，存储在磁盘中的Cookie是可以被多个浏览器代理所共享的。

Session

Session是服务器保持状态的方法。首先需要明确的是，Session保存在服务器上，可以保存在数据库、文件或内存中，每个用户有独立的Session用户在客户端上记录用户的操作。我们可以理解为每个用户有一个独一无二的Session ID作为Session文件的Hash键，通过这个值可以锁定具体的Session结构的数据，这个Session结构中存储了用户操作行为。

当服务器需要识别客户端时就需要结合Cookie了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用Cookie来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在Cookie里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。如果客户端的浏览器禁用了Cookie，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如sid=xxxxx这样的参数，服务端据此来识别用户，这样就可以帮用户完成诸如用户名等信息自动填入的操作了。

6. Session和cookie应该如何去选择（适用场景）？

Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

7. Cookies和Session区别是什么？

Cookie和Session都是客户端与服务器之间保持状态的解决方案 1，存储的位置不同

cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全 2，存储的数据类型不同两者都是key-value的结构，但针对value的类型是有差异的 cookie：value只能是字符串类型，session：value是Object类型 3，存储的数据大小限制不同 cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制， 4，生命周期的控制 cookie的生命周期当浏览器关闭的时候，就消亡了 (1)cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束， (2)session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁

#牛客解忧铺#

Job-Hunter 文章被收录于专栏

2024年最新整理的八股文。包括计算机网络，操作系统，MySQL，linux，设计模式，数据结构和算法，等等。题目来源于网友爆料，GZH摘录，CSDN等等。根据考察知识点，将题目进行分类，方便背诵。