腾讯云后台一面（3.24） --凉

2025年03月28日 1.3k 字大概 5 分钟

CS基础还是不够扎实啊，再去练练吧

八股

Hashmap
top k问题
- 随机选择算法：每次选处理段的一位O（n）划分大于/小于它，单词递归，期望复杂度O(n)+O(n/2)+O(n/4)+…+O(1)≈O(n)
TCP四次挥手，二次挥手和三次挥手中间在干嘛，处理什么
多个http请求过来，还是一个tcp连接吗
1. HTTP1.1：默认使用长连接（客户端可以建立tcp连接池来利用tcp长连接的特性）
  1. 单个TCP连接在同一时刻只能处理一个http请求，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。
    - 在应用层方面存在队头阻塞问题：同一tcp下的http请求，队头阻塞，后面请求都需要等待
    - 流水线（Pipelining）优化（默认不启用，实现复杂且效果不佳）：在同一条长连接上发出连续的请求，无需等待响应。服务器需要按接收顺序依次处理请求，响应也必须按顺序返回。
    - http1.1基于文本分割来解析，在遇到分隔符前不能停止解析，不适合划分成基本单位来实现多路复用
  2. 性能优化策略
    - 通常采用连接复用（长连接）和同时建立多个TCP连接的方式提升性能。但浏览器对其访问的host域名可建立的TCP连接数有限制（6~8个）
    - http的长连接长时间空闲一般会断开（长时间空闲浪费服务器资源）
    - 域名分片(加速图片等大资源的获取速度)：通过将内容拆分到多个子域来提高网页加载速度的技术，突破浏览器对同一域名host可以使用的tcp限制（从多个子域名获取资源，而这些子域名其实都指向同一台目标服务器，这样能并发使用更多tcp连接）
http2.0及以上版本多了什么功能
1. HTTP2：基于https上实现。基于二进制帧（紧凑的二进制结构）来传输数据，不再是明文传输
  1. 基本概念
    - 帧(frame)：最小的数据单位，帧包含数据长度、流标识符、帧类型等信息。http请求报文被拆散成帧
    - 消息(message)：即http报文（一个请求/响应），消息由帧组成（由头部帧和数据帧组成）
    - 流(stream)：一次完整的请求-响应由对应的流id标识，即流是双向的(含有一对请求消息+响应消息)
      - 流id严格递增，不可复用，具有唯一性，其流id对应了一次请求-响应
      - 一般规定客户端发起的流id奇数，服务端发起的流id偶数，避免冲突
      - 同一个流发送的帧要有顺序，接受端按照收到帧的顺序重新组装成消息(http报文)
  2. 多路复用(Multiplexing，一个TCP段可以存在多条流)
    - 同个域名只需要一个 TCP 连接，使用一个连接并行发送多个请求和响应。
    - 一个tcp段会包含多个stream，一个stream可能会分成非连续多次发送。
    - 不同流的帧之间可以乱序发送，因为会按照各自的流id组装
    - 请求优先级：每个流可以设定优先级
    - 流量控制：设定每个流可以占用一个tcp段多少带宽（接收端通过WINDOW_UPDATE帧控制其对应流的流量窗口大小），基于每一跳进行，而非端到端的控制
    - 服务端推送：服务端响应时也可以使用新流推送（预加载）资源给客户端（可被拒绝），减少请求响应次数
  3. 头部压缩（HPACK）
    - 原因：http1.1只针对body进行压缩，而包含协议内容，cookie等字段的请求头，有很多内容重复却没有压缩
    - HPACK 压缩算法
      - 客户端和服务端共同维护了一份字典表，来跟踪和存储之前发送的键值对
      - 每次发送数据时，相同的数据不再通过每次请求和响应发送；新数据/修改数据要么被追加到当前表的末尾，要么替换表中之前的值
  4. 禁用域名分片
    - 破坏多路复用优势：分片强制使用多个连接，反而增加握手和头部冗余。
    - 加剧头部压缩失效：多个子域名的请求需携带独立头部信息，无法充分复用HPACK字典。
  5. 缺点
    - TCP层面的队头阻塞并没有彻底解决：“超时重传”机制，丢失的包必须重传确认，后面的TCP包必须等待
    - 多路复用没有限制同时请求数，可能导致服务器压力上升
    - 多路复用容易 Timeout：大批量并行多个流，导致每个流的资源会被稀释，虽然它们开始时间相差更短，但却都可能超时
https加密过程
mysql sql索引设置，联合索引order by何时起作用

代码

输出LIS的起点，终点