Redis面试8连问

首先建立链接前需要 Server 端先监听端口，因此 Server 端建立链接前的初始状态就是 LISTEN 状态，这时 Client 端准备建立链接，先发送一个 SYN 同步包，发送完同步包后，Client 端的链接状态变成了 SYN_SENT 状态。Server 端收到 SYN 后，同意建立链接，会向 Client 端回复一个 ACK。

由于 TCP 是双工传输，Server 端也会同时向 Client 端发送一个 SYN，申请 Server 向 Client 方向建立链接。发送完 ACK 和 SYN 后，Server 端的链接状态就变成了 SYN_RCVD。

Client 收到 Server 的 ACK 后，Client 端的链接状态就变成了 ESTABLISHED 状态，同时，Client 向 Server 端发送 ACK，回复 Server 端的 SYN 请求。

Server 端收到 Client 端的 ACK 后，Server 端的链接状态也就变成了的 ESTABLISHED 状态，此时建连完成，双方随时可以进行数据传输。

在面试时需要明白三次握手是为了建立双向的链接，需要记住 Client 端和 Server 端的链接状态变化。另外回答建连的问题时，可以提到 SYN 洪水攻击发生的原因，就是 Server 端收到 Client 端的 SYN 请求后，发送了 ACK 和 SYN，但是 Client 端不进行回复，导致 Server 端大量的链接处在 SYN_RCVD 状态，进而影响其他正常请求的建连。可以设置 tcp_synack_retries = 0 加快半链接的回收速度，或者调大 tcp_max_syn_backlog 来应对少量的 SYN 洪水攻击

四次挥手

我们只要关注 80 端口与 13743 端口建立的连接断开过程，浏览器通过 13747 端口发送 [FIN, ACK] 这里是不是跟很多网上看到的不一样?

其实是客户端在发送 [FIN] 报文的时候顺带发了一个 [ACK] 确认上次传输确认。

接着服务端通过 80 端口响应了 [ACK] ，然后立马响应 [FIN, ACK] 表示数据传输完了，可以关闭连接。

最后浏览器通过 13743 端口 发送 [ACK] 包给服务端，客服端与服务端连接就关闭了。

具体流程如下图抓包所示：
 

异步：降低系统的耦合性

• 提供系统的可用性
• 加快响应速度

冗余：冷备和热备，保证系统的可用性

自动化：发布，测试，部署，监控，报警，失效转移，故障恢复

安全：

7.3. 架构核心要素

高性能：网站的灵魂

• 性能测试
• 前端优化
• 应用优化
• 数据库优化

可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成

• 负载均衡
• 数据备份
• 自动发布
• 灰度发布
• 监控报警

伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器

集群

• 负载均衡
• 缓存负载均衡

可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖

• 分布式消息
• 服务化

安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。

• xss攻击
• sql注入
• csr攻击
• web防火墙漏洞
• 安全漏洞
• ssl

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!