SPRINT-8

小竹子BAMBOO
137 阅读23分钟

306、从输入 URL 到页面加载完成

1、浏览器的地址栏输入URL并按下回车。
2、浏览器查找当前URL是否存在缓存，并比较缓存是否过期。
3、DNS解析URL对应的IP。
4、根据IP建立TCP连接（三次握手）。
5、HTTP发起请求。
6、服务器处理请求，浏览器接收HTTP响应。
7、渲染页面，构建DOM树。
8、关闭TCP连接（四次挥手）

技术解读

（1）**解析URL：**首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

（2）**缓存判断：**浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。

（3）DNS解析： 下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。

（4）获取MAC地址（选说） 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。

（5）TCP三次握手： ，确认客户端与服务器的接收与发送能力，下面是 TCP 建立连接的三次握手的过程，首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。

（6）**HTTPS握手（选说）：**如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

（7）发送HTTP请求：服务器处理请求,返回HTTP报文(响应)(文件)

（8）页面渲染： 浏览器首先会根据 html 文件(响应) 建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。

（9）**TCP四次挥手：**最后一步是 TCP 断开连接的四次挥手过程。若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

307、HTTP中的optins预检请求

在Web开发中，CORS（Cross-Origin Resource Sharing），跨域资源共享是一个重要的安全机制。当前页面和请求的网址不在同一个域下时，浏览器会拦截跨域请求并引发CORS问题。

CORS预检请求（Preflighted Request），是指在 CORS 机制中，浏览器在发送真正的跨域请求之前，会先发送一次预检请求（OPTIONS请求），用于检查服务器是否允许该跨域请求。

预检请求的作用是检测跨域请求的安全性。

CORS机制要求跨域请求必须满足两个条件：

  • 第一，请求方法必须是POST、GET或者HEAD；
  • 第二，请求Header的信息必须是符合规定的简单Header或者在一个被允许的表单数据（application/x-www-form-urlencoded、multipart/form-data、text/plain）中加入自定义的Header信息。而对于跨域请求中的一些非简单Header和请求方法（比如PUT、DELETE、PATCH等），则需要先发送一个预检请求到服务器，并等待服务器确认后再进行真正的跨域请求。

预检请求使用OPTIONS方法，因为该方法与实际请求的方法类似，但只会询问服务端能否接收真正的跨域请求。

一旦预检请求得到服务器的回应，响应结果中包含了请求方法（method）、请求Header（Headers）以及Content-Type等信息，这些信息通常由服务器在响应中的Access-Control-Allow-*字段返回，客户端才能确定是否可以安全地发送真正的跨域请求。

总之，CORS机制下的预检请求是一种安全机制，帮助保护Web资源不被随意访问。对于 Web 开发者而言，需要注意跨域访问时的规范和要求，以便在CORS机制下更好地处理跨域请求。

308、跨域的场景下一定会发OPTION吗

不一定，当跨域AJAX请求满足一定条件时，不需要发送OPTION请求。

根据CORS规范，只有当跨域AJAX请求满足以下条件之一时，浏览器才会自动发起OPTION请求进行预检：

  1. 使用了并非GET、HEAD或POST的HTTP方法。如PUT、DELETE等。
  2. 使用了POST请求方法，并且Content-Type的值不是application/x-www-form-urlencoded、multipart/form-data、text/plain中的一种。
  3. 使用了自定义请求头（除了以下几种常见字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type），即使用了未在标准中定义的自定义请求头。

对于这三种情况之外的跨域AJAX请求都属于简单请求，而且简单请求也不需要设置额外的请求头，因此浏览器会自动将Origin字段添加到HTTP头部中，然后直接发送AJAX请求。如果服务器允许该跨域请求，则在响应头中添加Access-Control-Allow-Origin字段来表明同意跨域访问，否则浏览器将抛出跨域访问错误。因此在这种情况下，OPTION预检请求是没有必要的。

309、HTTP请求都有哪些方法

GET：请求获取指定资源的表示形式，可以理解为“读取”，常用于数据的查找和读取操作。
POST：向指定资源提交要被处理的数据，可以理解为“修改”或“创建”，常用于数据的修改和创建操作。
PUT：将请求的资源的全部替换为目标资源，可以理解为“更新”，常用于数据的更新操作。
DELETE：删除指定的资源，可以理解为“删除”，常用于数据的删除操作。
HEAD：只返回响应头，不返回响应体，可以用于检查资源是否存在及资源的元信息。
OPTIONS：返回服务器支持的HTTP请求方法和HTTP首部字段。

310、Cookie有哪些字段呢？为啥有一个http only？

HttpOnly属性是为了提高Web应用的安全性而设计的。以下是引入HttpOnly的主要原因：

  • 防止跨站脚本攻击（XSS）：

    • 如果攻击者成功注入了恶意脚本到页面中，HttpOnly可以阻止这些脚本访问和修改Cookie。

  • 减少敏感信息泄露：

    • 通过限制Cookie的JavaScript访问，可以减少敏感信息（如会话标识符）被泄露的风险。

  • 增强安全性：

  • HttpOnly使得Cookie仅能通过HTTP请求被访问，从而减少了通过客户端脚本泄露信息的可能性。

Name

Cookie的名称

Value

Cookie的值

Expires

Cookie的过期时间，指定具体日期

Max-Age

Cookie的有效期，以秒为单位

Domain

Cookie有效的域名

Path

Cookie有效的路径

Secure

指示Cookie仅通过HTTPS传输

HttpOnly

限制Cookie不能通过客户端脚本访问

SameSite

限制Cookie的跨站点请求

Priority

Cookie的优先级，如Low、Medium（默认）、High

最佳实践：

  • 总是设置HttpOnly属性，以提高安全性。
  • 根据需要设置Secure属性，尤其是在传输敏感信息时。
  • 谨慎使用SameSite属性，以防止CSRF攻击。
  • 根据应用需求合理设置Domain和Path属性。

311、HTTP中的Keep-Alive有了解吗？

Keep-Alive是http的一个头部字段Connection中的一个值，它是保证我们的http请求能建立一个持久连接。

也就是说建立一次TCP连接即可进行多次**请求和响应的交互。

它的特点就是只要有一方没有明确提出断开连接，则保持TCP连接状态**，减少TCP连接和断开造成的额外开销。

HTTP/1.0阶段

在HTTP/1.0中所有的连接默认都是关闭的，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

HTTP/1.1阶段

在HTTP/1.1中所有的连接默认都是持久连接的。除非在请求头或响应头中指明要关闭：Connection: Close，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了。

HTTP/2阶段

多路复用：

  • 可以并行交错地发送请求 / 响应，请求/响应之间互不影响，
  • 只使用一个连接即可并行发送多个请求和响应；

312、HTTP/1.0 和 HTTP/1.1 之间有哪些区别

HTTP 1.0 和 HTTP 1.1 之间有以下区别：

  1. 缓存机制：HTTP 1.0 中缺乏强大的缓存处理机制，只支持客户端缓存，而 HTTP 1.1 引入了更为灵活的缓存机制，包括在客户端和服务器端缓存，以及对缓存进行控制的新指令。

  2. 持久连接：HTTP 1.0 中默认使用短连接（每个请求/响应都需要建立一个新的 TCP 连接），而 HTTP 1.1 引入了持久连接，即在单个连接上可以传输多个请求/响应。这大大减少了连接建立的开销，提高了性能。

  3. 超时机制：HTTP 1.0 中没有明确的超时机制，服务器会一直等待客户端发送请求，这容易导致资源的浪费和拥塞。而 HTTP 1.1 中引入了一些新的超时机制，包括连接超时、读取超时和空闲连接超时等。

  4. 错误状态码：HTTP 1.0 只定义了一小部分错误状态码（如404 Not Found），而 HTTP 1.1 定义了更多的错误状态码（如413 Request Entity Too Large）。

  5. 带宽优化：HTTP 1.1 引入了一些新的特性来帮助带宽优化，如分块传输编码（chunked transfer encoding）、Range 请求头支持等。

  6. Host 头部：HTTP 1.0 没有 Host 头部，而 HTTP 1.1 引入了这个头部，使得在一台服务器上托管多个域名成为可能。

313、什么是HTTPS协议

HTTPS (Hypertext Transfer Protocol Secure) 协议是一种在计算机网络上进行安全通信的协议，它由 HTTP 和 SSL/TLS 协议组合而成。

HTTPS 在传输过程中对数据进行了加密处理，能够有效地防止中间人攻击、数据被窃听、数据篡改等问题。与 HTTP 相比，HTTPS 更加安全可靠，适用于传输敏感信息，如银行账户、密码等。

HTTPS 的工作原理如下：

1.浏览器向服务器发起 HTTPS 请求。

2.服务器返回一个公钥证书。

3.浏览器验证证书的有效性和合法性，并提取公钥。

4.浏览器生成一个随机数并使用公钥对其进行加密，发送给服务器。

5.服务器使用私钥解密生成的随机数，然后使用此随机数对整个会话过程中的数据进行加密。

6.服务器将加密后的数据发送给浏览器，浏览器使用随机数解密数据并进行后续的操作。

HTTPS 协议具有以下优点：

1.数据安全：通过加密数据，有效保护了数据的隐私和安全性。

2.身份认证：通过证书机制，可以验证服务器的身份，防止伪造或欺骗。

3.完整性保证：通过数字签名，确保数据在传输过程中不被篡改或损坏。

总之，通过使用 HTTPS 协议，能够保护用户的隐私和安全，确保数据在传输过程中不被泄露、窃取或篡改，是现代网络通信中必不可少的一项技术。

314、TLS/SSL的工作原理

TLS全称安全传输层协议（Transport Layer Security）及其前身安全套接层（Secure Sockets Layer，缩写作SSL） 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

TLS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密。

这三类算法的作用如下：

  • 散列算法用来验证信息的完整性
  • 对称加密算法采用协商的秘钥对数据加密
  • 非对称加密实现身份认证和秘钥协商

315、TLS/SSL 中什么一定要用三个随机数，来生成"会话密钥"

TLS/SSL 中需要使用三个随机数来生成"会话密钥"，以增加加密的安全性。

这三个随机数分别为客户端随机数、服务器随机数和主密钥。

  • 客户端随机数是客户端生成并发送给服务器的一个随机数，
  • 服务器随机数是服务器生成并发送给客户端的另一个随机数，
  • 主密钥则是客户端和服务器共同协商生成的一个密钥。
  • 在TLS/SSL握手过程中，这三个随机数被结合在一起，并被用于生成一个"会话密钥"。

使用三个随机数可以增加加密的难度，避免因为只使用一个随机数而导致的密码破解攻击。同时，这也可以确保每个会话都使用不同的会话密钥，保证了会话的安全性。

316、SSL 连接断开后如何恢复

SSL连接是建立在TCP连接之上的，当SSL连接断开后，TCP连接仍然保持。如果需要恢复SSL连接，可以通过重新握手来实现。SSL重新握手的过程如下：

  1. 客户端向服务器发送一个ClientHello消息，包含一个随机数、支持的加密算法、支持的协议版本等信息。
  2. 服务器收到ClientHello消息后，向客户端发送一个ServerHello消息，包含一个随机数、选择的加密算法、选择的协议版本等信息。如果服务器支持会话恢复，它会在这个消息中包含一个Session ID。
  3. 服务器向客户端发送一个Certificate消息，包含服务器的证书和公钥。
  4. 服务器向客户端发送一个ServerHelloDone消息，表示服务器的握手阶段已经完成。
  5. 客户端校验服务器的证书，生成一个随机数，然后向服务器发送一个ClientKeyExchange消息，包含一个预主密钥。
  6. 客户端使用服务器的公钥加密预主密钥，并向服务器发送一个Finished消息，表示客户端的握手阶段已经完成。
  7. 服务器收到ClientKeyExchange消息后，使用自己的私钥解密预主密钥，生成主密钥，并向客户端发送一个Finished消息，表示服务器的握手阶段已经完成。
  8. 客户端收到服务器的Finished消息后，使用主密钥加密一条握手完成的消息，向服务器发送一个Finished消息，表示SSL连接已经恢复。

需要注意的是，SSL重新握手的过程需要消耗一定的时间和资源，因此应该尽可能避免频繁地进行重新握手。一般情况下，SSL连接的断开和恢复是由网络中断或超时等原因引起的，可以通过重新连接来解决这个问题。

317、HTTPS通信（握手）过程

HTTPS通信过程主要包括以下几个步骤：

  1. 客户端发起请求：客户端向服务器发起HTTPS请求，请求连接到服务器的443端口。这告诉服务器，客户想要建立一个安全的HTTP连接。

  2. 服务器返回证书：服务器会生成一份数字证书，用于证明网站的身份和安全性。该证书包含了网站的公钥，以及其他证书相关信息。

  3. 客户端验证证书：在收到服务器发送的证书后，客户端会对证书进行验证。客户端会检查证书是否是由可信的第三方机构颁发的（即是否是CA机构签发的证书），以及证书中包含的公钥是否可以使用。

  4. 客户端生成会话密钥：如果证书验证成功，客户端会生成一个随机的会话密钥，并使用服务器的公钥进行加密。

  5. 服务器使用私钥解密：服务器使用保存在服务器上的私钥来解密客户端的已经加密的会话密钥。

  6. 通信加密：在完成以上所有步骤后，客户端和服务器可以利用会话密钥加密数据的收发，以确保传输数据的安全性。

在以上步骤中，需要特别注意的是第三步：客户端验证证书。这是因为有些攻击者可能会伪造证书，从而使得客户端认为自己连接了一个安全的网站，实际上却连接到了攻击者控制的恶意网站。因此，客户端必须要对证书进行验证，确保证书的真实性和有效性，以保证所连接的网站是安全的。

318、HTTP和HTTPS协议有什么区别

HTTP（Hypertext Transfer Protocol）和HTTPS（Hypertext Transfer Protocol Secure）是两个常用的互联网通信协议。

HTTP是一种无状态的协议，即客户端和服务器之间的所有通信都是独立的，每个请求都是独立的事务。HTTP使用TCP传输协议进行通信，通信过程中所有的数据都是明文传输的，容易被黑客窃取、篡改或重放攻击等。

HTTPS基于HTTP，但利用了SSL/TLS协议对数据进行加密和认证。通信过程中，客户端和服务器之间的所有数据都会经过加密处理，保障了数据的机密性和完整性。另外，HTTPS采用证书验证机制，可以防止中间人攻击。

HTTP和HTTPS的区别主要有：

  1. 安全性：HTTP不加密传输数据，而HTTPS使用SSL/TLS协议加密数据传输，保障数据的安全性。

  2. 速度：由于HTTPS需要进行加密和解密操作，通信过程中需要进行更多的计算，所以HTTPS比HTTP会略慢一些。

  3. 端口： HTTP使用端口80，而HTTPS使用端口443。

  4. SEO：由于Google等搜索引擎更喜欢安全的网站，HTTPS网站在搜索排名中可能会更有优势。

综上所述，HTTPS相较于HTTP更为安全可靠，因此在数据传输敏感的场景下（如网上支付、个人信息等），建议使用HTTPS来进行通信。

319、对称加密、非对称加密是什么，有什么区别

对称加密和非对称加密是安全传输层里的加密算法

对称加密

  • 对称加密的特点是文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥，
    这种方法在密码学中叫做对称加密算法，对称加密算法使用起来简单快捷，密钥较短，且破译困难
    通信的双⽅都使⽤同⼀个秘钥进⾏加密, 解密。 ⽐如，两个人事先约定的暗号，就属于对称加密。

优点:

  • 计算量小、加密速度快、加密效率高。

缺点:

  • 在数据传送前，发送方和接收方必须商定好秘钥，然后双方保存好秘钥。
  • 如果一方的秘钥被泄露，那么加密信息也就不安全了
  • 最不安全的地方, 就在于第一开始, 互相约定密钥的时候和传递密钥。

使用场景：本地数据加密、https 通信、网络传输等

非对称加密

通信的双方使用不同的秘钥进行加密解密，即秘钥对（私钥 + 公钥）。

特征: 公钥用于加密数据，私钥用于解密数据。

非对称加密的特点是：

  • 优点：非对称加密与对称加密相比其安全性更好
  • 缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

使用场景：https 会话前期、CA 数字证书、信息加密、登录认证等

320、TLS握手做了什么

当客户端与服务器之间进行HTTPS通信时，会首先进行TLS握手，这个过程涉及到的步骤主要有以下几个：

  1. 客户端向服务器发送 Client Hello, 其中包含支持的TLS版本、加密算法等信息；
  2. 服务器收到 Client Hello 后，发送 Server Hello，其中包含选择的TLS版本、加密算法、证书等信息；
  3. 客户端验证服务器证书的有效性，并生成一个随机数，使用公钥加密后发送给服务器；
  4. 服务器使用私钥解密收到的消息，获得客户端发送的随机数，并生成另一个随机数作为加密密钥；
  5. 服务器将加密密钥使用公钥加密后发送给客户端；
  6. 双方使用所选择的加密算法和密钥进行加密通信。

通过TLS握手过程，双方可以建立安全的通信渠道，并使用加密算法保证数据的传输安全性。

321、HTTPS的优缺点

HTTPS的优点包括：

  1. 安全性高：HTTPS采用了SSL/TLS协议进行数据传输，通过数字证书验证和加密技术确保数据传输的安全性，有效防止了黑客攻击、窃听和篡改等安全威胁。

  2. 信任度高：HTTPS采用由可信任的第三方机构颁发的SSL/TLS证书，该证书可以验证网站的真实性和合法性，提高用户对网站的信任度。

  3. SEO友好度高：搜索引擎会优先显示使用HTTPS协议的网站内容，因此使用HTTPS协议可以提高网站的搜索引擎排名和搜索曝光率。

  4. 隐私性好：HTTPS协议使用加密技术可以防止敏感信息泄露，例如用户输入的账号密码等敏感信息。

HTTPS的缺点包括:

  1. 加密解密耗时：HTTPS协议通过复杂的加密算法进行数据加密解密，处理速度较慢，可能导致页面加载速度变慢。

  2. 成本相对较高：采用HTTPS需要购买SSL证书，一般来说成本较高，尤其是对于小型网站而言。

  3. 证书过期问题：SSL证书需要定期更新和续费，如果网站管理者没有及时更新证书，可能会导致网站的访问受到影响。

322、HTTPS是如何保证安全的

HTTPS通过使用SSL/TLS协议实现数据传输的加密和认证，从而保障了通信过程的安全性。主要有以下几个方面：

  1. 加密传输：HTTPS采用了SSL/TLS加密协议，对HTTP数据进行加密传输，使得数据传输过程中所传递的信息经过加密，黑客无法直接获取敏感信息。

  2. 数字证书验证：HTTPS使用数字证书来确保客户端与服务器之间的通信是可信、合法的。只有通过了数字证书验证，才能建立连接。数字证书是由证书颁发机构颁发的，其中包含了网站的信息和公钥。

  3. 客户端验证证书：HTTPS采用公开密钥加密系统，客户端会对服务器发送的数字证书进行验证，以判断证书是否由受信任的第三方机构颁发，是否过期或已被撤销等等，确保证书的真实性和有效性。

  4. 安全套接字层协议：HTTPS采用SSL/TLS协议，可以防止黑客进行中间人攻击和篡改，确保通信的安全性。SSL/TLS协议使用公钥和私钥来建立连接和进行加密，确保数据传输的保密性和完整性。

因此，HTTPS通过加密通信和数字证书认证系统，以及 SSL/TLS 协议等手段，确保了客户端和服务器之间通信的安全性，有效防止了黑客攻击、信息泄露、篡改等安全威胁。

安全特性

描述

加密通信

使用SSL/TLS协议对数据进行加密，防止数据在传输过程中被窃听。

密钥交换

使用非对称加密交换对称密钥，用于后续的加密通信。

身份验证

通过数字证书验证服务器的身份，确保客户端连接到正确的服务器。

防止篡改

使用MAC和序列化机制确保数据在传输过程中的完整性。

为什么HTTPS可以实现完整性：

  1. 哈希函数：哈希函数可以生成固定大小的哈希值，任何对数据的微小更改都会导致哈希值的巨大变化，因此可以用来检测数据是否被篡改。

  2. 消息认证码（MAC）：MAC结合了哈希函数和密钥，只有拥有正确密钥的参与方才能验证MAC，这增加了数据完整性的保证。

  3. 数字签名：CA的数字签名确保了证书内容的完整性和可信度，防止了恶意的证书伪造。

323、介绍一下Https的加密过程

HTTPS（Hypertext Transfer Protocol Secure）是一种通过加密和认证保护数据传输安全的网络协议。下面是 HTTPS 的加密过程：

  1. 客户端发起连接请求：客户端（通常是浏览器）向服务器发送连接请求，请求建立一个安全连接。

  2. 服务器发送数字证书：服务器收到连接请求后，会将自己的数字证书发送给客户端。数字证书包含了服务器的公钥、证书的有效期等信息。证书通常由受信任的第三方机构（如证书颁发机构）签发，用于验证服务器的身份。

  3. 客户端验证数字证书：客户端收到服务器的数字证书后，会对证书进行验证。它会检查证书的有效性、签名是否合法以及证书是否过期等。如果验证通过，客户端继续进行后续步骤；否则，会弹出安全警告或终止连接。

  4. 客户端生成随机密钥：客户端生成一个随机的对称密钥（Session Key），用于后续的加密和解密操作。这个对称密钥只在当前会话中使用，提供了快速的加密和解密性能。

  5. 客户端使用服务器公钥加密密钥：客户端使用服务器的公钥（从数字证书中获取）对生成的对称密钥进行加密，然后将加密后的密钥发送给服务器。

  6. 服务器使用私钥解密密钥：服务器收到客户端发送的加密密钥后，使用自己的私钥对其进行解密，得到对称密钥。

  7. 双方使用对称密钥进行通信：客户端和服务器都拥有相同的对称密钥，可以使用该密钥进行加密和解密操作。他们之间的数据传输通过使用对称密钥来加密和解密，保证了数据的机密性和完整性。

通过以上步骤，HTTPS 协议确保了数据在传输过程中的安全性。数字证书验证确保了服务器的身份，并防止中间人攻击。使用对称密钥进行数据加密和解密，保证了数据的机密性。这种加密过程使得数据传输在不可信的网络环境下更安全可靠。

324、HTTPS中证书的作用是什么

在 HTTPS 中，证书的作用是验证服务器的身份并确保通信的安全性。具体来说，证书有以下几个作用：

  1. 验证服务器身份：证书包含了服务器的公钥以及与服务器相关的信息（如域名、组织、证书颁发机构等）。通过数字证书，客户端能够验证服务器的身份是否合法、有效和可信。这样可以防止中间人攻击或欺骗，确保客户端正在与预期的服务器进行通信。

  2. 加密密钥交换：为了保证通信的机密性，HTTPS 使用非对称加密算法（如RSA、ECC）来进行密钥交换。服务器在证书中包含了自己的公钥，客户端通过验证证书后，使用该公钥加密生成的随机对称密钥（Session Key），然后发送给服务器。这种方式保证了密钥的安全传输，防止第三方窃取密钥。

  3. 数据加密和解密：通过证书交换密钥后，客户端和服务器都拥有对称密钥（Session Key）。在后续的通信过程中，双方使用该对称密钥进行数据的加密和解密操作。这样可以保证数据在传输过程中的机密性，只有拥有对称密钥的双方才能解密和读取数据。

  4. 完整性校验：证书中还包含了服务器的数字签名，用于确保证书的完整性。客户端可以使用证书颁发机构的公钥进行验证，以确认证书没有被篡改或伪造。这样可以防止中间人攻击，确保通信数据没有被篡改。

总结起来，HTTPS 中的证书起到了身份验证、密钥交换、数据加密解密和完整性校验等作用。通过证书，客户端可以确认服务器的身份，确保通信的机密性和数据的完整性，从而提供更安全可靠的通信环境。

325、HTTP/2有哪些新特性

  1. 多路复用：HTTP/2 支持多路复用，即在一个 TCP 连接上可以同时传输多个请求/响应，避免了 HTTP 1.1 的队头阻塞问题，提高了性能。

  2. 二进制分帧：HTTP/2 采用了二进制分帧，将请求和响应数据分割成二进制的数据帧，在传输时更加高效。

  3. 首部压缩：HTTP/2 引入了新的首部压缩算法 HPACK，可以将 HTTP 首部信息进行压缩，减少数据传输量，提高性能。

  4. 服务器主动推送：HTTP/2 支持服务器主动推送，即在客户端发送请求之前，服务器可以将一些预测到客户端需要的资源主动推送给客户端，减少请求延迟，提高页面加载速度。

  5. 请求优先级：HTTP/2 支持请求优先级，即在一个 TCP 连接上同时传输多个请求/响应时，可以通过设置不同请求的优先级来控制响应的顺序，从而提高页面渲染速度。

总之，HTTP/2 在传输效率和性能方面有了很大提升，并在一些方面引入了新的特性，为 Web 应用的发展提供了更好的支持。

326、HTTP/1.1 和HTTP/2 之间有哪些区别

  1. 多路复用：HTTP 2.0 支持多路复用，即在一个 TCP 连接上可以同时传输多个请求/响应，避免了 HTTP 1.1 的队头阻塞问题，提高了性能。

  2. 二进制分帧：HTTP 1.1 采用的是文本协议，而 HTTP 2.0 则采用了二进制分帧，将请求和响应数据分割成二进制的数据帧，在传输时更加高效。

  3. 首部压缩：HTTP 2.0 引入了新的首部压缩算法 HPACK，可以将 HTTP 首部信息进行压缩，减少数据传输量，提高性能。

  4. 服务器主动推送：HTTP 2.0 支持服务器主动推送，即在客户端发送请求之前，服务器可以将一些预测到客户端需要的资源主动推送给客户端，减少请求延迟，提高页面加载速度。

  5. 请求优先级：HTTP 2.0 支持请求优先级，即在一个 TCP 连接上同时传输多个请求/响应时，可以通过设置不同请求的优先级来控制响应的顺序，从而提高页面渲染速度。

总之，HTTP 2.0 比 HTTP 1.1 在传输效率和性能方面有了很大提升，并在一些方面引入了新的特性，为 Web 应用的发展提供了更好的支持。

327、HTTP2的头部压缩算法是怎样的

HTTP/2 的头部压缩算法采用了 HPACK，用于减少 HTTP 消息报头的大小。HPACK 采用了两种压缩方式：静态压缩和动态压缩

  • 静态压缩是指使用了一个称为静态表的固定字典，将经常使用的 HTTP 消息报头预先编码并保存在静态表中。这样，在传输 HTTP 消息时，可以查找静态表中已经编码过的报头，仅仅发送它的编码值和索引号，大大减少了传输的数据量。
  • 动态压缩则是采用基于哈希的压缩算法，对 HTTP 消息报头进行编码。首先建立一张空表，然后将新出现的报头存放到这张表中，并给其分配一个新的索引值。当下次遇到相同的报头时，将其索引值发送给接收端。
  • 当表中的可用空间不足时，会使用最近最少使用（LRU）的策略来删除最少使用的报头，并且更新索引表。这样做的好处是避免了重复传输相同的报头，减少了消息的大小，提高了传输效率。

综上所述，HTTP/2 的头部压缩算法采用了 HPACK 压缩算法。静态压缩和动态压缩结合使用，大大减少了 HTTP 消息报头的大小，提高了通信效率。

328、WebSocket连接是如何创建

WebSocket是一种在Web浏览器和服务器之间进行全双工通信的协议。它使用标准的HTTP/HTTPS端口（80或443），但是与HTTP/HTTPS协议不同，它支持双向通信，可以实现实时消息推送等功能。

WebSocket连接的创建过程如下：

  1. 客户端向服务器发起一个HTTP/HTTPS请求，包含一个Upgrade头部，表示要升级协议为WebSocket。请求还包含一个Sec-WebSocket-Key头部，用于生成握手响应的Sec-WebSocket-Accept头部。
  2. 服务器收到请求后，检查Upgrade头部，如果为WebSocket，则进行握手处理。服务器生成一个握手响应，包含一个Sec-WebSocket-Accept头部，用于校验客户端发送的Sec-WebSocket-Key头部。
  3. 客户端收到握手响应后，校验Sec-WebSocket-Accept头部，如果校验通过，则认为握手成功，建立WebSocket连接。此时，客户端和服务器之间可以进行全双工通信，发送和接收WebSocket数据帧。

需要注意的是，WebSocket连接的握手过程只需要进行一次，一旦成功建立连接，客户端和服务器之间就可以一直保持通信。在通信过程中，客户端和服务器可以自由地发送和接收WebSocket数据帧，数据帧可以是文本格式或二进制格式，也可以是分片格式。在服务器端，我们可以使用WebSocket API来接收和处理客户端发送的WebSocket数据帧。

329、WebSocket 协议有哪些优点

WebSocket是一种在Web浏览器和服务器之间进行全双工通信的协议，相比于传统的HTTP/HTTPS协议，它具有以下优点：

  1. 实时性：WebSocket实现了真正的实时双向通信，可以实现实时消息推送等功能，相比于HTTP轮询等技术，实时性更高，延迟更低。

  2. 降低网络开销：WebSocket连接只需要进行一次握手，之后客户端和服务器之间可以一直保持连接，不需要每次都建立和关闭连接，降低了网络开销和服务器负载。

  3. 更少的数据传输：WebSocket使用二进制数据帧，相比于HTTP协议的文本传输，数据传输量更小，传输效率更高。

  4. 更好的跨域支持：WebSocket协议支持跨域通信，可以在不同的域名或端口之间实现实时通信。

  5. 更好的扩展性：WebSocket协议支持自定义扩展，可以通过自定义协议扩展来实现更多的功能，例如压缩、加密等。

综上所述，WebSocket协议在实时性、网络开销、数据传输、跨域支持和扩展性等方面都具有优势，因此被广泛应用于实时通信、在线游戏、在线教育等领域。

330、WebSocket握手过程

客户端发起握手请求：

  • 客户端通过普通的 HTTP GET 请求向服务器发起 WebSocket 握手请求。请求头中包含了一些关键的字段，例如：

    GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13

  • Upgrade: websocket 表示客户端希望升级到 WebSocket 协议，Connection: Upgrade 表示连接升级的意图。

  • Sec-WebSocket-Key 是一个经过 Base64 编码的随机值，用于确保安全性。

服务器响应握手请求：

  • 服务器收到客户端的握手请求后，进行相应的处理并返回一个 HTTP 101 切换协议的响应。响应头中包含了类似以下的字段：

    HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

  • Upgrade: websocket 和 Connection: Upgrade 告知客户端服务器正在切换到 WebSocket 协议。

  • Sec-WebSocket-Accept 是由客户端发送的 Sec-WebSocket-Key 经过一定算法计算得出的值，用于确认握手请求的合法性。

客户端和服务器完成握手：

  • 客户端收到服务器的 101 切换协议响应后，表示握手成功，连接升级为 WebSocket 协议。
  • 此时，客户端和服务器之间的通信将不再遵循 HTTP 协议，而是遵循 WebSocket 协议进行双向通信。

建立 WebSocket 连接：

  • 客户端和服务器现在已经建立了 WebSocket 连接，双方可以通过该连接进行实时的双向通信，而无需像 HTTP 那样频繁地发起请求和响应。

总的来说，WebSocket 握手的过程是通过普通的 HTTP 请求-响应来完成的，但是在握手过程中，客户端和服务器协商切换到 WebSocket 协议，从而建立起全双工、低延迟的持久连接，实现了更高效的实时通信。

331、DNS协议的解析流程

  1. 电脑客户端会发出一个 DNS 请求，问 www.wl.com 的 IP 是啥啊，并发给本地域名服务器 (本地 DNS)。

  2. 本地 DNS 收到来自客户端的请求。然后，查找对应的记录信息。

    • 如果能找到 www.wl.com，它直接就返回 IP 地址。
    • 如果没有，本地 DNS 会去问它的根域名服务器。

  3. 根 DNS 收到来自本地 DNS 的请求，发现后缀是 .com，说：“www.wl.com 啊，这个域名是由.com 区域管理，我给你它的顶级域名服务器的地址，你去问问它吧。”

  4. 本地 DNS 转向问

    顶级域名服务器：

    • 顶级域名服务器就是大名鼎鼎的比如 .com、.net、 .org 这些一级域名
    • 它负责管理二级域名，比如 wl.com，所以它能提供一条更清晰的方向

  5. 顶级域名服务器说：“我给你负责 www.wl.com 区域的权威 DNS 服务器的地址，你去问它应该能问到。”

  6. 本地 DNS 转向问权威 DNS 服务器：“www.wl.com 对应的 IP 是啥呀？”

    • wl.com 的权威 DNS 服务器，它是域名解析结果的原出处。
    • 为啥叫权威呢？就是我的域名我做主。

  7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。

  8. 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

332、DNS 为什么使用 UDP 协议作为传输层协议

DNS协议通常使用UDP协议作为传输层协议，主要有以下几点原因：

  1. 快速性：使用UDP协议时，只要应用进程将数据传给UDP，UDP就会立即将此数据打包成UDP报文并传递给网络层。相比之下，TCP拥有拥塞控制的功能，在发送前需要判断互联网的拥堵情况，如果网络极度拥堵，则会抑制TCP的发送方，因此TCP的速度较慢。

  2. 可靠性：TCP是一种面向连接的协议，需要进行三次握手和流量控制，而UDP没有这样的流程，因此UDP能更快地传递数据。

  3. 简单性：由于UDP没有建立连接、流量控制等复杂的机制，它的实现比TCP简单得多，可以降低DNS服务器的负载。

  4. 规模：DNS通信通常涉及大量的小数据报文，使用UDP可以避免TCP的巨大开销，提高网络效率。

总之，DNS使用UDP协议主要是为了快速传输小数据包，并在保证可靠性的同时降低DNS服务器的负载。

333、DNS 协议是什么

DNS协议全称为“Domain Name System”（域名系统），它是一种将域名转换为IP地址的服务，同时也是一种分布式数据库的系统。DNS协议能够使人们使用易于记忆的域名来代替IP地址访问Internet上的资源。

具体来说，DNS协议将域名和IP地址对应起来，用户在使用计算机浏览器请求某个网站时，会首先向本地DNS服务器发出域名解析请求，本地DNS服务器则通过向根域名服务器、顶级域名服务器、权威域名服务器等层层查询，最终获取到目标主机的IP地址，然后将IP地址返回给客户端，客户端通过IP地址建立与目标主机的连接。

因此，DNS协议起到了一个类似于“电话簿”的作用，能够将易于记忆的域名和Internet上的实际IP地址相对应。这样，用户就可以通过输入域名来访问网络资源，而无需记住复杂的IP地址。

334、TCP中为什么要进行四次挥手

TCP 进行四次挥手的主要目的是确保双方都能正确关闭连接，并且双方没有任何数据丢失。

下面是 TCP 四次挥手的过程：

  1. 第一步（FIN-ACK）：其中一方（通常是发起关闭的一方）发送一个 FIN（Finish）信号给对方，表示它已经完成了数据的发送，不会再发送数据。同时，它还会等待对方发送确认应答 ACK（Acknowledgment）。

  2. 第二步（ACK）：接收到 FIN 的一方收到后，会发送一个 ACK 给对方作为确认应答。这个 ACK 表示它已经收到了对方的 FIN。

  3. 第三步（FIN）：接收到 ACK 的一方会进入 CLOSE_WAIT 状态，表示它还有一些数据需要处理，但已经准备好关闭连接。一旦完成了数据的处理，它会发送一个自己的 FIN 给对方。

  4. 第四步（ACK）：对方收到 FIN 后，会发送一个 ACK 给发起关闭的一方作为确认应答。这个 ACK 表示它已经收到了对方的 FIN。

这样，通过四次挥手，双方都可以安全地关闭连接。每一方都能够明确表达自己的意图，并且等待对方的确认应答，以避免数据的丢失或不完整。

需要注意的是，四次挥手过程中可能存在的延迟和丢失是由网络条件决定的，而不是 TCP 协议本身的问题。有时可能会出现一方发送了 FIN 后长时间没有收到对方的确认应答，这种情况下会触发超时重传机制，重新发送 FIN，以确保连接能够正确关闭。

335、TCP是如何保证传输的稳定性和可靠性

TCP（传输控制协议）是一种面向连接的、可靠的传输协议，它通过以下几个机制来保证传输的稳定性和可靠性：

  1. 确认和重传（Acknowledgment and Retransmission）：发送端在发送数据段后会等待接收端发送的确认应答（ACK）。如果发送端在合理的时间内没有收到确认应答，就会认为数据丢失或损坏，然后进行重传。接收端则可以通过确认应答告知发送端已成功接收数据。

  2. 序列号和确认号（Sequence and Acknowledgment numbers）：TCP 在传输过程中给每个数据段分配一个序列号和确认号。序列号用于标识数据段的顺序，确认号表示期望接收的下一个数据段的序列号。通过序列号和确认号的使用，TCP 可以检测丢失的数据段并进行重传。

  3. 流量控制（Flow Control）：TCP 使用滑动窗口机制来进行流量控制。滑动窗口大小表示接收端能够接收的数据量。发送端根据接收端的窗口大小来控制发送的数据量，确保不会发送超出接收端处理能力的数据，从而防止数据丢失或拥塞。

  4. 拥塞控制（Congestion Control）：TCP 使用拥塞控制算法来避免网络拥塞，保证传输的稳定性。它通过动态调整发送速率和窗口大小，根据网络的拥塞程度进行流量控制，以减少数据包丢失和延迟。

  5. 超时重传（Timeout Retransmission）：当发送端发送数据后，如果在一定时间内没有收到确认应答，就会认为数据丢失，触发超时重传机制，重新发送数据。

通过这些机制，TCP 可以在不可靠的网络环境中提供稳定和可靠的数据传输。它可以检测并纠正丢失、损坏、重复和乱序等问题，确保数据的正确性和完整性。同时，TCP 的流量控制和拥塞控制机制也能够适应网络的变化，防止过多的数据流入导致网络拥塞，从而保证整个网络的稳定性和可靠性。

336、TCP链接为什么会采用三次握手，而不是两次或四次呢

TCP（Transmission Control Protocol，传输控制协议）采用三次握手建立连接的机制是为了确保通信双方的可靠性和一致性。这种设计可以应对网络环境中可能出现的各种情况，保证数据的可靠传输。

具体来说，三次握手的过程如下：

  1. 客户端发送一个带有 SYN（同步序列号）标志的数据包给服务器，表示客户端请求建立连接。
  2. 服务器收到这个数据包后，回复一个带有 SYN/ACK 标志的数据包给客户端，表示确认收到客户端的请求，并且同意建立连接。
  3. 客户端再回复一个带有 ACK 标志的数据包给服务器，表示收到了服务器的确认，连接建立成功。

为什么要进行三次握手呢？主要有以下几个原因：

  1. 确保双方都能发送和接收数据：通过三次握手，可以确保客户端和服务器都能正常发送和接收数据，避免因为一方无法接收数据而导致连接失败。

  2. 防止旧连接请求被误认为新连接：如果只进行两次握手，可能会出现这样的情况：客户端发送了一个连接请求给服务器，但是由于某些网络问题导致该请求迟迟未到达服务器，而后客户端重新发送了一个新的连接请求。如果此时服务端接收到了旧的延迟的请求，就会误以为客户端发送的是一个新的连接请求，从而产生混乱。三次握手可以避免这种情况的发生。

  3. 防止过期的连接请求被接受：如果只进行两次握手，可能会导致服务器端在已经关闭的连接上收到客户端的连接请求。通过第三次握手，可以确保服务器收到的连接请求是最新的，避免处理过期的连接请求。

总之，TCP 采用三次握手的机制是为了确保连接的可靠性和一致性，以应对网络环境中可能出现的各种情况，从而保证数据的可靠传输。

337、一个TCP连接能发几个HTTP请求

一个TCP连接可以发多个HTTP请求，这也是HTTP/1.1采用持久连接（persistent connection）的原因之一。

在持久连接下，一个TCP连接可以在收到响应之前发送多个HTTP请求。当一个请求完成并且响应被接收后，连接将保持打开状态，以便下一个请求继续使用。这样可以减少TCP连接的建立和关闭带来的开销，从而提高网络性能。

需要注意的是，每个HTTP请求和响应都有自己的头部信息，这些信息会占用数据包的大小。

如果在一个TCP连接中发送大量的HTTP请求，可能会导致数据包增多，从而影响网络的传输效率。

为了避免这种情况，**可以采用流水线式（pipelining）**的方式发送HTTP请求，即在上一个请求的响应未到达时就开始发送下一个请求，在一定程度上可以减少头部信息的重复，并提高网络传输的效率。

不过，使用流水线式也会带来一些问题，比如如果一个请求出现错误，可能会导致后续的请求全部失败，因此需要适当控制请求的数量和顺序。

338、TCP粘包是怎么回事，如何处理

TCP粘包问题是由于TCP协议传输数据的特性所引起的：
TCP协议是基于字节流的，没有消息的概念，发送端发送的若干次数据可能会被一次性接收，或者一次发送的数据被拆成多个数据包进行发送，接收端无法分辨这些数据属于哪个消息。

TCP粘包问题的处理方法有以下几种：

  1. 基于长度的粘包处理。发送方将每个消息的长度添加到前面，接收方在接收数据时先读取固定长度的头部信息（通常是4个字节），再根据长度读取后面的报文，以此来避免粘包问题。

  2. 基于特殊字符的粘包处理。发送方在每个消息末尾加上特殊字符，并在接收端通过特殊字符的识别来拆分每个消息。

  3. 基于消息头的粘包处理。在每个消息头里添加一个特殊标记，用来标识该消息的具体内容，接收方通过读取该标记从而识别每个消息。

以上三种方法都需要在应用层进行适当的设计和实现，以解决TCP粘包问题。

339、TCP的滑动窗口

TCP 采用滑动窗口来管理数据发送和 ACK 号的操作。

所谓滑动窗口，就是在发送一个包之后，不等待 ACK 号返回，而是直接发送后续的一系列包

通过这种方式，就可以实现同一时间发送多个包，减少网络延迟。

其实，通过窗口，TCP 可以控制双向发送数据的速度。

流量控制

流量控制是一种预防发送端过多向接收端发送数据的机制。

为实现流量控制，TCP 连接的每一方都要通告自己的接收窗口（rwnd），其中包含能够保存数据的缓冲区空间大小信息。

第一次建立连接时，两端都会使用自身系统的默认设置来发送 rwnd。在后面的数据交换过程中，每个 ACK 分组都会携带相应的最新 rwnd 值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。

慢启动 (利用可用宽带)

流量控制确实可以防止发送端向接收端过多发送数据，但却没有机制预防任何一端向潜在网络过多发送数据。换句话说，发送端和接收端在连接建立之初，谁也不知道可用带宽是多少。因此需要一个估算机制，然后还要根据网络中不断变化的条件而动态改变速度。

拥塞窗口大小（cwnd）:发送端对从客户端接收确认（ACK）之前可以发送数据量的限制。发送端不会通告 cwnd 变量，即发送端和接收端不会交换这个值。

服务器和客户端怎么确定拥塞窗口大小的最优值呢:解决方案就是慢启动:即在分组被确认后增大窗口大小，慢慢地启动。

无论带宽多大，每个 TCP 连接都必须经过慢启动阶段

换句话说，应用不可能一上来就完全利用连接的最大带宽

把初始拥塞窗口大小增加到一个合理值，可以减少客户端与服务器之间的往返时间

340、TCP的队首阻塞

TCP 在不可靠的信道上实现了可靠的网络传输

每个 TCP 分组都会带着一个唯一的序列号被发出，而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端的 TCP 缓冲区，等待丢失的分组重发并到达接收端。这一切都发生在 TCP 层，应用程序对 TCP 重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。这种效应称为TCP {队首阻塞|Head of Line Blocking} （HOL)

TCP 队首阻塞

队首阻塞造成的延迟可以让我们的应用程序不用关心分组重排和重组，分组到达时间会存在无法预知的延迟变化。这个时间变化通常被称为抖动，也是影响应用程序性能的一个主要因素。

TCP 队首阻塞造成的延迟,也是影响应用程序性能的一个主要因素

341、谈谈 CDN 服务

CDN（Content Delivery Network，内容分发网络）是一种分布式的网络架构，通过在全球范围内部署大量的缓存服务器节点，将源站点（如网站、应用程序、音视频资源等）的内容缓存到离用户最近的节点上，从而实现加速用户对内容的访问。

CDN的工作原理通常包括以下几个步骤：

  1. 用户向CDN节点请求某个内容，如一个网页或视频。

  2. CDN节点检查是否存在所需内容的缓存副本。如果存在，直接返回给用户；否则向源站点请求原始内容。

  3. 源站点将原始内容传输到CDN节点，并在该节点上进行缓存。

  4. 下一次有用户请求同样内容时，CDN节点会直接返回缓存的副本，从而减轻源站点的负载，同时提升用户访问速度和稳定性。

CDN服务的优势主要包括：

  1. 减少延迟：由于CDN节点通常部署在离用户更近的位置，因此可以减少延迟和丢包率，提高用户体验。

  2. 提升带宽：CDN节点可以缓存大量的内容，从而减少源站点的带宽消耗，降低成本。

  3. 增强安全性：CDN服务商通常提供基于多种安全机制的防御措施，包括DDoS攻击、CC攻击、SQL注入等，提高了网站的安全性。

  4. 提高可用性：由于CDN节点分布较广，即使源站点出现故障，用户也可以从其他缓存节点获取内容，从而实现高可用性。

目前，国内外有很多CDN服务商，例如Akamai、Cloudflare、腾讯云CDN、阿里云CDN等。

342、CDN 一般放什么数据

CDN（内容分发网络）一般用于加速网站的内容传输，提高用户访问网站的速度和性能。在前端面试中，关于 CDN 一般放什么数据可以涉及以下内容：

  1. 静态资源文件：CDN 主要用来存放静态资源文件，如图片、CSS 文件、JavaScript 文件、字体文件等。这些静态资源文件相对不会频繁变动，通过 CDN 可以缓存并分发到全球各地的节点，加速用户访问速度。

  2. 视频和音频文件：CDN 也常用于存放视频和音频文件，特别是对于大型视频网站或音乐网站来说，通过 CDN 分发视频和音频文件可以有效减轻服务器压力，提高访问速度和稳定性。

  3. 第三方库和框架：许多网站使用了一些流行的第三方库和框架，比如 jQuery、Bootstrap、React 等，这些文件可以通过 CDN 来引入，提高加载速度，并且可以利用 CDN 的缓存机制减少重复下载。

  4. 字体文件：Web 字体文件在网页设计中扮演着重要角色，通过 CDN 存放字体文件可以确保字体文件能够快速加载，提高网页加载速度和展示效果。

  5. 静态页面文件：有些网站的页面内容相对固定，可以将整个静态页面文件存放在 CDN 上，利用 CDN 的缓存机制来加速页面的访问。

总的来说，CDN 主要用于存放静态资源文件、视频音频文件、第三方库和框架、字体文件等对于网站性能影响较大的内容，通过 CDN 加速这些数据的传输，提升用户体验和网站性能。

343、什么是正向代理和反向代理

正向代理和反向代理是两种代理模式，它们都用于代理服务器和客户端之间的通信，但代理的方向不同。

正向代理（Forward Proxy）

正向代理（Forward Proxy）充当客户端的代理，为客户端发送请求到服务器端。正向代理隐藏了客户端的真实 IP 地址，把所有客户端请求的数据收集起来，再代表客户端与服务器进行通信。

常见使用场景包括翻墙、内网穿透等。例如，墙内的用户需要访问 Google，可以通过设置代理服务器，将请求发送到代理服务器上，由代理服务器转发到 Google 上，然后返回响应给客户端。

反向代理（Reverse Proxy）

反向代理（Reverse Proxy）充当服务端的代理，为服务器接收客户端请求并进行处理。反向代理隐藏了服务器的真实 IP 地址，客户端请求先经过反向代理服务器，反向代理服务器负责将请求转发到后端的服务器，然后再将后端服务器的响应返回给客户端。

反向代理具有负载均衡、缓存、安全控制等作用，能够提高服务器的性能和安全性。

例如，用户访问淘宝网站，会首先访问反向代理服务器，由反向代理服务器负责将请求转发到后端多台服务器上进行处理，并返回响应给客户端。

344、负载平衡的两种实现方式

负载平衡是指将网络流量在多个服务器之间分配，并且确保每个服务器的负载尽量均衡，从而提高服务器整体性能和可靠性。以下是两种常见的负载平衡实现方式：

硬件负载均衡器 F5

硬件负载均衡器是一种专门的物理设备，通常包含交换机、路由器、防火墙等组件，可以通过检查传入请求的特定内容（如 IP 地址、协议、端口号、数据包内容等）来确定请求如何路由到不同的服务器。硬件负载均衡器通常具有高速缓存、高带宽和良好的可扩展性，适合处理大规模的网络流量。

软件负载均衡器 Nginx

软件负载均衡器是一种运行在普通服务器上的程序，具有类似于硬件负载均衡器的功能。软件负载均衡器通常使用轮询、最小连接数、IP 哈希等算法来分配请求到不同的服务器，并且可以根据需要调整分配策略。软件负载均衡器通常便于部署、配置和管理，并且具有较低的成本，适合中小规模的网络环境。

无论采用哪种方式，负载均衡的实现都需要注意以下几个方面：

  • 可靠性：负载均衡器本身应该具有高可靠性和容错能力，以应对硬件故障和网络中断等异常情况。

  • 稳定性：负载均衡器应该尽可能保持稳定，并且能够自适应调整服务器的负载，以优化系统性能。

  • 安全性：负载均衡器应该采取一些安全措施，如防止 DDoS 攻击、提供 SSL 加密等，以确保网络安全。

  • 可扩展性：负载均衡器应该具有良好的可扩展性，可以根据需要添加或删除服务器，以适应业务的发展需要。

345、即时通讯的实现，短轮询、长轮询、SSE 和 WebSocket 间的区别

即时通讯指的是实时地进行消息交互，一般使用的技术包括短轮询、长轮询、SSE 和 WebSocket。它们的区别如下：

  1. 短轮询 (Polling)：客户端每隔一定时间向服务器发送请求，询问是否有新的消息。服务器每次都会返回响应，即使没有新的消息，客户端也会不断请求，直到获取到新的数据。该方案的特点是实现简单，但是每次请求都需要占用服务器资源，不能实现实时性较高的场景。

  2. 长轮询 (Long Polling)：客户端发送一个请求到服务器，如果有新的消息，服务器就会立即返回响应，如果没有，服务器会把请求保持住，等待一段时间后再返回响应。客户端在接收到响应后重新发起请求，继续等待响应。该方案减少了无效请求，实时性相比于短轮询有所提高，但仍存在延迟。

  3. SSE（Server-Sent Events）：一种服务器推送技术，与客户端建立一个持久的连接，服务器可以随时向客户端发送消息。在该方案中，服务器会把新的消息封装成 Event 事件，通过 HTTP 协议推送给客户端。 SSE 具有良好的兼容性和可靠性，但是无法像 WebSocket 一样实现双向通信。

  4. WebSocket：一种全双工、双向通信协议，与 HTTP 协议不同的是，WebSocket 连接建立后会维持一个长时间的连接状态。客户端和服务器之间可以自由地发送和接收数据，无需像短轮询和长轮询那样频繁发起请求和应答。WebSocket 实现了真正的实时通信，支持传输二进制数据，具有出色的性能和扩展能力。

因此，在选择即时通讯技术方案时，需要根据具体场景和需求选择不同的方案。如果只是进行简单的消息传递，可使用短轮询或长轮询；如果需要实现较高的实时性和性能，并且需要进行双向通信，则可以选择 SSE 或 WebSocket。

长轮询常用的方案有哪些

长轮询（Long Polling）是一种实现服务器推送的技术，常用的方案有以下几种：

  1. Ajax 长轮询：利用 Ajax 技术实现长轮询，客户端通过定时发送异步请求，服务器在接收到请求后保持连接并等待事件触发，当事件触发后再返回响应给客户端，客户端接收到响应后再重新发起请求。这种方式实现简单，但是需要不断的建立和销毁 HTTP 连接，对服务器造成一定的负担。

  2. Comet 长轮询：Comet 是一种基于 Ajax 长轮询的技术，可以实现服务器向客户端推送数据。在 Comet 中，客户端只需要发送一次 Ajax 请求，服务器则会保持连接状态，并在有数据更新时立即返回响应。这种方式相比 Ajax 长轮询能减少 HTTP 连接数，提高性能，但由于需要保持连接，会增加服务器的资源消耗。

  3. 基于 HTTP 流的长轮询：也被称为流式响应（Streaming Responses），是一种将响应结果分块传输的方式，在服务器返回响应时保持连接，并将结果分段传输给客户端。客户端可以按照固定时间间隔或者其他条件来处理相应的段数据，这种方式比 Comet 更加高效，但是需要注意防止浏览器缓存问题。

  4. 微软的 SignalR 框架：SignalR 是一种实现实时双向通信的框架，支持多种浏览器和操作系统平台，使用的是轮询机制来实现数据传输，同时支持自动选择最优的传输方式，包括 SSE、WebSocket、短轮询等。SignalR 可以在客户端和服务器之间建立一个持久连接，当服务器端有数据更新时，可以直接推送数据给客户端，大大提高了实时性。

实现一个基于Ajax的长轮询

以下是一个基于 Ajax 的长轮询实现示例：

function longPolling() {
  $.ajax({
    url: "your_url",
    type: "GET",
    timeout: 30000, // 超时时间设置为 30 秒
    async: true, // 异步请求
    cache: false, // 不缓存结果
    dataType: "json", // 服务器响应的数据类型
    success: function(data) {
      // 处理服务器返回的数据
      // 这里仅作示例，可以根据需求自定义处理方式
      console.log("成功接收到数据：" + JSON.stringify(data));
    },
    error: function(xhr, status, error) {
      if (status === "timeout") {
        // 超时后重新发起请求
        longPolling();
      }
    }
  });
}

// 开始长轮询
longPolling();

这个示例中，我们使用 jQuery 的 Ajax 方法来实现长轮询。在请求参数中，我们设置了超时时间为 30 秒，表示如果在这个时间内没有接收到服务器的响应，那么就认为本次请求失败。如果发生超时错误，我们会重新发起请求，以达到长期保持连接的目的。

需要注意的是，这种基于 Ajax 的长轮询方式可能会对服务器造成一定的负担，因为服务器需要不断地处理请求。

实现一个基于 HTTP 流的长轮询

以下是一个基于 HTTP 流的长轮询实现示例：

function httpStreaming() {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", "your_url", true); // 注意设置为异步请求

  // 设置响应类型为 text/event-stream
  xhr.setRequestHeader("Content-Type", "text/event-stream");
  xhr.setRequestHeader("Cache-Control", "no-cache"); // 不缓存结果

  xhr.onprogress = function(event) {
    var lines = event.target.responseText.split("\n");
    lines.forEach(function(line) {
      if (line.indexOf(":") !== 0) {
        // 处理服务器推送的消息
        // 这里仅作示例，可以根据需求自定义处理方式
        console.log("接收到推送消息：" + line);
      }
    });
  };

  xhr.onerror = function(event) {
    // 处理错误
    console.log("发生错误：" + event);
  };

  xhr.send();
}

// 开始 HTTP 流式请求
httpStreaming();

这个示例中，我们使用原生的 XMLHttpRequest 对象来实现 HTTP 流式请求。在请求头中，我们设置了响应类型为 text/event-stream，表示服务器会将响应结果分块传输。每当服务器产生新的数据时，它会发送一条消息，客户端再通过 onprogress 事件来监听响应的变化，并进行相应的处理。

需要注意的是，由于 HTTP 流式请求需要保持长时间连接，因此如果处理错误或者超时，我们需要进行适当的操作，比如重新发起请求等。同时，由于浏览器的缓存机制，我们需要在请求头中设置 Cache-Control: no-cache，以确保每次请求都是最新的结果。

346、什么是单点登录

单点登录（Single Sign On，简称 SSO）是一种在多个应用系统中，用户只需要进行一次登录，就可以访问所有相互信任的应用系统的权限控制技术。

也就是说，在一个单点登录系统中，用户只需要登录一次，就可以在不同的系统中使用相同的账号和密码来访问不同的资源，而无需重复输入账号和密码。

单点登录技术实现的核心是共享认证凭据，如 token、cookie 等，以及认证授权的中心化管理，即身份验证的透明度，用户不需要关心登录在哪个系统中完成，而是可以自由地访问所有经过授权的系统和服务。

在早期，多系统登录解决方案的核心是 cookie，但是其安全性较低。随着技术的发展，SSO 后端源码已经开源，如 CAS、Shiro 等，以及第三方库，如 Spring Boot Security、xxl-sso 等，可以帮助我们快速实现单点登录功能。

347、基于server端session的管理

  1. 服务端session是用户第一次访问应用时，服务器就会创建的对象，代表用户的一次会话过程，可以用来存放数据。服务器为每一个session都分配一个唯一的sessionid，以保证每个用户都有一个不同的session对象。
  2. 服务器在创建完session后，会把sessionid通过cookie返回给用户所在的浏览器，这样当用户第二次及以后向服务器发送请求的时候，就会通过cookie把sessionid传回给服务器，以便服务器能够根据sessionid找到与该用户对应的session对象。
  3. session通常有失效时间的设定，比如2个小时。当失效时间到，服务器会销毁之前的session，并创建新的session返回给用户。但是只要用户在失效时间内，有发送新的请求给服务器，通常服务器都会把他对应的session的失效时间根据当前的请求时间再延长2个小时。
  4. session在一开始并不具备会话管理的作用。它只有在用户登录认证成功之后，并且往sesssion对象里面放入了用户登录成功的凭证，才能用来管理会话。管理会话的逻辑也很简单，只要拿到用户的session对象，看它里面有没有登录成功的凭证，就能判断这个用户是否已经登录。当用户主动退出的时候，会把它的session对象里的登录凭证清掉。所以在用户登录前或退出后或者session对象失效时，肯定都是拿不到需要的登录凭证的。

348、cookie-base的管理方式

  1. 用户发起登录请求，服务端根据传入的用户密码之类的身份信息，验证用户是否满足登录条件，如果满足，就根据用户信息创建一个登录凭证，这个登录凭证简单来说就是一个对象，最简单的形式可以只包含用户id，凭证创建时间和过期时间三个值。
  2. 服务端把上一步创建好的登录凭证，先对它做数字签名，然后再用对称加密算法做加密处理，将签名、加密后的字串，写入cookie。cookie的名字必须固定（如ticket），因为后面再获取的时候，还得根据这个名字来获取cookie值。这一步添加数字签名的目的是防止登录凭证里的信息被篡改，因为一旦信息被篡改，那么下一步做签名验证的时候肯定会失败。做加密的目的，是防止cookie被别人截取的时候，无法轻易读到其中的用户信息。
  3. 用户登录后发起后续请求，服务端根据上一步存登录凭证的cookie名字，获取到相关的cookie值。然后先做解密处理，再做数字签名的认证，如果这两步都失败，说明这个登录凭证非法；如果这两步成功，接着就可以拿到原始存入的登录凭证了。然后用这个凭证的过期时间和当前时间做对比，判断凭证是否过期，如果过期，就需要用户再重新登录；如果未过期，则允许请求继续。

349、token-base的管理方式

跟cookie-based的方式没有太多区别，只不过cookie-based里面写到cookie里面的ticket在这种方式下称为token，这个token在返回给客户端之后，后续请求都必须通过url参数或者是http header的形式，主动带上token，这样服务端接收到请求之后就能直接从http header或者url里面取到token进行验证。

350、JWT

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户。

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

JWT 的数据结构

它是一个很长的字符串，中间用点（.）分隔成三个部分 JWT 的三个部分依次如下。

  1. Header（头部）
    • Header 部分是一个 JSON 对象，描述 JWT 的元数据
    • 将上面的 JSON 对象使用 Base64URL 算法转成字符串。
  2. Payload（负载）
    • Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据
    • 这个 JSON 对象也要使用 Base64URL 算法转成字符串。
  3. Signature（签名）

JWT 的使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

351、什么是 RESTFUL API

RESTful API 是一种基于 HTTP 协议设计的 Web 应用程序接口。

它通过 URL（统一资源定位符） 和 HTTP 动词（如 GET、POST、PUT、DELETE 等） 来实现对资源的操作，旨在让 Web 服务更加简洁、易于扩展和便于维护。具体来说，

RESTful API 的核心设计原则包括：

  • 基于客户端-服务器架构，客户端和服务器之间通过 HTTP 协议通信。
  • 使用标准的 HTTP 动词来表示对资源的操作，如 GET 获取资源，POST 创建资源，PUT 更新资源，DELETE 删除资源等。
  • 使用 URL 来标识资源，URL 包含了资源类型以及唯一标识该资源的 ID。
  • 支持不同格式的数据传输，常见的有 JSON、XML 等。
  • 无状态的通信，每次请求都包含了足够的信息来处理该请求，服务器不会保存客户端的上下文信息。

RESTful API 被广泛应用于 Web 应用程序中，例如今天常用的移动应用、在线购物等。使用 RESTful API，我们可以方便地获取、创建、更新和删除数据等操作，并且能够更好地实现跨平台和分布式的交互。

352、网络分层是 5 层还是 7 层

网络分层指的是将网络协议栈分为不同层次来处理数据传输的过程，目前主流的网络分层有两种：五层模型和七层模型。

  1. 五层模型

五层模型也称为 TCP/IP 模型，它把网络协议栈划分为以下五层：

  • 应用层：负责处理用户应用程序与网络之间的交互，例如 HTTP、FTP、SMTP 等协议。
  • 传输层：负责提供端到端的可靠数据传输服务，包含 TCP、UDP 等协议。
  • 网络层：负责实现数据包的转发和路由选择，包含 IP、ICMP、ARP 等协议。
  • 数据链路层：负责实现物理层和网络层之间的数据传输，包含 PPP、Ethernet、ARP 等协议。
  • 物理层：负责处理物理设备、传输介质等底层物理信号的传输。
  1. 七层模型

七层模型也称为 OSI 模型，它将网络协议栈划分为以下七层：

  • 应用层：同五层模型。
  • 表示层：负责处理数据的格式、加密和压缩等操作，同 MIME、SSL/TLS 协议等。
  • 会话层：负责建立、管理和终止会话，同 RPC、SMB 等协议。
  • 传输层：同五层模型。
  • 网络层：同五层模型。
  • 数据链路层：同五层模型。
  • 物理层：同五层模型。
avatar
文章
阅读
粉丝