1、说一下udp和tcp的区别，说一下tcp的三次握手，为什么不是两次握手？说一下tcp的四次挥手，为什么四次挥手要等待2MSL？
说一下udp和tcp的区别
从几个维度来对比
连接方式：tcp是一种面向连接的协议，在数据传输之前，TCP 必须先建立一个可靠的连接（通过三次握手过程），确保双方都准备好进行通信；udp是一种无连接的协议，在传输数据之前不需要建立连接，材料可以直接发送，适合应该快捷传输而不需要建立连接的场景
否收到，也不会重新发送丢失的数据包，数据的到达顺序也不能得到保证就是可靠性：tcp提供可靠的数据传输，确保数据包按顺序到达且不会丢失，它经过确认应答（ACK）、重传机制、流量控制和拥塞控制等机制来实现这一点；udp不提供可靠性保障，一旦数据包发送，udp不会确认接收方
速度与效率：由于tcp需要建立连接、管理状态、确认接收、重传丢失数据等，因此相对较慢，开销较大；udp因为没有连接建立和确认过程，udp的传输速度较快，开销小，适合实时应用（如语音通话、视频会议等）和大规模的素材广播（如在线游戏）
说一下tcp的三次握手
第一次是客户端向服务器发起连接请求，第二次是服务器确认客户端的连接请求，并响应告知客户端“我已准备好”，第三次是客户端收到响应后向服务器发送确认连接报文，连接正式建立
第一次握手（SYN）：客户端发送SYN包（SYN=1，seq=x）到服务器，进入SYN_SENT状态
第二次握手（SYN-ACK）：服务器收到SYN包后，返回SYN+ACK包（SYN=1，ACK=1，seq=y，ack=x+1），进入SYN_RCVD状态
第三次握手（ACK）：客户端收到SYN-ACK包后，发送ACK包（ACK=1，seq=x+1，ack=y+1），双方进入ESTABLISHED状态，连接建立
为什么不是两次握手？
如果只有两次握手，服务器无法确认客户端是否收到自己可以连接的响应，可能导致半连接状态（服务器等待无用请求，浪费资源）
说一下tcp的四次挥手
TCP是全双工协议，双方需独立关闭自己的发送通道
客户端发送报文到服务器，表示不再发送数据，但可接收数据，客户端进入等待状态1
服务器收到报文后可能得处理剩余素材，向客户端发送确认收到报文，客户端收到确认报文后进入等待状态2，等待服务器的关闭请求
服务器向客户端发送报文表示剩余数据处理结束，正式发起关闭请求
客户端收接到请求后，发送确认报文给服务器，服务器收到确认报文后立即关闭连接，客户端在2MSL结束后关闭连接
为什么四次挥手要等待2MSL？
确保末了一个ACK到达：如果确认报文丢失，被动关闭方会重发关闭请求报文，2MSL时间足够处理此类重传
消除旧连接的数据包：等待2MSL（默认60秒）确保网络中残留旧连接数据包失效，避免和新连接混淆
补充：MSL定义（Maximum Segment Lifetime），报文最大生存时间，（通常30秒~2分钟），报文往返时间
2、说一下数据库的三范式和反三范式
三范式
三范式是数据库设计的核心原则，目的是方便维护、减少数据冗余和保证数据一致性
第一范式（1NF）要求表的每一列都是原子性的，不可再分，比如，地址字段不应该含有省、市、街道等多个信息，而应该拆分成多个字段
通过第二范式（2NF）是在1NF基础上，每个非主键字段必须完全依赖主键，而不是部分依赖，例如，学生和课程的关系是多对多，所以会有一个中间表选课表，一个学生可能选多门课，一门课能够被多个学生选，但是一个学生选某一门课只能选一次，比如表中有学生id、学生名称、课程id和课程名称，由学生id和课程id共同确定了某一个学生选某一门课的唯一关系，但是其实课程名称只和课程id有关系，而学生名称只和学生id有关系，并不和课程id有关系，这种情况就不符合第二范式，第二范式常用于多对多关联表的场景来约束
第三范式（3NF）是在2NF基础上，所有非主键字段必须直接依赖于主键，而不能依赖于其他非主键字段，这意味着不存在传递依赖，比如学生表，有学生id、学生姓名、学院id和学院名称，这个表中主键是学生id，但是这个学院名称应该要依赖学院id的，所以不符合第三方范式
反三范式
反三范式就是凭借引入冗余数据或合并表结构等手段，优化查询性能，但是不易于维护和保证数据一致性
怎么处理的？就是3、你有没有在工作过程中和同事有分歧或者冲突的时候？有的话举一个例子？当时
你有没有在工作过程中和同事有分歧或者冲突的时候？
技术上的就是冲突倒谈不上，在这些年的工作中，分歧肯定是有过的，这也是正常的嘛，一般是业务上或者
有的话举一个例子？当时是怎么处理的？
比如在工作中多个人负责同一个需求，在需求的理解或者设计方面有不同看法，这时候最初我们会认真倾听对方的方案，尝试把两者的方案的优点都糅合到一块，如果实在遇到双方没办法协调的，我们会找有经验的同事或者上级来协调解决，主要还是借助沟通应对