分类 技术 下的文章

前一篇的指导教程中,我们看到了读、写以及重放音频文件的简单步骤,我们甚至看到如何从一个周期函数比如余弦函数合成一个音频文件。在这篇指导教程中,我们将会看到如何对信号进行叠加和倍乘(调整),并应用一些基本的数学函数看看它们对原始信号的影响。

信号叠加

两个信号 S1(t)和 S2(t)相加形成一个新的信号 R(t),这个信号在任何瞬间的值等于构成它的两个信号在那个时刻的值之和。就像下面这样:

R(t) = S1(t) + S2(t)

我们将用 Octave 重新产生两个信号的和并通过图表看达到的效果。首先,我们生成两个不同频率的信号,看一看它们的叠加信号是什么样的。

第一步:产生两个不同频率的信号(oog 文件)

>> sig1='cos440.ogg';                  %creating the audio file @440 Hz
>> sig2='cos880.ogg';                  %creating the audio file @880 Hz
>> fs=44100;                           %generating the parameters values (Period, sampling frequency and angular frequency)
>> t=0:1/fs:0.02;
>> w1=2*pi*440*t;
>> w2=2*pi*880*t;
>> audiowrite(sig1,cos(w1),fs);        %writing the function cos(w) on the files created
>> audiowrite(sig2,cos(w2),fs);

然后我们绘制出两个信号的图像。

信号 1 的图像(440 赫兹)

>> [y1, fs] = audioread(sig1);
>> plot(y1)

信号 1 的图像

信号 2 的图像(880 赫兹)

>> [y2, fs] = audioread(sig2);
>> plot(y2)

信号 2 的图像

第二步:把两个信号叠加

现在我们展示一下前面步骤中产生的两个信号的和。

>> sumres=y1+y2;
>> plot(sumres)

叠加信号的图像

和信号的图像

Octaver 中的效果

在 Octaver 中,这个效果产生的声音是独特的,因为它可以仿真音乐家弹奏的低八度或者高八度音符(取决于内部程序设计),仿真音符和原始音符成对,也就是两个音符发出相同的声音。

第三步:把两个真实的信号相加(比如两首音乐歌曲)

为了实现这个目的,我们使用 格列高利圣咏 Gregorian Chants 中的两首歌曲(声音采样)。

圣母颂曲 Avemaria Track

首先,我们看一下圣母颂曲并绘出它的图像:

>> [y1,fs]=audioread('avemaria_.ogg');
>> plot(y1)

圣母歌曲

赞美诗曲 Hymnus Track

现在我们看一下赞美诗曲并绘出它的图像。

>> [y2,fs]=audioread('hymnus.ogg');
>> plot(y2)

赞美诗曲

圣母颂曲 + 赞美诗曲

>> y='avehymnus.ogg';
>> audiowrite(y, y1+y2, fs);
>> [y, fs]=audioread('avehymnus.ogg');
>> plot(y)

圣母歌曲 + 赞美诗曲

结果,从音频的角度来看,两个声音信号混合在了一起。

两个信号的乘积

对于求两个信号的乘积,我们可以使用类似求和的方法。我们使用之前生成的相同文件。

R(t) = S1(t) * S2(t)
>> sig1='cos440.ogg';                  %creating the audio file @440 Hz
>> sig2='cos880.ogg';                  %creating the audio file @880 Hz
>> product='prod.ogg';                 %creating the audio file for product
>> fs=44100;                           %generating the parameters values (Period, sampling frequency and angular frequency)
>> t=0:1/fs:0.02;
>> w1=2*pi*440*t;
>> w2=2*pi*880*t;
>> audiowrite(sig1, cos(w1), fs);      %writing the function cos(w) on the files created
>> audiowrite(sig2, cos(w2), fs);>> [y1,fs]=audioread(sig1);>> [y2,fs]=audioread(sig2);
>> audiowrite(product, y1.*y2, fs);    %performing the product
>> [yprod,fs]=audioread(product);
>> plot(yprod);                        %plotting the product

注意:我们必须使用操作符 ‘.*’,因为在参数文件中,这个乘积是值与值相乘。更多信息,请参考 Octave 矩阵操作产品手册。

乘积生成信号的图像

乘积信号的图像

两个基本频率相差很大的信号相乘后的图表效果(调制原理)

第一步:

生成两个频率为 220 赫兹的声音信号。

>> fs=44100;
>> t=0:1/fs:0.03;
>> w=2*pi*220*t;
>> y1=cos(w);
>> plot(y1);

载波

第二步:

生成一个 22000 赫兹的高频调制信号。

>> y2=cos(100*w);
>> plot(y2);

调制中

第三步:

把两个信号相乘并绘出图像。

>> plot(y1.*y2);

调制后的信号

一个信号和一个标量相乘

一个函数和一个标量相乘的效果等于更改它的值域,在某些情况下,更改的是相标志。给定一个标量 K ,一个函数 F(t) 和这个标量相乘定义为:

R(t) = K*F(t)
>> [y,fs]=audioread('cos440.ogg');        %creating the work files
>> res1='coslow.ogg';                
>> res2='coshigh.ogg';>> res3='cosinverted.ogg';
>> K1=0.2;                                %values of the scalars
>> K2=0.5;>> K3=-1;
>> audiowrite(res1, K1*y, fs);            %product function-scalar
>> audiowrite(res2, K2*y, fs);
>> audiowrite(res3, K3*y, fs);

原始信号的图像

>> plot(y)

信号振幅减为原始信号振幅的 0.2 倍后的图像

>> plot(res1)

低余弦

信号振幅减为原始振幅的 0.5 倍后的图像

>> plot(res2)

高余弦

倒相后的信号图像

>> plot(res3)

倒相余弦

结论

基本数学运算比如代数和、乘,以及函数与常量相乘是更多高级运算比如谱分析、振幅调制,角调制等的支柱和基础。在下一个教程中,我们来看一看如何进行这样的运算以及它们对声音文件产生的效果。


via: https://www.howtoforge.com/tutorial/octave-audio-signal-processing-ubuntu/

作者:David Duarte 译者:ucasFL 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Shinken 是一个用 Python 实现的开源的主机和网络监控框架,并与 Nagios like 兼容,它可以运行在所有支持 Python 程序的操作系统上,比如说 Linux、Unix 和 Windows。Shinken 是 Jean Gabes 为了验证一个新的 Nagios 架构思路而编写,但是这个想法被 Nagios 的作者拒绝后成为了一个独立的网络系统监视软件,并保持了与 Nagios 的兼容。

在这篇教程中,我将会描述如何从源代码编译安装 Shinken 和向监视系统中添加一台 Linux 主机。我将会以 Ubuntu 16.04 Xenial Xerus 操作系统来作为 Shinken 服务器和所监控的主机。

第一步 安装 Shinken 服务器

Shinken 是一个 Python 框架,我们可以通过 pip 安装或者从源码来安装它,在这一步中,我们将用源代码编译安装 Shinken。

在我们开始安装 Shinken 之前还需要完成几个步骤。

安装一些新的 Python 软件包并创建一个名为 shinken 的系统用户:

sudo apt-get install python-setuptools python-pip python-pycurl
useradd -m -s /bin/bash shinken

从 GitHub 仓库下载 Shinken 源代码:

git clone https://github.com/naparuba/shinken.git
cd shinken/

然后用以下命令安装 Shinken:

git checkout 2.4.3
python setup.py install

然后,为了得到更好的效果,我们还需要从 Ubuntu 软件库中安装 python-cherrypy3 软件包:

sudo apt-get install python-cherrypy3

到这里,Shinken 已经成功安装,接下来我们将 Shinken 添加到系统启动项并且启动它:

update-rc.d shinken defaults
systemctl start shinken

第二步 安装 Shinken Webui2

Webui2 是 Shinken 的 Web 界面(在 shinken.io 可以找到)。最简单的安装 Shinken webui2 的方法是使用shinken CLI 命令(必须作为 shinken 用户执行)。

切换到 shinken 用户:

su - shinken

初始化 shiken 配置文件,下面的命令将会创建一个新的配置文件 .shinken.ini

shinken --init

接下来用 shinken CLI 命令来安装 webui2

shinken install webui2

至此 webui2 已经安装好,但是我们还需要安装 MongoDB 和用 pip 来安装另一个 Python 软件包。在 root 下运行如下命令:

sudo apt-get install mongodb
pip install pymongo>=3.0.3 requests arrow bottle==0.12.8

接下来,切换到 shinken 目录下并且通过编辑 broker-master.cfg 文件来添加这个新的 webui2 模块:

cd /etc/shinken/brokers/
vim broker-master.cfg

在第 40 行添加一个模块选项:

modules     webui2

保存文件并且退出编辑器。

现在进入 contacts 目录下编辑 admin.cfg 来进行管理配置。

cd /etc/shinken/contacts/
vim admin.cfg

按照如下修改:

contact_name    admin       # Username 'admin'
password        yourpass    # Pass 'mypass'

保存和退出。

第三步 安装 Nagios 插件和 Shinken 软件包

在这一步中,我们将安装 Nagios 插件和一些 Perl 模块。然后从 shinken.io 安装其他的软件包来实现监视。

安装 Nagios 插件和安装 Perl 模块所需要的 cpanminus

sudo apt-get install nagios-plugins* cpanminus

cpanm 命令来安装 Perl 模块。

cpanm Net::SNMP
cpanm Time::HiRes
cpanm DBI

现在我们创建一个 utils.pm 文件的链接到 shinken 的目录,并且为 Log_File_Health 创建了一个新的日志目录 。

chmod u+s /usr/lib/nagios/plugins/check_icmp
ln -s /usr/lib/nagios/plugins/utils.pm /var/lib/shinken/libexec/
mkdir -p /var/log/rhosts/
touch /var/log/rhosts/remote-hosts.log

然后,从 shinken.io 安装 shinken 软件包 sshlinux-snmp 来监视 SSH 和 SNMP :

su - shinken
shinken install ssh
shinken install linux-snmp

第四步 添加一个 Linux 主机 host-one

我们将添加一个新的将被监控的 Linux 主机,IP 地址为 192.168.1.121,主机名为 host-one 的 Ubuntu 16.04。

连接到 host-one 主机:

ssh [email protected]

从 Ubuntu 软件库中安装 snmp 和snmpd 软件包:

sudo apt-get install snmp snmpd

然后,用 vim 编辑 snmpd.conf 配置文件:

vim /etc/snmp/snmpd.conf

注释掉第 15 行并取消注释第 17 行:

#agentAddress  udp:127.0.0.1:161
agentAddress udp:161,udp6:[::1]:161

注释掉第 51 和 53 行,然后加一行新的配置,如下:

#rocommunity mypass  default    -V systemonly
#rocommunity6 mypass  default   -V systemonly

rocommunity mypass

保存并退出。

现在用 systemctl 命令来启动 snmpd 服务:

systemctl start snmpd

在 shinken 服务器上通过在 hosts 文件夹下创建新的文件来定义一个新的主机:

cd /etc/shinken/hosts/
vim host-one.cfg

粘贴如下配置信息:

define host{
        use                 generic-host,linux-snmp,ssh
        contact_groups      admins
        host_name           host-one
        address             192.168.1.121
        _SNMPCOMMUNITY      mypass        # SNMP Pass Config on snmpd.conf
    }

保存并退出。

在 shinken 服务器上编辑 SNMP 配置文件。

vim /etc/shinken/resource.d/snmp.cfg

public 改为 mypass -必须和你在客户端 snmpd 配置文件中使用的密码相同:

$SNMPCOMMUNITYREAD$=mypass

保存并退出。

现在将服务端和客户端都重启:

reboot

现在 Linux 主机已经被成功地添加到 shinken 服务器中了。

第五步 访问 Shinken Webui2

在端口 7677 访问 Shinken webui2 (将 URL 中的 IP 替换成你自己的 IP 地址):

http://192.168.1.120:7767

用管理员用户和密码登录(你在 admin.cfg 文件中设置的)

Webui2 中的 Shinken 面板:

我们的两个服务器正在被 Shinken 监控:

列出所有被 linux-snmp 监控的服务:

所有主机和服务的状态信息:

第6步 Shinken 的常见问题

NTP 服务器相关的问题

当你得到如下的 NTP 错误提示

TimeSync - CRITICAL ( NTP CRITICAL: No response from the NTP server)
TimeSync - CRITICAL ( NTP CRITICAL: Offset unknown )

为了解决这个问题,在所有 Linux 主机上安装 ntp。

sudo apt-get install ntp ntpdate

编辑 ntp 配置文件:

vim /etc/ntp.conf

注释掉所有 pools 并替换为:

#pool 0.ubuntu.pool.ntp.org iburst
#pool 1.ubuntu.pool.ntp.org iburst
#pool 2.ubuntu.pool.ntp.org iburst
#pool 3.ubuntu.pool.ntp.org iburst

pool 0.id.pool.ntp.org
pool 1.asia.pool.ntp.org
pool 0.asia.pool.ntp.org

然后,在新的一行添加如下限制规则:

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict 192.168.1.120 #shinken server IP address
restrict ::1
NOTE: 192.168.1.120 is the Shinken server IP address.

保存并退出。

启动 ntp 并且检查 Shinken 面板。

ntpd

check\_netint.pl Not Found 问题

从 github 仓库下载源代码到 shinken 的库目录下:

cd /var/lib/shinken/libexec/
wget https://raw.githubusercontent.com/Sysnove/shinken-plugins/master/check_netint.pl
chmod +x check_netint.pl
chown shinken:shinken check_netint.pl

网络占用的问题

这是错误信息:

ERROR : Unknown interface eth\d+

检查你的网络接口并且编辑 linux-snmp 模版。

在我的 Ununtu 服务器,网卡是 “enp0s8”,而不是 eth0,所以我遇到了这个错误。

vim 编辑 linux-snmp 模版:

vim /etc/shinken/packs/linux-snmp/templates.cfg

在第 24 行添加网络接口信息:

_NET_IFACES         eth\d+|em\d+|enp0s8

保存并退出。


via: https://www.howtoforge.com/tutorial/server-monitoring-with-shinken-on-ubuntu-16-04/

作者:Muhammad Arul 译者:LinuxBars 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Save and exit.

你在 Distrowatch.com 上看到列出的将近 300 个 Linux 发行版本中,几乎任何一个发行版都可以被用来作为服务器系统。下面是一些相对于其他发行版而言比较突出的一些发行版。

你在 Distrowatch.com 上看到列出的将近 300 个 Linux 发行版本中,几乎任何一个发行版都可以被用来作为服务器系统,在 Linux 发展的早期,给用户提供的一直是“全能”发行版,例如 Slackware、Debian 和 Gentoo 可以为家庭和企业作为服务器完成繁重的工作。那或许对业余爱好者是不错的,但是它对于专业人员来说也有好多不必要的地方。

首先,这里有一些发行版可以作为文件和应用服务器,给工作站提供常见外围设备的共享,提供网页服务和其它我们希望服务器做的任何工作,不管是在云端、在数据中心或者在服务器机架上,除此之外没有别的用途。

下面是 5 个最常用的 Linux 发行版的简单总结,而且每一个发行版都可以满足小型企业的需求。

Red Hat Enterprise Linux(RHEL)

这或许是最有名的 Linux 服务器发行版了。RHEL 以它在高要求的至关重要的任务上坚如磐石的稳定性而出名,例如运行着纽约证券交易系统。红帽也提供了业内最佳的服务支持。

那么红帽 Linux 的缺点都有什么呢? 尽管红帽以提供首屈一指的客户服务和支持而出名,但是它的支持订阅费用并不便宜。有人可能会指出,这的确物有所值。确实有便宜的 RHEL 第三方服务,但是你或许应该在这么做之前做一些研究。

CentOS

任何喜欢 RHEL,但是又不想给红帽付费来获得支持的人都应该了解一下 CentOS,它基本上是红帽企业版 Linux 的一个分支。尽管这个项目 2004 年左右才开始,但它在 2014 年得到了红帽的官方支持,而它现在雇佣可这个项目的大多数开发者,这意味着安全补丁和漏洞修复提交到红帽不久后就会在 CentOS 上可用。

如果你想要部署 CentOS,你将需要有 Linux 技能的员工,因为没有了技术支持,你基本上只能靠自己。有一个好消息是 CentOS 社区提供了十分丰富的资源,例如邮件列表、Web 论坛和聊天室,所以对那些寻找帮助的人来说,社区帮助还是有的。

Ubuntu Server

当许多年前 Canonical 宣布它将要推出一个服务器版本的 Ubuntu 的时候,你可能会听到过嘲笑者的声音。然而嘲笑很快变成了惊奇,Ubuntu Server 迅速地站稳了脚跟。部分原因是因为其来自 Debian 派生的基因,Debian 长久以来就是一个备受喜爱的 Linux 服务器发行版,Ubuntu 通过提供一般人可以支付的起的技术支持费用、优秀的硬件支持、开发工具和很多亮点填补了这个市场空隙。

那么 Ubuntu Server 有多么受欢迎呢?最近的数据表明它正在成为在 OpenStack 和 Amazon Elastic Compute Cloud 上部署最多的操作系统。在那里 Ubuntu Server 超过了位居第二的 Amazon Linux 的 Amazon Machine Image 一大截,而且让第三位 Windows 处于尘封的地位。另外一个调查显示 Ubuntu Server 是使用最多的 Linux web 服务器

SUSE Linux Enterprise Server(SLES)

这个源自德国的发行版在欧洲有很大的用户群,而且在本世纪初由 Novell 公司引起的 PR 问题出现之前,它一直都是大西洋这边的排名第一服务器发行版。在那段漫长的时期之后,SUSE 在美国获得了发展,而且它的使用或许加速了惠普企业公司将它作为 Linux 首选合作伙伴

SLES 稳定而且易于维护,这正是很久以来对于一个好的 Linux 发行版所期待的东西。付费的 7*24 小时快速响应技术支持可以供你选择,使得这发行版很适合关键任务的部署。

ClearOS

基于 RHEL,之所以这里要包括 ClearOS 是因为它对于每个人来说都足够简单,甚至是没有专业知识的人都可以去配置它。它定位于服务中小型企业,它也可以被家庭用户用来作为娱乐服务器,为了简单易用我们可以基于 Web 界面进行管理,它是以“构建你的 IT 基础设施应该像在智能手机上下载 app 一样简单”为前提来定制的。

最新的 7.2 发行版本,包括了一些可能并不“轻量级”的功能,例如对微软 Hyper-V 技术的 VM 支持,支持 XFS 和 BTRFS 文件系统,也支持 LVM 和 IPv6。这些新特性在免费版本或者在并不算贵的带着各种支持选项的专业版中都是可用的。


via: http://windowsitpro.com/industry/five-linux-server-distros-worth-checking-out

作者:Christine Hall 译者:LinuxBars 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

自从我写了上一篇博文之后,就再也找不到空闲时间写文章了。今天我终于可以抽出时间写一些关于 HTTP 的东西。

我认为每一个 web 开发者都应该对这个支撑了整个 Web 世界的 HTTP 协议有所了解,这样才能帮助你更好的完成开发任务。

在这篇文章中,我将讨论什么是 HTTP,它是怎么产生的,它的地位,以及我们应该怎么使用它。

HTTP 是什么

首先我们要明白 HTTP 是什么。HTTP 是一个基于 TCP/IP 的应用层通信协议,它是客户端和服务端在互联网互相通讯的标准。它定义了内容是如何通过互联网进行请求和传输的。HTTP 是在应用层中抽象出的一个标准,使得主机(客户端和服务端)之间的通信得以通过 TCP/IP 来进行请求和响应。TCP 默认使用的端口是 80,当然也可以使用其它端口,比如 HTTPS 使用的就是 443 端口。

HTTP/0.9 - 单行协议 (1991)

HTTP 最早的规范可以追溯到 1991 年,那时候的版本是 HTTP/0.9,该版本极其简单,只有一个叫做 GET的请求方式。如果客户端要访问服务端上的一个页面,只需要如下非常简单的请求:

GET /index.html

服务端对应的返回类似如下:

(response body)
(connection closed)

就这么简单,服务端捕获到请求后立马返回 HTML 并且关闭连接,在这之中

  • 没有 头信息 headers
  • 仅支持 GET 这一种请求方法
  • 必须返回 HTML

如同你所看到的,当时的 HTTP 协议只是一块基础的垫脚石。

HTTP/1.0 - 1996

在 1996 年,新版本的 HTTP 对比之前的版本有了极大的改进,同时也被命名为 HTTP/1.0

HTTP/0.9 只能返回 HTML 不同的是,HTTP/1.0 支持处理多种返回的格式,比如图片、视频、文本或者其他格式的文件。它还增加了更多的请求方法(如 POSTHEAD),请求和响应的格式也相应做了改变,两者都增加了头信息;引入了状态码来定义返回的特征;引入了字符集支持;支持 多段类型 multi-part 、用户验证信息、缓存、内容编码格式等等。

一个简单的 HTTP/1.0 请求大概是这样的:

GET / HTTP/1.0
Host: kamranahmed.info
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

正如你所看到的,在请求中附带了客户端中的一些个人信息、响应类型要求等内容。这些是在 HTTP/0.9 无法实现的,因为那时候没有头信息。

一个对上述请求的响应例子如下所示:

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

HTTP/1.0 (HTTP 后面跟的是版本号)早期开始,在状态码 200 之后就附带一个原因短语(你可以用来描述状态码)。

在这个较新一点的版本中,请求和响应的头信息仍然必须是 ASCII 编码,但是响应的内容可以是任意类型,如图片、视频、HTML、文本或其他类型,服务器可以返回任意内容给客户端。所以这之后,HTTP 中的“ 超文本 Hyper Text ”成了名不副实。 HMTP 超媒体传输协议 Hypermedia transfer protocol )可能会更有意义,但是我猜我们还是会一直沿用这个名字。

HTTP/1.0 的一个主要缺点就是它不能在一个连接内拥有多个请求。这意味着,当客户端需要从服务器获取东西时,必须建立一个新的 TCP 连接,并且处理完单个请求后连接即被关闭。需要下一个东西时,你必须重新建立一个新的连接。这样的坏处在哪呢?假设你要访问一个有 10 张图片,5 样式表 stylesheet 5 个 JavaScript 的总计 20 个文件才能完整展示的一个页面。由于一个连接在处理完成一次请求后即被关闭,所以将有 20 个单独的连接,每一个文件都将通过各自对应的连接单独处理。当连接数量变得庞大的时候就会面临严重的性能问题,因为 TCP 启动需要经过三次握手,才能缓慢开始。

三次握手

三次握手是一个简单的模型,所有的 TCP 连接在传输应用数据之前都需要在三次握手中传输一系列数据包。

  • SYN - 客户端选取一个随机数,我们称为 x,然后发送给服务器。
  • SYN ACK - 服务器响应对应请求的 ACK 包中,包含了一个由服务器随机产生的数字,我们称为 y,并且把客户端发送的 x+1,一并返回给客户端。
  • ACK - 客户端在从服务器接受到 y 之后把 y 加上 1 作为一个 ACK 包返回给服务器。

一旦三次握手完成后,客户端和服务器之间就可以开始交换数据。值得注意的是,当客户端发出最后一个 ACK 数据包后,就可以立刻向服务器发送应用数据包,而服务器则需要等到收到这个 ACK 数据包后才能接受应用数据包。

请注意,上图有点小问题,客户端发回的最后一个 ACK 包仅包含 y+1,上图应该是 ACK:y+1 而不是 ACK:x+1,y+1

然而,某些 HTTP/1.0 的实现试图通过新引入一个称为 Connection: keep-alive 的头信息来克服这一问题,这个头信息意味着告诉服务器“嘿,服务器,请不要关闭此连接,我还要用它”。但是,这并没有得到广泛的支持,问题依然存在。

除了无连接之外,HTTP 还是一个无状态的协议,即服务器不维护有关客户端的信息。因此每个请求必须给服务器必要的信息才能完成请求,每个请求都与之前的旧的请求无关。所以,这增加了推波助澜的作用,客户端除了需要新建大量连接之外,在每次连接中还需要发送许多重复的数据,这导致了带宽的大量浪费。

HTTP/1.1 - 1999

HTTP/1.0 经过仅仅 3 年,下一个版本,即 HTTP/1.1 就在 1999 年发布了,改进了它的前身很多问题,主要的改进包括:

  • 增加了许多 HTTP 请求方法,包括 PUTPATCHHEADOPTIONSDELETE
  • 主机标识符 HostHTTP/1.0 并不是必须的,而在 HTTP/1.1 是必须的。
  • 如上所述的持久连接。在 HTTP/1.0 中每个连接只有一个请求并在该请求结束后被立即关闭,这导致了性能问题和增加了延迟。 HTTP/1.1 引入了持久连接,即连接在默认情况下是不关闭并保持开放的,这允许多个连续的请求使用这个连接。要关闭该连接只需要在头信息加入 Connection: close,客户通常在最后一个请求里发送这个头信息就能安全地关闭连接。
  • 新版本还引入了“ 管线化 pipelining ”的支持,客户端可以不用等待服务器返回响应,就能在同一个连接内发送多个请求给服务器,而服务器必须以接收到的请求相同的序列发送响应。但是你可能会问了,客户端如何知道哪里是第一个响应下载完成而下一个响应内容开始的地方呢?要解决这个问题,头信息必须有 Content-Length,客户可以使用它来确定哪些响应结束之后可以开始等待下一个响应。

    • 值得注意的是,为了从持久连接或管线化中受益, 头部信息必须包含 Content-Length,因为这会使客户端知道什么时候完成了传输,然后它可以发送下一个请求(持久连接中,以正常的依次顺序发送请求)或开始等待下一个响应(启用管线化时)。
    • 但是,使用这种方法仍然有一个问题。那就是,如果数据是动态的,服务器无法提前知道内容长度呢?那么在这种情况下,你就不能使用这种方法中获益了吗?为了解决这个问题,HTTP/1.1 引进了分块编码。在这种情况下,服务器可能会忽略 Content-Length 来支持分块编码(更常见一些)。但是,如果它们都不可用,那么连接必须在请求结束时关闭。
  • 在动态内容的情况下分块传输,当服务器在传输开始但无法得到 Content-Length 时,它可能会开始按块发送内容(一块接一块),并在传输时为每一个小块添加 Content-Length。当发送完所有的数据块后,即整个传输已经完成后,它发送一个空的小块,比如设置 Content-Length 为 0 ,以便客户端知道传输已完成。为了通知客户端块传输的信息,服务器在头信息中包含了 Transfer-Encoding: chunked
  • 不像 HTTP/1.0 中只有 Basic 身份验证方式,HTTP/1.1 包括 摘要验证方式 digest authentication 代理验证方式 proxy authentication
  • 缓存。
  • 范围请求 Byte Ranges
  • 字符集。
  • 内容协商 Content Negotiation
  • 客户端 cookies。
  • 支持压缩。
  • 新的状态码。
  • 等等。

我不打算在这里讨论所有 HTTP/1.1 的特性,因为你可以围绕这个话题找到很多关于这些的讨论。我建议你阅读 HTTP/1.0HTTP/1.1 版本之间的主要差异,希望了解更多可以读原始的 RFC

HTTP/1.1 在 1999 年推出,到现在已经是多年前的标准。虽然,它比前一代改善了很多,但是网络日新月异,它已经垂垂老矣。相比之前,加载网页更是一个资源密集型任务,打开一个简单的网页已经需要建立超过 30 个连接。你或许会说,HTTP/1.1 具有持久连接,为什么还有这么多连接呢?其原因是,在任何时刻 HTTP/1.1 只能有一个未完成的连接。 HTTP/1.1 试图通过引入管线来解决这个问题,但它并没有完全地解决。因为一旦管线遇到了缓慢的请求或庞大的请求,后面的请求便被阻塞住,它们必须等待上一个请求完成。为了克服 HTTP/1.1 的这些缺点,开发人员开始实现一些解决方法,例如使用 spritesheets、在 CSS 中编码图像、单个巨型 CSS / JavaScript 文件、域名切分等。

SPDY - 2009

谷歌走在业界前列,为了使网络速度更快,提高网络安全,同时减少网页的等待时间,他们开始实验替代的协议。在 2009 年,他们宣布了 SPDY

SPDY 是谷歌的商标,而不是一个缩写。

显而易见的是,如果我们继续增加带宽,网络性能开始的时候能够得到提升,但是到了某个阶段后带来的性能提升就很有限了。但是如果把这些优化放在等待时间上,比如减少等待时间,将会有持续的性能提升。这就是 SPDY 优化之前的协议的核心思想,减少等待时间来提升网络性能。

对于那些不知道其中区别的人,等待时间就是延迟,即数据从源到达目的地需要多长时间(单位为毫秒),而带宽是每秒钟数据的传输量(比特每秒)。

SPDY 的特点包括:复用、压缩、优先级、安全性等。我不打算展开 SPDY 的细节。在下一章节,当我们将介绍 HTTP/2,这些都会被提到,因为 HTTP/2 大多特性是从 SPDY 受启发的。

SPDY 没有试图取代 HTTP,它是处于应用层的 HTTP 之上的一个传输层,它只是在请求被发送之前做了一些修改。它开始成为事实标准,大多数浏览器都开始支持了。

2015年,谷歌不想有两个相互竞争的标准,所以他们决定将其合并到 HTTP 协议,这样就导致了 HTTP/2 的出现和 SPDY 的废弃。

HTTP/2 - 2015

现在想必你明白了为什么我们需要另一个版本的 HTTP 协议了。 HTTP/2 是专为了低延迟地内容传输而设计。主要特点和与 HTTP/1.1 的差异包括:

  • 使用二进制替代明文
  • 多路传输 - 多个异步 HTTP 请求可以使用单一连接
  • 报头使用 HPACK 压缩
  • 服务器推送 - 单个请求多个响应
  • 请求优先级
  • 安全性

1. 二进制协议

HTTP/2 通过使其成为一个二进制协议以解决 HTTP/1.x 中存在的延迟问题。作为一个二进制协议,它更容易解析,但可读性却不如 HTTP/1.x frames stream 的概念组成了 HTTP/2 的主要部分。

帧和流

现在 HTTP 消息是由一个或多个帧组成的。HEADERS 帧承载了 元数据 meta data DATA 帧则承载了内容。还有其他类型的帧(HEADERSDATARST_STREAMSETTINGSPRIORITY 等等),这些你可以通过 HTTP/2 规范来了解。

每个 HTTP/2 请求和响应都被赋予一个唯一的流 ID,并切分成帧。帧就是一小片二进制数据。帧的集合称为流,每个帧都有个标识了其所属流的流 ID,所以在同一个流下的每个帧具有共同的报头。值得注意的是,​除了流 ID 是唯一的之外,​由客户端发起的请求使用了奇数作为流 ID,从来自服务器的响应使用了偶数作为流 ID。

除了 HEADERS 帧和 DATA 帧,另一个值得一提的帧是 RST_STREAM。这是一个特殊的帧类型,用来中止流,即客户可以发送此帧让服务器知道,我不再需要这个流了。在 HTTP/1.1 中让服务器停止给客户端发送响应的唯一方法是关闭连接,这样造成了延迟增加,因为之后要发送请求时,就要必须打开一个新的请求。而在 HTTP/2,客户端可以使用 RST_STREAM 来停止接收特定的数据流,而连接仍然打开着,可以被其他请求使用。

2. 多路传输

因为 HTTP/2 是一个二进制协议,而且如上所述它使用帧和流来传输请求与响应,一旦建立了 TCP 连接,相同连接内的所有流都可以同过这个 TCP 连接异步发送,而不用另外打开连接。反过来说,服务器也可以使用同样的异步方式返回响应,也就是说这些响应可以是无序的,客户端使用分配的流 ID 来识别数据包所属的流。这也解决了 HTTP/1.x 中请求管道被阻塞的问题,即客户端不必等待占用时间的请求而其他请求仍然可以被处理。

3. HPACK 请求头部压缩

RFC 花了一篇文档的篇幅来介绍针对发送的头信息的优化,它的本质是当我们在同一客户端上不断地访问服务器时,许多冗余数据在头部中被反复发送,有时候仅仅是 cookies 就能增加头信息的大小,这会占用许多宽带和增加传输延迟。为了解决这个问题,HTTP/2 引入了头信息压缩。

不像请求和响应那样,头信息中的信息不会以 gzip 或者 compress 等格式压缩。而是采用一种不同的机制来压缩头信息,客户端和服务器同时维护一张头信息表,储存了使用了哈夫曼编码进行编码后的头信息的值,并且后续请求中若出现同样的字段则忽略重复值(例如 用户代理 user agent 等),只发送存在两边信息表中它的引用即可。

我们说的头信息,它们同 HTTP/1.1 中一样,并在此基础上增加了一些伪头信息,如 :scheme:host:path

4. 服务器推送

服务器推送是 HTTP/2 的另一个巨大的特点。对于服务器来说,当它知道客户端需要一定的资源后,它可以把数据推送到客户端,即使客户端没有请求它。例如,假设一个浏览器在加载一个网页时,它解析了整个页面,发现有一些内容必须要从服务端获取,然后发送相应的请求到服务器以获取这些内容。

服务器推送减少了传输这些数据需要来回请求的次数。它是如何做到的呢?服务器通过发送一个名字为 PUSH_PROMISE 特殊的帧通知到客户端“嘿,我准备要发送这个资源给你了,不要再问我要了。”这个 PUSH_PROMISE 帧与要产生推送的流联系在一起,并包含了要推送的流 ID,也就是说这个流将会被服务器推送到客户端上。

5. 请求优先级

当流被打开的时候,客户端可以在 HEADERS 帧中包含优先级信息来为流指定优先级。在任何时候,客户端都可以发送 PRIORITY 帧来改变流的优先级。

如果没有任何优先级信息,服务器将异步地无序地处理这些请求。如果流分配了优先级,服务器将基于这个优先级来决定需要分配多少资源来处理这个请求。

6. 安全性

在是否强制使用 TLS 来增加安全性的问题上产生了大范围的讨论,讨论的结果是不强制使用。然而大多数厂商只有在使用 TLS 时才能使用 HTTP/2。所以 HTTP/2 虽然规范上不要求加密,但是加密已经约定俗成了。这样,在 TLS 之上实现 HTTP/2 就有了一些强制要求,比如,TLS 的最低版本为 1.2,必须达到某种级别的最低限度的密钥大小,需要布署 ephemeral 密钥等等。

到现在 HTTP/2 已经完全超越了 SPDY,并且还在不断成长,HTTP/2 有很多关系性能的提升,我们应该开始布署它了。

如果你想更深入的了解细节,请访问该规范的链接HTTP/2 性能提升演示的链接。请在留言板写下你的疑问或者评论,最后如果你发现有错误,请同样留言指出。

这就是全部了,我们之后再见~


via: http://kamranahmed.info/blog/2016/08/13/http-in-depth/

作者:Kamran Ahmed 译者:NearTan 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

当你打算真正操纵好你的 Linux 系统,没有什么能比命令行界面更让你做到这一点。为了成为一个 Linux 高手,你必须能够理解 Shell 命令的不同类型,并且会在终端下正确的使用它们。

在 Linux 下,命令有几种类型,对于一个 Linux 新手来说,知道不同命令的意思才能够高效和准确的使用它们。因此,在这篇文章里,我们将会遍及各种不同分类的 Linux Shell 命令。

需要注意一件非常重要的事:命令行界面和 Shell 是不同的,命令行界面只是为你提供一个访问 Shell 的方式。而 Shell ,它是可编程的,这使得它可以通过命令与内核进行交流。

下面列出了 Linux 下命令的不同种类:

1. 程序可执行文件(文件系统 中的命令)

当你执行一条命令的时候,Linux 通过从左到右搜索存储在 $PATH 环境变量中的目录来找到这条命令的可执行文件。

你可以像下面这样查看存储在 $PATH 中的目录:

$ echo $PATH
/home/aaronkilik/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

在上面的命令中,目录 /home/aaronkilik/bin 将会被首先搜索,紧跟着是 /usr/local/sbin,然后一直接着下去。在搜索过程中,搜索顺序是至关重要的。

比如在 /usr/bin 目录里的文件系统中的命令:

$ ll /bin/

示例输出:

total 16284
drwxr-xr-x  2 root root    4096 Jul 31 16:30 ./
drwxr-xr-x 23 root root    4096 Jul 31 16:29 ../
-rwxr-xr-x  1 root root    6456 Apr 14 18:53 archdetect*
-rwxr-xr-x  1 root root 1037440 May 17 16:15 bash*
-rwxr-xr-x  1 root root  520992 Jan 20  2016 btrfs*
-rwxr-xr-x  1 root root  249464 Jan 20  2016 btrfs-calc-size*
lrwxrwxrwx  1 root root       5 Jul 31 16:19 btrfsck -> btrfs*
-rwxr-xr-x  1 root root  278376 Jan 20  2016 btrfs-convert*
-rwxr-xr-x  1 root root  249464 Jan 20  2016 btrfs-debug-tree*
-rwxr-xr-x  1 root root  245368 Jan 20  2016 btrfs-find-root*
-rwxr-xr-x  1 root root  270136 Jan 20  2016 btrfs-image*
-rwxr-xr-x  1 root root  249464 Jan 20  2016 btrfs-map-logical*
-rwxr-xr-x  1 root root  245368 Jan 20  2016 btrfs-select-super*
-rwxr-xr-x  1 root root  253816 Jan 20  2016 btrfs-show-super*
-rwxr-xr-x  1 root root  249464 Jan 20  2016 btrfstune*
-rwxr-xr-x  1 root root  245368 Jan 20  2016 btrfs-zero-log*
-rwxr-xr-x  1 root root   31288 May 20  2015 bunzip2*
-rwxr-xr-x  1 root root 1964536 Aug 19  2015 busybox*
-rwxr-xr-x  1 root root   31288 May 20  2015 bzcat*
lrwxrwxrwx  1 root root       6 Jul 31 16:19 bzcmp -> bzdiff*
-rwxr-xr-x  1 root root    2140 May 20  2015 bzdiff*
lrwxrwxrwx  1 root root       6 Jul 31 16:19 bzegrep -> bzgrep*
-rwxr-xr-x  1 root root    4877 May 20  2015 bzexe*
lrwxrwxrwx  1 root root       6 Jul 31 16:19 bzfgrep -> bzgrep*
-rwxr-xr-x  1 root root    3642 May 20  2015 bzgrep*

2. Linux 别名

这些是用户定义的命令,它们是通过 shell 内置命令 alias 创建的,其中包含其它一些带有选项和参数的 shell 命令。这个意图主要是使用新颖、简短的名字来替代冗长的命令。

创建一个别名的语法像下面这样:

$ alias newcommand='command -options'

通过下面的命令,可以列举系统中的所有别名:

$ alias -p
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'

要在 Linux 中创建一个新的别名,仔细阅读下面的例子。

$ alias update='sudo apt update'
$ alias upgrade='sudo apt dist-upgrade'
$ alias -p | grep 'up'

然而,上面这些我们创建的别名只能暂时的工作,当经过下一次系统启动后它们不再工作。你可以像下面展示的这样在 '.bashrc' 文件中设置永久别名。

添加以后,运行下面的命令来激活:

$ source ~/.bashrc

3. Linux Shell 保留字

在 shell 程序设计中,ifthenfiforwhilecaseesacelseuntil 以及其他更多的字都是 shell 保留字。正如描述所暗示的,它们在 shell 中有特殊的含义。

你可以通过使用下面展示的 type 命令来列出所有的 shell 关键字:

$ type if then fi for while case esac else until
if is a shell keyword
then is a shell keyword
fi is a shell keyword
for is a shell keyword
while is a shell keyword
case is a shell keyword
esac is a shell keyword
else is a shell keyword
until is a shell keyword

4. Linux shell 函数

一个 shell 函数是一组在当前 shell 内一起执行的命令。函数有利于在 shell 脚本中实现特殊任务。在 shell 脚本中写 shell 函数的传统形式是下面这样:

function_name() {
command1
command2
......
}

或者像这样:

function function_name {
command1
command2
......
}

让我们看一看如何在一个名为 shell\_functions.sh 的脚本中写 shell 函数。

#!/bin/bash 
#write a shell function to update and upgrade installed packages 
upgrade_system(){
sudo apt update;
sudo apt dist-upgrade;
}
#execute function
upgrade_system

取代通过命令行执行两条命令:sudo apt updatesudo apt dist-upgrade,我们在脚本内写了一个像执行一条单一命令一样来执行两条命令的 shell 函数 upgrade\_system。

保存文件,然后使脚本可执行。最后像下面这样运行 shell 函数:

$ chmod +x shell_functions.sh
$ ./shell_functions.sh

5. Linux Shell 内置命令

这些是在 shell 中内置的 Linux 命令,所以你无法在文件系统中找到它们。这些命令包括 pwdcdbgaliashistorytypesourcereadexit 等。

你可以通过下面展示的 type 命令来列出或检查 Linux 内置命令:

$ type pwd
pwd is a shell builtin
$ type cd
cd is a shell builtin
$ type bg
bg is a shell builtin
$ type alias
alias is a shell builtin
$ type history
history is a shell builtin

学习一些 Linux 内置命令用法:

结论

作为一个 Linux 用户,知道你所运行的命令类型是很重要的。我相信,通过上面明确、简单并且易于理解的解释,包括一些相关的说明,你可能对 “Linux 命令的不同种类”有了很好的理解。

你也可以在下面的评论区提任何问题或补充意见,从而和我们取得联系。


via: http://www.tecmint.com/understanding-different-linux-shell-commands-usage/

作者:Aaron Kili 译者:ucasFL 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

解析器是一种超级有用的软件库。从概念上简单的说,它们的实现很有挑战性,并且在计算机科学中经常被认为是黑魔法。在这个系列的博文中,我会向你们展示为什么你不需要成为哈利波特就能够精通解析器这种魔法。但是为了以防万一带上你的魔杖吧!

我们将探索一种叫做 Ohm 的新的开源库,它使得搭建解析器很简单并且易于重用。在这个系列里,我们使用 Ohm 去识别数字,构建一个计算器等等。在这个系列的最后你将已经用不到 200 行的代码发明了一种完整的编程语言。这个强大的工具将让你能够做到一些你可能过去认为不可能的事情。

为什么解析器很困难?

解析器非常有用。在很多时候你可能需要一个解析器。或许有一种你需要处理的新的文件格式,但还没有人为它写了一个库;又或许你发现了一种古老格式的文件,但是已有的解析器不能在你的平台上构建。我已经看到这样的事发生无数次。 Code 在或者不在, Data 就在那里,不增不减。

从根本上来说,解析器很简单:只是把一个数据结构转化成另一个。所以你会不会觉得你要是邓布利多校长就好了?

解析器历来是出奇地难写,所面临的挑战是绝大多数现有的工具都很老,并且需要一定的晦涩难懂的计算机科学知识。如果你在大学里上过编译器课程,那么课本里也许还有从上世纪七十年传下来的技术。幸运的是,解析器技术从那时候起已经提高了很多。

典型的,解析器是通过使用一种叫作 形式语法 formal grammar 的特殊语法来定义你想要解析的东西来创造的,然后你需要把它放入像 BisonYacc 的工具中,这些工具能够产生一堆 C 代码,这些代码你需要修改或者链接到你实际写入的编程语言中。另外的选择是用你更喜欢的语言亲自动手写一个解析器,这很慢且很容易出错,在你能够真正使用它之前还有许多额外的工作。

想像一下,是否你关于你想要解析的东西的语法描述也是解析器?如果你能够只是直接运行这些语法,然后仅在你需要的地方增加一些 挂钩 hook 呢?那就是 Ohm 所可以做到的事。

Ohm 简介

Ohm 是一种新的解析系统。它类似于你可能已经在课本里面看到过的语法,但是它更强大,使用起来更简单。通过 Ohm, 你能够使用一种灵活的语法在一个 .ohm 文件中来写你自己的格式定义,然后使用你的宿主语言把语义加入到里面。在这篇博文里,我们将用 JavaScript 作为宿主语言。

Ohm 建立于一个为创造更简单、更灵活的解析器的多年研究基础之上。VPRI 的 STEPS program (pdf) 使用 Ohm 的前身 Ometa 为许多特殊的任务创造了专门的语言(比如一个有 400 行代码的平行制图描绘器)。

Ohm 有许多有趣的特点和符号,但是相比于全部解释它们,我认为我们只需要深入其中并构建一些东西就行了。

解析整数

让我们来解析一些数字。这看起来会很简单,只需在一个文本串中寻找毗邻的数字,但是让我们尝试去处理所有形式的数字:整数和浮点数、十六进制数和八进制数、科学计数、负数。解析数字很简单,正确解析却很难。

亲自构建这个代码将会很困难,会有很多问题,会伴随有许多特殊的情况,比如有时会相互矛盾。正则表达式或许可以做的这一点,但是它会非常丑陋而难以维护。让我们用 Ohm 来试试。

用 Ohm 构建的解析器涉及三个部分: 语法 grammar 语义 semantics 测试 tests 。我通常挑选问题的一部分为它写测试,然后构建足够的语法和语义来使测试通过。然后我再挑选问题的另一部分,增加更多的测试、更新语法和语义,从而确保所有的测试能够继续通过。即使我们有了新的强大的工具,写解析器从概念上来说依旧很复杂。测试是用一种合理的方式来构建解析器的唯一方法。现在,让我们开始工作。

我们将从整数开始。一个整数由一系列相互毗邻的数字组成。让我们把下面的内容放入一个叫做 grammar.ohm 的文件中:

CoolNums {
   // just a basic integer
   Number = digit+
}

这创造了一条匹配一个或多个数字(digit)叫作 Number 的单一规则。 意味着一个或更多,就在正则表达式中一样。当有一个或更多的数字时,这个规则将会匹配它们,如果没有数字或者有一些不是数字的东西将不会匹配。“数字(digit)”的定义是从 0 到 9 其中的一个字符。digit 也是像 Number 一样的规则,但是它是 Ohm 的其中一条构建规则因此我们不需要去定义它。如果我们想的话可以推翻它,但在这时候这没有任何意义,毕竟我们不打算去发明一种新的数。

现在,我们可以读入这个语法并用 Ohm 库来运行它。

把它放入 test1.js:

var ohm = require('ohm-js');
var fs = require('fs');
var assert = require('assert');
var grammar = ohm.grammar(fs.readFileSync('src/blog_numbers/syntax1.ohm').toString());

Ohm.grammar 调用将读入该文件并解析成一个语法对象。现在我们可以增加一些语义。把下面内容增加到你的 JavaScript 文件中:

var sem = grammar.createSemantics().addOperation('toJS', {
    Number: function(a) {
        return parseInt(this.sourceString,10);
    }
});

这通过 toJS 操作创造了一个叫作 sem 的语法集。这些语义本质上是一些对应到语法中每个规则的函数。每个函数当与之相匹配的语法规则被解析时将会被调用。上面的 Number 函数将会在语法中的 Number 规则被解析时被调用。 语法 grammar 定义了在语言中这些代码是什么, 语义 semantics 定义了当这些代码被解析时应该做什么。

语义函数能够做我们想做的任何事,比如打印出故障信息、创建对象,或者在任何子节点上递归调用 toJS。此时我们仅仅想把匹配的文本转换成真正的 JavaScript 整数。

所有的语义函数有一个内含的 this 对象,带有一些有用的属性。其 source 属性代表了输入文本中和这个节点相匹配的部分。this.sourceString 是一个匹配输入的串,调用内置在 JavaScript 中的 parseInt 函数会把这个串转换成一个数。传给 parseInt10 这个参数告诉 JavaScript 我们输入的是一个以 10 为基底(10 进制)的数。如果少了这个参数, JavaScript 也会假定以 10 为基底,但是我们把它包含在里面因为后面我们将支持以 16 为基底的数,所以使之明确比较好。

既然我们有一些语法,让我们来实际解析一些东西看一看我们的解析器是否能够工作。如何知道我们的解析器可以工作?通过测试,许多许多的测试,每一个可能的边缘情况都需要一个测试。

使用标准的断言 assert API,以下这个测试函数能够匹配一些输入并运用我们的语义把它转换成一个数,然后把这个数和我们期望的输入进行比较。

   function test(input, answer) {
     var match = grammar.match(input);
     if(match.failed()) return console.log("input failed to match " + input + match.message);     
     var result = sem(match).toJS();
     assert.deepEqual(result,answer);
     console.log('success = ', result, answer);
    }

就是如此。现在我们能够为各种不同的数写一堆测试。如果匹配失败我们的脚本将会抛出一个例外。否则就打印成功信息。让我们尝试一下,把下面这些内容加入到脚本中:

    test("123",123);
    test("999",999);
    test("abc",999);

然后用 node test1.js 运行脚本。

你的输出应该是这样:

success =  123 123
success =  999 999
input failed to match abcLine 1, col 1:
> 1 | abc
      ^
Expected a digit

真酷。正如预期的那样,前两个成功了,第三个失败了。更好的是,Ohm 自动给了我们一个很棒的错误信息指出匹配失败。

浮点数

我们的解析器工作了,但是它做的工作不是很有趣。让我们把它扩展成既能解析整数又能解析浮点数。改变 grammar.ohm 文件使它看起来像下面这样:

CoolNums {
  // just a basic integer
  Number = float | int
  int    = digit+
  float  = digit+ "." digit+
}

这把 Number 规则改变成指向一个浮点数(float)或者一个整数(int)。这个 | 代表着“或”。我们把这个读成“一个 Number 由一个浮点数或者一个整数构成。”然后整数(int)定义成 digit+,浮点数(float)定义成 digit+ 后面跟着一个句号然后再跟着另一个 digit+。这意味着在句号前和句号后都至少要有一个数字。如果一个数中没有一个句号那么它就不是一个浮点数,因此就是一个整数。

现在,让我们再次看一下我们的语义功能。由于我们现在有了新的规则所以我们需要新的功能函数:一个作为整数的,一个作为浮点数的。

var sem = grammar.createSemantics().addOperation('toJS', {
    Number: function(a) {
        return a.toJS();
    },
    int: function(a) {
        console.log("doing int", this.sourceString);
        return parseInt(this.sourceString,10);
    },
    float: function(a,b,c) {
        console.log("doing float", this.sourceString);
        return parseFloat(this.sourceString);
    }
});

这里有两件事情需要注意。首先,整数(int)、浮点数(float)和数(Number)都有相匹配的语法规则和函数。然而,针对 Number 的功能不再有任何意义。它接收子节点 a 然后返回该子节点的 toJS 结果。换句话说,Number 规则简单的返回相匹配的子规则。由于这是在 Ohm 中任何规则的默认行为,因此实际上我们不用去考虑 Number 的作用,Ohm 会替我们做好这件事。

其次,整数(int)有一个参数 a,然而浮点数有三个:abc。这是由于规则的 实参数量 arity 决定的。 实参数量 arity 意味着一个规则里面有多少参数。如果我们回过头去看语法,浮点数(float)的规则是:

  float  = digit+ "." digit+

浮点数规则通过三个部分来定义:第一个 digit+.、以及第二个 digit+。这三个部分都会作为参数传递给浮点数的功能函数。因此浮点数必须有三个参数,否则 Ohm 库会给出一个错误。在这种情况下我们不用在意参数,因为我们仅仅直接攫取了输入串,但是我们仍然需要参数列在那里来避免编译器错误。后面我们将实际使用其中一些参数。

现在我们可以为新的浮点数支持添加更多的测试。

test("123",123);
test("999",999);
//test("abc",999);
test('123.456',123.456);
test('0.123',0.123);
test('.123',0.123);

注意最后一个测试将会失败。一个浮点数必须以一个数开始,即使它就是个 0,.123 不是有效的,实际上真正的 JavaScript 语言也有相同的规则。

十六进制数

现在我们已经有了整数和浮点数,但是还有一些其它的数的语法最好可以支持:十六进制数和科学计数。十六进制数是以 16 为基底的整数。十六进制数的数字能从 0 到 9 和从 A 到 F。十六进制数经常用在计算机科学中,当用二进制数据工作时,你可以仅仅使用两个数字表示 0 到 255 的数。

在绝大多数源自 C 的编程语言(包括 JavaScript),十六进制数通过在前面加上 0x 来向编译器表明后面跟的是一个十六进制数。为了让我们的解析器支持十六进制数,我们只需要添加另一条规则。

  Number = hex | float | int
  int    = digit+
  float  = digit+ "." digit+
  hex    = "0x" hexDigit+
  hexDigit := "0".."9" | "a".."f" | "A".."F"

我实际上已经增加了两条规则。十六进制数(hex)表明它是一个 0x 后面一个或多个十六进制数字(hexDigits)的串。一个十六进制数字(hexDigit)是从 0 到 9,或从 a 到 f,或 A 到 F(包括大写和小写的情况)的一个字符。我也修改了 Number 规则来识别十六进制数作为另外一种可能的情况。现在我们只需要另一条针对十六进制数的功能规则。

    hex: function(a,b) {
        return parseInt(this.sourceString,16);
    }

注意到,在这种情况下,我们把 16 作为基底传递给 parseInt,因为我们希望 JavaScript 知道这是一个十六进制数。

我略过了一些很重要需要注意的事。hexDigit 的规则像下面这样:

  hexDigit := "0".."9" | "a".."f" | "A".."F"

注意我使用的是 := 而不是 =。在 Ohm 中,:= 是当你需要推翻一条规则的时候使用。这表明 Ohm 已经有了一条针对 hexDigit 的默认规则,就像 digitspace 等一堆其他的东西。如果我使用了 =, Ohm 将会报告一个错误。这是一个检查,从而避免我无意识的推翻一个规则。由于新的 hexDigit 规则和 Ohm 的构建规则一样,所以我们可以把它注释掉,然后让 Ohm 自己来实现它。我留下这个规则只是因为这样我们可以看到它实际上是如何进行的。

现在,我们可以添加更多的测试然后看到十六进制数真的能工作:

test('0x456',0x456);
test('0xFF',255);

科学计数

最后,让我们来支持科学计数。科学计数是针对非常大或非常小的数的,比如 1.8×10^3。在大多数编程语言中,科学计数法表示的数会写成这样:1.8e3 表示 18000,或者 1.8e-3 表示 .018。让我们增加另外一对规则来支持这个指数表示:

    float  = digit+ "." digit+ exp?
    exp    = "e" "-"? digit+

上面在浮点数规则末尾增加了一个指数(exp)规则和一个 ?? 表示没有或有一个,所以指数(exp)是可选的,但是不能超过一个。增加指数(exp)规则也改变了浮点数规则的实参数量,所以我们需要为浮点数功能增加另一个参数,即使我们不使用它。

    float: function(a,b,c,d) {
        console.log("doing float", this.sourceString);
        return parseFloat(this.sourceString);
    },

现在我们的测试可以通过了:

test('4.8e10',4.8e10);
test('4.8e-10',4.8e-10);

结论

Ohm 是构建解析器的一个很棒的工具,因为它易于上手,并且你可以递增的增加规则。Ohm 也还有其他我今天没有写到的很棒的特点,比如调试观察仪和子类化。

到目前为止,我们已经使用 Ohm 来把字符串翻译成 JavaScript 数,并且 Ohm 经常用于把一种表示方式转化成另外一种。然而,Ohm 还有更多的用途。通过放入不同的语义功能集,你可以使用 Ohm 来真正处理和计算东西。一个单独的语法可以被许多不同的语义使用,这是 Ohm 的魔法之一。

在这个系列的下一篇文章中,我将向你们展示如何像真正的计算机一样计算像 (4.85 + 5 * (238 - 68)/2) 这样的数学表达式,不仅仅是解析数。

额外的挑战:你能够扩展语法来支持八进制数吗?这些以 8 为基底的数能够只用 0 到 7 这几个数字来表示,前面加上一个数字 0 或者字母 o。看看针对下面这些测试情况是够正确。下次我将给出答案。

test('0o77',7*8+7);
test('0o23',0o23);

via: https://www.pubnub.com/blog/2016-08-30-javascript-parser-ohm-makes-creating-a-programming-language-easy/

作者:Josh Marinacci 译者:ucasFL 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出