面试问题

  • 有没有实际上有用户使用这个 vpn，插件是不是只是把客户端上报的数据存储起来？是线上的业务嘛？
    • 第一版，确实有用户在使用；
    • 插件 不只是一个只做客户端上报存储的插件，而是一个和 客户端 进行通信的 服务端控制组件；
    • 插件至少做了三类实质工作：
      • 在 OpenVPN 的 TLS_VERIFY 阶段调用平台的 CertStatus 做证书状态校验；
      • 拉取 UserAccessRules，再用 nftables 下发用户级访问控制；
      • 通过 UserConnection 上报连接状态，并通过 PluginMsgPipe 接收动态规则更新；
      • 拥有 流量解析 和 Kafka 投递能力，这已经不是单纯埋点了；
  • grpc 同步和异步通信框架怎么去实现的？原来是什么样的？提升了什么性能？
    • 同步 RPC 主要用在必须马上拿结果的链路上，这些请求如果不马上返回，后续流程就走不下去；
    • 异步 RPC 主要用在不应该阻塞 OpenVPN 主线程的地方，比如 用户访问规则拉取 和 连接状态上报。
    • 双向流主要用在 长生命周期 控制通道上；
      • 托管节点和平台之间是 MsgPipe；
      • 插件和平台之间是 PluginMsgPipe；
      • 这两条都是流式长连接，用来接收 服务端推送 和 在线控制。
  • 客户端和后台是通过什么方式连接的？长连接还是短连接？通过域名嘛？
    • 这套系统有两类连接：控制面连接 和 数据面连接
      • 控制面连接
        • SDK、托管节点、插件到管理平台之间走的是 gRPC over TLS/mTLS。
          • 其中 SDK 到平台主要是短 RPC，用来登录和取配置；
          • 托管节点 和 插件 到 管理平台 则分别有 MsgPipe 和 PluginMsgPipe，属于 流式长连接。
      • 数据面连接
        • 真正的 VPN 接入是 SDK 内部的 OpenVPN3 客户端和托管节点上的 OpenVPN 服务端之间建立的隧道，这本身就是 长连接。
  • 客户端直接通过配置保存服务端的 ip:port， 后台的 ip:port 变更了，这种场景下有做策略嘛？如果去优化，有没有想过就算是服务器的 ip:port 迁移了，客户端仍然可以去连接上服务器？
    • 这个要分两部分看：
      • VPN 服务端地址：
        • 这部分不是固化在客户端里，而是 SDK 登录成功后，通过 RequireConfig 从平台动态拿 server[]，再转成 OpenVPN 的多个 remote。
        • VPN 接入点变更后，客户端下次重新登录拉配置，就能拿到最新地址；如果平台一次下发多个 server，也可以作为候选地址。
      • 管理平台地址
        • 这个在 SDK 侧更像是启动配置项，所以如果管理平台自己的 ip:port 迁移，现状上更依赖配置更新，或者依赖域名解析层兜底。
  • 实时抓包解析和 kafka 日志投递，有没有想过为什么要用 kafka？有没有想过为什么不直接投递到日志平台？
    • 面试官说害怕 Producer 扛不住，所以它把所有的日志都暂存在 kafka，使得 Producer 可以保持自己正常的负载，正常的运行。
  • 介绍一下 N : M 线程模型框架？
  • 协程阻塞后，让出协程，怎么保证阻塞协程的状态的？
  • 有没有压测过？并发量大概能到达多少？线程拿的到协程在执行什么任务？有没有关注过你这个 QPS 在什么规模的机器下跑的？有没有看过真正访问网页的成功率？有没有具体的数字？本机压测的嘛？发家机和测试机都在同一个 虚拟机 嘛？没有网络层面耗时的验证？
    • 面试官说这个很重要，因为 QPS 高，但是成功率不高，没什么用。
  • N : M 线程模型有没有性能的瓶颈？
  • 有没有用过 AI 相关的工具？
  • 你说在你这个协程服务器上面做 AI 相关的工具，现在只是讨论，你想会如何去做？想提什么东西？
  • 算法
    • leetcode_295：数据流的中位数
    • leetcode_138：随机链表的复制
  • 要求用 AI 来降低随机链表的复制的 空间复杂度 O(n) 为 O(1)