别以为是那些软件开发定律,别以为是开发出那些特殊用途的软件,别以为是软件设计技术本身。只有一条真理决定了一个软件程序员的成功还是失败。由于坚持这个真理,一个资深的程序员能在一天的时间里学会一门新的编程语言,而由于不坚持这条真理,一个初级的程序员用十年时间也只能挣到一份糊口的钱、永远是来实现别人的设计、永远不够优秀而得不到晋升的机会。这条真理让你看清了差的程序员和好的程序员的不同之处,好的程序员和伟大的程序员的不同之处,伟大的程序员和能通过自己的技术创造出一个亿万美元价值的程序帝国的超级程序员的不同之处。

不是什么复杂的道理,不是什么难懂的理论。不是具有什么天赋或“编程超能力“才能做到的事情。最终成为的是一个优秀的程序员还是一个很烂的程序员,这跟你的出身一点关系都没有。

而真正的原因只有一个,唯一的一个:

对所做的事情的理解越深,你就会做的越好。

超级程序员跟那些平庸的、一般的程序员比起来,对自己要做的事情的理解要深的多的多。这就是原因。

要想成为一名出色的程序员,你所要做的就是完全的理解要在做的事情。

有人会说,该知道的我都知道了。而对说这话的人的验证就是看他们能有应用他们知道的知识的能力。是否他能够构造出完美的系统架构,让人们能轻松的维护?是否他能在不皱眉头的情况下把一个普通程序员毫无可能解决的问题轻松解决掉?是否他能在被询问时能用最简单的概念把任何问题都阐述明白?如果能够,那他就是一个杰出的程序员,他能很好的理解了他在做的事情。

然而,尽管这些人看起来已经“无所不知”,很多的程序员(包括我)都感觉他们仍然在知识的海洋里奋斗不已。有如此多的东西需要去学习,一个人几乎要花费他毕生的心力去学习,但仍然很难说能掌握计算机知识的90%。

而这场持久战中的秘密武器、战胜计算机知识的亚瑟王的神剑,就是透彻理解。对你的领域里的基础知识理解的越好,你就越容易提升到更高的层次。你对这一层次的知识理解的越好,你就更容易掌握下一层次,以此类推。一旦你从最简单最基础的知识走到最高级最复杂的理论,你可以从头再过一遍,此时你会惊奇的发现,在最低最底的底层,竟然还有那么多知识需要学习。

看起来这个道理实在是太简单,难以受到重视,但事实就是这样。通往杰出的程序员的道路就是完全的深入的理解,从掌握精通最基本的知识开始,从而逐渐牢固掌握更高级的知识。

我不想骗你—这是一个很长的路程。但你是值得去做的。在路的尽头,你会突然发现,自己神奇的成为了一位资深的程序员,受到所有人的尊敬。你能成为一位神奇的程序员,任何事情都难不倒的程序员,让其他程序员都羡慕的程序员。谁能预料到呢?我不能告诉你你该做什么或能成为什么。但我可以告诉你我发现一些真实的道理和有价值的东西。怎么去做全在于自己。

-Max

posted @ 2013-06-24 14:24 小马歌 阅读(204) | 评论 (0)编辑 收藏
 
本文将探讨单例模式的各种情况,并给出相应的建议。单例模式应该是设计模式中比较简单的一个,但是在多线程并发的环境下使用却是不那么简单了。
首先看最原始的单例模式。
1 package xylz.study.singleton;
2 
3 public class Singleton {
4 
5     private static Singleton instance = null;
6 
7     private Singleton() {
8     }
9 
10     public static Singleton getInstance() {
11         if (instance == null) {
12             instance = new Singleton();
13         }
14         return instance;
15     }
16 }
17 

显然这个写法在单线程环境下非常好,但是多线程会导致多个实例出现,这个大家都能理解。
最简单的改造方式是添加一个同步锁。
1 package xylz.study.singleton;
2 
3 public class SynchronizedSingleton {
4 
5     private static SynchronizedSingleton instance = null;
6 
7     private SynchronizedSingleton() {
8     }
9 
10     public static synchronized SynchronizedSingleton getInstance() {
11         if (instance == null) {
12             instance = new SynchronizedSingleton();
13         }
14         return instance;
15     }
16 }
17 

显然上面的方法避免了并发的问题,但是由于我们只是在第一次构造对象的时候才需要同步,以后就不再需要同步,所以这里不可避免的有性能开销。于是将锁去掉采用静态的属性来解决同步锁的问题。
1 package xylz.study.singleton;
2 
3 public class StaticSingleton {
4 
5     private static StaticSingleton instance = new StaticSingleton();
6 
7     private StaticSingleton() {
8     }
9 
10     public static StaticSingleton getInstance() {
11         return instance;
12     }
13 }
14 

上面的方法既没有锁又解决了性能问题,看起来已经满足需求了。但是追求“完美”的程序员想延时加载对象,希望在第一次获取的时候才构造对象,于是大家非常聪明的进行改造,也即非常出名的双重检查锁机制出来了。
1 package xylz.study.singleton;
2 
3 public class DoubleLockSingleton {
4 
5     private static DoubleLockSingleton instance = null;
6 
7     private DoubleLockSingleton() {
8     }
9 
10     public static DoubleLockSingleton getInstance() {
11         if (instance == null) {
12             synchronized (DoubleLockSingleton.class) {
13                 if (instance == null) {
14                     instance = new DoubleLockSingleton();
15                 }
16             }
17         }
18         return instance;
19     }
20 }
21 


双重锁机制看起来非常巧妙的避免了上面的问题。但是真的是这样的吗?文章《双重检查锁定及单例模式》中谈到了非常多演变的双重锁机制带来的问题,包括比较难以理解的指令重排序机制等。总之就是双重检查锁机制仍然对导致错误问题而不是性能问题。

一种避免上述问题的解决方案是使用volatile关键字,此关键字保证对一个对象修改后能够立即被其它线程看到,也就是避免了指令重排序和可见性问题。参考文章

指令重排序与happens-before法则

所以上面的写法就变成了下面的例子。

package xylz.study.singleton;

public class DoubleLockSingleton {

    private static volatile DoubleLockSingleton instance = null;

    private DoubleLockSingleton() {
    }

    public static DoubleLockSingleton getInstance() {
        if (instance == null) {
            synchronized (DoubleLockSingleton.class) {
                if (instance == null) {
                    instance = new DoubleLockSingleton();
                }
            }
        }
        return instance;
    }
}


于是继续改造,某个牛人利用JVM的特性来解决上述问题,具体哪个牛人我忘记了,但是不是下面文章的作者。
(1)《Java theory and practice: Fixing the Java Memory Model, Part 2
(2)《Initialize-On-Demand Holder Class and Singletons

1 package xylz.study.singleton;
2 
3 public class HolderSingleton {
4 
5     private static class HolderSingletonHolder {
6 
7         static HolderSingleton instance = new HolderSingleton();
8     }
9 
10     private HolderSingleton() {
11         //maybe throw an Exception when doing something 
12     }
13 
14     public static HolderSingleton getInstance() {
15         return HolderSingletonHolder.instance;
16     }
17 }
18 




上述代码看起来解决了上面单例模式遇到的所有问题,而且实际上工作的很好,没有什么问题。但是却有一个致命的问题,如果第11行抛出了一个异常,也就是第一次构造函数失败将导致永远无法再次得到构建对象的机会。
使用下面的代码测试下。
1 package xylz.study.singleton;
2 
3 public class HolderSingletonTest {
4 
5     private static class HolderSingletonHolder {
6 
7         static HolderSingletonTest instance = new HolderSingletonTest();
8     }
9 
10     private static boolean init = false;
11     
12     private HolderSingletonTest() {
13         //maybe throw an Exception when doing something 
14         if(!init) {
15             init=true;
16             throw new RuntimeException("fail");
17         }
18     }
19 
20     public static HolderSingletonTest getInstance() {
21         return HolderSingletonHolder.instance;
22     }
23     public static void main(String[] args) {
24         for(int i=0;i<3;i++) {
25             try {
26                 System.out.println(HolderSingletonTest.getInstance());
27             } catch (Exception e) {
28                 System.err.println("one->"+i);
29                 e.printStackTrace();
30             }catch(ExceptionInInitializerError err) {
31                 System.err.println("two->"+i);
32                 err.printStackTrace();
33             }catch(Throwable t) {
34                 System.err.println("three->"+i);
35                 t.printStackTrace();
36             }
37         }
38     }
39 }
40 
很不幸将得到以下输出:
1 two->0
2 java.lang.ExceptionInInitializerError
3     at xylz.study.singleton.HolderSingletonTest.getInstance(HolderSingletonTest.java:21)
4     at xylz.study.singleton.HolderSingletonTest.main(HolderSingletonTest.java:26)
5 Caused by: java.lang.RuntimeException: fail
6     at xylz.study.singleton.HolderSingletonTest.<init>(HolderSingletonTest.java:16)
7     at xylz.study.singleton.HolderSingletonTest.<init>(HolderSingletonTest.java:12)
8     at xylz.study.singleton.HolderSingletonTest$HolderSingletonHolder.<clinit>(HolderSingletonTest.java:7)
9      2 more
10 three->1
11 java.lang.NoClassDefFoundError: Could not initialize class xylz.study.singleton.HolderSingletonTest$HolderSingletonHolder
12     at xylz.study.singleton.HolderSingletonTest.getInstance(HolderSingletonTest.java:21)
13     at xylz.study.singleton.HolderSingletonTest.main(HolderSingletonTest.java:26)
14 three->2
15 java.lang.NoClassDefFoundError: Could not initialize class xylz.study.singleton.HolderSingletonTest$HolderSingletonHolder
16     at xylz.study.singleton.HolderSingletonTest.getInstance(HolderSingletonTest.java:21)
17     at xylz.study.singleton.HolderSingletonTest.main(HolderSingletonTest.java:26)
18 

很显然我们想着第一次加载失败第二次能够加载成功,非常不幸,JVM一旦加载某个类失败将认为此类的定义有问题,将来不再加载,这样就导致我们没有机会再加载。目前看起来没有办法避免此问题。如果要使用JVM的类加载特性就必须保证类加载一定正确,否则此问题将比并发和性能更严重。如果我们的类需要初始话那么就需要想其它办法避免在构造函数中完成。看起来像是又回到了老地方,难道不是么?

总之,结论是目前没有一个十全十美的单例模式,而大多数情况下我们只需要满足我们的需求就行,没必有特意追求最“完美”解决方案。
原文[http://www.imxylz.info/p/177.html]
posted @ 2013-05-22 13:58 小马歌 阅读(171) | 评论 (0)编辑 收藏
 


1.1内存分配方面

:一般由程序员分配释放,若程序员不释放,程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事,分配方式是类似于链表。可能用到的关键字如下:new、malloc、delete、free等等。

:由编译器(Compiler)自动分配释放,存放函数的参数值,局部变量的值等。其操作方式类似于数据结构中的栈。

1.2申请方式方面:

:需要程序员自己申请,并指明大小。在c中malloc函数如p1 = (char *)malloc(10);在C++中用new运算符,但是注意p1、p2本身是在栈中的。因为他们还是可以认为是局部变量。

:由系统自动分配。 例如,声明在函数中一个局部变量 int b;系统自动在栈中为b开辟空间。

1.3系统响应方面:

:操作系统有一个记录空闲内存地址的链表,当系统收到程序的申请时,会遍历该链表,寻找第一个空间大于所申请空间的堆结点,然后将该结点从空闲结点链表中删除,并将该结点的空间分配给程序,另外,对于大多数系统,会在这块内存空间中的首地址处记录本次分配的大小,这样代码中的delete语句才能正确的释放本内存空间。另外由于找到的堆结点的大小不一定正好等于申请的大小,系统会自动的将多余的那部分重新放入空闲链表中。

:只要栈的剩余空间大于所申请空间,系统将为程序提供内存,否则将报异常提示栈溢出。

1.4大小限制方面:

:是向高地址扩展的数据结构,是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的,自然是不连续的,而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见,堆获得的空间比较灵活,也比较大。

:在Windows下, 栈是向低地址扩展的数据结构,是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的,在WINDOWS下,栈的大小是固定的(是一个编译时就确定的常数),如果申请的空间超过栈的剩余空间时,将提示overflow。因此,能从栈获得的空间较小。

1.5效率方面:

:是由new分配的内存,一般速度比较慢,而且容易产生内存碎片,不过用起来最方便,另外,在WINDOWS下,最好的方式是用VirtualAlloc分配内存,他不是在堆,也不是在栈是直接在进程的地址空间中保留一快内存,虽然用起来最不方便。但是速度快,也最灵活。

:由系统自动分配,速度较快。但程序员是无法控制的。

1.6存放内容方面:

:一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

:在函数调用时第一个进栈的是主函数中后的下一条指令(函数调用语句的下一条可执行语句)的地址然后是函数的各个参数,在大多数的C编译器中,参数是由右往左入栈,然后是函数中的局部变量。 注意: 静态变量是不入栈的。当本次函数调用结束后,局部变量先出栈,然后是参数,最后栈顶指针指向最开始存的地址,也就是主函数中的下一条指令,程序由该点继续运行。

1.7存取效率方面:

:char *s1 = "Hellow Word";是在编译时就确定的;

:char s1[] = "Hellow Word"; 是在运行时赋值的;用数组比用指针速度要快一些,因为指针在底层汇编中需要用edx寄存器中转一下,而数组在栈上直接读取。


小结

1、静态变量不入栈。 
2、栈由编译器自动分配和释放。栈中存放局部变量和参数,函数调用结束后,局部变量先出栈,然后是参数。 
3、数组比用指针速度要快一些,因为指针在底层汇编中需要用edx寄存器中转一下,而数组在栈上直接读取。 
4、堆是由程序员通过new、malloc、free、delete等指令进行分配和释放。如果程序员没有进行释放,程序结束时可能有OS回收。 
5、堆是由new分配的内存,速度较慢;栈是由系统自动分配,速度较快。 
6、比如存放在栈里面的数组,是在运行时赋值。而存在堆里面的指针数据,是在编译时就确定的。

附:

一. 在c中分为这几个存储区

1.栈 - 由编译器自动分配释放
2.堆 - 一般由程序员分配释放,若程序员不释放,程序结束时可能由OS回收
3.全局区(静态区),全局变量和静态变量的存储是放在一块的,初始化的全局变量和静态变量在一块区域,未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。- 程序结束释放
4.另外还有一个专门放常量的地方。- 程序结束释放
                                                                                                                                              
在函数体中定义的变量通常是在栈上,用malloc, calloc, realloc等分配内存的函数分配得到的就是在堆上。在所有函数体外定义的是全局量,加了static修饰符后不管在哪里都存放在全局区(静态区),在所有函数体外定义的static变量表示在该文件中有效,不能extern到别的文件用,在函数体内定义的static表示只在该函数体内有效。另外,函数中的"adgfdf"这样的字符串存放在常量区。比如:

int a = 0//全局初始化区
char *p1; //全局未初始化区
void main()
{
    int b; //
    char s[] = "abc"; //
    char *p2; //
    char *p3 = "123456"; //123456{post.content}在常量区,p3在栈上
    static int c = 0; //全局(静态)初始化区
     p1 = (char *)malloc(10); //分配得来得10字节的区域在堆区
     p2 = (char *)malloc(20); //分配得来得20字节的区域在堆区
     strcpy(p1, "123456");
    //123456{post.content}放在常量区,编译器可能会将它与p3所指向的"123456"优化成一块
}


二.在C++中,内存分成5个区,他们分别是堆、栈、自由存储区、全局/静态存储区和常量存储区
1.栈,
就是那些由编译器在需要的时候分配,在不需要的时候自动清楚的变量的存储区。里面的变量通常是局部变量、函数参数等。
2.堆,就是那些由new分配的内存块,他们的释放编译器不去管,由我们的应用程序去控制,一般一个new就要对应一个delete。如果程序员没有释放掉,那么在程序结束后,操作系统会自动回收。
3.自由存储区,就是那些由malloc等分配的内存块,他和堆是十分相似的,不过它是用free来结束自己的生命的。
4.全局/静态存储区,全局变量和静态变量被分配到同一块内存中,在以前的C语言中,全局变量又分为初始化的和未初始化的,在C++里面没有这个区分了,他们共同占用同一块内存区。
5.常量存储区,这是一块比较特殊的存储区,他们里面存放的是常量,不允许修改(当然,你要通过非正当手段也可以修改)

三. 谈谈堆与栈的关系与区别
具体地说,现代计算机(串行执行机制),都直接在代码底层支持栈的数据结构。这体现在,有专门的寄存器指向栈所在的地址,有专门的机器指令完成数据入栈出栈的操作。这种机制的特点是效率高,支持的数据有限,一般是整数,指针,浮点数等系统直接支持的数据类型,并不直接支持其他的数据结构。因为栈的这种特点,对栈的使用在程序中是非常频繁的。对子程序的调用就是直接利用栈完成的。机器的call指令里隐含了把返回地址推入栈,然后跳转至子程序地址的操作,而子程序中的ret指令则隐含从堆栈中弹出返回地址并跳转之的操作。C/C++中的自动变量是直接利用栈的例子,这也就是为什么当函数返回时,该函数的自动变量自动失效的原因。 

和栈不同,堆的数据结构并不是由系统(无论是机器系统还是操作系统)支持的,而是由函数库提供的。基本的malloc/realloc/free 函数维护了一套内部的堆数据结构。当程序使用这些函数去获得新的内存空间时,这套函数首先试图从内部堆中寻找可用的内存空间,如果没有可以使用的内存空间,则试图利用系统调用来动态增加程序数据段的内存大小,新分配得到的空间首先被组织进内部堆中去,然后再以适当的形式返回给调用者。当程序释放分配的内存空间时,这片内存空间被返回内部堆结构中,可能会被适当的处理(比如和其他空闲空间合并成更大的空闲空间),以更适合下一次内存分配申请。这套复杂的分配机制实际上相当于一个内存分配的缓冲池(Cache),使用这套机制有如下若干原因:
1. 系统调用可能不支持任意大小的内存分配。有些系统的系统调用只支持固定大小及其倍数的内存请求(按页分配);这样的话对于大量的小内存分类来说会造成浪费。
2. 系统调用申请内存可能是代价昂贵的。系统调用可能涉及用户态和核心态的转换。
3. 没有管理的内存分配在大量复杂内存的分配释放操作下很容易造成内存碎片。

堆和栈的对比
从以上知识可知,栈是系统提供的功能,特点是快速高效,缺点是有限制,数据不灵活;而栈是函数库提供的功能,特点是灵活方便,数据适应面广泛,但是效率有一定降低。栈是系统数据结构,对于进程/线程是唯一的;堆是函数库内部数据结构,不一定唯一。不同堆分配的内存无法互相操作。栈空间分静态分配和动态分配两种。静态分配是编译器完成的,比如自动变量(auto)的分配。动态分配由alloca函数完成。栈的动态分配无需释放(是自动的),也就没有释放函数。为可移植的程序起见,栈的动态分配操作是不被鼓励的!堆空间的分配总是动态的,虽然程序结束时所有的数据空间都会被释放回系统,但是精确的申请内存/ 释放内存匹配是良好程序的基本要素。

    1.碎片问题:对于堆来讲,频繁的new/delete势必会造成内存空间的不连续,从而造成大量的碎片,使程序效率降低。对于栈来讲,则不会存在这个问题,因为栈是先进后出的队列,他们是如此的一一对应,以至于永远都不可能有一个内存块从栈中间弹出,在他弹出之前,在他上面的后进的栈内容已经被弹出,详细的可以>参考数据结构,这里我们就不再一一讨论了。
    2.生长方向:对于堆来讲,生长方向是向上的,也就是向着内存地址增加的方向;对于栈来讲,它的生长方向是向下的,是向着内存地址减小的方向增长。
    3.分配方式:堆都是动态分配的,没有静态分配的堆。栈有2种分配方式:静态分配和动态分配。静态分配是编译器完成的,比如局部变量的分配。动态分配由alloca函数进行分配,但是栈的动态分配和堆是不同的,他的动态分配是由编译器进行释放,无需我们手工实现。
    4.分配效率:栈是机器系统提供的数据结构,计算机会在底层对栈提供支持:分配专门的寄存器存放栈的地址,压栈出栈都有专门的指令执行,这就决定了栈的效率比较高。堆则是C/C++函数库提供的,它的机制是很复杂的,例如为了分配一块内存,库函数会按照一定的算法(具体的算法可以参考数据结构/操作系统)在堆内存中搜索可用的足够大小的空间,如果没有足够大小的空间(可能是由于内存碎片太多),就有可能调用系统功能去增加程序数据段的内存空间,这样就有机会分到足够大小的内存,然后进行返回。显然,堆的效率比栈要低得多。

    明确区分堆与栈:
    在bbs上,堆与栈的区分问题,似乎是一个永恒的话题,由此可见,初学者对此往往是混淆不清的,所以我决定拿他第一个开刀。
    首先,我们举一个例子:

void f()

    int* p=new int[5];
}

这条短短的一句话就包含了堆与栈,看到new,我们首先就应该想到,我们分配了一块堆内存,那么指针p呢?他分配的是一块栈内存,所以这句话的意思就是:在栈内存中存放了一个指向一块堆内存的指针p。在程序会先确定在堆中分配内存的大小,然后调用operator new分配内存,然后返回这块内存的首地址,放入栈中,他在VC6下的汇编代码如下:
    00401028    push         14h
    0040102A    call            operator new (00401060)
    0040102F    add          esp,4
    00401032    mov          dword ptr [ebp-8],eax
    00401035    mov          eax,dword ptr [ebp-8]
    00401038    mov          dword ptr [ebp-4],eax
    这里,我们为了简单并没有释放内存,那么该怎么去释放呢?是delete p么?澳,错了,应该是delete []p,这是为了告诉编译器:我删除的是一个数组,VC6就会根据相应的Cookie信息去进行释放内存的工作。
    好了,我们回到我们的主题:堆和栈究竟有什么区别?
    主要的区别由以下几点:
    1、管理方式不同;
    2、空间大小不同;
    3、能否产生碎片不同;
    4、生长方向不同;
    5、分配方式不同;
    6、分配效率不同;
    管理方式:对于栈来讲,是由编译器自动管理,无需我们手工控制;对于堆来说,释放工作由程序员控制,容易产生memory leak。
    空间大小:一般来讲在32位系统下,堆内存可以达到4G的空间,从这个角度来看堆内存几乎是没有什么限制的。但是对于栈来讲,一般都是有一定的空间大小的,例如,在VC6下面,默认的栈空间大小是1M(好像是,记不清楚了)。当然,我们可以修改:
    打开工程,依次操作菜单如下:Project->Setting->Link,在Category 中选中Output,然后在Reserve中设定堆栈的最大值和commit。
注意:reserve最小值为4Byte;commit是保留在虚拟内存的页文件里面,它设置的较大会使栈开辟较大的值,可能增加内存的开销和启动时间。
    堆和栈相比,由于大量new/delete的使用,容易造成大量的内存碎片;由于没有专门的系统支持,效率很低;由于可能引发用户态和核心态的切换,内存的申请,代价变得更加昂贵。所以栈在程序中是应用最广泛的,就算是函数的调用也利用栈去完成,函数调用过程中的参数,返回地址,EBP和局部变量都采用栈的方式存放。所以,我们推荐大家尽量用栈,而不是用堆。

另外对存取效率的比较:
代码:

char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";

aaaaaaaaaaa是在运行时刻赋值的;
而bbbbbbbbbbb是在编译时就确定的;
但是,在以后的存取中,在栈上的数组比指针所指向的字符串(例如堆)快
比如:

void main()
{
    char a = 1;
    char c[] = "1234567890";
    char *p ="1234567890";
     a = c[1];
     a = p[1];
    return;
}

对应的汇编代码
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一种在读取时直接就把字符串中的元素读到寄存器cl中,而第二种则要先把指针值读到edx中,在根据edx读取字符,显然慢了.
    无论是堆还是栈,都要防止越界现象的发生(除非你是故意使其越界),因为越界的结果要么是程序崩溃,要么是摧毁程序的堆、栈结构,产生以想不到的结果,就算是在你的程序运行过程中,没有发生上面的问题,你还是要小心,说不定什么时候就崩掉,编写稳定安全的代码才是最重要的

posted @ 2013-05-20 16:40 小马歌 阅读(272) | 评论 (0)编辑 收藏
 

浅谈CSRF攻击方式

2009-04-09 22:44 by hyddd, 18997 阅读, 39 评论, 收藏编辑

一.CSRF是什么?

  CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。

二.CSRF可以做什么?

  你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全。

三.CSRF漏洞现状

  CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、Metafilter(一个大型的BLOG网站),YouTube和百度HI......而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为“沉睡的巨人”。

四.CSRF的原理

  下图简单阐述了CSRF攻击的思想:

  

  从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤

  1.登录受信任网站A,并在本地生成Cookie

  2.在不登出A的情况下,访问危险网站B

  看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生:

  1.你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。

  2.你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......)

  3.上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。

 

  上面大概地讲了一下CSRF攻击的思想,下面我将用几个例子详细说说具体的CSRF攻击,这里我以一个银行转账的操作作为例子(仅仅是例子,真实的银行网站没这么傻:>)

  示例1:

  银行网站A,它以GET请求来完成银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000

  危险网站B,它里面有一段HTML的代码如下:

  <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

  首先,你登录了银行网站A,然后访问危险网站B,噢,这时你会发现你的银行账户少了1000块......

  为什么会这样呢?原因是银行网站A违反了HTTP规范,使用GET请求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作......

  示例2:

  为了杜绝上面的问题,银行决定改用POST请求完成转账操作。

  银行网站A的WEB表单如下:  

  <form action="Transfer.php" method="POST">
    <p>ToBankId: <input type="text" name="toBankId" /></p>
    <p>Money: <input type="text" name="money" /></p>
    <p><input type="submit" value="Transfer" /></p>
  </form>

  后台处理页面Transfer.php如下:

复制代码
  <?php
    session_start();
    if (isset($_REQUEST['toBankId'&& isset($_REQUEST['money']))
    {
        buy_stocks(
$_REQUEST['toBankId'], $_REQUEST['money']);
    }
  ?>
复制代码

  危险网站B,仍然只是包含那句HTML代码:

  <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

  和示例1中的操作一样,你首先登录了银行网站A,然后访问危险网站B,结果.....和示例1一样,你再次没了1000块~T_T,这次事故的原因是:银行后台使用了$_REQUEST去获取请求的数据,而$_REQUEST既可以获取GET请求的数据,也可以获取POST请求的数据,这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中,可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中,用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

  示例3:

  经过前面2个惨痛的教训,银行决定把获取请求数据的方法也改了,改用$_POST,只获取POST请求的数据,后台处理页面Transfer.php代码如下:

复制代码
  <?php
    
session_start();
    
if (isset($_POST['toBankId'&& isset($_POST['money']))
    {
        buy_stocks(
$_POST['toBankId'], $_POST['money']);
    }
  
?>
复制代码

  然而,危险网站B与时俱进,它改了一下代码:

复制代码
<html>
  <head>
    <script type="text/javascript">
      function steal()
      {
               iframe 
= document.frames["steal"];
               iframe.document.Submit(
"transfer");
      }
    </script>
  </head>

  
<body onload="steal()">
    <iframe name="steal" display="none">
      <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
        
<input type="hidden" name="toBankId" value="11">
        
<input type="hidden" name="money" value="1000">
      
</form>
    </iframe>
  </body>
</html>
复制代码

如果用户仍是继续上面的操作,很不幸,结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

  总结一下上面3个例子,CSRF主要的攻击模式基本上是以上的3种,其中以第1,2种最为严重,因为触发条件很简单,一个<img>就可以了,而第3种比较麻烦,需要使用JavaScript,所以使用的机会会比前面的少很多,但无论是哪种情况,只要触发了CSRF攻击,后果都有可能很严重。

  理解上面的3种攻击模式,其实可以看出,CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的

五.CSRF的防御

  我总结了一下看到的资料,CSRF的防御可以从服务端客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。

  1.服务端进行CSRF防御

  服务端的CSRF方式方法很多样,但总的思想都是一致的,就是在客户端页面增加伪随机数

  (1).Cookie Hashing(所有表单都包含同一个伪随机值):

  这可能是最简单的解决方案了,因为攻击者不能获得第三方的Cookie(理论上),所以表单中的数据也就构造失败了:>

  <?php
    //构造加密的Cookie信息
    $value = “DefenseSCRF”;
    setcookie(”cookie”, $value, time()+3600);
  ?>

  在表单里增加Hash值,以认证这确实是用户发送的请求。

复制代码
  <?php
    $hash = md5($_COOKIE['cookie']);
  ?>
  <form method=”POST” action=”transfer.php”>
    <input type=”text” name=”toBankId”>
    <input type=”text” name=”money”>
    <input type=”hidden” name=”hash” value=<?=$hash;?>>
    <input type=”submit” name=”submit” value=”Submit”>
  </form>
复制代码

  然后在服务器端进行Hash值验证

复制代码
      <?php
        if(isset($_POST['check'])) {
             
$hash = md5($_COOKIE['cookie']);
             if($_POST['check'== $hash) {
                  doJob();
             } 
else {
        //...

             }
        } 
else {
      //...

        }
      
?>
复制代码

  这个方法个人觉得已经可以杜绝99%的CSRF攻击了,那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,这就另外的1%。一般的攻击者看到有需要算Hash值,基本都会放弃了,某些除外,所以如果需要100%的杜绝,这个不是最好的方法。
  (2).验证码

  这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,厄....这个方案可以完全解决CSRF,但个人觉得在易用性方面似乎不是太好,还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug,可能在某些版本的微软IE中受影响。

  (3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

  在实现One-Time Tokens时,需要注意一点:就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单,CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况:用户只能成功地提交他最后打开的表单,因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

  以下我的实现:

  1).先是令牌生成函数(gen_token()):

复制代码
     <?php
     function gen_token() {
    //这里我是贪方便,实际上单使用Rand()得出的随机数作为令牌,也是不安全的。
    //这个可以参考我写的Findbugs笔记中的《Random object created and used only once》
          $token = md5(uniqid(rand(), true));
          
return $token;
     }
复制代码

  2).然后是Session令牌生成函数(gen_stoken()):

复制代码
     <?php
     
  function gen_stoken() {
      $pToken = "";
      if($_SESSION[STOKEN_NAME]  == $pToken){
        //没有值,赋新值
      
  $_SESSION[STOKEN_NAME] = gen_token();
      }    
      else{
        //继续使用旧的值
      }

       }
     
?>
复制代码

  3).WEB表单生成隐藏输入域的函数:  

复制代码
     <?php
       function gen_input() {
            gen_stoken();
            echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
                 value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
       }
     ?>
复制代码

  4).WEB表单结构:

复制代码
     <?php
          
session_start();
          
include(”functions.php”);
     
?>
     
<form method=”POST” action=”transfer.php”>
          
<input type=”text” name=”toBankId”>
          
<input type=”text” name=”money”>
          
<? gen_input(); ?>
          
<input type=”submit” name=”submit” value=”Submit”>
     
</FORM>
复制代码

  5).服务端核对令牌:

  这个很简单,这里就不再啰嗦了。

  上面这个其实不完全符合“并行会话的兼容”的规则,大家可以在此基础上修改。

 

  其实还有很多想写,无奈精力有限,暂且打住,日后补充,如果错漏,请指出:>

  PS:今天下午写这篇文档的时候FF崩溃了一次,写了一半文章的全没了,郁闷好久T_T.......

  转载请说明出处,谢谢[hyddd(http://www.cnblogs.com/hyddd/)]

posted @ 2013-04-24 17:00 小马歌 阅读(223) | 评论 (0)编辑 收藏
 

分布式领域CAP理论,
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区:
Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成。
Consistency一致性. 在事务开始或结束时,数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓。
Durability. 一旦事务完成,就不能返回。
跨数据库事务:2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,JavaEE中的JTA事务可以支持2PC。因为2PC是反模式,尽量不要使用2PC,使用BASE来回避。
BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性:
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步,异步。
Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时高一致。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片 
BASE思想主要强调基本的可用性,如果你需要High 可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。
现在NoSQL运动丰富了拓展了BASE思想,可按照具体情况定制特别方案,比如忽视一致性,获得高可用性等等,NOSQL应该有下面两个流派:
1. Key-Value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 (Qi4j和NoSQL运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
这两者共同点:都是关系数据库SQL以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度。
不同点:NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX,可以适合非Java如PHP RUBY等领域,是一种可以拿来就用的产品,而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的。

posted @ 2013-04-23 16:18 小马歌 阅读(217) | 评论 (0)编辑 收藏
 

主要阐述以下内容:

磁盘的内部结构及实现机制
分区的结构及实现机制
块的构造及原理
扇区的构造及结构

 

由于机械硬盘的访问机制为移动磁头,并等待磁碟旋转,因此在设计磁盘时,需要考虑如何组织数据为顺序访问,并且最大限度提供一次顺序访问尽可能多的数据

由于块大小设计直影响到性能、内存、空间等因素,因此需要合理设置块大小,同时需要合理的为业务扩展预留升级空间

机械磁盘读写原理

 

机械硬盘获取数据的方式为:

1、通过查找meta数据(图中的Data Meta,它是用于描述数据的数据,所以称为数据元,通常这些数据会被Cache在磁盘Cache或OS Cache中),捕获数据存储物理区域。包括:磁头指向的磁道位置、磁道的起始、结束位置等,其中还包含了数据块的标记,如使用状态,分区、块、卷、扇区等等存储细节等,是磁盘运作机制的核心组件

2、驱动磁碟旋转(服务器通常磁盘会一直旋转,但为了省电及减少对驱动轴的损耗,通常会对旋转进行优化,即空闲时降低磁盘旋转速度或停止转动,但重新驱动磁盘也会消耗大量的功耗,厂家进行了很多节能减排的优化措施,为绿色环保做了不少贡献)

3、将磁头(图中的head)移动到指定的磁道,并从指定的起始位置开始读取bit流,一直至指定的结束位置,并将信号传送至处理程序,最后转化为OS识别的数据


机械硬盘核心组件:

1、磁盘控制器:内部包含用于控制多磁碟并行访问的机制,包括磁头移动、盘片旋转、供电、缓存、写保护等,是整个磁盘的核心组件

2、分区(LUN):机械硬盘要被使用,通常先要被分区,并基于分区进行格式化,格式化将产生Meta数据,Meta数据通常会占用部分磁盘空间。空间大小取决于Block大小、分区量,Block越小,需要消耗的空间,用于于索引磁盘数据,接下来我们将还会介绍块及扇区的组合方式,多碟磁盘中,磁盘控制器将在每块磁碟中划分一块空间用于该分区使用,达到并行访问的目的,提升响应速度(通常某些访问需要集中访问的数据都集中在某些分区中),此处的分区不同于OS中的分区,此处为物理分区

3、块:块由扇区构成,块大小决定了数据访问的性能,如果大数据如果存储在小块中会导致浪费大量的数据元空间,并消耗更多的Cache、更多的寻道时间(数据是被分散再分区中的各个位置),所以当应用数据块比较小的时候,我们建议将数据划分成更大的块,提升性能,但如果块划的太大,会导致存储空间的浪费,当这些不需要的数据被LOAD到应用中时,同样会消耗额外的OS内存,通常我们建议根据业务的类型,在应用层选择合适的数据集大小,并设置合理的磁盘块大小

块由扇区构成,扇区直接构建再磁碟的磁面上,每个扇区为512byte,业绩意味着4KB的块大小将需要8个扇区组成(通常Linux设置块大小为4K),但再某些数据库应用中我们将数据库的数据设置为更大,如8K、16K、64K,日志设置为更大,如8K、16K、64K等,结构如下

 

4、扇区:扇区是磁盘存储的单元,扇区顾名思义,机械硬盘是圆形的,通过分区格式化后将得到一个一个的扇形结构,一条磁道的存储空间被格式化后将的到大量的扇形结构,磁盘的扇区大小为512byte,其在磁盘的结构如下图:


图中我们可以看到扇区结构非常复杂,包含数据区域、扇区分界标识区域、扇区间隙区域,磁盘在处理数据时为了更好的保护数据及容错、设计了扇区分界标识及扇区间隙(当然远远不止如此)

posted @ 2013-04-23 09:56 小马歌 阅读(260) | 评论 (0)编辑 收藏
 

Hadoop是Apache的一个项目(http://hadoop.apache.org/),它是一个实现了MapReduce计算模型的可以运用于大型集群并行计算的分布式并行计算编程框架。

目前,整个Hadoop家族由以下几个子项目组成:

Hadoop Common
Hadoop体系最底层的一个模块,为Hadoop各子项目提供各种工具,如:配置文件和日志操作等。

Avro
Avro是doug cutting主持的RPC项目,有点类似Google的protobuf和Facebook的thrift。avro用来做以后hadoop的RPC,使hadoop的RPC模块通信速度更快、数据结构更紧凑。

Chukwa
Chukwa是基于Hadoop的大集群监控系统,由yahoo贡献。

HBase
基于Hadoop Distributed File System,是一个开源的,基于列存储模型的分布式数据库。

HDFS
分布式文件系统

Hive
hive类似CloudBase,也是基于hadoop分布式计算平台上的提供data warehouse的sql功能的一套软件。使得存储在hadoop里面的海量数据的汇总,即席查询简单化。hive提供了一套QL的查询语言,以sql为基础,使用起来很方便。

MapReduce
实现了MapReduce编程框架

Pig
Pig是SQL-like语言,是在MapReduce上构建的一种高级查询语言,把一些运算编译进MapReduce模型的Map和Reduce中,并且用户可以定义自己的功能。Yahoo网格运算部门开发的又一个克隆Google的项目Sawzall。

ZooKeeper
Zookeeper是Google的Chubby一个开源的实现。它是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。

posted @ 2013-04-22 12:39 小马歌 阅读(275) | 评论 (0)编辑 收藏
 
到http://nginx.org/en/download.html下载最新版本的Nginx并安装.
一 下载并安装pcre库ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
   tar zxvf pcre-8.30.tar.gz
   ./configure     make    make install
二 安装openssl 
   yum -y install openssl openssl-devel
三 下载tcp_proxy_module
到 https://github.com/yaoweibin/nginx_tcp_proxy_module 下载
四 安装nginx
export NGINX_VERSION=1.2.1
curl -O http://nginx.org/downlad/nginx-$NGINX_VERSION.tar.gz
tar -xvzf nginx-$NGINX_VERSION.tar.gz
cd nginx-$NGINX_VERSION
patch -p1 < ../nginx_tcp_proxy_module/tcp.patch
./configure --add-module=../nginx_tcp_proxy_module/
sudo make && make install
 
启动nginx上时,服务无法启动,出现libpcre.so.1 not found的错误,解决方法如下:
先执行下述命令,查看
---#ldd $(which /usr/sbin/nginx)
显示如下:
    linux-vdso.so.1 =>  (0x00007fff7e9db000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe4629d0000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fe462799000)
    libpcre.so.1 => not found//果然没找到
    libz.so.1 => /lib64/libz.so.1 (0x00007fe462582000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fe4621e1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe462bfa000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007fe461f7e000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fe461d7a000)
执行如下:
 ----#cd /lib64
 ----#ln -s libpcre.so.0.0.1 libpcre.so.1
再次查看一下:
 ----#ldd $(which /usr/sbin/nginx)
显示已经ok了:
    linux-vdso.so.1 =>  (0x00007fff4d7ff000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb06f13e000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb06ef07000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fb06ecda000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fb06eac4000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fb06e723000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb06f368000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007fb06e4c0000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fb06e2bc000)
 
为websocket应用实现负载均衡 http://cnodejs.org/topic/4f16442ccae1f4aa270010b3 
Reverse Proxy Web Sockets with Nginx and Socket.IO http://www.letseehere.com/reverse-proxy-web-sockets
posted @ 2013-04-18 17:38 小马歌 阅读(482) | 评论 (0)编辑 收藏
 

前言: 


websocket相信经常逛cnode社区的孩纸们都知道..具体API使用方式也再熟悉不过了..使用nodejs开发的websocket服务端也是品种繁多..github上总有你喜欢的..平时耍耍当然没问题..如果真要是承载一个生产环境服务的核心..总会有些问题需要你去解决. 

不可避免的问题: 

按照一个web请求占用线程数为参照..我们可以把nodejs称之为单线程语言..而java的servlet这种应该就是多线程语言了..我们可以想象在高并发情况下..单线程语言的运行风险还是蛮高的..毕竟如果一个请求出事那么整个线程(进程)就退出了..于是乎停止服务了..为了规避风险..我们常常会使用负载均衡技术..保证整个系统的对外正常服务.. 

解决方案: 

负载均衡方案目前来讲..用apache的也不多了吧..普遍的解决方案是使用nginx配置多个upstream.实现负载均衡..例子如下: 
http{ 
upstream http_sr {
server 192.168.0.2:8080;
server 192.168.0.3:8080;
}
server {
listen 80 ;
proxy_pass http_sr;
}
}

这样对于部署在192.168.0.2和3这两台机器上http服务..就通过这台nginx服务器实现了负载均衡...但是websocket的服务端nginx的http反向代理是不能支持的.从websocket的specs我们可以很明确的其实基于tcp协议的..http协议虽然也是基于tcp..它们都使用了tcp的握手方式..但是nginx的http_proxy_pass是不能支持websocket的.. 

于是我们可以寻根问主..让nginx支持tcp_proxy_pass..那websocket负载均衡的问题不就迎刃而解了..nginx有丰富的第三方扩展..一顿搜索在github上找到了yaoweibin老师的nginx_tcp_proxy_module 

  

二话不说下载此模块..重新编译nginx(此过程略吧大家应该都懂) ..修改nginx配置文件加入下面conf: 
tcp { 
upstream websocket {
server 192.168.0.2:8080;
server 192.168.0.3:8080;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 80;
proxy_pass websocket;
}
}

这个module的作者在description写到: 
 The motivation of writing these modules is Nginx's high performance and 
robustness. At first, I developed this module just for general TCP
proxy. And now, this module is frequently used in websocket reverse
proxying.

目前基本就是用来做websocket反向代理的..测试后确实是支持的..非常感谢module的开发者另外值得注意的是你要在nginx里同时配置tcp和http..那么它们是不能listen同一端口的..
posted @ 2013-04-18 17:38 小马歌 阅读(2238) | 评论 (0)编辑 收藏
 

nginx_tcp_proxy_module 为 Nginx 增加对 TCP 的反向代理支持,提供连接有效性检测和状态监控。

配置示例:

upstream cluster {
    # simple round-robin
    server 127.0.0.1:3306;
    server 127.0.0.1:1234;

    check interval=3000 rise=2 fall=5 timeout=1000;

    #check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;

    #check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    #check_http_send "GET / HTTP/1.0\r\n\r\n";
    #check_http_expect_alive http_2xx http_3xx;
}

add the feature of tcp proxy with nginx, with health check and status monitor — More...

http://yaoweibin.github.com/nginx_tcp_proxy_module

Issues
#74may be a debug in ngx_tcp_upstream_check_broken_connection?by chenbk85  2013-04-17
#73reverse proxy tcp and http on the same portby beurdouche  2013-03-26
#72TCP error_logby splitice  2013-03-24
#31basic auth htpsswdby manguz  2013-03-21
#71upstream ssl suppoprt!by sleets  2013-03-13

master分支代码最近更新:2013-03-28

posted @ 2013-04-18 17:19 小马歌 阅读(323) | 评论 (0)编辑 收藏
仅列出标题
共95页: First 上一页 26 27 28 29 30 31 32 33 34 下一页 Last