GraphicsMagick号称图像处理领域的瑞士军刀。提供了健壮及高效的图像处理工具包和库，支持超过88种主流图片格式包括：BMP，GIF，JPEG，JPEG-2000，PNG，PDF，PNM，TIFF，DPX…

现在最新稳定版本为：1.3.12。安装之前，因为是图片处理，所以需要系统中安装了libpng和libjpeg的开发包，否则的话不会安装这两种文件的支持。

官方下载地址：http://www.graphicsmagick.org/<br><br><br>http://www.imagemagick.org/download/<br><br><br>

命令格式：gm convert [ options ... ] input_file output_file

下面给出一些常用玩法，本文也将陆续添加其他玩法，敬请关注！

重定义尺寸，取样质量

gm convert -quality 80 -resize 100×100 input.jpg output.jpg

加文字水印，指定字体、字体大小、颜色、位置

gm convert -font ArialBold -pointsize 45 -fill red -draw “text 100,100 www.saysth.com” input.jpg output.jpg

加图片水印至右下角，透明度50%

gm composite -gravity southeast -dissolve 50 watermark.png input.jpg output.jpg

加图片水印至制定位置，透明度50%

 gm composite -geometry +50+50 -dissolve 50 watermark.png input.jpg output.jpg<br><br><br>http://www.imagemagick.org/download/

 time包中的Add和Sub的用法，Add用于计算某个时间之前和之后的时间点，Sub用于计算两个时间差

package main

import (

"fmt"

"strings"

"time"

)

func main() {

// Add 时间相加

now := time.Now()

// ParseDuration parses a duration string.

// A duration string is a possibly signed sequence of decimal numbers,

// each with optional fraction and a unit suffix,

// such as "300ms", "-1.5h" or "2h45m".

//  Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

// 10分钟前

m, _ := time.ParseDuration("-1m")

m1 := now.Add(m)

fmt.Println(m1)

// 8个小时前

h, _ := time.ParseDuration("-1h")

h1 := now.Add(8 * h)

fmt.Println(h1)

// 一天前

d, _ := time.ParseDuration("-24h")

d1 := now.Add(d)

fmt.Println(d1)

printSplit(50)

// 10分钟后

mm, _ := time.ParseDuration("1m")

mm1 := now.Add(mm)

fmt.Println(mm1)

// 8小时后

hh, _ := time.ParseDuration("1h")

hh1 := now.Add(hh)

fmt.Println(hh1)

// 一天后

dd, _ := time.ParseDuration("24h")

dd1 := now.Add(dd)

fmt.Println(dd1)

printSplit(50)

// Sub 计算两个时间差

subM := now.Sub(m1)

fmt.Println(subM.Minutes(), "分钟")

sumH := now.Sub(h1)

fmt.Println(sumH.Hours(), "小时")

sumD := now.Sub(d1)

fmt.Printf("%v 天\n", sumD.Hours()/24)

}

func printSplit(count int) {

fmt.Println(strings.Repeat("#", count))

}

 以前总是通过timestamp来防止重放攻击，但是这样并不能保证每次请求都是一次性的。今天看到了一篇文章介绍的通过nonce（Number used once）来保证一次有效，感觉两者结合一下，就能达到一个非常好的效果了。

重放攻击是计算机世界黑客常用的攻击方式之一，所谓重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程。

首先要明确一个事情，重放攻击是二次请求，黑客通过抓包获取到了请求的HTTP报文，然后黑客自己编写了一个类似的HTTP请求，发送给服务器。也就是说服务器处理了两个请求，先处理了正常的HTTP请求，然后又处理了黑客发送的篡改过的HTTP请求。

基于timestamp的方案

每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则认为是非法的请求。

假如黑客通过抓包得到了我们的请求url： 
http://koastal.site/index/Info?uid=ZX07&stime=1480862753&sign=80b886d71449cb33355d017893720666 
其中

$sign=md5($uid.$token.$stime); // 服务器通过uid从数据库中可读出token
1
2

一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以此时请求中的stime参数已经失效了。 
如果黑客修改stime参数为当前的时间戳，则sign参数对应的数字签名就会失效，因为黑客不知道token值，没有办法生成新的数字签名。

但这种方式的漏洞也是显而易见的，如果在60s之后进行重放攻击，那就没办法了，所以这种方式不能保证请求仅一次有效。

基于nonce的方案

nonce的意思是仅一次有效的随机字符串，要求每次请求时，该参数要保证不同，所以该参数一般与时间戳有关，我们这里为了方便起见，直接使用时间戳的16进制，实际使用时可以加上客户端的ip地址，mac地址等信息做个哈希之后，作为nonce参数。 
我们将每次请求的nonce参数存储到一个“集合”中，可以json格式存储到数据库或缓存中。 
每次处理HTTP请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。

假如黑客通过抓包得到了我们的请求url： 
http://koastal.site/index/Info?uid=ZX07&nonce=58442c21&sign=80b886d71449cb33355d017893720666

其中

$sign=md5($uid.$token.$nonce); // 服务器通过uid从数据库中可读出token
1
2

nonce参数在首次请求时，已经被存储到了服务器上的“集合”中，再次发送请求会被识别并拒绝。 
nonce参数作为数字签名的一部分，是无法篡改的，因为黑客不清楚token，所以不能生成新的sign。

这种方式也有很大的问题，那就是存储nonce参数的“集合”会越来越大，验证nonce是否存在“集合”中的耗时会越来越长。我们不能让nonce“集合”无限大，所以需要定期清理该“集合”，但是一旦该“集合”被清理，我们就无法验证被清理了的nonce参数了。也就是说，假设该“集合”平均1天清理一次的话，我们抓取到的该url，虽然当时无法进行重放攻击，但是我们还是可以每隔一天进行一次重放攻击的。而且存储24小时内，所有请求的“nonce”参数，也是一笔不小的开销。

基于timestamp和nonce的方案

那我们如果同时使用timestamp和nonce参数呢？ 
nonce的一次性可以解决timestamp参数60s的问题，timestamp可以解决nonce参数“集合”越来越大的问题。

我们在timestamp方案的基础上，加上nonce参数，因为timstamp参数对于超过60s的请求，都认为非法请求，所以我们只需要存储60s的nonce参数的“集合”即可。

假如黑客通过抓包得到了我们的请求url： 
http://koastal.site/index/Info?uid=ZX07&stime=1480862753&nonce=58442c21&sign=80b886d71449cb33355d017893720666

其中

$sign=md5($uid.$token.$stime.$nonce); // 服务器通过uid从数据库中可读出token
1
2

如果在60s内，重放该HTTP请求，因为nonce参数已经在首次请求的时候被记录在服务器的nonce参数“集合”中，所以会被判断为非法请求。超过60s之后，stime参数就会失效，此时因为黑客不清楚token的值，所以无法重新生成签名。

综上，我们认为一次正常的HTTP请求发送不会超过60s，在60s之内的重放攻击可以由nonce参数保证，超过60s的重放攻击可以由stime参数保证。

因为nonce参数只会在60s之内起作用，所以只需要保存60s之内的nonce参数即可。

我们并不一定要每个60s去清理该nonce参数的集合，只需要在新的nonce到来时，判断nonce集合最后一次修改时间，超过60s的话，就清空该集合，存放新的nonce参数集合。其实nonce参数集合可以存放的时间更久一些，但是最少是60s。

验证流程

//判断stime参数是否有效 if( $now - $stime > 60){     die("请求超时"); } //判断nonce参数是否在“集合”已存在 if( in_array($nonce,$nonceArray) ){     die("请求仅一次有效"); } //验证数字签名     if ( $sign != md5($uid.$token.$stime.$nonce) ){     die("数字签名验证失败"); } //判断是否需要清理nonce集合 if( $now - $nonceArray->lastModifyTime > 60 ){     $nonceArray = null; } //记录本次请求的nonce参数 $nonceArray.push($nonce);   //开始处理合法的请求

 进到/etc/vim/vimrc 使用root，添加

 作者：Vincross

 转载自：http://www.oschina.net/question/271044_2155059?sort=default&p=1#answers

目前有很多Java的RPC框架，有基于Json的，有基于XML，也有基于二进制对象的。

论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC。

现在问题是，遇到怎样的瓶颈了才需要或者说更适合用RPC（比如像阿里这么大的请求并发量，简单的HTTP肯定达不到预期），但问题是大家所在的公司，要有像阿里这么大的量是比较少的，甚至说1/1000的量可能都没有，那我们还需要使用RPC吗？

技术应该不是为了使用新技术而去使用，而应该是旧技术存在某些瓶颈，存在难以支撑或者扩展性越老越差等问题暴露出来之后，用新技术来进行解决。

那RPC最大的优点，或者说它相比简单的HTTP接口，它的优势、更适合它的业务场景是怎样呢？简单的HTTP又哪里不足，哪些场景明显不太适合呢？

---

RPC=Remote Produce Call 是一种技术的概念名词. HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.所以楼主可以换一个问法,为何RPC还有除HTTP 之外的实现法,有何必要.毕竟除了HTTP实现外,私有协议不具备通用性.那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体 案例具体分析了.

------

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑

---

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。 但我们交互是用HTTP接口来交互的，我想转用RPC，但问题是我现在还没发现为什么需要用RPC，我还没能理解它的作用和意义。

用http交互其实就已经属于rpc了。

---------

RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

--------

RPC是一个软件结构概念，是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电？是因为电是可以传输的。至于用铜线还是用铁丝还是其他 种类的导线，也就是用http还是用其他协议的问题了。这个要看什么场景，对性能要求怎么样。比如在java中的最基本的就是RMI技术，它是java原 生的应用层分布式技术。我们可以肯定的是在传输性能方面，RMI的性能是优于HTTP的。那为啥很少用到这个技术？那是因为用这个有很多局限性，首先它要 保证传输的两端都要要用java实现，且两边需要有相同的对象类型和代理接口，不需要容器，但是加大了编程的难度，在应用内部的各个子系统之间还是会看到 他的身影，比如EJB就是基于rmi技术的。这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面，这样减少了网络传输方面 的开发，只需要关注业务开发即可。所以在架构一个软件的时候，不能一定根据需求选定技术。