客户端请求出错，服务器无法处理请求
ServerError（服务器错误）
服务器处理请求出错
2xx（3种）各类别常见状态码：
200OK：表示从客户端发送给服务器的请求被正常处理并返回；如果是非HEAD请求,服务器返回的响应头都会有body数据。
204NoContent：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
206PatialContent：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容，应用于HTTP分块下载或断点续传,表示响应返回的body数据并不是资源的全部,而是其中的一部分,也是服务器处理成功的状态
3xx（5种）
301MovedPermanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL），301和302都会在响应头里使用字段Location,指明后续要跳转的URL,浏览器会自动定向新的URL。
303SeeOther：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
302与303的区别：后者明确表示客户端应当采用GET方式获取资源
304NotModified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
307TemporaryRedirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；
4xx（4种）
400BadRequest：表示请求报文中存在语法错误；
401Unauthorized：未经许可，需要通过HTTP认证；
403Forbidden：服务器拒绝该次访问（访问权限出现问题）
404NotFound：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
499客户端主动断开链接
5xx（3种）
500InterServerError：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；、
502BadGateway：通常是服务器作为网关或代理时返回的错误码,表示服务器自身工作正常,访问后端服务器发生了错误。
503ServerUnavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
requestheaders:
responseheaders:
Get方法的含义是请求从服务器获取资源,这个资源可以是静态的文本、面、图片视频等。
而POST方法则是相反操作,它向URI指定的资源提交数据,数据就放在报文的body里。
GET和POST方法都是安全和幂等的吗
先说明下安全和幂等的概念：在HTTP协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的。
那么很明显GET方法就是安全且幂等的,因为它是「只读」操作,无论操作多少次,服务器上的数据都是安全的,且每次的结果都是相同的。
POST因为是「新增或提交数据」的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以不是幂等的
HTTP最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。
1.简单
HTTP基本的报文格式就是header+body,头部信息也是key-value简单文本的形式,易于理解,降低了学习和使用的槛。
2.灵活和易于扩展HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员自定义和扩充。
同时HTTP由于是工作在应用层(OSI第七层),则它下层可以随意变化。
HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层,HTTP/3甚至把TCP层换成了基于UDP的QUIC。
3.应用广泛和跨平台互联网发展至今,HTTP的应用范围非常的广泛,从台式机的浏览器到手机上的各种APP,从看新闻、刷贴吧到购物、理财、吃鸡,HTTP的应用片地开花,同时天然具有跨平台的优越性。
缺点呢？
HTTP协议里有优缺点一体的双刃剑,分别是「无状态、明文传输」,同时还有一大缺点「不安全」。
1.无状态双刃剑
无状态的好处,因为服务器不会去记忆HTTP的状态,所以不需要额外的资源来记录状态信息,这能减轻服务器的负担,能够把更多的CPU和内存用来对外提供服务。
无状态的坏处,既然服务器没有记忆能力,它在完成有关联性的操作时会非常麻烦。
这样每操作一次,都要验证信息,这样的购物体验还能愉快吗别问,问就是酸爽!对于无状态的问题,解法方案有很多种,其中比较简单的方式用Cookie技术。
Cookie通过在请求和响应报文中写入Cookie信息来控制客户端的状态。相当于,在客户端第一次请求后,服务器会下发一个装有客户信息的「小贴纸」,后续客户端请求服务器的时候,
带上「小贴纸」,服务器就能认得了了,
3.不安全HTTP比较严的缺点就是不安全:
通信使用明文(不加密),内容可能会被窃听。比如,账号信息容易泄漏,那你号没了。
不验证通信方的身份,因此有可能遭遇伪装。比如,访问假的淘宝、拼多多,那你钱没了。
HTTP的安全问题,可以用HTTPS的方式解决,也就是通过引入SSL/TLS层,使得在安全上达到了极致。
为了解决上述TCP连接问题,HTTP/1.1提出了连接的通信方式,也叫持久连接。这种方式的好处在于减少了TCP连接的复建立和断开所造成的额外开销,减轻了服务器端的负载。
持久连接的特点是,只要任意一端没有明确提出断开连接,则保持TCP连接状态。
2.管道网络传输
举例来说,客户端需要请求两个资源。以前的做法是,在同一个TCP连接里面,先发送A请求,然后等待服务器做出回应,收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求。
3.队头阻塞
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一同被阻塞了,会招致客户端一直请求不到数据,这也就是「队头阻塞」。好比上班的路上塞。
如果维持连接，一个TCP连接是可以发送多个HTTP请求的。
一个TCP连接中HTTP请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？
虽然HTTP/1.1规范中规定了Pipelining来试图解决这个问题，但是这个功能在浏览器中默认是关闭的。
先来看一下Pipelining是什么，RFC2616中规定了：
至于标准为什么这么设定，我们可以大概推测一个原因：由于HTTP/1.1是个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。比如你向服务器发送了两个请求GET/queryq=A和GET/queryq=B，服务器返回了两个结果，浏览器是没有办法根据响应结果来判断响应对应于哪一个请求的。
Pipelining这种设想看起来比较美好，但是在实践中会出现许多问题：
所以现代浏览器默认是不开启HTTPPipelining的。
但是，HTTP2提供了Multiplexing多路传输特性，可以在一个TCP连接中同时完成多个HTTP请求。至于Multiplexing具体怎么实现的就是另一个问题了。
所以这个问题也有了答案：在HTTP/1.1存在Pipelining技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在HTTP2中由于Multiplexing特点的存在，多个HTTP请求可以在同一个TCP连接中并行进行。
那么在HTTP/1.1时代，浏览器是如何提高页面加载效率的呢？主要有下面两点：
浏览器对同一Host建立TCP连接到数量有没有限制？
假设我们还处在HTTP/1.1时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？肯定不能只开一个TCP连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个TCP连接发HTTP请求，那电脑或者服务器都可能受不了，要是有1000张图片的话总不能开1000个TCP连接吧，你的电脑同意NAT也不一定会同意。
所以答案是：有。Chrome最多允许对同一个Host建立六个TCP连接。不同的浏览器有一些区别。
那么回到最开始的问题，收到的HTML如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？
如果图片都是HTTPS连接并且在同一个域名下，那么浏览器在SSL握手之后会和服务器商量能不能用HTTP2，如果能的话就使用Multiplexing功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个TCP连接去获取，但是可以确定的是Multiplexing很可能会被用到。
如果发现用不了HTTP2呢？或者用不了HTTPS（现实中的HTTP2都是在HTTPS上实现的，所以也就是只能使用HTTP/1.1）。那浏览器就会在一个HOST上建立多个TCP连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。
窃听险,比如通信链路上可以获取通信内容,用户号容易没。
HTTPS在HTTP与TCP层之间加入了SSL/TLS协议,可以很好的解决了上述的险:
信息加密:交互信息无法被窃取,但你的号会因为「自身忘记」账号而没。
身份证书:证明淘宝是真的淘宝网,但你的钱还是会因为「剁手」而没。
HTTPS采用的是对称加密和非对称加密结合的「混合加密」方式:
在通信建立前采用非对称加密的方式交换「会话秘钥」,后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
采用「混合加密」的方式的原因:
对称加密只使用一个密钥,运算速度快,密钥必须保密,无法做到安全的密钥交换。非对称加密使用两个密钥:公钥和私钥,公钥可以任意分发而私钥保密,解决了密钥交换问题但速度慢。
2.摘要算法
摘要算法用来实现完整性,能够为数据生成独一无二的「指纹」,用于校验数据的完整性,解决了篡改的险。
客户端在发送明文之前会通过摘要算法算出明文的「指纹」,发送的时候把「指纹+明文」一同加密成密文后,发送给服务器,服务器解密后,用相同的摘要算法算出发送过来的明文,
通过比较客户端携带的「指纹」和当前算出的「指纹」做比较,若「指纹」相同,说明数据是完整的。
3.数字证书
客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。这就存在些问题,如何保证公钥不被篡改和信任度
所以这里就需要借助第三方权威机构CA(数字证书认证机构),将服务器公钥放在数字证书(由数字证书认证机构颁发)中,只要证书是可信的,公钥就是可信的。
SSL/TLS协议基本流程:
客户端向服务器索要并验证服务器的公钥。双方协商生产「会话秘钥」。双方采用「会话秘钥」进行加密通信。前两步也就是SSL/TLS的建立过程,也就是握手阶段。
SSL/TLS协议建立的详细流程:1.ClientHello首先,由客户端向服务器发起加密通信请求,也就是ClientHello请求。在这一步,客户端主要向服务器发送以下信息:(1)客户端支持的SSL/TLS协议版本,如TLS1.2版本。(2)客户端生产的随机数(ClientRandom),后面用于生产「会话秘钥」。
(3)客户端支持的密码套件列表,如RSA加密算法。2.SeverHello服务器收到客户端请求后,向客户端发出响应,也就是SeverHello。服务器回应的内容有如下内容:
(1)确认SSL/TLS协议版本,如果浏览器不支持,则关闭加密通信。(2)服务器生产的随机数(ServerRandom),后面用于生产「会话秘钥」。
(3)确认的密码套件列表,如RSA加密算法。(4)服务器的数字证书。3.客户端回应客户端收到服务器的回应之后,首先通过浏览器或者操作系统中的CA公钥,确认服务器的数字证书的真实性。如果证书没有问题,客户端会从数字证书中取出服务器的公钥,然后使用它加密报文,
向服务器发送如下信息:
(1)一个随机数(pre-masterkey)。该随机数会被服务器公钥加密。
(2)加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
(3)客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数,这样服务器和客户端就同时有三个随机数,接着就用双方协商的加密算法,各自生成本次通信的「会话秘钥」。
4.服务器的最后回应服务器收到客户端的第三个随机数(pre-masterkey)之后,通过协商的加密算法,计算出本次通信的「会话秘钥」。然后,向客户端发生最后的信息:
(1)加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。会话秘钥的产生是客户端随机数＋服务端随机数＋pre-master算出会话秘钥
(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供客户端校验。
至此,整个SSL/TLS的握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用「会话秘钥」加密内容。
HTTP/1.1相比HTTP/1.0性能上的改进:使用TCP连接的方式改善了HTTP/1.0短连接造成的性能开销。
但HTTP/1.1还是有性能瓶颈:
请求/响应头部(Header)未经压缩就发送,首部信息越多延迟越大。只能压缩Body的部分;
发送冗的首部。每次互相发送相同的首部造成的浪费较多;
服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据,也就是队头阻塞;
没有请求优先级控制；
请求只能从客户端开始,服务器只能被动响应。
那HTTP/2相比HTTP/1.1性能上的改进:1.头部压缩
HTTP/2会压缩头(Header)如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。
这就是所谓的HPACK算法:在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
2.二进制格式HTTP/2不再像HTTP/1.1里的纯文本形式的报文,而是全面采用了二进制格式,头信息和数据体都是二进制,并
且统称为帧(frame):头信息帧和数据帧。
3.数据流HTTP/2的数据包不是按顺序发送的,同一个连接里面连续的数据包,可能属于不同的回应。因此,必须要对数据包做标记,指出它属于哪个回应。
每个请求或回应的所有数据包,称为一个数据流(Stream)。每个数据流都标记着一个独一无二的编号,其中规定客户端发出的数据流编号为奇数,服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级。优先级高的请求,服务器就先响应该请求。
4.多路复用HTTP/2是可以在一个连接中并发多个请求或回应,而不用按照顺序一一对应。
移除了HTTP/1.1中的串行请求,不需要排队等待,也就不会再出现「队头阻塞」问题,降低了延迟,大幅度提高了连接的利用率。
举例来说,在一个TCP连接里,服务器收到了客户端A和B的两个请求,如果发现A处理过程非常耗时,于是就回应A请求已经处理好的部分,接着回应B请求,完成后,再回应A请求剩下的部分。
5.服务器推送HTTP/2还在一定程度上改善了传统的「请求-应答」工作模式,服务不再是被动地响应,也可以主动向客户端发
送消息。举例来说,在浏览器刚请求HTML的时候,就提前把可能会用到的JS、CSS文件等静态资源主动发给客户端,减
少延时的等待,也就是服务器推送(ServerPush,也叫CachePush)。
HTTP/2主要的问题在于,多个HTTP请求在复用一个TCP连接,下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生了丢包现象,就会触发TCP的传机制,这样在一个TCP连接中的所有的HTTP请求都必须等待这个丢了的包被重传回来。
HTTP/1.1中的管道(pipeline)传输中如果有一个请求阻塞了,那么队列后请求也统统被阻塞住了HTTP/2多个请求复用一个TCP连接,一旦发生丢包,就会阻塞住所有的HTTP请求。
这都是基于TCP传输层的问题,所以HTTP/3把HTTP下层的TCP协议改成了UDP!
UDP发生是不管顺序,也不管丢包的,所以不会出现HTTP/1.1的队头阻塞和HTTP/2的一个丢包全部传问题。
大家都知道UDP是不可靠传输的,但基于UDP的QUIC协议可以实现类似TCP的可靠性传输。QUIC有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响。
TLS3升级成了最新的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。