学习备忘录

您从本文可以得到：
1.如何在linux/windows下安装3proxy代理软件，并使用其开设代理
2.调整3proxy代理链，使用多个父代理联合上网
3.使用3proxy开设多个代理

3proxy是一个由俄罗斯人开发的多平台代理软件，支持http/https/ftp/socks4/socks5/socks4a/socks5a等多种代理方式。

之前由dRag0nMa介绍到drl,并由ccpp0兄写过一个简单的教程原文地址：
我是因为要在linux下寻找一款同时支持http和socks的代理软件，由ccpp0兄介绍给我的，从那篇文章里获益良多。跟据自己的需要，阅读软件英文手册并在软件论坛上发帖询问后有了一些新的理解，特发此文

一、安装
在windows下安装：
在windows下安装其实十分简单：
可以下载已经编译好的二进制包，然后解压缩到一个文件中。bin文件夹下即是软件执行文件。

二、配置：
对于windows系统来说要在bin文件夹下新建一个名为3proxy.cfg的文件。所有的配置信息都写在这里。
若为linux系统，则可新建一个3proxy.sh的文件。

我先粗略说明一下我的网络环境及想用3proxy实现哪些功能。
我手头上有一个socks代理,我希望大部分网络连接通过这个代理，同时不想进行代理所需的身份验证。同时，我是一个tor用户，但从来没有用过privoxy的其它功能，只用tor来浏览网页，所以希望将tor转换为普通的http代理。
同时，我还需要开设一个代理给寝室中的同学使用。
做下假设：
我的父代理
socks代理为:192.168.0.1:8080,代理类型是socks5,用户名、密码是：usr/pwd
tor代理是：127.0.0.1:9050,代理类型是socks4a
我希望开设的代理：
用户有192.168.1.1和192.168.1.2以及我自己
共开设四个代理接口：
1234端口：这个端口进来的http请求全部转到192.168.0.1
1235端口：这个端口接受socks请求，并全部转到192.168.0.1
1236端口：这个端口希望能建起一个代理链，使用tor为一级代理，192.168.0.1做为二级代理
1237端口：这个端口没有父代理，提供给除我之外的用户使用。

好了，让我们看一下我的cfg文件是如何实现以上要求的(#后为注释)：

下面就两个问题深入说明一下：
1.tor本身是socks4a的代理，在设置文件中应该表示为socks4+,但由于192.168.0.1不支持域名解析，所以标为socks4,否则会代理链出错
2.代理链是这样的，由权重值（即1000）来分组，每组权重值相加必须为1000，一组即为一层
　使用手册中的例子：
　parent 1000 socks5 192.168.10.1 1080
　parent 1000 connect 192.168.20.1 3128
　parent 300 socks4 192.168.30.1 1080
　parent 700 socks5 192.168.40.1 1080
以上的代理链共分为三组，分别是第一层：192.168.10.1,第二层：192.168.20.1,第三层：30.1和40.1
当一个请求到达后，第一层和第二层是必须要经过的，在第三层中，有30%的机会通过30.1,70%的机会通过40.1
使用权重的时候注意保证每组权重和为1000

三、运行
在windows具有管理员权限的情况下，运行3proxy.exe --install就可以了，之后将会作为后台服务运行。
在linux下在文件的最前面加入
#!/usr/local/bin/3proxy/3proxy
之后
chmod +x 3proxy.sh，直接运行3proxy.sh就可以开设代理服务了

web 站点的数据备份 rsync 官方站点
http://rsync.samba.org/
http://samba.anu.edu.au/rsync/download.html

[ WINDOWS 2003 RSYNC 服务端 ]
rsync for windows download :
http://switch.dl.sourceforge.net/sourceforge/sereds/cwRsync_Server_2.0.10_Installer.zip

1. 安装
选择安装路径 D:\cwRsyncServer , 注:   rsync 是作为cgywin的一个包装到windows下的
安装时  Rsync 会做下面的工作
a. 新建一个用户SvcwRsync  并且这个用户是管理员用户
b. 设置好安装目录的权限 D:\cwRsyncServer  , 请不要自行更改权限
c. 创建服务RsyncServer 低版本中可能需要手工做上面的步骤 ,  并需要象下面一样手工创建服务 , 但是这里3个步骤安装程序都已经做好了



2. 修改rsync服务的配置文件 .  


3. 创建备份目录 如 /var/backup 相当与 D:\cwRsyncServer\var\backup 也就是 /cygdrive/d/cwRsyncServer/var/backup4. 确定administrator对 D:\cwRsyncServer 目录有完全控制的权限 包括子目录 (可以略去  前面安装的时候 安装程序已经自动设定了)
5. 在服务里面启动 RsyncServer 服务 正常的话可以看到873端口在listening 参考

概要

Web服务是作为一种沟通技术而被很好地制订出来，它为Internet提供最佳的互通能力。它们的标准化进程正高速地进行着，这必将引起它们会被更广泛的接受。尽管如此，从许多邮件列表、用户组和各种讨论来判断，在不同Web服务设计（Web Service Design）方法中仍然存在相当多的混乱情形。“Document/Literal” 意味着什么，而“RPC-style”又是什么，怎样使SOAP“message-style” 适合这呢？

这篇文章将会阐明和详细解释那些由Web服务标准化组定义的不同的Web服务设计方法学，阐明各种术语，着重解释它们的不同之处。在这里，我们将把精力放在如下的几个Web服务设计方法学，评估它们的优点和缺点，并在设计一种互通性Web服务中探究每一种类型得到多大程度的支持。

1.RPC/Encoded 样式
2.RPC/Literal 样式
3.Document/Literal 样式
4.Document /Literal 外覆样式

介绍

在市场上Web服务在相对存在较短的时间内，得到了巨大的认同和广泛的应用。其中一个主要原因当然是它们的那些非常早期的开放式标准，而这些标准就是市场上所有主要的Web服务推崇者所推动的；另一方面，在Web服务看起来应该像什么和他们应该如何通信这些方面，这些推崇者各有自己的偏爱。这已经导致今天的标准支持各种不同的关于web服务消息能怎样格式化和它们如何通信的方法，事实上，那些不同的通信类型是需要的。

这些描述和使用Web服务的相关标准是WSDL(Web服务描述语言)，一种标准的类似XML　Schema的语言，用它详细说明Web服务和简单对象访问协议（SOAP），Web服务使用的实际的沟通协议就是简单对象访问协议（SOAP）。在了解真正的设计方法学之前，让我们先阐述下在web服务领域中频繁使用到的各种术语。

沟通模式

让我们从沟通模式开始，在使用Web服务时我们应能本质地区别三种沟通方法：

1.远程进程调用：客户端给服务提供者发送一个SOAP请求并等待一个SOAP响应（同步沟通）。
2.发送消息： 客户端发送一个SOAP请求但不期望有SOAP响应返回（单向沟通）。
3.异步回调： 一个客户端用上述方法中的一种调用服务。然后，双方为回叫调用交换角色。这种模式能建立在前面两种模式之上。

SOAP 协议格式化规则

现在我们转到一个Web服务的SOAP的消息（本质上是消息的 元素）能如何格式化，WSDL1.1 区分两种不同绑定形式（参考soap的绑定形式）：RPC和Document（文档）。（译者注：RPC（消息包含参数并返回值）Document（消息包含文档））

RPC 样式
RPC样式指定 元素包含一个将被调用的web方法的名称的元素（wrapper element（封装元素））。这个元素依次为该方法的每个参数还有返回值作了记录。

Document　样式
如果是document 样式，就没有像在RPC样式中的wrapper元素。转而代之的是消息片断直接出现在 元素之下。没有任何SOAP格式化规则规定元素下能包含什么；它包含的是一个发送者和接收者都达成一致的XML文档。

第二种格式规则就是‘Use’ 属性。这与各种类型如何在XML中显示有关，它指定使用某种编码规则对消息片段进行编码，还是使用消息的具体架构来定义片段。如下就是提供的两种选择：

编码
如果use的值是”encoded”, 则每个消息片段将使用类型属性来引用抽象类型。通过应用由 encodingStyle 属性所指定的编码样式，可使用这些抽象类型生成具体的消息。最常用到的SOAP编码样式是在SOAP1.1中定义的一组序列化规则，它说明了对象、结构、数组和图形对象应该如何序列化。通常，在应用程序中使用SOAP编码着重于远程进程调用和以后适合使用RPC消息样式。

Literal
如果use 的值是”Literal”， 则每个片段使用 element 属性（对于简单片段）或 type 属性（对于复合片段）来引用具体架构，例如，数据根据指定的架构来序列化，这架构通常使用W3C XML架构来表述。

表1总结了各种不同的web服务参数的可选项。一个重要的事实就是，每个web服务开发人员要做三个独立的决定，使用什么“沟通模式”？什么SOAP格式化“样式”？最后用到什么SOAP消息编码类型？

引用

WSDL 参数                                         可用选项

Communication Patterns                   远程进程调用或单方消息发送

Style                                                  Document 或 RPC

Use                                                    Encoded 或 Literal

表1.Web服务参数。

虽然，理论上说，这些选项的任何一种组合都是可以的，但在实践中会明确偏爱某种组合而不是其它的，同时，各种标准和Web服务互用性组织（WS-I）也有某种明确的偏爱。

因此在实践中，仅Document/Literal 和 RPC/Encoded 得到了广泛的应用，同时也被大部分平台直接支持，这些平台显示在表2中。这个表也显示了对不同的style/use组合的WS-I 一致性测试结果。

引用

Style/Use 组合                支持的 Soap 工具                       WS-I 一致性

RPC/Encoded                 Microsoft, Axis 1.1                    Failed

RPC/Literal                     Axis 1.1                                    Failed

Document/Literal            Microsoft , Axis1.1                    Passed

表2. Web服务格式支持

由于Document/Encoded这种组合不支持现有使用的平台，所以没有测试。事实上Document/Encoded组合还没有真实的应用环境。

（未完待续）

一、  识别占用资源较多的语句的方法（4种方法）
1.  测试组和最终用户反馈的与反应缓慢有关的问题。
2.  利用V_$SQLAREA视图提供了执行的细节。（执行、读取磁盘和读取缓冲区的次数）
•  数据列
EXECUTIONS：执行次数
DISK_READS：读盘次数
COMMAND_TYPE：命令类型（3:select,2:insert;6:update;7delete;47:pl/sql程序单元）
OPTIMIZER_MODE：优化方式
SQL_TEXT：Sql语句
SHARABLE_MEM：占用shared pool的内存多少
BUFFER_GETS：读取缓冲区的次数
•  用途
1、帮忙找出性能较差的SQL语句
2、帮忙找出最高频率的SQL
3、帮忙分析是否需要索引或改善联接
3.  监控当前Oracle的session，如出现时钟的标志，表示此进程中的sql运行时间较长。
4.  Trace工具：
a)  查看数据库服务的初始参数：timed_statistics、user_dump_dest和max_dump_file_size
b)  Step 1: alter session set sql_trace=true
c)  Step 2: run sql；
d)  Step 3: alter session set sql_trace=false
e)  Step 4:使用 “TKPROF”转换跟踪文件
f)  Parse，解析数量大通常表明需要增加数据库服务器的共享池大小，
query或current提取数量大表明如果没有索引，语句可能会运行得更有效，
disk提取数量表明索引有可能改进性能，
library cache中多于一次的错过表明需要一个更大的共享池大小
二、  如何管理语句处理和选项
•  基于成本（Cost Based） 和基于规则（Rule Based） 两种优化器， 简称为CBO 和RBO
•  Optimizer Mode参数值:
Choose：如果存在访问过的任何表的统计数据 ，则使用基于成本的Optimizer,目标是获得最优的通过量。如果一些表没有统计数据，则使用估计值。如果没有可用的统计数据，则将使用基于规则的Optimizer
All_rows：总是使用基于成本的Optimizer，目标是获得最优的通过量
First_rows_n：总是使用基于成本的Optimizer，目标是对返回前N行（“n”可以是1，10，100或者1000）获得最优的响应时间
First_rows：用于向后兼容。使用成本与试探性方法的结合，以便快速传递前几行
RULE：总是使用基于规则的Optimizer
三、  使用数据库特性来获得有助于查看性能的处理统计信息（解释计划和AUTOTRACE）
No1: Explain Plan
A）  使用Explain工具需要创建Explain_plan表，这必须先进入相关应用表、视图和索引的所有者的帐户内. (@D:\oracle\ora92\rdbms\admin\utlxplan)
B）  表结构：
STATEMENT_ID：为一条指定的SQL语句确定特定的执行计划名称。如果在EXPLAN PLAN语句中没有使用SET STATEMENT_ID，那么此值会被设为NULL。
OPERATION：在计划的某一步骤执行的操作名称，例如：Filters，Index，Table，Marge Joins and Table等。
OPTION：对OPERATION操作的补充，例如：对一个表的操作，OPERATION可能是TABLE ACCESS，但OPTION可能为by ROWID或FULL。
Object_Owner：拥有此database Object的Schema名或Oracle帐户名。
Object_name：Database Object名
Object_type：类型，例如：表、视图、索引等等
ID：指明某一步骤在执行计划中的位置。
PARENT_ID：指明从某一操作中取得信息的前一个操作。通过对与ID和PARENT_ID使用Connect By操作，我们可以查询整个执行计划树。
C）  EXPLAIN搜索路径解释
•  全表扫描（Full Table Scans）(无可用索引,大量数据,小表 ,全表扫描hints,HWM(High Water Mark), Rowid扫描)
•  索引扫描
索引唯一扫描（Index Unique Scans）
索引范围扫描（Index Range Scans）
索引降序范围扫描（Index Range Scans Descending）
索引跳跃扫描（Index Skip Scans）
全索引扫描（Full Scans）
快速全索引扫描（Fast Full Index Scans）
索引连接（Index Joins）
位图连接（Bitmap Joins）
•  如何选择访问路径： CBO首先检查WHERE子句中的条件以及FROM子句，确定有哪些访问路径是可用的。然后CBO使用这个访问路径产生一组可能的执行计划，再通过索引、表的统计信息评估每个计划的成本，最后优化器选择成本最低的一个。
•  表的连接方式：
Nested Loops会循环外表（驱动表），逐个比对和内表的连接是否符合条件。在驱动表比较小，内表比较大，而且内外表的连接列有索引的时候比较好。当SORT_AREA空间不足的时候，Oracle也会选择使用NL。基于Cost的Oracle优化器(CBO)会自动选择较小的表做外表。（优点：嵌套循环连接比其他连接方法有优势,它可以快速地从结果集中提取第一批记录,而不用等待整个结果集完全确定下来。缺点：如果内部行源表(读取的第二张表（内表）已连接的列上不包含索引,或者索引不是高度可选时, 嵌套循环连接效率是很低的。如果驱动行源表(从驱动表中提取的记录)非常庞大时,其他的连接方法可能更加有效。）
SORT- merge JOIN，将两表的连接列各自排序然后合并，只能用于连接列相等的情况，适合两表大小相若的情况（在缺乏数据的选择性或者可用的索引时,或者两个源表都过于庞大(超过记录数的5%)时,排序合并连接将比嵌套循环连更加高效。但是,排列合并连接只能用于等价连接(WHERE D.deptno=E.dejptno,而不是WHERE D.deptno>=E.deptno)。排列合并连接需要临时的内存块,以用于排序(如果SORT_AREA_SIZE设置得太小的话)。这将导致在临时表空间占用更多的内存和磁盘I/O。）
HASH JOIN在其中一表的连接列上作散列，因此只有另外一个表做排序合并，理论上比SORT JOIN会快些，需要有足够的内存，而且打开了SORT_JOIN_ENABLE参数。(当缺少有用的索引时，哈希连接比嵌套循环连接更加有效。哈希连接可能比排序合并连接更快，因为在这种情况下只有一张源表需要排序。哈希连接也可能比嵌套循环连接更快，因为处理内存中的哈希表比检索B_树索引更加迅速。和排序合并连接、群集连接一样，哈希连接只能用于等价连接。和排序合并连接一样，哈希连接使用内存资源，并且当用于排序内存不足时，会增加临时表空间的I/O（这将使这种连接方法速度变得极慢）。最后，只有基于代价的优化器才可以使用哈希连接。)
索引连接:
No2: AUTOTRACE
•  set autotrace 使用步骤：
1、以system登录
2、创建plustrace角色; \sqlplus\admin\plustrce.sql
3、向常规用户授予权限：grant plustrace to
4、如果没有plan_table也要创建: \rdbms\admin\utlxplan.sql
•  set autotrace 选项
on                    显示查询结果，执行计划，统计数据
on statistics             显示查询结果，统计数据，不显示执行计划
on explain              显示查询结果，执行计划，不显示统计数据
traceonly                显示执行计划和统计结果，但不包括查询结果
traceonly statistics     仅显示统计数据
recursive calls  在用户级别和系统级别上生成的递归调用的数量。Oracle维护了一些用于内部处理的表。当oracle需要对这些表进行更改时，它就会在内部生成一个SQL语句，然后这个语句再生成一个递归调用。
db block gets  请求一个CURRENT块的次数
consistent gets  为一块请求consistent read的次数
physical reads  从磁盘读取得数据块总数。这个数量等于“直接物理读取”的值加上读入缓冲区的所有数据块
redo size  生成的重做的总数量（以字节为单位）
bytes sent via SQL * Net to client  从前台进程发送给客户的总字节数
bytes received via SQL * Net from client  通过Oracle Net从客户接收的总字节数
SQL*Net roundtrips to/from client  发送给客户和从客户接收的Oracle Net消息的总数
sorts (memory)  完全在内存中执行并且不需要任何磁盘写入的排序操作的数量
sorts (disk)  至少需要一个磁盘写入的排序操作的数量
rows processed  在操作过程中处理的行数

四、最后，使用计时特性来测量和比较处理时间
Set timing on

 “推”由于篇幅的原因，只对 SERVER PUSH作了一般的介绍，下面我们来看看SERVER PUSH的具体实现过程：
  一、作业系统：
  目前 SERVER PUSH还不能在WIN9X上实现，至少是我自己还没有在WIN9X作为主机上实现过这一功能。经笔者试验成功的作业系统有：WINNT4.0,UNIX,LINUX,FREEBSD，以LINUX支持最好。因为我使用的LINUX都是最新的版本，可以方便地编译最新的功能模块。当然还有其它的作业系统也能很好地支持 SERVER PUSH功能，但笔者限于条件没有测试过。
  二、WWW服务器：
  其实目前除了IIS和APACHE这两个WWW服务器，你没有更好的选择，值得庆辛的是它们都能很好地支持 SERVER PUSH，当然你应该选择它们的最新版。别的那些小孩子过家家那样的WWW服务器就不用试了。在这里笔者极力推荐在LINUX上安装APACHE，以便能自由编译功能模块，这样可以充分使用SERVER PUSH、FASTCGI、E－CGI、HPH等新的扩展功能。
  三、脚本支持：
  虽然 SERVER PUSH可以用更多的脚本程序来编写，但笔者强烈推荐用PERL或C语言来写CGI脚本，因为PERL已经是CGI脚本程序事实上的标准。而且在PERL5中已经可以直接调用C子程序而不需要任何声明。不管你用什么语言来写CGI脚本，解释器中应该有CGI.PM模块，笔者试用的版本是 5.004，这一模块的更新版大家可以从网上下载，找不到？用搜索引擎输入CGI.PM就行了，要多少个都有。
  好了，有了上面的工具，下面我们就来写一个 SERVER PUSH程序来说明它的实现过程：

  use CGI qw/:push -nph/;这一行告诉CGI解释程序，调用支持SERVER PUSH的功能模块(CGI.PM)，在这个模块中预先定义了三个函数：multipart_init()、multipart_start()和multipart_end，只要在程序中有use CGI qw/:push -nph/声明。就可以直接使用这三个函数。
  multipart_init()函数的作用是声明了一个文档类型，就象普通的CGI程序中的“Content-Type: text/html”声明，告诉服务器下面传送的是HTML文档，而multipart_init()这一函数声明的文件类型却是实现SERVER PUSH最根本的方法类型：Content-Type: multipart/x-mixed-replace; boundary=''--boundary''如果你对HTTP的MIME类型有详细的了解，你就知道multipart类型是一种复合类型，它的子类型是mixed，子类型的X参数大家可以参看详细的MIME类型说明，这里最关键的是replace方法，它不停地用新接收的数据更新旧的数据。这，就是SERVER PUSH最大的技术内函。boundary只是一个边界值，告诉浏览器从这儿开始，使用SERVER PUSH方法了。其实你完全可以这样理解，只要在脚本程序中声明了multipart/x-mixed-replace; boundary=''--boundary''这样一个文档类型，服务器就和客户机建立了一个特别的连结。服务器就不断地把客户机请求的数据源源不断地推向了客户机。而传统的CLIENT PULL方法是：1、CLIENT和SERVER建立连结。2、CLIENT发送请求。3、SERVER响应请求。4、SERVER断开连结以响应下一请求。通过这两种方法的比较大家可以看出SERVER PUSH优点主要在于服务器和客户机之间这种不间断的连结方式。使得它不需要采用CLIENT PULL的这种方法来刷新页面，不仅更新速度快，而且不会产生闪动效果。
  可以看到，如果你不用multipart_init()，直接在脚本程序中用这样的语句也可以达到同样的目的：
 print "Content-Type: multipart/x-mixed-replace;boundary=''boundary''nn"
 这样做的好处是当系统不能支持multipart_init()函数时，就可以直接这样声明.
  multipart_start()这个函数是为服务器指定了传送一个确定的文档，如果不用这个函数，根据脚本程序的内容服务器可以直接把指定数据传送给客户机，当然客户机不能识别这种类型的文档可以忽略而不会产生错误。但如果你指明了具体的文档类型，如例程中的text/plain(纯文本类型)，客户机就不要再对文档加以分析从而提高了处理速度。否则客户机只知道传送过来的是multipart(复合型)而要重新对其分析。
  至于multipart_end函数不需作详细说明，只是说明了一个PUSH过程的结束。
为了使大家能更好地理解这三个函数详细的技术内容，我把这三个函数的实现过程解析给大家：