应用层

HTTP

3. 🌟请说一下 HTTP 的状态码？

• 301：永久重定向
• 302：临时重定向
• 400：语法错误
• 401：表示需要认证
• 403：表示请求被拒绝
• 404：没发现资源
• 500：服务器内部出现故障
• 503：服务器正在维护，或者已经超载

4. 🌟请说下转发和重定向的区别？

先简单说下转发的含义

在 Web 开发领域，转发（Forward）主要是指服务器端的一种操作。

当服务器收到客户端（如浏览器）的请求时，它可以将这个请求从一个 Web 组件（如一个 Servlet 或 JSP 页面）传递到另一个 Web 组件进行处理。

请求次数：

URL 显示：

数据共享范围：

5. 请说一下 HTTP 长连接和短链接

• 短链接：每进行一次 HTTP 通信，就要断开一次 TCP 连接
• 持久连接：建立一次 TCP 连接后进行多次请求和响应的交互，HTTP 头部添加以下配置

Connection:keep-alive

6. 🌟GET 和 POST 请求方式有什么不同？

Http 常用的请求方法共有 8 种，

• 在 HTTP1.0 中，定义了三种请求方法：GET、POST 和 HEAD 方法。
• 在 HTTP1.1 中，新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE 和 CONNECT 方法 但我们常用的一般就是 GET 和 POST 请求。

我们常用的 GET，POST 的区别：

• GET 有长度限制
• POST 比 GET 安全，因为 GET 的数据是直接在 URL 中暴露出来的。POST 数据不会显示在 URL 中,是放在 Request body 中。
• 参数类型：GET 只支持 ASCLL 码，POST 没有要求。
• GET 请求会保存在浏览器记录里，POST 浏览器也不会保存。
• GET 只支持 URL 编码，POST 则没有限制
• GET 会被浏览器主动缓存，POST 则不会
• GET 回退是无害的，POST 则是再次发出请求。

对比项	GET 方法	POST 方法
参数位置	附加在 URL 后（`key1=value1&key2=value2`）	封装在 HTTP 请求体（Request Body）
数据长度	受 URL 长度限制（通常 2048~8192 字符）	理论上无限制（但服务器可配置限制）
安全性	❌ 不安全（参数明文暴露在 URL、浏览器历史、服务器日志）	✅ 相对安全（参数不直接暴露，但未加密仍可被拦截）
编码类型	仅 `application/x-www-form-urlencoded`	支持多种编码（如 `multipart/form-data`、`application/json` 等）
缓存	✅ 会被浏览器主动缓存	❌ 默认不缓存（需手动设置 `Cache-Control`）
回退/刷新	✅ 无害（直接从缓存读取）	⚠️ 会重复提交数据（浏览器弹窗警告）
参数类型	仅 ASCII 字符（需 URL 编码）	支持二进制数据（如文件上传）
幂等性	✅ 是（多次请求结果相同）	❌ 否（可能修改服务器状态，如提交订单）
可见性	参数可见于： • 浏览器地址栏 • 历史记录 • 服务器日志	参数仅存在于： • 请求体 • 开发者工具网络面板
典型场景	获取数据（搜索、页面跳转）	修改数据（登录、表单提交、文件上传）
HTTP 语义	用于 获取资源 （Safe + Idempotent）	用于 创建/修改资源 （Non-Idempotent）
性能	⚡ 更快（可缓存、无 Body 处理开销）	⏳ 稍慢（需解析 Body）
书签/分享	✅ 可保存为书签或分享 URL（含参数）	❌ 无法直接保存参数

7. GET有没有Request Body呢？

没有，因为 GET 是直接把参数暴露在外面的，但是浏览器对 URL 的大小限制为 2K，所以如果长度太大，也就是 URL 参数较多，则有可能不被接收。

有人说 POST 比 GET 安全，这是因为 POST 的数据在地址栏 URL 中看不到。它其实在 HTTP 中，他们两个都是不安全的，因为 HTTP 是明文传输。

8. GET和POST请求发送的数据包有什么不同？

GET 是一个包将 Header 和 body 同时发送过去，POST 是先发送 head，再发送 body，分两个包发送。

就像是 GET 只需要汽车跑一趟就把货送到了，而 POST 得跑两趟，第一趟，先去和服务器打个招呼老铁，我等下要送一批货来，你们准备接收一下哈，然后第二趟再回头把货送过去。

GET 和参数有没有大小限制呢？

在 HTTP 协议规范本身，并没有严格规定 GET 方法参数大小的限制。

这是因为 HTTP 协议主要关注的是请求 - 响应的通信机制，而不是对参数大小进行强制约束。

理论上，只要网络、服务器和客户端软件等支持，GET 方法可以传递很长的参数。

但是这只是理论上 实际应用中浏览器会对其进行限制，不同的浏览器对 GET 请求的 URL 长度（包括参数部分）有不同的限制。

因为如果 URL 过长，可能会导致浏览器性能下降，如地址栏显示问题、历史记录存储问题等，同时也可能增加安全风险，例如某些恶意的超长 URL 可能用于攻击。

服务器软件也可能对 GET 请求的参数大小进行限制。例如，Apache 服务器默认有一个对 URL 长度的限制设置，虽然这个设置可以通过配置文件进行调整，但在默认情况下，如果 GET 请求的参数过长，可能会导致服务器返回 414（Request - URI Too Long）错误。

网络中的一些中间设备，如代理服务器、防火墙等，也可能对 URL 长度进行限制。这些设备在处理网络流量时，如果遇到过长的 GET 请求 URL，可能会截断请求或者返回错误信息。这是为了防止某些恶意的超长 URL 对网络安全和性能造成威胁，同时也是为了避免这些设备自身的资源被过度占用。

9. 请说一下 HTTP 1.1 的特点

HTTP1.0 和 HTTP 1.1 的一些区别

HTTP1.0 最早在网页中使用是在 1996 年，那个时候只是使用一些较为简单的网页上和网络请求上，而 HTTP1.1 则在 1999 年才开始广泛应用于现在的各大浏览器网络请求中，同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议。 主要区别主要体现在：

1. 缓存处理：在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用，错误通知的管理：在 HTTP1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 长连接：HTTP 1.1 支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP1.1 中默认开启 Connection： keep-alive，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。
4. Host 头处理：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。

10. 请说一下 HTTP 2.0 的特点

二进制编码：HTTP/2 厉害的地方在于将 HTTP/1 的文本格式改成二进制格式传输数据，极大提高了 HTTP 传输效率，而且二进制数据使用位运算能高效解析，这里一句话总结就是，将侦使用二进制格式传输。 header 压缩：

HTTP/2 没使用常见的 gzip 压缩方式来压缩头部，而是开发了 HPACK 算法，HPACK 算法主要包含三个组成部分：

• 静态字典；
• 动态字典；
• Huffman 编码（压缩算法）

客户端和服务器两端都会建立和维护字典，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。静态表是保存在 http2 框架里的。

多路复用分侦（server push）：HTTP 2.0 其实是将三个请求变成三个流，将数据分成帧，乱序发送到一个 TCP 连接中。将一个请求变成一个流，然后再将流拆分成侦，然后这些侦是可以混杂在一起进行发送。

服务端主动发送：可以在用户请求 html 时，可以主动的推送 css 资源，一次请求，多次发送。

11. http3.0 QUIC 和之前有不同？

http 多是基于 TCP 的传输，因为 HTTP 2.0 也是基于 TCP 协议的，TCP 协议在处理包时是有严格顺序的。当其中一个数据包遇到问题，TCP 连接需要等待这个包完成重传之后才能继续进行。

虽然 HTTP 2.0 通过多个 stream，使得逻辑上一个 TCP 连接上的并行内容，进行多路数据的传输，然而这中间并没有关联的数据。一前一后，前面 stream 2 的帧没有收到，后面 stream 1 的帧也会因此阻塞。

基于 UDP 自定义的类似 TCP 的连接

一条 TCP 连接是由四元组标识的，分别是源 IP、源端口、目的 IP、目的端口。ip 改变之后连接断开

QUIC 自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，所以当 IP 或者端口变化的时候，只要 ID 不变，就不需要重新建立连接。

重发

tcp 的重发是有缺陷的，发送端发送一个数据包，由于网络堵塞，发送失败，进行重传之后，接收端收到包之后，不知道应该如何计算往返时间，不利于我们拥塞控制。

这里加入了，偏移量和 id，重发之后加 1 即可。

HTTP 协议版本对比

特性维度	HTTP/1.0 (1996)	HTTP/1.1 (1999)	HTTP/2 (2015)	HTTP/3 (QUIC) (2022)
传输协议	TCP	TCP	TCP	UDP
连接方式	短连接（默认）	长连接（默认Keep-Alive）	多路复用单连接	基于UDP的多路复用连接
数据传输格式	文本	文本	二进制分帧	二进制分帧
头部压缩	无	无	HPACK算法（静态/动态字典+Huffman编码）	QPACK算法（改进版HPACK）
多路复用	❌ 不支持	❌ 不支持（虽有Pipelining但存在队头阻塞）	✅ 单连接并行传输多个请求	✅ 彻底解决队头阻塞（流间独立）
服务器推送	❌ 不支持	❌ 不支持	✅ 主动推送关联资源	✅ 保留推送能力
头部Host支持	❌ 可选	✅ 必需（否则返回400错误）	✅ 继承1.1	✅ 继承
典型延迟问题	高（每次请求新建TCP连接）	中（复用连接但仍有队头阻塞）	低（二进制分帧但受TCP队头阻塞影响）	极低（UDP无队头阻塞）
错误状态码扩展	基础16种	新增24种（如409/410）	继承1.1	继承
移动网络适应性	❌ 差（频繁握手）	⚠️ 一般（TCP重传效率低）	⚠️ 较好（但TCP迁移需重建连接）	✅ 优秀（连接ID保持，IP变化不中断）

多路复用

有了自定义的连接和重传机制，我们就可以解决上面 HTTP 2.0 的多路复用问题。同 HTTP 2.0 一样，同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求。但是，QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖。这样，假如 stream2 丢了一个 UDP 包，后面跟着 stream3 的一个 UDP 包，虽然 stream2 的那个包需要重传，但是 stream3 的包无需等待，就可以发给用户。

流量控制技术

在 TCP 协议中，接收端的窗口的起始点是下一个要接收并且 ACK 的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为 TCP 的 ACK 机制是基于序列号的累计应答，一旦 ACK 了一个序列号，就说明前面的都到了，所以只要前面的没到，后面的到了也不能 ACK，就会导致后面的到了，也有可能超时重传，浪费带宽。

只要收到的，就进行确认，因为后面的到了，前面的肯定已经发送，所以我们可以移动窗口，等待确认前面的和重发即可。

12. HTTP 的缺点

• 明文传输
• 没有校验，有可能被篡改
• 没有验证通信方身份

HTTPS 采用混合加密机制，位于 HTTP/TCP 之间，主要为高层协议服务。

• 安全性问题

  • 数据明文传输：HTTP 协议以明文方式传输数据。在这个过程中，数据包括请求信息（如用户登录的账号和密码、用户提交的各种表单内容）和响应信息（如服务器返回的包含用户敏感信息的内容）都是未经加密的。
  • 缺乏身份验证机制：HTTP 本身没有提供足够强大的身份验证机制来确保通信双方的身份真实可靠。当客户端与服务器进行通信时，很难验证对方是否是真正的目标服务器或者合法的客户端。这使得服务器容易受到中间人攻击，攻击者可以伪装成合法的客户端或者服务器，获取和篡改数据。

• 性能和效率方面的局限

  • 无状态性带来的额外开销：HTTP 是无状态协议，这意味着每个请求都是独立的，服务器不会记住之前和同一个客户端的交互情况。为了实现需要状态信息的功能，如用户登录状态的保持、购物车数据的维护等，就需要使用额外的技术，如 Cookie 或者 Session，这增加了系统的复杂性和开销。
  • 头信息的限制和开销：HTTP 请求和响应头信息（Header）有一定的格式和大小限制。头信息中包含了很多重要的信息，如请求的方法（GET、POST 等）、资源的类型、缓存控制信息等。
  • 然而，这些头信息可能会变得冗长，尤其是在现代复杂的 Web 应用中，可能会包含大量的自定义头信息。过多或过长的头信息会增加网络传输的开销，并且在一些情况下，可能会受到服务器或者代理的限制，影响请求的正常发送和接收。

• 不适合实时性要求高的场景

  • 请求 - 响应模式的延迟：HTTP 采用请求 - 响应的通信模式。这意味着客户端必须先发送请求，然后等待服务器的响应。在一些实时性要求很高的场景中，如实时视频流传输、在线游戏的实时操作等，这种模式会带来明显的延迟。

• 无法主动推送信息：HTTP 协议本身没有提供服务器主动向客户端推送信息的机制。在很多现代 Web 应用中，如股票行情实时更新、新闻实时推送等场景，需要服务器能够及时地将最新信息发送给客户端，而 HTTP 无法很好地满足这一需求。需要借助其他技术（如长轮询、WebSocket 等）来实现类似的功能。

13. HTTP 与 HTTPS 核心特性对比

特性维度	HTTP	HTTPS
传输方式	明文传输	加密传输（SSL/TLS）
默认端口	80	443
加密机制	❌ 无	✅ 混合加密（对称+非对称）
数据完整性	❌ 可能被篡改	✅ 哈希校验（防止篡改）
身份验证	❌ 无	✅ 证书认证（CA机构签发）
安全性风险	中间人攻击、嗅探、篡改	需妥善管理私钥（否则仍可能被破解）
性能开销	⚡ 低（无加密计算）	⏳ 高（增加10-30%延迟，CPU计算开销）
适用场景	不敏感信息传输（如静态页面）	敏感数据交互（登录、支付等）

HTTP 的固有缺陷详解

缺陷类型	具体表现	HTTPS 解决方案
明文传输	请求/响应内容可被中间节点直接读取	全链路加密（AES等对称加密）
篡改风险	攻击者可修改传输中的内容（如注入广告）	消息认证码（MAC）校验
身份伪造	无法验证服务器真伪（可能导致钓鱼网站）	数字证书+CA链式验证
无状态性	需依赖Cookie/Session维护状态	同样无状态，但加密保护会话ID
头信息膨胀	重复头部字段（如User-Agent）浪费带宽	HPACK压缩（HTTP/2+）
实时性不足	必须由客户端发起请求	仍需WebSocket等扩展协议

14. 🌟请说一下 HTTP 请求过程

1. 域名解析获取 IP 地址

   • 浏览器按顺序查找域名对应的 IP 地址，依次搜索浏览器缓存、系统缓存、路由器缓存、ISP DNS 缓存。

2. 建立 TCP 连接（三次握手）

   • 客户端与服务器通过 TCP 的三次握手建立连接，为 HTTP 请求传输做准备。

3. 发送 HTTP 请求

   • 请求报文组成：由请求行、请求头部、空行和请求数据（GET 方法一般无请求数据）组成。
   • 请求行：包含请求方法（如 GET、POST 等）、URL 和协议版本。
     • GET 用于读取文档，请求参数附在 URL 后，有长度限制且不适合私密数据传输；POST 用于向服务器提供较多信息，参数封装在请求数据中，可传输大量数据且不显示在 URL 中。
     • URL 由协议、主机、端口（HTTP 默认 80 可省略）、路径和参数组成。
     • 协议版本常见有 HTTP/1.0 和 HTTP/1.1。
   • 请求头部：由 “名 / 值” 对组成，每行一对，名和值用冒号分隔，最后有空行，包含如 Host、User - Agent 等信息。
   • 请求数据（POST 方法）：与 Content - Type 和 Content - Length 等请求头部相关，数据格式如 application/x - www - form - urlencoded。

4. 服务器处理请求并响应

   • 响应报文组成：由状态行、响应头部、空行和响应数据组成。
   • 状态行：包含协议版本、状态码（如 200 表示成功、404 表示未找到等）和状态码描述。
   • 响应头部：包含如 Server、Content - Type 等信息。
   • 响应数据：存放返回给客户端的数据，如 HTML 代码等。

5. 浏览器后续操作

   • 解析 HTML 代码，遇到静态资源则向服务器请求下载。
   • 渲染静态资源和 HTML 代码，呈现页面给用户，最后关闭 TCP 连接（通过四次挥手）。

可视化流程

15. 🌟能不能详细介绍一下 HTTPS ？

HTTPS 的基本概念与作用

定义：HTTPS（Hypertext Transfer Protocol Secure）即超文本传输安全协议，是在 HTTP 协议基础上加入 SSL/TLS 协议，通过加密通信和身份认证来保障数据传输安全的网络协议。

作用：主要用于保护用户与网站之间的数据交换安全，防止数据被窃取、篡改或伪造。例如，在网上银行进行交易时，用户输入的账号、密码、交易金额等敏感信息通过 HTTPS 加密后传输，确保只有银行服务器能够解密获取真实信息，有效防止黑客在网络传输过程中截获并窃取用户资金。

加密机制

对称加密与非对称加密结合：

• 对称加密：在 HTTPS 中，对称加密用于加密实际传输的数据内容。它使用相同的密钥进行加密和解密，具有加密和解密速度快的优点，适用于对大量数据进行快速加密处理。例如，在传输一段较长的网页文本内容时，采用对称加密可以高效地对其进行加密保护。常用的对称加密算法有 AES（Advanced Encryption Standard）等。
• 非对称加密：主要用于在客户端和服务器首次建立连接时交换对称加密密钥。非对称加密使用公钥和私钥两个不同的密钥，公钥可以公开，任何人都可以用公钥对数据进行加密，但只有持有私钥的一方才能解密。例如，服务器将自己的公钥发送给客户端，客户端用公钥加密对称加密密钥后发送给服务器，服务器再用私钥解密获取对称加密密钥。这样，即使公钥在传输过程中被黑客获取，黑客也无法解密后续用对称加密密钥加密的数据。常用的非对称加密算法有 RSA 等。

数字证书与证书颁发机构（CA）：

• 数字证书：服务器向客户端证明其身份时使用数字证书。数字证书包含服务器的公钥、服务器信息（如域名等）以及证书颁发机构的数字签名等内容。例如，当用户访问一个电商网站时，服务器会向用户的浏览器发送其数字证书，浏览器通过验证证书中的信息来确认是否信任该服务器。
• 证书颁发机构（CA）：是可信的第三方机构，负责为服务器颁发数字证书并对其真实性进行验证。CA 使用自己的私钥对服务器的数字证书进行签名，客户端浏览器内置了多个知名 CA 的公钥，用于验证服务器数字证书的签名是否有效。如果签名有效且证书中的服务器信息与实际访问的服务器相符，浏览器就认为服务器是可信的。

工作流程

• 客户端发起 HTTPS 请求：用户在浏览器中输入一个以 “https://” 开头的网址，浏览器向服务器的 443 端口（HTTPS 默认端口）发送连接请求，开始 HTTPS 通信。
• 服务器响应并发送数字证书：服务器收到请求后，将包含公钥的数字证书发送给客户端。
• 客户端验证数字证书：客户端收到数字证书后，使用本地存储的 CA 公钥验证证书的签名是否有效，同时检查证书中的服务器信息（如域名）是否与正在访问的服务器一致。如果验证失败，浏览器会提示用户证书存在问题，可能存在安全风险；如果验证成功，则继续下一步。
• 生成对称加密密钥并交换：客户端生成一个对称加密密钥，用服务器的公钥对其进行加密后发送给服务器。服务器收到后，用自己的私钥解密获取对称加密密钥。
• 使用对称加密进行数据传输：此后，客户端和服务器之间就使用对称加密密钥对传输的数据进行加密和解密，确保数据在网络传输过程中的保密性和完整性。

16. HTTPS 核心机制详解

组件/阶段	技术原理	关键功能	典型实现
基础定义	HTTP + SSL/TLS 加密层	保障数据传输安全	默认端口443
核心作用	三重保护： 1. 数据加密 2. 身份认证 3. 完整性校验	防窃听/防篡改/防伪装	银行/电商等敏感场景强制使用

加密机制

加密类型	密钥管理	性能特点	应用场景	常见算法
对称加密	共享同一密钥	⚡ 加密速度快	加密实际传输数据	AES-256, ChaCha20
非对称加密	公钥加密/私钥解密	⏳ 速度慢1000倍	密钥交换和身份认证	RSA-2048, ECDSA

数字证书体系

组件	功能说明	验证要点
数字证书	包含：- 公钥 - 域名信息 - 有效期 - CA签名	1. 检查CA签名有效性 2. 核对访问域名 3. 验证有效期
CA机构	签发证书的可信第三方（如DigiCert/Let's Encrypt）	浏览器内置根证书库

17. HTTPS 工作流程分步解析

步骤	交互过程	技术细节
1	客户端发起请求 ClientHello (TLS版本/加密套件支持)	支持的加密套件示例：`TLS_AES_256_GCM_SHA384`
2	服务器响应 ServerHello (选定加密套件) + 数字证书	证书包含：- 域名- 公钥- 签发机构
3	证书验证 浏览器校验： 1. CA签名 2. 域名匹配 3. 有效期	若失败显示警告：`NET::ERR_CERT_INVALID`
4	密钥交换 客户端生成会话密钥 → 用证书公钥加密 → 发送给服务器	前向保密机制：ECDHE临时密钥交换
5	加密通信 使用对称密钥加密所有后续通信	数据加密示例：`AES-256-GCM` + `SHA-384`完整性校验

安全特性对比

安全威胁	HTTP风险	HTTPS解决方案
窃听	明文传输可直接读取	AES加密数据
篡改	可中间注入恶意代码	HMAC哈希校验
伪装

18. HTTPS 与 HTTP 的区别

• 安全性：HTTP 以明文形式传输数据，容易被窃取和篡改；HTTPS 通过加密和身份认证保障数据安全，有效防止中间人攻击等安全威胁。例如，在未加密的 HTTP 下，黑客可以轻易截获用户在登录页面输入的账号密码；而在 HTTPS 下，这些信息被加密传输，黑客难以获取真实内容。
• 端口号：HTTP 默认使用 80 端口，HTTPS 默认使用 443 端口。
• 搜索引擎优化（SEO）影响：搜索引擎通常更倾向于将使用 HTTPS 的网站排在搜索结果的前列，因为 HTTPS 代表网站更注重用户数据安全，这在一定程度上有助于提高网站的访问量和排名。

DNS

19. 🌟请说一下在浏览器输入网址显示页面的过程

整体流程如图：

1. 查询浏览器缓存，如果有直接访问
2. 查询本地 host 文件，查询本地缓存，或者使用 cmd ,使用 ipconfig /displaydns 命令查询
3. 向 DNS 服务器发送 DNS 请求，查询本地 DNS 服务器（此时用到的是递归查询），这其中用的是 UDP 的协议
4. 本地域名服务器会向 根域名服务器发送一个请求，如果根域名服务器也不存在该域名时，
5. 本地域名会向顶级域名服务器的下一级 DNS 服务器发送一个请求，依次类推下去。直到最后本地域名服务器得到 google 的 IP 地址并把它缓存到本地，供下次查询使用。（上诉的迭代方式是迭代查询）
6. 此时我们已经知道了 ip 地址，及其默认的端口号，http 默认的是 80 端口，https 默认的是 https 端口
7. 我们首先会尝试使用 http 建立 socket 连接，三次握手之后，开始传送数据，如果是 http 的话，那么则接收数据，如果不是 http,是 https 则会返回 3 开头的重定向，将端口号从 80 端口改成 443 端口，并四次挥手断开之前的连接。
8. 再来一遍三次握手，此时还会采用 SSL 的加密技术来保证传输数据的安全性，保证数据传输过程中不被修改或者替换之类的
9. 沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的 CA 安全证书。
10. 连接完毕，开始传输数据

20. 🌟请简单介绍一下 Cookie

Cookie 是一种存储在用户本地终端（通常是浏览器）上的小文本文件，用于记录用户的某些信息或状态。它由服务器发送给浏览器，浏览器会根据服务器设置的规则（如有效期、作用域等）来存储和发送 Cookie。

当用户第一次访问某个网站时，服务器可以通过在响应头中添加 Set - Cookie 字段来发送 Cookie 信息给浏览器。

之后，当浏览器再次访问该网站的同一域名下的页面时，会在请求头中自动带上存储的 Cookie 信息。服务器通过读取这个 Cookie 信息，就可以识别出用户的身份或者其他相关状态，从而为用户提供个性化的服务，如记住用户登录状态、用户偏好设置等。

Cookie 是为了支持 Web 应用程序（如网页浏览）而设计的一种机制，用于在 HTTP 协议（应用层协议）的请求和响应过程中传递信息，帮助服务器识别和跟踪用户

21. 🌟请简单介绍一下 Session

Session 是一种服务器端的机制，用于在多个页面请求之间跟踪用户的状态。它是基于会话的概念，一个会话代表了用户与服务器之间的一系列交互过程，从用户开始访问网站到用户离开（如关闭浏览器或者长时间未操作）。

当用户第一次访问服务器时，服务器会为该用户创建一个唯一的会话 ID（Session ID），这个 ID 可以通过多种方式存储在服务器端，如内存、数据库或者文件系统中。

服务器会将这个 Session ID 以某种方式发送给浏览器，通常是通过在响应头中设置 Cookie（将 Session ID 作为 Cookie 的 value）来实现。

在后续的请求中，浏览器会将这个 Session ID 发送回服务器，服务器通过这个 Session ID 来查找对应的会话信息，从而获取用户的状态数据。

例如，在一个购物网站中，用户将商品加入购物车的操作会被记录在服务器端的 Session 数据中，当用户查看购物车或者结算时，服务器通过 Session ID 找到对应的购物车数据，为用户提供服务。

Session 也是工作在应用层，也是为了支持 Web 应用程序的状态管理而存在的，主要用于处理 HTTP 请求和响应过程中的用户状态跟踪。

22. 🌟请说一下 Cookie 和 Session 的区别与联系

区别：

联系

Cookie 和 Session 常常一起使用，Session ID 通常借助 Cookie 来在浏览器和服务器之间传递，使得服务器能够识别用户的会话，从而实现用户状态的跨页面跟踪。

Cookie vs Session 核心对比

对比维度	Cookie	Session
存储位置	客户端浏览器	服务器端（内存/数据库/文件）
安全性	⚠️ 较低（直接暴露在浏览器中）	✅ 较高（仅传输Session ID）
存储容量	通常≤4KB（不同浏览器有差异）	理论上仅受服务器内存限制
数据类型	仅支持字符串	支持复杂对象（Java/Python等可序列化对象）
生命周期	可设置过期时间（持久化Cookie）或会话级（浏览器关闭失效）	通常会话级（用户退出或超时失效，默认30分钟）
跨域支持	受同源策略限制（但可通过`Domain`和`Path`属性控制）	天然支持跨域（通过Session ID识别）
性能影响	无服务器开销	服务器需要维护会话存储
典型应用场景	记住登录状态、用户偏好设置、追踪用户行为	购物车数据、敏感临时信息（如验证码）、多步骤表单