1. 软市首页
  2. 行业观察

面渣逆袭：三万字，七十图，详解计算机 络六十二问（收藏版）

• 行业观察

大家好，我是老三，开工大吉，虎年第一篇，面渣逆袭系列继续！

这次给大家带来了计算机 络六十二问，三万字，七十图详解，大概是全 最全的 络面试题。

建议大家收藏了慢慢看，新的一年一定能够跳槽加薪，虎年“豹”富！

基础

1.说下计算机 络体系结构

计算机 络体系结构，一般有三种：OSI 七层模型、TCP/IP 四层模型、五层结构。

3.那么数据在各层之间是怎么传输的呢/h3>

对于发送方而言，从上层到下层层层包装，对于接收方而言，从下层到上层，层层解开包装。

  • 发送方的应用进程向接收方的应用进程传送数据
  • AP先将数据交给本主机的应用层，应用层加上本层的控制信息H5就变成了下一层的数据单元
  • 传输层收到这个数据单元后，加上本层的控制信息H4，再交给 络层，成为 络层的数据单元
  • 到了数据链路层，控制信息被分成两部分，分别加到本层数据单元的首部（H2）和尾部（T2）
  • 最后的物理层，进行比特流的传输

各个过程都使用了哪些协议/p>

假设你要查询 www.baidu.com 的 IP 地址:

  • 首先会查找浏览器的缓存,看看是否能找到www.baidu.com对应的IP地址，找到就直接返回；否则进行下一步。
  • 将请求发往给本地DNS服务器，如果查找到也直接返回，否则继续进行下一步；

HTTP

8.说说 HTTP 常用的状态码及其含义/h3>

HTTP状态码首先应该知道个大概的分类：

  • 1XX：信息性状态码
  • 2XX：成功状态码
  • 3XX：重定向状态码
  • 4XX：客户端错误状态码
  • 5XX：服务端错误状态码

几个常用的，面试之外，也应该记住：

其中，POST、DELETE、PUT、GET的含义分别对应我们最熟悉的增、删、改、查。

10.说?下 GET 和 POST 的区别/h3>

可以从以下几个方面来说明GET和POST的区别：

  • 每个服务器都有一个进程，它不断监听TCP的端口80，以便发现是否有浏览器向它发出连接建立请求
  • 监听到连接请求，就会建立TCP连接
  • 浏览器向服务器发出浏览某个页面的请求，服务器接着就返回所请求的页面作为响应
  • 最后，释放TCP连接

在浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则，这些格式和规则就是超文本传输协议HTTP。

PS:这道题和上面浏览器输入 址发生了什么那道题大差不差。

13.说一下HTTP的 文结构/h3>

HTTP 文有两种，HTTP请求 文和HTTP响应 文：

  • URI，统一资源标识符(Uniform Resource Identifier， URI)，标识的是Web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都是由一个URI进行标识的。

  • URL，统一资源定位符（Uniform Resource Location)，它是URI的一种子集，主要作用是提供资源的路径。

它们的主要区别在于，URL除了提供了资源的标识，还提供了资源访问的方式。这么比喻，URI 像是身份证，可以唯一标识一个人，而 URL 更像一个住址，可以通过 URL 找到这个人——人类住址协议://地球/中国/北京市/海淀区/xx职业技术学院/14 宿舍楼/525 寝/张三.男。

15.说下 HTTP/1.0，1.1，2.0 的区别/h3>

关键需要记住 HTTP/1.0 默认是短连接，可以强制开启，HTTP/1.1 默认长连接，HTTP/2.0 采用多路复用。

HTTP/1.0

  • 默认使用短连接，每次请求都需要建立一个 TCP 连接。它可以设置 这个字段，强制开启长连接。

HTTP/1.1

  • 引入了持久连接，即 TCP 连接默认不关闭，可以被多个请求复用。

  • 分块传输编码，即服务端每产生一块数据，就发送一块，用” 流模式” 取代” 缓存模式”。

  • 管道机制，即在同一个 TCP 连接里面，客户端可以同时发送多个请求。

HTTP/2.0

  • 二进制协议，1.1 版本的头信息是文本（ASCII 编码），数据体可以是文本或者二进制；2.0 中，头信息和数据体都是二进制。
  • 完全多路复用，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。
  • 头压缩，HTTP 协议不带有状态，每次请求都必须附上所有信息。Http/2.0 引入了头信息压缩机制，使用 gzip 或 compress 压缩后再发送。
  • 服务端推送，允许服务器未经请求，主动向客户端发送资源。

16.HTTP/3了解吗/h3>

HTTP/3主要有两大变化，传输层基于UDP、使用QUIC保证UDP可靠性。

HTTP/2存在的一些问题，比如重传等等，都是由于TCP本身的特性导致的，所以HTTP/3在QUIC的基础上进行发展而来，QUIC（Quick UDP Connections）直译为快速UDP 络连接，底层使用UDP进行数据传输。

HTTP/3主要有这些特点：

  • 使用UDP作为传输层进行通信
  • 在UDP的基础上QUIC协议保证了HTTP/3的安全性，在传输的过程中就完成了TLS加密握手
  • HTTPS 要建??个连接，要花费 6 次交互，先是建?三次握?，然后是 TLS/1.3 的三次握?。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
  • QUIC 有??的?套机制可以保证传输的可靠性的。当某个流发?丢包时，只会阻塞这个流，其他流不会受到影响。

我们拿一张图看一下HTTP协议的变迁：

所以引入了HTTPS，HTTPS 在 HTTP 与 TCP 层之间加?了 SSL/TLS 协议，可以很好的解决了这些风险：

  • 信息加密：交互信息?法被窃取。

  • 校验机制：?法篡改通信内容，篡改了就不能正常显示。

  • 身份证书：能证明淘宝是真淘宝。

所以SSL/TLS 协议是能保证通信是安全的。

20.HTTPS工作流程是怎样的/h3>

这道题有几个要点：公私钥、数字证书、加密、对称加密、非对称加密。

HTTPS 主要工作流程：

  1. 客户端发起 HTTPS 请求，连接到服务端的 443 端口。
  2. 服务端有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等）。
  3. 服务端将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有）。
  4. 客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。
  5. 客户端将公钥加密后的密钥发送到服务器。
  6. 服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥，然后用客户端密钥对返回数据进行对称加密，酱紫传输的数据都是密文啦。
  7. 服务器将加密后的密文返回到客户端。
  8. 客户端收到后，用自己的密钥对其进行对称解密，得到服务器返回的数据。

21.客户端怎么去校验证书的合法性/h3>

首先，服务端的证书从哪来的呢/p>

为了让服务端的公钥被?家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA就是?络世界?的公安局、公证中?，具有极?的可信度，所以由它来给各个公钥签名，信任的??签发的证书，那必然证书也是被信任的。

Session 和 Cookie 到底有什么不同呢/p>

  • 存储位置不一样，Cookie 保存在客户端，Session 保存在服务器端。

  • 存储数据类型不一样，Cookie 只能保存ASCII，Session可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。

  • 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般有效时间较短，客户端关闭或者 Session 超时都会失效。

  • 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。

  • 存储大小不同， 单个Cookie保存的数据不能超过4K，Session可存储数据远高于 Cookie。

Session 和 Cookie有什么关联呢/p>

可以使用Cookie记录Session的标识。

客户端无法使用Cookie怎么办/strong>

有可能客户端无法使用Cookie，比如浏览器禁用Cookie，或者客户端是安卓、IOS等等。

这时候怎么办essionID怎么存么传给服务端呢/p>

首先是SessionID的存储，可以使用客户端的本地存储，比如浏览器的sessionStorage。

接下来怎么传呢/p>

  • 拼接到URL里：直接把SessionID作为URL的请求参数
  • 放到请求头里：把SessionID放到请求的Header里，比较常用。

TCP

24.详细说一下 TCP 的三次握手机制

PS:TCP三次握手是最重要的知识点，一定要熟悉到问到即送分。

TCP提供面向连接的服务，在传送数据前必须建立连接，TCP连接是通过三次握手建立的。

25.TCP 握手为什么是三次，为什么不能是两次能是四次/h3>

为什么不能是两次/strong>

  • 为了防止服务器端开启一些无用的连接增加服务器开销
  • 防止已失效的连接请求 文段突然又传送到了服务端，因而产生错误。

由于 络传输是有延时的(要通过 络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了 SYN=1 的第一次握手。

如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为 络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。

服务端就认为这个连接是可用的，端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。这样一来，就会有很多无效的连接端口白白地开着，导致资源的浪费。

所以我们需要“第三次握手”来确认这个过程：

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

为什么不是四次/strong>

简单说，就是三次挥手已经足够创建可靠的连接，没有必要再多一次握手导致花费更多的时间建立连接。

26.三次握手中每一次没收到 文会发生什么情况/h3>

  • 第一次握手服务端未收到SYN 文

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

  • 第二次握手客户端未收到服务端响应的ACK 文

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

  • 第三次握手服务端为收到客户端发送过来的ACK 文

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

27.第二次握手传回了 ACK，为什么还要传回 SYN/h3>

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

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

28.第3次握手可以携带数据吗/h3>

第3次握手是可以携带数据的。

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

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

29.说说半连接队列和 SYN Flood 攻击的关系/h3>

什么是半连接队列/strong>

TCP 进入三次握手前，服务端会从 CLOSED 状态变为 LISTEN 状态, 同时在内部创建了两个队列：半连接队列（SYN 队列）和全连接队列（ACCEPT 队列）。

那有什么应对方案呢/strong>

主要有 syn cookie 和 SYN Proxy 防火墙等。

  • syn cookie：在收到 SYN 包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个 cookie 值作为自己的 SYNACK 包的序列 ，回复 SYN+ACK 后，服务器并不立即分配资源进行处理，等收到发送方的 ACK 包后，重新根据数据包的源地址、端口计算该包中的确认序列 是否正确，如果正确则建立连接，否则丢弃该包。

  • SYN Proxy 防火墙：服务器防火墙会对收到的每一个 SYN 文进行代理和回应，并保持半连接。等发送方将 ACK 包返回后，再重新构造 SYN 包发到服务器，建立真正的 TCP 连接。

30.说说 TCP 四次挥手的过程/h3>

PS：问完三次握手，常常也会顺道问问四次挥手，所以也是必须掌握知识点。

31.TCP 挥手为什么需要四次呢/h3>

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

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

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 和 一般都会分开发送，从而比三次握手导致多了一次。

32.TCP 四次挥手过程中，为什么需要等待 2MSL, 才进入 CLOSED 关闭状态/h3>

为什么需要等待/strong>

1. 为了保证客户端发送的最后一个 ACK 文段能够到达服务端。 这个 ACK 文段有可能丢失，因而使处在 LAST-ACK 状态的服务端就收不到对已发送的 FIN + ACK 文段的确认。服务端会超时重传这个 FIN+ACK 文段，而客户端就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 文段。接着客户端重传一次确认，重新启动 2MSL 计时器。最后，客户端和服务器都正常进入到 CLOSED 状态。

2. 防止已失效的连接请求 文段出现在本连接中。客户端在发送完最后一个 ACK 文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有 文段都从 络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求 文段。

为什么等待的时间是2MSL/strong>

MSL 是 Maximum Segment Lifetime， ?最??存时间，它是任何 ?在?络上存在的最?时间，超过这个时间 ?将被丢弃。

TIME_WAIT 等待 2 倍的 MSL，?较合理的解释是： ?络中可能存在来?发送?的数据包，当这些发送?的数据包被接收?处理后?会向对?发送响应，所以?来?回需要等待 2 倍的时间。

  • 防?旧连接的数据包

    如果客户端收到服务端的FIN 文之后立即关闭连接，但是此时服务端对应的端口并没有关闭，如果客户端在相同端口建立新的连接，可能会导致新连接收到旧连接残留的数据包，导致不可预料的异常发生。

  • 保证连接正确关闭

    假设客户端最后一次发送的ACK包在传输的时候丢失了，由于TCP协议的超时重传机制，服务端将重发FIN 文，如果客户端没有维持TIME-WAIT状态而直接关闭的话，当收到服务端重新发送的FIN包时，客户端就会使用RST包来响应服务端，导致服务端以为有错误发生，然而实际关闭连接过程是正常的。

35.TIME_WAIT 状态过多会导致什么问题么解决/h3>

TIME_WAIT 状态过多会导致什么问题/strong>

如果服务器有处于 TIME-WAIT 状态的 TCP，则说明是由服务器?主动发起的断开请求。

过多的 TIME-WAIT 状态主要的危害有两种：

第?是内存资源占?；

第?是对端?资源的占?，?个 TCP 连接?少消耗?个本地端?；

怎么解决TIME_WAIT 状态过多/strong>

  • 服务器可以设置SO_REUSEADDR套接字来通知内核，如果端口被占用，但是TCP连接位于TIME_WAIT 状态时可以重用端口。
  • 还可以使用长连接的方式来减少TCP的连接和断开，在长连接的业务里往往不需要考虑TIME_WAIT状态。

36.说说 TCP 文首部的格式/h3>

看一下TCP 文首部的格式：

TCP 文首部的格式

  • 16 位端口 ：源端口 ，主机该 文段是来自哪里；目标端口 ，要传给哪个上层协议或应用程序

  • 32 位序 ：一次 TCP 通信（从 TCP 连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编 。

  • 32 位确认 ：用作对另一方发送的 tcp 文段的响应。其值是收到的 TCP 文段的序 值加 1。

  • 4 位首部长度：表示 tcp 头部有多少个 32bit 字（4 字节）。因为 4 位最大能标识 15，所以 TCP 头部最长是 60 字节。

  • 6 位标志位：URG(紧急指针是否有效)，ACk（表示确认 是否有效），PST（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）

  • 16 位窗口大小：是 TCP 流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

  • 16 位校验和：由发送端填充，接收端对 TCP 文段执行 CRC 算法以检验 TCP 文段在传输过程中是否损坏。注意，这个校验不仅包括 TCP 头部，也包括数据部分。这也是 TCP 可靠传输的一个重要保障。

  • 16 位紧急指针：一个正的

    声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

上一篇 2022年1月21日
下一篇 2022年1月21日

相关推荐

首页
软件超市
企服市场
会员中心