2021 秋季最新前端面试题

亦凉 2022-09-11 15:27 381阅读 0赞

*  **1. HTTP 常用的请求方式，区别和用途？**
    
     *  GET: 发送请求，获取服务器数据
     *  POST：向 URL 指定的资源提交数据
     *  PUT：向服务器提交数据，以修改数据
     *  HEAD: 请求页面的首部，获取资源的元信息
     *  DELETE：删除服务器上的某些资源。
     *  CONNECT：建立连接隧道，用于代理服务器；
     *  OPTIONS：列出可对资源实行的请求方法，常用于跨域
     *  TRACE：追踪请求 - 响应的传输路径
 *  **2. HTTP 常用的状态码及含义？**
    
     *  1xx：接受的请求正在处理 （信息性状态码）
     *  2xx：表示请求正常处理完毕 （成功状态码）
     *  3xx：表示重定向状态，需要重新请求 （重定向状态码）
     *  4xx：服务器无法处理请求 （客户端错误状态码）
     *  5xx：服务器处理请求出错 （服务端错误状态码）
        
        常用状态码如下：
        
         *  101 切换请求协议，从 HTTP 切换到 WebSocket
         *  200 请求成功，表示正常返回信息。
         *  301 永久重定向，会缓存
         *  302 临时重定向，不会缓存
         *  400 请求错误
         *  403 服务器禁止访问
         *  404 找不到与 URI 相匹配的资源。
         *  500 常见的服务器端错误
 *  **3.从浏览器地址栏输入 url 到显示主页的过程**
    
     *  DNS 解析，查找真正的 ip 地址
     *  与服务器建立 TCP 连接
     *  发送 HTTP 请求
     *  服务器处理请求并返回 HTTP 报文
     *  浏览器解析渲染页面
     *  连接结束
    
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]
 *  **4.如何理解 HTTP 协议是无状态的**
    
    每次 HTTP 请求都是独立的，无相关的，默认不需要保存上下文信息的。我们来看个便于理解的例子：
    
    **有状态：**
    
     *  A：今天吃啥子？
     *  B：罗非鱼！
     *  A：味道怎么样呀？
     *  B：还不错，好香。
    
    **无状态**：  
    A：今天吃啥子？  
    B：罗非鱼！  
    A：味道怎么样呀？  
    B：？啊？啥？什么鬼？什么味道怎么样？
    
    **加下 cookie 这玩意：**
    
     *  A：今天吃啥子？
     *  B：罗非鱼
     *  A：你今天吃的罗非鱼味道怎么样呀？
     *  B：还不错，好香。
 *  **5.HTTP 1.0，1.1，2.0 的版本区别**
    
    **HTTP 1.0**
    
     *  HTTP 1.0 规定浏览器与服务器只保持**短暂的连接**，浏览器的每次请求都需要与服务器建立一个 TCP 连接，服务器完成请求处理后立即断开 TCP 连接。它也可以强制开启长链接，例如设置 Connection: keep-alive 这个字段
    
    **HTTP 1.1**
    
     *  引入了长连接，即 **TCP 连接默认不关闭，可以被多个请求复用**。
     *  引入了管道机制（pipelining），即在同一个 TCP 连接里面，客户端可以同时发送多个请求。
     *  缓存处理，引入了更多的缓存控制策略，如 Cache-Control、Etag/If-None-Match 等。
     *  错误状态管理，新增了 24 个错误状态响应码，如 409 表示请求的资源与资源的当前状态发生冲突。
    
    **HTTP 2**
    
     *  采用了**多路复用**，即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。
     *  服务端推送，HTTP 2 允许服务器未经请求，主动向客户端发送资源
 *  **6.说下计算机网络体系结构**
    
     *  计算机网路体系结构主要有 ISO 七层模型、TCP/IP 四层模型、五层体系结构

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]

*  **ISO 七层模型**
    
    > ISO 七层模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系。
    
     *  应用层：网络服务与最终用户的一个接口，协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
     *  表示层：数据的表示、安全、压缩。
     *  会话层：建立、管理、终止会话。对应主机进程，指本地主机与远程主机正在进行的会话
     *  传输层：定义传输数据的协议端口号，以及流控和差错校验。协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层
     *  网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。协议有：ICMP IGMP IP（IPV4 IPV6）
     *  数据链路层：建立逻辑连接、进行硬件地址寻址、差错校验等功能。
     *  物理层：建立、维护、断开物理连接。
 *  **TCP/IP 四层模型**
    
     *  应用层：对应于 OSI 参考模型的（应用层、表示层、会话层），为用户提供所需要的各种服务，例如：FTP、Telnet、DNS、SMTP 等
     *  传输层：对应 OSI 的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。定义了 TCP 和 UDP 两层协议。
     *  网际层：对应于 OSI 参考模型的网络层，主要解决主机到主机的通信问题。三个主要协议：网际协议（IP）、互联网组管理协议（IGMP）和互联网控制报文协议（ICMP）
     *  网络接口层：与 OSI 参考模型的数据链路层、物理层对应。它负责监视数据在主机和网络之间的交换。
 *  **五层体系结构**
    
     *  应用层：通过应用进程间的交互来完成特定网络应用。对应于 OSI 参考模型的（应用层、表示层、会话层），应用层协议很多，如域名系统 DNS，HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。
     *  传输层：负责向两台主机进程之间的通信提供通用的数据传输服务。对应 OSI 参考模型的传输层，协议有传输控制协议 TCP 和 用户数据协议 UDP。
     *  网络层：对应 OSI 参考模型的的网络层
     *  数据链路层：对应 OSI 参考模型的的数据链路层
     *  物理层：对应 OSI 参考模型的的物理层层。在物理层上所传送的数据单位是比特。物理层 (physical layer) 的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。
 *  **7.POST 和 GET 有哪些区别？**
    
     *  **请求参数**：GET 把参数包含在 URL 中，用 & 连接起来；POST 通过 request body 传递参数。
     *  \*\*请求缓存：\*\*GET 请求会被主动 Cache，而 POST 请求不会，除非手动设置。
     *  **收藏为书签**：GET 请求支持收藏为书签，POST 请求不支持。
     *  \*\*安全性：\*\*POST 比 GET 安全，GET 请求在浏览器回退时是无害的，而 POST 会再次请求。
     *  \*\*历史记录：\*\*GET 请求参数会被完整保留在浏览历史记录里，而 POST 中的参数不会被保留。
     *  \*\*编码方式：\*\*GET 请求只能进行 url 编码，而 POST 支持多种编码方式。
     *  **参数数据类型**：GET 只接受 ASCII 字符，而 POST 没有限制数据类型。
     *  **数据包:** GET 产生一个 TCP 数据包；POST 可能产生两个 TCP 数据包。
 *  **8.在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？**
    
     *  在 HTTP 中响应体的 Connection 字段指定为 **keep-alive**
 *  **9.HTTP 如何实现长连接？在什么时候会超时？**
    
     *  **HTTP 如何实现长连接**？
        
         *  HTTP 分为长连接和短连接，其实**本质上说的是 TCP 的长短连接**。TCP 连接是一个双向的通道，它是可以保持一段时间不关闭的，因此 TCP 连接才有真正的长连接和短连接这一个说法。
         *  长连接是指的是 TCP 连接，而不是 HTTP 连接。
         *  TCP 长连接可以复用一个 TCP 连接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，短连接可能还需要请求后续的 JS/CSS/ 图片等
        
        > 要实现 HTTP 长连接，在响应头设置 **Connection 为 keep-alive**，HTTP1.1 默认是长连接，而 HTTP 1.0 协议也支持长连接，但是默认是关闭的。
 *  它们主要区别：
    
     *  数据是否加密: Http 是明文传输，HTTPS 是密文
     *  默认端口: Http 默认端口是 80，Https 默认端口是 443
     *  资源消耗：和 HTTP 通信相比，Https 通信会消耗更多的 CPU 和内存资源，因为需要加解密处理；
     *  安全性: http 不安全，https 比较安全。
 *  **Https 流程是怎样的？**
    
     *  HTTPS = HTTP + SSL/TLS，即用 SSL/TLS 对数据进行加密和解密，Http 进行传输。
     *  SSL，即 Secure Sockets Layer（安全套接层协议），是网络通信提供安全及数据完整性的一种安全协议。
     *  TLS，即 Transport Layer Security (安全传输层协议)，它是 SSL 3.0 的后续版本。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16]

1.  用户在浏览器里输入一个 https 网址，然后连接到 server 的 443 端口。
2.  服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。
3.  服务器将自己的数字证书（含有公钥）发送给客户端。
4.  客户端收到服务器端的数字证书之后，会对其进行检查，如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。
5.  客户端会发起 HTTPS 中的第二个 HTTP 请求，将加密之后的客户端密钥发送给服务器。
6.  服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
7.  服务器将加密后的密文返回给客户端。
8.  客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。

*  **12. 对称加密与非对称加密有什么区别**
    
     *  **对称加密**：加密和解密使用相同密钥的加密算法。  
        ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16 1]
     *  **非对称加密**：非对称加密算法需要两个密钥（公开密钥和私有密钥）。 公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。  
        ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]
 *  **13.什么是 XSS 攻击，如何避免？**

XSS 攻击，全称**跨站脚本攻击（Cross-Site Scripting）**，这会与层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆，因此有人将跨站脚本攻击缩写为 XSS。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意攻击用户的特殊目的。XSS 攻击一般分三种类型：**存储型 、反射型 、DOM 型 XSS**

**XSS 是如何攻击的？**

拿反射型举个例子吧，流程图如下：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16 2]

*  **如何解决 XSS 攻击问题**
    
     *  不相信用户的输入，对输入进行过滤，过滤标签等，只允许合法值。
     *  HTML 转义
     *  对于链接跳转，如 `<a href="xxx">` 等，要校验内容，禁止以 script 开头的非法链接。
     *  限制输入长度等等
 *  **14.请详细介绍一下 TCP 的三次握手机制**

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]

*  开始客户端和服务器都处于 CLOSED 状态，然后服务端开始监听某个端口，进入 LISTEN 状态
    
     *  第一次握手 (SYN=1, seq=x)，发送完毕后，客户端进入 SYN\_SEND 状态
     *  第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器端进入 SYN\_RCV 状态。
     *  第三次握手 (ACK=1，ACKnum=y+1)，发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时
 *  **15.TCP 握手为什么是三次，不能是两次？不能是四次？**
    
     *  TCP 握手为什么是三次呢？为了方便理解，我们以谈恋爱为个例子：两个人能走到一起，最重要的事情就是相爱，就是**我爱你，并且我知道，你也爱我**，接下来我们以此来模拟三次握手的过程：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_15_color_FFFFFF_t_70_g_se_x_16_pic_center]

*  **为什么握手不能是两次呢？**  
    如果只有两次握手，女孩子可能就不知道，她的那句我也爱你，男孩子是否收到，恋爱关系就不能愉快展开。
 *  **为什么握手不能是四次呢？**  
    因为握手不能是四次呢？因为三次已经够了，三次已经能让双方都知道：你爱我，我也爱你。而四次就多余了。
 *  **16.TCP 四次挥手过程？**
    
     *  第一次挥手 (FIN=1，seq=u)，发送完毕后，客户端进入 FIN\_WAIT\_1 状态
     *  第二次挥手 (ACK=1，ack=u+1,seq =v)，发送完毕后，服务器端进入 CLOSE\_WAIT 状态，客户端接收到这个确认包之后，进入 FIN\_WAIT\_2 状态
     *  第三次挥手 (FIN=1，ACK1,seq=w,ack=u+1)，发送完毕后，服务器端进入 LAST\_ACK 状态，等待来自客户端的最后一个 ACK。
     *  第四次挥手 (ACK=1，seq=u+1,ack=w+1)，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME\_WAIT 状态，**等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后**，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]

*  **17.TCP 四次挥手过程中，客户端为什么需要等待 2MSL, 才进入 CLOSED 状态**
    
     *  2MSL，2 Maximum Segment Lifetime，即两个最大段生命周期

>  *  1 个 MSL 保证四次挥手中主动关闭方最后的 ACK 报文能最终到达对端
>  *  1 个 MSL 保证对端没有收到 ACK 那么进行重传的 FIN 报文能够到达

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]

*  **18.为什么需要四次挥手？**

> 小明和小红打电话聊天，通话差不多要结束时，小红说 “我没啥要说的了”，小明回答 “我知道了”。但是小明可能还会有要说的话，小红不能要求小明跟着自己的节奏结束通话，于是小明可能又叽叽歪歪说了一通，最后小明说 “我说完了”，小红回答 “知道了”，这样通话才算结束。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]

**19. Session 和 Cookie 的区别。**

**我们先来看 Session 和 Cookie 的定义：**

*  Cookie 是服务器发送到用户浏览器，并保存在浏览器本地的一小块文本串数据。它会在浏览器下次向同一服务器再发起请求时，被携带发送到服务器。通常，它用于告知服务端两个请求是否来自同一浏览器，一样用于保持用户的登录状态等。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
 *  session 指的就是服务器和客户端一次会话的过程。Session 利用 Cookie 进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个 Cookie，当这个 Session 结束时，其实就是意味着这个 Cookie 就过期了。Session 对象存储着特定用户会话所需的属性及配置信息。

**Session 和 Cookie 到底有什么不同呢？**

*  存储位置不一样，Cookie 保存在客户端，Session 保存在服务器端。
 *  存储数据类型不一样，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
 *  有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般有效时间较短，客户端关闭或者 Session 超时都会失效。
 *  隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
 *  存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

来看个图吧：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]

> 用户第一次请求服务器时，服务器根据用户提交的信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。  
> 当用户第二次访问服务器时，请求会自动判断此域名下是否存在 Cookie 信息，如果存在，则自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

*  **20.TCP 是如何保证可靠性的**
    
     *  首先，TCP 的连接是基于三次握手，而断开则是四次挥手。确保连接和断开的可靠性。
     *  其次，TCP 的可靠性，还体现在有状态 ;TCP 会记录哪些数据发送了，哪些数据被接受了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
     *  再次，TCP 的可靠性，还体现在可控制。它有数据包校验、ACK 应答、超时重传 (发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。
 *  **21TCP 和 UDP 的区别**
    
     *  TCP 面向连接（（如打电话要先拨号建立连接）;UDP 是无连接的，即发送数据之前不需要建立连接。
     *  TCP 要求安全性，提供可靠的服务，通过 TCP 连接传送的数据，不丢失、不重复、安全可靠。而 UDP 尽最大努力交付，即不保证可靠交付。
     *  TCP 是点对点连接的，UDP 一对一，一对多，多对多都可以
     *  TCP 传输效率相对较低，而 UDP 传输效率高，它适用于对高速传输和实时性有较高的通信或广播通信。
     *  TCP 适合用于网页，邮件等；UDP 适合用于视频，语音广播等
     *  TCP 面向字节流，UDP 面向报文
 *  **22.TCP 报文首部有哪些字段，说说其作用**
    
     *  16 位端口号：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序
     *  32 位序号：一次 TCP 通信（从 TCP 连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。
     *  32 位确认号：用作对另一方发送的 tcp 报文段的响应。其值是收到的 TCP 报文段的序号值加 1。
     *  4 位头部长度：表示 tcp 头部有多少个 32bit 字（4 字节）。因为 4 位最大能标识 15，所以 TCP 头部最长是 60 字节。
     *  6 位标志位：URG (紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）
     *  16 位窗口大小：是 TCP 流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。
     *  16 位校验和：由发送端填充，接收端对 TCP 报文段执行 CRC 算法以检验 TCP 报文段在传输过程中是否损坏。注意，这个校验不仅包括 TCP 头部，也包括数据部分。这也是 TCP 可靠传输的一个重要保障。
     *  16 位紧急指针：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP 的紧急指针是发送端向接收端发送紧急数据的方法。
    
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 8]
 *  **23.HTTP 状态码 301 和 302 的区别？**
    
     *  301（永久移动）请求的网页已被永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
     *  302：（临时移动）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。
 *  **HTTP 状态码 301 与 302 的区别：**

> 它们之间关键区别在，资源是否存在有效性；  
> 301 资源还在只是换了一个位置，返回的是新位置的内容；  
> 302 资源暂时失效，返回的是一个临时的代替页上。

*  **24.HTTP 状态码 301 与 302 的区别：**

1.  它们之间关键区别在，资源是否存在有效性；
2.  301 资源还在只是换了一个位置，返回的是新位置的内容；
3.  302 资源暂时失效，返回的是一个临时的代替页上。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 9]

RTT 就是，一个数据包从发出去到回来的时间，即**数据包的一次往返时间**。超时重传时间，就是 **Retransmission Timeout ，简称 RTO**。

**RTO 设置多久呢？**

*  如果 RTO 比较小，那很可能数据都没有丢失，就重发了，这会导致网络阻塞，会导致更多的超时出现。
 *  如果 RTO 比较大，等到花儿都谢了还是没有重发，那效果就不好了。

一般情况下，RTO 略大于 RTT，效果是最好的。一些小伙伴会问，超时时间有没有计算公式呢？有的！有个标准方法算 RTO 的公式，也叫 Jacobson / Karels 算法。我们一起来看下计算 RTO 的公式

1.  先计算 SRTT（计算平滑的 RTT）

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加权平均

1.  再计算 RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //计算 SRTT 与真实值的差距

1.  最终的 RTO

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR

其中，`α = 0.125，β = 0.25， μ = 1，∂ = 4`，这些参数都是大量结果得出的最优参数。

但是，超时重传会有这些缺点：

*  当一个报文段丢失时，会等待一定的超时周期然后才重传分组，增加了端到端的时延。
 *  当一个报文段丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。

并且，TCP 有个策略，就是超时时间间隔会加倍。超时重传需要**等待很长时间**。因此，还可以使用**快速重传机制**。

**快速重传**

**快速重传**机制，它不以时间驱动，而是以数据驱动。它基于接收端的反馈信息来引发重传。

一起来看下快速重传流程：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 10]

发送端发送了 1，2，3，4，5,6 份数据:

1.  第一份 Seq=1 先送到了，于是就 Ack 回 2；
2.  第二份 Seq=2 也送到了，假设也正常，于是 ACK 回 3；
3.  第三份 Seq=3 由于网络等其他原因，没送到；
4.  第四份 Seq=4 也送到了，但是因为 Seq3 没收到。所以 ACK 回 3；
5.  后面的 Seq=4,5 的也送到了，但是 ACK 还是回复 3，因为 Seq=3 没收到。
6.  发送端连着收到三个重复冗余 ACK=3 的确认（实际上是 4 个，但是前面一个是正常的 ACK，后面三个才是重复冗余的），便知道哪个报文段在传输过程中丢失了，于是在定时器过期之前，重传该报文段。
7.  最后，接收到收到了 Seq3，此时因为 Seq=4，5，6 都收到了，于是 ACK 回 7.

但**快速重传**还可能会有个问题：ACK 只向发送端告知最大的有序报文段，到底是哪个报文丢失了呢？**并不确定**！那到底该重传多少个包呢？

是重传 Seq3 呢？还是重传 Seq3、Seq4、Seq5、Seq6 呢？因为发送端并不清楚这三个连续的 ACK3 是谁传回来的。

**带选择确认的重传（SACK）**

为了解决快速重传的问题：应该重传多少个包 ? TCP 提供了 **SACK 方法**（带选择确认的重传，Selective Acknowledgment）。

**SACK 机制**就是，在快速重传的基础上，接收端返回最近收到的报文段的序列号范围，这样发送端就知道接收端哪些数据包没收到，酱紫就很清楚该重传哪些数据包啦。SACK 标记是加在 **TCP 头部选项**字段里面的。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 11]

如上图中，发送端收到了三次同样的 ACK=30 的确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 30~39 这段数据丢失，于是重发时就只选择了这个 30~39 的 TCP 报文段进行重发。

*  **D-SACK**
    
     *  D-SACK，即 Duplicate SACK（重复 SACK），在 SACK 的基础上做了一些扩展，，主要用来告诉发送方，有哪些数据包自己重复接受了。DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。来看个图吧：  
        ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 12]
 *  **25.IP 地址有哪些分类？**
    
    一句话概括，**IP 地址 = 网络号 + 主机号。**
    
     *  网络号：它标志主机（或路由器）所连接到的网络，网络地址表示属于互联网的哪一个网络
     *  主机号：它标志该主机（或路由器），主机地址表示其属于该网络中的哪一台主机
 *  IP 地址 分为 A，B，C，D，E 五大类：
    
     *  A 类地址 (1~126)：以 0 开头，网络号占前 8 位，主机号占后 24 位。
     *  B 类地址 (128~191)：以 10 开头，网络号占前 16 位，主机号占后 16 位。
     *  C 类地址 (192~223)：以 110 开头，网络号占前 24 位，主机号占后 8 位。
     *  D 类地址 (224~239)：以 1110 开头，保留位多播地址。
     *  E 类地址 (240~255)：以 11110 开头，保留位为将来使用

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 13]

*  **26.WebSocket 与 socket 的区别**
    
     *  Socket = IP 地址 + 端口 + 协议。  
        具体来说，Socket 是一套标准，它完成了对 TCP/IP 的高度封装，屏蔽网络细节以方便开发者更好地进行网络编程。
     *  WebSocket 是一个持久化的协议，它是伴随 HTTP5 而出的协议，用来解决 http 不支持持久化连接的问题。
     *  Socket 一个是网编编程的标准接口，而 WebSocket 是应用层通信协议。
 *  **27.Http 请求的过程与原理**
    
     *  HTTP 是一个基于 TCP/IP 协议来传递数据的超文本传输协议，传输的数据类型有 HTML 文件，、图片文件等。以访问百度有例子，看下一次 Http 的请求过程

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 14]

1.  客户端进行 DNS 域名解析，得到对应的 IP 地址
2.  根据这个 IP，找到对应的服务器建立连接（三次握手）
3.  建立 TCP 连接后发起 HTTP 请求（一个完整的 http 请求报文）
4.  服务器响应 HTTP 请求，客户端得到 html 代码
5.  客户端解析 html 代码，用 html 代码中的资源 (如 js,css, 图片等等) 渲染页面。
6.  服务器关闭 TCP 连接（四次挥手）

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/85e8ea70f928475b96deaa4d31901fe2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220828/386c195ed5f3477294acf87fce6f3107.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/147b520fd12d431cb665ca0b40f272bc.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/b5abaa1951774e85b733faac918ada6c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]: /images/20220828/4be84e466abc4dc6b51c3cec43b4a044.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/ee776293512d49239aab919c8ff026f3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]: /images/20220828/ecc53dad0ed345e78c2a31235f7c62e2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_15_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/5abed156f31044d9ade6ecf125b0f4c9.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]: /images/20220828/8ca83abcf2ef493399b41b548e320aca.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]: /images/20220828/3ff90509e97743eba3a6b38c555154d7.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]: /images/20220828/913e9eed424f4d6abce690d07184a510.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]: /images/20220828/70161a98fdcd4a3a94e9b9e3c9725ca4.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 8]: /images/20220828/2f93537bf50c44e1b4c4d3d8f32b6065.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 9]: /images/20220828/836a4c7720fc48718c611ad3ccb9cc67.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 10]: /images/20220828/c7f38f28cfc748bda21207bcf5fa5833.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 11]: /images/20220828/a0c9da84b9dc463db67b40fafb48401b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 12]: /images/20220828/42ae0794f41c4d32a0e144f6b022933e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 13]: /images/20220828/60af385d667540b4a6e137fb588c252b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YmN56uv6YWx57Sr_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 14]: /images/20220828/08aa8ebcdc874c87a99b76e44afeaf55.png