HTTP ​

1. 简述 TCP 连接的过程（淘系）
2. 介绍下 HTTPS 中间人攻击
3. 介绍下 HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 协议的区别？
4. 为什么 HTTP/1.1 不能实现多路复用（腾讯）
5. 简单讲解一下 HTTP/2 的多路复用（网易）
6. 谈谈你对 TCP 三次握手和四次挥手的理解
7. 介绍 HTTPS 握手过程
8. HTTPS 握手过程中，客户端如何验证证书的合法性
9. HTTP 状态码 301 和 302 的应用场景分别是什么
10. cookie 和 token 都存放在 header 中，为什么不会劫持 token？
11. 介绍下如何实现 token 加密
12. 说下单点登录（新东方）
13. HTTP/1.1 是如何复用 TCP 连接的？（网易）
14. 文件上传如何做断点续传（网易）
15. 介绍 SSL 和 TLS（寺库）
16. 说说网络的五层模型（寺库）
17. GET 和 POST 的区别（流利说）
18. HTTP 劫持是什么？
19. HTTP 劫持、DNS 劫持与 XSS
20. 介绍 xss csrf 攻击
21. HTTPS 验证身份也就是 TSL/SSL 身份验证的过程
22. 为什么需要 CA 机构对证书签名
23. 身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下
24. webSocket 协议是什么，能简述一下吗？
25. webSocket 与传统的 http 有什么优势
26. 如何劫持 https 的请求，提供思路
27. 怎样解决跨域问题？
28. 前端如何实现即时通讯？
29. HTTP 常用状态码 301 302 304 401 403 502
30. 在浏览器地址栏输入地址，并按下回车键后，发生了哪些事情？
31. 网页验证码是干嘛的，是为了解决什么安全问题？
32. cookie/sessionStorage/localStorage 的区别
33. post 请求什么时候用 form data 什么时候用 request payload
34. http 常见请求方法有哪些？
35. 列举优化网络性能方法
36. session 怎么消除
37. 什么是 DNS 域名解析？工作流程？

DNS 域名解析的工作流程 ​

1. 查询浏览器 DNS 缓存
2. 查询操作系统 DNS 缓存
3. 查询 hosts 文件
4. 查询本地域名服务器（ISP），一般是递归查询
   1. 本地域名服务器无，则发起迭代查询
   2. 根域名服务器
   3. 顶级域名服务器
   4. 权威 DNS 服务器

TCP/IP 网络参考模型 ​

TCP/IP 网络参考模型共有 四/五 层：

1. 应用层：HTTP、FTP、TFTP、SMTP、SNMP、DNS
2. 传输层：TCP、UDP、SSL/TLS
3. 网络层：IP、ARP、RARP、ICMP、IGMP
4. 网络接口层 (数据链路层 <=> 物理层)

ARP: 地址解析协议，即 ARP（Address Resolution Protocol），是根据 IP 地址获取物理地址的一个 TCP/IP 协议

OSI 参考模型，共有七层：

1. 应用层
2. 表示层
3. 会话层
4. 传输层
5. 网络层
6. 数据链路层
7. 物理层

TCP 三次握手与四次挥手 ​

三次握手 ​

一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

1. 客户端发起 SYN 报文
2. 服务端响应 SYN + ACK 报文
3. 客户端响应 ACK 报文

详细

1. 客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
2. 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
3. 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。

服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。

第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。

为什么是三次握手？不是两次、四次？ ​

为什么需要三次握手，两次不行吗？

其实这是由 TCP 的自身特点可靠传输决定的。客户端和服务端要进行可靠传输，那么就需要确认双方的接收和发送能力。

• 第一次握手可以确认客户端的发送能力，
• 第二次握手，确认了服务端的发送能力和接收能力，
• 所以第三次握手才可以确认客户端的接收能力。不然容易出现丢包的现象。

1. 三次握手才能保证双方具有接收和发送的能力
2. 三次握手的原因
   1. 三次握手才可以阻止重复历史连接的初始化（主要原因）
   2. 三次握手才可以同步双方的初始序列号
   3. 三次握手才可以避免资源浪费

三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

为什么挥手需要四次？ ​

从双方发 FIN 包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送（所以不能马上发送 FIN 报文），等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
• 之后客户端回应 ACK 应答报文

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。

但是在特定情况下，四次挥手是可以变成三次挥手的

什么情况会出现三次挥手？ ​

当被动关闭方（服务端）在 TCP 挥手过程中，「没有数据要发送」并且「开启了 TCP 延迟确认机制」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。

然后因为 TCP 延迟确认机制是默认开启的，所以导致我们抓包时，看见三次挥手的次数比四次挥手还多。

TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗？ ​

事实上，这两个完全是两样不同东西，实现的层面也不同：

• HTTP 的 Keep-Alive，是由 应用层（用户态） 实现的，称为 HTTP 长连接；
• TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；

HTTP 协议 ​

HTTP 发展历史以及优化改进

HTTP/0.9 ​

• 只有一个命令 GET
• 响应类型：仅 超文本
• 没有 header 等描述数据的信息
• 服务器发送完毕，就关闭 TCP 连接

HTTP/1.0 ​

• 增加了很多命令（post HESD）
• 增加 status code 和 header
• 多字符集支持、多部分发送、权限、缓存等
• 响应：不再只限于超文本 (Content-Type 头部提供了传输 HTML 之外文件的能力 — 如脚本、样式或媒体文件)

HTTP/1.1 ​

• 持久连接。TCP 三次握手会在任何连接被建立之前发生一次。最终，当发送了所有数据之后，服务器发送一个消息，表示不会再有更多数据向客户端发送了；则客户端才会关闭连接（断开 TCP）
• 支持的方法：GET , HEAD , POST , PUT ,DELETE , TRACE , OPTIONS
• 进行了重大的性能优化和特性增强，分块传输、压缩/解压、内容缓存磋商、虚拟主机（有单个 IP 地址的主机具有多个域名）、更快的响应，以及通过增加缓存节省了更多的带宽

HTTP/1.1 的性能如何？性能关键在于

1. 长连接，也叫持久连接，避免无谓的 TCP 连接建立和断开
2. 管道网络传输（HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持）
3. 队头阻塞

HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

HTTP/1.1 协议的性能问题

• 延迟难以下降
• 并发链接有限（Chrome 6 个）
• 队头阻塞问题
• HTTP 头部巨大且重复
• 不支持服务器推送消息

HTTP/2 ​

• 所有数据以二进制传输。HTTP/1.x 是基于文本的，无法保证健壮性，HTTP/2 使用新的二进制格式，方便且健壮
• 同一个连接里面发送多个请求不再需要按照顺序来
• 头信息压缩以及推送等提高效率的功能

优势

• 头部压缩
• 二进制帧
• 并发传输/多路复用
• 服务器主动推送资源

美中不足的是 HTTP/2 协议是基于 TCP 实现的，于是存在的缺陷有三个。

• 队头阻塞（TCP 层面）
• TCP 与 TLS 的握手时延迟；
• 网络迁移需要重新连接；

HTTP/3 ​

• QUIC“快速 UDP 互联网连接”（Quick UDP Internet Connections）

HTTP/3 的主要改进在传输层上。传输层不会再有我前面提到的那些繁重的 TCP 连接了。现在，一切都会走 UDP。

QUIC 协议的特点

• QUIC 通过连接 ID 来标记通信的两个端点
• 无队头阻塞（UDP 不关心数据包的顺序）
• 更快的连接建立（UDP 是不需要连接的，无需握手、挥手，QUIC 握手仅为确认双方的连接 ID）
• 连接迁移（连接迁移就是基于连接 ID 实现的）

HTTPS ​

在 HTTP 的基础上再加一层 TLS（传输层安全性协议）或者 SSL（安全套接层），就构成了 HTTPS 协议。

HTTPS 默认工作在 TCP 协议 443 端口，它的工作流程一般如以下方式：

1. TCP 三次同步握手
2. 客户端验证服务器数字证书
3. DH 算法协商对称加密算法的密钥、hash 算法的密钥
4. SSL 安全加密隧道协商完成
5. 网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的 hash 算法进行数据完整性保护，保证数据不被篡改。

HTTPS 连接需要 7 次握手，3 次 TCP + 4 次 TLS。

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

HTTP 是超文本传输协议，信息是明文传输，所以安全上存在以下三个风险：

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

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

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

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

HTTPS 有几次握手和挥手？ ​

HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。

在进行 HTTP 通信前，需要先进行 TLS 握手。

通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2 个 RTT 的时延

所以是四次握手

详细资料可以参考：

《HTTP 是个无状态协议，怎么保持登录状态？》

常见 HTTP 状态码 ​

• 1** 信息，服务器收到请求，需要请求者继续执行操作
• 2** 成功，操作被成功接收并处理
• 3** 重定向，需要进一步的操作以完成请求
• 4** 客户端错误，请求包含语法错误或无法完成请求
• 5** 服务器错误，服务器在处理请求的过程中发生了错误

详细

参考

• 详解 四层、五层、七层 计算机网络模型
• https://q.shanyue.tech/base/http/36.html
• gzip 压缩，详见 谷歌响应压缩策略
• 2023 高频前端面试题合集之网络篇
• HTTP、HTTPS、HTTP2 的区别？