小林coding学后对比系列-计网篇-HTTP

HTTP演进

	HTTP格式 --> 请求+响应
	HTTP1.0 ：	只能发一个请求。三次握手，请求+响应，四次挥手。
	HTTPS   ：	三次握手建立连接后，TLS四次握手得到会话秘钥，之后加密请求和相应内容。
	HTTP1.1 ：	长连接： 一次连接传多个请求，每个请求要等上一个请求的响应到达才能发送。
		      	管道传输： 通过管道一次发多个请求，但响应必须按顺序。如果一个坏了，后面的被阻塞。
	HTTP2.0：	头部压缩：双方维护一张动态表 HPACK； 传输的数据变为二进制；
				并发传输：多个stream流复用一个TCP连接，通过stream id。请求和响应中包含多个fream帧。
				服务器主动推送资源。
				TCP协议造成队头阻塞：如果前一个字节没到，后收的只能放在内核缓冲区。
	HTTP3.0 ：	基于UDP的QUIC 不存在队头阻塞。
				建立连接更快：TLS被合并在QUIC里了。
				连接迁移方便：连接ID取代四元组。
				特殊单向流同步双方动态表QPACK：确保动解码方收到更新。

详细

TLS

		RSA：
			客户端生成随机数C，服务器生成随机数S，交换这个随机数，客户端再生成一个随机数C2，
		通过服务器的公钥加密后发过去。他们双方都能通过秘钥加密算法算出同一个会话秘钥。
		DH：
			离散对数算。

RSA和DH、DHE、ECDHE

	RSA与DH，不具备向前安全。也就是说如果后面服务器公钥泄露，前面发的所有报文会被解密。因为整个流程用
	的是同一个秘钥 。
	DHE开始就具备向前安全了，E代表随机，每次通信都随机生成私钥，现在的泄露了之前的报文也不会被解密。
	ECDHE 用椭圆曲线提高计算私钥的速度。ECDHE比RSA省去一个RTT；
	ECDHE 四次TLS握手内容有区别： 
	第二次时候，双方同享，使用的椭圆曲线、椭圆曲线基点G，这些能算出X，X加上他们的随机数，服务器就能算
	出会话秘钥。所以第二次的时候，服务器就会发送 Server Key Exchange消息。
	RSA要在第三次的时候，要等客户端把生成的随机数用服务器公钥加密传给服务器。

HTTP优化 （这个目前记不住，要用的时候看下）

硬件：支持 AES-NI 特性的 CPU
软件：软件升级，协议优化（秘钥交换过程）
	选用 ECDHE 密钥交换，TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性，
	选择 x25519 曲线，选用 AES_128_GCM
	TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 
	TLS 握手。客户端在 Client Hello 消息里带上了支持的椭圆曲线，以及这些椭圆曲线对应的公钥。
证书优化： 
	传输优化：要短，择椭圆曲线（ECDSA）证书
	验证优化：OCSP Stapling 每隔一段时间主动找CA问
会话复用：
	Session ID：首次 TLS 握手连接后，双方在内存缓存会话密钥。
	Session Ticket：只客户端缓存。服务器解密客户端发来的ticket，如果有效就是用这个会话秘钥。
	Pre-shared Key ，只需要 0 RTT 就可以恢复会话。TLS1.3中，客户端把Ticket和HTTP一块发。
session不具备向前安全，重放攻击：劫持了session id 或者 session ticket 与报文，冒充。