面试计算机网络框架八股文十问十答第七期

面试计算机网络框架八股文十问十答第七期

作者:程序员小白条个人博客

相信看了本文后,对你的面试是有一定帮助的!关注专栏后就能收到持续更新!

⭐点赞⭐收藏⭐不迷路!⭐

1)UDP协议为什么不可靠?

UDP(用户数据报协议)是一种无连接的、不可靠的传输协议。它的不可靠性主要体现在以下几个方面:

  • 无连接性: UDP 不需要在发送数据之前建立连接,也不维护连接状态,因此不会进行握手和维持连接的开销。这使得 UDP 更加轻量级,但也使得它无法保证数据的可靠传输。
  • 不保证数据的到达顺序: 由于 UDP 不会对数据包进行排序和重组,因此发送的数据包的到达顺序不一定与发送顺序一致。在网络中,数据包可能会因为不同的路由和网络拥塞情况而以不同的顺序到达目的地。
  • 不提供重传机制: UDP 协议本身不提供重传机制。如果一个数据包在传输过程中丢失,UDP 协议不会负责重新发送该数据包,而是由应用层自行处理丢失的情况。

因此,尽管 UDP 在一些对实时性要求高、数据丢失对应用影响不大的场景下表现出色,但在对数据完整性和可靠性要求较高的场景下,通常会选择使用 TCP 协议。

2)TCP的重传机制

TCP(传输控制协议)是一种面向连接的、可靠的传输协议。TCP 通过以下机制来保证数据的可靠传输:

  • 序列号和确认应答: TCP 在发送的数据包中会包含序列号,接收方收到数据后会发送确认应答,告知发送方已经收到了哪些数据。如果发送方在合理的超时时间内没有收到确认应答,就会认为数据丢失,进行重传。
  • 超时重传: 如果发送方在一定时间内没有收到确认应答,就会重新发送相同的数据包。TCP 会动态调整重传的超时时间,以适应网络的变化。
  • 快速重传: 如果发送方收到了对同一数据包的三个重复的确认应答,就会认为接收方已经丢失了后续的数据,立即进行快速重传,而不必等待超时时间到期。

3)TCP的拥塞控制机制

TCP 的拥塞控制是为了避免过多的数据注入到网络中,导致网络拥塞,从而影响网络性能。TCP 的拥塞控制主要包括以下几个机制:

  • 慢启动: 发送方在连接刚建立时,会以指数增长的速率增加发送窗口大小,以快速填满网络的带宽。
  • 拥塞避免: 一旦发送方开始遇到丢包,就会进入拥塞避免阶段,发送窗口大小会线性增长,而不是指数增长,以降低发送速率。
  • 快速重传和快速恢复: 当发送方收到对同一数据包的三个重复的确认应答时,会触发快速重传和快速恢复机制,以快速调整发送窗口大小,避免继续注入更多的数据到网络中。

通过这些拥塞控制机制,TCP 能够在一定程度上适应网络的拥塞情况,保证网络的稳定性和公平性。

4)TCP的流量控制机制

TCP 的流量控制是为了防止发送方发送过多的数据,导致接收方无法处理。流量控制主要通过滑动窗口(Sliding Window)机制来实现:

  • 接收窗口(rwnd): 接收方在通信的过程中会通知发送方自己当前的接收窗口大小,即能够接收的数据量。发送方根据这个信息来控制发送的数据量,保证不会超过接收方的处理能力。
  • 滑动窗口: 发送方维护一个发送窗口,表示可以发送但还未收到确认的数据段的范围。滑动窗口的大小受到接收方通知的接收窗口大小和网络的实际情况的影响。

通过动态调整滑动窗口的大小,TCP 实现了流量控制,确保在通信过程中不会因为发送方速度过快而导致接收方无法处理。

5)TCP的可靠传输机制

TCP 的可靠传输机制主要包括以下几个方面:

  • 序列号和确认应答: 发送方会为每个数据包分配一个序列号,接收方通过确认应答来告知发送方已经正确接收到数据。如果发送方在一定时间内未收到确认应答,会进行重传。
  • 超时重传: 如果发送方在合理的超时时间内未收到确认应答,会认为数据包丢失,进行超时重传。
  • 快速重传和快速恢复: 当发送方收到对同一数据包的三个重复的确认应答时,会触发快速重传和快速恢复机制,以快速调整发送窗口大小。
  • 选择性重传: 发送方能够选择性地重传丢失的数据包,而不是重新传输所有的数据。

这些机制使得 TCP 在不可靠的网络环境中能够保证数据的可靠传输。

6)TCP的三次握手和四次挥手

TCP 的连接建立和断开分别通过三次握手和四次挥手来完成:

三次握手(Connection Establishment):

  1. 客户端发送 SYN: 客户端发送一个带有 SYN(同步)标志的数据包,表示请求建立连接。
  2. 服务端发送 SYN + ACK: 服务端收到客户端的请求后,回复一个带有 SYN 和 ACK(确认)标志的数据包,表示同意建立连接。
  3. 客户端发送 ACK: 客户端收到服务端的确认后,发送一个带有 ACK 标志的数据包,表示连接建立完成。

四次挥手(Connection Termination):

  1. 客户端发送 FIN: 客户端发送一个带有 FIN(结束)标志的数据包,表示要关闭连接。
  2. 服务端发送 ACK: 服务端收到客户端的关闭请求后,发送一个带有 ACK 标志的数据包,表示接收到关闭请求。
  3. 服务端发送 FIN: 服务端发送一个带有 FIN 标志的数据包,表示服务端也准备关闭连接。
  4. 客户端发送 ACK: 客户端收到服务端的关闭请求后,发送一个带有 ACK 标志的数据包,表示确认关闭。此时连接彻底关闭。

这样的握手和挥手机制确保了双方在建立和关闭连接时的可靠性和同步性。

7)TCP粘包是怎么回事,如何处理?

TCP粘包是指发送方发送的若干小数据包到达接收方时,接收方可能会将它们合并成一个大的数据包,从而导致接收方处理时难以区分原始的数据边界。这可能会引发一些问题,比如数据解析错误或应用层处理混乱。

原因:

  1. 缓冲机制: 操作系统或中间网络设备的缓冲机制可能会导致多个小数据包在传输过程中被合并成一个大的数据包。
  2. 发送速率: 发送方连续发送数据包的速率比接收方处理的速率快,导致多个数据包在传输过程中组成一个大的数据包。

处理方法:

  1. 消息长度标识: 在传输的数据中增加消息长度的信息,接收方通过解析长度信息来拆分数据。
  2. 特殊字符标识: 在消息之间增加特殊字符标识,接收方根据特殊字符来切分数据。
  3. 定长消息: 固定长度的消息,不足长度时用空格或其他填充。
  4. 使用消息边界标记: 在数据包的开头或结尾添加标记表示消息的开始或结束。
  5. 应用层协议设计: 在应用层设计协议时,可以采用更复杂的协议规定来避免粘包问题。

8)为什么udp不会粘包?

UDP是无连接的、不可靠的协议,它对数据包的传输不做任何拆分或合并的处理,因此不存在TCP粘包的问题。每个UDP数据包都是独立的,不会受到底层协议的影响而被合并,接收方能够按照发送方发送的数据包一一接收。

UDP的简单性和无连接性使得它不会进行复杂的缓冲和组包操作,也就不会出现TCP粘包的情况。然而,正因为UDP不保证可靠传输,应用层需要自行处理丢包、重复和顺序等问题。

9)对 WebSocket 的理解

WebSocket是一种在单个TCP连接上进行全双工通信的协议,它允许客户端和服务器之间进行实时、双向的数据传输。相比于传统的HTTP协议,WebSocket的优势在于降低了通信的延迟,提高了效率。

特点和优势:

  • 全双工通信: 可以同时在同一个连接上进行双向通信,服务器可以向客户端推送数据,而不需要等待客户端的请求。
  • 低延迟: 由于建立一次连接后可以持久存在,避免了HTTP协议中频繁的连接建立和断开,降低了通信的延迟。
  • 轻量级: WebSocket协议的头部较小,通信时的数据帧相对较小,减少了网络传输的开销。
  • 跨域通信: 支持跨域通信,通过一定的握手过程建立连接,使得客户端和服务器可以跨域进行实时通信。

10)即时通讯的实现:短轮询、长轮询、SSE 和 WebSocket 间的区别?

即时通讯的实现方式有多种,其中常见的包括短轮询(Short Polling)、长轮询(Long Polling)、SSE(Server-Sent Events)和WebSocket。

  1. 短轮询(Short Polling):
    • 客户端定期发送HTTP请求询问是否有新消息。
    • 服务器响应时,返回当前可用的消息。
    • 缺点:频繁的HTTP请求可能造成不必要的开销,延迟高。
  2. 长轮询(Long Polling):
    • 客户端发送HTTP请求到服务器,服务器保持连接打开,直到有新消息才响应给客户端。
    • 客户端收到响应后立即再次发起请求。
    • 缺点:仍然存在较高的延迟,但相较于短轮询减少了请求的频率。
  3. SSE(Server-Sent Events):
    • 使用单个HTTP连接,服务器可以主动推送数据给客户端。
    • 基于事件流的机制,通过EventSource对象在客户端接收服务器的推送。
    • 缺点:仅支持单向通信,不适合需要双向通信的场景。
  4. WebSocket:
    • 建立在单个TCP连接上,支持全双工通信。
    • 通过握手过程建立连接,之后可以双向发送消息。
    • 优点:低延迟,支持双向通信,适用于实时性要求高的场景。

总的来说,短轮询和长轮询通过HTTP请求,存在较高的延迟和开销;SSE是基于HTTP的单向通信,适用于服务器向客户端推送数据;WebSocket是全双工通信,延迟低,适用于实时性要求高的即时通讯场景。选择哪种方式取决于具体的需求和场景。

开源项目地址:https://gitee.com/falle22222n-leaves/vue_-book-manage-system

已 300 + Star!

⭐点赞⭐收藏⭐不迷路!⭐

相关推荐
晴殇i2 小时前
揭秘JavaScript中那些“不冒泡”的DOM事件
前端·javascript·面试
绝无仅有2 小时前
Redis过期删除与内存淘汰策略详解
后端·面试·架构
绝无仅有2 小时前
Redis大Key问题排查与解决方案全解析
后端·面试·架构
AAA梅狸猫3 小时前
Looper.loop() 循环机制
面试
AAA梅狸猫3 小时前
Handler基本概念
面试
Wect4 小时前
浏览器缓存机制
前端·面试·浏览器
掘金安东尼4 小时前
Fun with TypeScript Generics:玩转 TS 泛型
前端·javascript·面试
掘金安东尼4 小时前
Next.js 企业级落地
前端·javascript·面试
掘金安东尼4 小时前
React 性能优化完全指南 2026
前端·javascript·面试
掘金安东尼16 小时前
让 JavaScript 更容易「善后」的新能力
前端·javascript·面试