当前位置：首页 > news >正文

计算机网络知识等汇总补充

news 文章来源：https://blog.csdn.net/YZL40514131/article/details/137657566 2025/4/21 8:27:37

在这里插入图片描述

计算机网络知识汇总补充

一、四次挥手
- 1、为什么TCP要等待2MSL
- 2、如果说一个系统中，有大量的time_wait和close_wait，会是什么原因？
二、你是怎么解决粘包问题？
三、你觉得哪些场景适合redis
四、redis的持久化策略
五、你会怎么保证mysql 和Redis的一致性
六、事务隔离级别和MVCC控制的理解？
七、对称加密非对称加密
八、堆和栈的不同
九、如果A服务调B服务出现失败：下游服务调用失败，或者无法响应请求了，怎么优化
十、redo log,bin log, undo log

一、四次挥手

在这里插入图片描述

1、刚开始客户端和服务端都处于连接状态，假如客户端发起关闭请求
2、第一次挥手：客户端向服务器发送FIN报文，发完进入FIN_WAIT_1状态，即主动关闭TCP连接，不再发送数据，但是可以接收服务器发来的报文，等待服务器回复。；
3、第二次挥手：服务器接到FIN报文，返回一个ACK报文，表名自己接收到此报文，服务器进入CLOSE_WAIT等待关闭状态，此时客户端就知道服务端接收到自己的断开连接的请求，进入FIN_WAIT_2状态，TCP处于半关闭状态，但是服务器可能还有数据要传输。
4、第三次挥手：服务器关闭客户端连接，发送FIN报文给客户端数据传输完毕，等待客户端回应。
5、第四次握手：客户端收到FIN报文后，发送一个ACK给服务端做为应答，此时客户端处于TIME_WAIT状态，这个状态是为了等待足够的时间以确保TCP接收到连接中断请求的确认。

1、为什么TCP要等待2MSL

注意：这时服务器到客户端的TCP连接并未被释放，客户端需要经过等待2MSL（MSL表示一个报文的来回时间）后才会进入CLOSED状态，这样做的目的是确保服务器收到自己的ACK报文，如果在规定时间没有收到客户端发的ACK，那么服务器会重发FIN，客户端再次收到FIN报文，就知道自己的ACK丢了，然后会重发ACK给服务器。服务器收到ACK后，就会关闭连接，处于CLOSE状态了。

2、如果说一个系统中，有大量的time_wait和close_wait，会是什么原因？

未正确关闭连接
处理连接过程中出错
网络延迟或故障

二、你是怎么解决粘包问题？

1、粘包定义：粘包指的是数据和数据之间没有明确的分界线导致不能正确读取数据。
2、这意味着UDP根本不会粘包，但是会丢数据，不可靠。意味着: TCP传输数据是可靠的，但是会粘包。
所谓粘包问题主要还是因为:
1、接收方不知道消息之间的界限，不知道一个消息要提取多少字节的数据所造成的。 (服务器端出现黏包)
2、tcp在发送数据少且间隔时间短的数据时，会将几条和并一起发送。(客户端出现黏包)
3、黏包的解决办法：
为字节流加上一个报头,告诉发送的字节流总大小，然后接收端来一个死循环接收完所有数据。用struck将序列化后的数据长度打包成4个字节(4个字节完全够用)。
客户端把数据长度封装成一个固定大小的数据，这时服务端就可以指定读取固定大小的内容,不会读取数据的内容，服务端只要根据数据长度再来接收数据内容就好了，所以客户端连续两次发数据(文件) , 不会粘包,因为服务器端每次接收都只接收了本次该接收的数据。

4.你使用TCP的时候会出现，那么UDP会出现吗
- 不会出现

三、你觉得哪些场景适合redis

String（字符串）：缓存、计数器限流
Hash（哈希）：存储对象数据、统计类数据
List（列表）：文章列表
Set（无序集合）：标签、点赞、签单
Zset（有序集合）：排行榜

redis你使用的场景
string异步执行任务，消息队列

四、redis的持久化策略

RDB持久化：RDB持久化会在指定的时间间隔内生成一个快照文件（Snapshot），将数据集的内容写入一个压缩的二进制文件中。RDB持久化方式适合数据集较大，但不要求数据丢失太多的场景。可以通过配置文件设置快照生成的条件和时间间隔。
AOF持久化：AOF持久化是以日志的方式记录每个写操作的命令，在Redis重启时重新执行这些命令来恢复数据。AOF持久化方式保证了每个写操作的数据一致性和持久性，但相比RDB会更占用磁盘空间和对性能有一定影响。

五、你会怎么保证mysql 和Redis的一致性

淘汰缓存：在更新 MySQL 数据后，异步地更新 Redis 中的数据。这种方式可以降低对数据库写入性能的影响，但可能会导致短暂的数据不一致。
更新缓冲：在系统中同时写入 MySQL 和 Redis，确保两者的数据保持一致。这种方式可以保证每次写入操作都同时更新 MySQL 和 Redis，但会增加系统的写入负载。
消息队列：使用消息队列来实现 MySQL 和 Redis 数据的同步。在数据库更新后发送消息到队列，消费者将消息同步到 Redis 中，确保数据的一致性。
监控和报警：实时监控 MySQL 和 Redis 的数据一致性，一旦发现数据不一致情况，及时进行报警并修复。

六、事务隔离级别和MVCC控制的理解？

用于处理并发事务的一致性和隔离性
MVCC是一种并发控制机制，常用于数据库管理系统中，用于解决并发访问数据库时的数据一致性问题。MVCC通过在每个数据项上维护多个版本来实现并发控制。
- MVCC的核心思想是在读操作和写操作之间创建一个快照，使得读操作不会被写操作所阻塞，从而提高并发性能。具体实现方式如下：
1. 版本号：每个数据项都会有一个版本号，用于标识该数据项的版本。当一个事务开始时，它会获得一个全局的事务ID，并将该ID作为版本号。
2. 读操作：当一个事务执行读操作时，它会读取最新的符合条件的版本。如果存在比当前事务ID更大的版本号，则说明该数据项已被其他事务修改，当前事务需要等待。
3. 写操作：当一个事务执行写操作时，它会创建一个新的版本，并将新版本的数据写入数据库。同时，该事务会更新所有已读取该数据项的事务的版本号，使得它们无法再读取旧版本。
4. 回滚：如果一个事务执行过程中发生了错误或者被取消，它可以通过回滚操作将数据库恢复到事务开始之前的状态。回滚操作会撤销该事务对数据库的所有修改。
- MVCC的优点是提高了并发性能和并发控制的粒度，减少了锁的使用，从而减少了事务之间的冲突。但也存在一些缺点，如增加了存储空间的开销和读操作的复杂性。

七、对称加密非对称加密

对称加密

对称加密使用相同的密钥（称为私钥）来加密和解密数据。
加密和解密过程使用同一个密钥，因此对称加密算法在加密和解密速度上通常比较快。
常见的对称加密算法包括AES（高级加密标准）等。

非对称加密

非对称加密使用一对密钥（公钥和私钥）来加密和解密数据。
公钥用于加密数据，私钥用于解密数据，这两个密钥是相关联的，但不相同。
非对称加密算法能够实现数据的安全传输和身份认证，但由于涉及复杂的数学运算，其加密和解密速度较慢。
常见的非对称加密算法包括 RSA等。

八、堆和栈的不同

九、如果A服务调B服务出现失败：下游服务调用失败，或者无法响应请求了，怎么优化

实现重试机制：
- 在A服务发现调用B服务失败时，可以实现简单的重试机制，尝试重新调用B服务一定次数，以确保请求能够成功响应。
- 重试机制可以设置一定的重试间隔和次数，避免过多的请求导致负担增加。
实现服务降级：
- 当B服务无法响应或出现异常时，A服务可以实现服务降级策略，返回默认值或者缓存数据，保证用户体验。
- 服务降级可以在一定程度上减少对下游服务的依赖，提高系统的可用性。
设置超时时间：
- 为A服务调用B服务设置合理的超时时间，以避免长时间等待响应导致的性能问题。
- 当超过设定的超时时间后，可以及时进行异常处理或重试操作。

十、redo log,bin log, undo log

binlog：主节点 binlog，主从复制的基础是主库记录数据库的所有变更记录到 binlog。binlog是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
undo log记录事务提交前的状态，更新前的值，用于事务回滚；
redo log记录事务提交后的状态，更新后的值，用于数据恢复，持久化