你好，我是萝卜，我会在本篇文章持续更新关于计算机网络的面试题
最新内容更新日期：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报文，就会重新发送数据，直到发送成功为止
快速重传：
快速重传不以时间为驱动，以数据驱动，基于接收端的反馈信息来引发重传
快速重传流程如下：
但是快速重传只解决了超时时间的问题，但是它还存在一个问题，那就是重传的时候是重传之前的一个，还是重传所有的问题
带选择确认的重传(SACK)：
TCP 提供了带选择确认的重传（即 SACK，Selective Acknowledgment）以解决应该重传多少个包的问题。
SACK机制就是，在快速重传的基础上，接收方返回最近收到报文段的序列号范围，这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包。
流程如下：
发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发快速重发机制，通过 SACK 信息发现只有200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重发。
重复SACK：
D-SACK，英文是 Duplicate SACK，是在 SACK 的基础上做了一些扩展，主要用来告诉发送方，有哪些数据包，自己重复接受了。
DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。
流程如下：
超时重传中的超时重传时间应该设置多大？
讲一下TCP拥塞控制
讲一下TCP流量控制
讲一下TCP可靠传输机制
UDP
IP
HTTP
HTTP请求报文
HTTP响应报文
HTTP状态码有哪些？
HTTP请求方法有哪些？
GET和POST的区别？
HTTPS
其他
