2014年9月25日星期四

阮一峰的网络日志

阮一峰的网络日志


SSL延迟有多大?

Posted: 24 Sep 2014 06:59 AM PDT

据说,Netscape公司当年设计SSL协议的时候,有人提过,将互联网所有链接都变成HTTPs开头的加密链接。

这个建议没有得到采纳,原因之一是HTTPs链接比不加密的HTTP链接慢很多。(另一个原因好像是,HTTPs链接默认不能缓存。)

自从我知道这个掌故以后,脑袋中就有一个观念:HTTPs链接很慢。但是,它到底有多慢,我并没有一个精确的概念。直到今天我从一篇文章中,学到了测量HTTPs链接耗时的方法。

slow connection

首先我解释一下,为什么HTTPs链接比较慢。

HTTPs链接和HTTP链接都建立在TCP协议之上。HTTP链接比较单纯,使用三个握手数据包建立连接之后,就可以发送内容数据了。

tcp handshake

上图中,客户端首先发送SYN数据包,然后服务器发送SYN+ACK数据包,最后客户端发送ACK数据包,接下来就可以发送内容了。这三个数据包的发送过程,叫做TCP握手。

再来看HTTPs链接,它也采用TCP协议发送数据,所以它也需要上面的这三步握手过程。而且,在这三步结束以后,它还有一个SSL握手

总结一下,就是下面这两个式子。

HTTP耗时 = TCP握手

HTTPs耗时 = TCP握手 + SSL握手

所以,HTTPs肯定比HTTP耗时,这就叫SSL延迟。

命令行工具curl有一个w参数,可以用来测量TCP握手和SSL握手的具体耗时,以访问支付宝为例。

    $ curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://www.alipay.com    TCP handshake: 0.022, SSL handshake: 0.064    

上面命令中的w参数表示指定输出格式,time_connect变量表示TCP握手的耗时,time_appconnect变量表示SSL握手的耗时(更多变量请查看文档实例),s参数和o参数用来关闭标准输出。

从运行结果可以看到,SSL握手的耗时(64毫秒)大概是TCP握手(22毫秒)的三倍。也就是说,在建立连接的阶段,HTTPs链接比HTTP链接要长3倍的时间,具体数字取决于CPU的快慢和网络状况。

所以,如果是对安全性要求不高的场合,为了提高网页性能,建议不要采用保密强度很高的数字证书。一般场合下,1024位的证书已经足够了,2048位和4096位的证书将进一步延长SSL握手的耗时。

(完)

文档信息

2014年9月20日星期六

阮一峰的网络日志

阮一峰的网络日志


图解SSL/TLS协议

Posted: 20 Sep 2014 03:33 AM PDT

本周,CloudFlare宣布,开始提供Keyless服务,即你把网站放到它们的CDN上,不用提供自己的私钥,也能使用SSL加密链接。

CloudFlare

我看了CloudFlare的说明(这里这里),突然意识到这是绝好的例子,可以用来说明SSL/TLS协议的运行机制。它配有插图,很容易看懂。

下面,我就用这些图片作为例子,配合我半年前写的《SSL/TLS协议运行机制的概述》,来解释SSL协议。

一、SSL协议的握手过程

开始加密通信之前,客户端和服务器首先必须建立连接和交换参数,这个过程叫做握手(handshake)。

假定客户端叫做爱丽丝,服务器叫做鲍勃,整个握手过程可以用下图说明(点击看大图)。

握手阶段分成五步。

第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

第三步,爱丽丝确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给鲍勃。

第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。

第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。

上面的五步,画成一张图,就是下面这样。

二、私钥的作用

握手阶段有三点需要注意。

(1)生成对话密钥一共需要三个随机数。

(2)握手之后的对话使用"对话密钥"加密(对称加密),服务器的公钥和私钥只用于加密和解密"对话密钥"(非对称加密),无其他作用。

(3)服务器公钥放在服务器的数字证书之中。

从上面第二点可知,整个对话过程中(握手阶段和其后的对话),服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。

某些客户(比如银行)想要使用外部CDN,加快自家网站的访问速度,但是出于安全考虑,不能把私钥交给CDN服务商。这时,完全可以把私钥留在自家服务器,只用来解密对话密钥,其他步骤都让CDN服务商去完成。

上图中,银行的服务器只参与第四步,后面的对话都不再会用到私钥了。

三、DH算法的握手阶段

整个握手阶段都不加密(也没法加密),都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,我们可以考虑把握手阶段的算法从默认的RSA算法,改为 Diffie-Hellman算法(简称DH算法)。

采用DH算法后,Premaster secret不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

上图中,第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数,然后双方各自算出Premaster secret。这样就提高了安全性。

四、session的恢复

握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。

这时有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket。

session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。

上图中,客户端给出session ID,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信。

session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。

上图中,客户端不再发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

(完)

文档信息

2014年9月14日星期日

阮一峰的网络日志

阮一峰的网络日志


前端模块管理器简介

Posted: 13 Sep 2014 07:13 PM PDT

模块化结构已经成为网站开发的主流。

制作网站的主要工作,不再是自己编写各种功能,而是如何将各种不同的模块组合在一起。

模块化结构

浏览器本身并不提供模块管理的机制,为了调用各个模块,有时不得不在网页中,加入一大堆script标签。这样就使得网页体积臃肿,难以维护,还产生大量的HTTP请求,拖慢显示速度,影响用户体验。

为了解决这个问题,前端的模块管理器(package management)应运而生。它可以轻松管理各种JavaScript脚本的依赖关系,自动加载各个模块,使得网页结构清晰合理。不夸张地说,将来所有的前端JavaScript项目,应该都会采用这种方式开发。

最早也是最有名的前端模块管理器,非RequireJS莫属。它采用AMD格式,异步加载各种模块。具体的用法,可以参考我写的教程。Require.js的问题在于各种参数设置过于繁琐,不容易学习,很难完全掌握。而且,实际应用中,往往还需要在服务器端,将所有模块合并后,再统一加载,这多出了很多工作量。

RequireJS

今天,我介绍另外四种前端模块管理器:BowerBrowserifyComponentDuo。它们各自都有鲜明的特点,很好地弥补了Require.js的缺陷,是前端开发的利器。

需要说明的是,这篇文章并不是这四种模块管理器的教程。我只是想用最简单的例子,说明它们是干什么用的,使得读者有一个大致的印象,知道某一种工作有特定的工具可以完成。详细的用法,还需要参考它们各自的文档。

Bower

Bower

Bower的主要作用是,为模块的安装、升级和删除,提供一种统一的、可维护的管理模式。

首先,安装Bower。

   $ npm install -g bower 

然后,使用bower install命令安装各种模块。下面是一些例子。

   # 模块的名称   $ bower install jquery   # github用户名/项目名   $ bower install jquery/jquery   # git代码仓库地址   $ bower install git://github.com/user/package.git   # 模块网址   $ bower install http://example.com/script.js 

所谓"安装",就是将该模块(以及其依赖的模块)下载到当前目录的bower_components子目录中。下载后,就可以直接插入网页。

   <script src="/bower_componets/jquery/dist/jquery.min.js"> 

bower update命令用于更新模块。

   $ bower update jquery 

如果不给出模块的名称,则更新所有模块。

bower uninstall命令用于卸载模块。

   $ bower uninstall jquery 

注意,默认情况下,会连所依赖的模块一起卸载。比如,如果卸载jquery-ui,会连jquery一起卸载,除非还有别的模块依赖jquery。

Browserify

Browserify

Browserify本身不是模块管理器,只是让服务器端的CommonJS格式的模块可以运行在浏览器端。这意味着通过它,我们可以使用Node.js的npm模块管理器。所以,实际上,它等于间接为浏览器提供了npm的功能。

首先,安装Browserify。

   $ npm install -g browserify 

然后,编写一个服务器端脚本。

   var uniq = require('uniq');   var nums = [ 5, 2, 1, 3, 2, 5, 4, 2, 0, 1 ];   console.log(uniq(nums)); 

上面代码中uniq模块是CommonJS格式,无法在浏览器中运行。这时,Browserify就登场了,将上面代码编译为浏览器脚本。

   $ browserify robot.js > bundle.js 

生成的bundle.js可以直接插入网页。

   <script src="bundle.js"></script> 

Browserify编译的时候,会将脚本所依赖的模块一起编译进去。这意味着,它可以将多个模块合并成一个文件。

Component

Component

Component是Express框架的作者TJ Holowaychuk开发的模块管理器。它的基本思想,是将网页所需要的各种资源(脚本、样式表、图片、字体等)编译后,放到同一个目录中(默认是build目录)。

首先,安装Component。

   $ npm install -g component@1.0.0-rc5 

上面代码之所以需要指定Component的版本,是因为1.0版还没有正式发布。

然后,在项目根目录下,新建一个index.html。

   <!DOCTYPE html>   <html>     <head>       <title>Getting Started with Component</title>       <link rel="stylesheet" href="build/build.css">     </head>     <body>       <h1>Getting Started with Component</h1>       <p class="blink">Woo!</p>       <script src="build/build.js"></script>     </body>   </html> 

上面代码中的build.css和build.js,就是Component所要生成的目标文件。

接着,在项目根目录下,新建一个component.json文件,作为项目的配置文件。

   {     "name": "getting-started-with-component",     "dependencies": {       "necolas/normalize.css": "^3.0.0"     },     "scripts": ["index.js"],     "styles": ["index.css"]   } 

上面代码中,指定JavaScript脚本和样式表的原始文件是index.js和index.css两个文件,并且样式表依赖normalize模块(不低于3.0.0版本,但不高于4.0版本)。这里需要注意,Component模块的格式是"github用户名/项目名"。

最后,运行component build命令编译文件。

   $ component build      installed : necolas/normalize.css@3.0.1 in 267ms          build : resolved in 1221ms          build : files in 12ms          build : build/build.js in 76ms - 1kb          build : build/build.css in 80ms - 7kb 

在编译的时候,Component自动使用autoprefixer为CSS属性加上浏览器前缀。

目前,Component似乎处于停止开发的状态,代码仓库已经将近半年没有变动过了,官方也推荐优先使用接下来介绍的Duo。

Duo

Duo

Duo是在Component的基础上开发的,语法和配置文件基本通用,并且借鉴了Browserify和Go语言的一些特点,相当地强大和好用。

首先,安装Duo。

   $ npm install -g duo 

然后,编写一个本地文件index.js。

   var uid = require('matthewmueller/uid');   var fmt = require('yields/fmt');      var msg = fmt('Your unique ID is %s!', uid());   window.alert(msg); 

上面代码加载了uid和fmt两个模块,采用Component的"github用户名/项目名"格式。

接着,编译最终的脚本文件。

   $ duo index.js > build.js 

编译后的文件可以直接插入网页。

   <script src="build.js"></script> 

Duo不仅可以编译JavaScript,还可以编译CSS。

   @import 'necolas/normalize.css';   @import './layout/layout.css';      body {     color: teal;     background: url('./background-image.jpg');   } 

编译时,Duo自动将normalize.css和layout.css,与当前样式表合并成同一个文件。

   $ duo index.css > build.css 

编译后,插入网页即可。

   <link rel="stylesheet" href="build.css"> 

(完)

文档信息

2014年9月8日星期一

阮一峰的网络日志

阮一峰的网络日志


数据压缩与信息熵

Posted: 07 Sep 2014 05:17 AM PDT

1992年,美国佐治亚州的WEB Technology公司,宣布做出了重大的技术突破。

该公司的DataFiles/16软件,号称可以将任意大于64KB的文件,压缩为原始大小的16分之一。业界议论纷纷,如果消息属实,无异于压缩技术的革命。

数据压缩

许多专家还没有看到软件,就断言这是不可能的。因为根据压缩原理,你不可能将任意文件压缩到16分之一。事实上,有一些文件是无法压缩的,哪怕一个二进制位,都压缩不掉。

后来,事实果然如此,这款软件从来没有正式发布。没过几年,就连WEB Technology公司都消失了。

那么,为何不是所有的文件都可以被压缩?是否存在一个压缩极限呢,也就是说,到了一定大小,就没法再压缩了?

一、压缩的有限性

首先,回答第一个问题:为什么WEB Technology公司的发明不可能是真的。

反证法可以轻易地证明这一点。假定任何文件都可以压缩到n个二进制位(bit)以内,那么最多有2n种不同的压缩结果。也就是说,如果有2n+1个文件,必然至少有两个文件会产生同样的压缩结果。这意味着,这两个文件不可能无损地还原(解压缩)。因此,得到证明,并非所有文件都可以压缩到n个二进制位以下。

很自然地,下一个问题就是,这个n到底是多少?

二、压缩原理

要回答一个文件最小可以压缩到多少,必须要知道压缩的原理。

压缩原理其实很简单,就是找出那些重复出现的字符串,然后用更短的符号代替,从而达到缩短字符串的目的。比如,有一篇文章大量使用"中华人民共和国"这个词语,我们用"中国"代替,就缩短了5个字符,如果用"华"代替,就缩短了6个字符。事实上,只要保证对应关系,可以用任意字符代替那些重复出现的字符串。

本质上,所谓"压缩"就是找出文件内容的概率分布,将那些出现概率高的部分代替成更短的形式。所以,内容越是重复的文件,就可以压缩地越小。比如,"ABABABABABABAB"可以压缩成"7AB"。

相应地,如果内容毫无重复,就很难压缩。极端情况就是,遇到那些均匀分布的随机字符串,往往连一个字符都压缩不了。比如,任意排列的10个阿拉伯数字(5271839406),就是无法压缩的;再比如,无理数(比如π)也很难压缩。

压缩就是一个消除冗余的过程,相当于用一种更精简的形式,表达相同的内容。可以想象,压缩过一次以后,文件中的重复字符串将大幅减少。好的压缩算法,可以将冗余降到最低,以至于再也没有办法进一步压缩。所以,压缩已经压缩过的文件(递归压缩),通常是没有意义的。

三、压缩的极限

知道了压缩原理之后,就可以计算压缩的极限了。

上一节说过,压缩可以分解成两个步骤。第一步是得到文件内容的概率分布,哪些部分出现的次数多,哪些部分出现的次数少;第二步是对文件进行编码,用较短的符号替代那些重复出现的部分。

第一步的概率分布一般是确定的,现在就来考虑第二步,怎样找到最短的符号作为替代符。

如果文件内容只有两种情况(比如扔硬币的结果),那么只要一个二进制位就够了,1表示正面,0表示表示负面。如果文件内容包含三种情况(比如球赛的结果),那么最少需要两个二进制位。如果文件内容包含六种情况(比如扔筛子的结果),那么最少需要三个二进制位。

一般来说,在均匀分布的情况下,假定一个字符(或字符串)在文件中出现的概率是p,那么在这个位置上最多可能出现1/p种情况。需要log2(1/p)个二进制位表示替代符号。

这个结论可以推广到一般情况。假定文件有n个部分组成,每个部分的内容在文件中的出现概率分别为p1、p2、...pn。那么,替代符号占据的二进制最少为下面这个式子。

log2(1/p1) + log2(1/p2) + ... + log2(1/pn)

= ∑ log2(1/pn)

这可以被看作一个文件的压缩极限。

四、信息熵的公式

上一节的公式给出了文件压缩的极限。对于n相等的两个文件,概率p决定了这个式子的大小。p越大,表明文件内容越有规律,压缩后的体积就越小;p越小,表明文件内容越随机,压缩后的体积就越大。

为了便于文件之间的比较,将上式除以n,可以得到平均每个符号所占用的二进制位。

∑ log2(1/pn) / n

= log2(1/p1)/n + log2(1/p2)/n + ... + log2(1/pn)/n

由于p是根据频率统计得到的,因此上面的公式等价于下面的形式。

p1*log2(1/p1) + p2*log2(1/p2) + ... + pn*log2(1/pn)

= ∑ pn*log2(1/pn)

= E( log2(1/p) )

上面式子中最后的E,表示数学期望。可以理解成,每个符号所占用的二进制位,等于概率倒数的对数的数学期望。

下面是一个例子。假定有两个文件都包含1024个符号,在ASCII码的情况下,它们的长度是相等的,都是1KB。甲文件的内容50%是a,30%b,20%是c,则平均每个符号要占用1.49个二进制位。

0.5*log2(1/0.5) + 0.3*log2(1/0.3) + 0.2*log2(1/0.2)

= 1.49

既然每个符号要占用1.49个二进制位,那么压缩1024个符号,理论上最少需要1526个二进制位,约0.186KB,相当于压缩掉了81%的体积。

乙文件的内容10%是a,10%是b,......,10%是j,则平均每个符号要占用3.32个二进制位。

0.1*log2(1/0.1)*10

= 3.32

既然每个符号要占用3.32个二进制位,那么压缩1024个符号,理论上最少需要3400个二进制位,约0.415KB,相当于压缩掉了58%的体积。

对比上面两个算式,可以看到文件内容越是分散(随机),所需要的二进制位就越长。所以,这个值可以用来衡量文件内容的随机性(又称不确定性)。这就叫做信息熵(information entropy)。

它是1948年由美国数学家克劳德·香农(Claude Shannon)在经典论文《通信的数学理论》中,首先提出的。

Claude Shannon

五、信息熵的含义

想要理解信息熵这个概念,有几点需要注意。

(1)信息熵只反映内容的随机性,与内容本身无关。不管是什么样内容的文件,只要服从同样的概率分布,就会计算得到同样的信息熵。

(2)信息熵越大,表示占用的二进制位越长,因此就可以表达更多的符号。所以,人们有时也说,信息熵越大,表示信息量越大。不过,由于第一点的原因,这种说法很容易产生误导。较大的信息熵,只表示可能出现的符号较多,并不意味着你可以从中得到更多的信息。

(3)信息熵与热力学的熵,基本无关。这两个熵不是同一件事,信息熵表示无序的信息,热力学的熵表示无序的能量(参见我写的《熵的社会学意义》)。

(文章完)

=====================================================

以下为广告部分。欢迎大家在我的网络日志投放广告,推广自己的产品。今天介绍的是生命链记忆网

[赞助商广告]

别人的终究是别人的,今天我们书写自己的传奇!个人史是汇入正史河流的涓涓细流。

生命链记忆网是永远在线的个人史馆,是永恒的信息载体,永久保留每个人的人生记忆和生命轨迹直至千秋万代。

花一分钟成为注册用户,就可以使用两大基本功能:生命链生命之书

(1)生命链就是你的根,你可以邀请祖先(父系和母系)及子女合链,让自己的生命链有形化、可视化;所有血亲和姻亲成员之间可互动。

图1

(2)生命之书就是书写你的人生故事,包括日记、自传、随笔等等;自传可选择公开,在自传馆里能被所有人看到。

图2

生命链功能永久免费!

生命之书功能每年付费10元,可使用100M空间(免费试用6个月);累计付费1000元,生命之书永久开启。

永恒之旅,从此开始,点击试用

(完)

文档信息