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

字节跳动-后台开发岗面经

ops 2025/7/3 8:03:25

字节跳动一面

算法题：手写 LeetCode 146.LRU缓存
项目介绍，如何设计实现的？
场景题：字节的用户账号功能，量级很大（几十万几百万的请求量），注册的时候会写db，单用户每天可能编辑，通过uid去获取用户信息的接口，用缓存去提高访问速率，并且保证数据库和缓存的数据是一致的。参考：如何保障 MySQL 和 Redis 的数据一致性？- 缓存双删策略：先删除Redis，再写 MySQL，再删除 Redis
- kafka的写入是有序的，那么消费者的消费可以保证有序吗？
- 系统的容灾手段，异地容灾原理是什么？
MySQL的主从同步机制有哪些？异步复制、半同步复制、全同步复制 ???（这里我不确定是不是这个答案）
- MySQL主从的切换机制，主从同步原理，使用mysqlbinlog工具解析binlog，根据时间点去找同步位点position
TCP中的sync攻击原理，如何定位，如何解决？
- 危害：占满半连接队列；服务端每次重发时都要轮询比较未完成连接队列，占用服务端资源
- 定位：netstat -anp | grep SYN_RCVD，且大多数的服务端连接状态都是SYN_RCVD
- 解决：过滤网关防护、增加半连接队列大小及延长超时时间、黑名单（攻击量小）
TCP报文头结构，如何基于udp来实现tcp，就是udp需要加入哪些头部字段来实现tcp的功能？
- 需要以下字段：32位序号（序号重组）、32位确认序号（ack）、16位滑动窗口大小（流量控制）~~、6位标识位、16位紧急指针~~
- 补充：tcp在udp的基础上多了哪些机制：序号重组、超时重传、拥塞控制、流量控制

首先要知道tcp头部有哪些字段：

其次是udp头部有哪些字段：

16位源端口号和目的端口号：标识了发送方和接收方的进程标识；

32位序号：表示数据报文的编号。应用层要发送一段应用数据，当传送到传输层后，如果应用数据大小超过MSS（最大报文段长度）时，就会对应用层数据字节流从头到尾按顺序进行编号，然后再切分为一个个MSS大小的TCP报文段，每个报文段的序号字段就是该分段的第一个字节的序号
32位确认序号：表示希望对端发送的下一个报文段的序号。由于TCP是一种全双工的通讯协议，即发送方既发送数据也可能接收对端发送的数据，如源主机发送0-1000编号的字节段给目的主机，这时目的主机就会发送一个响应报文且确认序号为1001，表示希望收到下一个报文段编号为1001的数据，它和序号字段共同保证了TCP报文的可靠性；
4位首部长度：表示TCP报文首部的长度，该字段以4字节为单位。TCP首部的长度是可变的，在特殊情况下选项字段会有值，也计入首部长度，但一般情况下选项都会为空，这样首部长度就是20个字节，因此该字段的数值就为5，用4位二进制表示就是0101；
6位保留位：未用到，可能以后TCP版本升级会被征用；
6位标志位：其中SYN用于TCP连接的建立，FIN用于连接的关闭，RST是重新连接，ACK表示对发送方数据的确认，和确认序号结合使用；PSH标识⽴刻将数据交给上层处理；URG标识数据中需要被上层处理的紧急数据，而紧急数据部分是通过紧急指针字段来标识哪一段属于紧急数据；
16位滑动窗口大小：用于标识自己能接受的最大报文数，用于控制TCP连接的数据流量
16位校验和字段：用于接收端验证数据包的准确性，防止中途被篡改，这也是保证了TCP的可靠性

客户端上报到服务端的信息（比如mac地址）被黑客抓包拦截并绕过篡改，如何避免？
https加密原理及过程？https是如何防止中间人劫持的（如果服务端在向客户端下发CA证书时，被黑客替换成了自己恶意的CA证书，就形成了中间人攻击了）？

参考：HTTPS原理和防范中间人攻击
这里插一个我想了很久的但其实答案很简单的问题：既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。