http相关
这两篇文章结合看：https://mp.weixin.qq.com/s/2Mtg_UGF7yb3JF4qqVK8yA
根据 小林coding的文章总结：https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A
1、什么是http？
答：http就是超文本传输协议
2、http常见的状态码有哪些？
答：206是断点续传、503是服务不可用
3、http常见的字段有哪些
答：
Host：指定服务器域名
Content-Length：服务器在返回数据时，表明本次回应的数据长度
Content-Type：返回的数据的格式（如：text/html; charset=utf-8）
Content-Encoding：说明服务端返回的数据的压缩方法（如：gzip）
Accept-Encoding：说明客户端能接受的数据压缩方法
Connection：客户端要求服务器使用 TCP 持久连接，以便其他请求复用。
4、说一下 GET 和 POST 的区别？
答：
- Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
- POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里。
- GET 方法就是安全且幂等的；POST方法不安全，不幂等。
4、你知道的 HTTP（1.1） 的优点有哪些，怎么体现的？
答：
简单
HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。灵活和易于扩展
HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。应用广泛和跨平台
互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用片地开花，同时天然具有跨平台的优越性。
5、http有什么缺点呢？
答：
- 无状态双刃剑
解决方法：用Cookie - 明文传输
通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看 - 不安全
HTTP 比较严重的缺点就是不安全：
通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。
解决办法：可以用 HTTPS 解决，也就是通过引入 SSL/TLS 层
6、HTTP/1.1 的性能如何？
答：
- 长连接
HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无畏的 TCP 连接建立和断开，增加了通信开销。
HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。 - 管道网络传输
HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。 - 队头阻塞
「请求 - 应答」的模式加剧了 HTTP 的性能问题。
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。好比上班的路上塞车。
总之 HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能
7、HTTP 与 HTTPS 有哪些区别？
答：4个区别：
- HTTP 是超文本传输协议，信息是
明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。 - HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，
还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。 - HTTP 的端口号是
80，HTTPS 的端口号是443。 - HTTPS 协议需要向
CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
8、HTTPS 是如何解决http的风险的？
- HTTPS 采用的是对称加密和非对称加密结合的
「混合加密」方式，解决了明文的风险。 -
摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险 - 通过
数字证书的方式保证服务器公钥的身份，解决冒充的风险
9、SSL/TLS 的「握手阶段」涉及四次通信
- ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。（包含：客户端支持的ssl/tls版本、支持的密码套件、随机数） - SeverHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。（包含：确认ssl/tls版本、确认密码套件、随机数、数字证书）
3.客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。（包含：随机数、内容摘要） - 服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。（包含：会话密钥、内容摘要）
10、HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 头部压缩
如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。 - 二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。增加数据传输的效率。 - 数据流
HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。 - 多路复用
HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。解决了“队头阻塞” - 服务器推送
HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
缺点：
HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。
11、粘包和拆包
由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。
粘包：两个包较小，间隔时间短，发生粘包，合并成一个包发送；
拆包：一个包过大，超过缓存区大小，拆分成两个或多个包发送；
对于粘包和拆包问题，常见的解决方案有四种：
- 发送端将每个包都封装成固定的长度，比如100字节大小。如果不足100字节可通过补0或空等进行填充到指定长度；
- 发送端在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并；例如，FTP协议；
- 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息；
- 通过自定义协议进行粘包和拆包的处理。
