计算机网络知识（面试高频）

1. TCP和UDP的区别

TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管道中的水流。当应用程序采用TCP发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP为提供可靠性传输，实行 “顺序控制〞或“重发控制”机制。此外还具备“流控制（流量控制）、“拥塞控制”、提高网络利用率等众多功能。

UDP是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在UDP的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需要进行重发处理。
由于UDP面向无连接，它可以随时发送数据。再加上UDP本身的处理既简单又高效，因此经常用于以下几个方面：

• 包总量较少的通信（DNS、SNMP等）
• 视频、音频等多媒体通信（即时通信）
• 限定于LAN等特定网络中的应用通信
• 广播通信（广播、多播）
  补充知识：套接字

2. TCP三次握手、四次挥手过程

TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

• 最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。

• 第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时随机生成一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。

• 第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也随机生成一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。

• 第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。

TCP 断开连接的过程叫做挥手，需要在客户和服务器之间交换四个 TCP 报文段。

• 第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。

• 第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。

• 第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。

• 第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。

3. 为什么两次握手不行？

如果用两次握手的话，会有以下问题：

• A发送给B的请求报文段由于网络原因被阻塞，A迟迟没有收到B的确认报文段，于是超时重发请求报文段，第二次请求报文段成功发送，并收到B的确认报文段，连接建立。但此时第一次发送的请求报文段也到达B，于是B给该tcp连接分配缓存和变量并给A返回一个确认报文段，A收到确认报文段但此时对应的第一次发送的请求已经失效，所以A将确认报文段丢弃且不会为该tcp连接分配资源。这就造成了“僵尸连接”，B会一直维持这个无效的连接，造成资源的浪费。

• 三次握手中通信双方会在报文段中相互告知初始序号， 并确认对方已收到己方的初始序号。若只进行两次握手， 则仅有连接发起方的初始序号能够得到确认，另一方的初始序号无法得到确认，建立的不是双方互相确认过的可靠连接。

4. 为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？

1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。

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

5. TCP 协议是如何保证可靠传输的？

1. 序列号与确认应答：

   • 序列号：TCP为每个发送的数据段（Segment）分配一个唯一的序列号，以便接收方能够按照正确的顺序重组数据流。序列号使得接收方可以识别出乱序到达的数据以及重复收到的数据。
   • 确认应答（ACK） ：接收方对按序到达的数据段发送确认信息，包含一个“确认号”，指示期望接收的下一个数据段的序列号。这样，发送方就知道哪些数据已被成功接收，从而能够跟踪哪些数据需要重传。

2. 校验和：

   • TCP头和数据部分都包含在一个校验和的计算范围内，用于检测数据在传输过程中是否出现错误。发送端计算校验和后填入TCP头部，接收端重新计算并验证。如果校验和不匹配，说明数据可能已损坏，接收方将丢弃该数据段并要求发送方重传。

3. 超时重传：

   • 发送方在发送数据段后启动一个定时器。如果在预设的时间内没有收到对应的ACK确认，认为该数据段可能丢失，将重新发送该数据段。这种机制可以应对网络拥塞或数据包丢失的情况。

4. 连接管理：

   • TCP使用三次握手建立连接（SYN, SYN-ACK, ACK），四次挥手断开连接（FIN, ACK, FIN, ACK），确保双方在数据传输前就绪，传输结束时能有序释放资源，避免数据丢失或错误连接状态。

5. 流量控制：

   • 利用滑动窗口机制，接收方通过TCP报文中的窗口大小字段告知发送方当前能够接收的数据量。发送方据此调整发送速率，防止因发送过快导致接收方缓存溢出，丢失数据。这样可以确保接收方能及时处理接收到的数据，维持双方数据处理速度的平衡。

6. 拥塞控制：

   • 当网络发生拥塞时，TCP通过慢启动、拥塞避免、快速重传、快速恢复等算法动态调整数据发送速率，减少数据包丢失和网络拥塞加剧的风险。这些算法基于网络反馈（如连续ACK、超时等）来判断网络状况，并相应地增加或减少发送窗口大小。

6. 谈谈你对滑动窗口的了解？

TCP 利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

7. 谈下你对流量控制的理解？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

8. 谈下你对 TCP 拥塞控制的理解？ 使用了哪些算法？

拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。

拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。

快重传与快恢复： 在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。

没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。 有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和快恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

9. HTTP 状态码有了解吗？

10. 在浏览器中输入 URL 地址到显示主页的过程？

1. DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址：具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。对于向本地 DNS 服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；

2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；

3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；

4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；

5. 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

6. 连接结束

总结: DNS域名解析——>浏览器与服务器建立TCP连接——>向web服务器发送http请求——>web服务器收到这个请求进行处理——>服务器响应http请求——>网页渲染

DNS域名解析的过程：浏览器缓存——>本地域名服务器-——>根域名服务器——>顶级域名服务器——>权限域名服务器

11. 谈下 HTTP 1.0 和 1.1、1.2 的主要变化？

HTTP1.1 的主要变化：

1. HTTP1.0 经过多年发展，在 1.1 提出了改进。首先是提出了长连接，HTTP 可以在一次 TCP 连接中不断发送请求。

2. 然后 HTTP1.1 支持只发送 header 而不发送 body。原因是先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。

3. HTTP1.1 的 host 字段。由于虚拟主机可以支持多个域名，所以一般将域名解析后得到 host。

HTTP2.0 的主要变化：

1. HTTP2.0 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；

2. HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；

3. HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；

4. HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。

12. HTTPS 与 HTTP 的区别？

• HTTP 是明文传输协议，HTTPS 协议是在http协议基础上增加了 SSL/TLS协议加密，比 HTTP 协议安全；
• HTTPS对搜索引擎更友好，谷歌、百度优先索引HTTPS网页；
• HTTPS标准端口443，HTTP标准端口80；
• HTTPS基于传输层，HTTP基于应用层；

13. HTTPS 的工作原理？

1.https加密的过程：

HTTPS采用对称加密和非对称加密两者并用的混合加密机制。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

2.解决报文可能遭篡改问题——数字签名

https请求过程：