奇安信Web服务端面试全解析：从HTTP到缓存、从SQL注入到系统设计

2019年春招我投了奇安信的Web服务端岗位。笔试刷掉了一批人面试又筛掉了一批人。我把当时遇到的题目和我的复盘整理了一遍包括一些参考答案和答题思路尤其适合想去安全公司做服务端开发的读者。这篇文章不会只贴题目和结论我会把每道题背后的考察点、我的答题方向、踩过的坑都写出来。奇安信毕竟是安全公司Web服务端试题的明显特点是看起来是常规的后端八股但几乎所有题目都能往安全方向延伸。比如问到数据库、问到缓存、问到HTTP最后都会落到“如果这个环节被攻击了怎么办”。所以这篇文章也会围绕这个思路展开不是单纯背答案而是理解为什么面试官会这么问。1. 笔试第一关基础技术题背后的安全思维1.1 HTTP 协议题目表面在问协议实际在问边界奇安信的笔试里HTTP相关的题目占了差不多三分之一。别以为只是让你背状态码它考察的是你对HTTP协议边界和防御能力的理解。我记得有几道比较典型的题目说说HTTP常见的状态码以及它们分别适合什么场景。GET和POST的本质区别是什么PUT和DELETE为什么是幂等的HTTP keep-alive的作用是什么在服务端如何配置和优化Cookie和Session有什么区别HttpOnly属性解决了什么问题这些题目单看都不难但想拿高分不能只背结论。以状态码为例除了“200成功、404找不到、500服务端错误”这种基础答案面试官更希望听到你主动提到401和403的区别、429限流、502和504的差异。我当时是这样回答的401是未认证客户端需要提供身份凭证403是已认证但无权限说明你已经登录了但被拒绝访问。在服务端设计里这两个状态码混用会导致很严重的安全问题比如攻击者可以通过返回码判断某个路径是否存在。429则经常用于限流保护后端不被刷爆。502是网关收到上游无效响应504是上游超时这两个状态码在高并发排查中特别常见。GET和POST的区别也有讲究。我面试时没有只答“GET参数在URL上POST在body里”而是补充了安全性层面GET请求会被浏览器历史记录、日志服务器记录所以敏感信息绝不能放在GET参数里POST也不是绝对安全需要配合HTTPS和请求体加密。幂等性则是设计接口时必须考虑的因为网络重试会导致重复提交PUT和DELETE设计成幂等是为了让客户端可以放心重发。keep-alive这个点我认为难度稍高。很多人知道它能复用TCP连接减少握手开销但服务端参数怎么调就答不上来了。Nginx里通过keepalive_timeout控制超时upstream配置keepalive 32表示保留空闲连接数。如果压测时发现大量TIME_WAIT往往也和连接复用没调好有关。提示面试官问HTTP不是为了考你“记没记住”而是想看你能不能把协议特性转化为服务端的设计决策。每一个协议细节背后都有性能和安全的考量。1.2 TCP与连接管理TIME_WAIT 为什么重要接着HTTP往下问自然就会到TCP。我遇到的题目包括三次握手、四次挥手、为什么需要TIME_WAIT、大量TIME_WAIT怎么处理。这里有个容易被忽略的知识点TIME_WAIT是主动关闭连接的一方进入的状态持续2MSL最大报文段生存时间目的是保证最后一个ACK能够到达对方同时让旧连接的报文在网络中消失避免污染新连接。在面试中如果你只是背出这个定义只能算合格。想拿高分要继续说高并发短连接场景下服务端主动关闭连接会产生大量TIME_WAIT占用本地端口和内存可能导致无法建立新连接。常见的解决办法包括调整net.ipv4.tcp_tw_reuse在客户端场景下安全服务端一般不建议、开启tcp_tw_recycle不推荐、或者从根本上减少短连接比如开启keep-alive、使用连接池。我没有直接给奇安信的面试官念参数因为有些参数需要谨慎使用随意开启反而会引发更隐蔽的问题。这恰恰是安全公司面试里最看重的一点你会不会为了解决问题而引入新的风险。比如tcp_tw_recycle在NAT环境下会导致连接异常这个坑很多人不知道。奇安信这类安全公司的服务端经常要处理大流量、防攻击。面试官还喜欢追问如果攻击者故意建立大量TCP连接但不发数据你的服务端怎么抵御这就涉及半连接队列、SYN Flood等概念要用SYN cookie、缩短超时时间、限制单IP连接数等方式缓解。我在复试环节就被问到了这个场景幸好当时结合了系统参数和Nginx配置聊了几种方案。2. 服务端并发模型从操作系统到编程语言2.1 进程、线程、协程的选择题Web服务端的笔试核心绕不开并发模型。奇安信出了好几道类似“多进程、多线程、协程有什么区别实际开发中如何选择”的题。这道题我说一下踩坑经验。最好的答法不是死记三种模型的概念而是结合IO密集型和CPU密集型来分析。多进程稳定性高进程间隔离一个进程挂了不影响其他进程但创建和切换成本高内存占用也高进程间通信复杂。多线程线程共享进程内存通信方便但需要处理同步问题比如死锁、竞态条件。频繁创建销毁线程开销也大所以要使用线程池。协程用户态调度切换代价极小可以高并发地处理IO密集任务比如网络请求、文件读写但单线程内CPU密集型任务的并行能力有限而且要注意别让协程里的阻塞操作拖垮整个调度循环。在安全公司的场景里进程和协程的选择还要考虑隔离性。处理不信任的输入比如解析上传文件、处理不可信数据包用多进程隔离会更安全因为即使某个处理模块崩溃或被攻击也不会拖垮整个服务。Go协程虽然便宜但出panic没恢复好可能导致整个进程崩掉。我建议在回答里加一个自己用过的例子。我当时提到在文件解析服务里用进程池处理不可信的样本主进程负责调度和健康检查效果比单进程多线程更稳。这样就把操作系统原理和真实业务结合起来了。2.2 epoll 与 Redis 单线程模型奇安信笔试有一类题考察Linux网络IO模型尤其是select、poll、epoll的区别。这家公司大量服务端都是高并发接入场景所以这个点几乎是必考。核心区别要讲清楚select有FD_SETSIZE限制默认1024每次调用都要把FD集合从用户态拷贝到内核态内核要遍历全部FD效率不高。poll去掉了1024限制但同样是水平触发、遍历方式没有数量限制但性能依然随FD数量增长而下降。epoll事件驱动只返回就绪的FD并且使用mmap共享内存减少拷贝支持水平触发LT和边缘触发ET两种模式。奇安信面试官大概率会追问ET模式下为什么必须用非阻塞IO因为在ET模式下事件只通知一次如果没把数据读完之后就不会再通知了所以必须循环读直到返回EAGAIN。非阻塞IO就是保证读不到数据时能及时返回而不是卡住线程。能把到这一层说明真的理解epoll而不只是背几个名词。Redis单线程模型也是必问的。很多人会问“Redis为什么单线程还这么快”我当时的回答是因为它用的是IO多路复用在单线程内处理大量客户端连接所有命令串行执行避免了锁竞争和上下文切换。同时Redis的value操作基本都是内存级别复杂度集中在O(1)或O(log N)。这里要说一个细节Redis 6.0引入了多线程IO但核心命令执行仍然是单线程面试时主动提这个能体现你对新版本的跟进。注意不要把“单线程”理解为只能用一个CPU核心。Redis的瓶颈往往在网络IO和内存不在CPU。单线程是“命令执行”层面的设计它是为了简单和避免锁竞争不是“不用多核”。3. 数据库与缓存性能优化的必考点3.1 索引失效场景与慢查询分析奇安信的笔试里数据库题考查得很实用。它不是让你写复杂的SQL而是问一个慢查询出现了你怎么排查和优化参考答案从这几步展开用EXPLAIN看执行计划关注type、key、rows、Extra字段。type达到ref或const才算比较理想如果出现ALL全表扫描就要考虑加索引了。这里要注意索引不是万能药很多场景加了也没用。典型索引失效场景包括对索引列使用函数或计算比如WHERE YEAR(create_time) 2022。隐式类型转换比如字符串字段传数字。LIKE以%开头最左前缀原则失效。OR条件中有一个字段没索引整个查询可能不走索引。排序和分组字段如果不在索引里可能产生filesort。我建议准备一个自己真实遇到过的问题。我当时说的是一个订单查询接口在数据量达到千万级后变慢后来发现查询条件是user_id和status的联合条件但只给user_id建了索引status过滤把很多行查出来再排序慢在排序上。后来建了(user_id, status, create_time)的联合索引直接把排序也覆盖了查询时间从2秒降到20毫秒。数据库安全这块奇安信也问了一题如果SQL查询条件里包含了用户输入的原始字符串你怎么保证安全这就是引出了预编译和参数化查询。这里要讲清楚为什么参数化能防SQL注入因为参数是作为值传入数据库不会把它当作一句独立的SQL去解析。我在面试里特意说了“不要自己拼SQL也不要用字符串替换过滤黑名单”因为黑名单永远有绕过可能。3.2 Redis 缓存三大经典问题缓存部分的题目也很典型缓存穿透、缓存击穿、缓存雪崩以及如何解决。我见过很多候选人把穿透和击穿搞混其实关键在于区别缓存穿透查询一个不存在的数据缓存里没有数据库里也没有请求直接打到数据库。攻击者可以利用不存在的ID大量刷请求把数据库拖垮。缓存击穿某个热点key过期大量请求瞬间打到数据库。比如微博热搜的某条数据突然失效。缓存雪崩大量key在同一时间过期或者Redis实例宕机导致数据库压力激增。解决方案要分开讲。穿透可以用布隆过滤器快速判断key是否存在或者把空值也缓存一段时间、设置较短的过期时间。击穿可以用互斥锁或者热点key设置逻辑过期时间。雪崩可以给key的过期时间加随机值避免同一时刻成批失效而且要做Redis高可用尽量做集群和主从切换防止单点故障。我记得当时面试官追问“互斥锁加在业务代码里如果获取锁失败怎么办”这个问题很实际一定要先想好策略。最简单的是直接返回“请稍后重试”也可以用双重检查锁没拿到锁的线程短暂sleep后重新查询缓存而不是盲目等锁。还有一个进阶做法是“逻辑过期”把热点key的过期时间放在value里异步去刷新缓存这样就不会阻塞请求线程了。安全公司会额外关注一种场景如果用户恶意构造大量不存在的ID来刷接口穿透问题会被放大。所以布隆过滤器在设计时要考虑误判率和内存占用。我当时回答里补了一句布隆过滤器只能判断“一定不存在”和“可能存在”如果误判率太高可以把大key拆分到多个过滤器或者用布谷鸟过滤器替代。4. 安全专项奇安信面试里绕不开的题目4.1 输入验证与路径遍历奇安信毕竟是做安全的四轮面试里几乎每一轮都会出现安全问题。最让我印象深刻的是“路径遍历”这道题。题目大概是这样服务端有一个下载文件的接口文件名从参数传入比如/download?filereport.pdf。如果攻击者传入../../etc/passwd服务端会不会把系统文件读出来这就是典型的路径遍历Path Traversal漏洞在热词里也被翻来覆去地搜说明很多开发者在实际做文件接口时都遇到过。要回答好这道题先要解释漏洞原理程序拼接文件路径时没有过滤../这样的特殊序列导致可以跳出预期目录。防御思路要分几层最稳妥的是用白名单文件路径通过配置文件或数据库映射而不是直接接收用户传入的原始路径。比如file_id1后端映射到本地的某个固定文件名。如果必须接收文件名要校验规范化后的路径。在Java里用Paths.get(baseDir, fileName).normalize()然后判断结果是否以baseDir开头。对文件名做过滤禁止/和\以及..等特殊字符但要注意不同平台对路径分隔符的解析差异黑名单不是唯一手段。尽量限制服务进程的权限运行Web服务的用户没有权限读取/etc/passwd即使被遍历了也读不到。我在回答时特意强调了“输入验证不能只做一次”。文件上传、下载、导入导出都会涉及路径拼接不能只在入口校验还要在真正访问文件系统前再次校验因为参数可能经过中间层被二次加工。奇安信的人很认可这种“纵深防御”的思路。4.2 SQL注入与XSS的防御SQL注入在笔试里出现了面试又换了个角度问你负责的登录接口被人用SQL注入打穿了你怎么排查和修复排查思路要说清楚先看日志里有没有报错信息SQL语法错误可能会把SQL语句打出来立刻能看到拼接痕迹。然后定位代码里的SQL拼接位置看是否有预编译。修复就是改用参数化查询同时调整数据库账号权限不给应用账号DBA权限。SQL注入这里有一个容易忽视的点MyBatis里如果写${}而不是#{}仍然会有注入风险。很多人以为用了MyBatis就安全了其实#{}是预编译${}是字符串替换而${}常用于动态表名、排序字段这类无法参数化的场景。如果必须用${}要做严格白名单校验。XSS也出现了。面试官问用户评论内容存在数据库里展示到页面上时如何防止XSS这个问题不要回答“过滤