作者归档：kaisin

常用加密算法

发表于2016年10月24日由kaisin
算法选择：对称加密AES，非对称加密: ECC，消息摘要: MD5，数字签名:DSA


对称加密算法(加解密密钥相同)
名称
密钥长度
运算速度
安全性
资源消耗
DES
56位
较快
低
中
3DES
112位或168位
慢
中
高
AES
128、192、256位
快
高
低


非对称算法(加密密钥和解密密钥不同)
名称
成熟度
安全性(取决于密钥长度)
运算速度
资源消耗
RSA
高
高
慢
高
DSA
高
高
慢
只能用于数字签名
ECC
低
高
快
低(计算量小,存储空间占用小,带宽要求低)


散列算法比较
名称
安全性
速度
SHA-1
高
慢
MD5
中
快


对称与非对称算法比较
名称
密钥管理
安全性
速度
对称算法
比较难,不适合互联网,一般用于内部系统
中
快好几个数量级(软件加解密速度至少快100倍,每秒可以加解密数M比特数据),适合大数据量的加解密处理
非对称算法
密钥容易管理
高
慢,适合小数据量加解密或数据签名


算法选择(从性能和安全性综合)
对称加密: AES(128位),
非对称加密: ECC(160位)或RSA(1024),
消息摘要: MD5
数字签名:DSA
轻量级：TEA、RC系列（RC4），Blowfish （不常换密钥）
速度排名（个人估测，未验证）：IDEA <DES <GASTI28<GOST<AES<RC4<TEA<Blowfish  

简单的加密设计： 用密钥对原文做  异或，置换，代换，移...

继续阅读 →

发表在 technologys | 常用加密算法已关闭评论

linux l2tp

发表于2016年9月30日由kaisin

 

yum install openswan xl2tpd ppp

 

/etc/ipsec.conf

 

config setup
        protostack=netkey
        dumpdir=/var/run/pluto/
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10
        nat_traversal=yes
        oe=off

 

/etc/ipsec.d/l2tp-psk.conf

conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
  &n...

继续阅读 →

发表在 network | linux l2tp已关闭评论

lucene

发表于2016年9月26日由kaisin

lucene3.0中BooleanQuery 实现与或的复合搜索 .
BooleanClause用于表示布尔查询子句关系的类，

包
括：

BooleanClause.Occur.MUST，

BooleanClause.Occur.MUST_NOT，

BooleanClause.Occur.SHOULD。

 

必须包含,不能包含,可以包含三种.有以下6种组合： 
 
1．MUST和MUST：取得连个查询子句的交集。 
2．MUST和MUST_NOT：表示查询结果中不能包含MUST_NOT所对应得查询子句的检索结果。 
3．SHOULD与MUST_NOT：连用时，功能同MUST和MUST_NOT。
4．SHOULD与MUST连用时，结果为MUST子句的检索结果,但是SHOULD可影响排序。
5．SHOULD与SHOULD：表示“或”关系，最终检索结果为所有检索子句的并集。
6．MUST_NOT和MUST_NOT：无意义，检索无结果。

...

构造出“与”的关系: bquery.Add(query, BooleanClause.Occur.MUST);

构造“或”关系：bquery.Add(query, BooleanClause.Occur.SHOULD);

构造“非”关系：bquery.Add(query, ...

继续阅读 →

发表在 search | lucene已关闭评论

Zookeeper的核心：ZAB原子消息广播协议

发表于2016年9月20日由kaisin

　点击查看原图
        ZooKeeper为高可用的一致性协调框架，自然的ZooKeeper也有着一致性算法的实现，ZooKeeper使用的是ZAB协议作为数据一致性的算法，ZAB（ZooKeeper Atomic Broadcast ）全
称为：原子消息广播协议；ZAB可以说是在Paxos算法基础上进行了扩展改造而来的，ZAB协议设计了支持崩溃恢复，ZooKeeper使用单一主进程
Leader用于处理客户端所有事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上；由于事务间可能存在着依赖关系，ZAB
协议保证Leader广播的变更序列被顺序的处理，：一个状态被处理那么它所依赖的状态也已经提前被处理；ZAB协议支持的崩溃恢复可以保证在
Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性；
　　在ZooKeeper中
所有的事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，
并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有过半数（>=N/2+1）的Follower反馈信息后，Leader将再次向集群内F... 继续阅读 →

发表在 technologys | Zookeeper的核心：ZAB原子消息广播协议已关闭评论

TcpTimedWaitDelay/MaxUserPort

发表于2016年9月12日由kaisin

当TCP连接被关闭时，{ Protocol, Local IP, Local Port, Remote IP, Remote Port}五元组就进入TIME_WAIT状态，默认时间是4分钟。可以通过一组命令看看tcp的连接状态：

netstat -ano>>c:\port.txt

本地ip，远程ip，远程端口都是固定的，只有本地端口是变化的，本地端口只能使用1024-5000，因此如果在4分钟内发起了大约4000个连接，这时就会发生异常，下面是使用WCF，客户端的异常:

System.Net.Sockets.SocketException: Only one usage of each socket
address (protocol/network address/port) is normally permitted
192.168.101.5:8888
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.ServiceModel.Channels.SocketConnectio...

继续阅读 →

发表在 network | TcpTimedWaitDelay/MaxUserPort已关闭评论

PPTP/L2TP over PPPoE的準確MTU/MRU值

发表于2016年9月2日由kaisin
Ethernet MinSize = 512bit = 64 Byte
Ethernet MaxSize = 1518 Byte
so Ethernet IP MTU = 1518 - 18 ( 6 SRCMAC+ 6 DSTMAC+ 2 TYPE+ 4 CRC) = 1500 B
so Ethernet IP TCP MSS = 1500 - 40 ( 20 IP_HEADER + 20 TCP_HEADER) = 1460 B
so Ethernet IP UDP MTU/MRU = 1500 - 28 ( 20 IP_HEADER + 8 UDP_HEADER ) = 1472 B
so PPPoE MTU/MRU = 1500 - 8 ( 6 PPPoE_SESSION + 2 PPP_HEADER ) = 1492 B
so TCP over PPPoE MSS = 1492 ( PPPoE MTU/MRU ) - 40 ( 20 IP_HEADER + 20 TCP_HEADER) = 1452
so PPTP MTU/MRU = 1500 - 56 ( 20 IP_HEADER + 20 TCP_HEADER + 12 GRE_HEADER + 4 PPP_HEADER ) = 1444 B
so TCP over PPTP MSS = 1444 ( PPTP MTU/MRU ) -...

继续阅读 →

发表在 technologys | PPTP/L2TP over PPPoE的準確MTU/MRU值已关闭评论

(CORS)Cross-origin resource sharing

发表于2016年8月25日由kaisin

How CORS works:

https://upload.wikimedia.org/wikipedia/commons/c/ca/Flowchart_showing_Simple_and_Preflight_XHR.svg

点击查看原图

 

参考：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

 

 

简单请求：

简单指：

  • 只使用 GET, HEAD 或者 POST 请求方法。如果使用 POST 向服务器端传送数据，则数据类型(Content-Type)只能是 application/x-www-form-urlencoded, multipart/form-data 或 text/plain中的一种。
  • 不会使用自定义请求头（类似于 X-Modified 这种）。

 

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) 
Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+...

继续阅读 →

发表在 http | 标签为 | (CORS)Cross-origin resource sharing已关闭评论

zookeeper

发表于2016年8月15日由kaisin

场景一

有这样一个场景：系
统中有大约100w的用户，每个用户平
均有3个邮箱账号，每隔5分钟，每个邮箱账需要收取100封邮件，最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力，从
多个不同的网路出口进行访问外网，计算的压力得到缓解，那么每台机器的计算压力也不会很大了。

        通过我们的讨论和以往的经验判断在这场景中可以实现并行计算，但我们还期望能对并行计算的节点进行动态的添加/删除，做到在线更新并行计算的数目并且不会影响计算单元中的其他计算节点，但是有4个问题需要解决，否则会出现一些严重的问题：

  1. 20台机器同时工作时，有一台机器down掉了，其他机器怎么进行接管计算任务，否则有些用户的业务不会被处理，造成用户服务终断。
  2. 随着用户数量增加，添加机器是可以解决计算的瓶颈，但需要重启所有计算节点，如果需要，那么将会造成整个系统的不可用。
  3. 用户数量增加或者减少，计算节点中的机器会出现有的机器资源使用率繁忙，有的却空闲，因为计算节点不知道彼此的运行负载状态。
  4. 怎么去通知每个节点彼此的负载状态，怎么保证通知每个计算节点方式的可靠性和实时性。

        先不说那么多专业名词，白话来说我们需要的是...

继续阅读 →

发表在 technologys | zookeeper已关闭评论

ZooKeeper 数据流动图

发表于2016年8月13日由kaisin


ZooKeeper的基本原理

ZooKeeper是以Fast Paxos算法为基础的，通过选举产生一个leader，只有leader才能提交propose，具体算法可见Fast Paxos 。

 

2）ZooKeeper的基本运转流程

ZooKeeper主要存在以下两个流程：

  • 选举Leader
  • 同步数据

选举Leader过程中算法有很多，但要达到的选举标准是一致的：

  • Leader要具有最高的zxid 
  • 集群中大多数的机器得到响应并follow选出的Leader

下图为ZooKeeper数据流动图，比较直观地描述了ZooKeeper是如何同步数据的：

 


点击查看原图

 

 

继续阅读 →

发表在 technologys | ZooKeeper 数据流动图已关闭评论

2016年续费的27家机构

发表于2016年8月12日由kaisin

资料备份供自身查询，资料来源：

中国人民银行公告〔2016〕第17号

http://c.m.163.com/news/a/BU9GAJHN00097U7R.html?spss=newsapp&spsw=1

 

点击查看原图点击查看原图点击查看原图

继续阅读 →

发表在 article | 2016年续费的27家机构已关闭评论

10大基础算法

发表于2016年8月12日由kaisin

一：快速排序算法

 

快速排序是由东尼·霍尔所发展的一种排序算法。在平均状况下，排序 n 个项目要Ο(n log n)次比较。在最坏状况下则需要Ο(n2)次比较，但这种状况并不常见。事实上，快速排序通常明显比其他Ο(n log n) 算法更快，因为它的内部循环（inner loop）可以在大部分的架构上很有效率地被实现出来。

快速排序使用分治法（Divide and conquer）策略来把一个串行（list）分为两个子串行（sub-lists）。

算法步骤：

1 从数列中挑出一个元素，称为 “基准”（pivot），

2 重新排序数列，所有元素比基准值小的摆放在基准前面，所有元素比基准值大的摆在基准的后面（相同的数可以到任一边）。在这个分区退出之后，该基准就处于数列的中间位置。这个称为分区（partition）操作。

3 递归地（recursive）把小于基准值元素的子数列和大于基准值元素的子数列排序。

递归的最底部情形，是数列的大小是零或一，也就是永远都已经被排序好了。虽然一直递归下去，但是这个算法总会退出，因为在每次的迭代（iteration）中，它至少会把一个元素摆到它最后的位置去

点击查看原图


参考：

快速排序

https://zh.wikipedia.org...

继续阅读 →

发表在 technologys | 10大基础算法已关闭评论

OSI 模型与 TCP/IP

发表于2016年8月9日由kaisin

以下是 维基百科 中关于OSI 模型的说明：

开放式系统互联通信参考模型（英语：Open System Interconnection Reference Model，ISO/IEC 7498-1），简称为OSI模型（OSI model），一种概念模型，由国际标准化组织（ISO）提出，一个试图使各种计算机在世界范围内互连为网络的标准框架。

而 TCP/IP 协议可以看做是对 OSI 模型的一种简化（以下内容来自 维基百科）：

它将软件通信过程抽象化为四个抽象层，采取协议堆叠的方式，分别实作出不同通信协议。协议套组下的各种协议，依其功能不同，被分别归属到这四个阶层之中7，常被视为是简化的七层OSI模型。

一张图详细介绍了 TCP/IP 协议族中的各个协议在 OSI模型 中的分布，一图胜千言（下图来自 科来）：
点击查看原图

TCP/IP 协议和 OSI 模型的内容，在互联网上有很多。我没有必要再次介绍它们。在这里，我们只需要知道，HTTP、WebSocket 等协议都是处于 OSI 模型的最高层： 应用层 。而 IP 协议工作在网络层（第3层），TCP 协议工作在传输层（第4层）。

至于 OSI 模型的各个层次都有什么系统和它们对应，这里有篇很好的文章可以满足大家的求知欲：OSI七层模型详解 。
继续阅读 →

发表在 network | 标签为 , | OSI 模型与 TCP/IP已关闭评论

Authorization

发表于2016年8月2日由kaisin

授权模块代码片段:

/// <summary>
    /// HTTP模块默认授权配置
    /// </summary>
    public class Authorization
    {
        Dictionary<string, string> users;
        bool hasValidate;

        /// <summary>
        /// 获取用户总数
        /// </summary>
        public int UserCount
        {
            get
            {
                return this.users.Count;
            }
        }

        /// <summary>
        /// 是否具有验证项
        /// </summary>
        public bool HasValidate
        {
            get { return this.hasValidate; }
        }

...

继续阅读 →

发表在 C# Code | Authorization已关闭评论

CommandLine Parse Code Fragment

发表于2016年7月29日由kaisin

Command Line Parse Code Fragment

 

internal class CommandLine
    {
        /// <summary>
        /// get process command line info
        /// </summary>
        /// <param name="processId"></param>
        /// <returns>command line info, array length is 2, ex: ["C:\Windows\system32\svchost.exe","-k LocalService"]</returns>
        public static String[] GetCommandLineInfo(int processId)
        {
            String[] info = new string[2];
            info[0] = "";
            info[1] = "";
            //
            var command...

继续阅读 →

发表在 C# Code | CommandLine Parse Code Fragment已关闭评论

Quartz Misfire处理规则

发表于2016年7月27日由kaisin
调度(scheduleJob)或恢复调度(resumeTrigger,resumeJob)后不同的misfire对应的处理规则

CronTrigger

withMisfireHandlingInstructionDoNothing
——不触发立即执行
——等待下次Cron触发频率到达时刻开始按照Cron频率依次执行

withMisfireHandlingInstructionIgnoreMisfires
——以错过的第一个频率时间立刻开始执行
——重做错过的所有频率周期后
——当下一次触发频率发生时间大于当前时间后，再按照正常的Cron频率依次执行

withMisfireHandlingInstructionFireAndProceed
——以当前时间为触发频率立刻触发一次执行
——然后按照Cron频率依次执行

SimpleTrigger

withMisfireHandlingInstructionFireNow
——以当前时间为触发频率立即触发执行
——执行至FinalTIme的剩余周期次数
——以调度或恢复调度的时刻为基准的周期频率，FinalTime根据剩余次数和当前时间计算得到
——调整后的FinalTime会略大于根据starttime计算的到的FinalTime值

withMisfireHandlingInstructionIgnor...

继续阅读 →

发表在 technologys | 标签为 , | Quartz Misfire处理规则已关闭评论