1：HTTP基本概念 超文本 传输 协议

2：常见状态码 1xx 提示信息 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误

3：HTTP常见的字段 host 指定服务器的域名 Content-Length 回应的数据长度 Connection 长连接（Keep-Alive）
Content-Type 响应数据格式（text/html; Charset=utf-8） Content-Encoding 数据压缩格式（gzip）

4：get和post的区别 get安全、幂等、可被缓存 post不安全（请求的参数只允许 ASCII 字符），不幂等，（大部分实现）不可缓存
 RFC规范 POST的语义是根据请求负荷（报文body）对指定的资源做出处理 
 GET请求可以带body吗？ 任何请求都可以带 body的 只是因为RFC规范定义的GET请求是获取资源，所以根据这个语义不需要用到body

5：HTTP缓存技术
强制缓存：强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
响应头部相关参数：200 状态码，但在 size 项中标识的是from disk cache，Cache-Control和Expires表示资源在客户端缓存的有效期
协商缓存：就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。
响应头部相关参数：304状态码 If-Modified-Since和Last-Modified（资源最后修改时间），If-None-Match和ETag（唯一标识响应资源）

6：HTTP/1.1特性
优点：简单（HTTP 基本的报文格式就是 header + body，头部信息也是 key-value） 
    灵活和易于扩展（各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，允许开发人员自定义和扩充） 
    应用广泛和跨平台（从台式机的浏览器到手机上的各种 APP）
缺点：
无状态双刃剑（好：服务器不用记忆HTTP的状态，减轻服务器的负担。坏：没有记忆能力，完成有关联性的操作时会非常麻烦），解决：cookie
明文传输双刃剑（好：方便阅读。坏：被抓包，信息裸奔）
不安全（通信使用明文，不验证通信方的身份，无法证明报文的完整性），解决：HTTPS
性能：
长连接（一次TCP连接，多次请求响应）
管道网络传输（连续发送请求，不必等其响应。服务器必须按照接收请求的顺序发送对这些管道化请求的响应。HTTP/1.1管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞）
队头阻塞（当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据）这也是后续的HTTP/2和HTTP/3在优化HTTP的性能的方向

7：HTTP和HTTPS的区别 HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输
HTTP 默认端口号是 80，HTTPS 默认端口号是 443
HTTPS 是如何解决上面的三个风险的？（窃听风险、篡改风险、冒充风险）
混合加密（对称加密和非对称加密结合，密钥）、摘要算法+数字签名（哈希算法+非对称双向加解密）、数字证书（身份验证，CA 数字证书认证机构）

8：HTTPS是如何建立连接的？其间交互了什么？HTTPS 的应用数据是如何保证完整性的？（略）https://xiaolincoding.com/network/2_http/http_interview.html#https-%E6%98%AF%E5%A6%82%E4%BD%95%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5%E7%9A%84-%E5%85%B6%E9%97%B4%E4%BA%A4%E4%BA%92%E4%BA%86%E4%BB%80%E4%B9%88

9：HTTPS 一定安全可靠吗？
HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全
如何避免被中间人抓取数据？通过 HTTPS 双向认证

10：HTTP/1.1、HTTP/2、HTTP/3 演变
HTTP/1.1
改进：长连接的方式改善了短连接造成的性能开销、支持管道网络传输 减少整体的响应时间
瓶颈：请求头部未经压缩就发、发送冗长的首部、队头阻塞、没有请求优先级控制、请求只能从客户端开始 服务器只能被动响应
HTTP/2
改进：头部压缩、二进制格式、并发传输、服务器主动推送资源
缺点：HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层
HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。
HTTP/3
改进：HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
QUIC有以下3个特点 
：无队头阻塞（当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题）
：更快的连接建立（QUIC 内部包含了 TLS， QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商）
：连接迁移（基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接，QUIC 协议通过连接 ID 来标记通信的两个端点，P 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能）

问答环节

问：“https 和 http 相比，就是传输的内容多了对称加密，可以这么理解吗？”

答：建立连接时候：https 比 http多了 TLS 的握手过程；
传输内容的时候：https 会把数据进行加密，通常是对称加密数据；

问：“ 我看文中 TLS 和 SSL 没有做区分，这两个需要区分吗？”

答：这两实际上是一个东西。
SSL 是洋文 “Secure Sockets Layer” 的缩写，中文叫做「安全套接层」。它是在上世纪 90 年代中期，由网景公司设计的。
到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是 “Transport Layer Security” 的缩写），中文叫做 「传输层安全协议」。
很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

问：“为啥 SSL 的握手是 4 次？”

答：SSL/TLS 1.2 需要 4 握手，需要 2 个 RTT 的时延，就是 4 次握手：另外， SSL/TLS 1.3 优化了过程，只需要 1 个 RTT 往返时延，也就是只需要 3 次握手：