【2023最新】计算机网络面试题【收藏持续更新】_计算机基础知识和计算机网络知识 面试题2023

你好，我是萝卜，我会在本篇文章持续更新关于计算机网络的面试题

最新内容更新日期：2023-04-11

基础

说一下计算机网络体系结构

网络体系结构一般有三种：ISO七层模型，TCP/IP四层模型和五层结构

ISO七层模型是理论上的网络通信模型，TCP/IP四层模型是实际上的网络通信模型，五层结构是为了介绍网络原理而折中的网络通信模型

由上至下说一下ISO七层模型和每层的作用

ISO七层模型由上至下是：

• 应用层：通过应用进程之间的交互来完成特定网络应用，应用层协议定义的是应用进程间通信和交互的规则

• 表示层：数据的表示、安全、压缩，确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取

• 会话层：建立、管理、终止会话，是用户应用程序和网络之间的接口

• 传输层：提供源端与目的端之间提供可靠的透明数据传输，传输层协议为不同主机上运行的进程提供逻辑通信

• 网络层：将网络地址翻译成对应的物理地址，实现不同网络之间的路径选择

• 数据链路层：在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路

• 物理层：建立、维护、断开物理连接

由上至下说一下TCP/IP四层模型每层的作用

TCP/IP四层模型由上至下是：

• 应用层：用来接收来自传输层的数据或者按不同应用要求与方式将数据传输至传输层

• 传输层：是使用者使用平台和计算机信息网内部数据结合的通道，可以实现数据传输与数据共享，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性

• 网络层：主要负责网络中数据包的传送等，主要解决主机到主机的通信问题

• 网络接口层：提供链路管理错误检测、对不同通信媒介有关信息细节问题进行有效处理等

讲一下ISO七层模型和TCP/IP四层模型中每一层对应的网络协议

TCP

TCP和UDP的概念及特点

TCP和UDP的区别？

TCP和UDP的使用场景有哪些？

TCP如何保证可靠性？

讲一下TCP三次握手

TCP三次握手

主动发起连接请求的一端称为客户，被动连接的一端称为服务器

连接建立前，服务器进程处于LISTEN(收听状态)，等待客户的连接请求

过程：

第一次握手：

客户端发送报文段SYN=1，seq=x给服务器

进程状态变化：客户端进程的状态进入SYN-SENT(同步已发送)状态

第二次握手:

服务器发送报文段SYN=1，ACK=1，seq=y，ack=x+1给客户端

服务器在本次握手时为该TCP连接分配缓存和变量

进程状态变化：服务器进程的状态进入SYN-RCVD(同步收到)状态

第三次握手：

客户端发送报文段ACK=1，seq=x+1，ack=y+1给服务器

客户端在本次握手时为该TCP连接分配缓存和变量

进程状态变化：

客户端进程的状态进入ESABLISHED(已建立连接)状态

完成第三次握手后，服务器进程的状态也进入ESABLISHED(已建立连接)状态，可以开始发送数据

为什么要三次握手？两次可以吗？

• 为了防止服务器端开启一些无用的连接增加服务器开销

首先我们要知道第三次握手的作用：是客户端告诉服务器能够收到服务器所传输的数据。

如果没有了第三次握手出现的结果：假如第二次握手的这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包，但是没有了第三次握手，服务器无法确定客户端是否收到了服务器所传输的数据，服务端就认为这个连接是可用的，端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。这样一来，就会有很多无效的连接端口白白地开着，导致资源的浪费

• 防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误

所以需要第三次握手来确认连接过程：

通过第三次握手的数据告诉服务端，客户端有没有收到服务器“第二次握手”时传过去的数据，以及这个连接的序号是不是有效的。若发送的这个数据是“收到且没有问题”的信息，接收后服务器就正常建立 TCP 连接，否则建立 TCP 连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

第三次握手可以携带数据吗？

可以携带数据，此时客户端已经处于ESTABLISHED(已建立连接)状态。对于客户端来说，它已经建立连接成功，并且确认服务端的接收和发送能力是正常的。

第一次握手可以携带数据吗？

不可以携带数据，第一次握手不能携带数据是出于安全的考虑，因为如果允许携带数据，攻击者每次在SYN报文中携带大量数据，就会导致服务端消耗更多的时间和空间去处理这些报文，会造成CPU和内存的消耗

那么四次握手可以吗？

三次握手已经足够建立可靠连接，没必要多进行一次握手花费更多时间建立连接

分别说一下三次握手中每一次没收到报文会发生什么情况？

第一次握手服务端未SYN报文：

服务端没有任何动作；客户端在一段时间内没有收到服务端发来的确认报文，等待一段时间后会重新发送SYN报文，如果仍然没有回应，会重复这个过程，直到发送次数超过最大重传次数限制，就会返回连接建立失败

第二次握手客户端未收到ACK报文：

客户端会继续重传，直到次数限制；而务端此时会阻塞在accept()处，等待客户端发送ACK报文

第三次握手服务端未收到ACK报文：

服务端同样会采用类似客户端的超时重传机制，如果重试次数超过限制，则accept()调用返回-1，服务端建立连接失败；而此时客户端认为自己已经建立连接成功，因此开始向服务端发送数据，但是服务端的accept()系统调用已经返回，此时不在监听状态，因此服务端接收到客户端发送来的数据时会发送RST报文给客户端，消除客户端单方面建立连接的状态

第二次握手传回了 ACK，为什么还要传回 SYN？

传回ACK是为了告诉客户端传来的数据已经接收无误

而传回SYN是为了告诉客户端，服务端响应的确实是客户端发送的报文

讲一下TCP四次挥手

tcp连接释放的过程称为tcp的四次挥手

第一次挥手：客户端发送释放连接报文FIN=1，seq=u，发送完毕后，客户端进入 FIN_WAIT_1 (终止等待1)状态。

第二次挥手：服务端发送确认报文ACK=1，ack=u+1,seq =v，发送完毕后，服务器端进入 CLOSE_WAIT (关闭等待) 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 (终止等待2)状态。

第三次挥手：在服务器已经没有要向客户机发送的数据后就会进行第三次挥手，服务端发送释放连接报文FIN=1，ACK1,seq=w,ack=u+1(序号w说明在半关闭状态服务器可能又发送了一些数据)，发送完毕后，服务器端进入 LAST_ACK(最后确认) 状态，等待来自客户端的最后一个 ACK

第四次挥手：客户端发送确认报文ACK=1，seq=u+1,ack=w+1，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime，MSL约为60s）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED(连接关闭) 状态。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED(连接关闭) 状态。

为什么要四次挥手？三次可以吗？

关闭连接时，第一次挥手客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文(第二次挥手)，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文(第三次挥手)给客户端来表示同意现在关闭连接。你发的FIN报文我收到了，只有等到我服务器所有的报文都发送完了，我才能发送FIN报文，因此服务端的ACK报文和FIN报文不能一起发送，故需要四次挥手。

TCP粘包是什么？怎么解决？

讲一下TCP重传机制

tcp重传机制包括超时重传、快速重传、带选择确认的重传(SACK)、重复SACK四种

超时重传：

超时重传是tcp协议保证数据可靠性的一个重要机制

原理是在发送某一个数据以后开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，就会重新发送数据，直到发送成功为止

快速重传：

快速重传不以时间为驱动，以数据驱动，基于接收端的反馈信息来引发重传

快速重传流程如下：

• 第⼀份 Seq1 先送到了，于是就 Ack 回 2；

• 结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；

• 后⾯的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；

• 发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。

• 最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。

但是快速重传只解决了超时时间的问题，但是它还存在一个问题，那就是重传的时候是重传之前的一个，还是重传所有的问题

带选择确认的重传(SACK)：

TCP 提供了带选择确认的重传（即 SACK，Selective Acknowledgment）以解决应该重传多少个包的问题。

SACK机制就是，在快速重传的基础上，接收方返回最近收到报文段的序列号范围，这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包。

流程如下：

发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发快速重发机制，通过 SACK 信息发现只有200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重发。

重复SACK：

D-SACK，英文是 Duplicate SACK，是在 SACK 的基础上做了一些扩展，主要用来告诉发送方，有哪些数据包，自己重复接受了。

DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。

流程如下：

• 接收⽅发给发送⽅的两个 ACK 确认应答都丢失了，所以发送⽅超时后，重传第⼀个数据包(100-499)

• 于是接收⽅发现数据是重复收到的，于是回了⼀个 SACK = 100-500，告诉「发送⽅」 100-500的数据早已被接收了，因为 ACK 都到了1000 了，已经意味着1000之前的所有数据都已收到，所以这个SACK 就代表着 D-SACK 。这样发送⽅就知道了，数据没有丢，是接收⽅的 ACK 确认报⽂丢了。

超时重传中的超时重传时间应该设置多大？

讲一下TCP拥塞控制

讲一下TCP流量控制

讲一下TCP可靠传输机制

UDP

IP

HTTP

HTTP请求报文

HTTP响应报文

HTTP状态码有哪些？

HTTP请求方法有哪些？

GET和POST的区别？

HTTPS

其他