计算机网络高频面试题

1、介绍一下ISO七层网络模型？

ISO七层网络模型（OSI参考模型）是国际标准化组织（ISO）提出的网络通信框架，将网络通信划分为七个逻辑层次，每层提供特定的服务并与相邻层交互。其核心目的是实现不同厂商设备的互操作性，并简化网络通信的设计与故障排查。

（1）OSI七层模型的结构：

• 物理层（Physical Layer）

功能：负责传输原始比特流，定义电压、接口等物理特性。
关键技术：双绞线、光纤、无线信号（如Wi-Fi）、电压标准（如RS-232）。
设备：中继器（Repeater）、集线器（Hub）。
传输单位：比特（Bit）。

• 数据链路层（Data Link Layer）

功能：将比特流组织成帧，实现点到点的可靠传输，进行差错检测（如CRC校验）和流量控制。
子层：
        MAC子层：管理介质访问（如以太网的MAC地址）。
        LLC子层：提供逻辑链路控制，处理帧的同步和错误恢复。
协议：以太网（IEEE 802.3）、PPP、HDLC。
设备：交换机（Switch）、网桥（Bridge）。
传输单位：帧（Frame）。

• 网络层（Network Layer）

功能：负责逻辑寻址（如IP地址）和路由选择，将数据包从源主机转发到目标主机。
核心任务：
        路由协议（如OSPF、BGP）。
        分片与重组（如IPv4的MTU处理）。
协议：IP、ICMP、IGMP。
设备：路由器（Router）、三层交换机。
传输单位：数据包（Packet）。

• 传输层（Transport Layer）

功能：提供端到端的可靠或不可靠数据传输，管理流量控制和错误恢复。
核心协议：
        TCP：面向连接的可靠传输（如HTTP、FTP）。
        UDP：无连接的低开销传输（如DNS、VoIP）。
传输单位：数据段（Segment for TCP，Datagram for UDP）。

• 会话层（Session Layer）

功能：建立、管理和终止会话（如用户登录），支持对话控制和同步点（如断点续传）。
协议：RPC（远程过程调用）、NetBIOS。
实际应用：数据库连接管理、视频会议的会话控制。

• 表示层（Presentation Layer）

功能：处理数据格式转换、加密/解密、压缩/解压，确保数据在不同系统间的兼容性。
协议：SSL/TLS（加密）、JPEG（图像编码）、ASCII（字符编码）。
实际应用：跨平台文件共享（如PDF格式）、HTTPS的加密传输。

• 应用层（Application Layer）

功能：直接为用户提供网络服务，如文件传输、电子邮件、网页浏览。
协议：HTTP、FTP、SMTP、DNS、Telnet。
实际应用：Web浏览器（HTTP）、电子邮件客户端（SMTP/POP3）。
 

（2）OSI模型的核心价值:
标准化：为不同厂商的设备和协议提供统一的框架，促进互操作性。
模块化设计：各层独立实现功能，便于技术迭代和故障隔离。
简化复杂性：通过分层抽象，降低网络通信的设计和维护难度。
理论指导：为实际网络协议（如TCP/IP）的设计提供参考。

（3）实际应用示例

• 数据传输过程：
  当用户通过浏览器访问网页时，数据从应用层（HTTP请求）向下传递，经过传输层（TCP分段）、网络层（IP寻址）、数据链路层（以太网帧封装），最终通过物理层（网线/光信号）传输到目标服务器。
• 故障排查：
  如果网络不通，可逐层排查：物理层（网线是否损坏）、数据链路层（MAC地址冲突）、网络层（IP路由问题）、传输层（端口阻塞）等。

2、TCP协议和UDP协议有什么区别？

TCP 面向连接的、可靠的、基于字节流的传输层协议。 提供有序、无丢失、无重复的数据传输。 常用于需要高可靠性的场景，如网页浏览、文件传输、电子邮件等

UDP 无连接的、不可靠的、面向数据报的传输层协议。 不保证数据的有序性、完整性或交付。 常用于对实时性要求高但可容忍部分丢包的场景，如视频流、在线游戏、实时通信等。

详细区别可总结为：

✅一、连接方式不同：

TCP：是面向连接的协议。在通信之前，需要在通信双方之间建立一条连接，就像打电话一样，要先拨号建立连接才能通话。这个连接的建立过程包括三次握手，确保连接的可靠性。连接后，数据传输过程中有确认、重传、排序等机制，保证数据的准确无误传输。

UDP：是无连接的协议。通信双方不需要事先建立连接，就像发广播一样，直接将数据发送出去，不管对方是否准备好接收。这种方式传输速度快，但可靠性相对低。

✅二、可靠性不同

TCP：具有高度可靠性。通过序列号、确认应答、超时重传等机制来确保数据的准确传输。如果发送方发送的数据没有被接收方正确接收，发送方会在一定时间后重新发送数据，直到接收方确认收到为止。此外，TCP 还会对数据进行排序，确保接收方接收到的数据顺序与发送方发送的顺序一致。

支持流量控制（滑动窗口）和拥塞控制，避免网络过载‌。

UDP：可靠性较低。它不提供确认、重传等机制，数据发送后无法确定对方是否收到，也不保证数据的顺序。因此，对数据准确性要求不高，但对速度要求较高的场景下，如实时视频、音频传输等，UDP 更为适用。

✅三、传输效率不同

TCP：传输效率相对较低；TCP由于其连接建立和维护的开销以及可靠性机制，传输效率相对较低。在数据传输过程中，需要进行确认、重传等，这会增加一定的延迟。

UDP：传输效率高。不需要建立连接，也没有复杂的可靠性机制，所以数据可以快速地发送出去。在一些对实时性要求很高的应用中，如在线游戏、实时视频会议等，它的高效性可以满足应用的需求。

✅四、报文格式不同

•  TCP：报文头相对较长，至少包含 20 个字节。其包括源端口号、目的端口号、序列号、确认号等信息。这些信息用于建立连接、保证数据传输的可靠性和控制流量等。

UDP：报文头只有 8 个字节，非常简洁。包含源端口号、目的端口号、长度和校验等。由于报文头短，在传输数据时的额外开销小。

五、数据传输方式‌

• ‌TCP‌：‌面向字节流‌。数据被拆分为多个分段传输，接收端按序列号重组，确保连续性‌。
• ‌UDP‌：‌面向报文‌。每个数据包独立发送，大小受限（≤64KB），接收端直接处理整包‌。

✅六、应用场景不同

TCP：适用于对数据准确性要求高的场景，如文件传输、电子邮件、网页浏览等。在这些应用中，数据的完整性和正确性至关重要，即使传输速度稍慢一些也可以接受。

UDP：适用于对实时性要求高、对数据准确性要求相对较低的场景，如实时视频、音频传输、在线游戏等。在这些应用中，快速的数据传输和低延迟比数据的准确性更为重要。

总结：‌

• ‌TCP‌：牺牲速度换可靠性，适合关键数据传递。
• ‌UDP‌：牺牲可靠性换效率，适合实时性与灵活性优先的场景。
  两者本质是‌可靠性‌与‌速度‌的权衡，而非替代关系‌

3、如果让你设计TCP协议你怎么设计？

设计一个新的TCP协议需要在保留其核心优势的基础上，针对现有问题进行优化，并适应现代网络环境的新需求。以下是基于现有TCP特性和当前网络趋势的设计思路：

1. 核心目标：

• 可靠性：确保数据完整、有序传输。
• 高效性：减少延迟，提升带宽利用率。
• 灵活性：适应多样化的网络场景（如高延迟、高丢包、移动网络）。
• 扩展性：支持未来需求（如多路径传输、安全集成）。

2. 连接管理优化：

2.1 快速连接建立

• 零RTT（Round-Trip Time）握手：
  • 借鉴QUIC协议思想，允许客户端在首次握手后缓存服务器参数，后续连接可直接发送数据（需验证安全性）。
  • 示例：客户端 → 服务端（携带加密参数）→ 直接发送数据（无需等待SYN-ACK）。
• 多阶段握手：
  • 对高延迟网络（如卫星通信），采用动态调整的握手流程（如减少握手次数或增加并行握手）。

2.2 智能连接终止

• 半关闭状态优化：
  • 引入“半关闭超时”机制，避免FIN_WAIT_2状态的资源浪费。
  • 自动检测长时间未响应的连接，强制释放（如TIME_WAIT缩短为1MSL）。

3. 可靠性增强

3.1 动态确认机制

• 混合确认模式：
  • 对关键数据（如金融交易）强制使用ACK确认。
  • 对实时数据（如视频流）允许部分丢包，仅对关键帧进行确认。
• 前向纠错（FEC）：
  • 在数据包中嵌入冗余信息，接收方无需重传即可恢复少量丢包（适用于高丢包率场景）。

3.2 智能重传策略

• 基于机器学习的重传决策：
  • 根据历史网络状态（如延迟、丢包率）动态调整重传超时时间（RTO）。
  • 区分“网络拥塞丢包”和“随机丢包”，仅对前者触发拥塞控制。

4. 流量控制与拥塞控制

4.1 滑动窗口改进

• 动态窗口调整：
  • 结合实时带宽探测（如基于BBR的瓶颈带宽计算），动态调整窗口大小。
  • 支持突发流量（如大文件传输）的临时窗口扩容。

4.2 拥塞控制算法

• 多算法自适应：
  • 根据网络类型自动切换拥塞控制算法（如BBR用于高带宽场景，CUBIC用于传统网络）。
  • 集成AI驱动的拥塞预测模型，提前调整发送速率。

4.3 多路径支持（MPTCP）

• 路径聚合：
  • 同时利用多个网络接口（如Wi-Fi + 4G）传输数据，提升带宽利用率。
  • 动态分配数据流到最优路径（基于实时延迟和丢包率）。

5. 安全性增强

5.1 内置加密

• 协议层加密：
  • 在TCP头部集成轻量级加密字段，减少TLS握手开销（类似QUIC的加密握手）。
  • 默认启用端到端加密，避免中间人攻击。

5.2 抗DDoS攻击

• 速率限制与身份验证：
  • 服务器端对连接请求进行速率限制，结合IP信誉机制过滤恶意流量。
  • 引入轻量级身份验证（如基于公钥的握手）。

6. 适应新兴场景

6.1 低功耗设备优化

• 节能模式：
  • 为物联网设备设计“低功耗模式”，减少ACK频率（如批量确认）。
  • 支持断线续传，避免频繁重连。

6.2 云原生支持

• 容器化连接管理：
  • 为微服务架构提供轻量级连接复用（如共享TCP连接池）。
  • 与SDN/NFV集成，动态调整路由策略。

7. 协议扩展性

7.1 可扩展头部设计

• 可变长度选项字段：
  • 支持动态添加新功能（如QoS标记、流量优先级）。
  • 使用压缩算法减少头部开销（如ROHC）。

7.2 向后兼容性

• 版本协商机制：
  • 在握手阶段协商协议版本，兼容旧版TCP实现。
  • 提供降级模式（如回退到传统TCP）。

8. 实际应用示例

• 场景1：实时视频会议
  • 使用FEC恢复少量丢包，动态调整窗口大小以适应带宽波动。
  • 对关键帧强制确认，普通帧允许丢弃。
• 场景2：物联网传感器网络
  • 启用低功耗模式，减少ACK频率，支持断线续传。
  • 使用轻量级加密保护传感器数据。

9. 验证与测试

• 仿真工具：
  • 使用NS-3或Mininet模拟高延迟、高丢包场景。
• 真实部署：
  • 在边缘计算节点部署原型，测试多路径传输性能。
• 指标监控：
  • 关键指标：吞吐量、延迟、丢包率、连接建立时间。

总结：

新设计的TCP协议需在可靠性、效率、安全性和扩展性之间取得平衡。通过引入AI驱动的动态策略、多路径传输、内置加密等技术，可以更好地适应现代网络需求。同时，需通过严格测试验证其在实际环境中的表现，并确保与现有生态的兼容性。

4、介绍一下TCP三次握手/四次挥手，为什么要进行三次握手？二次或四次不行吗？

（1）三次握手：

 

第一次握手：

客户端向服务器发出连接请求报文，这时报文首部中的同部位SYN=1，同时随机生成初始序列号 seq=x，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。这个三次握手中的开始。表示客户端想要和服务端建立连接。

第二次握手：

TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己随机初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。这个报文带有SYN(建立连接)和ACK(确认)标志，询问客户端是否准备好。

第三次握手：

TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。

TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。这里客户端表示我已经准备好。

三次握手完成之后，TCP连接就正式建立起来了，双方可以开始进行数据的可靠传输。三次握手的目的是确保双方的初始序号和确认号的同步，并验证双方的可达性。通过这个过程，TCP可以建立一个可靠的双向通信通道，在后续的数据传输中保证数据的可靠性和顺序性。

（2）四次挥手：

 

第一次挥手：

TCP发送一个FIN(结束)，用来关闭客户到服务端的连接。

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），

此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

第二次挥手：

服务端收到这个FIN，他发回一个ACK(确认)，确认收到序号为收到序号+1，和SYN一样，一个FIN将占用一个序号。

服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。

TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。

这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

第三次挥手：

服务端发送一个FIN(结束)到客户端，服务端关闭客户端的连接。

服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据

假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手：

客户端发送ACK(确认)报文确认，并将确认的序号+1，这样关闭完成。

客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。

注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

（3）为什么一定要进行三次握手？

①确认双方的收发能力；

第一次握手，客户端发送请求，服务端能收到，表明服务端接收能力正常；第二次握手，服务端回应，客户端能收到，表明客户端接收和服务端发送能力正常；第三次握手，客户端再次回应，服务端能收到，表明服务端接收和客户端发送能力正常。通过三次握手，能够全面确认双方的发送和接收能力都没有问题。例如，如果只有两次握手，客户端发送请求后服务端回应，此时服务端只能确认自己的接收和发送以及客户端的发送能力正常，但无法确定客户端是否能成功接收服务端的回应，也就不能确认客户端的接收能力。

②防止已失效的连接请求报文突然传送到服务端；

网络中可能存在延迟的数据包。如果采用两次握手，服务端收到一个失效的连接请求后立即建立连接，可能会造成错误。而三次握手时，客户端再次确认，服务端就可以判断这个请求是否是有效的。假设一种情况，客户端发送的连接请求在网络中滞留，客户端超时后重新发送请求并完成连接。若此时之前滞留的请求到达服务端，服务端会误以为是新的连接请求并建立连接。但由于客户端不会响应，就会造成服务端资源的浪费。通过三次握手可以避免这种情况。

③同步初始序列号；

三次握手可以让双方协商并确定初始序列号，为后续按序传输数据做准备。

5、为什么在释放链接的时候客户端要等待2MSL的时间才关闭链接？

一是为了保证客户端发送的最后一个ACK报文段能够到达服务器端，确保服务端能正常进入CLOSED状态。服务端在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文。

二是为了避免新旧连接混淆。清除旧连接的残留数据，防止其干扰新连接。由于网络滞留，客户端可能发送了多次请求建立连接的请求，经过时间2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

  

6、滑动窗口和拥塞避免机制了解吗？

 

• 滑动窗口机制（流量控制）

        滑动窗口的核心目标是保护接收方不被淹没，即根据接收方的处理能力动态调整发送方的数据发送速率。

• 拥塞避免机制（网络保护）

        拥塞避免的核心目标是保护网络不被过载，通过动态调整发送速率，避免网络拥塞导致的丢包和延迟。

7、OSI模型与TCP/IP模型的对比？

OSI模型	TCP/IP模型
七层（物理层→应用层）	四层（网络接口层→应用层）
理论化框架，侧重概念分层	实用模型，直接指导协议实现
包含独立的会话层、表示层	会话层、表示层功能被合并到应用层
早期主要用于标准化，实际应用较少	广泛应用于现代互联网（如IP、TCP、HTTP）