http和https

  从本篇文章开始总结http协议相关的知识点。http协议相关的内容可以分为四个部分：HTTP报文、HTTP请求、HTTP发展历史、HTTPS。

---

1. HTTP报文

  HTTP全称Hyper Text Transfer Protocol，即超文本传输协议。在OSI七层网络模型中，HTTP属于上层应用层的协议，是一种基于TCP实现的应用层协议（HTTP3改为基于UDP实现）。

1.1 Http是什么？

  http协议是一种无状态的、明文传输的数据传输协议。
  无状态是指，前后两次请求没有必然的联系，每次请求都是独立的。无状态协议对事务处理没有记忆能力，因此需要通过一些特殊手段来保存用户状态，比如浏览器和服务器可以通过cookie和session保存登录状态。

1.2. Http常见字段有哪些？

Request Headers

HTTP请求头

1. Accept：自己可以接受哪些数据。Accept:*/*
2. Accept-Encoding:客户端可以接受的哪些压缩方法对应的数据。Accept-Encoding:gzip,deflate,br
3. Connection：使用长连接，HTTP1.1默认使用长连接，为兼容老版本HTTP需要设置Connection:keep-alive
4. Host字段：请求头中用来指定服务器域名。Host:

Response Headers

HTTP响应头

1. Connection：使用长连接，HTTP1.1默认使用长连接，为兼容老版本HTTP需要设置Connection:keep-alive
2. Content-Encoding:数据压缩方式。Content-Encoding:gzip
3. Content-Length：本次响应的数据长度
4. Content-Type：服务器响应的数据格式。Content-Type:text/javascript;charset=utf-8

1.3. HTTP特性

  HTTP最突出的优点就是简单、灵活和跨平台。另外HTTP也具有无状态和明文传输两种既是优点又是缺点的特性。

HTTP有哪些优点

1. 简单。HTTP报文格式是header + body,请求头、响应头也是key-value类型简单文本格式。
2. 灵活。HTTP协议中请求方法、URL、状态码和头字段组成都允许开发人员自定义；HTTP工作在应用层，下层可以变化，如HTTPS就是在HTTP层和TCP层加了SSL/TLS安全传输层，HTTP3甚至把TCP换成了基于UDP的QUIC。
3. 跨平台。应用广泛，从浏览器到手机APP都应用到了HTTP，天然具有跨平台的优越性。

HTTP有哪些缺点
  HTTP的缺点是由HTTP的特性决定的，从一个角度讲，HTTP的特性既是优点又是缺点。我们已经知道HTTP是一种无状态的明文传输协议。

1. 无状态。

  无状态的好处在于，服务器不会去记忆HTTP的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，节省服务器CPU和内存资源。

  无状态的坏处在于，由于服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

1. 明文传输

  明文传输意味着所有信息都暴露出来，所有信息内容将毫无隐私可言，会导致内容被窃听或者身份容易伪装，容易被人篡改。

2. HTTP请求

1. GET: 获取资源
2. POST: 传输实体主体
3. PUT: 上传文件
4. DELETE: 删除文件
5. HEAD: 获取报文首部
6. PATCH: 对资源进行部分修改
7. OPTION: 查询指定的URL能够支持的方法
8. CONNECT: 要求用隧道协议连接代理
9. TRACE: 追踪路径

2.1. GET和POST

GET和POST区别

1. GET参数通过URL传递；POST放在Request body中。
2. GET参数直接暴露在URL中，不能传递敏感信息；POST可以。
3. GET参数在URL中，长度有限制；POST没有。
4. GET请求会被浏览器主动缓存；POST不会，除非手动设置。
5. GET请求的URL地址可以被收藏为书签；POST不可以。
6. GET请求参数会被保存在浏览历史中；POST不会。

2.2. HTTP状态码

1 - 信息。服务器收到请求，请继续执行请求
2 - 成功。请求被成功接收并处理
3 - 重定向。 需要进一步操作来完成请求
4 - 客户端错误。 无法完成请求，或请求包含语法错误
5 - 服务端错误。服务器在处理请求的过程中发生错误

https://blog.csdn.net/banana960531/article/details/85621865

3. HTTP1.1、HTTP2、HTTP3

3.1. HTTP1.1相对于HTTP1.0提高了什么性能？

  HTTP1.0采用短连接的设计，每次请求都需要经历三次握手和慢启动跟服务器建立TCP连接，响应结束就立即关闭，严重影响性能。服务器并不跟踪每个用户，也不记录过去的请求。

  长连接：HTTP1.1将短连接优化成了长连接，即一个TCP连接可以处理多次http请求。在请求头或响应头中可以看到一个connection参数，等于close时可以使TCP请求使用短连接，默认情况下是keep-alive（长连接）。

问题一：HTTP层面，浏览器发送数据的过程
   浏览器发送数据时，首先要先构造数据（HTTP格式）；其次调用操作系统提供的功能，建立TCP连接；最后发送数据。

问题二：HTTP长连接和Socket的关系

1. 一个Socket可以处理多个HTTP请求（Tomcat中可以设置），如Tomcat拿到一个请求后，解析connection字段中的内容。
2. 如果connection字段为closed，在处理完请求后，响应头中connection也为closed，双方就会关闭TCP连接。
3. 如果connection字段为keep-alive，在处理完请求后，响应头中connection也为keep-alive，双方就会共用TCP连接。也不是绝对，如Tomcat会设置最多保持的socket（活跃的长连接）的个数，以及一个socket（长连接）最多可以处理多少个HTTP请求（maxKeepRequestAlive选项），在Tomcat处理完指定个数的http请求后，发送的响应头中connection为closed。
   
   

问题三：长连接的缺点
  长连接也存在缺点：一个TCP连接中，所有的通信数据都是按照次序进行的，服务器只有完成一个请求，才会处理下一个请求，如果前面的请求阻塞了，后面的请求会一直等待，产生“队头阻塞”。

  并发：HTTP1.1支持对同一域名同时发起多个http请求（并发处理），但是针对同一域名的并发数量是有限制的。如果想要绕过并发数量的限制，可以将资源放到不同域名的服务器下。

3.2. HTTP2针对HTTP1.1做了哪些优化？

1. 多路复用: 数据传输性能显著提高。1.1版本中，多个http请求是通过开启多个TCP连接实现并发的；在2.0中，多个http请求的并发，是在同一个TCP连接中实现的。
2. 格式： HTTP 2.0采用二进制格式而非文本格式
3. 数据压缩： HTTP1.1不支持header数据压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络中传输也更快了。
4. 服务器推送： 当向支持HTTP2.0的web server发起请求数据时，服务器可以将一些客户端需要的静态资源一起推送到客户端，免得客户端再次创建连接发起请求到服务器端获取。

3.3. HTTP2有哪些缺陷？HTTP3做了哪些优化？

  QUIC协议 底层协议从TCP切换到UDP。我们知道UDP协议,没有流量控制，滑动窗口等机制，于是就不会对数据包顺序和丢包处理有要求，所以不会出现HTTP1.1中队头阻塞和HTTP2中丢包全部重传的问题。

  UDP协议是不可靠传输协议，但基于UPD的QUIC协议，可以在功能上实现类似TCP的可靠性。

1. 机制一：自定义连接机制

• 一条tcp连接是由四元组标识的，分别是源ip、源端口、目的端口，一旦一个元素发生变化时，就会断开重连，重新连接。再次进行三次握手，导致一定的延时。
• 在TCP是没有办法的，但是基于UDP，就可以在QUIC自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个64
  位的随机数作为ID来标识，而且UDP是无连接的，所以当ip或者端口变化的时候，只要ID不变，就不需要重新建立连接

1. 机制二：自定义重传机制

• tcp为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。任何一个序号的包发过去，都要在一定的时间内得到应答，否则一旦超时，就会重发这个序号的包，通过自适应重传算法（通过采样往返时间RTT不断调整）。
• 在TCP里面超时的采样存在不准确的问题。例如发送一个包，序号100，发现没有返回，于是在发送一个100，过一阵返回ACK101.客户端收到了，但是往返的时间是多少，没法计算。是ACK到达的时候减去第一还是第二。QUIC也有个序列号，是递增的，任何序列号的包只发送一次，下次就要加1，那样就计算可以准确了
• 但是有一个问题，就是怎么知道包100和包101发送的是同样的内容呢？quic定义了一个offset概念。QUIC既然是面向连接的，也就像TCP一样，是一个数据流，发送的数据在这个数据流里面有个偏移量offset，可以通过offset查看数据发送到了那里，这样只有这个offset的包没有来，就要重发。如果来了，按照offset拼接，还是能够拼成一个流。

1. 机制三： 无阻塞的多路复用

  有了自定义的连接和重传机制，就可以解决上面HTTP2.0的多路复用问题
  同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求。但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。这样，假如stream2丢了一个UDP包，后面跟着stream3的一个UDP包，虽然stream2的那个包需要重新传，但是stream3的包无需等待，就可以发给用户。

1. 机制四：自定义流量控制

• TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update，来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个steam控制窗口。
• 在TCP协议中，接收端的窗口的起始点是下一个要接收并且ACK的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为TCP的ACK机制是基于序列号的累计应答，一旦ACK了一个序列号，就说明前面的都到了，所以是要前面的没到，后面的到了也不能ACK,就会导致后面的到了，也有可能超时重传，浪费带宽
• QUIC的ACK是基于offset的，每个offset的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发，而窗口的起始位置为当前收到的最大offset，从这个offset到当前的stream所能容纳的最大缓存，是真正的窗口的大小，显然，那样更加准确。

 HTTPS建立连接，需要三次交互（三次握手+SSL三次握手），QUICK把这个过程缩减为了3次。因此，QUICK是一个在UDP之上的伪TCP+TLS+HTTP/2的多路复用协议。

4. https

  https使用了非对称加密技术和对称加密技术。1. 使用非对称加密技术实现共享秘钥的安全传输 2. 对传输数据的加密使用对称加密技术，秘钥就是非对称加密传输的共享秘钥。

4.1. SSL握手步骤

1. 客户端向服务器发送连接请求。
2. 服务器收到请求后，生成一个公私钥对；服务器向客户端发送安全证书，包含服务器生成的公钥
3. 客户端收到服务器发来的安全证书，对证书进行验证；随机生成一个对称加密秘钥，用服务器发来的公钥对其进行加密；客户端将加密后的对称秘钥发送给服务器，
4. 服务器收到后用私钥解密，就得到了客户端随机生成的那个对称秘钥。 此时客户端和服务器都有了对称秘钥，就可以使用该秘钥对数据进行加密传输了。

问题一：为什么不直接使用非对称加密，进行加密传输？
  使用公钥对数据进行加密要比对称加密的方式复杂，效率会很低。
问题二：安全证书的作用是什么？
  保证客户端收到的公钥就是服务器发送的，而不是中途有攻击者截取篡改后的。

4.2. CA证书

  数字证书是由CA(Certificate Authority)发行的并且对公开密钥做了签名，它可以保证客户端收到的公钥是合法的，不是伪造的。

CA证书签发过程

1. 服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；
2. CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
3. 如信息审核通过，CA 会向申请者签发认证文件-证书。
   证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；
   签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

CA证书验证

1. 客户端 C 向服务器 S 发出请求时，S 返回证书文件；
2. 客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；
3. 客户端然后验证证书相关的域名信息、有效时间等信息；
4. 客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

在这个过程注意几点：

1. 申请证书不需要提供私钥，确保私钥永远只能服务器掌握；
2. 证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；
3. 内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；
4. 证书=公钥+申请者与颁发者信息+签名；