的协议协商机制,创建一个非常简单的离线页面

谈谈 HTTP/2 的协议协商机制

2016/04/16 · 基础技术 ·
HTTP/2

本文作者: 伯乐在线 –
JerryQu
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

文章目录

  • HTTP Upgrade
  • ALPN 扩展
  • 小结

在过去的几个月里,我写了很多有关 HTTP/2
的文章,也做过好几场相关分享。我在向大家介绍 HTTP/2
的过程中,有一些问题经常会被问到。例如要部署 HTTP/2 一定要先升级到 HTTPS
么?升级到 HTTP/2 之后,不支持 HTTP/2
的浏览器还能正常访问么?本文重点介绍 HTTP/2
的协商机制,明白了服务端和客户端如何协商出最终使用的 HTTP
协议版本,这两个问题就迎刃而解了。

利用 Service worker 创建一个非常简单的离线页面

2016/06/07 · JavaScript
· 1 评论 · Service
Worker

本文由 伯乐在线 –
刘健超-J.c
翻译,艾凌风
校稿。未经许可,禁止转载!
英文出处:Dean
Hume。欢迎加入翻译组。

让我们想像以下情景:我们此时在一辆通往农村的火车上,用移动设备看着一篇很棒的文章。与此同时,当你点击“查看更多”的链接时,火车忽然进入了隧道,导致移动设备失去了网络,而
web 页面会呈现出类似以下的内容:

图片 1

这是相当令人沮丧的体验!幸运的是,web
开发者们能通过一些新特性来改善这类的用户体验。我最近一直在折腾 Service
Workers,它给 web 带来的无尽可能性总能给我惊喜。Service Workers
的美妙特质之一是允许你检测网络请求的状况,并让你作出相应的响应。

在这篇文章里,我打算用此特性检查用户的当前网络连接状况,如果没连接则返回一个超级简单的离线页面。尽管这是一个非常基础的案例,但它能给你带来启发,让你知道启动并运行该特性是多么的简单!如果你没了解过
Service Worker,我建议你看看此 Github
repo,了解更多相关的信息。

在该案例开始前,让我们先简单地看看它的工作流程:

  1. 在用户首次访问我们的页面时,我们会安装 Service
    Worker,并向浏览器的缓存添加我们的离线 HTML 页面
  2. 然后,如果用户打算导航到另一个 web
    页面(同一个网站下),但此时已断网,那么我们将返回已被缓存的离线
    HTML 页面
  3. 但是,如果用户打算导航到另外一个 web
    页面,而此时网络已连接,则能照常浏览页面

网页程序迁移至微信小程序web-view详解

2018/08/02 · JavaScript
· 小程序

原文出处: NeoPasser   

小程序现在越来越流行,但是公司的很多项目都是用网页写的,小程序语法不兼容原生网页,使得旧有项目迁移至小程序代价很高。

小程序之前开放了webview功能,可以说是网页应用的一大福音了,但是微信的webview有一些坑,这篇文章就是列举一下我在开发过程中遇到的一些问题以及我找到的一些解决方案。

HTTP Upgrade

为了更方便地部署新协议,HTTP/1.1 引入了 Upgrade
机制,它使得客户端和服务端之间可以借助已有的 HTTP
语法升级到其它协议。这个机制在 RFC7230 的「6.7
Upgrade」这一节中有详细描述。

要发起 HTTP/1.1 协议升级,客户端必须在请求头部中指定这两个字段:

Connection: Upgrade Upgrade: protocol-name[/protocol-version]

1
2
Connection: Upgrade
Upgrade: protocol-name[/protocol-version]

客户端通过 Upgrade
头部字段列出所希望升级到的协议和版本,多个协议之间用 ,(0x2C,
0x20)隔开。除了这两个字段之外,一般每种新协议还会要求客户端发送额外的新字段。

如果服务端不同意升级或者不支持 Upgrade
所列出的协议,直接忽略即可(当成 HTTP/1.1 请求,以 HTTP/1.1
响应);如果服务端统一升级,那么需要这样响应:

HTTP/1.1 101 Switching Protocols Connection: upgrade Upgrade:
protocol-name[/protocol-version] [… data defined by new protocol
…]

1
2
3
4
5
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: protocol-name[/protocol-version]
 
[… data defined by new protocol …]

可以看到,HTTP Upgrade 响应的状态码是
101,并且响应正文可以使用新协议定义的数据格式。

如果大家之前使用过 WebSocket,应该已经对 HTTP Upgrade
机制有所了解。下面是建立 WebSocket 连接的 HTTP 请求:

GET ws://example.com/ HTTP/1.1 Connection: Upgrade Upgrade: websocket
Origin: Sec-WebSocket-Version: 13 Sec-WebSocket-Key:
d4egt7snxxxxxx2WcaMQlA== Sec-WebSocket-Extensions: permessage-deflate;
client_max_window_bits

1
2
3
4
5
6
7
GET ws://example.com/ HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Origin: http://example.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: d4egt7snxxxxxx2WcaMQlA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

这是服务端同意升级的 HTTP 响应:

HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket
Sec-WebSocket-Accept: gczJQPmQ4Ixxxxxx6pZO8U7UbZs=

1
2
3
4
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: gczJQPmQ4Ixxxxxx6pZO8U7UbZs=

在这之后,客户端和服务端之间就可以使用 WebSocket
协议进行双向数据通讯,跟 HTTP/1.1 没关系了。可以看到,WebSocket
连接的建立就是典型的 HTTP Upgrade 机制。

显然,这个机制也可以用做 HTTP/1.1 到 HTTP/2 的协议升级。例如:

GET / HTTP/1.1 Host: example.com Connection: Upgrade, HTTP2-Settings
Upgrade: h2c HTTP2-Settings:

1
2
3
4
5
GET / HTTP/1.1
Host: example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings:

在 HTTP Upgrade 机制中,HTTP/2 的协议名称是 h2c,代表 HTTP/2
ClearText。如果服务端不支持 HTTP/2,它会忽略 Upgrade 字段,直接返回
HTTP/1.1 响应,例如:

HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html …

1
2
3
4
5
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
 

如果服务端支持 HTTP/2,那就可以回应 101
状态码及对应头部,并且在响应正文中可以直接使用 HTTP/2 二进制帧:

HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c [
HTTP/2 connection … ]

1
2
3
4
5
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
 
[ HTTP/2 connection … ]

以下是通过 HTTP Upgrade 机制将 HTTP/1.1 升级到 HTTP/2 的 Wireshark
抓包(两张图可以对照来看):

图片 2

图片 3

根据 HTTP/2 协议中的描述,额外补充几点:

  • 41 号包中,客户端发起的协议升级请求中,必须通过 HTTP2-Settings
    指定一个经过 Base64 编码过的 HTTP/2 SETTINGS 帧;
  • 45 号包中,服务端同意协议升级,响应正文中必须包含 HTTP/2 SETTING
    帧(二进制格式,不需要 Base64 编码);
  • 62 号包中,客户端可以开始发送各种 HTTP/2 帧,但第一个帧必须是 Magic
    帧(内容固定为 PRI * HTTP/2.0rnrnSMrnrn),做为协议升级的最终确认;

HTTP Upgrade
机制本身没什么问题,但很容易受网络中间环节影响。例如不能正确处理
Upgrade 头部的代理节点,很可能造成最终升级失败。之前我们统计过
WebSocket 的连通情况,发现大量明明支持 WebSocket
的浏览器却无法升级,只能使用降级方案。

让我们开始吧

假如你有以下 HTML 页面。这虽然非常基础,但能给你总体思路。

XHTML

<!DOCTYPE html>

1
<!DOCTYPE html>

接着,让我们在页面里注册 Service Worker,这里仅创建了该对象。向刚刚的
HTML 里添加以下代码。

JavaScript

<script> // Register the service worker // 注册 service worker if
(‘serviceWorker’ in navigator) {
navigator.serviceWorker.register(‘/service-worker.js’).then(function(registration)
{ // Registration was successful // 注册成功 console.log(‘ServiceWorker
registration successful with scope: ‘, registration.scope);
}).catch(function(err) { // registration failed 🙁 // 注册失败 🙁
console.log(‘ServiceWorker registration failed: ‘, err); }); }
</script>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<script>
// Register the service worker
// 注册 service worker
if (‘serviceWorker’ in navigator) {
    navigator.serviceWorker.register(‘/service-worker.js’).then(function(registration) {
    // Registration was successful
    // 注册成功
    console.log(‘ServiceWorker registration successful with scope: ‘, registration.scope);
}).catch(function(err) {
    // registration failed 🙁
    // 注册失败 🙁
    console.log(‘ServiceWorker registration failed: ‘, err);
   });
}
</script>

然后,我们需要创建 Service Worker 文件并将其命名为
‘service-worker.js‘。我们打算用这个 Service Worker
拦截全部网络请求,以此检查网络的连接性,并根据检查结果向用户返回最适合的内容。

JavaScript

‘use strict’; var cacheVersion = 1; var currentCache = { offline:
‘offline-cache’ + cacheVersion }; const offlineUrl =
‘offline-page.html’; this.addEventListener(‘install’, event => {
event.waitUntil( caches.open(currentCache.offline).then(function(cache)
{ return cache.addAll([ ‘./img/offline.svg’, offlineUrl ]); }) ); });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
‘use strict’;
 
var cacheVersion = 1;
var currentCache = {
  offline: ‘offline-cache’ + cacheVersion
};
const offlineUrl = ‘offline-page.html’;
 
this.addEventListener(‘install’, event => {
  event.waitUntil(
    caches.open(currentCache.offline).then(function(cache) {
      return cache.addAll([
          ‘./img/offline.svg’,
          offlineUrl
      ]);
    })
  );
});

在上面的代码中,我们在安装 Service Worker
时,向缓存添加了离线页面。如果我们将代码分为几小块,可看到前几行代码中,我为离线页面指定了缓存版本和URL。如果你的缓存有不同版本,那么你只需更新版本号即可简单地清除缓存。在大概在第
12
行代码,我向这个离线页面及其资源(如:图片)发出请求。在得到成功的响应后,我们将离线页面和相关资源添加到缓存。

现在,离线页面已存进缓存了,我们可在需要的时候检索它。在同一个 Service
Worker 中,我们需要对无网络时返回的离线页面添加相应的逻辑代码。

JavaScript

this.addEventListener(‘fetch’, event => { // request.mode = navigate
isn’t supported in all browsers // request.mode = naivgate
并没有得到所有浏览器的支持 // so include a check for Accept: text/html
header. // 因此对 header 的 Accept:text/html 进行核实 if
(event.request.mode === ‘navigate’ || (event.request.method === ‘GET’ &&
event.request.headers.get(‘accept’).includes(‘text/html’))) {
event.respondWith( fetch(event.request.url).catch(error => { //
Return the offline page // 返回离线页面 return caches.match(offlineUrl);
}) ); } else{ // Respond with everything else if we can //
返回任何我们能返回的东西 event.respondWith(caches.match(event.request)
.then(function (response) { return response || fetch(event.request); })
); } });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
this.addEventListener(‘fetch’, event => {
  // request.mode = navigate isn’t supported in all browsers
  // request.mode = naivgate 并没有得到所有浏览器的支持
  // so include a check for Accept: text/html header.
  // 因此对 header 的 Accept:text/html 进行核实
  if (event.request.mode === ‘navigate’ || (event.request.method === ‘GET’ && event.request.headers.get(‘accept’).includes(‘text/html’))) {
        event.respondWith(
          fetch(event.request.url).catch(error => {
              // Return the offline page
              // 返回离线页面
              return caches.match(offlineUrl);
          })
    );
  }
  else{
        // Respond with everything else if we can
        // 返回任何我们能返回的东西
        event.respondWith(caches.match(event.request)
                        .then(function (response) {
                        return response || fetch(event.request);
                    })
            );
      }
});

为了测试该功能,你可以使用 Chrome
内置的开发者工具。首先,导航到你的页面,然后一旦安装上了 Service
Worker,就打开 Network 标签并将节流(throttling)改为
Offline。(译者注:若将节流设置为 Offline
没效果,则可通过关闭网络或者通过360安全卫士禁止 Chrome 访问网络)

图片 4

如果你刷新页面,你应该能看到相应的离线页面!

图片 5

如果你只想简单地测试该功能而不想写任何代码,那么你可以访问我已创建好的
demo。另外,上述全部代码可以在
Github repo 找到。

我知道用在此案例中的页面很简单,但你的离线页面则取决于你自己!如果你想深入该案例的内容,你可以为离线页面添加缓存破坏(
cache busting),如:
此案例。

遇到的问题

  1. openid登录问题
  2. webview动态src
  3. 支付功能
  4. 分享功能
  5. 扫描普通二维码跳转特定页面
  6. 返回按钮缺失问题

ALPN 扩展

HTTP/2 协议本身并没有要求它必须基于
HTTPS(TLS)部署,但是出于以下三个原因,实际使用中,HTTP/2 和 HTTPS
几乎都是捆绑在一起:

  • HTTP 数据明文传输,数据很容易被中间节点窥视或篡改,HTTPS
    可以保证数据传输的保密性、完整性和不被冒充;
  • 正因为 HTTPS 传输的数据对中间节点保密,所以它具有更好的连通性。基于
    HTTPS 部署的新协议具有更高的连接成功率;
  • 当前主流浏览器,都只支持基于 HTTPS 部署的 HTTP/2;

如果前面两个原因还不足以说服你,最后这个绝对有说服力,除非你的 HTTP/2
服务只打算给自己客户端用。

下面介绍在 HTTPS 中,浏览器和服务端之间怎样协商是否使用 HTTP/2。

基于 HTTPS 的协议协商非常简单,多了 TLS 之后,双方必须等到成功建立 TLS
连接之后才能发送应用数据。而要建立 TLS 连接,本来就要进行 CipherSuite
等参数的协商。引入 HTTP/2 之后,需要做的只是在原本的协商机制中把对 HTTP
协议的协商加进去。

Google 在 SPDY 协议中开发了一个名为 NPN(Next Protocol
Negotiation,下一代协议协商)的 TLS 扩展。随着 SPDY 被 HTTP/2 取代,NPN
也被官方修订为 ALPN(Application Layer Protocol
Negotiation,应用层协议协商)。二者的目标和实现原理基本一致,这里只介绍后者。如图:

图片 6

可以看到,客户端在建立 TLS 连接的 Client Hello 握手中,通过 ALPN
扩展列出了自己支持的各种应用层协议。其中,HTTP/2 协议名称是 h2

图片 7

如果服务端支持 HTTP/2,在 Server Hello 中指定 ALPN 的结果为 h2
就可以了;如果服务端不支持 HTTP/2,从客户端的 ALPN
列表中选一个自己支持的即可。

并不是所有 HTTP/2 客户端都支持 ALPN,理论上建立 TLS
连接后,依然可以再通过 HTTP Upgrade
进行协议升级,只是这样会额外引入一次往返。

拓展阅读

此外,还有几个很棒的离线功能案例。如:Guardian 构建了一个拥有 crossword
puzzle(填字游戏)的离线
web 页面 –
因此,即使等待网络重连时(即已在离线状态下),也能找到一点乐趣。我也推荐看看
Google Chrome Github
repo,它包含了很多不同的
Service Worker 案例 – 其中一些应用案例也在这!

然而,如果你想跳过上述代码,只是想简单地通过一个库来处理相关操作,那么我推荐你看看
UpUp。这是一个轻量的脚本,能让你更轻松地使用离线功能。

打赏支持我翻译更多好文章,谢谢!

打赏译者

openid登录问题

微信webview的使用方法很简单,只要如下设置src就可以展示具体的网站了。

<!– wxml –> <!– 指向微信公众平台首页的web-view –>
<web-view src=”;

1
2
3
<!– wxml –>
<!– 指向微信公众平台首页的web-view –>
<web-view src="https://mp.weixin.qq.com/"></web-view>

微信环境里的很多网页都是用页面要实现网站的登录功能,只要把登录的信息,比如openid或者其他信息拼接到src里就好了。

这里有个问题,公众号的账号体系一般是以openid来判断唯一性的,小程序是可以获取openid的,但是小程序的openid和原公众号之类的openid是不一样的,需要将原先的openid账号体系升级为unionid账号体系。

以下是微信对unionid的介绍

获取用户基本信息(UnionID机制)

在关注者与公众号产生消息交互后,公众号可获得关注者的OpenID(加密后的微信号,每个用户对每个公众号的OpenID是唯一的。对于不同公众号,同一用户的openid不同)。公众号可通过本接口来根据OpenID获取用户基本信息,包括昵称、头像、性别、所在城市、语言和关注时间。

请注意,如果开发者有在多个公众号,或在公众号、移动应用之间统一用户帐号的需求,需要前往微信开放平台(open.weixin.qq.com)绑定公众号后,才可利用UnionID机制来满足上述需求。

UnionID机制说明:

开发者可通过OpenID来获取用户基本信息。特别需要注意的是,如果开发者拥有多个移动应用、网站应用和公众帐号,可通过获取用户基本信息中的unionid来区分用户的唯一性,因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号,用户的unionid是唯一的。换句话说,同一用户,对同一个微信开放平台下的不同应用,unionid是相同的。

做完以上步骤,就可以调用小程序api wx.getUserInfo()
来获取用户信息了,此步骤需要进行后台信息解密过程,在此就不再赘述,结合小程序api文档操作就好。

获取到unioid之后,将unionid信息拼接到src就可以进行网页登录操作了(前提是网页可以用跳转链接的方式登录,类似公众号页面获取openid的形式)。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

标签:, ,

相关文章

网站地图xml地图