计算机网络面试题

参考：小林Coding-图解计网

必备基础知识点

（一）TCP/IP网络模型和标准ISO网络模型

1，TCP/IP详解-各层使用到的协议

对应的数据包的结构 ：

?2，ISO七层模型

3，TCP/IP和ISO的对比

主要特定是：

? ? ? ? TCP/IP的应用层可以拆分出ISO的：会话层、表示层、应用层

? ? ? ? 网络接口层可以拆分：物理层和数据链路层

HTTP

1，HTTP是什么？

中文名称：超文本传输协议

面试中，可以根据中文名拆分出名词，来分别解析，例如:

HTTP是一个在计算机世界里专门在{两点}之间【传输】文字、图片、音频和视频等【超文本】数据的约定和规范【协议】

2，HTTP中常见的状态码

?3，HTTP缓存实现有什么方式？

两种，都是本地缓存，在客户端进行重复请求时，直接使用本地缓存，提高速度

1. 强制缓存
2. 协商缓存

解释：

什么是强制缓存？

什么是协商缓存？

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是?304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

下面是使用协商缓存的请求流程图：

?

4，HTTP/1.1的特点

1，三个优点

1. 简单

HTTP 基本的报文格式就是?header + body，头部信息也是?key-value?简单文本的形式，易于理解，降低了学习和使用的门槛。

2. 灵活和易于扩展

HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

同时 HTTP 由于是工作在应用层（?OSI?第七层），则它下层可以随意变化，比如：

• HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
• HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议。

3. 应用广泛和跨平台

互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

2，三个缺点

HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

1. 无状态双刃剑

无状态好处：服务器不用去记录HTTP的状态，即无需资源去记录，可以减轻服务器的负担

无状态坏处：服务器没有记忆力能力，则完成和客户端的关联操作会麻烦，需要另外一些手段

因为HTTP是无状态的，所以需要一些手段去解决这个问题，那就是：cookie技术

Cookie?通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了。

2. 明文传输双刃剑

明文意味着在传输过程中的信息，是可方便阅读的，比如 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。

但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。

总结：

利于网络调试，但是不安全

3. 不安全

HTTP 比较严重的缺点就是不安全：

• 通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
• 不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
• 无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

5，HTTP和HTTPS的不同点

• HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

• HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

• 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

6，HTTP存在的三个风险

HTTP 由于是明文传输，所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险，比如冒充淘宝网站，用户钱容易没。

?7，HTTPS对HTTP风险的解决方案

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

HTTPS是如何解决三个风险的呢？用到了什么技术呢？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。?

采用「混合加密」的方式的原因：

• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

非对称加密：包含私钥和公钥

非对称加密两个流程和两个作用：

流程的不同，意味着目的也不相同：

• 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
• 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。

所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

5，Get和Post

1，Get和Post的区别

1. 根据 RFC 规范，GET 的语义是从服务器获取指定的资源
2. 根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理

2，GET 和 POST 方法都是安全和幂等的吗？

先说明下安全和幂等的概念：

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

如果从 RFC 规范定义的语义来看：

• GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。
• POST?因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

此外：Put和Delete也都是幂等的

1. get：获取资源 【幂等】
2. post：创建资源，【不幂等】每次请求都会创建新的资源或执行不同的操作
3. put：更新资源【幂等】
4. Delete：删除资源【幂等】

3，Get请求可以携带body（请求体）?

RFC （Request for Comments）规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。

另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。

?总结：get和post都是请求，即数据包结构是一致的【url路径都可以放参数，也可以在请求体中防请求数据】，只是遵守RFC规范或Resful风格，导致的不同而已。

TCP

（一）TCP的基本知识

1，TCP头格式有哪些？

有红色箭头的都是比较重要的字段

注意：传输层的协议发送出的数据包，不管TCP还是UDP，其都不包含任何IP地址相关信息，因为该信息在网络层才会在数据包头添加上去

序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。

确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。

控制位：

• ACK：（acknowledgement确认）该位为?1?时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的?SYN?包之外该位必须设置为?1?。
• RST：（reset重置）该位为?1?时，表示 TCP 连接中出现异常必须强制断开连接。
• SYN：（synchronize同步）该位为?1?时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
• FIN：（finish完成）该位为?1?时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换?FIN?位为 1 的 TCP 段。

2，为什么需要 TCP 协议？ TCP 工作在哪一层？?

IP?层（网络层）是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。

?因为 TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。

3，TCP的定义和特点

定义：TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

特点：

• 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；

• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；

• 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

4，什么是一个TCP连接？

我们来看看 RFC 793 是如何定义「连接」的：

Connections: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.

简单来说就是，用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括 Socket、序列号和窗口大小称为连接。

所以我们可以知道，建立一个 TCP 连接是需要客户端与服务端达成上述三个信息的共识。

• Socket：由 IP 地址和端口号组成
• 序列号：用来解决乱序问题等
• 窗口大小：用来做流量控制

5，UDP 和 TCP 有什么区别呢？分别的应用场景是？

UDP 不提供复杂的控制机制，利用 IP 提供面向「无连接」的通信服务。

UDP 协议真的非常简，头部只有?8?个字节（64 位），UDP 的头部格式如下：

• 目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。
• 包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
• 校验和：校验和是为了提供可靠的 UDP 首部和数据而设计，防止收到在网络传输中受损的 UDP 包。

?TCP和UDP不同点：

1. 连接

• TCP 是面向连接的传输层协议，传输数据前先要建立连接。
• UDP 是不需要连接，即刻传输数据。

2. 服务对象

• TCP 是一对一的两点服务，即一条连接只有两个端点。
• UDP 支持一对一、一对多、多对多的交互通信

3. 可靠性

• TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按序到达。
• UDP 是尽最大努力交付，不保证可靠交付数据。但是我们可以基于 UDP 传输协议实现一个可靠的传输协议，比如 QUIC 协议，具体可以参见这篇文章：如何基于 UDP 协议实现可靠传输？(opens new window)

4. 拥塞控制、流量控制

• TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
• UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

5. 首部开销

• TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是?20?个字节，如果使用了「选项」字段则会变长的。
• UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

6. 传输方式

• TCP 是流式传输，没有边界，但保证顺序和可靠。
• UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

7. 分片不同

• TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
• UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

TCP 和 UDP 应用场景：

由于 TCP 是面向连接，能保证数据的可靠性交付（性能较UDP比较差），因此经常用于：

• FTP?文件传输；
• HTTP / HTTPS；

由于 UDP 面向无连接，它可以随时发送数据，再加上 UDP 本身的处理既简单又高效（性能高），因此经常用于：

• 包总量较少的通信，如?DNS?、SNMP?等；
• 视频、音频等多媒体通信；
• 广播通信；

（二）TCP连接建立

1，TCP 三次握手过程是怎样的？

TCP 是面向连接的协议，所以使用 TCP 前必须先建立连接，而建立连接是通过三次握手来进行的。三次握手的过程如下图：

1，初始状态

一开始，客户端和服务端都处于?CLOSE?状态。先是服务端主动监听某个端口，处于?LISTEN?状态

2，客户端发送第一个syn同步报文

客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把?SYN?标志位置为?1，表示?SYN?报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于?SYN-SENT?状态。

?3，服务端回复第一ayn+ack报文

服务端收到客户端的?SYN?报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入?client_isn + 1, 接着把?SYN?和?ACK?标志位置为?1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于?SYN-RCVD?状态。

?4，客户端发送最后ack报文

• 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部?ACK?标志位置为?1?，其次「确认应答号」字段填入?server_isn + 1?，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于?ESTABLISHED?状态。

• 服务端收到客户端的应答报文后，也进入?ESTABLISHED?状态。

从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。

一旦完成三次握手，双方都处于?ESTABLISHED?状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。

?2，为什么是三次握手？不是两次、四次？

相信大家比较常回答的是：“因为三次握手才能保证双方具有接收和发送的能力。”

这回答是没问题，但这回答是片面的，并没有说出主要的原因。

在前面我们知道了什么是?TCP 连接：

• 用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括?Socket、序列号和窗口大小称为连接。

所以，重要的是为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。

接下来，以三个方面分析三次握手的原因：

• 三次握手才可以阻止重复历史连接的初始化（主要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源浪费

（三）TCP连接断开

1，TCP 四次挥手过程是怎样的？

天下没有不散的宴席，对于 TCP 连接也是这样， TCP 断开连接是通过四次挥手方式。

双方都可以主动断开连接，断开连接后主机中的「资源」将被释放，四次挥手的过程如下图：

• 客户端打算关闭连接，此时会发送一个 TCP 首部?FIN?标志位被置为?1?的报文，也即?FIN?报文，之后客户端进入?FIN_WAIT_1?状态。
• 服务端收到该报文后，就向客户端发送?ACK?应答报文，接着服务端进入?CLOSE_WAIT?状态。
• 客户端收到服务端的?ACK?应答报文后，之后进入?FIN_WAIT_2?状态。
• 等待服务端处理完数据后，也向客户端发送?FIN?报文，之后服务端进入?LAST_ACK?状态。
• 客户端收到服务端的?FIN?报文后，回一个?ACK?应答报文，之后进入?TIME_WAIT?状态
• 服务端收到了?ACK?应答报文后，就进入了?CLOSE?状态，至此服务端已经完成连接的关闭。
• 客户端在经过?2MSL?一段时间后，自动进入?CLOSE?状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

2，为什么挥手需要四次？

再来回顾下四次挥手双方发?FIN?包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送?FIN?时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务端收到客户端的?FIN?报文时，先回一个?ACK?应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送?FIN?报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的?ACK?和?FIN?一般都会分开发送，因此是需要四次挥手。

但是在特定情况下，四次挥手是可以变成三次挥手的，具体情况可以看这篇：TCP 四次挥手，可以变成三次吗？