大厂常见问题（3）----计算机网络之HTTP篇

1.Http是什么？描述一下
HTTP是超文本传输协议，也就是HyperText Transfer Protocol
2.能否详细解释“超文本传输协议”？
HTTP的名字可以分为三个部分：超文本 传输 协议
协议：HTTP是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为和规范）。
传输：HTTP是一个在计算机世界里专门用来在两点之间传输数据的约定和规范，它是一个双向协议。
超文本：HTTP传输的内容是“超文本”、
3.“HTTP是用于从互联网服务器传输超文本到本地浏览器的协议HTTP”，这种说法对吗？
不对，也可以是“服务器到服务器”，所以采用两点之间的描述会更准确。
4.HTTP常见的状态码，有哪些？
1xx：这类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2xx：这类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
200 OK：是最常见的成功状态码，表示一切正常。如果是非HEAD请求，服务器返回的响应头都会有body数据。
204 No Content：也是常见的成功状态码，与200 OK基本相同，但是响应头没有body数据。
206 Partial Content：是应用于HTTP分块下载或断电续传，表示响应返回的body数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
3xx：这类状态码表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向。
301 Moved Permanently：表示永久重定向，说明请求的资源已经不存在了，需改用新的URL再次访问。
302 Moved Permanently：表示临时重定向，说明请求的资源还在，但暂时需要用另一个URL来访问。
301和302都会在响应头里使用字段Location，指明后续要跳转的URL，浏览器会自动重定向新的URL。
304 Not Modified：不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。
4xx：这类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
400 Bad Request：表示客户端请求的报文有错误，但只是个笼统的错误。
403 Forbidden：表示服务器禁止访问资源，并不是客户端的请求出错。
404 Not Found：表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
5xx：这类状态码表示客户端请求报文正确，但服务器处理时内部发生了错误，属于服务端的错误码。
500 Internal Server Error：与400类型，是个笼统通用的错误码，服务器发生了什么错误，我们不知道。
501 Not Implemented：表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
502 Bad Gateway：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
503 Service Unavailable：表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。
5.HTTP常见字段有哪些？
Host：客户端发送请求时，用来指定服务器的域名。有了Host字段，就可以将请求发往同一台服务器上的不同网站。
Content-Length字段：服务器在返回数据时，会有Content-Length字段，表明本次回应的数据长度。
Connection：字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。HTTP/1.1版本的默认连接都是持久连接，但是为了兼容老版本 的HTTP，需要指定Connection首部字段的值为Keep-Alive。
Content-Type字段：字段用于服务器回应时，告诉客户端，本次数据是什么格式。上面的类型表明，发送的是网页，而且编码是UTF-8客户端请求的时候，可以使用Accept字段声明自己可以接受那些数据格式。
Content-Encoding字段：字段说明数据压缩方法。表示服务器返回的数据使用了什么压缩格式，若用Content-Encoding: gzip上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。
6.GET与POST？
get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本，页面，图片视频等。而POST方法则是相反操作，它向URI指定的资源提交数据，数据就放在报文的body里。
7.GET和POST方法都是安全和幂等的吗？
安全和幂等概念： 在HTTP协议里，所谓的安全是指请求方法不会破坏服务器上的资源。
所谓的幂等，意思是多次执行相同的操作，结果都是相同的。
很明显GET方法就是安全且幂等的，因为它是只读操作，无论操作多少次，服务器上个数据都是安全的，意思是多次执行相同的操作，结果都是相同的。
POST因为是新增或提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。
8.你知道的HTTP的优点有哪些，怎么体现的？
HTTP最突出的优点就是简单，灵活，易于扩展，应用广泛和跨平台。
简单：HTTP基本报文就是header+body，头部信息也是key-value简单文本的形式，易于理解，降低了学习和使用的门槛。
灵活和易于扩展：HTTP协议里的各类请求方法，URI/URL，状态码，头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。同时HTTP由于是工作在应用层（OSI第七层），则它下层可以随意变化。HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层，HTTP/3甚至把TCP层换成了基于UDP的QUIC。
应用广泛和跨平台：互联网发展至今，HTTP的应用范围非常的广泛，从台式机的浏览器到手机上的各种APP，HTTP的应用片地开花，同时天然具有跨平台的优越性。
9.HTTP的缺点？
HTTP协议里有优缺点一体的双刃剑，分别是无状态，明文传输，同时还有一大缺点不安全。
无状态双刃剑：无状态的好处，服务器不会记忆HTTP状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的CPU和内存用来对外提供服务；无状态的坏处，既然服务器没有记忆，他在关键性的操作就会很麻烦。每操作一次就需要验证信息。对于无状态问题，最简单的方式就是Cookie技术。Cookie通过在请求和响应报文中写入Cookie信息来控制客户端的状态。相当于在客户端第一次请求后，服务器会下发一个装有客户信息的小贴纸，后续客户端请求服务器的时候，带上小贴纸，服务器就可以认识了。
明文传输双刃剑：明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器F12控制台或Wireshark抓包都可以直接肉眼查看，为我们调试工作带来了极大的便利性。正因为这样，HTTP的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。
不安全：HTTP的严重缺点就是不安全：通信使用明文（不加密），内容可能会被窃听。
不验证通信方的身份，因此可能遭遇伪装。
无法证明报文的完整性所以有可能已遭篡改。
HTTP的安全问题，可以用HTTPS的方式解决，引用SSL/TLS层，使得安全上达到了极致。
10.说一下HTTP/1.1的性能如何？
HTTP协议是基于TCP/IP，并且使用了请求-应答的通信模式，所以性能的关键就是两点。
长连接：早期的HTTP/1.0性能上的一个很大问题，就是每发起一个请求，就要新建一次TCP连接（三次握手），而且是串行请求，做了无畏的TCP连接建立和断开，增加了通信开销。为了解决TCP连接问题，HTTP/1.1提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器的负载。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
管道网络传输：HTTP/1.1采用了长连接的方式，这使得管道网络传输成为了可能。即使在同一个TCP连接里面，客户端发起多个请求，只要第一个请求发出去了，不必等回来，就可以发送第二个，可以减少整体的响应时间。但是服务器按照顺序，先回答第一个请求，在回答第二个请求。如果前面回答的特别慢，后面就会有许多请求排队等着，这种称为队头堵塞。
队头阻塞：请求-应答的模式加剧了HTTP的性能问题。因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会导致客户端一直收不到数据，这就是队头阻塞。
HTTP/1.1的性能一般般，后续的HTTP/2和HTTP/3就是在优化HTTP的性能。
11.HTTP与HTTPS有哪些区别？
HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才可进入加密报文传输。
HTTP的端口号80，HTTPS的端口号是443.
HTTPS协议需要向CA申请数字证书，来保证服务器的身份是可信的。
11.HTTPS解决了HTTP的那些问题？
因为HTTP是明文传输所以存在三个风险：窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制输入垃圾广告
冒充风险，比如冒充各大网站。
HTTPS在HTTP与TCP层之间加入了SSL/TLS协议。可以解决上述风险
信息加密：交互信息无法被窃听
校验机制：无法篡改通信内容，篡改了就不能正常显示。
身份证书：就是为了证明各大网站。
12.HTTPS如何解决上述风险的？
混合加密的方式实现信息的机密性，解决了窃听的风险。
摘要算法的方式来实现完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了篡改的风险。
将服务器公匙放到数字证书中，解决了冒充的风险。
混合加密：HTTPS采用的是对称加密和非对称加密结合的混合加密方式
在通信建立前采用非对称加密的方式交换会话密钥，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的会话秘钥的方式加密明文数据。
采用混合加密的原因：
对称加密只使用一个秘钥，运算速度快，秘钥必须保密，无法做到安全的秘钥交换。
非对称加密使用两个秘钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了秘钥交换问题但速度慢。
摘要算法：客户端在发送明文之前会通过摘要算法算出明文的指纹，发送的时候把指纹+明文一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前算出的指纹作比较，若指纹相同，说明数据是完整的。
数字证书;需要借助第三方权威机构CA（数字证书认证），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
13.HTTPS是如何建立连接的？期间交互了什么？
SSL/TLS协议的基本流程：
客户端向服务器索要并验证服务器的公钥。
双方协商生产会话秘钥。
双方采用会话秘钥进行加密通信。
前两步也就是SSL/TLS的建立过程，也就是握手阶段。
SSL/TLS协议建立的详细流程：
ClientHello：首先，客户端向服务器发起加密通信请求，也就是ClientHello请求。这步，客户端向服务器发送以下信息。
客户端支持的SSL/TLS协议版本。
客户端生产的随机数（Client Random），后面用于生产会话秘钥。
客户端支持的密码套件列表，如：RSA加密算法。
SeverHello：服务器收到客户端请求后，向客户端发出响应，也就是SeverHello。服务器回应以下内容。
确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信。
服务器生产的随机数（Sever Random），后面用于生产会话秘钥。
确认的密码套件列表，如RSA加密算法。
服务器的数字证书。
客户端回应：客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
一个随机数（pre-master Key）。该随机数会被服务器公钥加密。
加密通信算法通知，表示随后的信息都将用会话秘钥加密通信。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
第一项的随机数是整个握手阶段的第三个随机数，这样的服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的会话秘钥。
服务器的最后的回应：服务器收到客户端的第三个随机数（pre-master Key）之后，通过协商的加密算法，计算出本次通信的会话秘钥，然后，向客户端发送最后的信息：
加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信。
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。至此，整个SSL/TLS的握手阶段全部结束。然后，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用会话秘钥加密内容。
14. HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
性能上的改进：使用TCP长连接的方式改善了HTTP/1.0短连接造成的性能开销。
支持管道网络传输，只要第一个请求发出去了，不必等它回来，就可以发送第二个请求，减少整体的响应时间
HTTP/1.1性能瓶颈：
请求/响应头部未经压缩就发送，首部信息越多延迟越大。只能压缩Body部分；
发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
服务器是按请求顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据，也就是队头堵塞；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。
15.HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性是有保障的。
头部压缩：HTTP/2会压缩头，如果你同时发送多个请求，它的头是一样的或者是相似的，那么，协议会消除重复的部分。这就是HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不在发送同样字段了，只发送索引号，这样就提高速度了。
二进制格式：HTTP/2不像HTTP/1.1里的纯文本形式报文，而是全面采用了二进制格式。头信息和数据体都是二进制，并且统称为帧：头信息帧和数据帧。虽然这样对人不太友好，但是对计算机非常友好，计算机识别二进制，减少了报文转换二进制的过程，这增加了数据传输的效率。
数据流：HTTP/2的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，需要对数据包做标记，指出它属于那个回应。每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发送的数据流编号为偶数。客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
多路复用：HTTP/2是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了HTTP/1.1中的串行请求，不需要排队等待，也不会再出现队头阻塞问题，降低了延迟，大幅度提高了连接的利用率。
服务器推送：HTTP/2还在一定程度上改善了传统的请求-应答工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
16.HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？
HTTP/2主要问题在于：多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生了丢包现象，就会触发TCP重传机制，这样一个TCP连接中的所有的HTTP请求都必须等待这个丢了的包被重传回来。
HTTP/1.1中的管道传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2多请求复用一个TCP连接，一旦发生丢包，就会阻塞所有的HTTP请求。
这都是基于TCP传输层的问题，所以HTTP/3把HTTP下层的TCP协议改成了UDP。UDP是不管顺序，也不管丢包的，所以不会出现HTTP/1.1的队头阻塞和HTTP/2的一个丢包全部重传问题。
大家都知道UDP是不可靠传输，但基于UDP的QUIC协议可以实现类似UDP的可靠性传输。
QUIC有自己的一套机制可以保证传输的可靠性。当某个流发生丢包时，只会阻塞这个流，其他流不会发生影响。
TL3升级成了最新的1.3版本，头部压缩算法升级成了QPACK。
HTTPS要建立一个连接，要花费6次交互，先是建立三次握手，然后是TLS/1.3的三次握手。QUIC直接把以往的TCP和TLS/1.3的6次交互合并成了3次，减少了交互次数。所以，QUIC是一个在UDP之上的伪TCP+TLS+HTTP/2的多路复用的协议。
QUIC是新协议，对于很多网络设备，根本不知道什么是QUIC，只会当做UDP，这样会出现新的问题。所以HTTP/3现在的普及的进度非常缓慢，不知道未来UDP是否能逆袭TCP。