快手（安全方向）面试准备

一、自我介绍+项目介绍

面试官您好！我目前就读于东北林业大学人工智能专业，核心学习方向是Go后端开发。了解到贵岗是安全方向的研发内部认证授权系统，恰好我有一个IAM系统的项目经验高度匹配，接下来重点介绍这个项目：

该IAM系统的核心目标是解决"统一认证授权、细粒度访问控制"的行业痛点。其中认证功能基于JWT实现，逻辑相对清晰；授权功能是核心难点，主要围绕用户、密钥、策略三类核心资源展开，用户通过IAM系统完成授权仅需4步：

完成注册登录；
创建专属密钥；
配置访问策略；
调用IAM授权接口时，系统会依据预设策略判断操作是否允许。

系统完整数据链路如下：

用户（如张三）在IAM网页完成注册、创建密钥和策略，相关数据持久化存储在MySQL中；
授权核心模块主动拉取密钥和策略，缓存至内存以提升权限判断效率；
若用户修改策略，系统会自动同步更新内存缓存，保证数据一致性；
当电商APP调用IAM授权接口（传入张三的密钥+"修改订单123"请求），授权核心先验证密钥合法性，再查询内存中的策略规则，判断允许操作后返回"允许"结果；
同时将"张三改订单成功"的操作日志存入Redis，便于审计追溯。

二、四种常见认证方式（按常用程度排序）

1. Basic 认证（基础认证）：最简单但需配 HTTPS

原理：将"用户名：密码"做base64编码（仅格式转换，非加密），放入请求头发送至服务器，服务器解码后与数据库比对，匹配则通过。
示例：admin:Admin@2021编码后生成对应字符串，请求时携带该字符串即可。
优缺点：实现简单，但安全性极低------编码可轻松解密，且易遭遇"重放攻击"（截获编码后重复使用）。
用法：必须搭配HTTPS加密传输，在IAM系统中用于用户登录（前后端通过HTTPS通信）。
重要原则：禁止将明文密码放入请求参数，也不存储明文密码在数据库。

2. Bearer 认证（令牌认证）：API 调用首选，常用 JWT 实现

原理：登录成功后服务器发放加密令牌，后续请求仅需携带令牌，服务器验证令牌合法性即可通过，无需反复传输用户名密码。
核心实现：基于JWT（最主流的令牌格式）。
优缺点：安全（令牌可设置过期时间、支持加密）、无状态（服务器无需存储令牌，降低性能消耗）；需搭配HTTPS防止令牌被截获。

3. Digest 认证（摘要认证）：比 Basic 安全，但实现复杂

原理：不直接传输密码，服务器先返回随机数，客户端用密码+随机数计算"摘要"（加密字符串），服务器用相同逻辑计算摘要并比对，匹配则通过。
优点：密码非明文传输，且随机数动态变化可防重放攻击；
缺点：实现复杂度高，仅保护密码不保护请求内容，仍需搭配HTTPS。

4. OAuth2.0（开放授权）：第三方登录专用

原理：第三方应用无需获取用户账号密码，即可访问用户资源（如微信登录小程序，小程序无需知晓微信密码）。
四种授权方式（按安全程度排序） ：
- 授权码模式（最安全）：先获取"授权码"，再用授权码兑换令牌，适配有后端的应用；
- 密码式：直接将用户名密码提交给第三方，仅适用于高度信任的应用；
- 隐藏式：直接返回令牌，适配前端应用，需缩短令牌有效期；
- 凭借式：用预分配的secretID/secretKey兑换令牌，适配命令行应用。
常见场景：微信登录、QQ登录、GitHub授权第三方应用。

三、重点：Bearer 认证的核心实现 ------ JWT

JWT是一段加密字符串，登录成功后由服务器下发至客户端，客户端后续请求携带该令牌，服务器验证通过则放行。

1. JWT 认证流程（4 步）

用户提交用户名密码登录；
服务器验证通过后，签发JWT令牌返回给客户端；
客户端将令牌存储在浏览器（Cookie 或 LocalStorage）；
后续请求均携带令牌，服务器验证令牌合法后处理请求。

2. JWT 结构（3 部分，以"."分隔）

示例：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJpYW0uYXV0aHoubWFybW90ZWR1LmNvbSIsImV4cCI6MTYwNDE1ODk4NywiaWF0IjoxNjA0MTUxNzg3LCJpc3MiOiJpYW1jdGwiLCJuYmYiOjE2MDQxNTE3ODd9.LjxrK9DuAwAzUD8-9v43NzWBN7HXsSLfebw92DKd1JQ

每部分均为base64编码（可解密查看内容，签名部分篡改后立即失效）：

Header（头部）：声明JWT类型及加密算法，示例：{"typ":"JWT","alg":"HS256"}；
Payload（载荷） ：存储核心信息，分三类：
- 标准字段（可选）：exp（过期时间）、iss（签发者）、aud（接收方）；
- 公共字段：自定义非敏感信息（如用户名、角色）；
- 私有字段：与服务器约定的信息（禁止存储密码、手机号等敏感内容）；
Signature（签名） ：核心安全保障，防止令牌篡改。
- 原理：服务器基于Header指定的算法+专属密钥（仅服务器知晓），对"Header编码.Payload编码"加密生成签名；
- 验证：服务器接收令牌后，重新计算签名并与令牌中的签名比对，一致则合法。

3. JWT 使用建议

禁止在Payload中存储敏感信息（如密码、身份证号），因其可解密；
令牌过期时间不宜过长（线上建议2小时，开发环境可设7天）；
服务器密钥需严格保管，泄露可能导致令牌伪造与系统入侵。

四、IAM 项目的认证功能设计与实现

核心逻辑：两种认证方式（Basic/Bearer）+ 两个核心服务（iam-apiserver/iam-authz-server）+ 设计模式加持。

1. 核心设计：不同服务/客户端的认证方式适配

服务 / 客户端	认证方式	核心场景
控制台、App 端	Basic 认证	用户登录（输入用户名密码）
iamctl、API 调用、Go SDK	Bearer 认证（JWT）	后续API接口调用
iam-authz-server	Bearer 认证（JWT）	处理/v1/authz授权请求
核心原则：登录环节用Basic（简单直观），后续接口调用用Bearer（安全高效，避免密码反复传输），且所有通信均适配HTTPS防御攻击。

2. 关键设计细节

（1）密码/密钥存储策略

iam-apiserver（用户/密钥管理）：存储于MySQL------管理流对延迟不敏感，需保证数据持久化；
iam-authz-server（授权请求处理）：缓存至内存------数据流需支撑高并发，内存查询效率比数据库高10倍以上。

（2）内存缓存同步机制

iam-authz-server的密钥从iam-apiserver通过gRPC获取；当iam-apiserver更新密钥时，会向Redis通道发送消息，iam-authz-server订阅后自动更新内存缓存，保证数据一致性。

（3）JWT 选型原因

无需在服务器存储Token，JWT自带签名与过期时间，客户端存储即可；服务器仅需用密钥校验签名，降低性能压力，且支持跨服务使用。

3. Basic 认证实现（登录验证）

核心作用：用户通过用户名密码兑换JWT Token，类比"刷身份证进门"。

客户端操作

两种请求方式（推荐第一种，避免密码明文传输）：

方式1：将"用户名：密码"base64编码后，放入请求头Authorization: Basic 编码字符串；
方式2：请求体直接传输明文用户名密码（不推荐）。

服务器（iam-apiserver）操作

采用"策略模式"，将Basic认证封装为独立"策略"挂载至/login接口，步骤如下：

解析请求：从请求头/请求体提取用户名密码；
校验密码：从数据库查询用户加密密码，与客户端密码加密后比对；
签发Token：校验通过后生成带过期时间的JWT Token并返回；
可选操作：将Token存入Cookie，便于前端后续使用。

配套接口

/logout：清空Cookie中的Token，实现登出；
/refresh：Token即将过期时，用旧Token兑换新Token，避免重新登录。

4. Bearer 认证实现（后续API验证）

核心作用：通过JWT Token证明"已完成登录"，类比"刷门禁卡进门"，两个服务实现逻辑略有差异，但核心均为校验JWT合法性。

（1）iam-apiserver的Bearer认证（普通API请求）

采用"自动策略"：从请求头Authorization: Bearer XXX解析Token，自动识别认证类型（Basic/Bearer），校验步骤：

解析Token：拆分Header（加密算法）、Payload（过期时间、用户名）、Signature（签名）；
校验签名：用服务器密钥+Header指定算法重新计算签名，与Token中的Signature比对；
校验过期：检查Payload中的exp字段，确认未过期；
传递信息：将Token中的用户名存入上下文，供后续业务逻辑直接使用。

（2）iam-authz-server的Bearer认证（/v1/authz授权请求）

采用"缓存策略"：密钥缓存至内存，校验效率更高，步骤精简：

解析Token：从Header提取JWT，拆分Header中的kid（密钥ID）；
查找密钥：通过kid从内存缓存获取对应secretKey；
校验签名：用secretKey校验Token签名，确认合法且未过期；
传递信息：将用户名存入上下文，供权限判断使用。

5. 设计模式：提升代码灵活性

无需记忆名词，核心作用如下：

策略模式：将Basic/Bearer认证封装为独立策略，切换认证方式仅需替换策略，无需修改核心逻辑；
抽象工厂模式：通过newBasicAuth()、newJWTAuth()等函数创建认证策略，返回接口类型，隐藏内部实现，便于扩展；
面向接口编程：所有认证策略均实现AuthFunc()方法，调用方式统一，代码更简洁。

6. 核心流程总结

用户通过控制台/App，以Basic认证（用户名密码）调用/login接口；
iam-apiserver校验通过后，返回JWT Token；
后续调用API时，客户端在请求头携带Bearer + Token；
服务端（iam-apiserver/iam-authz-server）校验Token合法性（签名+过期时间）；
校验通过后，允许接口调用或处理授权请求。

7. 关键提醒

Basic认证仅用于登录，后续全用Bearer，避免密码泄露；
JWT Token禁止存储敏感信息（如密码），因Payload可解密；
内存缓存需做好同步（基于Redis通道），防止密钥不一致导致认证失败。

五、5 大权限模型

核心逻辑：解决"谁（用户）能对什么（资源）做什么（操作）"，不同模型的差异在于"定义权限规则的方式"。

1. 基础术语（理解即可）

用户（Subject）：操作发起者（如张三、李四）；
资源（Object）：操作对象（如文件、文章、服务器）；
操作（Action）：具体行为（如查看、创建、删除）；
权限（Permission）：允许/禁止"用户对资源执行操作"；
角色（Role）：一组权限的集合（如"管理员""普通用户"）；
策略（Policy）：权限的具体规则（如"仅允许张三从公司IP查看文件"）。

2. 五大权限模型拆解

模型	核心逻辑	示例	适用场景	缺点
ACL（权限控制列表）	为每个资源配置"允许操作的用户名单"，名单内用户可操作	文件A的ACL包含张三、李四，仅二人可查看	资源/用户少（个人网盘）	资源/用户增多后，维护成本剧增
DAC（自主访问控制）	ACL升级版，允许有权限的用户将权限转让给他人	张三可将"修改文章"权限转让给李四	团队协作（共享文档）	权限分散，难以统一管控
MAC（强制访问控制）	用户和资源均有"安全标签"，需同时满足用户可操作、资源允许被操作才放行	张三（普通员工标签）无法删除"仅管理员可删"的文件B	涉密场景（政府、军工）	规则死板，不适配普通业务
RBAC（基于角色的访问控制）	先将权限打包为"角色"，再给用户分配角色，用户继承角色所有权限	"管理员"角色含"增删查文件"权限，分配给张三后其拥有对应权限	公司系统、后台管理（规模化场景）	复杂条件下灵活性不足（如按IP限制）
ABAC（基于属性的权限验证）	基于用户/资源/环境等属性判断权限，规则粒度极细	产品部张三仅可在公司IP下编辑技术类草稿文章	大平台、复杂场景（云厂商权限管控）	规则复杂，前期设计成本高

RBAC进阶版本

RBAC1：角色支持继承（如"超级管理员"继承"管理员"权限，新增"批量操作"权限）；
RBAC2：增加约束（如"不可同时为管理员和普通用户"）；
RBAC3：包含以上所有功能，最完整。

六、常见加密算法

核心分为三类：对称加密（同钥加解密）、非对称加密（双钥加解密）、哈希算法（不可逆验证）。

1. 对称加密：一把钥匙开一把锁（高效）

核心逻辑：加密/解密使用同一密钥，如用"123456"加密文件，也需该密钥解密。
常见算法 ：
- AES：主流算法（手机支付、文件加密），安全高效，密钥选128/256位；
- DES：老旧算法，56位密钥易破解，已淘汰；
- 3DES：DES升级版，安全性提升但效率低于AES。
特点：速度快，适配大文件/大量数据加密；缺点是密钥需安全传输。
生活类比：用同一把钥匙锁柜、开柜。

2. 非对称加密：两把钥匙，一把锁一把开（安全但慢）

核心逻辑：生成"公钥（公开）+私钥（保密）"密钥对；公钥加密的内容仅私钥可解，反之亦然。
常见算法 ：
- RSA：应用最广（HTTPS、SSH登录），密钥选2048/4096位；
- ECC（椭圆曲线加密）：效率更高，同等安全级别下密钥更短，适配手机/物联网设备。
特点：无需传递密钥（公钥可公开），安全性高；速度慢，仅适配小数据加密（如对称加密的密钥）。
生活类比：公钥发给所有人用于锁秘密，仅自己的私钥能解锁。

3. 哈希算法：不可逆的"指纹"（仅验证）

核心逻辑：将任意长度数据转换为固定长度哈希值（如32位字符串），不可逆（无法从哈希值还原原数据）。
常见算法 ：
- MD5：128位哈希值，易碰撞，仅用于文件完整性校验；
- SHA系列：SHA-1（已淘汰）、SHA-256（常用）、SHA-512（更安全但慢）；
- HMAC：结合哈希算法+密钥，用于接口请求签名验证。
特点：不可逆、唯一性（相同数据哈希值一致）；适配密码存储、文件篡改验证。
生活类比：文件哈希值=文件指纹，比对指纹可确认文件是否被篡改。

4. 实际应用场景

大文件/大量数据加密：AES（对称）加密数据 + RSA（非对称）加密AES密钥；
HTTPS：先通过RSA/ECC交换对称密钥，后续数据用对称加密传输；
密码存储：SHA-256+HMAC计算哈希值，搭配"盐"（如用户ID）防彩虹表破解；
文件/消息验证：哈希算指纹，或私钥签名+公钥验签（确认来源且未篡改）。

核心总结

快/加密大数据：选对称加密（AES）；
安全/传密钥/签名：选非对称加密（RSA/ECC）；
验证/存密码：选哈希算法（SHA-256）；
实际场景多为"非对称+对称"搭配，兼顾安全与效率。

七、Casbin权限模型落地逻辑（源码层面）

核心目标：将ACL/RBAC/ABAC等权限规则，转化为代码可执行的判断逻辑。

1. Casbin核心结构（四大模块）

模块	大白话作用
Model（模型）	定义权限模型的"语法规则"（如RBAC需区分用户/角色/权限），即"规则模板"
Policy（策略）	存储具体权限规则（如"管理员可删除文件"），即"规则明细"
Adapter（适配器）	将Policy存储至数据库/文件/内存（如MySQL、JSON），负责规则的读写
Enforcer（执行器）	核心模块：加载Model+Policy，接收访问请求，按规则校验并返回"允许/拒绝"

2. 核心流程（以RBAC为例）

步骤1：定义Model（规则模板）

通过.conf配置文件定义Model，源码解析为Model结构体：

ini 复制代码

[request_definition]
r = sub, obj, act  # 请求格式：用户、资源、操作
[policy_definition]
p = sub, obj, act  # 策略格式：与请求对应
[role_definition]
g = _, _           # 角色关系：g(用户, 角色)
[policy_effect]
e = some(where (p.eft == allow))  # 有一条允许规则即通过
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act  # 匹配规则

源码动作 ：model.NewModel()解析配置，将matchers表达式解析为可执行的"表达式树"。

步骤2：加载Policy（规则明细）

Policy为具体权限规则（如JSON格式），通过Adapter加载：

json 复制代码

[
  {"ptype":"p","v0":"管理员","v1":"文件","v2":"删除"},
  {"ptype":"g","v0":"张三","v1":"管理员"}
]

源码动作 ：Adapter实现LoadPolicy()方法，将规则读入Enforcer的policyMap（按ptype分组，便于快速查找）。

步骤3：校验请求（核心逻辑）

调用enforcer.Enforce("张三", "文件", "删除")时，源码核心流程：

go 复制代码

func (e *Enforcer) Enforce(rvals ...interface{}) bool {
  req := model.NewRequest(rvals...) // 封装请求参数
  result, _ := e.enforceWithMatcher(e.model.Model["m"]["m"].Value, req) // 匹配规则
  return result
}

func (e *Enforcer) enforceWithMatcher(matcher string, req *model.Request) (bool, error) {
  expr, _ := e.compileMatcher(matcher) // 解析匹配表达式
  for _, policy := range e.policyMap["p"] { // 遍历策略规则
    // 代入请求参数与策略，计算表达式（如判断张三是否为管理员、操作是否匹配）
    if expr.Eval(map[string]interface{}{"r": req, "p": policy, "g": e.roleManager.HasLink}) {
      return true, nil // 匹配成功则允许
    }
  }
  return false, nil // 无匹配规则则拒绝
}

源码细节：

RoleManager：处理角色关系（如判断用户是否属于某角色）；
Matcher表达式：支持自定义逻辑（如ABAC的属性判断）；
性能优化：通过policyMap、缓存减少遍历次数。

步骤4：ABAC落地扩展

修改matchers表达式即可适配ABAC（加入属性判断）：

ini 复制代码

[matchers]
m = r.sub.department == p.obj.department && r.act == p.act && r.env.ip == p.env.ip

源码动作：请求参数传入带属性的对象，表达式读取属性并判断匹配。

3. 落地核心技巧（源码层面）

接口化设计：Model/Policy/Adapter均为接口，扩展存储/模型仅需实现接口，无需改核心逻辑；
表达式引擎：基于govaluate解析matchers，规则可动态配置，无需改代码切换权限模型；
分层解耦：Model（规则结构）、Policy（规则数据）、Enforcer（规则校验）解耦，扩展灵活。

4. 核心总结

Casbin落地权限模型的本质：

将权限规则拆分为"模板（Model）+ 数据（Policy）"，通过配置定义，无需硬编码；
Enforcer通过表达式引擎，将请求参数与策略代入匹配，返回判断结果；
不同权限模型仅需修改Model的matchers表达式和policy_definition结构。

八、Go的测试框架

核心逻辑：官方testing包为基础核心，第三方库为功能补充。

1. 框架组成：核心包+第三方工具

Go无"一站式大框架"，靠官方testing包（基础测试）+ 社区第三方库（功能扩展）完成测试，前者管基础逻辑，后者简化操作、丰富功能。

2. 核心：官方`testing`包（开箱即用）

（1）单元测试（验证功能正确性）

核心逻辑：编写以Test开头的函数（如TestAbs），参数为*testing.T，通过t.Errorf()判断测试结果。
示例：
go 复制代码
```
func TestAbs(t *testing.T) {
  got := Abs(-1)
  if got != 1 {
    t.Errorf("Abs(-1)得到%f，想要1", got)
  }
}
```
执行方式：代码目录执行go test，自动识别*_test.go中的Test函数。

（2）性能测试（验证代码效率）

核心逻辑：编写以Benchmark开头的函数（如BenchmarkRandInt），参数为*testing.B，通过b.N循环执行统计耗时。
示例：
go 复制代码
```
func BenchmarkRandInt(b *testing.B) {
  for i := 0; i < b.N; i++ {
    RandInt()
  }
}
```
执行方式：go test -bench=".*"，输出每秒执行次数、单次耗时、内存占用。

（3）基准能力

子测试：t.Run("用例1", func(t *testing.T) { ... })，一个函数内执行多个用例；
跳过测试：t.Skip("暂时跳过")；
超时控制：go test -timeout=10s，防止测试阻塞。

官方包特点

优点：轻量、原生、无依赖，满足80%基础测试需求；
缺点：功能简单（需手写对比逻辑、无断言/ mock）。

3. 补充：常用第三方测试库

库名	核心作用	示例
testify	简化结果对比（断言），支持mock、测试套件	`assert.Equal(t, got, 1)`（一行完成结果比对，自动输出错误）
gomock	模拟依赖（如模拟数据库返回，无需连接真实数据库）	模拟`DB.Query`返回值，测试依赖DB的函数
goconvey	可视化测试报告，支持嵌套测试	浏览器访问http://localhost:8080查看结果，链式写法组织测试用例
gotests	自动生成测试代码框架	`gotests -all -w .`，为当前目录函数生成`TestXxx`模板

4. 使用逻辑（新手适配）

基础测试：testing包实现单元/性能测试；
简化操作：引入testify做断言；
复杂场景：gomock模拟依赖、goconvey可视化；
效率提升：gotests自动生成测试模板。

5. 核心总结

核心：testing包轻量够用，满足基础测试；
补充：第三方库解决断言、mock、可视化等问题；
新手优先级：testing+testify（覆盖90%场景）；
硬性规则：测试文件命名*_test.go，测试函数以Test/Benchmark开头。

九、LRUCache 代码解析（面试回答版）

1. 核心思路

LRU（最近最少使用）缓存的核心是"淘汰最久未使用的缓存项"，实现方案为：哈希表（O(1)查找）+ 双向链表（O(1)增删），哈希表存储"键-节点"映射，双向链表维护缓存使用顺序（头部为最新，尾部为最久未使用）。

2. 代码结构拆解

（1）节点结构体（Node）

go 复制代码

type Node struct{
    key int       // 存储键（删除尾节点时，需通过key删除哈希表对应项）
    value int     // 存储值
    prev *Node    // 前驱节点
    next *Node    // 后继节点
}

（2）LRUCache 结构体

go 复制代码

type LRUCache struct {
    cache map[int]*Node   // 哈希表：快速查找节点
    dummyHead *Node       // 虚拟头节点（避免头节点为空判断）
    dummyTail *Node       // 虚拟尾节点（避免尾节点为空判断）
    capacity int          // 缓存容量
    size int              // 当前缓存数量
}

（3）构造函数（Constructor）

go 复制代码

func Constructor(capacity int) LRUCache {
    head,tail:=&Node{},&Node{}
    head.next=tail  // 虚拟头连虚拟尾
    tail.prev=head
    return LRUCache{
        cache: make(map[int]*Node,capacity),
        dummyHead: head,
        dummyTail: tail,
        capacity: capacity,
        size: 0,
    }
}

核心动作：初始化虚拟头尾节点并建立连接，初始化哈希表与容量参数。

（4）核心辅助方法

addNodeToHead：将节点插入虚拟头节点后（标记为最新使用）；
removeNode：从链表中移除指定节点；
moveToHead：将节点移至头部（更新使用状态）；
removeTailNode：移除虚拟尾节点前驱（淘汰最久未使用项）。

（5）Get 方法（查询缓存）

go 复制代码

func (this *LRUCache) Get(key int) int {
    if node,ok:=this.cache[key];ok{ // 哈希表找到节点
        this.moveToHead(node)       // 移至头部（标记为最新使用）
        return node.value
    }
    return -1 // 未找到返回-1
}

（6）Put 方法（写入缓存）

go 复制代码

func (this *LRUCache) Put(key int, value int)  {
    if node,ok:=this.cache[key];ok{ // 缓存已存在
        node.value=value            // 更新值
        this.moveToHead(node)       // 移至头部
    }else{ // 缓存不存在
        node:=&Node{key:key,value:value} // 新建节点
        this.cache[key]=node             // 哈希表添加映射
        this.addNodeToHead(node)         // 链表头部插入
        this.size++                      // 缓存数量+1
        if this.size>this.capacity{      // 超出容量
            tailNode:=this.removeTailNode() // 移除最久未使用节点
            delete(this.cache,tailNode.key) // 哈希表删除映射
            this.size--                      // 缓存数量-1
        }
    }
}

3. 核心优势

时间复杂度：所有操作（增删查）均为O(1)，满足高频访问场景；
空间复杂度：O(capacity)，仅占用缓存容量级别的内存；
边界处理：虚拟头尾节点避免了空指针判断，逻辑更简洁。

十、网络核心知识点（面试话术）

1. TCP三次握手

回答思路 ：核心作用+生活例子+流程+核心考点（为什么三次）
面试话术 ：

"TCP三次握手的核心是「建立可靠的双向通信连接」，类比打电话确认连通：

客户端（我）：'喂，能听到吗？'------发送连接请求；
服务端（你）：'能听到，你能听到我吗？'------确认收到请求，验证自身收发能力；
客户端（我）：'我也能听到！'------确认收到回应，双方达成双向连通。
之所以需要三次而非两次，是为了防止「过期连接请求」浪费资源。比如客户端早期发送的请求因网络延迟迟到，服务端收到时客户端已无通信需求，三次握手能确保双方均处于"当前在线且有通信意愿"的状态。"

2. UDP可靠传输实现

回答思路 ：UDP本质+手动保障规则+实际场景
面试话术 ：

"UDP本身是「无保障的平邮」------不管丢包、不管顺序，速度快但不可靠。要实现可靠传输，需自定义4类规则：

编号+确认：给每个数据包编序号，接收方收到后回传确认包，未收到则重发；
超时重传：发送方设置计时器，超时未收到确认则重新发送；
排序重组：接收方按序号整理乱序数据包；
批量确认：每批数据包汇总确认，检测丢包并补发。
实际场景中，微信语音、直播均采用「UDP+自定义可靠规则」，既保证实时性，又能降低丢包影响。"

3. HTTP/HTTPS区别

回答思路 ：核心差异+类比+实际应用
面试话术 ：

"HTTP和HTTPS的核心差异是「安全性」，类比普通快递vs加密快递：

HTTP：明文传输，数据裸奔（可被抓包查看），使用80端口，无需证书，适配纯资讯类网页；
HTTPS：= HTTP + SSL/TLS加密 + CA证书，数据加密传输（仅收件方可解密），使用443端口，需正规CA证书（验证网站合法性，防钓鱼）。
实际开发中，涉及密码、支付、用户隐私的场景必须用HTTPS，这也是行业合规要求。"

4. HTTP缓存机制（强缓存/协商缓存）

回答思路 ：缓存目的+类比+两类缓存规则+核心字段+应用场景
面试话术 ：

"HTTP缓存的核心目的是「减少重复请求，提升加载速度、降低服务器压力」，类比超市囤货：

强缓存：「直接用囤货，不问老板」------服务器返回资源时，通过Cache-Control（如max-age=3600）或Expires告知浏览器有效期，未过期则直接读取本地缓存，无需与服务器通信；
协商缓存：「问老板货还能用吗」------强缓存过期后，浏览器携带ETag（资源内容哈希）或Last-Modified（资源修改时间）询问服务器，服务器返回304（未更新）则继续用缓存，返回200则更新缓存并使用新资源。
实际应用中，图片、静态JS/CSS用强缓存，动态用户数据用协商缓存，平衡性能与数据新鲜度。"

5. DNS解析流程

回答思路 ：核心作用+类比+从近到远流程+缓存机制
面试话术 ：

"DNS解析的核心是「把网址（如www.baidu.com）翻译成IP地址」，类比查快递地址本，流程分4步：

查本地缓存：先看电脑/路由器本地缓存，有则直接使用；
查运营商DNS：本地无则询问运营商DNS（如电信DNS），常用网址大概率已缓存；
递归查询：运营商DNS逐级询问根DNS（全球13台，指引查.com DNS）→ .com顶级DNS（指引查baidu.com DNS）→ 百度权威DNS（返回真实IP）；
返回结果：运营商DNS将IP返回至客户端，客户端即可访问百度。
DNS解析结果会缓存，首次查询走全流程，后续几小时内直接读取缓存，提升效率。"

6. OSI七层模型

回答思路 ：核心逻辑+类比+分层作用+与TCP/IP对应关系
面试话术 ：

"OSI七层模型是「网络通信的分工手册」，将传输拆分为7层，每层各司其职，类比快递流水线：

从下到上：

物理层（网线/电信号）：快递货车/公路；
数据链路层（WiFi/交换机）：小区快递柜；
网络层（IP+路由）：物流路线规划；
传输层（TCP/UDP）：配送规则（顺丰/平邮）；
会话层（建立连接）：确认收件时间；
表示层（加密/转码）：商品打包；
应用层（HTTP/DNS）：包裹内的商品。
实际互联网使用TCP/IP四层模型，将OSI的应用/表示/会话合并为应用层，物理/数据链路层合并为网络接口层，核心逻辑均为「分层解耦，便于维护扩展」。"

面试加分小技巧

每个知识点补充「实际应用场景」（如"支付用HTTPS""直播用UDP"），体现实战认知；
提及1-2个关键技术字段（如Cache-Control、ETag），体现技术细节掌握；
语速适中，先结论后展开，避免冗长，突出"理解而非背诵"。

快手（安全方向）面试准备

一、自我介绍+项目介绍

二、四种常见认证方式（按常用程度排序）

1. Basic 认证（基础认证）：最简单但需配 HTTPS

2. Bearer 认证（令牌认证）：API 调用首选，常用 JWT 实现

3. Digest 认证（摘要认证）：比 Basic 安全，但实现复杂

4. OAuth2.0（开放授权）：第三方登录专用

三、重点：Bearer 认证的核心实现 ------ JWT

1. JWT 认证流程（4 步）

2. JWT 结构（3 部分，以"."分隔）

3. JWT 使用建议

四、IAM 项目的认证功能设计与实现

1. 核心设计：不同服务/客户端的认证方式适配

2. 关键设计细节

（1）密码/密钥存储策略

（2）内存缓存同步机制

（3）JWT 选型原因

3. Basic 认证实现（登录验证）

客户端操作

服务器（iam-apiserver）操作

配套接口

4. Bearer 认证实现（后续API验证）

（1）iam-apiserver的Bearer认证（普通API请求）

（2）iam-authz-server的Bearer认证（/v1/authz授权请求）

5. 设计模式：提升代码灵活性

6. 核心流程总结

7. 关键提醒

五、5 大权限模型

1. 基础术语（理解即可）

2. 五大权限模型拆解

RBAC进阶版本

六、常见加密算法

1. 对称加密：一把钥匙开一把锁（高效）

2. 非对称加密：两把钥匙，一把锁一把开（安全但慢）

3. 哈希算法：不可逆的"指纹"（仅验证）

4. 实际应用场景

核心总结

七、Casbin权限模型落地逻辑（源码层面）

1. Casbin核心结构（四大模块）

2. 核心流程（以RBAC为例）

步骤1：定义Model（规则模板）

步骤2：加载Policy（规则明细）

步骤3：校验请求（核心逻辑）

步骤4：ABAC落地扩展

3. 落地核心技巧（源码层面）

4. 核心总结

八、Go的测试框架

1. 框架组成：核心包+第三方工具

2. 核心：官方testing包（开箱即用）

（1）单元测试（验证功能正确性）

（2）性能测试（验证代码效率）

（3）基准能力

官方包特点

3. 补充：常用第三方测试库

4. 使用逻辑（新手适配）

5. 核心总结

九、LRUCache 代码解析（面试回答版）

1. 核心思路

2. 代码结构拆解

（1）节点结构体（Node）

（2）LRUCache 结构体

（3）构造函数（Constructor）

（4）核心辅助方法

（5）Get 方法（查询缓存）

（6）Put 方法（写入缓存）

3. 核心优势

十、网络核心知识点（面试话术）

1. TCP三次握手

2. UDP可靠传输实现

3. HTTP/HTTPS区别

4. HTTP缓存机制（强缓存/协商缓存）

5. DNS解析流程

6. OSI七层模型

面试加分小技巧

2. 核心：官方`testing`包（开箱即用）