常见的网络IO模型
- 阻塞IO（Blocking IO）
- 非阻塞IO（Non-blocking IO）
- IO多路复用（IO Multiplexing）
- 信号驱动IO（Signal-driven IO）
- 异步IO（Asynchronous IO）
一文搞懂常见的网络I/O模型同步是指用户线程发起IO请求后需要等待或者轮询内核IO操作完成后才能继续执行； 异步是指用户 - 掘金
TCP/IP
TCP为什么是三次握手四次挥手？
三次握手
- 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
- 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
- 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
四次挥手
- 因此当主动方发送断开连接的请求（即FIN报文）给被动方时，仅仅代表主动方不会再发送数据报文了，但主动方仍可以接收数据报文。
- 被动方此时有可能还有相应的数据报文需要发送，因此需要先发送ACK报文，告知主动方“我知道你想断开连接的请求了”。这样主动方便不会因为没有收到应答而继续发送断开连接的请求（即FIN报文）。
- 被动方在处理完数据报文后，便发送给主动方FIN报文；这样可以保证数据通信正常可靠地完成。发送完FIN报文后，被动方进入LAST_ACK阶段（超时等待）。
- 如果主动方及时发送ACK报文进行连接中断的确认，这时被动方就直接释放连接，进入可用状态。
TCP和UDP的区别
| TCP | UTP | |
|---|---|---|
| 连接性 | 面向连接的协议，意味着在数据传输之前，必须先建立连接。它保证了数据包的顺序传输和完整性。 | 无连接的协议，数据包可以独立发送，无需建立连接。 |
| 可靠性 | 可靠 | 不可靠（不保证数据包的到达，也不对数据包进行排序，可能会丢失） |
| 速度 | 较慢（需要进行三次握手建立连接、确认和错误恢复） | 较快 |
| 头部开销 | 头部开销较大，至少需要20字节的头信息 | 头部开销小，头信息只有8字节 |
| 用途 | Web浏览、电子邮件、文件传输 HTTP、HTTPS、FTP、SMTP等协议 | 视频会议、在线游戏和语音传输 DNS、SNMP、DHCP、RTP、VoIP等协议 |
| 确认机制 | 接收方会对接收到的包进行确认，未被确认的包会被重新发送。 | 没有确认机制，发送方不会知道包是否已成功到达。 |
| 错误检测 | 有错误检测和错误恢复功能。 | 有基本的错误检测，但没有错误恢复。 |
黏包与拆包
由于网络的不可靠性，TCP为了提高传输效率，会将多个小数据块打包成一个大的数据块一起发送（称为TCP粘包），或者将一个大的数据块拆分成多个小的数据块发送（称为TCP拆包）。这种情况可能发生在发送和接收数据的任何一端，通常是由于TCP缓冲区的大小限制或数据发送和接收的速率不一致引起的。
解决黏包、拆包问题
- 在信息中加入特殊的标志作为分隔符
- 加入信息的长度
- 添加包首部
服务端未收到请求，如何确保请求已被客户端成功发出？
-
日志：确保客户端在发送数据时记录了日志，检查客户端的
write或send方法是否成功执行。 -
可以使用
netstat或其他类似工具检查 TCP 连接的状态，确认连接是否正常。netstat -an | grep :<port> -
检查客户端的网络问题
- 防火墙和安全组
- 检查网络连通性
- 排除网络超时或者网络延时的原因
-
抓包
- 确认TCP三次握手成功：使用抓包工具（如Wireshark）检查TCP三次握手是否成功完成。
- 确认没有丢包：使用抓包工具检查是否有丢包或重传现象。
-
检查TCP缓冲区
- 客户端缓冲区：确保客户端的数据已成功写入内核发送缓冲区。
- 服务端缓冲区：检查服务端是否从接收缓冲区读取数据。
- 缓冲区大小：如果数据量较大，可能需要调整TCP缓冲区大小。
-
其他
- 排查是否服务端负载过高。
HTTP与HTTPS
HTTP常见状态码
-
1xx（信息响应）
- 100 Continue：客户端可以继续发送请求。
- 101 Switching Protocols：服务器同意切换协议。
-
2xx（成功）
- 200 OK：请求成功，常用于GET和POST请求。
- 201 Created：请求成功，并且服务器创建了新的资源。
- 202 Accepted：请求已接受，但尚未处理完成。
- 204 No Content：请求成功，但服务器未返回任何内容。
-
3xx（重定向）
- 301 Moved Permanently：资源永久移动，客户端应使用新URL。
- 302 Found：资源临时移动，建议继续使用原URL。
- 304 Not Modified：资源未修改，可使用缓存版本。
-
4xx（客户端错误）
- 400 Bad Request：请求有语法错误或参数错误。
- 401 Unauthorized：请求未经授权，需身份认证。
- 403 Forbidden：服务器拒绝执行请求，权限不足。
- 404 Not Found：请求的资源不存在。
- 405 Method Not Allowed：请求的方法不被允许。
-
5xx（服务器错误）
- 500 Internal Server Error：服务器内部错误，无法处理请求。
- 502 Bad Gateway：服务器作为网关或代理时收到无效响应。
- 503 Service Unavailable：服务器暂时无法处理请求，可能是过载或维护。
- 504 Gateway Timeout：网关或代理未能在规定时间内响应请求。
HTTPS的工作流程
- TCP 三次同步握手
- 2、客户端验证服务器数字证书
- 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
- 4、SSL 安全加密隧道协商完成
- 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
HTTPS 如何保证安全?
SSL/TLS 握手过程
- 客户端发起请求：浏览器（客户端）向服务器发起连接请求，发送一个 ClientHello 消息，告知服务器客户端支持的加密算法等信息。
- 服务器响应：服务器返回一个 ServerHello 消息，选择加密算法，并发送其数字证书（包含服务器的公钥和证书链）。
- 证书验证：客户端验证服务器的数字证书，确保该证书是由可信的证书颁发机构（CA）签发的，且证书没有过期或被吊销。
- 生成共享密钥：一旦证书验证成功，客户端和服务器将进行密钥交换（使用公钥加密和私钥解密技术），生成一个对称密钥，用于后续的加密通信。
- 加密通信：客户端和服务器使用对称加密算法（如 AES）加密数据，确保数据在传输过程中的安全性。
加密算法
- 对称加密：客户端和服务器之间使用相同的密钥进行数据加密和解密。常见的对称加密算法包括 AES。
- 非对称加密：在握手过程中使用公钥加密数据，私钥解密数据。常见的非对称加密算法包括 RSA 和 ECC。
- 哈希算法：用于确保数据在传输过程中未被篡改。常见的哈希算法包括 SHA-256。
密钥管理
SSL/TLS 握手协议的核心在于密钥的交换与管理。在 HTTPS 中，服务器和客户端通过安全的方式共享对称密钥，确保后续通信的加密性和完整性。
HTTP 与 HTTPS 之间有何区别？
| HTTP | HTTPS | |
|---|---|---|
| 名称 | 超文本传输协议 | 超文本安全传输协议 |
| 端口 | 默认端口80 | 默认端口443 |
| 底层协议 | HTTP/1 和 HTTP/2 使用 TCP/IP。HTTP/3 使用 QUIC 协议 | 使用包含 SSL/TLS 的 HTTP/2，以进一步加密 HTTP 请求和响应 |
| 安全性 | 没有任何安全机制 | 通过 SSL/TLS 加密技术，提供身份验证、数据加密和数据完整性的保护，确保通信内容在传输过程中不被窃取或篡改。 |
| 证书 | 没有任何证书要求 | 使用 SSL/TLS 证书 来验证服务器的身份，确保连接的是合法的、受信任的服务器。证书由受信任的证书颁发机构（CA）签发。 |
| 性能 | 由于没有加密过程，性能上较为高效，传输速度较快。 | 需要通过加密和解密过程，性能相对较慢，但差距在现代硬件和优化下并不显著。 |
WebSocket和SSE有什么区别？
| WebSocket | SSE(Server-Sent Events) | |
|---|---|---|
| 通信方向 | 双向通信（服务器到客户端，客户端到服务器） | 单向通信（服务器到客户端） |
| 协议 | 使用HTTP协议 | 使用WebSocket协议（初始握手通过HTTP升级） |
| 连接 | 长链接 | 长链接 |
| 自动重连 | 需要手动实现 | 原生支持 |
| 适用场景 | 适合实时事件推送场景 | 适用于聊天应用、多人游戏等需要频繁双向通信的场景 |
| 加密版本 | wss:// | https:// |
| 数据格式 | 支持二进制和文本数据传输 | 只支持文本数据传输，并且服务器推送的数据通常是 UTF-8 编码的文本数据 |
常见的网络安全问题
- DDoS 攻击
- DNS 劫持
- SQL 注入
gRPC 和 REST API 的区别
负载均衡
CDN
OAuth2.0
JWT
API 限流
- 固定窗口限流：每秒 X 次请求
- 滑动窗口限流：基于时间滑动统计请求
- 令牌桶算法：每秒生成一定量的令牌，用户消耗令牌访问
- 漏桶算法：请求排队，控制流速
gRPC
4种请求模式
| 服务方法 | ||
|---|---|---|
| Unary RPC | 单项 RPC | 客户端发送一个请求给服务端，从服务端获取一个应答 |
| Server Streaming RPC | 服务端流式 RPC | 客户端发送一个请求给服务端，可获取一个数据流用来读取一系列消息。客户端从返回的数据流里一直读取直到没有更多消息为止。 |
| Client Streaming RPC | 客户端流式 RPC | 客户端用提供的一个数据流写入并发送一系列消息给服务端。一旦客户端完成消息写入，就等待服务端读取这些消息并返回应答。 |
| Bidirectional Streaming RPC | 双向流式 RPC | 两边都可以分别通过一个读写数据流来发送一系列消息。这两个数据流操作是相互独立的，所以客户端和服务端能按其希望的任意顺序读写 |
