计网-HTTP

总结计算机网络HTTP相关的面试题目和知识点

HTTP常见题目分类：
​​

1、HTTP基本概念

什么是HTTP？

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

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

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

HTTP常见状态码有哪些？

　　​​

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

　　​2xx​ 类状态码表示服务器成功处理了客户端的请求

• 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD​ 请求，服务器返回的响应头都会有 body 数据。
• 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

　　​3xx​ 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

　　301 和 302 都会在响应头里使用字段 Location​，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

• 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

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

• 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
• 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

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

• 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
• 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
• 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
• 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思

　　500记忆方法： 先问有没有这个功能 有的话通过网关代理访问 然后最后是服务器无响应

　　400系列也是一样，先确认你有没有权限能不能访问 然后再确认有没有

HTTP常见字段有哪些？

　　Host字段：客户端发送请求时，用来指定服务器的域名。

　　Content-Length字段：服务器在返回数据时，会有Content-Length字段，表示本次回应的数据长度。HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。什么是TCP拆包和粘包问题？怎么解决？

　　Connection字段：常用于客户端要求服务器使用HTTP长连接机制，以便其他请求复用。

　　4.15 TCP Keepalive 和 HTTP Keep-Alive 是一个东西吗？ | 小林coding (xiaolincoding.com)

　　Content-Type字段：用于服务器回应时，告诉客户端，本次数据是什么格式。客户端请求的时候，可以使用 Accept​ 字段声明自己可以接受哪些数据格式。

　　Content-Type字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。客户端在请求时，用 Accept-Encoding​ 字段说明自己可以接受哪些压缩方法。

HTTP断点续传原理？

　　HTTP必知必会——断点续传原理 - 简书 (jianshu.com)

　　简单来说多了 Range和Content-Range字段，来确认续传位置 同时返回码也变为206

GET和POST？

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

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

　　GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。

　　POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存

RFC 规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。

另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的

除了POST和GET，你还知道什么及其作用（HTTP有哪些请求方法）？

请求	作用
GET	请求页面，并返回页面内容
POST	大多用于提交表单或者上传文件，数据包括在body中
HEAD	类似于GET请求，只不过返回的响应中没有具体的内容，用于获取包头
PUT	从客户端向服务器传送的数据取代指定文档中的内容
DELETE	请求服务器删除指定的页面
CONNECT	服务器当作跳板，让服务器代替客户端访问其他网页
OPTIONS	允许客户端查看服务器的性能
TRACE	回显服务器收到的请求，主要用于测试或者诊断

为什么HTTP是无状态的？

　　HTTP协议为什么是无状态的？无状态指的是什么_名称解释 完全无状态是什么意思_窝窝头蘸番茄酱的博客-CSDN博客

　　简而言之，最初http协议只是浏览静态文件，无状态足够，后面加一层就行，维持状态负担太大。

　　实现有状态：cookies，session，application

　　​​

如果浏览器禁用Cookie，如何记录HTTP状态信息？

　　如果浏览器禁用Cookie，如何记录HTTP状态信息？

　　一种方法是使用URL重写，把会话ID附加在HTML页面中所有的URL上，这样每次请求时会话ID都会作为URL的一部分发送回服务器。

　　另一种方法是在登录成功后将会话ID返回给前端，然后前端通过其他可用的数据持久化技术，将会话ID保存在客户端硬盘中​^2^，然后在后续的请求中，根据浏览器是否禁用Cookie来判断是否需要将”;jsessionid=xxx”加入到请求的URL末尾。

如果让你来设计Cookie，你会怎么实现？

　　需要为 Cookie 设置一个有效时间

　　需要为 Cookie 设置路径

　　使用一个唯一的标识符作为 Cookie 的键，然后在服务器端保存与该标识符相关的用户信息。这样可以避免在 Cookie 中直接存储用户信息，提高安全性和效率。

如果让你来设计 Session，你会怎么实现？

• 用户首次访问时生成唯一ID(session_id​)
• 根据session_id作为唯一标示，生成session_id为名称的文件(储存session内容，当然也可以存到redis或者mysql中)
• 通过cookie下发session_id​到客户端
• 用户再次访问时会通过cookie将session_id​带上
• 服务端通过session_id​获取对应的session内容(文件、Cache、数据库)

HTTP1.0/1.1/2/3区别？

　　​​

　　HTTP1.0：短连接

　　HTTP1.1：长连接，管道传输 HTTP层队头阻塞

　　HTTP2： TCP层队头阻塞

　　基于HTTPS，安全保障；

　　头部压缩（头信息表，发送头索引），二进制格式（头信息帧，数据帧），并发传输（Stream复用连接，=>Message=>frame），服务器主动推送资源

　　​​

　　客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

　　HTTP3

　　改下层TCP为UDP，使用基于UDP的QUIC协议实现可靠传输。

　　QUIC特点：

1. 无队头阻塞 只会阻塞stream
2. 更快的连接建立
3. 连接迁移

　　​​

QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能

HTTP缓存技术？

　　对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据

　　缓存实现方式：强制缓存和协商缓存

　　强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边

　　强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

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

　　通过比较过期时间和请求资源时间来计算出资源是否过期

　　协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

　　​​

HTTP特性？

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

　　其他的就分版本特性展开讲。

HTTPS 从客户端到服务器端全流程，包括 CA 验证体系

　　HTTPS 是如何解决三个风险的？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。

　　SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

　　前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

　　TLS 的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法 ​(opens new window)和 ECDHE 算法 ​(opens new window)。

TLS 协议建立的详细流程

　　1. ClientHello

　　首先，由客户端向服务器发起加密通信请求，也就是 ClientHello​ 请求。

　　在这一步，客户端主要向服务器发送以下信息：

　　（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。

　　（2）客户端生产的随机数（Client Random​），后面用于生成「会话秘钥」条件之一。

　　（3）客户端支持的密码套件列表，如 RSA 加密算法。

　　2. SeverHello

　　服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello​。服务器回应的内容有如下内容：

　　（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。

　　（2）服务器生产的随机数（Server Random​），也是后面用于生产「会话秘钥」条件之一。

　　（3）确认的密码套件列表，如 RSA 加密算法。

　　（4）服务器的数字证书。

　　3.客户端回应

　　客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

　　如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

　　（1）一个随机数（pre-master key​）。该随机数会被服务器公钥加密。

　　（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

　　（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

　　上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。

　　服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

　　4. 服务器的最后回应

　　服务器收到客户端的第三个随机数（pre-master key​）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

　　然后，向客户端发送最后的信息：

　　（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

　　（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

　　至此，整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

　　‍

CA验证体系

　　CA 签发证书的过程：

• 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

　　客户端校验服务端的数字证书的过程：

• 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
• 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

　　HTTP数据保证完整性：TLS记录协议。

　　TLS 在实现上分为握手协议和记录协议两层：

• TLS 握手协议即TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）；
• TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议；

　　TLS 记录协议主要负责消息（HTTP 数据）的压缩，加密及数据的认证

　　具体过程如下：

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

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

　　‍

知道哪些非对称密钥算法？

　　非对称加密算法 (RSA、DSA、ECC、DH) - 简书 (jianshu.com)

对称加密和非对称加密的适用场景

　　对称场景：加密会话

　　非对称：签名(==服务端加签、客户端解签验证==)、加解密

　　对称加密主要的运算是位运算，速度非常快，如果使用硬件计算，速度会更快

　　非对称加密计算一般都比较复杂，比如 RSA，它里面涉及到大数乘法、大数模等等运算，速度较慢