【QT面试题】（二）

文章目录

• SQL流入原理，如何避免SQL注入
• MySQL死锁问题产生的原因以及如何解决
• TCP三次握手的过程为啥不能两次握手
• TCP四次挥手
• 什么是连接的半打开，半关闭状态？
• TCP是如何保证可靠性的

SQL流入原理，如何避免SQL注入

1.什么是SQL注入

用户在提交查询请求时，将恶意的SQL语句作为参数嵌入到原来的SQL语句当中，修改了原SQL语句的意图，达到逃过授权直接非法操作数据的目的。

例子：用户登录

select * from `login_t` where `name` = `用户名`and `password` =`用户密码`;

输入

` or 1=1 --空格

逻辑绕过: OR 1=1 使WHERE条件恒为真
注释使用: – 注释掉后续密码验证部分

2.SQL执行过程

(1)语法句法分析生成语法树
(2)优化SQL语句
(3)制定执行计划
(4)开始执行

3.如何避免SQL注入

(1)预编译：

select * from `login_t` where `name` = ? and `password` =?

提前对SQL语句进行词法句法分析、生成语法树、优化并制定执行计划，结果缓存在预编译缓存中。后续执行时，注入的恶意SQL会被视为普通字符串参数，不再经过编译过程。
(2)字符串正则表达式匹配
对输入参数进行正则表达式检查，检测SQL关键字（如or、–、#等）和特殊符号（单引号、分号等）若发现可疑内容直接拦截并报错
典型检测项：
SQL注释符号：--、#
逻辑运算符：or、and、=
特殊字符：单引号'、分号;
(3)函数过滤转义
使恶意输入成为普通字符串数据，使其失去SQL语法意义，无法改变SQL语句结构

MySQL死锁问题产生的原因以及如何解决

1.什么是死锁

定义: 两个或两个以上的并发事务在执行过程中，因争夺锁资源而造成相互等待的现象。
现象表现:
事务会一直阻塞，造成资源浪费
程序可能长时间等待资源但得不到反馈
异常报错: 当发生死锁时会出现"deadlock found when trying to get lock"的错误提示

2.锁有哪些

(1)查询操作加锁:
①自动加锁: 可串行化隔离级别自动加S锁(共享锁)
②手动加锁:
S锁: lock in share mode
X锁: for update
③特殊场景: 可重复读隔离级别下，范围查询或未命中时会加gap锁(间隙锁)避免幻读
（2）删除/更新操作加锁
①自动加X锁(排它锁)
②可重复读隔离级别下，范围操作或未命中时会加gap锁
（3）插入操作加锁:
①自增列: 使用auto-inc锁(特殊表锁，插入后立即释放)
②非自增列: 先加insert intention lock(插入意向锁)，再加X锁

3.哪些锁会冲突？

(1)S锁和X锁互相冲突
(2)已有gap锁时尝试加插入意向锁会发生锁等待

4.锁什么时候释放

操作时加锁，事务结束时释放(除auto-inc锁外)

5.死锁的产生原因

(1)相反顺序加锁：
①不同表的加锁顺序相反；
②相同表不同行枷锁顺序相反；
③给辅助索引行加锁时给聚集索引行加锁，造成加锁顺序相反；
④给具有外键索引加锁时，给父表加锁，隐含给子表也会加锁；
⑤触发器（表操作触发的联动操作也会加锁）
(2)锁冲突死锁
一个事务已经加了gap锁，另一个事务禅师获取插入意向锁，造成死锁。

6.死锁解决

(1)对于相反顺序加锁的情况，修改sql语句，调整执行顺序
(2)对于锁冲突类型，更换语句或降低隔离级别。

7.如何避免死锁

(1)尽可能以相同顺序来访问索引记录或表
(2)当幻读和不可重复读对应用影响不大时，将隔离级别降为读已提交
(3)添加合理的索引,不走索引会导致全表扫描，为每行记录加锁,死锁概率非常大
(4)尽量在一个事务中锁定所需资源,减少事务执行过程中逐步加锁导致的死锁概率
(5)尽量避免大事务,大事务占用更多资源,执行耗时较长,死锁概率更高。将大事务拆分为多个小事务
(6)避免同一时间点运行多个对同一表进行读写的概率

TCP三次握手的过程为啥不能两次握手

1.背景知识

(1)建立连接需要进行三次握手
(2)TCP是全双工的、面向连接的、可靠的、基于字节流的传输层协议

全双工特性: 一条连接有读端和写端，可以同时进行读写操作。
面向连接: 同一个五元组（源IP、源端口、目的IP、目的端口、协议类型）只允许建立一条连接。
可靠性机制:通过序列号实现数据包按序收发，丢失时进行重传，重复数据包进行去重

(3) 实现网络状态比较复杂，发送方可能连续发送多次建立连接的请求。
(4)发送方通过对端回应的seq值快速判断是否为历史请求。若为历史请求，则发送重置包(RST)告知服务端不要建立连接
(5)通过序列号实现数据包按序收发、丢失重传。

2.三次握手的流程

流程图

第一次握手:
客户端发送SYN=1, seq=x（x为随机生成的唯一值）
客户端状态从CLOSED变为SYN_SENT
第二次握手:
服务端回应SYN=1, ACK=1, seq=y, ack=x+1（y为服务端随机值）
服务端状态从LISTEN变为SYN_RECEIVED
第三次握手:
客户端发送ACK=1, seq=x+1, ack=y+1
双方状态都变为ESTABLISHED，开始数据传输

3.三次握手的作用

连接确认: 确保双方都有发送和接收能力
序列号同步: 交换初始序列号，为后续数据传输建立基准
资源准备: 服务端在收到第三次ACK后才创建连接资源,避免造成资源浪费。防止因网络延迟导致同一个五元组建立多条连接，确保连接唯一性。
防止历史连接: 通过序列号机制避免处理旧的连接请求，当收到历史连接的SYN包时，可以通过比对序列号判断其时效性。

4.为什么不能只进行两次握手

(1)无法避免重复连接导致资源浪费;
(2)无法同步双端起始序列号，从而无法保证可靠传输

TCP四次挥手

1.四次挥手的过程。

(1)客户端发送FIN给服务端。服务端收到FIN包，自动回复ACK包，进入CLOSE_WAIT状态。
(2)在服务端中，TCP协议栈会为FIN包插入一个文件结束符EOF到内核态网络读缓冲区。应用程序通过read=0来感知这个FIN包。
(3)若此时应用程序有数据要发送，则发送完数据后，发送FIN包到对面，调用关闭连接操作。
(4)服务端收到FIN包后会发送ACK包给客户端
(5)双端关闭都需要一个FIN和一个ACK流程
原理图

2.为什么要四次挥手？

(1)网络应用程序可能还有数据要发送，所以不能直接发送FIN包。
(2)将发送FIN包的控制权限交由网络应用程序去处理。
(3)不是只能通过调用close或shutdown来发送FIN包。程序退出时，内核网络协议栈都会发送FIN包，确保完成四次挥手流程。

3.四次挥手过程中，数据包丢失会发生什么？

(1)第一次FIN包丢失：触发超时重传，客户端会多次超时重试发送FIN包。超过重试次数后由FIN_WAIT_1直接转入CLOSED状态。
(2)第二次ACK包丢失：ACK包不会超时重传，客户端会认为服务端未收到FIN包，会多次重试发送FIN包，最终进入CLOSED状态。而服务端长期处于CLOSE_WAIT状态后最终也会进入CLOSED。
(3)第三次FIN包丢失：服务端会多次重试发送FIN包。服务端长期处于LAST_ACK状态，客户端处于FIN_WAIT_2状态。重试失败后双方都会进入CLOSED状态
(4)第四次ACK包丢失：不会触发重传。客户端处理经过2MSL时间后直接进入CLOSED状态。服务端处理未收到ACK会重传FIN包，最终也会进入CLOSED状态。

什么是连接的半打开，半关闭状态？

1.什么是半打开状态

定义：服务端发送SYN+ACK后，等待客户端ACK时的中间状态
存储机制：存储在通过哈希表实现的半连接队列（SYN队列）

2.全连接状态

(1)全连接定义：当服务端收到客户端的ACK包后，连接建立成功。
(2)先将该连接在半连接中移除，再把该连接加入到全连接队列(accept队列)中。

3.SYN攻击防护

(1)攻击方式：客户端发送SYN后故意不回复ACK
(2)攻击类型：SYN泛洪、SYN攻击、DDos攻击
(3)危害：占用半连接队列资源，导致正常连接无法建立

4.SYN包丢弃条件

(1)队列满：SYN队列满且未开启syncookies
(2)重传过多：全连接队列满且SYN+ACK重传请求>1
(3)阈值限制：半连接队列长度>3/4 tcp_max_syn_backlog

内核参数：
tcp_max_syn_backlog：控制半连接队列最大长度
syncookies：替代方案，不依赖队列存储连接信息

5.syncookies原理

(1)作用：绕过SYN队列直接建立连接，用于解决SYN队列满导致的连接丢弃问题
(2)工作流程：服务端收到SYN包后不存入半连接队列，而是生成并返回SYN cookies。客户端需回复包含cookies的ACK包。服务端验证cookies有效性后直接加入全连接队列
(3)代价说明：虽然能有效防御SYN攻击，但会消耗较多系统资源，应作为最后手段使用

6.如何防御SYN攻击

(1)增大半连接队列：修改tcp_max_syn_backlog参数（默认256）同时调整somaxconn和listen()的backlog参数（默认128）
(2)减少SYN+ACK重传次数：设置/proc/sys/net/ipv4/tcp_synack_retries=1
将重传次数从默认5次降为1次
(3)开启tcp_syncookies：开启/proc/sys/net/ipv4/tcp_syncookies=1

7.半关闭状态

定义：服务端收到FIN包后处于CLOSE_WAIT状态时，仍可向客户端发送数据
特性：（1）读缓冲区附加EOF标记；（2）仍可向客户端发送数据（CLOSE_WAIT状态）；（3）FIN包控制权交由应用层处理

8.FIN包发送方式

(1)close方式：
特点：同时关闭读写端口，清空读写缓冲区
风险：服务端在CLOSE_WAIT状态下发送数据,客户端将回复RST包
后果：导致连接立即终止，跳过正常四次挥手流程
(2)shutdown方式：
shutdown(fd, SHUT_WR)：仅关闭写端，仍可接收数据并回复ACK
优势：实现优雅关闭，服务端发送数据时客户端回复ACK

TCP是如何保证可靠性的

1.TCP的背景知识

TCP全称: Transmission Control Protocol，传输控制协议。
特点:
(1)全双工: 允许双方同时发送和接收数据。
(2)面向连接: 在数据传输前需要建立连接，数据传输完成后释放连接。
(3)基于字节流: 数据以字节流的形式传输，不限制数据块的大小。

2.TCP保证可靠性的机制

(1)确认与重传: 接收方收到数据后发送确认报文ACK，发送方在一定时间内未收到确认报文，就认为数据可能丢失，于是重传该数据报文。
(2)滑动窗口: 发送方和接收方各自维护一个窗口，窗口大小表示允许发送或接收的最大数据量。通过滑动窗口机制控制发送和接收的数据量，避免网络拥塞和接收方处理不过来。
(3)拥塞控制: 当网络出现拥塞时，TCP会降低发送速率， 避免网络拥塞导致的数据丢失和传输延迟增加。
(4)数据校验: 发送方在发送数据前计算数据的校验和，并将其附加在数据报文后。接收方收到数据后验证校验和是否正确。如果校验和错误，则要求发送方重传数据。

2.TCP分段

定义: 数据包经过socket后，会进入TCP层，并添加一个TCP头。在TCP层，会有一个mss（Maximum Segment Size，最大报文段长度）来对最小包进行确认。如果用户发送了一个很大的包，TCP层会将其分段成多个mss大小的数据小包。
作用: TCP分段能够控制发送数据的大小，确保数据以合适的大小进行传输。

3.序列号

作用：确认完整接收：TCP头中的序列号可以确保数据的完整接收。发送端发送数据包时，接收端会回复一个ACK，通过序列号来确认哪些数据包已经被接收。
排序与避免重复：在TCP分段传输中，每个分段都会被加上一个序列号。如果接收端无序接收数据，可以通过序列号对数据进行排序，确保按序接收，并避免重复数据的出现。

4.校验和

定义: 检验和是用于检测报文在传输过程中数据是否发生变化的一种技术。
作用: 如果数据在传输过程中发生改变，通过检验和可以检测到这种变化，并可能会进行报错或丢失处理，以确保数据的准确性。

5.滑动窗口机制

解决无需为每个数据包应答，否则吞吐量太低
窗口概念：在没有应答的情况下，发送方可以发送的数据量。
滑动的含义: 当发送方收到确认包后，会根据确认的信息将窗口向前滑动，即允许发送更多的数据。
发送滑动窗口的大小约等于接收滑动窗口的大小
接收方通过TCP头部字段中的“窗口”来告知发送方其接收缓冲区还剩多少空间。

6.流量控制

通过接收方的处理能力来限制发送方发送的数据量。避免数据丢包，确保数据传输的稳定性和可靠性。
接收方处理能力:如果接收方的滑动窗口变小，发送方的可用窗口也会相应减小，导致发送方发送数据量减少。 当接收方的滑动窗口降为零时，发送方不能发送数据，只能发送窗口探测包来探测接收方窗口的变化。
怎么控制：当发送方可用窗口变为零时，不断发送窗口探测报文。一段时间后，如果接收方窗口仍然很小，发送方会收缩接收方的窗口，并减小缓冲区的大小，以此来进行流量控制。

7.拥塞控制

背景: 网络发生拥塞时，继续发送大量数据包可能导致数据包延时及丢失，进而造成更多重传，陷入死循环
判断依据: 主要通过是否触发重传
拥塞窗口: 描述网络的拥塞程度，是一个动态变化的过程。
发送方窗口=min(拥塞窗口,接收方窗口)

8.怎么控制拥塞窗口的大小

慢启动: 初始窗口为1，每收到一个ack，拥塞窗口加1。慢启动使拥塞窗口呈指数增加，直至达到慢启动门限（通常为65535字节）。
拥塞避免: 超过慢启动门限后，拥塞窗口呈线性增加。
拥塞发生时，①超时重传处理: 发生超时重传时，拥塞窗口重置为1，慢启动门限减半，然后重新开始慢启动过程。②快速重传：说明只丢了一小部分数据，网络拥塞不严重。拥塞窗口和门限均减半，并进入快速恢复状态。
快速恢复: 快速恢复是快速重传造成拥塞后采用的策略。如果收到3个重复的ack（D-SACK），直接进入拥塞避免

9. 确认应答机制

基本流程：接收方对每个成功接收的数据包发送ACK确认
累积确认：可通过单个ACK确认多个连续接收的数据包
双向通信：全双工特性使得双方可以同时发送数据和ACK

10.重传机制

用来解决数据丢失的问题，通过序列号和确认应答机制来实现
(1)超时重传 ：启动定时器，在指定时间内如果没有收到数据包，则进行重传。
(2)快速重传：在超时重传时间到来之前，通过收到的部分确认包判断数据丢失，并立即重传丢失的数据。
(3)SACK：接收方将已收到的数据告知发送方，发送方只需传输重传丢失的那部分数据。
(4)D-SACK ：接收方把重复接收的包通过SACK选项告知发送方，发送方据此判断①数据包是否丢失、②ACK是否未收到、③是否因网络时延导致ACK很晚才发送。