让前端飞Web前端之路javascript基础原理

【面试题】HTTP知识点整理(附答案)

2020-04-16  本文已影响0人  IOneStar

目录

http1.x、http2、http3

http1.0 和HTTP1.1的一些区别

HTTP2.0和HTTP1.X相比的新特性

HTTP1.x存在的问题：

  1. TCP连接数限制
    对于同一个域名，浏览器最多只能同时创建6 ~ 8个TCP链接。为了解决数量的限制，出现 域名分片技术。
  2. 队头阻塞(Head-Of-Line Blocking)
    当HTTP开启长连接时，共用一个TCP连接，同一时刻只能处理一个请求，浏览器按 FIFO 原则处理请求，如果上一个响应没返回，后续请求 - 响应都会受阻。
  3. header内容多，并且每次请求 Header不会变化太多，没有相应的压缩传输优化方案
  4. 为了尽可能减少请求数，需要做合并文件、雪碧图、资源内联等优化工作，但是这无疑造成了单个请求内容变大延迟变高的问题，且内嵌的资源不能有效地使用缓存机制
  5. 明文传输不安全

HTTP2

  1. 二进制传输
    HTTP/2传输数据量的大幅减少,主要有两个原因:以二进制方式传输和Header 压缩， HTTP/2 采用二进制格式传输数据，而非HTTP/1.x 里纯文本形式的报文 ，二进制协议解析起来更高效
    HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。帧是数据传输的最小单位，以二进制传输代替原本的明文传输，原本的报文消息被划分为更小的数据帧。

  2. 多路复用
    在一个TCP连接上，我们可以向对方不断发送帧，每帧的 stream identifier 标明这一帧属于哪个流，然后在对方接收时，根据 stream identifier 拼接每个流的所有帧组成一整块数据。 把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP/2 中的多路复用。

  3. header压缩
    使用 HPACK 算法来压缩首部内容

  4. 服务端推送
    浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这被称为"服务器推送"（ Server Push，也叫 Cache push）

HTTP/1 的几种优化可以弃用:
合并文件、内联资源、雪碧图、域名分片对于 HTTP/2 来说是不必要的，使用 h2 尽可能将资源细粒化，文件分解地尽可能散，不用担心请求数多

为什么 HTTP1.1 不能实现多路复用

HTTP/1.1 不是二进制传输，而是通过文本进行传输。由于没有流的概念，在使用并行传输（多路复用）传递数据时，接收端在接收到响应后，并不能区分多个响应分别对应的请求，所以无法将多个响应的结果重新进行组装，也就实现不了多路复用。

多路复用和 keep alive区别

[图片上传失败...(image-65a055-1587046342922)]

  1. 队头阻塞（Head-of-Line Blocking），HTTP1.X虽然可以采用Keep alive来解决复用TCP的问题，但是还是无法解决请求阻塞；
  2. 所谓请求阻塞意思就是一条 TCP 的connection在同一时间只允许一个请求经过，这样假如后续请求想要复用这个链接就必须等到前一个完成才行，正如上图左边表示的。
  3. 之所以有这个问题就是因为HTTP1.x需要每条请求都是可以识别，按顺序发送，否则serve就无法判断该响应哪个具体的请求。
  4. HTTP2采用多路复用是指，在同一个域名下，开启一个TCP的connection，每个请求以stream的方式传输，每个stream有唯一的标识，connection一旦建立，后续的请求都可以复用这个connection并且可以同时发送，server端可以根据stream的唯一标识来响应对应的请求。

http3

HTTP/2 的缺点

尽管HTTP/2解决了很多1.1的问题，但HTTP/2仍然存在一些缺陷，这些缺陷并不是来自于HTTP/2协议本身，而是来源于底层的TCP协议，我们知道TCP链接是可靠的连接，如果出现了丢包，那么整个连接都要等待重传，HTTP/1.1可以同时使用6个TCP连接，一个阻塞另外五个还能工作，但HTTP/2只有一个TCP连接，阻塞的问题便被放大了。

http3

由于TCP协议已经被广泛使用，我们很难直接修改TCP协议，基于此，HTTP/3选择了一个折衷的方法——UDP协议，HTTP/2在UDP的基础上实现多路复用、0-RTT、TLS加密、流量控制、丢包重传等功能。

https

HTTP和HTTPS的区别

HTTPS握手过程

  1. 客户端使用HTTPS的URL访问Web服务器，要求与服务器建立SSL连接
  2. web服务器收到客户端请求后, 会将网站的证书(包含公钥)传送一份给客户端
  3. 客户端收到网站证书后会检查证书的颁发机构以及过期时间, 如果没有问题就随机产生一个密钥
  4. 客户端利用公钥将会话密钥加密, 并传送给服务端, 服务端利用自己的私钥解密出会话密钥
  5. 之后服务器与客户端使用密钥加密传输

HTTPS通过什么保证是安全的

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

加密：

认证：证明公开密钥正确性的证书

使用数字证书认证机构（CA）和其他相关机关颁发的公开密钥证书

三次握手，四次挥手，为什么是三次和四次

三次握手

  1. 发送端首先发送一个带SYN标志的数据包给对方
  2. 接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息
  3. 最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。

若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

握手为什么是三次？

三次握手其实就是建立一个TCP连接时，需要客户端和服务器总共发出3个包，进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常。指定自己的初始化序列号为后面的可靠性传送做准备。

第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力。服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收。发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收。发送能力正常，服务器自己的发送、接收能力也正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

四次挥手

  1. 第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。
  2. 第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
  3. 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
  4. 第四次挥手：主动关闭方收到 FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

挥手为什么是四次?

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送 SYN + ACK 报文。其中 ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

面试官，不要再问我三次握手和四次挥手

HTTP 的请求方法有哪些？GET和POST区别？

HTTP 的请求方法

GET和POST区别

HTTP状态码

  1. 1xx (信息性状态码) 接受的请求正在处理

  2. 2xx 成功 请求正常处理完毕

    • 200 OK 客户端发来的请求在服务器端被正常处理了
    • 204 No Content 服务器接收的请求已成功处理,但是返回的响应报文中不含实体的主体部分，另外,也不允许返回任何实体的主体
      一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
    • 206 Partial Content 客户端进行了范围请求,而服务器成功执行了这部分的Get请求,响应报文中包含Content-Range指定范围的实体内容

  3. 3xx 重定向 需要进行附加操作已完成请求

    • 301 Moved Permanently 永久性重定向
    • 302 Found 临时性重定向
    • 303 See Other 表示由于请求对应的资源错在着另一个URI,应用GET方法定性获取请求的资源
    • 304 Not Modified 表示客户端发送附带条件的请求时,服务器允许请求访问资源,但未满足条件的情况下
    • 附带条件的请求是指采用GET方法的请求报文中包含If-Match,If-Modified-Since, If-None-Match，If-Range，If-Unmodified-Since中任一的首部

  4. 4xx 客户端错误 服务器无法处理请求

    • 400 Bad Request 请求报文中存在语法错误
    • 401 Unauthorized 表示发送的请求需要有通过HTTP认证
    • 403 Forbidden 对请求资源的访问被服务器拒绝了
    • 404 Not Found 服务器无法找到请求的资源

  5. 5xx 服务器错误 服务器处理请求错误

    • 500 Internal Server Error 服务器在执行时发生了错误
    • 503 Service Unavailable 表明服务器暂时处于超负载或正在进行停机维护

WebSocket

HTTP协议通信只能由客户端发送，实现想消息通知的这种，我们只能使用“轮询”：每隔一段时间，就发出一个后端请求，询问有没有新的消息更新。

WebSocket 和 HTTP 一样，同属于应用层协议。它最重要的用途是实现了客户端与服务端之间的全双工通信，当服务端数据变化时，可以第一时间通知到客户端。

除此之外，它与http协议不同的地方还有：

WebSocket 教程

Ajax, Fetch, Axios

ajax

const xhr = new XMLHttpRequest();
xhr.open('GET', url);
xhr.onreadystatechange = function() {
    if (xhr.readyState === 4 && xhr.status === 200) {
        console.log(xhr.responseText)   // 从服务器获取数据
    }
}
xhr.send();

Fetch

Fetch的API是基于Promise设计的。fetch不是ajax的进一步封装，而是原生js，没有使用XMLHttpRequest对象

fetch(url)
    .then(response => {
        if (response.ok) {
            // fetch()请求返回的response是Stream对象，因此我们调用response.json时由于异步读取流对象所以返回的是一个Promise对象
            return response.json();
        }
    })
    .then(data => console.log(data))
    .catch(err => console.log(err))

MDN

axios

axios是对原生 XHR的封装，基于Promise的http库，适用于浏览器和node.js。有以下几大特性：

更多使用可以直接查阅 axios文档

相关文章推荐

上一篇下一篇

猜你喜欢

热点阅读