面试题怎么答？

https：
我觉得可以从https解决的几个问题入手，一个是消息内容必须保密，这个是通过混合加密的形式，先通过非对称加密（RSA）实现密钥交换，然后通过对称加密（AES）来交换数据（可以详细讲步骤）。第二个是保证消息不能被篡改，是对消息内容做一个摘要（SHA）和数据一起发过去，然后对端重新做摘要比较。第三是身份认证，因为tls握手的第三阶段也就是客户端和服务端非对称加密的第一个步骤是服务端向客户端发公钥，需要验证服务端的合法性，所以服务端要给客户端发送一个证书把公钥内嵌在证书里面，然后判断证书的认证机构（CA）是否在浏览器和操作系统内嵌的RootCA里面，如果不是的话就一层层往上遍历证书链，直到找到RootCA才说明合法。第四是不可抵赖，这个是通过签名也就是私钥加密公钥解密的形式，一般消息内容比较长，是对消息的摘要做签名
tls握手流程：
分为四个阶段，前面两个阶段是客户端和服务器交换各自的协议版本号，加密套件（密钥交换算法 +签名算法 + 对称加密算法 + 摘要算法），随机数还有服务器的数字证书，客户端公钥；第三阶段就是客户端通过浏览器和操作系统的CA来验证服务端的合法性，验证成功后就将客户端产生的一个随机数（pre-master）发给客户端，然后双方通过pre-master+第一次握手客户端产生的随机数+第二次握手服务端产生的随机数算出会话密钥，后面就用会话密钥通信
验证证书的过程：
CA 签发证书的过程，如上图左边部分:
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，
得到一个 Hash 值;
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名; 最后将 Certificate Signature 添加在文件证书上，形成数字证书;
客户端校验服务端的数字证书的过程，如上图右边部分: 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1;
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ;
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
https优化：
升级协议（TLS1.3）和加密算法（ECDHE替换RSA）..
缓存：

双方缓存上次的会话密钥然后用session id互相关联（内存和集群问题）
session ticket服务端不缓存，验证ticket有效期

http1.1-http3的性能优化
http1.1通过设置Connection选项为keepalive支持长连接，默认是开始的，所以说不用像http1.0那样每次重新三次握手然后再请求应答，所以可以通过管道机制同时发出去多个请求，但是这样并没有解决队头阻塞的问题，他还是基于请求应答模式，应答的顺序必须严格按照请求的顺序来，所以说在http1.1下要减少队头阻塞带来的问题的话只能去减少请求数（比如缓存，合并请求，keepalive），然后多开长连接和域名分片来优化性能，而http2的话引入了多路复用的机制（多个stream复用一个tcp连接），请求的应答顺序可以不按照请求的顺序来，所以说我们必须给数据包分配一个stream编号来标识对应的请求，然后http2相对于http1.1也对带宽进行了优化， 比如说头部压缩和二进制传输，具体就是双方维护了一张索引信息表，对头部字段生成了索引号，这样每次就不用重复的发一些字段了，然后对头部和报文主体进行了二进制压缩（HPACK），而不是像http1.1那样使用文本的形式，然后服务端也可以主动向客户端发送数据，也一定量的减少了延迟。http2在tcp层面还是有队头阻塞的问题，必须等前面的字节都接收到了，他的能被应用程序处理的数据窗口才能滑动，所以http3使用的是基于udp的quic协议，多个数据流之间没有依赖，当某个流发生丢包才会使这个流阻塞，（类http2+tls+tcp）而且也不需要tcp的三次握手带来的时延，拥塞控制算法在应用层控制，可以根据网络环境自由切换（相对于tcp）还有wifi和4g网络无需重连，然后相对于tls来说他对头部也进行了加密，使用tls1.3协议将连接时间缩短到了1RTT（第二次使用缓存0RTT）
扩展：http1.1新增的host字段以及新增的PUT，DELETE，OPTIONS方法，tls1.3只要1个RTT

TCP字段：
源端口，目的端口号，序列号，应答号，控制位（ACK，RST，FIN，SYN，PSH，URG）窗口大小，紧急指针，校验和，选项字段（时间戳，SACK）
三次握手的作用：初始化双方初始序列号，以免旧报文对新连接产生影响
三次握手能否变为两次？为什么？
不能，因为要同步初始化序列号，客户端必须给服务端发来的syn+ack报文一个ack才能告诉服务端客户端已经接收到了，否则服务端会重传报文（如果没有告诉服务端我已经接受到了怎么办？那服务端就不知道客户端是否接收到了自己的握手报文，这时候如果有超时重传的syn报文服务端，服务端也会再次创建一个新连接，造成资源的浪费）
服务端发过来的syn和ack报文可能是旧的客户端syn报文导致的，这时候就可以根据客户端期望收到的ack和服务端发来的报文做比对判断是否是旧连接，如果是旧连接就返回一个RST报文
序列号的作用，去重，有序（对方可以根据序列号知道哪些收到），是可靠传输的关键
ISN问题：一般在一个随机数（四元组hash）的基础上绑定一个时钟（4毫秒加一）进行递增，防止新旧连接的ISN产生冲突，并且防止被猜出来