共计 1593 个字符，预计需要花费 4 分钟才能阅读完成。
面试官 ： 明天要不来聊聊 HTTP 吧？
候选者：嗯，HTTP「协定」是客户端和服务器「交互」的一种通迅的格局
候选者：所谓的「协定」实际上就是单方约定好的「格局」，让单方都能看得懂的货色而已
候选者：所谓的交互实际上就是「申请」和「响应」
面试官 ： 那你晓得 HTTP 各个版本之间的区别吗？
候选者：HTTP1.0 默认是短连贯，每次与服务器交互，都须要新开一个连贯
候选者：HTTP1.1 版本最次要的是「默认长久连贯」。只有客户端服务端没有断开 TCP 连贯，就始终放弃连贯，能够发送屡次 HTTP 申请。
候选者：其次就是「断点续传」（Chunked transfer-coding）。利用 HTTP 音讯头应用分块传输编码，将实体主体分块进行传输
候选者：HTTP/ 2 不再以文本的形式传输，采纳「二进制分帧层」，对头部进行了「压缩」，反对「流控」，最次要就是 HTTP/ 2 是反对「多路复用」的（通过繁多的 TCP 连贯「并行」发动多个的申请和响应音讯）
面试官 ：嗯，略微打断下。 我晓得 HTTP1.1 版本有个管线化 (pipelining) 实践，但默认是敞开的。管线化这个跟 HTTP/ 2 的「多路复用」是很相似的，它们有什么区别呀？
候选者：HTTP1.1 提出的「管线化」只能「串行」（一个响应必须齐全返回后，下一个申请才会开始传输）
候选者：HTTP/ 2 多路复用则是利用「分帧」数据流，把 HTTP 协定合成为「互不依赖」的帧（为每个帧「标序」发送，接管回来的时候按序重组），进而能够「乱序」发送防止「肯定水平上」的队首阻塞问题
候选者：然而，无论是 HTTP1.1 还是 HTTP/2，response 响应的「解决程序」总是须要跟 request 申请程序保持一致的。如果某个申请的 response 响应慢了，还是同样会有阻塞的问题。
候选者：这受限于 HTTP 底层的传输协定是 TCP，没方法齐全解决「线头阻塞」的问题
面试官：哦，好的。
候选者：HTTP/3 跟后面版本最大的区别就是：HTTP1.x 和 HTTP/ 2 底层都是 TCP，而 HTTP/ 3 底层是 UDP。应用 HTTP/ 3 可能缩小 RTT「往返时延」（TCP 三次握手，TLS 握手）
面试官 ： 你理解 HTTPS 的过程吗？
候选者：嗯啊，HTTPS 在我的了解下，就是「平安」的 HTTP 协定（客户端与服务端的传输链路中进行加密）
候选者：HTTPS 首先要解决的是：认证的问题
候选者：客户端是须要确切地晓得服务端是不是「实在」，所以在 HTTPS 中会有一个角色：CA（公信机构）
候选者：服务端在应用 HTTPS 前，须要去认证的 CA 机构申请一份「数字证书」。数字证书里蕴含有证书持有者、证书有效期、「服务器公钥」等信息
候选者：CA 机构也有本人的一份公私钥，在公布数字证书之前，会用本人的「私钥」对这份数字证书进行加密
候选者：等到客户端申请服务器的时候，服务端返回证书给客户端。客户端用 CA 的公钥对证书解密（因为 CA 是公信机构，会内置到浏览器或操作系统中，所以客户端会有公钥）。这个时候，客户端会判断这个「证书是否可信 / 有无被篡改」
候选者：私钥加密，公钥解密咱们叫做「数字签名」（这种形式能够查看有无被篡改）
候选者：到这里，就解决了「认证」的问题，至多客户端能保障是在跟「实在的服务器」进行通信。
候选者：解决了「认证」的问题之后，就要解决「窃密」问题，客户端与服务器的通信内容在传输中不会泄露给第三方
候选者：客户端从 CA 拿到数字证书后，就能拿到服务端的公钥
候选者：客户端生成一个 Key 作为「对称加密」的秘钥，用服务端的「公钥加密」传给服务端
候选者：服务端用本人的「私钥解密」客户端的数据，失去对称加密的秘钥
候选者：之后客户端与服务端就能够应用「对称加密的秘钥」欢快地发送和接管音讯
面试官：理解了
关注我的微信公众号【Java3y】来聊点不一样的！
【对线面试官 + 从零编写 Java 我的项目】继续高强度更新中！求 star
原创不易！！求三连！！
