Keepalived&LVS搭建高可用的Web服务

在本文中,我将会讲述如何在Centos 7下基于Keepalived和LVS技术,实现Web服务的高可用和负载均衡,我们的目标拓扑结构如下图所示

未命名文件

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

准备

如果你觉得一步一步按照下面的操作来搭建太过麻烦,可以直接下载 mylxsw/keepalived-example 项目,然后执行 make create 即可一键搭建起整个演示环境。

使用Vagrant创建四台虚拟机用于测试使用,Vagrant 配置文件格式如下

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"
  config.vm.network "private_network", ip: "IP地址"
end

对于每个配置,需要替换配置文件中的IP地址

目录IP用途
keepalived192.168.88.8负载均衡Master
keepalived-backup192.168.88.9负载均衡Backup
node-1192.168.88.10web服务器
node-2192.168.88.11web服务器
client192.168.88.2客户端,也可以直接用自己的电脑,IP地址任意都可

VIP为 192.168.88.100,客户端IP为 192.168.88.2

启动Vagrant服务器需要进入服务器所在目录,执行 vagrant up 命令,登录到服务器需要执行 vagrant ssh 命令。如果你还没有接触过Vagrant,那么可以看看这篇文章 Vagrant入门。由于本文中很多命令都需要使用 root 权限进行操作,因此建议执行命令 su root 直接提升到root权限(密码为 vagrant ),否则需要在所有命令前添加 sudo 来执行。

分别登录每台服务器,设置其hostname,方便后面我们区分不同的服务器

# 在192.168.88.8上执行
hostnamectl set-hostname keepalived
# 在192.168.88.9上执行
hostnamectl set-hostname keepalived-backup
# 在192.168.88.10上执行
hostnamectl set-hostname node-1
# 在192.168.88.11上执行
hostnamectl set-hostname node-2

然后退出重新登录,就可以看到hostname生效了。

安装Keepalived服务

在 keepalived 和 keepalived-backup 两个虚拟机上,安装keepalived服务

yum install -y keepalived ipvsadm

安装完成后,可以看到生成了/etc/keepalived/keepalived.conf配置文件,不过这个文件是Keepalived提供的示例,后面我们需要修改。

将 Keepalived 服务添加到开机自启动

systemctl enable keepalived

安装web服务

在两台web服务器 node-1 和 node-2 上,我们就简单安装一个 nginx,然后开放80端口,提供简单的web服务用于测试

yum install yum-utils
yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
yum install -y openresty

为了方便查看效果,我们将 nginx 的默认web页面修改为显示服务器的IP

ip addr show eth1 | grep '192.168.88.' | awk '{print $2}' > /usr/local/openresty/nginx/html/index.html

然后,启动web服务

systemctl enable openresty
systemctl start openresty

Keepalive实现高可用

在这里,我们实现Keepalive服务(keepalived 和 keepalived-backup 两台服务器)的高可用,也就是为负载均衡服务提供主备服务,当master挂掉之后,backup自动成为新的master继续提供服务。

下面是Keepalived配置文件内容

global_defs {
    router_id LVS_8808
}

vrrp_instance HA_WebServer {
    state MASTER
    ! 监听的网卡,keepalived会将VIP绑定到该网卡上
    interface eth1
    ! 虚拟路由器ID,同一个实例保持一致,多个实例不能相同
    virtual_router_id 18
    garp_master_refresh 10
    garp_master_refresh_repeat 2
    ! VRRP 优先顺序的设定值。在选择主节点的时候,该值大的备用 节点会优先漂移为主节点
    priority 100
    ! 发送VRRP通告的间隔。单位是秒
    advert_int 1

    ! 集群授权密码
    authentication {
        auth_type PASS
        auth_pass 123456
    }

    ! 这里是我们配置的VIP,可以配置多个,每个IP一行
    virtual_ipaddress {
         192.168.88.100/24
    }
}

两台 keepalived服务器均使用该配置文件,唯一的不同是 priority 的取值在两台服务器上是不同的,我们设置 keepalived 服务器的 priority=100keepalived-backup 的 priority=99

两台服务器设置不同的优先级之后,只要两台服务器都正常工作,则优先级高的为 主服务器,优先级低的为 备服务器。

配置完成后,重启 keepalived 服务

systemctl restart keepalived

然后,我们可以看到 keepalived 服务器绑定了VIP 192.168.88.100

keepalived 服务器

keepalived-backup服务器

我们验证一下主服务器挂掉之后,备份服务器是否能够正常接替工作,在 keepalived 服务器上,执行 systemctl stop keepalived 命令,停止keepalived服务,模拟服务器挂掉的情景,然后我们看到

keepalived 服务器

keepalived-backup服务器

VIP成功漂移到了备份服务器,在备份服务器的/var/log/message日志中,可以看到如下信息

重启 keepalived 服务器的Keepalived服务(systemctl start keepalived),模拟服务器恢复,我们可以看到VIP又重新漂移回了 keepalived 服务器(因为 keepalived 服务器设置的 priority大于 keepalived-backup 服务器的设置)。查看 keepalived-backup 的日志,可以看到下面信息

LVS实现负载均衡

在两台Keepalived服务器的配置文件 /etc/keepalived/keepalived.conf 中,追加以下配置

virtual_server 192.168.88.100 80 {
    ! 健康检查的时间间隔
    delay_loop 6
    ! 负载均衡算法
    lb_algo wlc
    ! LVS模式,支持NAT/DR/TUN模式
    lb_kind DR
    protocol TCP
    nat_mask 255.255.255.0

    ! 真实Web服务器IP,端口
    real_server 192.168.88.10 80 {
        weight 3
        ! Web服务健康检查
        HTTP_GET {
            url {
                path /
                status_code 200
            }
           connect_timeout 1
        }
    }

    ! 真实Web服务器IP,端口
    real_server 192.168.88.11 80 {
        weight 3
        ! Web服务健康检查
        HTTP_GET {
            url {
                path /
                status_code 200
            }
           connect_timeout 1
        }
    }
}

由于我们所有的服务器都在同一个子网中,因此无法使用NAT(Network Address Translation)模式,这里我们使用DSR(Direct Server Return)模式,使用DSR模式(配置时使用DR),需要web服务器将VIP绑定到自己的本地回环网卡上去,否则无法与web服务器通信。在 node-1 和 node-2 上,执行下面的命令

ip addr add 192.168.88.100/32 dev lo

这里绑定的VIP只在本次设置有效,服务器重启后需要再次执行,因此,可以通过下面的方法永久的添加该IP

/etc/sysconfig/network-scripts目录下,创建ifcfg-lo:0文件

DEVICE=lo:0
IPADDR=192.168.88.100
NETMASK=255.255.255.255
ONBOOT=yes
NAME=loopback

然后重启网络服务(systemctl restart network)让其生效即可

接下来,重启两台 keepalived 服务器的服务就可以生效了

systemctl restart keepalived

然后我们在客户端访问以下我们的web服务,这里我们就可以使用VIP来访问了

可以看到,请求被分配到了两台真实的web服务器。在 keepalived 服务器上执行 ipvsadm

如果此时node-1的服务挂了怎么办?我们来模拟一下,在node-1上面,我们停止web服务

systemctl stop openresty 

等几秒之后(我们配置健康检查周期为6s)然后再来请求

在 keepalived 服务器上执行 ipvsadm

可以看到,有问题的 node-1 已经被剔除了。

扩展阅读

这里你可能会有两个疑问:

第一个是为什么无法使用NAT模式?

使用NAT模式,正常的流程应该是这样的,在NAT模式下,客户端(192.168.1.2)请求经过负载均衡器(192.168.88.100)后,负载均衡器会修改目的IP地址为真实的web服务器IP地址 192.168.88.10,这样web服务器收到请求后,发现目的IP地址是自己,就可以处理该请求了。响应报文发送给负载均衡器,负载均衡器修改响应报文的源IP地址为自身VIP,这样客户端收到响应后就能够正常处理了。

我们的客户端和服务器都在同一个子网下。处理完成后响应给客户端时,响应报文的源IP地址为 192.168.88.10,目的IP为 192.168.88.2,由于在同一个子网中,因此不会经过负载均衡器,而是直接将报文发送给了客户端。因此在响应报文中,源IP地址尚未经过修改直接发送给了客户端,导致无法正常完成通信。

第二个是为什么使用DSR模式必须将VIP绑定到web服务器的网卡上去?

在DSR模式下,发送给负载均衡器的报文没有经过任何修改就直接发送给了真实的web服务器,这时候目的IP地址是 VIP 192.168.88.100,Web服务器收到该请求之后,发现目的IP地址不是自己,会认为这个报文不是发送给自己的,无法处理该请求。也就是说,在使用DSR模式下,仅仅在负载均衡器上做配置是无法实现负载均衡的。因此最简单的方式就是将VIP绑定到真实服务器的回环接口上。之所以子网掩码时 255.255.255.255(或者/32),是让其广播地址是其自身,避免其发送ARP到该子网的广播域,防止负载均衡器上的VIP和Web服务器的IP冲突。

对于负载均衡算法,我们这里采用了wlc(加权最小连接调度)。其它调度算法如下(图来自 《24小时365天不间断服务:服务器基础设施核心技术》一书)

总结

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

通过本文,相信你已经可以搭建一套高可用的Web服务了,Keepalived还有很多配置选项等待大家自己去发掘,我们不仅可以实现Web服务的高可用,还可以用来实现一些基础服务组件的高可用,比如MySQL、Redis、RabbitMQ等,本文也只是抛砖引玉了。

参考文献

  • 24小时365天不间断服务:服务器基础设施核心技术

Linux服务器下的HTTP抓包分析

DSC09922

说到抓包分析,最简单的办法莫过于在客户端直接安装一个Wireshark或者Fiddler了,但是有时候由于客户端开发人员(可能是第三方)知识欠缺或者其它一些原因,无法顺利的在客户端进行抓包分析,这种情况下怎么办呢?

本文中,我们将给大家介绍在服务端进行抓包分析的方法,使用tcpdump抓包,配合Wireshark对HTTP请求进行分析,非常简单有效。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

使用tcpdump在服务器抓包

在服务端进行抓包分析,使用tcpdump

tcpdump -tttt -s0 -X -vv tcp port 8080 -w captcha.cap

这里的参数是这样的

  • -tttt 输出最大程度可读的时间戳
  • -s0 指定每一个包捕获的长度,单位是byte,使用-s0可以捕获整个包的内容
  • -X 以hex和ASCII两种形式显示包的内容
  • -vv 显示更加多的包信息
  • tcp 指我们只捕获tcp流量
  • port 8080 指我们只捕获端口8080的流量
  • -w captcha.cap 指定捕获的流量结果输出到captcha.cap文件,便于分析使用

关于tcpdump更加高级的用法,可以参考 tcpdump简明教程

上述命令会保持运行,并将结果输出到 captcha.cap 文件中,在这个过程中,所有访问 8080 端口的 TCP 流量都会被捕获。当请求结束之后,我们可以使用 Ctrl+C 中断该命令的执行,这时候在当前目录下就可以看到生成了一个名为 captcha.cap 的文件。

使用Wireshark分析

接下来我们从服务器上下载这个captcha.cap文件到自己电脑上,使用 Wireshark 打开

最简单的下载方法当然是使用scp了

scp account@ip:/path/to/captcha.cap .

因为我们需要分析http包,直接打开看显然无法区分我们需要的内容,因此,可以在filter栏中添加过滤规则 http,这样就可以只展示http流量了

当请求比较多的时候,我们还是无法快速区分出哪个是指定客户端的访问请求,好在强大的filter可以组合使用

http and ip.src == 192.168.0.65    

上面这个filter将会过滤出所有来自客户端 192.168.0.65 的http流量。

找到我们需要分析的http请求了,那么怎么查看请求响应的内容呢?也很简单,只需要选中这个请求,右键 FollowHTTP Stream

在新开的窗口中,我们就可以看到这个请求的所有内容了

总结

tcpdump和wireshark都是非常强大的网络分析工具,其使用用途不仅仅局限于http请求抓包,借助这两个工具,我们可以对所有的网络流量,网络协议进行分析。本文只是针对最常见的http请求抓包方法做了一个简单的讲解,实际上配合wireshark强大的filter规则,我们可以更加精准的对流量进行过滤,分析。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

RabbitMQ实现延时重试队列

RabbitMQ是一款使用Erlang开发的开源消息队列。本文假设读者对RabbitMQ是什么已经有了基本的了解,如果你还不知道它是什么以及可以用来做什么,建议先从官网的 RabbitMQ Tutorials 入门教程开始学习。

本文将会讲解如何使用RabbitMQ实现延时重试和失败消息队列,实现可靠的消息消费,消费失败后,自动延时将消息重新投递,当达到一定的重试次数后,将消息投递到失败消息队列,等待人工介入处理。在这里我会带领大家一步一步的实现一个带有失败重试功能的发布订阅组件,使用该组件后可以非常简单的实现消息的发布订阅,在进行业务开发的时候,业务开发人员可以将主要精力放在业务逻辑实现上,而不需要花费时间去理解RabbitMQ的一些复杂概念。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

概要

我们将会实现如下功能

  • 结合RabbitMQ的Topic模式和Work Queue模式实现生产方产生消息,消费方按需订阅,消息投递到消费方的队列之后,多个worker同时对消息进行消费
  • 结合RabbitMQ的 Message TTLDead Letter Exchange 实现消息的延时重试功能
  • 消息达到最大重试次数之后,将其投递到失败队列,等待人工介入处理bug后,重新将其加入队列消费

具体流程见下图

xxx

  1. 生产者发布消息到主Exchange
  2. 主Exchange根据Routing Key将消息分发到对应的消息队列
  3. 多个消费者的worker进程同时对队列中的消息进行消费,因此它们之间采用“竞争”的方式来争取消息的消费
  4. 消息消费后,不管成功失败,都要返回ACK消费确认消息给队列,避免消息消费确认机制导致重复投递,同时,如果消息处理成功,则结束流程,否则进入重试阶段
  5. 如果重试次数小于设定的最大重试次数(3次),则将消息重新投递到Retry Exchange的重试队列
  6. 重试队列不需要消费者直接订阅,它会等待消息的有效时间过期之后,重新将消息投递给Dead Letter Exchange,我们在这里将其设置为主Exchange,实现延时后重新投递消息,这样消费者就可以重新消费消息
  7. 如果三次以上都是消费失败,则认为消息无法被处理,直接将消息投递给Failed Exchange的Failed Queue,这时候应用可以触发报警机制,以通知相关责任人处理
  8. 等待人工介入处理(解决bug)之后,重新将消息投递到主Exchange,这样就可以重新消费了

技术实现

Linus Torvalds 曾经说过

Talk is cheap. Show me the code

我分别用Java和PHP实现了本文所讲述的方案,读者可以通过参考代码以及本文中的基本步骤来更好的理解

创建Exchange

为了实现消息的延时重试和失败存储,我们需要创建三个Exchange来处理消息。

  • master 主Exchange,发布消息时发布到该Exchange
  • master.retry 重试Exchange,消息处理失败时(3次以内),将消息重新投递给该Exchange
  • master.failed 失败Exchange,超过三次重试失败后,消息投递到该Exchange

所有的Exchange声明(declare)必须使用以下参数

参数 说明
exchange Exchange名称
type topic Exchange 类型
passive false 如果Exchange已经存在,则返回成功,不存在则创建
durable true 持久化存储Exchange,这里仅仅是Exchange本身持久化,消息和队列需要单独指定其持久化
no-wait false 该方法需要应答确认

Java代码

// 声明Exchange:主体,失败,重试
channel.exchangeDeclare("master", "topic", true);
channel.exchangeDeclare("master.retry", "topic", true);
channel.exchangeDeclare("master.failed", "topic", true);

PHP代码

// 普通交换机
$this->channel->exchange_declare('master', 'topic', false, true, false);
// 重试交换机
$this->channel->exchange_declare('master.retry', 'topic', false, true, false);
// 失败交换机
$this->channel->exchange_declare('master.failed', 'topic', false, true, false);

在RabbitMQ的管理界面中,我们可以看到创建的三个Exchange

消息发布

消息发布时,使用basic_publish方法,参数如下

参数 说明
message 发布的消息对象
exchange master 消息发布到的Exchange
routing-key 路由KEY,用于标识消息类型
mandatory false 是否强制路由,指定了该选项后,如果没有订阅该消息,则会返回路由不可达错误
immediate false 指定了当消息无法直接路由给消费者时如何处理

发布消息时,对于message对象,其内容建议使用json编码后的字符串,同时消息需要标识以下属性

'delivery_mode'=> 2 // 1为非持久化,2为持久化

Java代码

channel.basicPublish(
    "master", 
    routingKey, 
    MessageProperties.PERSISTENT_BASIC, // delivery_mode
    message.getBytes()
);

PHP代码

$msg = new AMQPMessage($message->serialize(), [
    'delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT,
]);

$this->channel->basic_publish($msg, 'master', $routingKey);

消息订阅

消息订阅的实现相对复杂一些,需要完成队列的声明以及队列和Exchange的绑定。

Declare Queue

对于每一个订阅消息的服务,都必须创建一个该服务对应的队列,将该队列绑定到关注的路由规则,这样之后,消息生产者将消息投递给Exchange之后,就会按照路由规则将消息分发到对应的队列供消费者消费了。

消费服务需要declare三个队列

  • [queue_name] 队列名称,格式符合 [服务名称]@订阅服务标识
  • [queue_name]@retry 重试队列
  • [queue_name]@failed 失败队列

订阅服务标识是客户端自己对订阅的分类标识符,比如用户中心服务(服务名称ucenter),包含两个订阅:user和enterprise,这里两个订阅的队列名称就为 ucenter@userucenter@enterprise,其对应的重试队列为 ucenter@user@retryucenter@enterprise@retry

Declare队列时,参数规定规则如下

参数 说明
queue 队列名称
passive false 队列不存在则创建,存在则直接成功
durable true 队列持久化
exclusive false 排他,指定该选项为true则队列只对当前连接有效,连接断开后自动删除
no-wait false 该方法需要应答确认
auto-delete false 当不再使用时,是否自动删除

对于@retry重试队列,需要指定额外参数

'x-dead-letter-exchange' => 'master'
'x-message-ttl'          => 30 * 1000 // 重试时间设置为30s

这里的两个header字段的含义是,在队列中延迟30s后,将该消息重新投递到x-dead-letter-exchange对应的Exchange中

Java代码

// 声明监听队列
channel.queueDeclare(
    queueName, // 队列名称
    true,      // durable
    false,     // exclusive
    false,     // autoDelete
    null       // arguments
);
channel.queueDeclare(queueName + "@failed", true, false, false, null);

Map<String, Object> arguments = new HashMap<String, Object>();
arguments.put("x-dead-letter-exchange", exchangeName());
arguments.put("x-message-ttl", 30 * 1000);
channel.queueDeclare(queueName + "@retry", true, false, false, arguments);

PHP代码

$this->channel->queue_declare($queueName, false, true, false, false, false);
$this->channel->queue_declare($failedQueueName, false, true, false, false, false);
$this->channel->queue_declare(
    $retryQueueName, // 队列名称
    false,           // passive
    true,            // durable
    false,           // exclusive
    false,           // auto_delete
    false,           // nowait
    new AMQPTable([
        'x-dead-letter-exchange' => 'master',
        'x-message-ttl'          => 30 * 1000,
    ])
);

在RabbitMQ的管理界面中,Queues部分可以看到我们创建的三个队列

查看队列的详细信息,我们可以看到 queueName@retry 队列与其它两个队列的不同

Bind Exchange & Queue

创建完队列之后,需要将队列与Exchange绑定(bind),不同队列需要绑定到之前创建的对应的Exchange上面

Queue Exchange
[queue_name] master
[queue_name]@retry master.retry
[queue_name]@failed master.failed

绑定时,需要提供订阅的路由KEY,该路由KEY与消息发布时的路由KEY对应,区别是这里可以使用通配符同时订阅多种类型的消息。

参数 说明
queue 绑定的队列
exchange 绑定的Exchange
routing-key 订阅的消息路由规则
no-wait false 该方法需要应答确认

Java代码

// 绑定监听队列到Exchange
channel.queueBind(queueName, "master", routingKey);
channel.queueBind(queueName + "@failed", "master.failed", routingKey);
channel.queueBind(queueName + "@retry", "master.retry", routingKey);

PHP代码

$this->channel->queue_bind($queueName, 'master', $routingKey);
$this->channel->queue_bind($retryQueueName, 'master.retry', $routingKey);
$this->channel->queue_bind($failedQueueName, 'master.failed', $routingKey);

在RabbitMQ的管理界面中,我们可以看到该队列与Exchange和routing-key的绑定关系

消息消费实现

使用 basic_consume 对消息进行消费的时候,需要注意下面参数

参数 说明
queue 消费的队列名称
consumer-tag 消费者标识,留空即可
no_local false 如果设置了该字段,服务器将不会发布消息到 发布它的客户端
no_ack false 需要消费确认应答
exclusive false 排他访问,设置后只允许当前消费者访问该队列
nowait false 该方法需要应答确认

消费端在消费消息时,需要从消息中获取消息被消费的次数,以此判断该消息处理失败时重试还是发送到失败队列。

Java代码

protected Long getRetryCount(AMQP.BasicProperties properties) {
    Long retryCount = 0L;
    try {
        Map<String, Object> headers = properties.getHeaders();
        if (headers != null) {
            if (headers.containsKey("x-death")) {
                List<Map<String, Object>> deaths = (List<Map<String, Object>>) headers.get("x-death");
                if (deaths.size() > 0) {
                    Map<String, Object> death = deaths.get(0);
                    retryCount = (Long) death.get("count");
                }
            }
        }
    } catch (Exception e) {}

    return retryCount;
}

PHP代码

protected function getRetryCount(AMQPMessage $msg): int
{
    $retry = 0;
    if ($msg->has('application_headers')) {
        $headers = $msg->get('application_headers')->getNativeData();
        if (isset($headers['x-death'][0]['count'])) {
            $retry = $headers['x-death'][0]['count'];
        }
    }

    return (int)$retry;
}

消息消费完成后,需要发送消费确认消息给服务端,使用basic_ack方法

ack(delivery-tag=消息的delivery-tag标识)

Java代码

// 消息消费处理
Consumer consumer = new DefaultConsumer(channel) {
    @Override
    public void handleDelivery(String consumerTag, Envelope envelope,
                               AMQP.BasicProperties properties, byte[] body) throws IOException {
        ...
        // 注意,由于使用了basicConsume的autoAck特性,因此这里就不需要手动执行
        // channel.basicAck(envelope.getDeliveryTag(), false);
    }
};
// 执行消息消费处理
channel.basicConsume(
    queueName, 
    true, // autoAck
    consumer
);

PHP代码

$this->channel->basic_consume(
    $queueName,
    '',    // customer_tag
    false, // no_local
    false, // no_ack
    false, // exclusive
    false, // nowait
    function (AMQPMessage $msg) use ($queueName, $routingKey, $callback) {
        ...
        $msg->delivery_info['channel']->basic_ack($msg->delivery_info['delivery_tag']);
    }
);

如果消息处理中出现异常,应该将该消息重新投递到重试Exchange,等待下次重试

basic_publish(msg, 'master.retry', routing-key)
ack(delivery-tag) // 不要忘记了应答消费成功消息

如果判断重试次数大于3次,仍然处理失败,则应该讲消息投递到失败Exchange,等待人工处理

basic_publish(msg, 'master.failed', routing-key)
ack(delivery-tag) // 不要忘记了应答消费成功消息

一定不要忘记ack消息,因为重试、失败都是通过将消息重新投递到重试、失败Exchange来实现的,如果忘记ack,则该消息在超时或者连接断开后,会重新被重新投递给消费者,如果消费者依旧无法处理,则会造成死循环。

Java代码

try {
    String message = new String(body, "UTF-8");
    // 消息处理函数
    handler.handle(message, envelope.getRoutingKey());

} catch (Exception e) {
    long retryCount = getRetryCount(properties);
    if (retryCount > 3) {
        // 重试次数大于3次,则自动加入到失败队列
        channel.basicPublish("master.failed", envelope.getRoutingKey(), MessageProperties.PERSISTENT_BASIC, body);
    } else {
        // 重试次数小于3,则加入到重试队列,30s后再重试
        channel.basicPublish("master.retry", envelope.getRoutingKey(), properties, body);
    }
}

失败任务重试

如果任务重试三次仍未成功,则会被投递到失败队列,这时候需要人工处理程序异常,处理完毕后,需要将消息重新投递到队列进行处理,这里唯一需要做的就是从失败队列订阅消息,然后获取到消息后,清空其application_headers头信息,然后重新投递到master这个Exchange即可。

Java代码

channel.basicPublish(
    'master', 
    envelope.getRoutingKey(),
    MessageProperties.PERSISTENT_BASIC,
    body
);

PHP代码

$msg->set('application_headers', new AMQPTable([]));
$this->channel->basic_publish(
    $msg,
    'master',
    $msg->get('routing_key')
);

怎么使用

队列和Exchange以及发布订阅的关系我们就说完了,那么使用起来是什么效果呢?这里我们以Java代码为例

// 发布消息
Publisher publisher = new Publisher(factory.newConnection(), 'master');
publisher.publish("{\"id\":121, \"name\":\"guanyiyao\"}", "user.create");

// 订阅消息
new Subscriber(factory.newConnection(), Main.EXCHANGE_NAME)
    .init("user-monitor", "user.*")
    .subscribe((message, routingKey) -> {
        // TODO 业务逻辑
        System.out.printf("    <%s> message consumed: %s\n", routingKey, message);
    }
);

总结

使用RabbitMQ时,实现延时重试和失败队列的方式并不仅仅局限于本文中描述的方法,如果读者有更好的实现方案,欢迎拍砖,在这里我也只是抛砖引玉了。本文中讲述的方法还有很多优化空间,读者也可以试着去改进其实现方案,比如本文中使用了三个Exchagne,是否只使用一个Exchange也能实现本文中所讲述的功能。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

tcpdump简明教程

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

本文翻译自 A tcpdump Tutorial and Primer with Examples 一文,在使用Linux系统进行网络抓包分析的时候,一直没有找到比较简便的非图形界面的方法,在Linux系统下tcpdump命令确实是一柄利器,但是一直苦于学习成本较高,迟迟没有下手。看了 A tcpdump Tutorial and Primer with Examples 这篇文章之后,发现其实使用tcpdump也没有那么困难,特别是其导出的cap文件,再使用wireshark等图形界面软件打开分析非常方便。因此,将其翻译出来,一方面方便自己学习,一方面也为像我一样对tcpdump感兴趣的人提供一个学习途径。

概述

对于专业的信息安全人员来说,tcpdump 是非常重要的网络分析工具。对于任何想深入理解TCP/IP的人来说,掌握该工具的使用时非常必要的。很多人更喜欢高级的分析工具,比如Wireshark,但我相信通常情况下这是个错误的选择。

当使用工具对网络进行分析的时候,更重要的是人对结果的分析,而不是应用的分析。这就促使了对TCP/IP协议栈的理解,因此,我强烈建议学会使用 tcpdump 代替其它工具。

15:31:34.079416 IP (tos 0x0, ttl 64, id 20244, offset 0, flags [DF], 
proto: TCP (6), length: 60) source.35970 > dest.80: S, cksum 0x0ac1 
(correct), 2647022145:2647022145(0) win 5840 0x0000: 4500 003c 4f14 
4006 7417 0afb 0257  E..  0x0010: 4815 222a 8c82 0050 9dc6 5a41 0000 
0000  H."*...P..ZA.... 0x0020: a002 16d0 0ac1 0000 0204 05b4 
0402 080a  ................ 0x0030: 14b4 1555 0000 0000 0103 0302

TABLE 1. 原生 TCP/IP 输出

基础

下面是一些用来配置 tcpdump 的选项,它们非常容易被遗忘,也容易和其它类型的过滤器比如Wireshark等混淆。

选项

  • -i any 监听所有的网卡接口,用来查看是否有网络流量
  • -i eth0 只监听eth0网卡接口
  • -D 显示可用的接口列表
  • -n 不要解析主机名
  • -nn 不要解析主机名或者端口名
  • -q 显示更少的输出(更加quiet)
  • -t 输出可读的时间戳
  • -tttt 输出最大程度可读的时间戳
  • -X 以hex和ASCII两种形式显示包的内容
  • -XX-X类似,增加以太网header的显示
  • -v, -vv, -vvv 显示更加多的包信息
  • -c 只读取x个包,然后停止
  • -s 指定每一个包捕获的长度,单位是byte,使用-s0可以捕获整个包的内容
  • -S 输出绝对的序列号
  • -e 获取以太网header
  • -E 使用提供的秘钥解密IPSEC流量

表达式

tcpdump中,可以使用表达式过滤指定类型的流量。有三种主要的表达式类型:typedirproto

  • 类型(type)选项包含:hostnetport
  • 方向(dir)选项包含:srcdst
  • 协议(proto)选项包含:tcpudpicmpah

示例

捕获所有流量

查看所有网卡接口上发生了什么

tcpdump -i any

指定网卡接口

查看指定网卡上发生了什么

tcpdump -i eth0

原生输出

查看更多的信息,不解析主机名和端口号,显示绝对序列号,可读的时间戳

tcpdump -ttttnnvvS

查看指定IP的流量

这是最常见的方式,这里只查看来自或者发送到IP地址1.2.3.4的流量。

tcpdump host 1.2.3.4

查看更多的包信息,输出HEX

当你需要查看包中的内容时,使用hex格式输出是非常有用的。

# tcpdump -nnvXSs 0 -c1 icmp

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
16:08:16.791604 IP (tos 0x0, ttl 64, id 34318, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.102.35 > 114.114.114.114: ICMP 192.168.102.35 udp port 50694 unreachable, length 36
    IP (tos 0x0, ttl 152, id 0, offset 0, flags [none], proto UDP (17), length 112)
    114.114.114.114.53 > 192.168.102.35.50694: [|domain]
    0x0000:  5869 6c88 7f64 784f 4392 ed7e 0800 4500  Xil..dxOC..~..E.
    0x0010:  0038 860e 0000 4001 e906 c0a8 6623 7272  .8....@.....f#rr
    0x0020:  7272 0303 3665 0000 0000 4500 0070 0000  rr..6e....E..p..
    0x0030:  0000 9811 16cd 7272 7272 c0a8 6623 0035  ......rrrr..f#.5
    0x0040:  c606 005c 0000                           ...\..
1 packet captured
357 packets received by filter
0 packets dropped by kernel

使用源和目的地址过滤

tcpdump src 2.3.4.6
tcpdump dst 3.4.5.6

过滤某个子网的数据包

tcpdump net 1.2.3.0/24

过滤指定端口相关的流量

tcpdump port 3389
tcpdump src port 1025

过滤指定协议的流量

tcpdump icmp

只显示IPV6流量

tcpdump ip6

使用端口范围过滤

tcpdump portrange 21-23

基于包的大小过滤流量

tcpdump less 32
tcpdump greater 64
tcpdump <=128

将捕获的内容写入文件

使用-w选项可以将捕获的数据包信息写入文件以供以后分析,这些文件就是著名的PCAP(PEE-cap)文件,很多应用都可以处理它。

tcpdump port 80 -w capture_file

使用tcpdump加载之前保存的文件进行分析

tcpdump -r capture_file

高级

使用组合语句可以完成更多高级的过滤。

  • AND: and or &&
  • OR: or or ||
  • EXCEPT: not or !

过滤指定源IP和目的端口

tcpdump -nnvvS src 10.5.2.3 and dst port 3389

过滤指定网络到另一个网络

比如下面这个,查看来自192.168.x.x的,并且目的为10.x或者172.16.x.x的所有流量,这里使用了hex输出,同时不解析主机名

tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or 172.16.0.0/16

过滤到指定IP的非ICMP报文

tcpdump dst 192.168.0.2 and src net and not icmp

过滤来自非指定端口的指定主机的流量

下面这个过滤出所有来自某个主机的非ssh流量

tcpdump -vv src mars and not dst port 22

复杂分组和特殊字符

当构建复杂的过滤规则的时候,使用单引号将规则放到一起是个很好的选择。特别是在包含()的规则中。比如下面的规则就是错误的,因为括号在shell中会被错误的解析,可以对括号使用\进行转义或者使用单引号

tcpdump src 10.0.2.3 and (dst port 3389 or 22)

应该修改为

tcpdump 'src 10.0.2.3 and (dst port 3389 or 22)'

隔离指定的TCP标识

可以基于指定的TCP标识(flag)来过滤流量。

下面的过滤规则中,tcp[13]表示在TCP header中的偏移位置13开始,后面的数字代表了匹配的byte数。

显示所有的URGENT (URG)包

tcpdump 'tcp[13] & 32!=0'

显示所有的ACKNOWLEDGE (ACK)包

tcpdump 'tcp[13] & 16!=0'

显示所有的PUSH(PSH)包

tcpdump 'tcp[13] & 8!=0'

显示所有的RESET(RST)包

tcpdump 'tcp[13] & 4!=0'

显示所有的SYNCHRONIZE (SYN) 包

tcpdump 'tcp[13] & 2!=0'

显示所有的FINISH(FIN)包

tcpdump 'tcp[13] & 1!=0'

显示说有的SYNCHRONIZE/ACKNOWLEDGE (SYNACK)包

tcpdump 'tcp[13]=18'

其它方式

与大多数工具一样,也可以使用下面这种方式来捕获指定TCP标识的流量

tcpdump 'tcp[tcpflags] == tcp-syn'
tcpdump 'tcp[tcpflags] == tcp-rst'
tcpdump 'tcp[tcpflags] == tcp-fin'

识别重要流量

最后,这里有一些重要的代码片段你可能需要,它们用于过滤指定的流量,例如畸形的或者恶意的流量。

过滤同时设置SYN和RST标识的包(这在正常情况下不应该发生)

tcpdump 'tcp[13] = 6'

过滤明文的HTTP GET请求

tcpdump 'tcp[32:4] = 0x47455420'

通过横幅文本过滤任意端口的SSH连接

tcpdump 'tcp[(tcp[12]>>2):4] = 0x5353482D'

过滤TTL小于10的包(通常情况下是存在问题或者在使用traceroute)

tcpdump 'ip[8] < 10'

过滤恶意的包

tcpdump 'ip[6] & 128 != 0'

补充(非原文内容)

下面这个命令用于过滤所有与8080端口相关的tcp流量,将其输出到capcha.cap文件中,我们可以使用wireshark打开这个文件,更加可视化的分析过滤其中包含的http流量。

tcpdump -tttt -s0 -X -vv tcp port 8080 -w captcha.cap

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=30w4cly1rgsgo

Linux必知必会-理解内存使用统计命令free

本文详细介绍了Linux系统中的free命令的使用方法以及关键参数的含义,这可能是你见过的关于free命令最详细的一篇文章了,绝对值得你收藏。

free命令显示了Linux系统中物理内存、交换分区的使用统计信息。

指标说明

使用free命令查看内存信息,最重要的是理解当前系统的可用内存并不是直接看 free 字段就可以看出来的,应该参考的是

可用内存 = free + buffers + cached

除去标题行之后,第一行为 物理内存使用统计

标题 说明
total 物理内存总量 total = used + free
used 已使用内存总量,包含应用使用量+buffer+cached
free 空闲内存总量
shared 共享内存总量
buffers 块设备所占用的缓存
cached 普通文件数据所占用的缓存
available 当前可用内存总量(可用于分配给应用的,不包含虚拟内存)

对于available字段,在内核3.14中,它会从/proc/meminfo中的MemAvailable读取,在内核2.6.27+的系统上采用模拟的方式获取,其它情况下直接与free的值相同。

第二行-/+ buffers/cache 中只有两列usedfree有值,它们是物理内存的调整值

标题 说明
used 已使用内存(used)减去buffer和cached之后的内存,也就是应用正在使用的内存总量
free 空闲内存加上buffer和cached之后的内存,也就是真正的可用内存总量

第三行为交换分区使用统计

标题 说明
total 交换分区内存总量
used 正在使用的交换分区内存
free 空闲交换分区内存

在上面这些指标中,我们需要注意的是在下面这些情况下,系统是正常的,不需要担心

  • 空闲内存free接近于0
  • 已使用内存used接近于total
  • 可用内存(free+buffers/cache)占total的 20% 以上
  • 交换分区内存 swap 没有发生改变

下面情况说明内存过低,需要注意!

  • 可用内存(free+buffers/cache)过低,接近于0的时候
  • 交换分区内存占用swap used增加或者有波动
  • dmesg | grep oom-killer显示有OutOfMemory-killer正在运行

常用参数

选项 说明
-b/k/m/g 以bytes/kilobytes/megabytes/gigabytes为单位显示结果
-h 以人类可读的方式输出统计结果
-t 使用该选项会多显示一行标题为Total的统计信息
-o 禁止显示第二行的缓冲区调整值
-s 每隔多少秒自动刷新结果
-c -s配合使用,控制刷新结果次数
-l 显示高低内存的统计详情
-a 显示可用内存
-V 显示版本号

版本不同,可能部分选项也不相同。

参考示例

# free -t -a -g

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

参考文献

程序猿必读-防范CSRF跨站请求伪造

CSRF(Cross-site request forgery,中文为跨站请求伪造)是一种利用网站可信用户的权限去执行未授权的命令的一种恶意攻击。通过伪装可信用户的请求来利用信任该用户的网站,这种攻击方式虽然不是很流行,但是却难以防范,其危害也不比其他安全漏洞小。

本文将简要介绍CSRF产生的原因以及利用方式,然后对如何避免这种攻击方式提供一些可供参考的方案,希望广大程序猿们都能够对这种攻击方式有所了解,避免自己开发的应用被别人利用。

CSRF也称作one-click attack或者session riding,其简写有时候也会使用XSRF

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

什么是CSRF?

简单点说,CSRF攻击就是 攻击者利用受害者的身份,以受害者的名义发送恶意请求。与XSS(Cross-site scripting,跨站脚本攻击)不同的是,XSS的目的是获取用户的身份信息,攻击者窃取到的是用户的身份(session/cookie),而CSRF则是利用用户当前的身份去做一些未经过授权的操作。

CSRF攻击最早在2001年被发现,由于它的请求是从用户的IP地址发起的,因此在服务器上的web日志中可能无法检测到是否受到了CSRF攻击,正是由于它的这种隐蔽性,很长时间以来都没有被公开的报告出来,直到2007年才真正的被人们所重视。

CSRF有哪些危害

CSRF可以盗用受害者的身份,完成受害者在web浏览器有权限进行的任何操作,想想吧,能做的事情太多了。

  • 以你的名义发送诈骗邮件,消息
  • 用你的账号购买商品
  • 用你的名义完成虚拟货币转账
  • 泄露个人隐私

产生原理以及利用方式

要完成一个CSRF攻击,必须具备以下几个条件:

  • 受害者已经登录到了目标网站(你的网站)并且没有退出
  • 受害者有意或者无意的访问了攻击者发布的页面或者链接地址

(图片来自网络,出处不明,百度来的😂)

整个步骤大致是这个样子的:

  1. 用户小明在你的网站A上面登录了,A返回了一个session ID(使用cookie存储)
  2. 小明的浏览器保持着在A网站的登录状态,事实上几乎所有的网站都是这样做的,一般至少是用户关闭浏览器之前用户的会话是不会结束的
  3. 攻击者小强给小明发送了一个链接地址,小明打开了这个地址,查看了网页的内容
  4. 小明在打开这个地址的时候,这个页面已经自动的对网站A发送了一个请求,这时候因为A网站没有退出,因此只要请求的地址是A的就会携带A的cookie信息,也就是使用A与小明之间的会话
  5. 这时候A网站肯定是不知道这个请求其实是小强伪造的网页上发送的,而是误以为小明就是要这样操作,这样小强就可以随意的更改小明在A上的信息,以小明的身份在A网站上进行操作

利用方式

利用CSRF攻击,主要包含两种方式,一种是基于GET请求方式的利用,另一种是基于POST请求方式的利用。

GET请求利用

使用GET请求方式的利用是最简单的一种利用方式,其隐患的来源主要是由于在开发系统的时候没有按照HTTP动词的正确使用方式来使用造成的。对于GET请求来说,它所发起的请求应该是只读的,不允许对网站的任何内容进行修改

但是事实上并不是如此,很多网站在开发的时候,研发人员错误的认为GET/POST的使用区别仅仅是在于发送请求的数据是在Body中还是在请求地址中,以及请求内容的大小不同。对于一些危险的操作比如删除文章,用户授权等允许使用GET方式发送请求,在请求参数中加上文章或者用户的ID,这样就造成了只要请求地址被调用,数据就会产生修改。

现在假设攻击者(用户ID=121)想将自己的身份添加为网站的管理员,他在网站A上面发了一个帖子,里面包含一张图片,其地址为http://a.com/user/grant_super_user/121

<img src="http://a.com/user/grant_super_user/121" />

设想管理员看到这个帖子的时候,这个图片肯定会自动加载显示的。于是在管理员不知情的情况下,一个赋予用户管理员权限的操作已经悄悄的以他的身份执行了。这时候攻击者121就获取到了网站的管理员权限。

POST请求利用

相对于GET方式的利用,POST方式的利用更加复杂一些,难度也大了一些。攻击者需要伪造一个能够自动提交的表单来发送POST请求。

<script>
$(function() {
    $('#csrf_form').trigger('submit');
});
</script>
<form action="http://a.com/user/grant_super_user" id="csrf_form" method="post">
    <input name="uid" value="121" type="hidden">
</form>

只要想办法实现用户访问的时候自动提交表单就可以了。

如何防范

防范原理

防范Csrf攻击,其实本质就是要求网站能够识别出哪些请求是非正常用户主动发起的。这就要求我们在请求中嵌入一些额外的授权数据,让网站服务器能够区分出这些未授权的请求,比如说在请求参数中添加一个字段,这个字段的值从登录用户的Cookie或者页面中获取的(这个字段的值必须对每个用户来说是随机的,不能有规律可循)。攻击者伪造请求的时候是无法获取页面中与登录用户有关的一个随机值或者用户当前cookie中的内容的,因此就可以避免这种攻击。

防范技术

Synchronizer token pattern

令牌同步模式(Synchronizer token pattern,简称STP)是在用户请求的页面中的所有表单中嵌入一个token,在服务端验证这个token的技术。token可以是任意的内容,但是一定要保证无法被攻击者猜测到或者查询到。攻击者在请求中无法使用正确的token,因此可以判断出未授权的请求。

Cookie-to-Header Token

对于使用Js作为主要交互技术的网站,将csrf的token写入到cookie中

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

然后使用javascript读取token的值,在发送http请求的时候将其作为请求的header

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

最后服务器验证请求头中的token是否合法。

验证码

使用验证码可以杜绝Csrf攻击,但是这种方式要求每个请求都输入一个验证码,显然没有哪个网站愿意使用这种粗暴的方式,用户体验太差,用户会疯掉的。

简单实现STP

首先在index.php中,创建一个表单,在表单中,我们将session中存储的token放入到隐藏域,这样,表单提交的时候token会随表单一起提交

<?php
$token = sha1(uniqid(rand(), true));
$_SESSION['token'] = $token;
?>
<form action="buy.php" method="post">
    <input type="hidden" name="token" value="<?=$token; ?>" />
    ... 表单内容
</form>

在服务端校验请求参数的buy.php中,对表单提交过来的token与session中存储的token进行比对,如果一致说明token是有效的

<?php
if ($_POST['token'] != $_SESSION['token']) {
    // TOKEN无效
    throw new \Exception('Token无效,请求为伪造请求');
}
// TOKEN有效,表单内容处理

对于攻击者来说,在伪造请求的时候是无法获取到用户页面中的这个token值的,因此就可以识别出其创建的伪造请求。

解析Laravel框架中的VerifyCsrfToken中间件

在Laravel框架中,使用了VerifyCsrfToken这个中间件来防范CSRF攻击。

在页面的表单中使用{{ csrf_field() }}来生成token,该函数会在表单中添加一个名为_token的隐藏域,该隐藏域的值为Laravel生成的token,Laravel使用随机生成的40个字符作为防范csrf攻击的token。

$this->put('_token', Str::random(40));

如果请求是ajax异步请求,可以在meta标签中添加token

<meta name="csrf-token" content="{{ csrf_token() }}">

使用jquery作为前端的框架时候,可以通过以下配置将该值添加到所有的异步请求头中

$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
    }
});

在启用session的时候,Laravel会生成一个名为_token的值存储到session中。而使用前面两种方式在页面中加入的token就是使用的这一个值。在用户请求到来时,VerifyCsrfToken中间件会对符合条件的请求进行Csrf检查

if (
  $this->isReading($request) ||
  $this->runningUnitTests() ||
  $this->shouldPassThrough($request) ||
  $this->tokensMatch($request)
) {
  return $this->addCookieToResponse($request, $next($request));
}

throw new TokenMismatchException;

if语句中有四个条件,只要任何一个条件结果为true则任何该请求是合法的,否则就会抛出TokenMismatchException异常,告诉用户请求不合法,存在Csrf攻击。

第一个条件$this->isReading($request)用来检查请求是否会对数据产生修改

protected function isReading($request)
{
    return in_array($request->method(), ['HEAD', 'GET', 'OPTIONS']);
}

这里判断了请求方式,如果是HEADGETOPTIONS这三种请求方式则直接放行。你可能会感到疑惑,为什么GET请求也要放行呢?这是因为Laravel认为这三个请求都是请求查询数据的,如果一个请求是使用GET方式,那无论请求多少次,无论请求参数如何,都不应该最数据做任何修改

第二个条件顾名思义是对单元测试进行放行,第三个是为开发者提供了一个可以对某些请求添加例外的功能,最后一个$this->tokensMatch($request)则是真正起作用的一个,它是Laravel防范Csrf攻击的关键

$sessionToken = $request->session()->token();
$token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');

if (! $token && $header = $request->header('X-XSRF-TOKEN')) {
  $token = $this->encrypter->decrypt($header);
}

if (! is_string($sessionToken) || ! is_string($token)) {
  return false;
}

return hash_equals($sessionToken, $token);

Laravel会从请求中读取_token参数的的值,这个值就是在前面表单中添加的csrf_field()函数生成的。如果请求是异步的,那么会读取X-CSRF-TOKEN请求头,从请求头中读取token的值。

最后使用hash_equals函数验证请求参数中提供的token值和session中存储的token值是否一致,如果一致则说明请求是合法的。

你可能注意到,这个检查过程中也会读取一个名为X-XSRF-TOKEN的请求头,这个值是为了提供对一些javascript框架的支持(比如Angular),它们会自动的对异步请求中添加该请求头,而该值是从Cookie中的XSRF-TOKEN中读取的,因此在每个请求结束的时候,Laravel会发送给客户端一个名为XSRF-TOKEN的Cookie值

$response->headers->setCookie(
    new Cookie(
        'XSRF-TOKEN', $request->session()->token(), time() + 60 * $config['lifetime'],
        $config['path'], $config['domain'], $config['secure'], false
    )
);

写在最后

本文只是对CSRF做了一个简单的介绍,主要是侧重于CSRF是什么以及如何应对CSRF攻击。有一个事实是我们无法回避的:没有绝对安全的系统,你有一千种防御对策,攻击者就有一千零一种攻击方式,但不管如何,我们都要尽最大的努力去将攻击者拦截在门外。如果希望深入了解如何发起一个CSRF攻击,可以参考一下这篇文章 从零开始学CSRF

作为一名web方向的研发人员,无论你是从事业务逻辑开发还是做单纯的技术研究,了解一些安全方面的知识都是很有必要的,多关注一些安全方向的动态,了解常见的攻击方式以及应对策略,必将在你成长为一名大牛的路上为你“推波助澜”。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,更多精彩内容请 follow me

参考

第一次拍星轨

第一次拍星轨,大约半个小时的时间,使用Sony A7的星轨插件拍摄,50张合成,效果略显粗糙,不过作为第一次尝试,也算是没有白白挨冻了。

22535600

2017-02-13 20_14_55

MySQL之ROUND函数四舍五入的陷阱

在MySQL中,ROUND函数用于对查询结果进行四舍五入,不过最近使用ROUND函数四舍五入时意外发现并没有预期的那样,本文将这一问题记录下来,以免大家跟我一样犯同样的错误。

问题描述

假如我们有如下一个数据表test,建表语句如下

CREATE TABLE test (
  id int(11) NOT NULL AUTO_INCREMENT,
  field1 bigint(10) DEFAULT NULL,
  field2 decimal(10,0) DEFAULT NULL,
  field3 int(10) DEFAULT NULL,
  field4 float(15,4) DEFAULT NULL,
  field5 float(15,4) DEFAULT NULL,
  field6 float(15,4) DEFAULT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

我们创建了一个名为test的表,出了id字段之外还包含了多个字段,拥有这不同的数据类型。我们向这个表中插入一条数据

INSERT INTO test (field1, field2, field3, field4, field5, field6) VALUE (100, 100, 100, 1.005, 3.5, 2.5);

插入之后表中的数据是这样的

mysql> select * from test;
+----+--------+--------+--------+--------+--------+--------+
| id | field1 | field2 | field3 | field4 | field5 | field6 |
+----+--------+--------+--------+--------+--------+--------+
|  1 |    100 |    100 |    100 | 1.0050 | 3.5000 | 2.5000 |
+----+--------+--------+--------+--------+--------+--------+
1 row in set (0.00 sec)

如果现在我们执行下面这个SQL,你觉得结果会是什么样的呢?

SELECT
  round(field1 * field4),
  round(field2 * field4),
  round(field3 * field4),
  round(field1 * 1.005),
  round(field2 * 1.005),
  round(field3 * 1.005),
  round(field5),
  round(field6)
FROM test;

最初一直以为这样的结果肯定是都是101,因为上面这六个取值结果都是对100 * 1.005进行四舍五入,结果肯定都是101才对,而后面两个肯定是43才对,但是最终的结果却是与设想的大相径庭

*************************** 1. row ***************************
round(field1 * field4): 100
round(field2 * field4): 100
round(field3 * field4): 100
 round(field1 * 1.005): 101
 round(field2 * 1.005): 101
 round(field3 * 1.005): 101
         round(field5): 4
         round(field6): 2
1 row in set (0.00 sec)

为什么会这样?

同样是100*1.005,为什么从数据库中的字段相乘得到的结果和直接字段与小数相乘得到的不一样呢?

对这个问题百思不得其解,各种百度谷歌无果。。。没办法,还得靠自己,这个时候最有用的就是官网文档了,于是查询了mysql官方文档中关于ROUND函数的部分,其中包含下面两条规则

  • For exact-value numbers, ROUND() uses the “round half up” rule(对于精确的数值,ROUND函数使用四舍五入)
  • For approximate-value numbers, the result depends on the C library. On many systems, this means that ROUND() uses the “round to nearest even” rule: A value with any fractional part is rounded to the nearest even integer. (对于近似值,则依赖于底层的C函数库,在很多系统中ROUND函数会使用“取最近的偶数”的规则)

通过这两条规则,我们可以看出,由于我们在使用两个字段相乘的时候,最终的结果是按照float类型处理的,而在计算机中float类型不是精确的数,因此处理结果会按照第二条来,而直接整数字段与1.005这样的小数运算的结果是因为两个参与运算的值都是精确数,因此按照第一条规则计算。从field5field6执行ROUND函数的结果可以明确的看确实是转换为了最近的偶数。

总结

从这个例子中可以看到,在MySQL中使用ROUND还是要非常需要注意的,特别是当参与计算的字段中包含浮点数的时候,这个时候计算结果是不准确的。

本文将会持续修正和更新,最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目,欢迎 Star,另外,求follow😂。

三十分钟学会SED

本文承接之前写的三十分钟学会AWK一文,在学习完AWK之后,趁热打铁又学习了一下SED,不得不说这两个工具真的堪称文本处理神器,谁用谁知道!本文大部分内容依旧是翻译自Tutorialspoint上的入门教程,这次是 Sed Tutorial 一文,内容做了一些删减和补充,增加了一些原文中没有提及到的语法和命令的讲解,并且对原文所有的示例都一一进行了验证,希望本文对大家学习和了解Sed有所帮助。

Continue reading →

为什么你的命令行程序没有输出

问题描述

为什么你的程序没有输出?请看下面的命令

tail -f logfile | grep 'foo bar' | awk...

执行上述命令,你会发现你的程序没有产生任何输出,只有当logfile的内容足够多的时候才会产生输出,这是怎么回事呢?

原因

在非交互模式下,大多数的UNIX命令行程序都会缓冲它们的输出,这就意味着程序会缓冲一定数量(通常是4kilobytes)的字符再进行输出,而不是直接输出它的每个字符。在上面这种情况下,grep命令会缓冲它的输出,因此后面的awk命令只会收到一大块的输入。

缓冲区的使用极大地提高了I/O操作的效率,通常情况下其缓冲操作对用户是不可见的,不会影响到用户。在交互式的控制台会话中执行tail -f命令是实时的,但是当命令行程序通过管道连接其它程序的时候,命令行程序可能就无法识别最终的输出是否需要(接近)实时了。幸运的是,在UNIX下有一些技术可以用于控制I/O的缓冲行为。

理解缓冲原理,最重要的是要明确的知道,是写入方(writer)使用的缓冲区,而不是读取方(reader)。

什么是交互模式、非交互模式?

交互式模式就是在终端上执行,shell等待你的输入,并且立即执行你提交的命令。这种模式被称作交互式是因为shell与用户进行交互。这种模式也是大多数用户非常熟悉的:登录、执行一些命令、退出。当你退出后,shell也终止了。

shell也可以运行在另外一种模式:非交互式模式,以shell script(非交互)方式执行。在这种模式 下,shell不与你进行交互,而是读取存放在文件中的命令,并且执行它们。当它读到文件的结尾EOF,shell也就终止了。

参考bash 深入理解:交互式shell和非交互式shell、登录shell和非登录shell的区别

解决方案

排除不需要的命令

回到上面的问题,我们有一个命令行管道程序tail -f logfile | grep 'foo bar' | awk ...。因为tail -f永远都不会缓冲它的输出,因此如果只是运行tail -f logfile的话我们的程序是没有问题的。当标准输出是控制台的时候,grep命令不会使用输出缓冲区,因此在交互模式下,我们运行tail -f logfile | grep 'foo bar'也是没有问题的。现在的问题是如果grep命令的输出是通过管道连接到其它程序(例如上例中的awk命令)的话,它会启用输出缓冲区以提高效率。

下面的命令中去掉了grep命令,使用AWK去实现了筛选操作

tail -f logfile | awk '/foo bar/ ...'

但是这样做依然是不够的,比如我们无法实现对结果进行排序。这种情况下怎么办呢,我们应该总是去寻找最简单的方法,或许你的命令行程序已经支持非缓冲的输出了呢!

grep (e.g. GNU version 2.5.1) –line-buffered
sed (e.g. GNU version 4.0.6) -u,–unbuffered
awk (GNU awk, nawk) use the fflush() function
awk (mawk) -W interactive
tcpdump, tethereal -l

为了让我们的整个管道命令可以(近乎)实时的执行,我们需要告诉管道程序中的每个命令禁用输出缓冲区。管道的最后一个命令可以不需要禁用输出缓冲,因为它的输出是控制台。

在C程序中禁用缓冲区

如果带缓冲的程序是使用C语言开发的,或者你拥有他的源码可以修改它,可以使用下面这个函数禁用缓冲

setvbuf(stdout, 0, _IONBF, 0);

通常情况下只需要在main函数的顶部添加该函数即可。不过如果你的程序关闭并且重新打开了标准输出或者是调用了setvbuf()函数,你可能需要更加仔细一点。

unbuffer

expect 的程序包中包含了一个名为 unbuffer 的程序,它可以有效的欺骗其它程序,让它们以为自己总是在交互模式下执行(交互模式下会禁用缓冲)。

tail -f logfile | unbuffer grep 'foo bar' | awk ...

unbufferunbuffer不是标准的POSIX工具,不过不要担心,你的系统中可能已经安装过它们了。

stdbuf

新版的 GNU coreutils (从7.5开始)新增了一个名为 stdbuf 的程序,使用它也可以用来取消程序的输出缓冲。

tail -f logfile | stdbuf -oL grep 'foo bar' | awk ...

上面的代码中,“-oL” 选项告诉程序使用行缓冲模式,也可以使用“-o0”完全禁止缓冲。

stdbuf也不是标准的POSIX工具,但是你的系统中可能也已经安装了。另外,在Mac系统下可能是没有这个命令的,你需要手动去安装 brew install coreutils,安装之后的该工具的名字叫做gstdbuf

参考

本文大部分内容翻译自What is buffering? Or, why does my command line produce no output: tail -f logfile | grep 'foo bar' | awk …,内容有删减。

Scroll Up