U上q行?APISIX ?1.5 版本Q而社区已l发布了 Apisix 2.2Q是时候需要升U到最新版了,能够享受最版本带来的大量的BugFixQ性能增强Q以及新增特性的支持{~
从Apisix 1.5升到Apisix 2.2q程中,不是一帆风的Q中间踩了不坑Q所谓前车之鉴后事之师,q里l大家简单梳理一下我们团队所在具体业务环境下Q升U过E中t的若干坑,以及一些需要避免的若干注意事项{?/p>
下文所说原先版本,皆指Apisix 1.5Q新版则是Apisix 2.2版本?/p>
针对上游Upstream没有使用服务发现的\由来Ԍ本次升没有遇到什么问题?/p>
公司内部U上业务大都ZConsul KV方式实现服务注册和服务发玎ͼ因此我们自行实现了一?consul_kv.lua
模块实现服务发现程?/p>
q在Apisix 1.5下面一切工作正常?/p>
但在Apisix 2.2下面Q就无法直接工作了,原因如下Q?/p>
discovery_type
q行索引原先q行中仅支持一U服务发现机Ӟ需要配|在 apisix
层下面Q?/p>
apisix:
......
discover: consul_kv
......
新版需要直接在config*.yaml
文g中顶层层U下q行配置Q可支持多种不同的\由发现机Ӟ如下Q?/p>
discovery: # service discovery center
eureka:
host: # it's possible to define multiple eureka hosts addresses of the same eureka cluster.
- "http://127.0.0.1:8761"
prefix: "/eureka/"
fetch_interval: 30 # default 30s
weight: 100 # default weight for node
timeout:
connect: 2000 # default 2000ms
send: 2000 # default 2000ms
read: 5000
我们有所变通,直接在配|文仉层配|consul_kv多个集群相关参数Q避?discovery
层q深?/p>
discovery:
consul_kv: 1
consul_kv:
servers:
-
host: "172.19.5.30"
port: 8500
-
host: "172.19.5.31"
port: 8500
prefix: "upstreams"
timeout:
connect: 6000
read: 6000
wait: 60
weight: 1
delay: 5
connect_type: "long" # long connect
......
当然Q这仅仅保证了服务发现模块能够在启动时被正常加蝲?/p>
推荐阅读Q?/p>
Apisix当前同时支持多种服务发现机制Q这个很赞。对应的代hQ就是需要额外引?discovery_type
字段Q用于烦引可能同时存在的多个服务发现机制?/p>
?Cousul KV方式服务发现ZQ那么需要在已有?upstream
对象中需要添加该字段Q?/p>
"discovery_type" : "consul_kv"
原先的一?code>upstream对象Q仅仅需?service_name
字段属性指定服务发现相兛_址卛_Q?/p>
{
"id": "d6c1d325-9003-4217-808d-249aaf52168e",
"name": "grpc_upstream_hello",
......
"service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
"create_time": 1610437522,
"desc": "demo grpc service",
"type": "roundrobin"
}
而新版的则需要添?code>discovery_type字段Q表明该service_name
字段对应的具体模块名Uͼ效果如下Q?/p>
{
"id": "d6c1d325-9003-4217-808d-249aaf52168e",
"name": "grpc_upstream_hello",
......
"service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
"create_time": 1610437522,
"desc": "demo grpc service",
"type": "roundrobin",
"discovery_type":"consul_kv"
}
后面我们若支持Consul Service或ETCD KV方式服务发现机制Q则会非常弹性和清晰?/p>
调整了配|指令,d上述字段之后Q后端服务发现其实就已经起作用了?/p>
但gRPC代理路由q不会生?#8230;…
在我们的pȝ中,上游和\由是需要单独分开理的,因此创徏的HTTP或GRPC路由需要处理支?code>upstream_id的烦引?/p>
q在1.5版本中,grpc路由是没问题的,但到了apisix 2.2版本中,l护?@spacewander
暂时没做支持Q原因是规划grpc路由和dubbo路由处理逻辑于一_更ؓ紧凑。从l护角度我是认可的,但作Z用者来Ԍq就有些不合理了Q直接丢弃了针对以往数据的支持?/p>
作ؓ当前Geek一些方式,?apisix/init.lua
中,最成?Q优雅和成本成反比)修改如下Q找到如下代码:
-- todo: support upstream id
api_ctx.matched_upstream = (route.dns_value and
route.dns_value.upstream)
or route.value.upstream
直接替换Z面代码即可解决燃眉之急:
local up_id = route.value.upstream_id
if up_id then
local upstreams = core.config.fetch_created_obj("/upstreams")
if upstreams then
local upstream = upstreams:get(tostring(up_id))
if not upstream then
core.log.error("failed to find upstream by id: " .. up_id)
return core.response.exit(502)
end
if upstream.has_domain then
local err
upstream, err = lru_resolved_domain(upstream,
upstream.modifiedIndex,
parse_domain_in_up,
upstream)
if err then
core.log.error("failed to get resolved upstream: ", err)
return core.response.exit(500)
end
end
if upstream.value.pass_host then
api_ctx.pass_host = upstream.value.pass_host
api_ctx.upstream_host = upstream.value.upstream_host
end
core.log.info("parsed upstream: ", core.json.delay_encode(upstream))
api_ctx.matched_upstream = upstream.dns_value or upstream.value
end
else
api_ctx.matched_upstream = (route.dns_value and
route.dns_value.upstream)
or route.value.upstream
end
新版的apisix auth授权插g支持多个授权插g串行执行Q这个功能也很赞Q但此DD了先前ؓ具体业务定制的授权插件无法正常工作,q时需要微调一下?/p>
原先调用方式Q?/p>
local consumers = core.lrucache.plugin(plugin_name, "consumers_key",
consumer_conf.conf_version,
create_consume_cache, consumer_conf)
因ؓ新版?code>lrucache不再提供 plugin
函数Q需要微调一下:
local lrucache = core.lrucache.new({
type = "plugin",
})
......
local consumers = lrucache("consumers_key", consumer_conf.conf_version,
create_consume_cache, consumer_conf)
另一处是Q顺利授权之后,需要赋?code>consumer相关信息Q?/p>
ctx.consumer = consumer
ctx.consumer_id = consumer.consumer_id
此时需要替换成如下方式QؓQ可能存在的Q后l的授权插gl箋作用?/p>
consumer_mod.attach_consumer(ctx, consumer, consumer_conf)
更多请参考:apisix/plugins/key-auth.lua
源码?/p>
q移分ؓ三步Q?/p>
/apisix/upstreams
中包含服务注册的数据Q一一d "discovery_type" : "consul_kv"
属?/li>
Z以上操作之后Q从而完成了ETCD V2到V3的数据迁UR?/p>
我们在运l层面,使用 /usr/local/openresty/bin/openresty -p /usr/local/apisix -g daemon off;
方式q行|关E序?/p>
q也导_自动忽略了官Ҏ倡的Q?code>apisix start 命o自动提前为ETCD V3初始化的一些键值对内容?/p>
因此Q需要提前ؓETCD V3建立以下键值对内容Q?/p>
Key Value
/apisix/routes : init_dir
/apisix/upstreams : init_dir
/apisix/services : init_dir
/apisix/plugins : init_dir
/apisix/consumers : init_dir
/apisix/node_status : init_dir
/apisix/ssl : init_dir
/apisix/global_rules : init_dir
/apisix/stream_routes : init_dir
/apisix/proto : init_dir
/apisix/plugin_metadata : init_dir
不提前徏立的话,׃Dapisix重启后,无法正常加蝲ETCD中已有数据?/p>
其实有一个补救措施,需要修?apisix/init.lua
内容Q找到如下代码:
if not dir_res.nodes then
dir_res.nodes = {}
end
比较geek的行为,使用下面代码替换一下即可完成兼容:
if dir_res.key then
dir_res.nodes = { clone_tab(dir_res) }
else
dir_res.nodes = {}
end
我们Zapisix-dashboard定制开发了大量的针对公司实际业务非常实用的企业U特性,但也D了无法直接升U到最新版的apisix-dashboard?/p>
因ؓ非常基础的上游和路由没有发生多大改变Q因此这部分升的需求可以忽略?/p>
实际上,只是在提交上游表单时Q包含服务注册信息JSON字符串中需要增?discovery_type
字段和对应值即可完成支持?/p>
p了一些时间完成了从Apisix 1.5升到Apisix 2.2的行为,虽然有些坑,但整体来Ԍq算利。目前已l上Uƈ全量部vq行Q目前运行良好?/p>
针对q停留在Apisix 1.5的用P新版增加了Control API以及多种服务发现{新Ҏ支持,q是非常值得升的?/p>
升之前Q不妨仔l阅L一个版本的升日志Q地址Q?a >https://github.com/apache/apisix/blob/2.2/CHANGELOG.md Q,然后需要根据具体业务做好兼Ҏ试准备和准备升步骤Q这些都是非常有必要的?/p>
针对我们团队来讲Q升U到最新版Q一斚w降低了版本升U的压力Q另一斚w也能够辅助我们能参与到开源社Z去,挺好~
最q一D|_要ؓ一个手机终端APPE序从零开始设计一整套HTTP APIQ因为面向的用户很固定,一个新的移动端APP。目前还是项目初期,自然要求一切快速、从Q实用性ؓ丅R?/p>
下面逐一我们是如何设计HTTP APIQ虽然相对大部分言Q没有什么新意,但对我来说很新鲜的。避免忘_着I闲快记录下来?/p>
PHP嘛?团队内也没几个h熟悉?/p>
JavaQ好几年没有过了,那么复杂的解x案,再加上团队内也没什么h?……
团队使用qLuaQ基于OpenResty构徏qTCP、HTTP|关{,对Lua + Nginxl合非常熟悉Q能够快速的应用在线上环境。再说Lua语法y、简单,一个新手半天就可以基本熟悉Q马上开工?/p>
看来QNginx + Lua是目前最为适合我们的了?/p>
HTTP APIQ需要充分利用HTTP具体操作语义Q来应对具体的业务操作方法。基于此Q没有闭门造RQ我们选择?http://lor.sumory.com/ q么一个小巧的框架Q用于辅助HTTP API的开发开发?/p>
嗯,OpenResty + Lua + LorQ就构成了我们简单技术堆栈?/p>
每一具体业务逻辑Q直接在URL Path中体现出来。我们要的是单快速,数据l构之间的连接关p,可能的LE化。egQ?/p>
/resource/video/ID
比如用户反馈q一模块Q将使用下面比较固定的\径:
/user/feedback
GET
Q以用户l度查询反馈的历史列表,可分?
curl -X GET http://localhost/user/feedback?page=1
POST
Q提交一个反?
curl -X POST http://localhost/user/feedback -d "content=hello"
DELETE
Q删除一个或多个反馈Q参数附加在URL路径中?
curl -X DELETE http://localhost/user/feedback?id=1001
PUT
Q更新评论内?
curl -X PUT http://localhost/user/feedback/1234 -d "content=hello2"
用户属性很多,用户늧只是其中一个部分,因此更新늧q一行ؓQHTTP?PATCH
Ҏ可更_և的描q部分数据更新的业务需求:
/user/nickname
PATCH
Q更新用hUͼ늧是用户属性之一Q可以用更轻量U的 PATCH
语义
curl -X PATCH http://localhost/user/nickname -d "nickname=hello2"
嗯,同一cȝ资源URL虽然固定了,但HTTP Method呈现了不同的业务逻辑需求?/p>
实际业务HTTP API的访问是需要授权的?/p>
传统的Access Token解决ҎQ有session回话机制Q一般需要结合Web览器,需要写入到Cookie中,或生产一个JSessionID用于标识{。这针对单纯面向Udl端的HTTP API后端来讲Qƈ没有义务dq一的兼容,略显冗余?/p>
另外是 OAUTH
认证了,有整套的认证Ҏq已工业化,很是成熟了,但对我们而言q是太重Q不太适合轻量U的HTTP APIQ不太可能花费太多的_֊d它的q维工作?/p>
最l选择了轻量?Json Web TokenQ非常紧凑,开即用?/p>
最佛_法是把JWT Token攑֜HTTPh头部中,不至于和其它参数hQ?/p>
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI2NyIsInV0eXBlIjoxfQ.LjkZYriurTqIpHSMvojNZZ60J0SZHpqN3TNQeEMSPO8" -X GET http://localhost/user/info
下面是一副浏览器D늚一般认证流E,q与HTTP API认证大体一_
JWT的Lua实现Q推? https://github.com/SkyLothar/lua-resty-jwt.git
Q简单够用?/p>
jwt需要和业务q行l定Q结?lor q个API开发框架提供的中间件机Ӟ可在业务处理之前Q在合适位|进行权限拦截?/p>
不同于OAUTHQJWT协议?strong>自包?/strong>Ҏ,军_了后端可以将很多属性信息存攑֜payload负荷中,其token生成之后后端可以不用存储Q下ơ客L发送请求时会发送给服务器端Q后端获取之后,直接验证卛_Q验证通过Q可以直接读取原先保存其中的所有属性?/p>
下面梳理一下Jwt认证和Lor的结合?/p>
app:use(function(req, res, next)
local token = ngx.req.get_headers()["Authorization"]
-- 校验p|Qerr为错误代码,比如 400
local payload, err = verify_jwt(token)
if err then
res:status(err):send("bad access token reqeust")
return
end
-- 注入q当前上下文中,避免每次从token中获? req.params.uid = payload.uid
next()
end)
app:use("/user", function(req, res, next)
if not req.params.uid then
-- 注意Q这里没有调用next()ҎQ请求到q里截止了Q不在匹配后面的路由
res:status(403):send("not allowed reqeust")
else
next() -- 满以上条gQ那么l匹配下一个\? end
end)
local function check_token(req, res, next)
if not req.params.uid then
res:status(403):send("not allowed reqeust")
else
next()
end
end
local function check_master(req, res, next)
if not req.params.uid ~= master_uid then
res:status(403):send("not allowed reqeust")
else
next()
end
end
local lor = require("lor.index")
local app = lor()
-- 声明一个group router
local user_router = lor:Router()
-- 假设查看是不需要用h限的
user_router:get("/feedback", function(req, res, next)
end)
user_router:put("/feedback", check_token, function(req, res, next)
end)
user_router:post("/feedback", check_token, function(req, res, next)
end)
-- 只有理员才有权限删?user_router:delete("/feedback", check_master, function(req, res, next)
end)
-- 以middleware的Ş式将该group router加蝲q来
app:use("/user", user_router())
......
app:run()
我们在上一个项目中对外提供了GraphQL APIQ其Q在试环境下)自n提供文档输出自托机Ӟ再结合方便的调试客户端,实让后端开发和前端APP开发大大降低了频繁交流的频率,节省了若q流量,但前期还是需要较多的培训投入?/p>
但在新项目中Q一度想提供GraphQL APIQ遇到的问题如下Q?/p>
毫无疑问Q以最低成本快速构为完整的APP功能QHTTP API + JSON格式是最服的选择?/p>
虽然有些担心服务器端的输出,很多时候还是会费掉一些流量,客户端ƈ不能够有效的利用q回数据的所有字D属性。但和进度以及h们已l习惯的HTTP API调用方式相比Q又微乎其微了?/p>
当前q一套HTTP API技术堆栈运行的q不错,希望能给有同样需要的同学提供一点点的参考h? :))
当然没有一成不变的架构模型Q随着业务的逐渐发展Q后面相信会有很多的变动。但q是以后的事情了Q谁知道呢,后面有空再次记录吧~
q里整理了一下错误和安全相关部分单记录?/p>
HTTP/2定义了两U类型错误:
错误代码Q?2位正整数表示错误原因QRST_STREAM和GOAWAY帧中包含?/p>
未知或不支持的错误代码可以选择忽略Q或作ؓINTERNAL_ERROR错误对待都可以?/p>
一般来讲连接错误很严重Q会D处理q程无法q行下去Q或影响到整个连接的状态?/p>
一般来讲具体流上的错误不会媄响到其它的处理?/p>
TCPq接被关闭或重置时仍有处?open"?half closed"的流不能自动重试?/p>
跨协议攻击,字面上理解就很简单,比如d者构建HTTP/1.1h直接转发l仅仅支持HTTP/2的服务器Q以期待获取d效果?/p>
q里有一讲解跨协议d的文章:http://www.freebuf.com/articles/web/19622.html
TLS的加密机制得攻击者很难获得明文,另外TLS的ALPN协议扩展可以很轻村֤理请求是否需要作为HTTP/2hq行处理QM可有效阻止对ZTLS的其它协议攻凅R?/p>
Z标准版TCP没有TLS和ALPN的帮忙,客户端所发送连接序a前缀为PRI字符串用来淆HTTP/1.1服务器,但对其它协议没有提供保护Q仅限于此。但在处理时Q若接收到HTTP/1.1的请求,没有包含Upgrade升字段Q则需要认为是一个跨协议d?/p>
MQ程序要可能的健壮Q容错,针对非法的请求,直接关闭Ҏq接?/p>
中介所做的HTTP/1.1和HTTP/2之间转换Q会存在d点:
解决方式Q一旦发现非法头字段名称Q以及非法头字段|都作Z完整、残~数据对待,或丢弃,或忽略?/p>
推送内Ҏ保证的服务器提供Q是否缓存由头字DCache-Control控制?/p>
但若服务器上多租户Ş式(SAASQ,每一个租户用一部分URLI间Q比?tenant1.domain.comQtenant2.domain.comQ服务器需要确保没有授权的U户不能够推送超于预期的资源Q覆盖已有内宏V?/p>
原始服务器没有被授权使用推送,既不能够q规发送推送,也不能够被缓存?/p>
MQ诸如SETTINGS帧、小帧或IQ报头压~被合理滥用Ӟ表明上看W合逻辑Q会造成资源q度消耗。这需要服务器端监控跟t到此种行ؓQƈ且设|用数量的上限Q一旦发现直接报ENHANCE_YOUR_CALMcdq接错误?/p>
报头块过大导致实现需要维护大量的状态开销。另外,Ҏ报头字段q行路由的情况,若此报头字段出现在一pd报头块的最后一个里面Q可能会D无法正常路由到目的地。若被缓存会D耗费大量的内存。这需要设|SETTINGS_MAX_HEADER_LIST_SIZE参数限制报头最大|以尽可能的避免出C上情c?/p>
服务器一旦接收到过报头限制hQ需要响应一?31Q请求头q大Q?HTTP状态码Q客L呢可直接丢掉响应?/p>
一般来Ԍ填充可用来淆的真实负载长度,E加保护Q降低攻ȝ可能性。但若不当的填充{略Q固定填充数、可L推导出填充规则等情况都会降低保护的力度,都有可能会被d者破解?/p>
中介讑֤应该保留DATA帧的填充Q需要避免如上所qC些情况)Q但可丢弃HEADERS和PUSH_PROMISE帧的填充?/p>
HTTP/2加密建立在TLS基础Q关于TLSQ维基百U上有解释:http://zh.wikipedia.org/wiki/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E5%8D%94%E8%AD%B0
摘取一张图Q可说明ZALPN协议扩展定义的协商流E:
其它要求Q?/p>
q里单记录HTTP/2错误和安全相关事,本系列规范学习到此告一D落?/p>
无论是HTTP/1.*q是HTTP/2QHTTP的基本语义是不变的,比如Ҏ语义QGET/PUST/PUT/DELETEQ,状态码Q?00/404/500{)QRange RequestQCacheingQAuthentication、URL路径。以前纯文本形式作ؓ传输的蝲体,HTTP/2带来了与之不同的二进制传输语法语义?/p>
下面为HTTP/2消息交换方便W记?/p>
一个典型的HTTP消息包含h/响应Q组成如下:
注意事项Q?/p>
HTTP/2多\复用Q以及自w也可以通过HTTP/1.1 101切换古来Q因此不支持101切换协议QSwitching ProtocolsQ机制也是情理之中?/p>
HTTP/2报头字段注意点:
单图片请求:
模拟一ơ提交,讄报头大于16KBQ一般情况下Q报头没有那么大Q除非Cookie撑大Q:
以上CZQ可以帮助理解HTTP/1.x和HTTP/2在HTTP语义表述上的不同?/p>
HTTP/1.1QHTTP客户端无法重试非q等hQ尤其在错误发生的时候,׃无法错误性质q会寚w试带来不利的影响?/p>
而HTTP/2在这斚w有所增强Q提供了两种方式可判断请求是否被完成Q?/p>
另外PING帧有利于客户端检当前连接是否可用,可以理解为心跳保zLӞ因ؓ一些网兟뀁负载设备会关闭I闲状态下的连接以节省资源?/p>
HTTP/2新增Ҏ,服务器根据客L一ơ请求内容主动推送与之相关的hq去Q避免客L在解析出初次h面内容Ӟ再逐一发送资源请求,节省|络资源利用效率?一些注意事:
比如Q服务器接收到来自客L的请求某个HTML文档资源Q该文档包含了若q图片连接,服务器应该优先发送图片数据到客户端,q需要优先发送推送承诺早于包含完整HTML文档内容的DATA帧,q样客户端优先接收到承诺资源Q后面接收到DATA数据帧进行解析出囄q接的时候,避免再ơ发送图片资源请求嘛?/p>
在HTTP原始语义中是没有CONNECTҎ的,q个伪方法(pseudo-methodQ在HTTP/1.xQHTTP代理用作转换HTTPq接通过隧洞方式到远E主机,HTTPS方式交互?HTTP/2与之cMQ伪ҎCONNECT被HTTP代理用作在一个单独的HTTP/2之上徏立一个到q程L的隧道,要求如下Q?/p>
一旦不满要求Q会被视Z完整的需求?/p>
HTTP/2消息交换通过持久q接、重用实玎ͼ目的可能做到资源利用率最大化?/p>
以上为HTTP/2消息交换机制的一些简单梳理,需要注意点Q?/p>
客户端和服务器端一旦握手协商成功接建立q接Q端点之间可以基于HTTP/2协议传递交换数据了?/p>
下图为HTTP/2帧通用格式Q?负蝲的比特位通用l构Q?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
帧头为固定的9个字节((24+8+8+1+31)/8=9Q呈玎ͼ变化的ؓ帧的负蝲(payload)Q负载内Ҏ由cdQTypeQ定义?/p>
关于帧长度,需要稍加关注: - 0 ~ 2^14Q?6384Qؓ默认U定长度Q所有端炚w需要遵?- 2^14 (16,384) ~ 2^24-1(16,777,215)此区间数|需要接收方讄SETTINGS_MAX_FRAME_SIZE参数单独赋?- 一端接收到的长度过讑֮上限或太小Q需要发送FRAME_SIZE_ERR错误 - 当镉K误会影响到整个连接状态时Q须以连接错误对待之Q比如HEADERSQPUSH_PROMISEQCONTINUATIONQSETTINGSQ以及标识W不该ؓ0的{,都需要如此处?- M端都没有义务必须使用完一个的所有可用空?- 大可能会导致gq,针对旉敏感的Q比如RST_STREAM, WINDOW_UPDATE, PRIORITYQ需要快速发送出去,以免延迟D性能{问?/p>
和HTTP/1一PHTTP/2报头字段包含一个或多个相关的键值对。报头字D会在HTTPh/响应报头和服务器推送操作中使用。原先ؓ文本字段Q现在需要用HTTP报头压羃q行序列化成报头分块Q作为HEADERS ?PUSH_PROMISE、CONTINUATION{的负载传输出厅R?/p>
解压~采用的HPACK协议Q具体可参考:http://http2.github.com/http2-spec/compression.html
接收端合q接收到的l装成报头分块,解压~还原报头集合?/p>
一个完整的报头分块包含Q?- 单个包含报头l止标记END_HEADERS的HEADERS、PUSH_PROMISE帧,或?- HEADERS、PUSH_PROMISE帧不包含的END_HEADERS标记Q后l跟随一个或多个CONTINUATION帧,最后一个CONTINUATION帧包含了END_HEADERS标记?/p>
报头压羃是有状态的Q在一个完整的q接中,一方的压羃上下文环境,另一方的解压的上下文环境Q都是需要具备的。报头解码失败需要作接错误COMPRESSION_ERROR对待?/p>
报头块彼此之间离散,作ؓq箋的同一cd帧序列存在,不存在交错以及来自其他cd帧或。D一个例子,一个连l的HEADERS/CONTINUATION/PUSH_PROMISE帧序列,最后一个包含了END_HEADERS标记Q表CZ个报头完l。一个报头块逻辑上是一个Q但是否完整取决于同cdq箋的的最后一个包含END_HEADERS标记?/p>
报头块作为HEADERS/PUSH_PROMISE/CONTINUATION{负蝲被一端发向另一端。接收端需要从HEADERS/PUSH_PROMISE/CONTINUATION{负蝲中进行组装报头块Q执行解压还原报头集合,不管帧需要不需要被丢弃。接收端在解压时若不能够正常解压报头块,需要回应COMPRESSION_ERROR错误Q然后终止连接?/p>
规范定义?0个正式用到帧类型,扩展实验cd的ALTSVC、BLOCKED{不在介l之列。下面按照优先用顺序重新排排序?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x4 (8) | 0000 000? (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier/0x0 (32) | +=+=============================+===============================+ | Identifier (16) | +-------------------------------+-------------------------------+ | Value (32) | +---------------------------------------------------------------+ | Identifier (16) | +-------------------------------+-------------------------------+ | Value (32) | +---------------------------------------------------------------+
讄帧,接收者向发送者通告己方讑֮Q服务器端在q接成功后必ȝ一个发送的帧?/p>
字段Identifier定义了如下参敎ͼ - SETTINGS_HEADER_TABLE_SIZE (0x1)Q通知接收者报头表的字节数最大|报头块解码用;初始gؓ4096个字节,默认可不用设|?- SETTINGS_ENABLE_PUSH (0x2)Q?Q禁止服务器推送,1Q允许推送;其它值非法,PROTOCOL_ERROR错误 - SETTINGS_MAX_CONCURRENT_STREAMS (0x3)Q发送者允许可打开的最大|?00Q默认可不用讄Q?gؓ止创徏新流 - SETTINGS_INITIAL_WINDOW_SIZE (0x4)Q发送端控H口大小Q默认?^16-1 (65,535)个字节大;最大gؓ2^31-1个字节大,若溢出需要报FLOW_CONTROL_ERROR错误 - SETTINGS_MAX_FRAME_SIZE (0x5)Q单帧负载最大|默认?^14Q?6384Q个字节Q两端所发送都会收到此设定媄响;值区间ؓ2^14Q?6384Q?2^24-1(16777215) - SETTINGS_MAX_HEADER_LIST_SIZE (0x6)Q发送端通告自己准备接收的报头集合最大|卛_节数。此g赖于未压~报头字D,包含字段名称、字Dg及每一个报头字D늚32个字节的开销{;文档里面虽说默认g受限Ӟ因ؓ受到报头集合大小不限制的影响Q个Z要多? SETTINGS_MAX_FRAME_SIZEQ即2^142=32768Q,否则包头太大Q隐患多多?/p>
标志位: * ACK (0x1)Q表C接收者已l接收到SETTING帧,作ؓ认必须讄此标志位Q此时负载ؓI,否则需要报FRAME_SIZE_ERROR错误
注意事项Q?- 在连接开始阶D必d许发送SETTINGS帧,但不一定要发?- 在连接的生命周期内可以允怓Q一端点发?- 接收者不需要维护参数的状态,只需要记录当前值即?- SETTINGS帧仅作用于当前连接,不针对单个流Q因此流标识Wؓ0x0 - 不完整或不合规范的SETTINGS帧需要抛出PROTOCOL_ERRORcdq接错误 - 负蝲字节Cؓ6个字节的倍数Q?*N (N>=0)
处理程Q?- 发送端发送需要两端都需要携带有遵守的SETTINGS讄帧,不能够带有ACK标志?- 接收端接收到无ACK标志位的SETTINGS帧,必须按照帧内字段出现序一一q行处理Q中间不能够处理其它?- 接收端处理时Q针对不受支持的参数需忽略 - 接收端处理完毕之后,必须响应一个包含有ACK认标志位、无负蝲的SETTINGS?- 发送端接收到确认的SETTINGS帧,表示两端讄已生?- 发送端{待认若超Ӟ报SETTINGS_TIMEOUTcdq接错误
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x1 (8) | 00?0 ??0? (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============+===============================================+ |Pad Length? (8)| +-+-------------+-----------------------------------------------+ |E| Stream Dependency? (31) | +-+-------------+-----------------------------------------------+ | Weight? (8) | +-+-------------+-----------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+
报头主要载体Q请求头或响应头Q同时呢也用于打开一个流Q在处于打开"open"或者远E半关闭"half closed (remote)"状态都可以发送?/p>
字段列表Q?- Pad LengthQ受制于PADDED标志控制是否昄Q?个比特表C填充的字节数?- EQ一个比特表C流依赖是否专用Q可选项Q只在流优先UPRIORITY被设|时有效 - Stream DependencyQ?1个比特表C流依赖Q只在流优先UPRIORITY被设|时有效 WeightQ?个比特(一个字节)表示无符L自然数流优先U,D围自然是(1~256)Q或UC为权重。只在流优先UPRIORITY被设|时有效 - Header Block FragmentQ报头块分片 - PaddingQ填充的字节Q受制于PADDED标志控制是否昄Q长度由Pad Length字段军_
所需标志位: END_STREAM (0x1): 报头块ؓ最后一个,意味着的l束。后l可紧接着CONTINUATION帧在当前的流中,需要把CONTINUATION帧作为HEADERS帧的一部分对待 END_HEADERS (0x4): 此报头不需分片Q完整的一个。后l不再需要CONTINUATION帧帮忙凑齐。若没有此标志的HEADER帧,后箋帧必L以CONTINUATION帧传递在当前的流中,否则接收者需要响应PROTOCOL_ERRORcd的连接错误?PADDED (0x8): 需要填充的标志 PRIORITY (0x20): 优先U标志位Q控制独立标志位EQ流依赖Q和权重?/p>
注意事项Q?- 其负载ؓ报头块分片,若内容过大,需要借助于CONTINUATION帧l传输。若标识符?x0Q结束段需要返回PROTOCOL_ERRORq接异常。HEADERS帧包含优先信息是ؓ了避免潜在的不同之间优先序的干扰?- 其实一般来Ԍ报文头部不大的情况下Q一个HEADERS可以完成了Q特D情况就是Cookie字段过16KiB大小Q不常见?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x9 (8) | 0x0/0x4 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (32) | +=+=============================================================+ | Header Block Fragment (*) | +---------------------------------------------------------------+
字段列表Q?- Header Block FragmentQ用于协助HEADERS/PUSH_PROMISE{单帧无法包含完整的报头剩余部分数据?/p>
注意事项Q?- 一个HEADERS/PUSH_PROMISE帧后面会跟随零个或多个CONTINUATIONQ只要上一个没有讄END_HEADERS标志位,׃一个完整数据的结束?- 接收端处理此U情况,从开始的HEADERS/PUSH_PROMISE帧到最后一个包含有END_HEADERS标志位l束Q合q的数据才算是一份完整数据拷?- 在HEADERS/PUSH_PROMISEQ没有END_HEADERS标志位)和CONTINUATION帧中_是不能够掺杂其它帧的Q否则需要报PROTOCOL_ERROR错误
标志位: * END_HEADERS(0X4)Q表C报头块的最后一个Q否则后面还会跟随CONTINUATION帧?/p>
一个或多个DATA帧作求、响应内容蝲体,较ؓ完整的结构如下:
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x0 (8) | 0000 ?00? (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============+===============================================+ |Pad Length? (8)| +---------------+-----------------------------------------------+ | Data (*) ... +---------------------------------------------------------------+ | Padding? (*) ... +---------------------------------------------------------------+
字段Q?Pad Length: 一个字节表C填充的字节长度。取决于PADDED标志是否被设|? Data: q里是应用数据,真正大小需要减d他字D(比如填充长度和填充内容)长度?* Padding: 填充内容q个0x0字节Q受PADDED标志控制是否昄。接收端处理时可忽略验证填充内容。若验证Q可以对?x0内容填充回应PROTOCOL_ERRORcdq接异常?/p>
标志位: END_STREAM (0x1): 标志此为对应标志流最后一个Q流q入了半关闭/关闭状态?PADDED (0x8): 负蝲需要填充,Padding Length + Data + Paddingl成?/p>
注意事项Q?- 若流标识Wؓ0x0Q接收者需要响应PROTOCOL_ERRORq接错误 - DATA帧只能在处?open" or "half closed (remote)"状态时被发送出去,否则接收端必d应一个STREAM_CLOSED的连接错误。若填充长度不小于负载长度,接收端必d应一个PROTOCOL_ERRORq接错误?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x5 (8) | 0000 ??00 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (32) | +=+=============================================================+ |Pad Length? (8)| +-+-------------+-----------------------------------------------+ |R| Promised Stream ID (31) | +-+-------------------------------------------------------------+ | Header Block Fragment (*) . . . +---------------------------------------------------------------+ | Padding (*) . . . +---------------------------------------------------------------+
服务器端通知对端初始化一个新的推送流准备E后推送数据: - 要求推送流为打开或远端半关闭Qhalf closed (remote)Q状态,否则报PROTOCOL_ERROR错误Q?- 承诺的流不一定要按照其流打开序q行使用Q仅用作E后使用 - 受对端所讄SETTINGS_ENABLE_PUSH标志位决定是否发送,否则作ؓPROTOCOL_ERROR错误对待 - 接收端一旦拒l接收推送,会发送RST_STREAM帧告知对Ҏ送无?/p>
字段列表Q?- Promised Stream IDQ?1个比特表C无W号的自然数Qؓ推送保留的标识符Q后l适用于发送推送数?- Header Block FragmentQ请求头部字D|可看做是服务器端模拟客户端发起一ơ资源请?/p>
标志位: END_HEADERSQ?x4/00000010Q,此包含完整的报头块Q不用后面跟随CONTINUATION帧了 PADDEDQ?x8/00000100Q,填充开养I军_了下面的Pad Length和Padding是否要填充,具体和HEADERS帧内容一_不多?/p>
优先UQ类型gؓ0x6Q?个字节表C。发送者测量最往q时_心蟩机制用于空闲连接是否有效?/p>
+-----------------------------------------------+ | 0x8 (24) | +---------------+---------------+---------------+ | 0x6 (8) | 0000 000? (8) | +-+-------------+---------------+-------------------------------+ |R| 0x0 (32) | +=+=============================================================+ | Opaque Data (64) | +---------------------------------------------------------------+
字段列表Q?- Opaque DataQ?个字节负载,值随意填写?/p>
标志位: * ACK(0x1)Q一旦设|,表示此PING帧ؓ接收者响应的PING帧,非发送者?/p>
注意事项Q?- PING帧发送方ACK标志位ؓ0x0Q接收方响应的PING帧ACK标志位ؓ0x1。否则直接丢弃。其优先U要高于其它cd帧?- PING帧不和具体流相关联,若流标识Wؓ0x0Q接收方需要响应PROTOCOL_ERRORcdq接错误?- 过负蝲长度Q接收者需要响应FRAME_SIZE_ERRORcdq接错误?/p>
优先UQ类型gؓ0x2Q?个字节表C。表达了发送方Ҏ优先U权重的|在流的Q何状态下都可以发送,包括I闲或关闭的?/p>
+-----------------------------------------------+ | 0x5 (24) | +---------------+---------------+---------------+ | 0x2 (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ |E| Stream Dependency (31) | +-+-------------+-----------------------------------------------+ | Weight (8) | +---------------+
字段列表Q?- EQ流是否独立 - Stream DependencyQ流依赖Qgؓ的标识W,自然也是31个比特表C?- WeightQ权?优先U,一个字节表C然数Q范?~256
注意事项Q?- PRIORITY帧其标识符?x0Q接收方需要响应PROTOCOL_ERRORcd的连接错误?- PRIORITY帧可在流的Q何状态下发送,但限制是不能够在一个包含有报头块连l的帧里面出玎ͼ其发送时刻需要,若流已经l束Q虽然可以发送,但已l没有什么效果?- 过5个字节PRIORITY帧接收方响应FRAME_SIZE_ERRORcd错误?/p>
+-----------------------------------------------+ | 0x4 (24) | +---------------+---------------+---------------+ | 0x8 (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ |R| Window Size Increment (31) | +-+-------------------------------------------------------------+
量控制帧,作用于单个流以及整个q接Q但只能影响两个端点之间传输的DATA数据帧。但需注意Q中介不转发此?/p>
字段列表Q?- Window Size IncrementQ?1个比特位无符可然数Q范围ؓ1-2^31-1Q?,147,483,647Q个字节敎ͼ表明发送者可以发送的最大字节数Q以及接收者可以接收到的最大字节数?/p>
注意事项Q?- 目前控只会影响到DATA数据?- 标识符?Q媄响整个连接,非单个流 - 标识符不ؓI,具体的标识W,只能够影响到具体流 - WINDOW_UPDATE在某个携带有END_STREAM帧的后面被发送(当前处于关闭或q程关闭状态)Q接收端可忽略,但不能作为错误对?- 发送者不能发送一个窗口值大于接收者已持有Q接收端已经拥有一个流控窗口|可用I间大小的WINDOW_UPDATE?- 当流控窗口所讄可用I间已耗尽Ӟ对端发送一个零负蝲带有END_STREAM标志位的DATA数据帧,q是允许的行?- 量控制不会计算帧头所占用?个字节空?- 若窗口值溢出,针对单独,响应RST_STREAMQ错误码FLOW_CONTROL_ERRORQQ针Ҏ个连接的Q响应GOAWAYQ错误码FLOW_CONTROL_ERRORQ - DATA数据帧的接收方在接收到数据之后Q需要计已消耗的控H口可用I间Q同时要把最新可用窗口空间发送给对端 - DATA数据帧发送方接收到WINDOW_UPDATE帧之后,获取最新可用窗口?- 接收方异步更新发送方H口|避免停?失?- 默认情况下流量控制窗口gؓ65535Q除非接收到SETTINGS帧SETTINGS_INITIAL_WINDOW_SIZE参数Q或者WINDOWS_UPDATE帧携带的H口值大,否则不会改变 - SETTINGS_INITIAL_WINDOW_SIZE值的改变会导致窗口可用空间不明晰Q易出问题,发送者必d止受控影响的DATA数据帧的发送直到接收到WINDOW_UPDATE帧获得新的窗口|才会l箋发送。egQ客L在连接徏立的瞬间一口气发送了60KB的数据,但来自服务器SETTINGS讄帧的初始H口gؓ16KBQ客L只能够等到WINDOW_UPDATE帧告知新的窗口|然后l箋发送传送剩下的44KB数据 - SETTINGS帧无法修攚wҎ个连接的量控制H口?- M端点在处理SETTINGS_INITIAL_WINDOW_SIZE值时一旦导致流控窗口D出最大|都需要作Z个FLOW_CONTROL_ERRORcdq接错误对待
优先UQ类型gؓ0x3Q?个字节表C。表达了发送方Ҏ优先U权重的|M旉M都可以发送,包括I闲或关闭的?/p>
+-----------------------------------------------+ | 0x4 (24) | +---------------+---------------+---------------+ | 0x3 (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Error Code (32) | +---------------------------------------------------------------+
字段列表Q?- Error CodeQ错误代码,32位无W号的自然数表示被关闭的错误原因?/p>
注意事项Q?- 接收到RST_STREAM帧,需要关闭对应流Q因此流也要处于关闭状态?- 接收者不能够在此上发送Q何?- 发送端需要做好准备接收接收端接收到RST_STREAM帧之前发送的帧,q个I隙的需要处理?- 若流标识Wؓ0x0Q接收方需要响应PROTOCOL_ERRORcdq接错误?- 当流处于I闲状态idle状态时是不能够发送RST_STREAM帧,否则接收方会报以PROOTOCOL_ERRORcdq接错误?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0x7 (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (32) | +=+=============================================================+ |R| Last-Stream-ID (31) | +-+-------------------------------------------------------------+ | Error Code (32) | +---------------------------------------------------------------+ | Additional Debug Data (*) | +---------------------------------------------------------------+
一端通知对端较ؓ优雅的方式停止创建流Q同时还要完成之前已建立的d?/p>
HTTP/2协议的扩展是允许存在的,在于提供额外服务。扩展包括: - 新类型Q需要遵守通用帧格?- 新的讄参数Q用于设|新帧相兛_?- 新的错误代码Q约定可能触发的错?/p>
当定义一个新帧,需要注?1. 规范新的扩展需要经q双方协商后才能使用 1. 在SETTINGS帧添加新的参数项Q可在连接序a时发送给对端Q或者适当Z发?1. 双方协商成功Q可以用新的扩?/p>
已知ALTSVC、BLOCKED属于扩展帧?/p>
服务器提供给客户端当前可用的替代服务Q类gCNAMEQ客L不支持可用选择忽略
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0xa (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (32) | +=+=============================+===============================+ | Origin-Len (16) | Origin? (*) ... +-------------------------------+-------------------------------+ | Alt-Svc-Field-Value (*) ... +---------------------------------------------------------------+
字段列表Q?- Origin-Len: 16比特位整敎ͼ说明了Origin字段字节?- Origin: ASCII字符串表C替代服?- Alt-Svc-Field-Value: 包含了Alt-Svc HTTP Header FieldQ长?Length (24) - Origin-Len (16)
需要注意: - 中介讑֤不能转发l客LQ原因就是中介自w替换处理,转发正常的业务数据给客户端就?/p>
具体可参考:https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06
一端告诉另一端因为受到流量控制的作用有数据但无法发送?/p>
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | 0xb (8) | 0x0 (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier/0x0 (32) | +=+=============================================================+
以上记录了HTTP/2帧基本结构,10个文档定义的正式帧,以及额外的两个扩展?/p>
本部分将讲解HTTP/2协议中对的定义和用,其实是在说HTTP/2是若何做到多路复用的?/p>
(StreamQ,服务器和客户端在HTTP/2q接内用于交换数据的独立双向序列,逻辑上可看做一个较为完整的交互处理单元Q即表达一ơ完整的资源h-响应数据交换程Q一个业务处理单元,在一个流内进行处理完毕,q个生命周期完l?/p>
特点如下Q?/p>
的概念提出是ؓ了实现多路复用,在单个连接上实现同时q行多个业务单元数据的传输。逻辑囑֦下:
实际传输可能是这LQ?/p>
只看到(Frame)Q没有流QStreamQ嘛?/p>
需要抽象化一些,好理解了:
q样单梳理,有些小清晰了?/p>
的概念提出Q就是ؓ了实现多路复用。媄响因素:
Ml成如下Q?/p>
搞清楚了和多\复用之间关系Q下面稍微深入一点,学习的一些细节?/p>
帧的行ؓ以及END_STREAM标志位都会对的状态的产生变化。因为流由各个端独立创徏Q没有协商,消极后果是Q两端无法匹配的的状态)D发送完毕RST_STREAM帧之?#8220;关闭”状态受限,因ؓ帧的传输和接攉要一Ҏ间?/p>
帧的状态列表:
reservedQؓ推送保留一个流E后使用
reserved (remote)Q客L接收到PUSH_PROMISE帧,本地预留的一个用于接收推送流所处于的状?/p>
不满xӞ需要报PROTOCOL_ERRORcdq接错误
half closed
half closed (remote)Q接收到包含有END_STREAM标志位的一端,进入远E半关闭状?/p>
一旦接收或发送RST_STREAM帧,将q入"closed"状态?/p>
要求如下Q?/p>
的优先U在于允许终端向对端表达所期待的给予具体流更多资源支持的意见的表达Q不能保证对端一定会遵守Q非强制性需求徏议;默认?6。在资源有限Ӟ可以保证基本数据的传输?/p>
优先U改变:
A A
/ \ ==> /|\
B C B D C
A
A |
/ \ ==> D
B C / \
B C
? ? ? ?
| / \ | |
A D A D D
/ \ / / \ / \ |
B C ==> F B C ==> F A OR A
/ \ | / \ /|\
D E E B C B C F
| | |
F E E
(intermediate) (non-exclusive) (exclusive)
多\复用会引入资源竞争,量控制可以保证之间不会严重媄响到彼此。流量控刉过使用WINDOW_UPDATE帧实玎ͼ可作用于单个以及整个的q接。一些原则如下:
需要注意事:
HTTP/2规范中所定义的流概念、属性很复杂Q在h量很大以及应Ҏv量ƈ发的情况下,整个q接的流量控?单个的量控制+的状?优先属?优先U的状?依赖树形模型等一pd新特性,可能会造成Q?/p>
HTTP/2协议在TCPq接之初q行协商通信Q只有协商成功,才会涉及到后l的h-响应{具体的业务型数据交换?/p>
针对直接建立在标准TCP之上HTTP2Q在未知服务器是否提供HTTP/2支持之前Q可以依赖现有HTTP/1.1q行试探?/p>
GET / HTTP/1. 1
Host: server. example. com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
HTTP/1. 1 200 OK
Content-Length: 243
Content-Type: text/html
. . .
服务器支持HTTP/2Q通知客户端一起切换到HTTP/2协议下吧
HTTP/1. 1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
[ HTTP/2 connection . . .
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // U字W串表示Q翻译成字节Cؓ24个字?
SETTINGS? // 其负载可能ؓI?
服务器端和客L所发送的q接序言有所不同?/li>
客户端预先知道服务器提供HTTP/2支持Q可以免?01协议切换的流E开销? 具体程Q?/p>
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // U字W串表示Q翻译成字节Cؓ24个字?
SETTINGS? // 其负载可能ؓI?
HTTP/2安全版本在TLS上构建,协商采用的ALPN扩展协议Q采?#8220;h2”作ؓ协议标识W(http版本则是“h2c”Q。一定程度上可认Z存在试探是否支持或直接连接的烦恼Q因个过E直接在TLS层协商而成?/p>
程如下Q?/p>
HTTPS协商是强Ӟ装在TLS之上ALPN扩展实现QHTTP只有非直接连接方式才会存在通过101 协议切换方式q行升?/p>
q里有一张图形象说明其流E?/p>
q里不论是HTTPq是HTTPSQ在两端成功协商之后Q或HTTP的直接连接)Q其q接q程都是一L
HTTP/2q接的徏立协商机制比HTTP/1.1E微复杂了一些?/p>
Ҏ明文版的HTTP/1.1和HTTP/2完成一ơ请?响应Q?/p>
在弱|络环境下,会不会加重网l负载,只能拭目一看了?/p>
本系列基于HTTP/2W?7个草案文档,地址是Q?a href="https://tools.ietf.org/html/draft-ietf-httpbis-http2-17?>https://tools.ietf.org/html/draft-ietf-httpbis-http2-17?/a>
HTTP/2规范已经通过发布批准Q下面等待分配具体的RFCLQ不会有所较大的变动了?/p>
本笔C是直接翻译,记录成笔记方便以后学习?/p>
一张图可以很较为全面的概括了HTTP/1.*存在~陷Q?/p>
前端一般采用: - CSS SpritingQ小囑q成大图QCSSq行分割成小图显C?- InliningQ用DataURL方式内嵌Base64~码格式囄 - JS ConcatenationQ多个JS文g合ƈ成一个,~陷是一旦有文g修改Q需要重新合q?- ShardingQ将资源/服务部v到多个机器上Q均?分nh压力
HTTP/1.*没有充分利用TCPҎ,再加上同一个站Ҏ开多个q接{,D|络资源利用率不高?/p>
与HTTP/1相比Q主要区别包括:
q里有一张图Q可以M上了解HTTP/2Q?/p>
保留/兼容HTTP/1.1的所有语义,但传输语法(或者说传输方式Q改变,目的在于更充分利用TCP更高效传输,多\复用是实现途径Q低延迟是改q方向?/p>
以上为简单M介绍了HTTP/2协议Q要x入其Ҏ,需要阅d规范。下面ؓ围绕HTTP/2规范的各个方面,列出提纲Q便于后面一一填充?/p>
以下名词会在当前或以后笔C出现Q脓出来方便理解?/p>
HTTP/2相比HTTP/1.1Q可以做到更有效的充分利用TCPq接Q避免了TCPq接的重复的创徏Q三ơ握手)、销毁(四次挥手Q的q程?/p>