Web前端最全如果你正在准备面试TCP，看这一篇就够了(1)，在线面试app

本文链接：https://blog.csdn.net/2401_84619287/article/details/138985233

react和vue的比较

相同
1）vitual dom
2）组件化
3）props，单一数据流

不同点
1）react是jsx和模板；（jsx可以进行更多的js逻辑和操作）
2）状态管理（react）
3）对象属性（vue）
4）vue：view——medol之间双向绑定
5）vue：组件之间的通信（props，callback，emit）

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

常见面试题2：TCP 建立连接为什么要三次握手而不是四次？

答：相比上个问题而言，这个问题就简单多了。因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

常见面试题3：有一种网络攻击是利用了 TCP 建立连接机制的漏洞，你了解吗？这个问题怎么解决？

答：在三次握手过程中，服务器在收到了客户端的 SYN 报文段后，会分配并初始化连接变量和缓存，并向客户端发送 SYN + ACK 报文段，这相当于是打开了一个“半开连接 (half-open connection)”，会消耗服务器资源。如果客户端正常返回了 ACK 报文段，那么双方可以正常建立连接，否则，服务器在等待一分钟后会终止这个“半开连接”并回收资源。这样的机制为 SYN洪泛攻击 (SYN flood attack)提供了机会，这是一种经典的 DoS攻击 (Denial of Service，拒绝服务攻击)，所谓的拒绝服务攻击就是通过进行攻击，使受害主机或网络不能提供良好的服务，从而间接达到攻击的目的。在 SYN 洪泛攻击中，攻击者发送大量的 SYN 报文段到服务器请求建立连接，但是却不进行第三次握手，这会导致服务器打开大量的半开连接，消耗大量的资源，最终无法进行正常的服务。

解决方法：SYN Cookies，现在大多数主流操作系统都有这种防御系统。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。它的原理是，在服务器接收到 SYN 报文段并返回 SYN + ACK 报文段时，不再打开一个半开连接，也不分配资源，而是根据这个 SYN 报文段的重要信息 (包括源和目的 IP 地址，端口号可一个秘密数)，利用特定散列函数计算出一个 cookie 值。这个 cookie 作为将要返回的SYN + ACK 报文段的初始序列号(ISN)。当客户端返回一个 ACK 报文段时，服务器根据首部字段信息计算 cookie，与返回的确认序号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后分配资源并建立连接，否则拒绝建立连接。

2.2.2 同时打开

==========

这是 TCP 建立连接的特殊情况，有时会出现两台机器同时执行主动打开的情况，不过概率非常小，这种情况大家仅作了解即可。在这种情况下就无所谓发送方和接收方了，双放都可以称为客户端和服务器，同时打开的过程如下：

如果你正在准备面试TCP，看这一篇就够了

同时打开的过程

如图所示，双方在同一时刻发送 SYN 报文段，并进入 SYN-SENT 状态，在收到 SYN 后，状态变为 SYN-RECEIVED，同时它们都在发送一个 SYN + ACK 的报文段，状态都变为 ESTABLISHED，连接成功建立。在此过程中双方一共交换了4个报文段，比三次握手多一个。

2.2 关闭连接

========

2.2.1 四次挥手

==========

建立一个连接需要三次握手，而终止一个连接要经过 4次握手。这由 TCP 的半关闭( half-close) 造成的。既然一个 TCP 连接是全双工 (即数据在两个方向上能同时传递)，因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向连接。当一端收到一个 FIN，它必须通知应用层另一端已经终止了数据传送。理论上客户端和服务器都可以发起主动关闭，但是更多的情况下是客户端主动发起。

如果你正在准备面试TCP，看这一篇就够了

四次挥手过程

四次挥手详细过程如下：

客户端发送关闭连接的报文段，FIN 标志位1，请求关闭连接，并停止发送数据。序号字段 seq = x (等于之前发送的所有数据的最后一个字节的序号加一)，然后客户端会进入 FIN-WAIT-1 状态，等待来自服务器的确认报文。
服务器收到 FIN 报文后，发回确认报文，ACK = 1， ack = x + 1，并带上自己的序号 seq = y，然后服务器就进入 CLOSE-WAIT 状态。服务器还会通知上层的应用程序对方已经释放连接，此时 TCP 处于半关闭状态，也就是说客户端已经没有数据要发送了，但是服务器还可以发送数据，客户端也还能够接收。
客户端收到服务器的 ACK 报文段后随即进入 FIN-WAIT-2 状态，此时还能收到来自服务器的数据，直到收到 FIN 报文段。
服务器发送完所有数据后，会向客户端发送 FIN 报文段，各字段值如图所示，随后服务器进入 LAST-ACK 状态，等待来自客户端的确认报文段。
客户端收到来自服务器的 FIN 报文段后，向服务器发送 ACK 报文，随后进入 TIME-WAIT 状态，等待 2MSL(2 * Maximum Segment Lifetime，两倍的报文段最大存活时间) ，这是任何报文段在被丢弃前能在网络中存在的最长时间，常用值有30秒、1分钟和2分钟。如无特殊情况，客户端会进入 CLOSED 状态。
服务器在接收到客户端的 ACK 报文后会随即进入 CLOSED 状态，由于没有等待时间，一般而言，服务器比客户端更早进入 CLOSED 状态。

常见面试题1：为什么 TCP 关闭连接为什么要四次而不是三次？

答：服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段，接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接，然后客户端再做出应答，因此一共需要四次挥手。

常见面试题2：客户端为什么需要在 TIME-WAIT 状态等待 2MSL 时间才能进入 CLOSED 状态？

答：按照常理，在网络正常的情况下，四个报文段发送完后，双方就可以关闭连接进入 CLOSED 状态了，但是网络并不总是可靠的，如果客户端发送的 ACK 报文段丢失，服务器在接收不到 ACK 的情况下会一直重复 FIN 报文段，这显然不是我们想要的。因此客户端为了确保服务器收到了 ACK，会设置一个定时器，并在 TIME-WAIT 状态等待 2MSL 的时间，如果在此期间又收到了来自服务器的 FIN 报文段，那么客户端会重新设置计时器并再次等待 2MSL 的时间，如果在这段时间内没有收到来自服务器的 FIN 报文，那就说明服务器已经成功收到了 ACK 报文，此时客户端就可以进入 CLOSED 状态了。

2.2.2 同时关闭

==========

之前在介绍 TCP 建立连接的时候会有一种特殊情况，那就是同时打开，与之对应地， TCP 关闭时也会有一种特殊情况，那就是同时关闭，这种情况仅作了解即可，流程图如下：

如果你正在准备面试TCP，看这一篇就够了

同时关闭过程

这种情况下，双方应用层同时发出关闭命令，这将导致双方各发送一个 FIN，两端均从 ESTABLISHED 变为 FIN_WAIT_1，两个 FIN 经过网络传送后分别到达另一端。收到 FIN 后，状态由 FIN_WAIT_1 变迁到 CLOSING，并发送最后的 ACK，当收到最后的 ACK 时，为确保对方也收到 ACK，状态变化为 TIME_WAIT，并等待 2MSL 时间，如果一切正常，随后会进入 CLOSED 状态。

三、TCP 的流量控制与滑动窗口

================

3.1 什么是流量控制？

============

TCP 连接双方的主机都为该连接设置了发送缓存和接收缓存，这些缓存起到了蓄水池的作用，我们肯定不能把上层应用程序发来的数据一股脑儿发送到网络中，而是利用发送缓存将其缓存起来，然后再按一定的速率通过网络发送给对方，而接收缓存的作用是把对方传来的数据先缓存起来，等到己方应用程序有空的时候再来取走数据。示意图如下：

如果你正在准备面试TCP，看这一篇就够了

TCP 缓存示意图

在此过程中，如果接收方应用程序读取数据的速度小于发送方的数据发送速度，将导致接收方的接收缓存溢出，造成数据丢失，这显然不是我们想看到的。因此 TCP 为应用程序提供了流量控制服务 (flow-control service)，以消除发送方使接收方的接收缓存溢出的可能性。简单来说流量控制的目的就是协调发送方的数据发送速度，使其与接收方的数据处理速度相匹配，避免数据丢失，那么如何实现流量控制呢？

3.2 早期的流量控制模式——停止-等待模式 (stop-wait)

==================================

顾名思义就是发送方在发送一个数据包后就停止发送，等待对方响应 ACK，然后才能继续发送数据。这种模式的具体实现为 Positive Acknowledgment With Retransmission (PAR)，意为带重传的肯定确认协议，其实现方式如下图所示：

如果你正在准备面试TCP，看这一篇就够了

PAR 示意图

这种实现很简单，发送方在发送数据包 (图中的msg)时会设置一个计时器，然后等待接收方的 ACK，接收方在收到数据后会返回 ACK 作为应答，发送方在收到 ACK 后会发送下一个数据包。如果由于网络原因造成数据包或者 ACK 丢失时，计时器会超时，然后发送方会重新发送未被确认的数据包。可以看到，这种模式虽然可以确保数据传输的可靠性，但是有个致命的缺点，那就是效率太低？如果是你，你会怎么对这个方案进行优化呢？

既然每次发送只一个数据包效率太低，那就多发送几个，然后给这些数据包编上号，接收端必须对每一个包进行确认，这样设备 A 一次多发送几个片段，而不必等候 ACK，同时接收端也要告知它能够收多少，这样发送端发起来也有个限制，当然还需要保证顺序性，不要乱序，对于乱序的状况，我们可以允许等待一定情况下的乱序，比如说先缓存提前到的数据，然后去等待需要的数据，如果一定时间没来就丢掉乱序的数据，来保证顺序性，这样的话，数据传输效率就可以大大提高。不过 TCP 也没有采用这种方案，而是在此基础上实现更加复杂的滑动窗口。

3.3 滑动窗口

========

首先给大家推荐一个视频，讲得很不错

https://www.bilibili.com/vide…

我们可以把发送方的发送缓存中的字节分为以下四类，每个编号对应一个字节：

如果你正在准备面试TCP，看这一篇就够了

发送缓存中的字节分类

第一类：已发送且已确认，这些数据已经发送成功并已经被确认的数据，比如图中的前31个bytes，这些数据其实的位置是在窗口之外了，下一步将被移出发送缓存。窗口内顺序最低的字节被确认之后，窗口左边界会向右移动，称为窗口合拢。
第二类：已发送但未收到确认，这部分数据已经被发送出去，但是还没有收到接收端的 ACK，认为并没有完成发送，这部分数据属于窗口内的数据。
第三类：未发送但是接收方已经准备好接收，这部分是尽快发送的数据，这部分数据已经被加载到缓存中，也在发送窗口中，正在等待发送，其实这个窗口是完全有接收方告知的，接收方告知当前可以接受这些数据，所以发送方需要尽快的发送。
第四类：未发送且接收方未准备好接收，这些数据属于未发送，同时接收端也不允许发送的，因为这些数据已经超出了发送端所接收的范围。

3.3.1 发送窗口和接收窗口

===============

如果你正在准备面试TCP，看这一篇就够了

发送窗口

发送窗口：图中的黑色框就是发送方的发送窗口，其大小由两个因素决定：1、接收方的提供的窗口大小 (TCP 报文段首部中的 window 字段)，发送方在三次握手阶段首次得到这个值，之后的通信过程中接收方会根据自己的可用缓存对这个值进行动态调整；2、发送方会根据网络情况维护一个拥塞窗口变量 (后文介绍)。发送窗口的大小取这两个值的最小值。对于发送方来说，发送窗口分为两部分，分别是已经发送的部分（已经发送了，但是没有收到ACK）和可用窗口，接收端允许发送但是没有发送的那部分称为可用窗口。

接收窗口：对于接收端也是有一个接收窗口的，类似发送端，接收端的数据有3个分类，因为接收端并不需要等待ACK所以它没有类似的接收并确认了的分类，情况如下

Received and ACK Not Send to Process：这部分数据属于接收了数据但是还没有被上层的应用程序接收；
Received Not ACK: 已经接收，但是还没有回复 ACK；
Not Received：有空位，还没有被接收的数据。

3.3.2 滑动窗口是如何滑动的？

=================

如果你正在准备面试TCP，看这一篇就够了

滑动窗口的滑动过程

累积确认概念：TCP 并不是每一个报文段都会回复一个 ACK ，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送 1 个 ACK，这称为累积确认。比如说发送方有 1/2/3 3 个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候 2/3 报文段就只能放在缓存中等待报文1的空洞被填上，如果报文段1一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个 ACK 对第3个报文段进行确认，就代表对这三个报文段全部进行了确认。

下面举例说明一下窗口滑动的过程：

在握手过程中，接收方通告的窗口大小为20字节，所以发送方将发送窗口大小设置为20字节。
从图中的"上一个发送窗口的位置"(灰色虚线框)说起， 32-51号字节恰好处于发送窗口中，恰好20个字节，假设 TCP 将其分为 4 个报文段进行发送，每个报文段 5 个字节数据，分别记为 seg1 32-36, seg2 37-41, seg3 42-46, seg4 47-51。
TCP 将有序发送 seg1、seg2、seg3和seg4四个报文段，如果这四个报文段都顺利到达接收方 (图中并不是这样)，接收方将发回一个累积确认的 ACK 报文段，其中 ack = 52，代表希望收到下一个报文段的起始字节编号，报文段中也会继续通告窗口大小，如果还是20字节，那么发送方的窗口将整体向右移动20字节，如果通告的窗口值变小，比如变成15，那么发送窗口左边界移动20字节，右边界移动15字节。
如果在发送过程中 seg2 报文段丢失，而其他三个报文段正常到达接收方，那么接收方会现接受这三个报文段，然后返回 ACK 报文段，ack = 37，表示希望收到的下一个报文段的起始字节号为37，也就是seg2报文段。如果通告窗口值未发生变化，发送方在收到 ACK 后会将窗口整体右移5个字节，也就变成了图中的位置。
由于 seg2 还未收到 ACK，当重传计时器超时后，发送方会重新发送 seg2，此时52-56号字节又落到了发送窗口中，TCP 将其封装成报文段进行发送，如果接收方全部顺利收到，会返回一个累积确认的 ACK，ack = 57，表示希望收到的喜爱个报文段的起始字节号为57。

接下来就是重复上述过程，直到 TCP 字节流的所有数据发送完毕。在这个过程中，接收方会根据自己接收缓存的剩余空间动态调整窗口值，对发送方进行流量控制。文字描述可能不够直观，大家可以参考上文推荐的视频。另外推荐一个动图演示的网站动画地址，可以观看滑动窗口的动态效果，如下图 (此演示未考虑丢包的情况)：

如果你正在准备面试TCP，看这一篇就够了

滑动窗口动画效果

四、TCP 的拥塞控制

===========

4.1 什么是拥塞控制？

============

当数据从一个大的管道 (比如一个快速局域网)向一个较小的管道 (比如较慢的广域网)发送的时候就会发生拥塞，还有一种情况就是当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时，也会发生拥塞。举个例子就好理解了，第一种情况就好像源源不断的车流从八车道进入四车道，如果不进行控制，必然造成道路拥堵；第二种情况类似于很多车辆汇入十字路口，如果进的速度大于出的速度，再不加以控制，必然也会造成拥堵。于是 TCP 提供了相应的机制来应对这种情况，也就是 TCP 的拥塞控制。

4.2 如何实现拥塞控制？

=============

TCP 一共使用了四种算法来实现拥塞控制：1、慢开始 (slow-start)；2、拥塞避免 (congestion avoidance)；3、快速重传 (fast retransmit)；4、快速恢复 (fast recovery)。

这里先介绍一下拥塞窗口 (congestion window，简写为 cwnd)的概念：拥塞窗口是由发送方根据网络状况维护的一个变量，用于控制自己的数据发送速率。前文提到了发送方的发送窗口受两个变量约束，一是接收方通告的窗口大小值，二就是发送方自身的拥塞窗口，实际的发送窗口大小取二者最小值。

如果你正在准备面试TCP，看这一篇就够了

慢开始和拥塞避免

4.2.1 慢开始（慢启动）

==============

如图所示，在刚开始，TCP 采用慢开始算法。慢开始不是指拥塞窗口的增长速度慢(增长速度是指数增长，非常快)，而是指 TCP 开始发送设置 cwnd=1。思路就是不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。这里用报文段的个数的拥塞窗口大小举例说明慢启动算法，实时拥塞窗口大小是以字节为单位的。为了防止 cwnd 增长过大引起网络拥塞，设置一个慢开始门限(slow start threshold，简写为 ssthresh) ，

当cnwd < ssthresh，使用慢开始算法

当 cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法

当 cnwd > ssthresh，使用拥塞避免算法

4.2.2 拥塞避免

==========

当拥塞窗口大小达到初始 ssthresh 值时，转而采用拥塞避免算法。拥塞避免并非完全能够避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞，思路：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口加一。无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理)，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为 1，执行慢开始算法。

4.2.3 快速重传

==========

如果你正在准备面试TCP，看这一篇就够了

TCP Reno 应用了四种算法

有时候的发送方未收到某个报文段的确认也并一定就说明一定是出现了网络拥塞，也可能是其他原因，所以直接执行慢开始算法会影响整体效率，后来的 TCP Reno 版本解决了这一问题，那就是采用快速重传和快速恢复算法。

快速重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)，而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量。

4.2.4 快速恢复

==========

当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。但是接下去并不执行慢开始算法。考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。