面试小结 - 计算机网络

记录一下秋招面试遇到关于 计算机网络 的问题，会持续更新。

文章目录

• 1. 应用层
• • 1.1 URL
  • • 1.1.1 URL 回车
  • 1.2 HTTP
  • • 1.2.1 GET / POST 区别
    • 1.2.2 网络响应码
    • 1.2.3 cookie / SESSION 区别
  • 1.3 HTTPS
  • • • 1.3.1 HTTPS 是怎么实现的？
      • 1.3.2 非对称加密怎么安全传输密钥
      • 1.3.3 为什么浏览器和操作系统的内嵌证书可以验证其他证书
      • 1.3.4 为什么不直接使用非对称加密
      • 1.3.5 HTTPS 怎么保证安全传输
  • 1.4 WebSocket
  • • 1.4.1 和 Ajax 轮询区别
• 2. 传输层
• • 2.1 TCP
  • • 2.1.1 三次握手
    • 2.1.2 三次握手解决的是什么问题
    • 2.1.3 四次挥手
    • 2.1.4 TCP 如何保证可靠传输
    • 2.1.5 怎么理解滑动窗口
  • 2.2 UDP
  • • 2.2.1 UDP 怎么保证可靠性
  • 2.3 TCP vs UDP

1. 应用层 1.1 URL 1.1.1 URL 回车

• 解析 url，生成 http 请求信息
• 通过 dns 查询服务器域名对应的 ip 地址（客户端到本地域名服务器是递归查询，本地域名服务器到其他服务器是迭代查询）
• 三次握手建立连接，添加 TCP 头部，IP 头部， MAC 头部，报头，组装结束后发送到网络，由路由器和交换机传输到目的服务器
• 服务器解析数据包，把 响应结果 依次添加 TCP 头部，IP 头部， MAC 头部，报头，组装结束后发送到网络，由路由器和交换机传输到客户端
• 客户端收到后，发起四次挥手断开连接

1.2 HTTP 1.2.1 GET / POST 区别

GET 方法的含义是请求从服务器获取资源，参数放在 URL 后面，这个资源可以是静态的文本、页面、图片视频等，是安全且幂等的。

POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 Body 里，不是幂等的。

1.2.2 网络响应码

• 1XX

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

• 2XX

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

• 3XX

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源， 也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location ，指明后续要跳转的 URL，浏览器会自动重定向新的URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

• 4XX

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

• 5XX

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似 “即将开业，敬请期待” 的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似 “网络服务正忙，请稍后重试” 的意思。

1.2.3 cookie / SESSION 区别

cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

cookie 数据保存在客户端 (浏览器端)，Session 数据保存在服务器端。

cookie 一般用来保存用户信息。

Session 的主要作用就是通过服务端记录用户的状态。

cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果使用 cookie 的一些敏感信息不要写入 cookie 中，最好能将 cookie 信息加密然后使用到的时候再去服务器端解密。

1.3 HTTPS 1.3.1 HTTPS 是怎么实现的？

HTTPS 是在 TCP 三次握手之后，进行 SSL/TLS 的握手过程，实现了加密传输。

SSL/TLS 协议的基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

SSL/TLS 协议建立的详细流程：

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（ Client Random ），后面用于生产「会话秘钥」。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（ Server Random ），后面用于生产「会话秘钥」。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

3. 客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA （证书权威机构）公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（ pre-master key ）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的 「会话秘钥」。然后，向客户端发生最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

1.3.2 非对称加密怎么安全传输密钥

参考 1.3.1，将含数字证书的数据包发给客户端即可。

1.3.3 为什么浏览器和操作系统的内嵌证书可以验证其他证书

证书由 CA 颁发。

一般来说，根证书会安装到操作系统或浏览器中，这样的话浏览器就会默认信任该根证书的所有子签名证书。

1.3.4 为什么不直接使用非对称加密

非对称加密是一种高级加密的算法，算法强度复杂，加密解密的速度比较慢，所以一般是用非对称加密来交换对称加密的密钥，然后用对称加密进行通信。

1.3.5 HTTPS 怎么保证安全传输

• 混合加密的方式实现信息的机密性，解决了窃听的风险。

• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

• 将服务器公钥放入到数字证书中，解决了冒充的风险。

1. 混合加密

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

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

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

2. 摘要算法

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

3. 数字证书

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

1.4 WebSocket 1.4.1 和 Ajax 轮询区别

Ajax 轮询：每隔几秒发送请求，询问是否有新的消息。客户端发起连接后，如果没消息，就一直不返回 Response 给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。服务器不能主动推送给客户端，只能由客户端发起。

WebSocket： 当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。只需要经过一次 HTTP 请求，就可以做到源源不断的信息传送了。这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。

2. 传输层 2.1 TCP 2.1.1 三次握手

• 过程

握手前，服务器主动监听某个端口，客户端发起连接。

第一次握手：客户端发送标志位 SYN = 1，随机产生序列号 seq1 的数据包到服务器。服务器由 SYN = 1 知道客户端请求同步。

第二次握手：服务端收到数据包后，发送确认号 ack = seq1 + 1，SYN = 1，ACK = 1，随机产生 seq2 的数据包。

第三次握手：客户端收到后检查 ack 是否正确以及标志位 ACK 是否为 1，如果正确就会再次发送确认号 ack = seq2 + 1，ACK = 1，也可以选择携带数据，服务器收到后确认 ack 的值和 ACK = 1，无差错则连接建立成功。

2.1.2 三次握手解决的是什么问题

TCP 是全双工的连接，只有通过三次握手，双方维护一个序列号和一个应答号，通过这个序列号来确认哪些数据包是被对方接收到的，才能保证连接是双向的。

如果只有两次的话，只能保证这个连接在发送方到接收方这个方向是建立起来的，但也只是半双工连接。

三次可以解决问题，就没必要用四次握手浪费更多的资源。

2.1.3 四次挥手

• 过程

因为 TCP 的连接是全双工的，所以关闭时每个方向都要单独进行关闭。

第一次挥手：客户端发送一个 FIN = 1，seq = 随机数 的数据包到服务器，表示断开连接。客户端进入终止等待状态。

第二次挥手：服务器收到这个 FIN 数据包，发回一个 ACK，确认号 ack = 收到的序列号 + 1。服务器进入关闭等待状态。

第三次挥手：服务器处理完数据后，也是发送一个 FIN 数据包给客户端。服务器进入最后确认状态。

第四次挥手：客户端收到 FIN 数据包，返回一个 ACK 报文确认，并把确认号 ack 设置为收到的序列号 + 1。服务端收到数据包后进入关闭状态。而客户端进入时间等待状态，必须等待时间等待计时器设置的 2MSL 后，TCP 连接才会被释放掉，客户端才进入关闭状态。

2.1.4 TCP 如何保证可靠传输

1. 应用数据分割成 TCP 认为最合适发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. TCP 将保持它首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如何收到段的校验和有差错，TCP 会丢弃该报文和不确认收到此报文。
4. TCP 接收端会丢弃重复收到的数据。
5. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP 接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 利用滑动窗口实现流量控制。
6. 拥塞控制：网络拥塞时，减少数据的发送。
7. ARQ 协议：每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传：TCP 发出一个报文段后会启动一个定时器，等待目的端确认收到这个报文端。如果不能及时收到一个确认，将重发这个报文段。
9. 探测报文：如果对方断开连接，一段时间后会主动发送探测报文，验证连接是否存活。

2.1.5 怎么理解滑动窗口

对于接收方来说，滑动窗口代表的是接收方尚能处理数据的一个能力，然后接收方可以在发送的数据包上表明当前窗口的大小，告知发送方控制相应的速率，以免一次性发送太多数据导致处理不过来。

对于发送方来说，滑动窗口代表的是当前网络的拥塞程度，主要就是防止一次性发送太多数据导致网络瘫痪，或者说数据包在网络路由过程中丢失。通过这个窗口大小和接收方的窗口大小取一个较小值，作为当前发送数据速率的一个标准。

2.2 UDP 2.2.1 UDP 怎么保证可靠性

传输层无法保证数据的可靠传输，只能通过应用层来实现，实现的方式可以参考 TCP 可靠性传输，只是实现不在传输层，实现转移到了应用层。

1. 添加 seq / ack 机制，确保数据发送到对端。
2. 添加发送和接受缓冲区，针对超时重传。
3. 添加超时重传机制。

2.3 TCP vs UDP

特点分析：TCP 面向连接，基于字节流，可靠性好，但是消耗的资源多，传输效率慢；UDP 不面向连接，基于数据包，不可靠，消耗资源少，传输效率快。

使用场景：TCP 更加注重可靠性，而 UDP 注重实时性。

TCP：文件传输 / 邮件收发 / 远程登陆

UDP：直播 / QQ 视频 / QQ 语音 / 游戏