http基础(2)
密码学入门
密码学的处理对象是数字和字符串,散列是一种数据一旦转换为其他的形式将永远无法恢复的加密技术。加密又分为对称加密(AES、DES、3DES)和非对称加密(RSA)。
常见面算法,秘钥交换算法,Diffie-Hallman算法是一种著名的密钥协商算法,这种算法可以使得信息交换的双方通过公开的非安全的网络写上生成安全的共享秘钥,算法过程如下:
- Alice与Bob确定两个大素数n和g,这两个数不用保密
- Alice选择另一个大随机数x,并计算A如下:A=gx mod n
- Alice将A发给Bob
- Bob选择另一个大随机数y,并计算B如下:B=gy mod n
- Bob将B发送给Alice
- 计算秘密秘钥k1如下:k1= Bx mod n
- 计算秘密秘钥k2如下:k2=Ay mod n
- k1=k2因此ALice和Bob可以用其进行加解密


证书签发机构
通过CA发放的整数完成秘钥的交换,实际上是利用非对称的加密算法完成数据加密密钥的安全交换,然后再利用数据加密密钥完成数据的安全交换。数字整数是互联网通信中标识双方身份信息的数字文件,由CA签发。CA(certification authority)是数字整数的签发机构。作为权威机构,其审核申请者身份后签发数字证书,这样我们只需要校验数字整数即可确定对方的真实身份。

CA的工作流程:
- 服务器example.com将从CA请求TLS证书,例如Digicert
- Digicert将为example.com创建证书,证书将包含必要的数据,例如 服务器名称,服务器的公钥等。
- Digicert将创建的数据(证书)的哈希值,并使用自己的私钥进行加密
- 浏览器和操作系统自带Digicert等权威机构的公钥
- 当浏览器收到签名证书时,它将使用公钥从签名生成哈希值,它还将使用证书中指定的散列算法生成数据(证书)的散列,如果两个哈希值匹配,则签名验证成功并且证书是可信的。
- 现在浏览器可以使用证书中指定的example.com的公钥继续进行身份验证过程
- 这里,可以将Digicert称为Root CA
浏览器验证服务器证书的有效性
证书颁发机构是为服务器创建并签署证书,很少有组织从事这项工作,即Digicert、Geotrust、Comodo。如果他们正在为所有的服务器签署证书,则必须为所有签名使用相同的私钥,如果它被盗,那么所有的信任都会丢失,为了解决这个问题并增加更多的平均信息量,引入了中间CA(Intermediate CA)的概念。
服务器使用中级证书颁发机构的签名,因此在浏览器通信时,服务器将共享两个证书:
- 包含服务器的公钥,即实际的服务器证书
- 由Root CA办法的intermediate CA证书。

在签名验证期间,浏览器首先使用已经存储在浏览器中的Root CA的公钥来验证中间证书的数字签名,如果成功浏览器现在可以信任中间证书及其公钥,现在使用此公钥,浏览器将验证原始服务器证书的签名,该组织可以注册为intermediate CA,以便为其域签署证书。
SSL/TLS协议
传输层安全性协议(Transport Layer Security-TLS),及其前身安全嵌套层(Secure Sockets Layer - SSL)是一种安全协议,目的是Wie互联网通信提供安全及数据完整性保障。HTTPS协议的安全性由SSL协议实现,当前使用的TLS协议1.2版本包含了四个核心子协议:握手协议、秘钥配置切换协议、应用数据协议及报警协议。
- TLS适用于对称秘钥
- 对称秘钥可以通过安全秘钥交换算法共享
- 如果请求被截获,密钥交换可能被欺骗
- 使用数字签名进行身份验证
- 证书颁发机构和信任链

HTTPS协议、SSL协议、TLS协议、握手协议关系如下:
- HTTPS是Hypertext Transfer Protocol Secure Socket Layer的缩写,即HTTP over SSL, 可理解为基于SSL的HTTP协议。HTTPS协议安全是由SSL协议实现的。
- SSL协议是一种记录协议,扩展性良好,可以方便的添加子协议
- 握手协议是SSL协议的一个子协议
- TLS协议是SSL协议的后续版本(文章中涉及到的SSL协议默认是TLS协议1.2版本)
HTTPS协议分析
TLS握手的步骤:
- ClientHello:客户端发送所支持的SSL/TLS最高协议版本号和所支持的加密算法集合及压缩方法集合等信息给服务器端。
- ServerHeel:服务器端收到客户端信息后,选定双方都能够支持的SSL/TLS协议版本号和加密方法及压缩方法返回给客户端。
- SendCertificate(可选):服务器端发送服务端证书给客户端
- RequestCertificate(可选):如果选择双向验证,服务器端向客户端请求客户端证书
- ServerHelloDone:服务器端通知客户端初始写上结束
- ResponseCertificate(可选):如果选择双向验证,客户端向服务器端发送客户端证书
- ClientKeyExchange:客户端使用服务器端的公钥,对客户端公钥和秘钥种子进行加密,再发送给服务器端。
- CertificateVerify(可选)如果选择双向验证,客户端用本地私钥生成数字签名,并发送给服务器端,让其通过收到的客户端公钥进行身份验证。
- CreateSecretKey:通讯双方基于秘钥种子等信息生成通讯秘钥
- ChangeCipherSpec:客户端通知服务器端已将通讯方式切换到加密方式
- Finished:客户端做好加密通讯的准备
- ChangeCipherSpec:服务器端通知客户端已将通讯方式切换到加密模式
- Finished:服务器端做好加密通讯的准备
- Encrypted/DecryptedData:双方使用客户端秘钥,通过对称加密算法对通讯的内容进行加密
- ClosedConnection:通讯结束后,任何一方发出断开SSL连接的消息
HTTP2协议分析
HTTP/2没有改动HTTP的应用语义。HTTP方法、状态码、URI和标头字段等核心概念。HTTP/2修改了数据格式化(分帧)以及在客户端与服务器间传输的方式。这两天统帅全局通过分帧层向我们的应用隐藏了所有的复杂性。由于HTTP/2引入了新的二进制分帧层,该层无法与之前的HTTP/1.x服务器和客户端向后兼容,因此协议的主版本提升到HTTP/2。
HTTP/2的特点:
- 使用二进制格式传输,更高效。更紧凑
- 对报头压缩,降低开销
- 多路复用,一个网络连接实现并行请求
- 服务器主动推送,减少请求的延迟
- 默认使用加密
HTTP2:二进制分帧层

HTTP/2所有性能增强的核心在于新的二进制分帧层,它定义了如何封装HTTP消息并在客户端与服务器之间传输。这里所谓的“层”指的是位于套接字接口与应用可见的高级HTTP API之间一个经过优化的新编码机制。HTTP/1.x协议以换行符作为纯文本的分隔符,而HTTP/2将所有传输的信息分割为更小的消息和帧,并采用二进制格式对它们编码。客户端和服务器会自动替我们完成必要的分帧工作。
HTTP2:多路复用

在HTTP1.x中,如果客户端要想发起多个请求以提升性能,则必须使用多个TCP链接。这种模型也会导致队首阻塞,从而造成底层TCP连接效率低下。将HTTP消息分解成独立的帧,交错发送,然后在另一端重新组装是HTTP2最重要的一项增强,这个机制会在整个网络技术栈中引发一系列连锁反应,从而带来巨大的性能提升。
- 并行交错地发送多个请求,请求之间互不影响
- 并行交错地发送多个响应,响应之间互不干扰
- 使用一个连接并行发送多个请求和响应
- 不必再为绕过HTTP/1.x限制而做很多工作
- 消除不必要的延迟和提高现有网络容量的利用率,从而减少页面加载时间
HTTP2:服务器推送
HTTP/2新增的另一个强大的新功能是,服务器可以对一个客户端请求发送多个响应,换句话说,除了对最初请求的响应外,服务器还可以向客户端推送额外资源而无需客户端明确地请求。HTTP2打破了严格的请求-响应语义,支持一对多和服务器发送的推送工作流。服务器已经知道客户端系一步要请求什么资源,这时候服务器推送即可派上用场。
推送资源可以进行以下处理:
- 客户端缓存
- 在不同页面之间重用
- 与其他资源一起复用
- 由服务器设定优先级
- 被客户端拒绝
HTTP2的伪头字段

伪头部字段是http2内置的几个特殊的以“:”开始的key,用于替代HTTP/1.x中请求行/响应行中的信息,比如请求方法,响应状态码等
- :method 目标URL模式部分(请求)
- :scheme 目标URL模式部分(请求)
- :authority目标URL认证部分(请求)
- :path 目标URL的路径和查询部分(绝对路径产生式和一个跟着“?”字符的查询产生式)(请求)
- :status 响应头中的HTTP状态码部分(响应)
了解HTTP3

运行在QUIC智商的HTTP协议被称为HTTP/3(HTTP-over-QUIC)。QUIC协议(Quick UDP Internet Connection)基于UDP,正是看中了UDP的速度与效率,同时QUIC也整合了TCP、TLS和HTTP/2的优点,并加以优化。
特点:
- 较少握手的延迟(1-RTT或0-RTT)
- 多路复用,并且没有TCP的阻塞问题
- 链接迁移(主要是在客户端)当wifi转移到4G时,连接不会断开。
HTTP3与HTTP1.1和HTTP2没有直接的关系,也不是HTTP2的扩展,HTTP3将会是一个全新的WEB协议,HTTP3目前处于定制和测试阶段,详情查看:https://www.chromium.org/quic
队首阻塞问题
HTTP/1.1和HTTP/2都存在队头阻塞问题(Head of line blocking),HTTO/1.1的队头阻塞,一个TCP链接同事传输10个请求,其中低1、2、3个请求已经被客户端接收,但是第四个请求丢失,那么后面第5-10个请求都被阻塞,需要第4个请求处理完毕后才能被处理,这样就浪费了带宽资源。HTTP/2的多路复用虽然可以解决“请求”这个粒度的阻塞,但HTTP/2的基础TCP协议本身却也存在着队头阻塞的问题,由于HTTP2必须使用HTTPS,而HTTPS使用的TLS协议也存在队头阻塞问题,队头阻塞会知道HTTP/2在更容易丢包的弱网络环境下比HTTP/1.1更慢。
QUIC解决队头阻塞问题的方法:
- QUIC的传输单元是Packet,加密单元也是Packet整个加密,传输、解密都基于Packet,这样就能避免TLS的队头阻塞问题
- QUIC基于UDP,UDP的数据包在接收端没有处理顺序,即使中间丢失一个包,也不会阻塞整条连接,其他的资源会被正常处理。
反向代理与WEB服务
反向代理与正向代理:
反向代理的用途
- 加密和SSL加速
- 负载均衡
- 缓存静态内容
- 压缩
- 减速上传
- 安全
- 外网发布
反向代理做负载均衡:
安装nginx
在linux下的两种安装方案:yum/apt安装,源码编译安装
yum安装
- rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
- yum install -y nginx
编译安装
- 准备环境:Linux服务器、gcc编译器、nginx源代码
- 获取nginx源码:http://nginx.org
- 编译安装nginx源码