Q: 什么是中间人攻击
A:
中间人攻击（Man-in-the-Middle Attack，MITM）是一种网络攻击方式，其中攻击者通过拦截和可能篡改两个通信实体之间的数据流，来窃取敏感信息或插入恶意内容。攻击者在通信链路中充当一个“中间人”，而通信的双方通常并不知晓其存在。
可能出现的风险
- 窃取信息: 登录信息,银行信息等
- 冒充身份: 攻坚组可以冒充一方和另一方进行通信
- 修改通信内容: 攻击者可以在传输过程中更改消息内容
用什么手段进行中间人攻击
-
ARP 欺骗: 攻击者通过发送伪造的ARP消息，将自己的MAC地址与受害者目标IP地址关联。当目标设备发送数据包时，数据将被发送到攻击者，而不是原始的默认网关
- ARP请求和响应：当一台主机需要知道另一台主机的MAC地址时，它会发送一个ARP请求广播到网络中，包含目标主机的IP地址。目标主机接收到请求后，会回复一个ARP响应，告知请求方其MAC地址。
- 发送伪造ARP响应: 攻击者向局域网内的目标设备发送伪造的ARP响应包，声称目标IP地址对应于攻击者的MAC地址。这可以使其他设备将目标IP地址的流量发送到攻击者的机器
- 更新ARP缓存: 受害者设备会更新其ARP缓存，将目标IP与攻击者的MAC地址关联。由于ARP缓存通常没有认证，这一更新很容易实现
- 中转流量: 从此刻起，受害者设备发送到目标IP的所有流量都会首先到达攻击者的计算机。攻击者可以选择拦截、查看、更改或继续将数据转发给最终目标以避免被察觉
-
Wi-Fi 嗅探: 攻击者在开放或不安全的Wi-Fi网络中拦截通过无线网络传输的所有不加密流量。恶意Wi-Fi热点也可以用于捕获用户的数据
-
中间人代理攻击: 攻击者设置一个代理服务器，充当客户端和服务器之间的中间节点。所有通信流量都通过这个代理服务器，攻击者可以查看、修改或记录这些流量
Q: K8S是如何实现服务注册和服务发现的呢
A:
服务注册:
- 当一个Service对象被创建时，Kubernetes API会自动创建一个对应的Endpoints对象。
- Pod被标记上特定的label后，只要这个label符合某个Service的selector要求，Kubernetes就会将此Pod的IP加入到该Service的Endpoints中。
- 这种方式实现了动态的服务注册，无需手动配置。
服务发现:
- DNS：Kubernetes内置的DNS服务器（如CoreDNS）会自动为每个Service创建DNS记录，其他Pod可以通过服务名称轻松访问。
监听POD的上线和下线:
每一个POD都有自己的状态,而这些状态的变更是通过探针来完成的,比如判断一个POD是否处于就绪状态,对应的有一个就绪探针,如果这个POD内部的容器已经准备好接受请求了,那么就是就绪状态,当POD是就绪状态时, Kubernetes的控制平面会自动更新对应的Endpoints对象，将Pod的IP地址添加到关联的Service的Endpoints列表中,如果Pod的就绪探针失败，且Pod之前已在Endpoints中，则Kubernetes会将该Pod的IP从Endpoints中移除。这样可以确保只将流量路由到准备好的Pod上。
SVC里有可访问的POD的Endpoint,当我们要访问这些POD的时候通过SVC这个代理,还能实现负载均衡
Q: 如何理解: 任何系统的网络调用过程中都至少会有一个单点存在
A:
这句话指出在任何系统的网络调用过程中，通常都存在至少一个单点，即某个关键组件或节点，这个组件在系统架构中起着至关重要的作用。如果这个单点出现故障或崩溃，整个系统的网络功能可能会受到严重影响或完全中断。
一般的系统中哪些容易出现单点呢?
- 数据库: 许多应用依赖于数据库来存储和检索关键数据。如果数据库服务器出现故障，可能会导致整个应用不可用
- 有状态的业务服务器: 因为有状态,导致服务器很难扩展,所以可能会出现单点问题
- 负载均衡器: 负载均衡器常常数放到业务的入口处,是调用方统一的入口,很有可能出现单点
- 如果可以,可以用云服务商的 负载均衡器,稳定性有保证
- 第三发服务: 依赖于外部服务的应用如果没有处理好故障检测和降级策略，外部服务的中断可能导致应用功能瘫痪
Q: 微服务中的容错策略有哪些
A:
- 重试: 如果失败就自动重试
- 要求因为是幂等的
- 针对能自动恢复的服务器
- 一定要有退让策略,不然可能会让服务器更难正常
- 断路器: 当服务器的故障率到达阈值后,将开启断路器,这时候请求将不会再发到该服务器,一定时间后将会变成半开状态,一定量的请求会到到该服务器,如果请求正常则关闭断路器,如果还是不正常,半开状态变成开启状态,继续等待
- 针对自动恢复的服务器
- 服务降级: 让服务正常返回,只是一些故障的部分不返回或是返回缓存数据或是默认数据
- 非核心业务可以使用该方法
Q: 一个服务器每一秒可处理80个请求，为什么来了100个请求时，并不是处理80个完整的请求丢弃20个请求，反而是绝大部分的请求都超时了呢
A:
- 资源竞争: 服务器在处理并发请求时，多个请求可能争抢同一资源（如CPU、内存、I/O等），如果这些资源没有很好地管理，可能导致所有请求的性能下降 其实就是 排队用了太多的资源了,把需要用于处理正常请求的资源都消耗了,所以才会导致无法处理.
解决方法:
- 动态扩展,类似k8s的纵向扩展服务器,并在入口处加上负载均衡器
- 限流,使用 令牌桶,漏斗等对流量进行限流
- 使用计数或是滑动窗口等方法主动丢弃一部分请求
