视频内容业务对延迟比较敏感，在海外运营场景下，这种延迟敏感性更为突出。是妙开。除了CDN和边缘节点的部署，海外后端团队还针对HTTPS请求做了一系列的优化。下面我将之前工作中的一些技术探索和优化总结一下，分享给大家。01背景为什么要花这么多精力在移动端？由于移动端的设备特性和网络环境因素，新链路和链路复用的问题被放大。HTTPS请求需要多长时间？对于一个全新的HTTPS链接，从发起请求到返回数据需要多少个RTT？假设没有缓存，一个HTTPS请求需要10个RTT才能返回内容。如果一个RTT是50ms，这个全新的请求至少要花费50*10=500ms。这还没有计算后台业务处理的时间。HTTPS请求延迟确实比较高。通常，业务HTTP的延迟容忍度较差。ServerToClient模式下，效率越高越好。现实中会有各种缓存来减少不必要的消耗，所以上述极端10RTT的情况很少发生。如果DNS有本地缓存??或者使用HTTPDNS预解析，第一步可以省略。如果浏览器声明了HSTS，则302重定向可以省略，第3步可以省略。如果本地已有主流的CDNS缓存，则第6步可以省略。如果CA有本地验证缓存或者启用了OCSPStapling的本地验证，则可以省略步骤7和8。在各种缓存的情况下，一个普通的HTTPS请求会保留如下4个RTT进程。除了HTTPS的内容请求，握手阶段或者TLS层是否可以进一步优化，让我们的APP或者视频播放速度更快？答：绝对可以！对于HTTP协议，我们可以从这几个方面着手：提高加解密效率，减少内容传输量，链路复用...02HTTPS流程分析及优化策略使用WireShark抓包，根据TCP数据包，我们绘制流程图下面一步步分析流程，确定中间可以优化的点。（TLS1.2协议ECDHE算法）整个过程有以下几个阶段：TLSHello确定协议版本、密码套件、对称密钥随机数ServerCertificateServer发送证书链Client/ServerKeyExchange（DH算法、协商交换加密算法）ChangeCipherSpec对称加密双向验证TLSHelloPhase的分析和应用首先看一下Clienthellostructhello{Version//TLS版本号Random//客户端随机数SessionidCipherSuites//客户端支持的加密SuiteExtension的几个主要参数：支持版本；//扩展的TLS版本支持}上面抓包版本为TLS1.2，扩展名为TLS1.3。如果服务器支持1.3，则改为1.3协议。服务器首先要进行相应的支持配置，如下。ssl_protocolsTLSv1.2TLSv1.3CipherSuites是一个数组，里面会包含一堆新老加密算法支持，优先级从上到下。ServerHello返回CipherSuite，并根据Client的请求匹配合适的密码套件。以下服务器返回支持的包。密码套件：TLS_RSA_WITH_AES_256_GCM_SHA256是什么意思？握手期间的对称加密参数交换使用RSA。通信加密采用256位长度的对称AES算法，GCM和SHA256是AES的分组模式和摘要算法。现阶段优化的几个思路：密钥交换算法改进：RSA可以改为DH算法（Diffie-Hellman），如ECDHE。相同复杂度下，计算效率更高，证书体积更小。优化ECDHE算法的实现，优先考虑最高效的椭圆曲线实现x25519。使用ssl_ecdh_curve在Nginx后端配置椭圆曲线优先级。ssl_ecdh_curveX25519:secp384r1;同时，ECDHE支持FalseStart。启用FalseStart后，Client发送ChangeCipherSpec后即可发送加密的应用数据，减少1个RTT的等待时间。服务器配置密码套件的优先级。将性能最高的算法放在首位。ssl_prefer_server_ciphers开启；ssl_ciphersEECDH+ECDSA+AES128+SHA:RSA+AES128+SHA...虽然AES的效率很高，但在一些安全性较低的业务中，AES密钥的长度可以小一些，256位到128位。在ServerCertificate阶段，Certificate阶段会将自己的公钥和证书CA的中间公钥发送给客户端。在本地验证证书有效后继续客户端密钥交换过程。现阶段优化的方向有两个：证书传输+证书验证。证书传输证书越小越好。在证书生成阶段选择ECDSA而不是RSA证书。在安全性不变的情况下，密钥长度越小，计算量越小。例如，使用类似下面的方式生成一个ECDSA证书opensslecparam-genkey-nameprime256v1-outkey.pemcertificateverification客户端在验证证书时，会通过证书链逐级验证，在为了知道证书是否被CA吊销，客户端会访问CA下载OCSP数据并验证证书是否有效。OCSP需要查询CA，所以也会产生网络请求。如果CA服务器的延迟过大，会导致客户端延迟验证证书。OCSPStapling为了解决证书有效性校验的问题，出现了OCSPStapling。服务器定期向CA查询证书的状态，获取带有时间戳和签名的响应并将其缓存。当客户端请求证书时，服务器会在TLS握手阶段将结果发送给客户端。因为结果是经过CA私钥签名的，所有的结果都是可信的，客户端可以在本地判断证书的有效性。EnableOCSPStaplinginNginxssl_staplingon;ssl_stapling_verifyon;ssl_trusted_certificatexx.pem使用以下命令测试服务器是否有ocspstapingopenssls_client-connectip:443-statusOCSPresponse:noresponsesent//如果出现以下，则没有配置keyexchange和验证阶段Client/ServerKeyExchange阶段主要是在这个阶段交换DH加密公钥，比如选择椭圆曲线，生成椭圆曲线公钥，公钥签名，与客户端的ClientKeyExchange呼应，最后获取对方的公钥，用于加密AES的密钥。加解密双方验证ChangeCipherSpec/EncryptedHandshakeMessage处于KeyChange阶段，加密参数已经生成。双方都有交换密钥的公钥和对称密钥的参数。可以进行数据传输。如果双方验证加解密都OK，则握手正式完成。这样加密后的HTTP请求和响应就可以正常收发了。以上两个阶段是否可以优化？是的，我们可以通过链接重用跳过这个阶段。优化链接重用的方式有两种：SessionID和SessionTicket，两者各有千秋，但目标一致。（一个服务器实现，一个客户端实现）SessionID客户端和服务器第一次TLS握手连接后，双方会在内存中缓存会话密钥，并用唯一的SessionID来标识。在下一次连接时，服务器可以知道之前是否已经建立了传入连接。如果会话密钥也存在于服务器中，则可以重复使用。在服务器端开启SessionIDssl_session_cacheshared:SSL:50m;ssl_session_timeout1d;SessionTicket为了解决SessionID的问题，SessionTicket出现了。服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给客户端，类似于HTTPcookies。当客户端第一次与服务器建立连接时，服务器会将“会话密钥”加密后作为Ticket发送给客户端，由客户端缓存。当客户端再次连接到服务器时，客户端会发送一个Ticket，服务器解密后就可以得到上次的会话密钥，然后验证有效期。如果没有问题，会话可以恢复。打开会话票sl_session_ticketson；服务器端的ssl_session_ticket_keyxx.key；使用链接重用技术，当HTTPS再次重连时，恢复会话只需要1个RTT。对于使用Pre-sharedKeyreuse技术的TLS1.3，可以实现0RTT恢复链路。当然，使用链接重用不可避免地会产生重放攻击的风险。对于安全性要求非常高的业务，谨慎使用链接复用。当然，如果衡量复用过期时间，同时在业务端做好安全防范，得到的收益也不会小。03总结从HTTP/1.0到HTTP/2，HTTP协议的基础一直是与TCP的可靠连接。TCPhead-to-headblocking、handshakeprocess等机制问题，无论怎么优化，都会导致HTTP延迟很高。此外，TCP协议作为Internet上使用最广泛的协议之一，涉及的中间设备和操作系统数不胜数。该协议的刚性使得它很难实现许多由IETF标准化的新TCP特性。所以下一阶段的HTTP/3彻底抛弃了TCP七年。自从QUIC被提交给IETF进行标准化后，QUIC协议的HTTP/3终于在今年正式发布。基于QUIC，更容易实现0-RTT和1-RTT连接的建立。爱奇艺出海也在早期尝试使用QUIC来提升用户服务。后续技术团队也会分享我们基于数据使用QUIC的实践。终于，排除万难，HTTP/3时代已经到来，让我们拭目以待。
