文章思路
HTTP基本概念：
- 基本概念 - HTTP是什么？
- 状态码 - HTTP常见的状态码有哪些？
- 首部字段 - HTTP常见的首部字段有哪写？
- 请求方法 - HTTP常见的请求方法有哪写？Get和Post的区别？
HTTP的特性：
- HTTP的特点 - （HTTP1.1）的优点有哪些？缺点有哪写？Cookie是什么？Session是什么？跨域攻击？
- HTTP1.1的性能 - HTTP1.1的性能特点，可能会和HTTP1.0，2.0，3.0对比。
HTTPS：
- HTTP和HTTPS的区别
- HTTPS主要解决了哪写问题？
- HTTPS如何解决的上面出现的问题？
HTTP版本演变和区别：
- HTTP1.1比HTTP1.0的提升之处？有什么缺陷？
- HTTP2.0做了什么优化？有什么缺陷?
- HTTP3.0做了什么优化？
一、HTTP基本概念
- 基本概念 - HTTP是什么？
- HTTP报文格式 - HTTP报文格式是什么样的？HTTP常见的首部字段有哪写？
- 状态码 - HTTP常见的状态码有哪些？
- 请求方法 - HTTP常见的请求方法有哪写？Get和Post的区别？
1. 基本概念
HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。
2. HTTP报文格式 - 常用首部字段
- 报文首部
- 请求行 / 状态行：请求方法 / 响应状态 + HTTP版本
- 请求首部字段 / 响应首部字段
- 通用首部字段
- 实体首部字段
- 其他
- 空行
- 报文主体
a. Host
请求首部字段，客户端用来指定服务器的域名
b. Content-Length
实体首部字段：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。
c. Connection
通用首部字段，用来表示是否是长连接。HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。
d. Content-Type
实体首部字段：用于服务器回应时，告诉客户端，本次数据是什么格式。
Content-Type: text/html; charset=utf-8
上面的类型表明，发送的是网页，而且编码是UTF-8
客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Accept: */*
e. Content-Encoding
实体首部字段，字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
3. HTTP常见状态码
1XX：属于提示信息，是协议处理中的一种中间状态，用到比较少
-
2XX：表示服务器成功处理了客户端的请求
- 200-OK：一切正常，如果是非HEAD请求，会有报文主体(Body)
- 204-No Content：常见的成功状态码，与200基本相同，但是报文没有报文主体数据
-
3XX：表示重定向，需要用户重新发送请求获取资源
301-Moved Permanently：永久重定向，表示请求的资源已经不存在了，需要用新的URL再次访问
-
302-Moved Temporarily：暂时重定向，表示请求的资源还在，但暂时需要用另一个URL来访问
301 和 302 都会在响应头里使用字段
Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。 -
304-Not Modified：不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称为缓存重定向，用于缓存控制
304状态码或许不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。
客户端在请求一个文件的时候，发现自己缓存的文件有 Last Modified ，那么在请求中会包含 If Modified Since ，这个时间就是缓存文件的 Last Modified 。因此，如果请求中包含 If Modified Since，就说明已经有缓存在客户端。服务端只要判断这个时间和当前请求的文件的修改时间就可以确定是返回 304 还是 200 。
对于静态文件，例如：CSS、图片，服务器会自动完成 Last Modified 和 If Modified Since 的比较，完成缓存或者更新。但是对于动态页面，就是动态产生的页面，往往没有包含 Last Modified 信息，这样浏览器、网关等都不会做缓存，也就是在每次请求的时候都完成一个 200 的请求。
因此，对于动态页面做缓存加速，首先要在 Response 的 HTTP Header 中增加 Last Modified 定义，其次根据 Request 中的 If Modified Since 和被请求内容的更新时间来返回 200 或者 304 。虽然在返回 304 的时候已经做了一次数据库查询，但是可以避免接下来更多的数据库查询，并且没有返回页面内容而只是一个 HTTP Header，从而大大的降低带宽的消耗，对于用户的感觉也是提高。
如果用户按下了CTRL-F5 (有时称之为“强刷-hard refresh”),你会发现浏览器省略了If-Modified-Since和If-None-Match请求头,也就是无条件的请求页面中的每个资源.
-
4XX：表示客户端发送的报文有误，服务器无法处理
- 400-Bad Request：笼统错误
- 403-Forbidden：服务器禁止访问资源
- 404-Not Found：服务器上找不到此资源
-
5XX：表示服务器内部处理发生错误
- 500-Internal Server Error：与400类似，是一个笼统的错误，在不知道哪错了的时候使用
- 502-Bad Gateway：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
- 503-Serviece Unavaliable：服务器正忙，无法响应。
4. 常见的HTTP请求方法
用于告知服务器此条HTTP的意图
- get / post
- put / delete
- head
- options
Get：获取资源
GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器 端解析后返回响应内容。
Post：传输实体主体
POST 方法用来传输实体的主体。 虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容
Put：传输文件
PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。
但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。
Delete：删除文件
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。
和Put一样，因为不安全，所以一般不用
Head：获取报文首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
Post和Get的区别？
- 后退和刷新时：get无害，post数据会被重新提交
- GET请求在URL中传送的参数是有长度限制的，而POST么有。
- GET参数通过URL传递，POST放在Request body中。
二、HTTP的特性
- HTTP的特点 - （HTTP1.1）的优点有哪些？缺点有哪写？Cookie是什么？Session是什么？
- HTTP1.1的性能 - HTTP1.1的性能特点，可能会和HTTP1.0，2.0，3.0对比。
HTTP优点：
- 简单：header + body，头部信息也是key-value形式
- 灵活和易于扩展：
- 请求方法，URL，状态码，头部字段，都可以由开发人员自主选择。
- HTTP位于应用层，也就是第七层，他下面的层可以随时变化扩展。
- 应用广泛和跨平台
HTTP缺点：
- 无状态-双刃剑
- 好处：服务器不需要去记录HTTP状态，减轻服务器的负担
- 坏处：在完成有关联性的操作时会非常麻烦。其中一种解决方法是通过Cookie
- 明文传输-双刃剑
- 好处：调试遍历，方便阅读
- 坏处：信息裸奔不安全
- 不安全：(用HTTPS的方式解决)
- 使用明文传输，报文可以被截获监听
- 不验证通信方身份，报文可以被伪装重放
- 无法证明报文完整性，报文可以被篡改
HTTP1.1性能：
- 长连接
- 管道网络传输
- 队头阻塞
三、HTTPS
- HTTP和HTTPS的区别
- 80端口，443端口
- HTTP在TCP三次握手就行了，HTTPS在TCP三次握手基础上还要四个阶段的SSL / TLS的握手
- HTTPS需要向CA申请数字证书，来保证服务器的身份是可信的
- HTTPS主要解决了哪写问题？如何解决的上面出现的问题？
- HTTPS如何建立连接的？其间交互了什么？
HTTPS解决了什么问题？
因为HTTP是明文传输，所以有：
- 窃听风险
- 篡改风险
- 冒充身份风险
对此，HTTPS对于的解决办法分别是：
- 信息加密：混合加密
- 校验机制：摘要算法
- 身份证书：将公钥放入数字证书中
1. 混合加密
HTTPS采用的是对称加密和非对称加密结合的混合加密方式：
- 在通信建立前，采用非对称加密的方式交换
会话密钥，后续就不再使用非对称加密 - 在通信过中全部使用对称加密的
会话密钥的方式加密明文数据
采用混合加密的原因：
- 对称加密只是用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换
- 非对称密钥使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了交换密钥交换问题，但数度慢
2. 摘要算法
3. 数字证书
非对称加密原始方式：客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
那怎么保证公钥不被篡改和保证公钥的信任程度（客户端识别服务端身份）？
- 服务器把自己的公钥注册到CA
- CA用自己的私钥加密(数字签名)，形成数字证书，返回给服务器
- 客户端在建立连接的时候，拿到数字证书，用CA的公钥(事先置入到浏览器或者操作系统了)去查看数字证书的正确性，解得开说明此数字证书是正确的，获得服务器的公钥，用此公钥对报文加密后发送。
HTTPS建立连接的流程
SSL/TLS协议基本流程：
TCP三次握手
客户端向服务器索要并验证服务器的公钥。
双方协商生产
会话密钥双方采用
会话密钥进行加密通信
1-2步也就是SSL/TLS的建立构成，也就是握手阶段
详细流程：
- ClientHello
- ServerHello
- 客户端回应
- 服务器最后回应
1. ClientHello
- SSL / TLS 协议版本，如TLS 1.2版本
- 客户端产生的随机数1
- 客户端支持的密码套件列表，如RSA加密算法
2. ServerHello
- 确认 SSL / TLS协议版本，如果浏览器不支持，则关闭加密通信
- 服务端产生的随机数2
- 确认密码套件，如RSA加密算法
- 服务器的数字证书
数字证书是用CA私钥加密的服务端的公钥，客户端可以用CA公钥解密，拿到正确的服务端的公钥。
确认了密码套件之后，客户端和服务端就会根据三个随机数，然后用此密码套件生成一个会话密钥。
3. 客户端回应
- 一个随机数3（用公钥加密的）
- 通知服务端接下来可以用
会话密钥加密了 - 所有握手数据的一个摘要：供服务端校验
三个随机数 + 一个密码套件 ==》会话密钥
4. 服务端回应
- 通知客户端之后改用
会话密钥加密 - 所有握手数据的一个摘要：供客户端校验
之后就是用会话密钥加密的通信过程了。
四、HTTP的版本演变(区别)
- HTTP1.1比HTTP1.0的提升之处？有什么缺陷？
- HTTP2.0做了什么优化？有什么缺陷?
- HTTP3.0做了什么优化？
HTTP/1.1的改进和不足
优点：
- 使用TCP长连接方式，改善HTTP短链接造成的性能开销
- 支持 管道网络传输，只要第一个请求发出去了，不用等返回结果，就可以发送第二个请求，减少整体的响应时间
缺点：
- 请求 / 响应头(Header)未经压缩就发送，首部信息越多延迟越大。只能压缩Body部分
- 队头阻塞问题，如果服务器响应慢，会招致客户端一直请求不到数据。
- 没有优先级控制
- 只能从客户端开始，服务器只能被动响应。
HTTP/2的改进和不足
HTTP/2 协议是基于 HTTPS (TLS)的，所以 HTTP/2 的安全性也是有保障的。
除此之外，在性能上，HTTP/2的改进有：
头部压缩：如果同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的分。
二进制格式：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。 头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。 计算机在收到报文后，无需再将明文转为二进制，直接解析了。
-
数据流：每个请求或回应的所有数据包，称为一个数据流（
Stream）。因为多路复用，所以数据不是按序的，所以需要编号。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级
多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。解决了【队头阻塞】问题，降低了延迟，大幅提高了连接的利用率
服务器推送：HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
HTTP/2的不足之处：
多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP/3的改进和不足
HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
改进：UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。
不足：QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。
