计网
①网络分层
应用层(数据)：确定进程之间通信的性质以及满足用户需要以及提供网络和用户应用，为应用程序提供服务，
表示层(数据)：主要解决用户信息的语法表示问题，提供各种用于应用层数据的编码和转换功能，确保一个系统的应用层发送的数据能被另一个系统的应用层识别，如数据转换，压缩和加密，解密。
会话层(数据)：负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。 比如服务器验证用户登录就是在会话层。
传输层(段)：实现网络不同主机上的用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制，拥塞控制。
网络层(包)：通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。
数据链路层(帧)：将上层数据封装成帧，用MAC地址访问媒介，并由错误检测和修正
物理层(比特流)：主要解决两台物理机之间的通信，通过二进制比特流的传输来实现。网卡、集线器工作在这一层。
②TCP
🌟简述 TCP 的报文头部结构
序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。
确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。
控制位：
- ACK：该位为
1时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的SYN包之外该位必须设置为1。 - RST：该位为
1时，表示 TCP 连接中出现异常必须强制断开连接。 - SYN：该位为
1时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。 - FIN：该位为
1时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位为 1 的 TCP 段。
🌟简述 UDP 的报文头部结构
UDP 协议头部只有 8 个字节（64 位），UDP 的头部格式如下：
- 目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。
- 包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
- 校验和：校验和是为了提供可靠的 UDP 首部和数据而设计，防止收到在网络传输中受损的 UDP 包。
🌟三次握手
- 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送数据包（包含标志位
SYN=1，序列号seq=x）。- 第一次握手前客户端的状态为
CLOSE，第一次握手后客户端的状态为SYN-SEND。此时服务端的状态为LISTEN。
- 第一次握手前客户端的状态为
- 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文（包括标志位
SYN=1，ACK=1，序列号seq=y，确认号ack=x+1）。（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认信号有效）- 第二次握手前服务端的状态为
LISTEN，第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态为SYN-SEND。
- 第二次握手前服务端的状态为
- 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文（包含标志位
ACK=1，序列号seq=x+1，确认号ack=y+1）。- 第三次握手前客户端的状态为
SYN-SEND，第三次握手后客户端和服务端的状态都为ESTABLISHED。此时连接建立完成，客户端和服务端就可以传输数据啦。
- 第三次握手前客户端的状态为
🌟为什么要三次握手?
两次握手可以吗？
三次握手的目的是建立可靠的通信信道，即双方确认自己与对方的发送与接收是否正常。
| Client | Server | |
|---|---|---|
| 第一次握手 | 什么都不能确认 | 对方发送正常，自己接收正常 |
| 第二次握手 | 自己发送、接收正常；对方发送、接收正常 | 对方发送正常，自己接收正常 |
| 第三次握手 | 自己发送、接收正常；对方发送、接收正常 | 自己发送、接收正常，对方发送、接收正常 |
- 第三次握手防止了已失效的连接请求报文段突然又传输到了服务端（主要原因）
如果服务端接收到了一个早已失效的来自客户端的连接请求报文，会向客户端发送确认报文同意建立TCP连接。但因为客户端并不需要向服务端发送数据，所以此次TCP连接没有意义并且浪费了资源。
- 两次握手服务端无法确认自己发送和对方接收是否正常，三次握手就能确认双方收发功能都正常，缺一不可。
假设建立TCP连接仅需要两次握手，那么如果第二次握手时，服务端返回给客户端的确认报文丢失了，客户端这边认为服务端没有和他建立连接，而服务端却以为已经和客户端建立了连接，并且可能向服务端已经开始向客户端发送数据，但客户端并不会接收这些数据，浪费了资源。如果是三次握手，不会出现双方连接还未完全建立成功就开始发送数据的情况。
🌟TCP 中 SYN 攻击是什么？如何防止？
我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务端不能为正常用户服务。
SYN 攻击方式最直接的表现就会把 TCP 半连接队列（SYN队列）打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。
避免 SYN 攻击方式，可以有以下四种方法：
- 增大 TCP 半连接队列；
- 减少 SYN+ACK 重传次数
- 调大 netdev_max_backlog；
- 开启 tcp_syncookies；(绕过 SYN 半连接来建立连接)
🌟四次挥手
- 第一次挥手：客户端向服务端连接释放报文段（
FIN=1，seq=u），进入FIN-WAIT-1（终止等待1）状态。 - 第二次挥手：服务端收到连接释放报文段后发出确认报文段（
ACK=1，ack=u+1，seq=v），服务端进入CLOSE-WAIT（关闭等待-被动关闭）状态，客户端进入FIN-WAIT-2（终止等待2）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。 - 第三次挥手：服务端发送完数据，就会发出连接释放报文段（
FIN=1，ACK=1，seq=w，ack=u+1），服务端进入LAST-ACK（最后确认）状态，等待客户端的确认。 - 第四次挥手：客户端收到服务端的连接释放报文段后，发出确认报文段（
ACK=1，seq=u+1，ack=w+1），客户端进入TIME-WAIT（时间等待-主动关闭）状态。服务端收到客户端发出的确认报文段后关闭连接，进入CLOSED状态。如果客户端等待2MSL（最大报文段生存时间） 后依然没有收到回复，就证明服务端已正常关闭，客户端才进入CLOSED状态。
只要四次挥手没有结束，客户端和服务端就可以继续传输数据！
🌟为什么要四次挥手？
TCP是全双工通信，可以双向传输数据，不能单方面完全断开连接。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
- 客户端发送
FIN：只能断开客户端向服务端方向的连接 - 服务端发送
FIN：只能断开服务端向客户端方向的连接
为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。
如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
客户端没有收到 ACK 确认，会重新发送 FIN 请求。
为什么第四次挥手客户端需要等待 2MSL时间后才进入 CLOSED 状态？
第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2MSL （报文段最长寿命）的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，如果客户端在 2MSL的时间内没有收到 FIN了，就证明服务端已正常关闭。防止 Server 没有收到 ACK 而不断重发 FIN。
MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。
🌟TCP 挥手时出现大量 TIME_WAIT 怎么解决？
TIME_WAIT 状态是「主动关闭连接方」才会出现的状态，所以如果服务器出现大量的 TIME_WAIT 状态的 TCP 连接，就是说明服务器主动断开了很多 TCP 连接。
什么场景下服务端会主动断开连接呢？
- 第一个场景：HTTP 没有使用长连接
- 针对这个场景下，让客户端和服务端都开启 HTTP Keep-Alive 机制。
- 第二个场景：HTTP 长连接超时
- 针对这个场景下，调大 nginx 的 keepalive_timeout 参数就行。
- 第三个场景：HTTP 长连接的请求数量达到上限
- 针对这个场景下，调大 nginx 的 keepalive_requests 参数就行。
🌟TCP 挥手时出现大量 CLOSE_WAIT 怎么解决？
CLOSE_WAIT 状态是「被动关闭方」才会有的状态，而且如果「被动关闭方」没有调用 close 函数关闭连接，那么就无法发出 FIN 报文，从而无法使得 CLOSE_WAIT 状态的连接转变为 LAST_ACK 状态。
当服务端出现大量 CLOSE_WAIT 状态的连接的时候，通常都是代码的问题，这时候我们需要针对具体的代码一步一步的进行排查和定位，主要分析的方向就是服务端为什么没有调用 close。
🌟TCP 与 UDP 的区别
- 是否面向连接 ：
- UDP是无连接的，在传送数据之前不需要先建立连接。
- TCP 面向连接，在传送数据之前必须先建立连接，数据传送结束后要释放连接。
- 是否是可靠传输：
- 主机收到 UDP 报文后，不需要给出任何确认，并且不保证数据不丢失，不保证是否顺序到达。
- TCP 提供可靠的传输服务，TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。
- 传输效率 ：由于 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。
- 传输形式 ： TCP 是面向字节流的，UDP 是面向报文的。
- 首部开销 ：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
- 是否提供广播或多播服务 ：TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多；
| TCP | UDP | |
|---|---|---|
| 是否面向连接 | 是 | 否 |
| 是否可靠 | 是 | 否 |
| 是否有状态 | 是 | 否 |
| 传输效率 | 较慢 | 较快 |
| 传输形式 | 字节流 | 数据报文段 |
| 首部开销 | 20 ～ 60 bytes | 8 bytes |
| 广播或多播 | 否 | 是 |
🌟使用 TCP 的协议有哪些?
基于TCP的应用层协议有：HTTP、 FTP、 SMTP、POP3/IMAP、 TELNET、SSH
| 协议 | 名称 | 默认端口 | 功能 |
|---|---|---|---|
| HTTP | 超文本传输协议 | 80 | Web 浏览器与 Web 服务器通信 |
| FTP | 文件传输协议 | 20、21 | 提供文件传输服务 |
| SMTP | 简单邮件传输协议 | 25 | 用来发送电子邮件 |
| POP3/IMAP | 邮件接收协议 | 110/143 | 负责邮件接收的协议 |
| TELNET | 远程登陆协议 | 23 | 远程登录会话，被SSH取代 |
| SSH | 安全外壳协议 | 22 | 专为远程登录会话和其他网络服务提供安全性的协议 |
🌟使用 UDP 的协议有哪些?
基于UDP的应用层协议：DHCP、DNS
- DHCP：动态主机配置协议，用来动态配置 IP 地址，默认端口68
- DNS：域名解析协议，将域名转换为 IP 地址，默认端口53
🌟TCP 如何保证传输的可靠性？
- 首先，TCP的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。
- 其次，还体现在有状态；TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
- 再次，还体现在可控制。它有数据包校验、超时重传、失序数据排序、丢弃重复数据、流量控制和拥塞控制等机制。
- 校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
- 超时重传 : 当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。
- 失序数据包排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
- 流量控制 : 当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
- 拥塞控制 : 当网络拥塞时，减少数据的发送。
拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
🌟TCP 如何实现流量控制？
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收，防止包丢失。 接收方发送的确认报文中有一个16位的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。并且发送方定期会发送探测报文，来获取窗口大小。
为什么需要流量控制?
这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。处理不过来的数据存在 接收缓冲区 里。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。
流量控制原理
TCP 为全双工通信，双方可以进行双向通信，通信双方都各自维护一个发送窗口和一个接收窗口。发送窗口和接收窗口的要求相同
TCP 发送窗口可以划分成四个部分 ：
- 已经发送并且确认的TCP段（已经发送并确认）；
- 已经发送但是没有确认的TCP段（已经发送未确认）；
- 未发送但是接收方准备接收的TCP段（可以发送）；
- 未发送并且接收方也并未准备接受的TCP段（不可发送）。
- SND.WND ：发送窗口。
- SND.UNA：Send Unacknowledged 指针，指向发送窗口的第一个字节。
- SND.NXT：Send Next 指针，指向可用窗口的第一个字节。
可用窗口大小 = SND.UNA + SND.WND - SND.NXT 。
TCP 接收窗口可以划分成三个部分 ：
- 已经接收并且已经确认的 TCP 段（已经接收并确认）；
- 等待接收且允许发送方发送 TCP 段（可以接收未确认）；
- 不可接收且不允许发送方发送TCP段（不可接收）。
TCP 接收窗口结构图示 ：
接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快，接收窗口可能会扩大。 否则，它可能会缩小。
总结：通信双方都各自维护一个发送窗口和一个接收窗口，接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快，接收窗口可能会扩大。 否则，它可能会缩小。
🌟TCP 的拥塞控制是怎么实现的？
拥塞：在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。
拥塞控制 : 当网络拥塞时，减少数据的发送。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。
- 慢开始
当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞。
较好的方法是先探测一下，由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。拥塞窗口 cwnd 初始值为 1，每经过一个传输轮次，拥塞窗口 cwnd 加倍。
- 拥塞避免
让拥塞窗口 cwnd 缓慢增大，即每经过一个传输轮次就把发送方的 拥塞窗口 加 1。
- 快重传
有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而
降低了传输效率。快重传算法可以避免这个问题。
首先要求接收方每收到一个失序的报文段后就立即发出重复确认（使发送方及早知道有报文段没有到达对方）。发送方连续收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必等待重传计时器到期。
由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。
- 快恢复
当发送方连续收到三个重复确认，就会把慢开始门限（ssthresh）减半，接着把 拥塞窗口 cwnd 值设置为慢开始门限，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。
🌟什么是 TCP 粘包和拆包？
因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP就会将多个请求合并为同一个请求进行发送，这就形成了粘包。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。
常见的解决方案有四种：
- 将每个包都封装成固定的长度，比如100字节。如果不足100字节可通过补0或空等进行填充到指定长度；
- 在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并；例如，FTP协议；
- 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息；
- 通过自定义协议进行粘包和拆包的处理。
🌟UDP 如何保证尽量可靠？
基于 UDP 传输协议实现一个可靠的传输协议，比如 QUIC 协议（HTTP/3）
那么在 UDP 之上怎么实现可靠呢？答案就是重传。
如何基于 UDP 协议实现可靠传输？、怎么让不可靠的UDP可靠？
③HTTP
🌟从输入URL 到页面展示的过程
- DNS 解析
因为浏览器不能直接通过域名找到对应的服务器 IP 地址，所以需进行 DNS 解析，查找到对应的 IP 地址进行访问。
- TCP 连接
当浏览器获取到服务器的 IP 地址后，浏览器会用一个随机的端口（1024 < 端口 < 65535）向服务器 80/443 端口发起 TCP 连接请求。这个连接请求到达服务端后，通过 TCP 三次握手，建立 TCP 的连接。
- 发送 HTTP / HTTPS 请求（建立 TLS 连接）
建立连接后就可以通过 HTTP 进行数据传输。如果使用 HTTPS，会在 TCP 与 HTTP 之间多添加一层协议做加密及认证的服务。HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 协议，保障了信息的安全。
- 服务器处理请求并返回 HTTP 报文
服务器收到请求后，将发回一个 HTTP 响应报文，内容包括相关响应头和 HTML 正文。
- 浏览器解析渲染页面
浏览器在收到HTML，CSS，JS文件后，渲染页面呈现到屏幕上
- HTTP 请求结束，断开 TCP 连接
现在的页面为了优化请求的耗时，默认都会开启持久连接（keep-alive），那么一个 TCP 连接确切关闭的时机，是这个 tab 标签页关闭的时候。这个关闭的过程就是四次挥手。
使用到的协议：DNS、TCP、IP、OSPF、ARP、HTTP
🌟HTTP 和 HTTPS 有什么区别
- 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
- URL 前缀 ：HTTP 的 URL 前缀是
http://，HTTPS 的 URL 前缀是https://。 - 安全性和资源消耗 ：HTTP 安全性没有 HTTPS 高，但 HTTPS 比 HTTP 耗费更多服务器资源且响应速度更慢。
- HTTP 协议运行在 TCP 之上，所有传输的内容都是明文。客户端和服务器端都无法验证对方的身份。
- HTTPS 协议运行在 SSL 之上，SSL/TLS 运行在 TCP 之上，HTTPS = (SSL/TLS + HTTP)，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。加密采用对称加密，但对称加密的密钥用服务器方的证书进行非对称加密。
- HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包。
- HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。
🌟简述 HTTPS 的加密与认证过程 （SSL/TLS）
- 浏览器将支持的加密算法信息发给服务器
- 服务器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器
- 客户端(SSL/TLS)解析证书验证证书合法性，生成对称加密的密钥，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密。
- 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器
- 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
- 服务器将加密后的密文发送给客户端
- 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成
SSL/TLS是一种密码通信框架，他是世界上使用最广泛的密码通信方法。SSL/TLS综合运用了密码学中的对称密码，消息认证码，公钥密码，数字签名，伪随机数生成器等。
SSL(Secure Socket Layer)安全套接层，是1994年由Netscape公司设计的一套协议，并与1995年发布了3.0版本。
TLS(Transport Layer Security)传输层安全是IETF在SSL3.0基础上设计的协议，相当于SSL的后续版本。
TLS主要分为两层，
底层是TLS记录协议，负责消息的压缩，加密及认证
上层是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。
1.握手协议：负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证
2.密码规格变更协议：负责向通信对象传达变更密码方式的信号
3.警告协议：负责在发生错误的时候将错误传达给对方
4.应用数据协议：负责将TLS承载的应用数据传达给通信对象的协议。
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，有以下好处：
- 信息加密：混合加密的方式实现信息的机密性，解决了窃听的风险。
- 校验机制：摘要算法的方式来实现完整性，用于校验数据的完整性，解决了篡改的风险。
- 身份认证：将服务器公钥放入到数字证书中，解决了冒充的风险。
🌟HTTP 1.0 、1.1、 2.0、3.0区别
⓵HTTP 1.0——1996
1.0的HTTP版本，是一种无状态，无连接的应用层协议。
特点：
短连接：HTTP1.0规定浏览器和服务器保持短暂的链接
无连接：浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接
无状态：服务器不跟踪每个客户，也不记录过去的请求，借助cookie/session机制来做身份认证和状态记录。
无法复用连接：每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
队头阻塞：HTTP1.0规定下一个请求必须在前一个请求响应到达之后才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。
不支持断点续传：也就是说，每次都会传送全部的页面和数据。
⓶HTTP 1.1——1999
HTTP1.1继承了HTTP1.0，克服了HTTP1.0性能上的问题。
长连接：HTTP1.1增加
Connection字段，通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。支持断点续传：通过使用请求头中的
Range来实现。它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。增加Host字段 : HTTP/1.1在请求头中加入了
Host字段。没有Host头域会报告一个错误（400 Bad Request）缓存处理 : 在 HTTP1.0 中主要使用
Header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。可以使用管道传输：多个请求可以同时发送，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。
状态响应码 : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。例如：
100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。
⓷HTTP 2.0——2015
http2.0是一种安全高效的下一代http传输协议。安全是因为http2.0建立在https协议的基础上，高效是因为它是通过二进制分帧来进行数据传输。正因为这些特性，http2.0协议也在被越来越多的网站支持。
- 二进制分帧：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
- 多路复用：HTTP/2.0 在同一连接上可以同时传输多个请求和响应。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
- 头部压缩：HTTP/1.1 支持
Body压缩，不支持Header压缩。HTTP/2.0 支持Header压缩，减少了网络开销。 - 服务器推送：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。
⓸HTTP 3.0——2022
基于Google的QUIC，HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC 协议。
为什么要有HTTP3.0？
为了解决HTTP/2.0中TCP造成的队头阻塞问题，HTTP/3.0直接放弃使用TCP，将传输层协议改成UDP；但是因为UDP是不可靠传输，所以这就需要QUIC实现可靠机制
使用基于UDP的QUIC 协议：减少了tcp三次握手时间，以及tls握手时间；
解决多路复用丢包的队头阻塞问题：解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题；
优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗；
连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接；
更合适的流量控制：通过流量控制可以限制客户端传输资料量的大小，有了流量控制后，接收端就可以只保留相对应大小的接收 buffer ,优化记忆体被占用的空间。
参考：HTTP/3 ，它来了
🌟HTTP 常见状态码总结
HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。响应分为五类：
| 分类 | 分类描述 |
|---|---|
| 1** | 信息响应，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功响应，服务器成功处理了客户端的请求 |
| 3** | 重定向，客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源 |
| 4** | 客户端错误，客户端发送的报文有误，服务器无法处理 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
- 「200 OK」是最常见的成功状态码，表示一切正常。除
HEAD请求，服务器返回的响应头都会有 body 数据。 - 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
- 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。
- 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
- 「401-Unauthorized」表示缺乏身份验证凭证，类似403。
- 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
- 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
- 「408-Request-Time-out」表示服务器想要将没有在使用的连接关闭。
- 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
- 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
- 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
- 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。
🌟HTTP 中 GET 和 POST 区别
- 1.GET请求参数通过URL传递；POST请求参数通过请求体传递。
- 2.GET请求产生1个TCP数据包；POST请求产生2个TCP数据包。
- 对于GET请求，浏览器会把请求头和请求体一并发送出去
- 对于POST请求，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体
- 3.GET请求会被浏览器主动缓存；POST请求不会，需手动设置。
- 4.GET请求参数会被保留在浏览器历史记录中；POST请求参数不会被保留。
🌟URI 和 URL 的区别
- URI（Uniform Resource Identifier）统一资源标识符，唯一标识一个资源
- URI 像是身份证，唯一标识一个人
- URL（Uniform Resource Locator）统一资源定位符，提供该资源多路径，是一种具体的URI。
- URL像是住址，可以通过URL找到这个人
🌟cookie和session的区别？
Cookie & Session | 简言之 (jwt1399.top)
Cookie 是一种服务端产生但存储在客户端用于记录客户端状态的机制。
Session 是一种存储在服务器端用于记录客户端状态的机制。
- cookie保存sessionid，服务器会根据cookie中sessionid获取session；
Cookie 机制是通过检查客户身上的“通行证”来确认客户身份
Session 机制是通过检查服务器上的“客户明细表”来确认客户身份
| 区别 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端 | 服务端 |
| 存储大小 | 有限制（4k） | 无限制 |
| 跨域支持 | 支持 | 不支持 |
| 存储信息 | 不加密 | 加密 |
| 生命周期 | 可自定义 | 不可自定义（默认30分钟） |
🌟session和cookie：关闭浏览器后会怎样？
session保存在服务器端，会一直存在，默认存在时间30分钟；
两种类型的Cookie：
不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
为何关闭浏览器后，再次访问会觉得session失效了呢，这里的失效意思是session的数据丢失了？
其实这里session数据并没有丢失，只是关闭浏览器后，因为默认的cookie生命周期为浏览器的缓存，即关掉浏览器之后cookie就失效了，此时sessionid也就没有了（cookie保存sessionid，服务器会根据cookie中sessionid获取session；）。再次访问后，服务器又生成一个新的sessionid，此时request.getSession()通过sessionid获取到的session就不是之前的session了。
🌟HTTP 如何保存用户状态?
HTTP 是一种无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。
Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。
既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
**Cookie 被禁用怎么办?**最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。
🌟HTTP和RPC
| HTTP（HyperText Transfer Protocol，超文本传输协议） | RPC（Remote Procedure Call，远程过程调用） |
|---|---|
| 基于HTTP协议 | 基于TCP协议，也可以基于HTTP协议 |
| HTTP接口使用基于HTTP协议的URL传参调用 | 实现调用本地接口一样调用远程服务的接口 |
| HTTP更臃肿，但跨平台、跨语言更灵活 | RPC效率更好，但是实现更难 |
| 需要配置Nginx，HAProxy实现负载均衡 | 自带了负载均衡策略 |
| HTTP主要用于对外的异构环境，浏览器调用，APP接口调用，第三方接口调用等等。 | RPC主要用于公司内部服务调用，性能消耗低，传输效率高，服务治理方便。 |
流行的RPC框架
gRPC：gRPC是Google公布的开源项目，基于HTTP2.0协议，并支持常见的众多编程语言。HTTP 2.0协议是基于二进制的HTTP协议的升级版本，gRPC底层使用了Netty框架。Thrift：Thrift是Facebook的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL文件自动生成服务代码框架。Thrift对于底层的RPC通讯都是透明的，用户只需要对其进行二次开发即可，省去了一系列重复的前置基础开发工作。Dubbo：Dubbo是阿里集团开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。
④Other
🌟ping工作原理
「ping」是用来探测本机与网络中另一主机之间是否可达的命令
ping 是基于 ICMP 协议工作的，ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议。
ICMP 主要的功能包括：确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。
假设机器A ping机器B，工作过程如下：
- ping通知系统，新建一个固定格式的ICMP请求数据包
- ICMP协议，将该数据包和目标机器B的IP地址打包，一起转交给IP协议层
- IP层协议将本机IP地址为源地址，机器B的IP地址为目标地址，加上一些其他的控制信息，构建一个IP数据包
- 先获取目标机器B的MAC地址。
- 数据链路层构建一个数据帧，目的地址是IP层传过来的 MAC地址，源地址是本机的 MAC地址
- 机器B收到后，对比目标地址，和自己本机的MAC地址是否一致，符合就处理返回，不符合就丢弃。
- 根据目的主机返回的ICMP回送回答报文中的时间戳，从而计算出往返时间
- 最终显示结果有这几项：发送到目的主机的IP地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大& 平均值
🌟DNS 的解析过程
浏览器搜索自己的DNS缓存
若没有，则搜索操作系统中的DNS缓存和hosts文件
若没有，则操作系统将域名发送至本地域名服务器，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权威域名服务器发起查询请求，最终返回IP地址给本地域名服务器
本地域名服务器将得到的IP地址缓存起来并返回给操作系统
操作系统将 IP 地址缓存起来并返回给浏览器
浏览器得到域名对应的IP地址
🌟DNS 劫持是什么？
DNS 劫持是通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。
域名劫持往往只能在特定的网络范围内进行，范围外的 DNS 服务器能够返回正常的 IP 地址。
攻击者可以冒充原域名所属机构，通过电子邮件的方式修改组织机构的域名注册信息，或者将域名转让给其它组织，并将新的域名信息保存在所指定的 DNS 服务器中，从而使得用户无法通过对原域名进行解析来访问目的网址。
解决DNS 劫持
- 直接通过 IP 地址访问网站，避开 DNS 劫持。
- 由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。
🌟ARP 协议
地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
工作原理是发送ARP广播来解析对方主机的MAC地址，解析的结果存储到本机ARP缓存列表中，先查看ARP缓存表，在进行ARP广播查找
🌟简述在四层和七层网络协议中负载均衡的原理
四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器；
七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。
🌟简述 DDOS 攻击原理，如何防范它？
DoS (DenialofService)拒绝服务攻击，这种攻击行为使网站服务器充斥大量的要求回复的信息，消耗网络带宽或系统资源，导致网络或系统不胜负荷而停止提供正常的网络服务。
DDoS分布式拒绝服务，则主要利用 Internet上现有机器及系统的漏洞，攻占大量联网主机，使其成为攻击者的代理。当被控制的机器达到一定数量后，攻击者通过发送指令操纵这些攻击机同时向目标主机或网络发起DoS攻击，大量消耗其网络带和系统资源，导致该网络或系统瘫痪或停止提供正常的网络服务。
如何防御DDOS攻击
采用高性能的网络设备
充足的网络带宽保证
把网站做成静态页面或者伪静态
安装专业抗DDOS防火墙
部署CDN
🌟什么是跨域，什么情况下会发生跨域请求？
当一个请求 url 的协议、域名、端口三者之间任意一个与当前页面 url 不同即为跨域
浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同时就会发生跨域。
🌟简述 JWT 的原理和校验机制
JWT 是 JSON Web Tokens 的缩写。是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准
JWT 的内容由 3 部分组成。第一部分我们称它为头部（header)，第二部分我们称其为载荷（payload，类似于飞机上承载的物品)，第三部分是签证（signature)。
eyJhbGciOiJIU【header部分】.eyJzdWjM0NTY【payload部分】.TJVA9M7E2【signature部分】
Token认证 ，在服务端不需要存储用户的登录记录
认证流程：
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
优点：
支持跨域访问：Cookie是不允许垮域访问的，这一点对Token机制是不存在的
无状态：Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息。
更适用CDN：可以通过内容分发网络请求你服务端的所有资源，而你的服务端只要提供API即可。
OS
①进程和线程
❶进程和线程的区别
| 区别 | 线程 | 进程 |
|---|---|---|
| 调度 | 处理器任务调度和执行的基本单位 | 操作系统资源管理的基本单位 |
| 资源 | 共享本进程的地址空间和资源 | 独立的内存和资源 |
| 关系 | 线程属于进程 | 进程包含线程 |
| 切换 | 上下文切换快 | 上下文切换慢 |
| 开销 | 创建、销毁开销小 | 创建、销毁开销大 |
🌟为什么切换线程比切换进程开销小
现在都采用轮转时间片的方式去运行，当切换进程时，需要保存进程的执行现场，然后去执行下一个进程，恢复执行时，首先要恢复执行现场，才能继续执行。切换线程也是同样的道理，需要保存线程的执行现场。
但是在进程内切换线程，进程内的资源是共享的不用切换。
可以理解为线程上下文是进程上下文的子集。
🌟进程间的通信方式
- 管道/匿名管道(Pipes) ：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。
- 有名管道(Named Pipes) : 匿名管道由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道。有名管道严格遵循**先进先出(first in first out)**。有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。
- 信号(Signal) ：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生；
- 消息队列(Message Queuing) ：消息队列是消息的链表，具有特定的格式，存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显式地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询，消息不一定要以先进先出的次序读取，也可以按消息的类型读取。比 FIFO 更有优势。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
- 信号量(Semaphores) ：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。
- 共享内存(Shared memory) ：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。
- 套接字(Sockets) : 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。
🌟线程间通信方式
同一进程的线程共享地址空间，通信通过共享内存，一般来说只需要做好同步/互斥，保护共享的全局变量。
- 锁机制：包括互斥锁，读写锁，自旋锁，条件变量。synchronized 关键词和各种 Lock 都是这种机制。
- 互斥锁提供排他方式防止数据结构被修改的方法，
- 读写锁允许多个线程同时读共享变量，对写操作互斥，
- 自旋锁循环检测是否释放锁，
- 条件变量以原子方式阻塞进程，直到条件为真，与互斥锁一起使用。
- 信号量机制：它允许同一时刻多个线程访问同一资源，但是需要控制同一时刻访问此资源的最大线程数量。
- 信号机制：通过通知操作的方式来保持多线程同步，方便的实现多线程优先级的比较操作。Wait/Notify
❸进程有哪几种状态
创建状态(new) ：进程正在被创建，尚未到就绪状态。
就绪状态(ready) ：进程已处于准备运行状态，即进程获得了除了处理器之外的一切所需资源，一旦得到处理器资源(处理器分配的时间片)即可运行。
运行状态(running) ：进程正在处理器上运行(单核 CPU 下任意时刻只有一个进程处于运行状态)。
阻塞状态(waiting) ：又称为等待状态，进程正在等待某一事件而暂停运行如等待某资源为可用或等待 IO 操作完成。即使处理器空闲，该进程也不能运行。
结束状态(terminated) ：进程正在从系统中消失。可能是进程正常结束或其他原因中断退出运行。
❹进程的调度算法
先来先服务（FCFS）
- 从就绪队列中选择一个最先进入该队列的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
短作业优先（SJF）
- 从就绪队列中选出一个估计运行时间最短的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
优先级调度算法（PSA）
- 为每个流程分配优先级，首先执行具有最高优先级的进程，依此类推。具有相同优先级的进程以 FCFS 方式执行。可以根据内存要求，时间要求或任何其他资源要求来确定优先级。
高响应比优先调度算法（HRRN）
- 根据“响应比 =（进程执行时间+进程等待时间）/ 进程执行时间”这个公式得到的响应比来进行调度。
- 优点是兼顾长短作业，缺点是计算响应比开销大，适用于批处理系统。
- FCFS方式只考虑每个作业的等待时间而未考虑执行时间的长短；
- SJF方式只考虑执行时间而未考虑等待时间的长短。
时间片轮转调度算法 （RR）
- 每个进程被分配一个时间段，称作它的时间片，即该进程允许运行的时间。
❺线程有多少种状态
- New（新建）：尚未启动的线程处于此状态。
- Runnable（运行）：在Java虛拟机中执行的线程处于此状态。
- Blocked（阻塞）：被阻塞等待监视器锁定的线程处于此状态。
- Waiting（等待）：正在等待另一个线程执行特定动作的线程处于此状态。
- Timed Waiting（计时等待）：正在等待另一个线程执行动作达到指定等待时间的线程处于此状态。
- Terminated（终止）：已退出的线程处于此状态。
❻并发&并行
并发：同一个时刻，多个任务交替执行。单核 cpu 实现的多任务就是并发。例如：Tom 边开车边接电话
并行：同一个时刻，多个任务同时执行。多核 cpu 可以实现并行。例如：Tom 开车 ，Jack 接电话
❽死锁
死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用，它们都将无法推进下去。
死锁产生的四个必要条件
互斥：一个资源每次只能被一个进程使用
不可强占：任一进程不能从另一进程那里抢夺资源
请求和保持：一个进程请求资源而阻塞时，不释放已占有的资源
循环等待：进程之间循环等待着资源
解决死锁的方法
- 预防死锁：采用策略限制并发进程对资源的请求，使得死锁的必要条件在系统执行的任何时间上都不满足。
- 避免死锁：系统在分配资源时，根据资源的使用情况提前做出预测，从而避免死锁的发生
- 检测死锁：设专门的机构，当死锁发生时，能够检测死锁的发生，并精确地确定与死锁有关的进程和资源。
- 解除死锁：与检测死锁配套的一种措施，用于将进程从死锁状态下解脱出来。
②内存管理
Sponsor❤️
您的支持是我不断前进的动力，如果您感觉本文对您有所帮助的话，可以考虑打赏一下本文，用以维持本博客的运营费用，拒绝白嫖，从你我做起！🥰🥰🥰
| 支付宝 | 微信 |
 |
 |
