http1.0http是无状态连接，即它只关心连接，不管你之前有没有连接过，所以它通常通过设置cookie来记录用户的登录状态，服务器产生一个session来记录用户的登录上下文，并生成一个sessionId来唯一标识这条记录，然后放到responseheader中，后续浏览器发起请求再带上requestheader来区分自己的用户状态；http是基于TCP连接的，从连接建立到断开需要三次握手四次挥手，并且一个http链接只创建一个新的tcp链接，请求和响应都是以文本形式传输，每次都断开链接传输数据；同时，如果出现丢包，需要重新建立tcp链接，导致在http1.0下传输效率其实不高。每个资源的请求和响应都必须在队列中排队，等待传输。http1.1为了解决以上问题，http1.1http1.1默认使用长链接，降低了建立tcp链接的成本同时http1.1支持pipeline，可以在一个上发起多个请求tcp连接，但是这个特性有一个限制，就是虽然可以发起多个请求，但是请求本身是按顺序发起的，同时require从服务器返回的也需要按照这个顺序返回，否则无法识别response对应的是哪个request，也就是说http1.1的pipeline其实是节省了发起request的时间，允许同时发起request而不用等下一个request回来才发起第二个但是，由于这种机制限制较多，实施起来比较麻烦。大多数现代浏览器通过建立多个tcp链接来实现并发。同时由于浏览器本身的限制，孙子兵法中允许的tcp链接数为6。为了真正解决并发问题，http2.0提出了http2.0http2.0使用了一种技术称为多路复用，也就是将消息以二进制形式进行编码，同时分成多个帧，称为二进制帧，同一请求的二进制帧具有相同的标识符，以便接收方将其拼凑成一个完整的消息。同时http2.0的所有请求都建立在一个tcp连接上。通过binaryframe的技术，不需要像http1.1.即要求响应顺序与请求顺序一致。服务器会响应最先收到的请求，浏览器通过识别可以得到完整的消息。此外，http2.0还采用了头部压缩技术。各自维护和浏览器一样的请求头字典，后面的请求头直接替换为字典的键值，减少传输量，http2.0允许消息从服务器推送到浏览器，通过预测浏览器的请求，服务器可以提前将需要的资源推送给浏览器，减少资源传输但是http2.0还有一个问题没有解决，就是丢包时的性能问题。由于tcp协议本身的限制，数据传输采用响应机制。数据包发出后，需要得到接收方的回复。如果没有收到回复，则认为当前发送的数据包丢失，需要重发。同时，tcp使用“滑动窗口”机制来提高传输效率，即不等待发送尽可能多的数据包，但是这个数量不需要等待发送是有上限的，换句话说他是分批发送的。批量确认响应用于数据传输。发送方将根据收到的最大连续数据包序列移动窗口。如果一个数据包丢失并且没有返回响应，则窗口将停止移动并重新发送数据包。并且http2.0的所有请求都是基于一个tcp请求，也就是说某个请求丢包会阻塞其他请求的发送QUIC(http3.0)QUIC-quickudpinternetconnection,由GoogleA提出协议，他放弃了使用tcp转而使用udp协议。与tcp不同，udp不需要等待响应。建立连接后，只需发送数据即可。一般用在实时通话或者视频等，QUIC在时效性要求高的场景下解决。http2.0的阻塞问题的基本思想是不需要批量等待响应。收到某个数据包的响应后，窗口会后移，下一个数据包tcp的数据传输是根据sequence_no和ack来保证可靠性的，其中sequence_no为字节在数据包中的序号，ack为sequence_no加一。丢包的时候，必须等包重发，收到ack响应，才能继续往下走。否则，如果跳过丢失的数据包继续往前走，就无法知道丢失了哪些数据包。结合之前的滑动窗口，receiver会根据自己收到的包发回acks。如果接收方收到的sequence_no是连续的，那么发送方只需要确认最后一个ack就够了，就可以根据这个ack移动窗口了。但是如果发现数据包中的sequence_no不连续，receiver会返回最新的ack。当发送端收到3次相同的ack，就知道数据丢失了。包，需要重发数据，而由于发送方不知道除了ack表示的丢包之外是否还有其他丢包，所以很可能需要重发从丢包开始的所有数据，即使ifReceiver可能已经收到了这些包，所以tcp丢包不仅造成拥塞还浪费带宽QUIC，它使用packet_no来保证可靠性，标识符从0开始，每发送一个包就加1，即使丢包，重发时也是根据当前在添加packet_no的同时，QUIC利用复用时的strem_id和QUIC新添加的stream_offset来判断当前数据包的正确顺序。offset是当前数据包在整个数据流中的偏移量，这样即使packet_no不一致，也可以通过stream_id和stream_offset来识别数据包的顺序，重新组装。也就是说，QUIC支持数据的乱序传输。与tcp不同的是，中间ack的丢失对数据传输影响不大，因为它只需要确认最后一个ack，但是QUIC要求每个数据包都有明确的ack返回，如果没有返回，则认为是一个数据包丢失。QUIC通过这种方式提供数据传输效率。QUIC还提供了纠错机制。通过增加一个冗余包发送，当只有一个包丢失时，可以根据之前收到的包和冗余包来恢复丢失的包。其原理是对所有数据包进行异或运算，得到一个冗余包，即假设有5个包，异或产生一个冗余包，一共6个，根据异或原理，相同的数异或为00和任意一个数异或等于那个数本身假设现在3号包丢失了，只需要将1、2、4、5和冗余相加，其余的包一起进行异或运算，就可以得到00号包。3包。虽然这种纠错机制只能在只有一个包丢失的基础上生效，但是根据网络环境，选择合适的包总数进行异或处理，可以基本防止丢包重传的情况。最后，QUIC采用类似TFO（TCPfastopen）的思路，通过cookie缓存识别客户端身份，实现第一次连接占用1-RTT（Round-TripTime），后续连接占用0-RTT开销https：简述关于对称加密和非对称加密。对称加密使用token对数据进行加密编码，服务端收到加密数据后，使用相同的token对加密数据进行解密。但是，这种形式很容易被破解。非对称加密采用公钥加密，只能用私钥解锁，所以服务端生成公钥再传给客户端。客户端用公钥加密后回传给服务器，服务器用私钥解密，可以防止信息被窃取。但是非对称加密计算量大，性能消耗大。通常，使用对称加密和非对称加密的组合。客户端向服务器发起请求，服务器生成公钥传递给客户端。客户端生成一个随机数并使用公钥。进行非对称加密，然后将加密后的信息返回给服务器。服务器使用私钥解码得到客户端生成的随机数。在后续的数据传输中，客户端使用自己产生的随机数对信息进行对称加密，这样既保证了对称加密token不暴露，又保证了传输效率
