2.应用层

2.1说说HTTP协议是什么？

HTTP协议是超文本传输协议。意思就是在计算机网络世界中，在两点之间传输文本、图片、视频、音频等超文本信息的约定和规范。

2.2说说Http常见的状态码，有哪些？

2xx表示服务器成功处理了客户端的请求
[200 Ok]最常见的成功状态码，表示一切正常。
[204 Not Content]也是最常见的成功状态码，与200 OK基本相同，但响应头没有body数据。
[206 Partial Content]是应用于HTTP分块下载或断点续传，表示响应返回的body数据并不是资源的全部，而是其中一部分，也是服务器处理成功的状态。
3xx表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向
[301 Moved permanently]表示永久重定向，说明请求的资源已经不存在了，需要改用新的URL再次访问。
[302 Found]表示临时重定向，说明请求的资源还在，但暂时需要用另一个URL来访问。
301和302都会在响应头里使用字段Location，指明稍微要跳转的URL，浏览器会自动重定向到新的URL。
4xx表示客户端发送的报文有误，服务器无法处理
[400 Bad Request]表示客户端请求的报文有错误，但只是个笼统的错误。
[403 Forbidden]表示服务器禁止访问资源，并不是客户端的请求出错。
[404 Not Found]表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
5xx表示客户端请求报文正常，但是服务器处理内部发生了错误，属于服务器端的错误码
[500 Internal Server Error]笼统的错误码，服务器发生了什么错误，我们并不知道。
[501 Not implemented]表示客户端请求的功能还不支持。
[502 Bad GateWay]通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
[503 Service Unavailable]表示服务器当前很忙，暂时无法响应。

2.3说说HTTP常见的字段有哪些？

Host字段：客户端发送请求时，用来指定服务器的域名。有了Host字段，就可以将请求发往同一台服务器上的不同网站。

Content-Length字段：服务器在返回数据时，会有Content-Length字段表示本次回应的数据长度。

Connection字段：客户端要求服务器使用TCP持久连接，比便其他请求复用。Http1.1默认连接都是持久连接，但为了兼容1.0，需要制定Connection字段的值为Keep-Alive。

Content-Type字段：用于服务器回应时，告诉客户端，本次数据使用的是什么格式。比如，表明发送的是网页，编码是uft-8.

Accept字段：客户端声明自己可以接受什么格式的数据。
Content-Encoding字段：说明数据的压缩方式，表明服务器返回的数据使用了什么压缩格式。比如gzip

2.4说说Get请求和Post请求的区别

get请求：表示从服务器指定路径上获取资源，这个资源可以是静态的文本、页面、图片、视频等。
post请求：向URL指定的资源提交数据，数据就放在请求体里。
最直观的区别：
（1）get请求是安全且幂等的，因为它是只读的操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同；post请求因为是提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。
（2）get请求会被浏览器主动缓存，而post请求不会，除非手动设置。
（3）get请求在url中传送的参数是有长度限制的，而post请求没有。
（4）get请求的参数通过url传递，而post请求的参数放在request body里。
但get请求与post请求是http协议中两种发送请求的方法，get和post的底层是tcp/ip，所以get请求和post请求能做的事情都是一样的，给get加上request body，给post带上url参数，技术上也是行得通的；但大多数浏览器都会限制url长度在2k个字节，而大多数服务器最多处理64k大小的url，超过的部分有可能就不会处理了；如果你用get请求，在request body里藏了数据，不同服务器的处理方式是不同的，有些服务器会取出请求体的请求参数，有些服务器会直接忽略。
另外get请求会产生一个tcp数据包，post请求会产生两个tcp数据包。对于get方式的请求，浏览器会把http头和数据data一并发送出去，服务器响应200(返回数据)；而对于post请求，浏览器先发送header，服务器响应100continue，浏览器再发送data，服务器响200ok。

2.5说说HTTP的优点有哪些，怎么体现的？

（1）简单
HTTP基本的报文格式就是header+body，头部信息也是key-value简单文本的形式，容易理解，降低学习门槛。
（2）灵活和易于扩展
HTTP协议里的各类请求方法、URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
并且由于HTTP工作在最上层，它下层是可以随意变化的。
比如HTTPS就是在HTTP与TCP层之间增加了SSL/TLS安全传输层，HTTP3甚至把TCP层换成了基于UDP的QUIC。
（3）应用广泛和跨平台
互联网发展到今天，HTTP的应用范围非常广泛，从台式机到移动端APP，从看新闻、刷贴吧到抖音短视频、吃鸡、理财、淘宝等，HTTP的应用遍地开花，同时天然具有跨平台的优越性。

2.6说说HTTP的缺点有哪些，怎么体现的？

HTTP协议里有优缺点一体的双刃剑[无状态、明文传输]，同时还有一大缺点就是不安全。
无状态的好处：服务器不会去记忆HTTP的状态，不需要额外的资源来记录状态信息，这能减轻服务器的负担，把更多的CPU和内存用来对外提供服务。
无状态的坏处：在完成关联性操作的时候会非常麻烦。比如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行，但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。解决方式：Cookie技术
【不安全】
1.通信使用明文(不加密)，内容可能会被窃听，信息容易泄露
2.不验证通信方的身份，有可能遭到伪装，比如假淘宝、假拼多多。
3.无法验证报文的完整性，所以有可能已遭篡改。比如网页上植入垃圾广告。

2.6说说HTTP的性能怎么样？

HTTP1.0在性能上有一个很大的问题就是，每发起一次请求服务器响应一次请求，都需要经历三次握手、四次挥手的过程，增加通信开销。
HTTP1.1提出了长连接的通信方式，减少重复建立连接和断开所造成的的额外开销。

因为Http1.1使用了长连接的方式，使得管道网络传输称为了可能。
管道网络传输就是可在同一个TCP连接里面，客户端同时发起多次请求，只要第一个请求发出去了，不必要等它回来，就可以发送第二次请求出去，减少整体的响应时间。但是服务器还是按照顺序，先回应A请求，再回应B请求，要是前面的回应特别慢，后面就会有很多请求积压，这就是对头阻塞。

2.7说说HTTPS如何解决HTTP的不安全问题的？

窃听问题：使用混合加密的方式实现信息的机密性。
HTTPS在通信建立前采用非对称加密的方式交换[会话密钥]，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的[会话密钥]的方式加密明文数据。
对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发，而私钥保密，解决了密钥交换问题但速度慢。
篡改问题：使用摘要算法的方式实现信息传输的完整性验证。
客户端在发送明文之前会通过摘要算法算出明文的[指纹]，发送的时候把[指纹+明文]一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的[指纹]和当前算出的[指纹]做比较，如果相同，说明数据是完整的。
冒充问题：将服务器公钥放入到数字证书中，解决冒充的风险。
客户端先向服务器索要数字证书，从数字证书中获取公钥，然后用公钥加密，服务器收到密文后，用自己的私钥解密。

（1）服务器把自己的公钥注册到CA。
（2）CA用自己的私钥将服务器的公钥数字签名并颁发数字证书。
（3）客户端向服务器索要数字证书，拿到数字证书之后，使用CA的公钥进行确认服务器数字证书的真实性
（4）从数字证书中获取服务器公钥使用它对报文加密后发送。
（5）服务器用私钥对报文解密。

2.8说说Https是如何建立连接的？

【1】ClientHello
客户端向服务器发起加密通信请求，主要发送以下内容：
（1）客户端支持的SSL/TLS协议版本，比如TLS1.2版本；
（2）客户端生成的随机数，后面用于生成会话密钥；
（3）客户端支持的密码套接列表，比如RSA加密算法；
【2】ServerHello
服务器收到客户端的请求后，向客户端发出响应，主要发送以下内容：
（1）确认SSL/TLS协议版本，如果客户端不支持，就关闭加密通道；
（2）服务器生成的随机数，后面用于生成会话密钥；
（3）确认的密码套接列表，比如RSA加密算法；
（4）服务器的数字证书；
【客户端回应】
客户端收到服务器的回应之后，通过浏览器或操作系统中的CA公钥，确认服务器数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数，该随机数会被公钥加密；
（2）加密通信算法改变通知，表示随后的信息都将用[会话密钥]加密通信；
（3）客户端握手结束通知。同时会之前所有内容发生的数据做个摘要，用来供服务器校验。
【服务器的最后响应】
服务器收到客户端的第三个随机数之后，通过协商的加密算法，计算出本次通信的[会话密钥]。然后向客户端发出如下内容：
（1）加密通信算法改变通知，表示随后的信息都将用[会话密钥]加密通信。
（2）服务器端握手结束通知。同时会把之前所有内容发生的数据做个摘要，用来供客户端校验。
到此，整个SSL/TLS的握手阶段就全部结束了。接下来，客户端和服务器进入加密通信。就完全是使用普通的HTTP协议，只不过数据部分都使用了会话密钥来加密内容。

2.9说说HTTP2比1.1做出了哪些改进？

HTTP1.1的性能瓶颈
（1）请求头、响应头没有经过压缩就发送，首部信息越多延迟越大，只能压缩Body的部分；
（2）发送冗长的头部。每次互相发送相同的头部造成浪费；
（3）服务器是按照请求的顺序来响应的，如果服务器响应慢，就导致对头阻塞；
（4）没有请求优先级控制；
（5）请求只能从客户端开始，服务器只能被动响应；
HTTP2.0性能上的改进
（1）头部压缩
HTTP2会使用静态表和霍夫曼编码压缩头部信息，如果同时发出多个请求，他们的请求头是一样的或者是相似的，协议会帮你清除重复的部分。就是HPACK算法：在客户端和服务器同时维护一张头部信息表，所有字段都会存入这个表，生成一个索引号，只发送索引号。针对后续的请求头部，还可以建立动态表，压缩体积，提高编码效率，节约带宽资源。
不过动态表会占用内存，容易影响服务器总体的并发能力，因此服务器需要限制http2的连接时长或请求次数。
（2）二进制格式
HTTP2不再像1.1那样纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制的。这样对人虽然不友好，但是对计算机是非常有好的。收到报文之后，就不需要将明文的报文转成二进制，而是直接解析二进制报文，增加数据传输的效率。
（3）数据流
HTTP2的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为一个数据流。每个数据流都标记着一个独一无二的标号，其中规定客户端发送的数据流编号是奇数，服务器发送的数据流编号是偶数。客户端还可以指定数据流的优先级，优先级高的请求，服务器就先响应该请求。
（4）多路复用
HTTP1.1的数据都是基于文本的，只能按按顺序传输，HTTP2可以在一个连接中并发多个请求或回应，不用按照顺序一一对应。解决了HTTP1.1的串行请求，不需要排队等待，不会出现队头阻塞的问题，降低了延迟，大幅度提高了连接的利用率。简单来说，在一个TCP连接里，服务器收到了客户端A和客户端B的两个请求，如果发现A处理过程非常耗时，就会回应A请求已经处理好的部分，接着回应B请求，完成后再回应A请求剩下的部分。

（5）服务器推送
浏览器在请求html的时候，就提前把可能会用到的JS、CSS文件等静态资源主动发给客户端，减少延时的等待。
HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？
HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，因为传输格式是文本的，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的队头阻塞。
HTTP/2多个请求可同时在一个连接上并行执行（由于支持二进制的格式，可以无序）某个请求任务耗时严重，不会影响到其它连接的正常执行。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

2.10说说HTTP3比2做出了哪些改进？

【HTTP2】
HTTP2使用静态表+霍夫曼编码进行头部压缩、数据不基于文本而是二进制流、多路复用、服务器推送等新特性大幅度提升了HTTP1.1的性能，而美中不足的是HTTP2协议是基于TCP实现的，主要的缺陷有三个。
（1）队头阻塞：HTTP2多个请求是跑在一个TCP连接中的，那么当TCP丢包时，整个TCP都要等待重传，那么久会阻塞该TCP连接中的所有请求。因为TCP是字节流协议，TCP层必须保证收到的字节数据是完整且有序的，如果序列号较低的TCP段在网络传输中丢失了，即使序列号高的TCP段已经被接受了，应用层也无法从内核中读取到这部分数据，从HTTP视角看，就是请求被阻塞了。
（2）TCP和TLS的握手时延迟：发起HTTP请求时，需要经过TCP三次握手和TLS四次握手(TLS1.2)的过程，因此共需要3个RTT的时延才能发送请求数据。另外，TCP由于具有拥塞控制的特性，所有刚建立连接的TCP会有个慢启动的过程，它会对连接产生减速效果。
（3）网络迁移需要重新连接：一个TCP连接是由一个四元组(源端口、源IP地址、目的端口、目的IP地址)确定的，这意味着如果IP地址或者端口变动了，就会导致需要TCP和TLS重新握手，这不利于移动设备切换网络的场景，比如从4G网络环境切换成WIFI。
以上都是TCP协议固有的问题，无论应用层的HTTP2怎么设计都无法逃脱。要解决这个问题，就必须把传输层协议替换成UDP。
【HTTP3】
HTTP3不仅仅只是简单得讲传输层协议替换成了UDP，还基于UDP协议在适应层实现了QUIC协议，它具有类似TCP的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠的UDP协议变成可靠的了。所以不用当心数据包丢失的问题。QUIC协议的优点有很多，比如：无队头阻塞、更快的连接建立、连接迁移。
（1）无队头阻塞：QUIC也有类似HTTP2/Stream与多路复用的概念，也是可以在同一个连接上并发传输多个Stream，Stream可以认为是一条HTTP请求。由于QUIC使用的传输协议是UDP，UDP不关心数据包的顺序，如果数据包丢失，UDP也不关心。不过QUIC协议会保证数据包的可靠性，每个数据包都有一个序号唯一标识，当某个流中的一个数据包丢失了，即使该流其他的数据包达到了，数据也无法被HTTP3读取，直到QUIC重传丢失的报文，数据才会交给HTTP3。而其他流的数据报文只要被完整接收，HTTP3就可以读取到数据，这与HTTP2不同，HTTP2只要某个流中的数据报丢失了，其他流也会因此受到影响。所以QUIC连接上的多个Stream之间没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。
（2）更快的连接建立：HTTP3在传输数据前虽然需要QUIC协议握手，但这个握手过程只需要1RTT，握手的目的就是为了确认双方的连接ID，连接迁移就是基于连接ID实现的。HTTP3的QUIC协议并不是与TLS分层，而是QUIC内部包含了TLS，它在自己的帧会携带TLS里的记录，再加上QUIC使用的是TLS1.3，因此只需要1个RTT就可以同时完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据报可以和QUIC握手信息(连接信息+TLS信息)一起发送，达到0-RTT的效果。
（3）数据迁移：QUIC协议没有用四元组的当时来绑定连接，而是通过连接ID来表示通信的两个断点，客户端和服务器可以各自选择一组ID来标识自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要仍保有上下文信息(比如连接ID、TLS密钥等)，就可以复用原连接，消除重连的成本。