客户端先发送FIN，进入FIN_WAIT1状态，用来关闭Client到Server的数据传送

服务端收到FIN，发送ACK，进入CLOSE_WAIT状态，客户端收到这个ACK，进入FIN_WAIT2状态

服务端发送FIN，进入LAST_ACK状态，用来关闭Server到Client的数据传送

客户端收到FIN，发送ACK，进入TIME_WAIT状态，服务端收到ACK，进入CLOSE状态（等待2MSL时 间，约4分钟。主要是防止最后一个ACK丢失。）

四次挥手

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的 ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

五、TCP和UDP的区别以及应用场景

1、概念

TCP（传输控制协议）和 UDP（用户数据报协议）是 TCP/IP 协议族中两种核心的传输层协议，它们在数据传输方式、可靠性、效率等方面存在显著差异，适用于不同的应用场景。

传输层的核心作用

1. 提供进程间通信：通过端口号（如 HTTP 的 80 端口、SSH 的 22 端口）区分同一主机上的不同应用程序，实现进程间的数据传输。
2. 可靠性控制：
   • TCP 通过确认机制、重传机制、流量控制等保证可靠传输。
   • UDP 不提供可靠性，仅尽最大努力交付数据。
3. 数据分段与重组：将上层（应用层）的报文分割为适合传输的段（Segment），或在接收端将接收到的段重组为完整数据。

对比其他层

• 网络层（Network Layer）：如 IP 协议，负责将数据包从源主机传输到目标主机，但不保证可靠性和顺序。
• 应用层（Application Layer）：如 HTTP、SMTP、DNS 等，直接为用户应用程序提供服务。
• 链路层（Link Layer）：负责物理网络的帧传输，如以太网、Wi-Fi 等。

2、核心对比

3、应用场景分析

1. TCP 的典型应用场景

TCP 的可靠性使其适用于对数据准确性要求高、允许一定延迟的场景：

• 文件传输：如 FTP（文件传输协议）、HTTP/HTTPS（网页传输）。文件传输需保证数据完整，不能丢失或损坏，TCP 的重传机制可确保这一点。

• 邮件发送：如 SMTP（简单邮件传输协议）。邮件内容的完整性和顺序至关重要，TCP 能避免邮件内容错乱或丢失。

• 远程登录：如 SSH（安全外壳协议）、Telnet。远程操作指令需要准确执行，TCP 的按序传输可保证指令顺序正确。

• 数据库交互：如 MySQL 的 TCP 连接。数据库查询和修改需确保数据一致性，TCP 的可靠性可防止数据同步错误。

2. UDP 的典型应用场景

UDP 的高效性使其适用于对实时性要求高、可容忍少量数据丢失的场景：

• 实时通信：如视频通话（Skype）、语音通话（VoIP）。实时传输中，延迟比偶尔的数据包丢失更影响体验，UDP 的低延迟特性更适合。

• 流媒体播放：如直播（RTSP/RTP 协议常用 UDP）。直播中，丢失个别帧不会影响整体观看，但若用 TCP 可能因重传导致画面卡顿。

• 游戏数据传输：如多人在线游戏的实时位置、操作指令。游戏需要低延迟响应，少量数据包丢失可通过本地预测补偿，而 TCP 的重传可能导致操作延迟。

• 物联网通信：如传感器数据上报（CoAP 协议）。传感器数据通常周期性发送，少量丢失不影响整体分析，UDP 的低开销更适合资源有限的设备。

• DNS 查询：域名解析（DNS 协议）通常用 UDP。查询数据量小，且即使丢失可快速重发，UDP 的高效性能缩短解析时间。

4、总结

• TCP是 “可靠但低效” 的协议，适合需要保证数据完整性的场景，如文件传输、邮件、数据库交互等。
• UDP是 “高效但不可靠” 的协议，适合需要低延迟、可容忍少量丢失的场景，如实时音视频、游戏、物联网等。

六、用户输入网址到响应界面操作中间发生了什么？

1、DNS 解析：将域名转换为 IP 地址

1. 浏览器缓存检查：浏览器首先检查本地缓存中是否有该域名对应的 IP 地址（缓存时间由 DNS 记录的 TTL 值控制）。

2. 系统缓存检查：若浏览器缓存未命中，则检查操作系统的 hosts 文件或本地 DNS 缓存（如 Windows 的 DNS Client 服务）。

3. 本地 DNS 服务器查询：若仍未命中，请求本地 DNS 服务器（通常由 ISP 提供）。本地 DNS 服务器会先检查自身缓存，若没有则进行递归查询。

4. 递归查询流程：

   • 根 DNS 服务器（.com、.cn 等顶级域名服务器的地址）。

   • 顶级域 DNS 服务器（如.com 域名服务器）。

   • 权威 DNS 服务器（如example.com的具体 DNS 服务器）。

5. 获取 IP 地址：最终从权威 DNS 服务器获取目标网站的 IP 地址，并逐级返回给浏览器。

2、TCP 连接：建立与服务器的可靠通信

1. TCP 三次握手：

   • 客户端发送 SYN 包，请求建立连接，并携带初始序列号（ISN）。

   • 服务器返回 SYN+ACK 包，确认请求并发送自己的初始序列号。

   • 客户端发送 ACK 包，完成连接建立。

2. TCP 参数协商：双方协商 MSS（最大段大小）、窗口大小等参数，优化数据传输。

3、HTTP 请求：发送网页资源请求

1. 构建 HTTP 请求报文：包含请求行（如 GET /index.html HTTP/1.1）、请求头（如 User-Agent、Cookie 等）和请求体（如 POST 请求的数据）。

2. HTTPS 额外步骤（若启用）：

   • TLS 握手：协商加密算法、验证服务器证书、生成会话密钥。

   • 数据加密：后续 HTTP 数据通过对称加密传输。

4、服务器处理请求

1. 负载均衡（若存在）：请求先到达负载均衡器（如 Nginx、AWS ELB），被转发到合适的后端服务器。

2. Web 服务器接收请求：如 Apache、Nginx 处理 HTTP 请求，解析请求头和 URL。

3. 应用服务器处理：

   • 静态资源：直接返回文件（如 HTML、CSS、JS）。

   • 动态资源：调用应用程序（如 PHP、Python、Java）生成响应。

4. 数据库交互（若需要）：应用程序查询数据库获取数据（如用户信息、文章内容）。

5. 生成 HTTP 响应：包含状态码（如 200 OK、404 Not Found）、响应头（如 Content-Type、Cache-Control）和响应体（网页内容）。

5、HTTP 响应：返回数据到客户端

1. 服务器发送响应：将 HTTP 响应通过 TCP 连接返回给客户端。

2. 客户端接收响应：

   • 解析响应头：获取内容类型、缓存策略等信息。

   • 处理压缩数据：若内容被压缩（如 gzip），先解压。

6、浏览器解析渲染页面

1. 解析 HTML：构建 DOM 树（文档对象模型）。

2. 资源加载：

   • 解析 HTML 中的资源引用（如 CSS、JS、图片）。

   • 并行请求这些资源（HTTP/1.1 通过多个 TCP 连接，HTTP/2 通过多路复用）。

3. 构建 CSSOM：解析 CSS 文件，构建 CSS 对象模型。

4. 合并渲染树：将 DOM 树和 CSSOM 合并为渲染树（只包含可见元素）。

5. 布局（Layout）：计算每个元素在屏幕上的位置和大小。

6. 绘制（Painting）：将渲染树转换为屏幕上的像素。

7. 合成（Compositing）：处理层叠和动画，优化渲染性能。

7、TCP 连接关闭（可选）

1. 四次挥手：

   • 客户端发送 FIN 包，表示请求关闭发送方向。

   • 服务器返回 ACK 包，确认关闭请求。

   • 服务器发送 FIN 包，表示请求关闭接收方向。

   • 客户端返回 ACK 包，确认关闭请求。

2. 连接复用：HTTP/1.1 默认使用持久连接（Connection: keep-alive），多个请求可复用同一个 TCP 连接；HTTP/2 进一步优化了连接复用效率。

概括总结如下：

1. DNS 解析：浏览器将域名（如www.example.com）转换为服务器 IP 地址（如 192.168.1.1）。
2. 建立连接：通过 TCP 三次握手与服务器建立连接（若为 HTTPS，还需额外完成 TLS 加密握手）。
3. 发送请求：浏览器向服务器发送 HTTP 请求（如获取首页内容）。
4. 服务器响应：服务器处理请求后，返回 HTTP 响应（包含网页 HTML、CSS、JS 等数据）。
5. 渲染页面：浏览器解析响应内容，构建 DOM 树和样式，最终渲染出可视化页面。
6. 关闭连接：完成后通过 TCP 四次挥手关闭连接（或复用连接处理后续请求）。

七、redis的缓存穿透、缓存击穿、缓存雪崩

1、什么是redis

        redis是一个单线程的支持网络、可基于内存也可持久化的日志型、K-V数据库，并提供多种语言的API。支持多种的数据类型：string hash 列表、集合等，支持事务读写速度非常快

2、缓存穿透

2.1描述：

        用户想要查询某个数据，在 Redis 中查询不到，即没有缓存命中，这时就会直接访问数据库进行查询。当请求量超出数据库最大承载量时，就会导致数据库崩溃。这种情况一般发生在非 正常 URL 访问，目的不是为了获取数据，而是进行恶意攻击。

2.2现象：

        1、应用服务器压力变大

        2、Redis缓存命中率降低

        3、一直查询数据库

2.3原因：

        一个不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果 从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查 询，失去了缓存的意义。

2.4解决方法：

        ① 对空值缓存：如果一个查询数据为空（不管数据是否存在），都对该空结果进行缓存，其 过期时间会设置非常短。

        ② 设置可以访问名单：使用bitmaps类型定义一个可以访问名单，名单id作为bitmaps的偏移量，每次访问时与bitmaps中的id进行比较，如果访问id不在bitmaps中，则进行拦截，不允 许访问。

        ③ 采用布隆过滤器：布隆过滤器可以判断元素是否存在集合中，他的优点是空间效率和查询 时间都比一般算法快，缺点是有一定的误识别率和删除困难。

        ④ 进行实时监控：当发现 Redis 缓存命中率急速下降时，迅速排查访问对象和访问数据，将其设置为黑名单。

3、缓存击穿

3.1描述

        key中对应数据存在，当key中对应的数据在缓存中过期，而此时又有大量请求访问该数据， 由于缓存中过期了，请求会直接访问数据库并回设到缓存中，高并发访问数据库会导致数据库崩溃。

3.2现象

        1、数据库访问压力瞬时增加

        2、Redis中没有出现大量 Key 过期

        3、Redis正常运行

        4、数据库崩溃

3.3原因：

        由于 Redis 中某个 Key 过期，而正好有大量访问使用这个 Key，此时缓存无法命中，因此就会直接访问数据层，导致数据库崩溃。 最常见的就是非常“热点”的数据访问。

3.4解决方法

        ① 预先设置热门数据：在redis高峰访问时期，提前设置热门数据到缓存中，或适当延长缓存 中key过期时间。

        ② 实时调整：实时监控哪些数据热门，实时调整key过期时间。

        ③ 对于热点key设置永不过期。

4、缓存雪崩

4.1描述

        key中对应数据存在，在某一时刻，缓存中大量key过期，而此时大量高并发请求访问，会直 接访问后端数据库，导致数据库崩溃。

4.2现象

数据库压力变大导致数据库和 Redis 服务崩溃

4.3原因

        短时间内大量的key过期，恰好大量的访问使用这些过期的key，此时缓存无法命中，导致大量的请求直接打到数据库中，导致宕机。

4.4解决方法

        ① 构建多级缓存机制：nginx缓存 + redis缓存 + 其他缓存。

        ② 设置过期标志更新缓存：记录缓存数据是否过期，如果过期会触发另外一个线程去在后台 更新实时key的缓存。

        ③ 将缓存可以时间分散：如在原有缓存时间基础上增加一个随机值，这个值可以在1-5分钟随 机，这样过期时间重复率就会降低，防止大量key同时过期。

        ④ 使用锁或队列机制：使用锁或队列保证不会有大量线程一次性对数据库进行读写，从而避 免大量并发请求访问数据库，该方法不适用于高并发情况。