HTTP
- 概念
HTTP 是一种用于分布式, 协作式和超媒体信息系统的应用层协议. 设计HTTP的的目的是为了提供一种发布和接收html页面的方法. 通过HTTP或者HTTPS协议请求的资源由统一资源标识符(URI)来标识.
- HTTP 协议层
HTTP (HyperText Transfer Protocol), 超文本传输协议, 是一个基于TCP实现的应用层协议.
应用层
FTP(File Transfer Protocol) 文件传输协议
HTTP(HyperText Transfer Protocol) 超文本传输协议
SMTP(Simple Mail Transfer Protocol) 简单邮件传输协议
POP3(Post Office Protocol) 邮局协议
DNS(Domain Name System) 域名系统
传输层
TCP(Transmission control protocol) 传输控制协议
UDP(User data Protocol) 用户数据协议
网络层
IP(Internet Protocol) 网络协议
ARP(Address Resolution Protocol)地址解析协议
ICMP(Internet control message Protocol)网络控制消息协议
HDLC(High Data Link Control)高级数据链路控制
数据链路层
SLIP(Serial link IP)串行线路IP
PPP 点到点协议
物理层
放大或者再生的信号, 在两个电缆段之间复制每一个byte
- HTTP请求响应模型
HTTP 由请求和响应构成, 是一个标准的B/S(客户端/服务端模型). HTTP协议永远是客户端发起请求, 服务器回送响应.
HTTP 是一个无状态的协议. 无状态是指客户机(web浏览器)和服务器之间不需要建立持久的连接, 这意味着当一个客户端向服务器发出请求, 然后服务器返回响应(response), 连接就关闭了, 在服务器端, 不保留连接的有关信息.
- HTTP 的工作过程
-
地址解析
http://www.baidu.com:8080/index.html
从中分解出协议名, 主机名, 端口, 对象路径等. -
封装HTTP请求数据包
把以上部分接口本机自己的信息, 封装成一个HTTP请求数据包 -
封装成TCP包, 建立TCP连接 (TCP 三次握手)
在HTTP开始工作前, 客户机(Web 浏览器)首先要通过网络与服务器建立连接, 该连接是通过TCP来完成的, 该协议与IP协议共同构建Internet, 即TCP/IP协议簇, 因此Internet又被称为TCP/IP网络. HTTP是比TCP更高层次的应用层协议, 根据规则, 只有底层协议建立之后才能进行高层协议的连接, 因此首先要建立TCP连接, 一般TCP连接的端口是80. -
客户机发送请求
建立连接后, 客户机发送一个请求给服务器, 请求方式格式为: 统一资源标识符(URI), 协议版本号, 后面是MIME信息, 包括服务器信息, 实体信息和可能的内容. -
服务器响应
服务器接到请求后, 给予响应的信息, 其格式为一个状态行, 包括信息的协议版本号, 一个成功或失败代码, 后面是MIME信息包括服务器信息, 实体信息和可能内容.
实体消息是服务器向浏览器发送头信息后, 他会发送一个空白行来表示头信息的发送到此为结束, 接着它就以content-type应答头信息所描述的格式发送用户所请求的实际数据. -
服务器关闭TCP连接
一般情况下, 一万web服务器向浏览器发送了请求数据, 它就关闭TCP连接, 然后如果浏览器或者服务器在其头部加入了Connection: keep-alive
TCP连接在发送后将任然保持连接状态, 于是浏览器可以继续通过相同的连接发送请求, 保持连接节省了为每个请求建立新连接所需要的时间, 还节约了网络带宽. -
HTTP 工作工程用到的概念
请求报文格式
-
请求方法 URL HTTP版本号
请求头
空行
body(只对post有效)
GET http://m.baidu.com/ HTTP/1.1
Host m.baidu.com
Connection Keep-Alive
...// 其他header
key=iOS
响应报文格式
HTTP版本号 返回码 返回码描述
应答头字段(可选)
空行
body
HTTP/1.1 200 OK
Content-Type text/html;charset=UTF-8
...// 其他header
<html>...
- URL结构
使用HTTP协议访问资源是通过URL(Uniform resource locator)统一资源定位符来实现的. 格式如下:
scheme://host:port/path ? query
协议, 域名, 端口(80), 路径, 查询条件
- HTTP 请求方法
GET: 获取URL 制定的资源
POST: 传输实体信息
PUT: 上传文件
DELETE:删除文件
HEAD: 获取报文头部, 与get相比不返回body部分
OPTIONS: 访问支持的方法
TRACE: 追踪请求路径
CONNECT:要求在与代理服务器通信时建立隧道, 使用隧道进行TCP通信. 主要使用SSL和TLS将数据加密后通过网络隧道进行传输.
- 报文字段
HTTP头部字段由字段名和字段值组成, 中间以 ":"分割, 如 Content-Type: text/html 其中, 同一个字段名可对应多个字段值.
HTTP报文字段分为5种:
请求报文字段
应答报文字段
实体头部字段
通用报文字段
其他报文字段
- 请求报文字段
Accept: 客户端能够处理的媒体类型如text/html, (type/subType)
常见的媒体类型:
文本文件: text/html, text/plain, text/css, application/xml
图片文件: image/jpeg, image/gif, image/png
视频文件: video/mpeg
应用程序使用的二进制文件: application/octet-stream, application/zip
Accept字段可设置多个字段值, 这样服务器依次进行匹配, 并返回最先匹配到的媒体类型, 可以通过 `q` 来设置媒体权重 [0 , 1]默认为1.0, 权重越高, 优先级越高.
Accept: text/html, application/xml; q = 0.9
Accept-Charset: 表示客户端支持的字符集
如: Accept-Charset: GB2312, ISO-8859-1
Accept-Encoding: 表示客户端内容编码格式
如: Accept-Encoding: gzip
常用的内容编码:
gzip: 由文件压缩程序 gzip 生成的编码格式
compress: 由Unix 文件压缩程序生成的编码格式
deflate: 组合使用zlib和deflate压缩算法生成的编码格式
identity: 默认的编码格式, 不执行压缩
Accept-Language: 表示客户端支持的语言
如: Accept-Language: zh-cn, en
Authorization: 表示客户端的认证信息.
Host: 表示访问资源所在主机名
如: www.baidu.com
If-Match: 该值与请求资源的ETag值一致时, 服务器才会处理此请求
If-Modified-Since: 用于确认客户端拥有本地资源的时效性
If-None-Match: 该值与请求资源的ETag值不一致时, 服务器才会处理此请求
If-Range:该值(或者时间)与访问资源的ETag值(或时间)相一致时, 服务器处理该请求并返回Range 字段中设置的指定范围数据. 如果不一致, 返回所有内容. 实为If-Match 的升级版.
If-Unmodified-Since: 与 If-modified-Since相反, 表示请求的资源在指定的时间之后未发生变化才处理此请求, 否则返回412
Max-Forwards: 表示请求可经过服务器的最大数目, 请求每被转发一次, Max-Forwards的值减1, 当减为0时, 所在服务器不再转发, 而是直接应答. 通过设置此参数, 来大概确定问题.
Proxy-Forwards: 当客户端接收到来自代理服务器的认证质询时, 客户端会将认证信息添加到Proxy-Forwards来完成认证, 类似与Authorization, 只不过是发生在客户端与服务器之间.
Range: 获取部分资源,
例如: Range: bytes = 500-1000.表示获取指定资源的500-1000字节之间的内容, 如果服务器能够争取处理, 则返回206作为应答, 表示返回了部分数据, 如果不能处理这种范围请求, 则返回200作为应答, 返回完整的数据.
Referer: 告知服务器请求是从哪个页面发起的, 通过这个字段可以统计广告点击次数.
User-Agent: 将发起请求的浏览器和代理名称等发送到服务端
如: User-Agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/63.0.3239.84 Mobile Safari/537.36
- 应答报文字段
Age: 服务端告知客户端, 源服务器(不是缓存服务器)在多久之前创建了响应
ETag: 实体资源的标识, 可用来请求指定的资源.
Location: 请求资源所在位置
Proxy-Authenticate: 将代理服务器需要的认证信息发送给客户端
Retry-After: 服务器告知客户端多久之后重试, 一般与503和3xx重定向类型的应答一起使用
Server: 告知服务端当前使用的HTTP服务器应用程序的相关信息.
WWW_Authenticate: 告诉客户端适用于所访问资源的认证方案, 如 Basic或者Digest, 401 中肯定包含这个字段
- 实体头部字段
Allow: 通知客户端, 服务器支持的请求方法, 服务器收到不支持的请求方法时, 会以405作为响应
Content-Encoding:告知客户端, 服务器对资源的内容编码
Content-Language: 资源所用自然语言
Content-Length: 告知客户端资源的长度
Content-Location: 告知客户端资源所在位置
Content-Type: 资源的媒体类型, 取值等同于请求头部的Accept 字段.
Expires: 客户端资源失效日期, 可用于对缓存的处理
Last-Modified: 最后一次修改的时间
- 通用报文字段
Cache-Control: 控制缓存
Connection: 管理持久连接, Keep-Alive 为长连接
Date: 创建HTTP报文的日期和时间
Pragma: Http/1.1 之前的历史遗留字段, 仅作为http/1.0向后兼容而定义, 虽然是通字段, 通常被使用在客户端的请求中,
如: Pragma: no-cache, 表示客户端在请求过程中不遵循服务单返回的缓存数据
Transfer-Encoding: 规定了传输报文时使用的传输编码
如: Transfer-Encoding: chunked
Upgrade: 用于检查Http协议或者其他协议是否有可使用的更高版本
Via: 追踪客户端和服务端之间的报文传输路径, 还可避免环的发生, 所以经过代理时, 必须添加此字段
- 其他报文字段
这些字段不是Http协议中定义的, 但是被广泛应用于HTTP请求中
Cookie: 属于请求型报文字段, 在请求时添加Cookie, 以实现HTTP的状态记录
Set-Cookie: 属于应答型报文字段. 服务器给客户端传递cookie信息时, 就是通过这个字段实现的
Set-Cookie: 字段属性
NAME=VALUE:设置cookie的名称和值
expires=DATE: cookie的有效期
path=PATH: 将服务器上的目录作为cookie的适用对象, 若不指定, 则默认为文档所在文件目录
domin=域名: 作为cookies适用对象的域名, 若不指定则为创建cookie的服务器域名
Secure: 仅在HTTPS安全通信时, 才会发送cookie
HttpOnly: 适用cookie不能被js脚本访问
`如:Set-Cookie:BDSVRBFE=Go; max-age=10; domain=m.baidu.com; path=/`
- HTTP应答状态码
| 1xx | Informational(信息类状态码) | 请求正在处理中 |
|---|---|---|
| 2xx | Success(成功状态码) | 请求成功 |
| 3xx | Redirection(重定向状态码) | 需要进行重定向 |
| 4xx | Client Error(客户端状态码) | 服务端无法处理请求 |
| 5xx | Server Error(服务端状态码) | 服务器处理请求时出错 |
200: 请求成功
204: 请求成功, 但响应的主体部分为空, 适用于只需要客户端向服务器发送数据的情况
206: 客户端进行了部分请求, 服务端返回了指定部分内容
301 请求的资源已被分配了新的URL, 永久性重定向
302 请求的资源被分配了新的URL, 暂时性重定向
303 同302, 区别在于服务端要求客户端使用get方法请求
304 客户端进行附带条件的请求时, 服务端允许访问资源, 但没满足条件, 304跟重定向没有任何关系
401 请求报文中存在语法错误
402 发送请求需要HTTP认证
403 请求的资源被服务器拒绝
404 服务器上没有请求的资源
500 服务器在处理请求是出现了错误
503 服务器正处于超负荷或维护状态, 无法处理请求
- HTTP缺点
- 使用明文传输, 可能被窃听
- 不验证身份, 可能遭遇伪装
- 无法证明报文完整性, 可能被篡改
HTTPS
HTTP + TLS/SSL
- HTTPS 概念
超文本传输安全协议(Hypertext Transfer Protocol secure)利用SSL/TLS来加密数据包. 目的是: 提供对服务器的身份认证, 保护交换数据的隐私与完整性.
HTTP 协议采用明文传输信息, 存在信息窃听, 信息篡改, 信息劫持的风险, 而TLS/SSL具有身份验证, 信息加密和完整性校验的功能, 可以避免此类问题发生.
TLS/SSL 安全传输层协议(Transport Layer Security), 是介于TCP和HTTP之间的一层安全协议, 不影响原有的TCP协议和HTTP协议.
HTTPS 对数据进行加密, 并建立一个信息安全通道, 来保证传输过程中的数据安全; 对网站服务器进行身份认证.
- TLS/SSL 工作原理
HTTPS协议的主要功能基本都依赖于TLS/SSL协议, TLS/SSL功能实现主要依赖于三类基本算法: 散列函数 hash, 对称加密, 非对称加密, 其利用非对称加密实现身份认证和秘钥协商, 对称加密算法采用协商的秘钥对数据加密, 基于散列函数验证信息的完整性.
image.png
image.png
-
散列函数 hash
常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性;
在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密; -
对称加密
常见的有AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1;
对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制; -
非对称加密
即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现1对多的通信，客户端也可以用来验证掌握私钥的服务器身份。
非对称加密的特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。
结合三类算法的特点，TLS的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，
然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。
PKI体系
RSA身份验证的隐患
身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患:
- 客户端C和服务器S进行通信，中间节点M截获了二者的通信;
- 节点M自己计算产生一对公钥pub_M和私钥pri_M;
- C向S请求公钥时，M把自己的公钥pub_M发给了C;
- C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，而 C无法根据公钥信息判断服务器的身份，从而 C和 * M之间建立了"可信"加密连接;
- 中间节点 M和服务器S之间再建立合法的连接，因此 C和 S之间通信被M完全掌握，M可以进行信息的窃听、篡改等操作。
- 另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。
因此该方案下至少存在两类问题：中间人攻击和信息抵赖。
image
身份验证CA和证书
解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使用者提供证书验证服务，即PKI体系(PKI基础知识)。
基本的原理为，CA负责审核信息，然后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下：
image
a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
b.CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
c.如信息审核通过，CA会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名;
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
d.客户端 C 向服务器 S 发出请求时，S 返回证书文件;
e.客户端 C读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法;
f.客户端然后验证证书相关的域名信息、有效时间等信息;
g.客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
在这个过程注意几点：
a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
d.证书=公钥+申请者与颁发者信息+签名;
证书链
如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。
a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;
b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;
c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。
image
服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。
二级证书结构存在的优势：
a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;
b.根证书一般内置在客户端中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;
c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;
d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。
image
证书链有以下特点：
a.同一本服务器证书可能存在多条合法的证书链。
因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。
中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。
证书吊销
CA 机构能够签发证书，同样也存在机制宣布以往签发的证书无效。证书使用者不合法，CA 需要废弃该证书;或者私钥丢失，使用者申请让证书无效。主要存在两类机制：CRL 与 OCSP。
CRL
Certificate Revocation List, 证书吊销列表(什么是证书吊销列表(CRL)？吊销列表起什么作用)，一个单独的文件。该文件包含了 CA 已经吊销的证书序列号(唯一)与吊销日期，同时该文件包含生效日期并通知下次更新该文件的时间，当然该文件必然包含 CA 私钥的签名以验证文件的合法性。
证书中一般会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。
OCSP
Online Certificate Status Protocol, 证书状态在线查询协议，一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址，要求查询服务器具有良好的性能。部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的，对于吊销证书会是一件非常麻烦的事情。
HTTPS性能与优化
HTTPS性能损耗
前文讨论了HTTPS原理与优势：身份验证、信息加密与完整性校验等，且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价，HTTPS协议的性能损耗主要体现如下：
- 增加延时
分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT，利用会话缓存从而复用连接，延时也至少1* RTT*
- 消耗较多的CPU资源
除数据传输之外，HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约17核，24核CPU最多接入 HTTPS 连接 4800;
静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，如果将所有的HTTP连接变为HTTPS连接，则明显RSA的解密最先成为瓶颈。因此，RSA的解密能力是当前困扰HTTPS接入的主要难题。
HTTPS接入优化
CDN接入
HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。
会话缓存
虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。
硬件加速
为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。
远程解密
本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
SPDY/HTTP2
前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。
https://www.kancloud.cn/spirit-ling/http-study/851905
https://www.jianshu.com/p/071bb0c266ac
https://www.jianshu.com/p/42e1c073c142
网友评论