问题背景及特点：

    我们在使用多用户数据库时常常会碰到数据更新失败、删除失等情况，如果有多个用户且同时访问一个数据库则当他们的事务同时使用相同的数据时可能会发生并发问题。

    并发问题包括：

    1.丢失或覆盖更新。(幻像读)

    2.未确认的相关性（脏读）。

    3.不一致的分析（非重复读）。

    详细描述：

    1.丢失更新

    当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。

    例如，两个编辑人员制作了同一文档的电子复本。每个编辑人员独立地更改其复本，然后保存更改后的复本，这样就覆盖了原始文档。最后保存其更改复本的编辑人员覆盖了第一个编辑人员所做的更改。如果在第一个编辑人员完成之后第二个编辑人员才能进行更改，则可以避免该问题。

    2.未确认的相关性（脏读）

    当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。

    例如，一个编辑人员正在更改电子文档。在更改过程中，另一个编辑人员复制了该文档（该复本包含到目前为止所做的全部更改）并将其分发给预期的用户。此后，第一个编辑人员认为目前所做的更改是错误的，于是删除了所做的编辑并保存了文档。分发给用户的文档包含不再存在的编辑内容，并且这些编辑内容应认为从未存在过。如果在第一个编辑人员确定最终更改前任何人都不能读取更改的文档，则可以避免该问题。

    3.不一致的分析（非重复读）

    当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。

    例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。

    4.幻像读

    当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。

    例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。
-----------------------------------------------------------------------------------------------
    从上面可以看到，解决并发主要是用到了锁和事务。

    锁  ：给记录或表加上锁是为了对当前操作对象加上一个状态表示位，让其它用户在获取编辑权限时有了判断。

    事务：是为了保证一组操作的完整性。(要么就全部成功，要么就全部失败)

-----------------------------------------------------------------------------------------------
    一般处理并发问题时我这样做：

    1.开启事务。

    2.申请写权限，也就是给对象(表或记录)加锁。

    3.如果失败，则结束事务，过一会重试。

    4.如果成功，也就是给对象加锁成功，防止其它用户再用同样的方式打开。

    5.进行编辑操作。

    6.写入所进行的编辑结果。

    7.如果写入成功，则提交事务,完成操作。

    8.如果写入失败，则回滚事务，取消提交。

    9.(7.8)两步操作已释放了锁定的对象，恢复到操作前的状态。

UPDATE语句用于创建一个更新查询，根据指定的条件更改指定表中的字段值。UPDATE语句不生成结果集，而且当使用更新查询更新记录之后，不能取消这次操作。

语法：UPDATE table SET newvalue WHERE criteria

说明：table参数指定表的名称，其中包含要更改的数据。
newvalue参数为一个表达式，用来计算要插入更新记录中特定字段的值。
criteria参数为一个表达式，用来指定被更新的记录。只有符合表达式的记录才会被更新。

名称

UPDATE — 替换表中列/字段的数值

语法

UPDATE table SET col = expression [, ...]
    [ FROM fromlist ]
    [ WHERE condition ]

输入

table

现存表的名称．

column

表 table 中列/字段的名．

expression

赋予列/字段的一个有效的值或表达式．

fromlist

Postgres 的一个非标准的扩展，允许别的表中的列/字段出现在 WHERE 条件里．

condition

UPDATE films SET kind = 'Dramatic' WHERE kind = 'Drama';
SELECT * FROM films WHERE kind = 'Dramatic' OR kind = 'Drama';

 code  |     title     | did | date_prod  |   kind   | len
-------+---------------+-----+------------+----------+-------
 BL101 | The Third Man | 101 | 1949-12-23 | Dramatic | 01:44
 P_302 | Becket        | 103 | 1964-02-03 | Dramatic | 02:28
 M_401 | War and Peace | 104 | 1967-02-12 | Dramatic | 05:57
 T_601 | Yojimbo       | 106 | 1961-06-16 | Dramatic | 01:50
 DA101 | Das Boot      | 110 | 1981-11-11 | Dramatic | 02:29

UPDATE table SET column = expression [, ...]
    WHERE CURRENT OF cursor

51Testing软件测试网  www.51testing.com
测试时代  www.testage.net
CSDN——软件测试频道  testing.csdn.net
希赛网——软件测试频道  testing.csai.cn
中国软件测试联盟  www.iceshi.com
一起测试网  www.17testing.com
北大测试  www.btesting.com
中国软件测试基地 www.cntesting.com
中国软件评测中心  www.cstc.org.cn
中国软件质量网  www.rjzl.gov.cn

测试时代论坛  www.testage.net/bbs

中国软件测试社区 http://www.sztest.net/forum/

海松宝的小屋  http://www1.testage.net/haisongbao/

Alan工作室  http://alanzhou.nease.net/index.htm

软件工程专家网  http://www.51cmm.com/

51testing软件测试网（慧谷-博为峰软件测试工作室）  www.51testing.com

中国软件测试在线  http://www.softtest.cn/

杨柳清风论坛  http://www.kaiyuanlaw.com/dvbbs/

天极网的软件测试板块  

http://www.yesky.com/SoftChannel/72342393369657344/index.shtml

测试工程师  http://opentest.51.net/index.htm

自由龙（好像是珠海的）   http://www.freedragon.net/

选用适合的ORACLE优化器
ORACLE的优化器共有3种

A、RULE (基于规则) b、COST (基于成本) c、CHOOSE (选择性)

    设置缺省的优化器，可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。 你当然也在SQL句级或是会话(session)级对其进行覆盖。

    为了使用基于成本的优化器(CBO， Cost-Based Optimizer) ， 你必须经常运行analyze 命令，以增加数据库中的对象统计信息(object statistics)的准确性。

    如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze命令有关。 如果table已经被analyze过， 优化器模式将自动成为CBO ， 反之，数据库将采用RULE形式的优化器。

    在缺省情况下，ORACLE采用CHOOSE优化器， 为了避免那些不必要的全表扫描(full table scan) ， 你必须尽量避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。


2.访问Table的方式
ORACLE 采用两种访问表中记录的方式：

A、 全表扫描

全表扫描就是顺序地访问表中每条记录。ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。

B、 通过ROWID访问表

    你可以采用基于ROWID的访问方式情况，提高访问表的效率， ROWID包含了表中记录的物理位置信息。ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。


3.共享SQL语句
    为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享。 因此，当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同， ORACLE就能很快获得已经被解析的语句以及最好的执行路径。ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用。

    可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。

    数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。

    当你向ORACLE提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格，换行等)。

    数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。

共享的语句必须满足三个条件：

A、 字符级的比较： 当前被执行的语句和共享池中的语句必须完全相同。

B、 两个语句所指的对象必须完全相同：

C、 两个SQL语句中必须使用相同的名字的绑定变量(bind variables)。


4.选择最有效率的表名顺序(只在基于规则的优化器中有效)
    ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表。当ORACLE处理多个表时， 会运用排序及合并的方式连接它们。首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，然后扫描第二个表(FROM子句中最后第二个表)，最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。

    如果有3个以上的表连接查询， 那就需要选择交叉表(intersection table)作为基础表， 交叉表是指那个被其他表所引用的表。


5.WHERE子句中的连接顺序
    ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前， 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。


6.SELECT子句中避免使用 ' * '
    当你想在SELECT子句中列出所有的COLUMN时，使用动态SQL列引用 '*' 是一个方便的方法。不幸的是，这是一个非常低效的方法。实际上，ORACLE在解析的过程中， 会将'*' 依次转换成所有的列名， 这个工作是通过查询数据字典完成的， 这意味着将耗费更多的时间。


7.减少访问数据库的次数
    当执行每条SQL语句时，ORACLE在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等。由此可见，减少访问数据库的次数，就能实际上减少ORACLE的工作量。


8.使用DECODE函数来减少处理时间
    使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。


9.整合简单，无关联的数据库访问
    如果你有几个简单的数据库查询语句，你可以把它们整合到一个查询中(即使它们之间没有关系)


10.删除重复记录

11.用TRUNCATE替代DELETE
    当删除表中的记录时，在通常情况下， 回滚段(rollback segments ) 用来存放可以被恢复的信息。 如果你没有COMMIT事务，ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)。

    而当运用TRUNCATE时， 回滚段不再存放任何可被恢复的信息。当命令运行后，数据不能被恢复。因此很少的资源被调用，执行时间也会很短。


12.尽量多使用COMMIT
    只要有可能，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT所释放的资源而减少

COMMIT所释放的资源：

A、 回滚段上用于恢复数据的信息。

B、被程序语句获得的锁。

C、 redo log buffer 中的空间。

D、ORACLE为管理上述3种资源中的内部花费。


13.计算记录条数
    和一般的观点相反，count(*) 比count(1)稍快，当然如果可以通过索引检索，对索引列的计数仍旧是最快的。例如 COUNT(EMPNO)


14.用Where子句替换HAVING子句
    避免使用HAVING子句，HAVING 只会在检索出所有记录之后才对结果集进行过滤。 这个处理需要排序，总计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。


15.减少对表的查询
    在含有子查询的SQL语句中，要特别注意减少对表的查询。


16.通过内部函数提高SQL效率。

17.使用表的别名(Alias)
    当在SQL语句中连接多个表时， 请使用表的别名并把别名前缀于每个Column上。这样一来，就可以减少解析的时间并减少那些由Column歧义引起的语法错误。


18.用EXISTS替代IN
    在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率。


19.用NOT EXISTS替代NOT IN
    在子查询中，NOT IN子句将执行一个内部的排序和合并。 无论在哪种情况下，NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历)。为了避免使用NOT IN ，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。


20.用表连接替换EXISTS
    通常来说，采用表连接的方式比EXISTS更有效率


21.用EXISTS替换DISTINCT
    当提交一个包含一对多表信息(比如部门表和雇员表)的查询时，避免在SELECT子句中使用DISTINCT。 一般可以考虑用EXIST替换

　　无论是客户端还是服务器端多线程Java程序，最常见的多线程问题包括死锁、隐性死锁和数据竞争。

　　死锁

　　死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

　　导致死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的作用是，确保在某个时刻只有一个线程被允许执行特定的代码块，因此，被允许执行的线程首先必须拥有对变量或对象的排他性的访问权。当线程访问对象时，线程会给对象加锁，而这个锁导致其它也想访问同一对象的线程被阻塞，直至第一个线程释放它加在对象上的锁。

　　由于这个原因，在使用“synchronized”关键词时，很容易出现两个线程互相等待对方做出某个动作的情形。代码一是一个导致死锁的简单例子。

//代码一
class Deadlocker {
 int field_1;
 private Object lock_1 = new int[1];
 int field_2;
 private Object lock_2 = new int[1];

 public void method1(int value) {
  “synchronized” (lock_1) {
   “synchronized” (lock_2) {
    field_1 = 0; field_2 = 0;
   }
  }
 }

 public void method2(int value) {
  “synchronized” (lock_2) {
   “synchronized” (lock_1) {
    field_1 = 0; field_2 = 0;
   }
  }
 }
}

　　参考代码一，考虑下面的过程：

　　◆　一个线程（ThreadA）调用method1()。

　　◆　ThreadA在lock_1上同步，但允许被抢先执行。

　　◆　另一个线程（ThreadB）开始执行。

　　◆　ThreadB调用method2()。

　　◆　ThreadB获得lock_2，继续执行，企图获得lock_1。但ThreadB不能获得lock_1，因为ThreadA占有lock_1。

　　◆　现在，ThreadB阻塞，因为它在等待ThreadA释放lock_1。

　　◆　现在轮到ThreadA继续执行。ThreadA试图获得lock_2，但不能成功，因为lock_2已经被ThreadB占有了。

　　◆　ThreadA和ThreadB都被阻塞，程序死锁。

　　当然，大多数的死锁不会这么显而易见，需要仔细分析代码才能看出，对于规模较大的多线程程序来说尤其如此。好的线程分析工具，例如JProbe Threadalyzer能够分析死锁并指出产生问题的代码位置。

　　隐性死锁

　　隐性死锁由于不规范的编程方式引起，但不一定每次测试运行时都会出现程序死锁的情形。由于这个原因，一些隐性死锁可能要到应用正式发布之后才会被发现，因此它的危害性比普通死锁更大。下面介绍两种导致隐性死锁的情况：加锁次序和占有并等待。

　　加锁次序

　　当多个并发的线程分别试图同时占有两个锁时，会出现加锁次序冲突的情形。如果一个线程占有了另一个线程必需的锁，就有可能出现死锁。考虑下面的情形，ThreadA和ThreadB两个线程分别需要同时拥有lock_1、lock_2两个锁，加锁过程可能如下：

　　◆　ThreadA获得lock_1；

　　◆　ThreadA被抢占，VM调度程序转到ThreadB；

　　◆　ThreadB获得lock_2；

　　◆　ThreadB被抢占，VM调度程序转到ThreadA；

　　◆　ThreadA试图获得lock_2，但lock_2被ThreadB占有，所以ThreadA阻塞；

　　◆　调度程序转到ThreadB；

　　◆　ThreadB试图获得lock_1，但lock_1被ThreadA占有，所以ThreadB阻塞；

　　◆　ThreadA和ThreadB死锁。

　　必须指出的是，在代码丝毫不做变动的情况下，有些时候上述死锁过程不会出现，VM调度程序可能让其中一个线程同时获得lock_1和lock_2两个锁，即线程获取两个锁的过程没有被中断。在这种情形下，常规的死锁检测很难确定错误所在。

　　占有并等待

　　如果一个线程获得了一个锁之后还要等待来自另一个线程的通知，可能出现另一种隐性死锁，考虑代码二。

//代码二
public class queue {
 static java.lang.Object queueLock_;
 Producer producer_;
 Consumer consumer_;

 public class Producer {
  void produce() {
   while (!done) {
    “synchronized” (queueLock_) {
     produceItemAndAddItToQueue();
     “synchronized” (consumer_) {
      consumer_.notify();
     }
    }
   }
  }

  public class Consumer {
   consume() {
    while (!done) {
     “synchronized” (queueLock_) {
      “synchronized” (consumer_) {
       consumer_.wait();
      }
      removeItemFromQueueAndProcessIt();
     }
    }
   }
  }
 }
}

　　在代码二中，Producer向队列加入一项新的内容后通知Consumer，以便它处理新的内容。问题在于，Consumer可能保持加在队列上的锁，阻止Producer访问队列，甚至在Consumer等待Producer的通知时也会继续保持锁。这样，由于Producer不能向队列添加新的内容，而Consumer却在等待Producer加入新内容的通知，结果就导致了死锁。

　　在等待时占有的锁是一种隐性的死锁，这是因为事情可能按照比较理想的情况发展—Producer线程不需要被Consumer占据的锁。尽管如此，除非有绝对可靠的理由肯定Producer线程永远不需要该锁，否则这种编程方式仍是不安全的。有时“占有并等待”还可能引发一连串的线程等待，例如，线程A占有线程B需要的锁并等待，而线程B又占有线程C需要的锁并等待等。

　　要改正代码二的错误，只需修改Consumer类，把wait()移出“synchronized”()即可。

　　数据竞争

　　数据竞争是由于访问共享资源（例如变量）时缺乏或不适当地运用同步机制引起。如果没有正确地限定某一时刻某一个线程可以访问变量，就会出现数据竞争，此时赢得竞争的线程获得访问许可，但会导致不可预知的结果。

　　由于线程的运行可以在任何时候被中断（即运行机会被其它线程抢占），所以不能假定先开始运行的线程总是比后开始运行的线程先访问到两者共享的数据。另外，在不同的VM上，线程的调度方式也可能不同，从而使数据竞争问题更加复杂。

　　有时，数据竞争不会影响程序的最终运行结果，但在另一些时候，有可能导致不可预料的结果。

　　良性数据竞争

　　并非所有的数据竞争都是错误。考虑代码三的例子。假设getHouse()向所有的线程返回同一House，可以看出，这里会出现竞争：BrickLayer从House.foundationReady_读取，而FoundationPourer写入到House.foundationReady_。

//代码三
public class House {
 public volatile boolean foundationReady_ = false;
}

public class FoundationPourer extends Thread {
 public void run() {
  House a = getHouse();
  a.foundationReady_ = true;
 }
}

public class BrickLayer extends Thread {
 public void run() {
  House a = getHouse();
   while (!a.foundationReady_) {
    try {
     Thread.sleep(500);
    }
    catch (Exception e) {
     System.err.println(“Exception:” + e);
    }
   }
  }
 } 
}

　　尽管存在竞争，但根据Java VM规范，Boolean数据的读取和写入都是原则性的，也就是说，VM不能中断线程的读取或写入操作。一旦数据改动成功，不存在将它改回原来数据的必要（不需要“回退”），所以代码三的数据竞争是良性竞争，代码是安全的。

　　恶性数据竞争

　　首先看一下代码四的例子。

//代码四
public class Account {
 private int balance_; // 账户余额
 public int getBalance(void) {
  return balance_;
 }
 public void setBalance(int setting) {
  balance_ = setting;
 }
}

public class CustomerInfo {
 private int numAccounts_;
 private Account[] accounts_;
 public void withdraw(int accountNumber, int amount) {
  int temp = accounts_[accountNumber].getBalance();
  temp = temp - amount;
  accounts_[accountNumber].setBalance(temp);
 }
 public void deposit(int accountNumber, int amount) {
  int temp = accounts_[accountNumber].getBalance();
  temp = temp + amount;
  accounts_[accountNumber].setBalance(temp);
 }
}

　　如果丈夫A和妻子B试图通过不同的银行柜员机同时向同一账户存钱，会发生什么事情？让我们假设账户的初始余额是100元，看看程序的一种可能的执行经过。

　　B存钱25元，她的柜员机开始执行deposit()。首先取得当前余额100，把这个余额保存在本地的临时变量，然后把临时变量加25，临时变量的值变成125。现在，在调用setBalance()之前，线程调度器中断了该线程。

　　A存入50元。当B的线程仍处于挂起状态时，A这面开始执行deposit()：getBalance()返回100（因为这时B的线程尚未把修改后的余额写入），A的线程在现有余额的基础上加50得到150，并把150这个值保存到临时变量。接着，A的线程在调用setBalance()之前，也被中断执行。

　　现在，B的线程接着运行，把保存在临时变量中的值（125）写入到余额，柜员机告诉B说交易完成，账户余额是125元。接下来，A的线程继续运行，把临时变量的值（150）写入到余额，柜员机告诉A说交易完成，账户余额是150元。

　　最后得到的结果是什么？B的存款消失不见，就像B根本没有存过钱一样。

　　也许有人会认为，可以把getBalance()和setBalance()改成同步方法保护Account.balance_，解决数据竞争问题。其实这种办法是行不通的。“synchronized”关键词可以确保同一时刻只有一个线程执行getBalance()或setBalance()方法，但这不能在一个线程操作期间阻止另一个线程修改账户余额。

要正确运用“synchronized”关键词，就必须认识到这里要保护的是整个交易过程不被另一个线程干扰，而不仅仅是对数据访问的某一个步骤进行保护。

　　所以，本例的关键是当一个线程获得当前余额之后，要保证其它的线程不能修改余额，直到第一个线程的余额处理工作全部完成。正确的修改方法是把deposit()和withdraw()改成同步方法。

　　死锁、隐性死锁和数据竞争是Java多线程编程中最常见的错误。要写出健壮的多线程代码，正确理解和运用“synchronized”关键词是很重要的。另外，好的线程分析工具，例如JProbe Threadalyzer，能够极大地简化错误检测。对于分析那些不一定每次执行时都会出现的错误，分析工具尤其有用。

1. http协议

除了TCP/IP协议，http可以说是最重要，且使用最多的网络协议了。本节简要介绍一下http协议的工作原理。

假设现在有一个html文件:http.html, 存放在Web服务器上，其URL为www.myweb.com/http.html ,文件内容为:
HTML 代码:
<html>
<head>
<title>http.html</title>
</head>
<body>
hello, http
</body>
</html>

现在，一个用户通过IE访问该地址，IE首先将此地址的域名通过DNS转换为一个IP地址，然后通过一个Web服务器开放的端口（默认为80，不为80需在域名后加上“:端口号”，例如www.myweb.com:81）与其连接, 然后传送一个类似这样的http请求（使用flashget等下载软件下载文件时，在详细信息里也可以看到类似的信息）:

GET /http.html HTTP/1.1
Host: www.myweb.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE.6.0; Windows NT 5.1)
Pragma: no-cache
Cache-Control: no-cache
Connection: close
[空行]

请求的第一行为请求内容, 表示通过GET方法向服务器请求资源，/http.html为请求资源名称，HTTP/1.1 表示使用http协议，版本1.1。然后接下来的几行称为请求信息的标头(header)，其中描述了请求的一些其他信息，比如客户端浏览器标识等。最后一个空行表示请求结束。

当Web服务器接收到该请求时，服务器检查所请求的资源是否有效，且是否有相应的权限。如果没有问题，则服务器会传回类似如下的http响应信息:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thursday, March 31, 2005 17:15:23 GMT
Content-Type: text/html
Content-Length: 88
[空行]
<html>
<head>
<title>http.html</title>
</head>
<body>
hello, http
</body>
</html>

其中第一行的“200”是一个状态码，表示服务器成功完成该请求，如果不成功会返回其他状态码。Content-Type表示返回的数据类型，Content-Length表示返回的数据长度。空行表示标头结束，下面则是浏览器根据请求返回的数据内容，这里是http.html的文件内容，浏览器解析html源代码，将Web页面呈现给用户，到这里就完成了一次成功的http通信。

以上内容是Web通信的基础，就和Windows消息机制一样，你可能不会用到它，但是你必须了解它，你得知道那些高级的东西隐藏了哪些低级的内容，这样对你理解和使用那些高级的东西都有非常大的帮助:)。

2. html form

前面的http.html文件是一个最简单的静态html页面，但作为一个Web程序，它实在是太简陋了，它不接受用户输入，永远显示一样的内容。我们需要能够根据用户输入来返回相应的数据。

看下面的html代码:
<html>
<head>
<title>form.html</title>
</head>
<body>
    <form method=”get”>
          <input type=”text” name=”p” />
          <input type=”submit” value=”submit” />
    </form>
</body>
</html>

观察这段代码，其中有一个html form，其内容包括在<form>和</form>之间, 其中有一个提交按钮(<input type=”submit” value=”submit” />)，当用户点击该按钮时，浏览器将html form中的所有输入提交给Web服务器，form标签的method属性指定了提交的方式，这里为get，这个get对应http请求中的GET请求方法,form中的输入均以查询字符串的方式附加在URL上, 在文本框里输入一个字符串，比如“form”，然后观察浏览器的地址栏,会变成类似 http://www.myweb.com/form.html?p=form ，这是因为浏览器发出了这样的GET请求:

GET /form.html?p=form HTTP/1.1
...
...
[空行]

假如<form>标签的method属性为”post”,即令浏览器使用post方法发送该请求，当使用post方法时，用户的输入并不是通过URL来传输的，而是浏览器将内容放在POST请求的标头之后发送给Web服务器的:
POST /form.html HTTP/1.1
...
...
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
[空行]
p=form

浏览器将用户输入使用GET或者POST方法发送给Web服务器，这个过程称为“回发(Postback)”。这个概念相当重要，在Web应用程序中经常涉及到回发。

关于网络数据库里一些商业数据被盗窃后公布于网上；公司商业网站的产品价格数据又被恶意修改……类似这样的案例，在网上搜索了一下，实在不少。其原因只有一个，就是来自网络上对Web数据库攻击。那么，在Web环境下的数据库是否能有足够的安全为企业服务呢?答案是肯定的。

　　Web数据库是基于Internet/Intranet的应用系统，由于互连网开放性和通信协议的安全缺陷，以及在网络环境中数据存储和对其访问与处理的分布性特点，网上传输的数据容易受到破坏、窃取、篡改、转移和丢失。这些危害通常是对网络的攻击引起的。

　　到现在，针对Web数据库的应用级入侵已经变得越来越猖獗，如SQL注入、跨站点脚本攻击和未经授权的用户访问等。

　　所有这些入侵都有可能绕过前台安全系统并对数据库系统攻击。如何保证Web数据库的安全性已成为新的课题。

　　第一关、对用户安全管理

　　Web数据库是个极为复杂的系统，因此很难进行正确的配置和安全维护，当然，必须首先要保证的就是数据库用户的权限的安全性。

　　当用户通过Web方式要对数据库中的对象(表、视图、触发器、存储过程等)进行操作时，必须通过数据库访问的身份认证。多数数据库系统还有众所周知的默认账号和密码，可支持对数据库资源的各级访问。因此，很多重要的数据库系统很可能受到威协。

　　用户存取权限是指不同的用户对于不同的数据对象有不同的操作权限。存取权限由两个要素组成：数据对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据对象上进行哪些类型的操作。

　　权限分系统权限和对象权限两种。系统权限由DBA授予某些数据库用户，只有得到系统权限，才能成为数据库用户。对象权限是授予数据库用户对某些数据对象进行某些操作的权限，它既可由DBA授权，也可由数据对象的创建者授予。

　　第二关、定义视图

　　为不同的用户定义不同的视图，可以限制用户的访问范围。通过视图机制把需要保密的数据对无权存取这些数据的用户隐藏起来，可以对数据库提供一定程度的安全保护。实际应用中常将视图机制与授权机制结合起来使用，首先用视图机制屏蔽一部分保密数据，然后在视图上进一步进行授权。

　　第三关、数据加密

　　数据安全隐患无处不在。一些机密数据库、商业数据等必须防止它人非法访问、修改、拷贝。如何保证数据安全?数据加密是应用最广、成本最低廉而相对最可靠的方法。数据加密是保护数据在存储和传递过程中不被窃取或修改的有效手段。

　　数据加密系统包括对系统的不同部分要选择何种加密算法、需要多高的安全级别、各算法之间如何协作等因素。在系统的不同部分要综合考虑执行效率与安全性之间的平衡。因为一般来讲安全性总是以牺牲系统效率为代价的。

　　如果要在Internet上的两个客户端传递安全数据，这就要求客户端之间可以彼此判断对方的身份，传递的数据必须加密，当数据在传输中被更改时可以被发觉。

　　第四关、事务管理和故障恢复

　　事务管理和故障恢复主要是对付系统内发生的自然因素故障，保证数据和事务的一致性和完整性。

　　故障恢复的主要措施是进行日志记录和数据复制。在网络数据库系统中，分布事务首先要分解为多个子事务到各个站点上去执行，各个服务器之间还必须采取合理的算法进行分布式并发控制和提交，以保证事务的完整性。

　　事务运行的每一步结果都记录在系统日志文件中，并且对重要数据进行复制，发生故障时根据日志文件利用数据副本准确地完成事务的恢复。

　　第五关、数据库备份与恢复

　　计算机同其他设备一样，都可能发生故障。计算机故障的原因多种多样，包括磁盘故障、电源故障、软件故障、灾害故障以及人为破坏等。一旦发生这种情况，就可能造成数据库的数据丢失。

　　因此数据库系统必须采取必要的措施，以保证发生故障时，可以恢复数据库。数据库管理系统的备份和恢复机制就是保证在数据库系统出故障时，能够将数据库系统还原到正常状态。

　　加强数据备份非常重要，数据库拥有很多关键的数据，这些数据一旦遭到破坏后果不堪设想，而这往往是入侵者真正关心的东西。不少管理员在这点上作得并不好，不是备份不完全，就是备份不及时。

　　数据备份需要仔细计划，制定出一个策略测试后再去实施，备份计划也需要不断地调整。

　　第六关、审计追踪机制

　　审计追踪机制是指系统设置相应的日志记录，特别是对数据更新、删除、修改的记录，以便日后查证。日志记录的内容可以包括操作人员的名称、使用的密码、用户的IP地址、登录时间、操作内容等。若发现系统的数据遭到破坏，可以根据日志记录追究责任，或者从日志记录中判断密码是否被盗，以便修改密码，重新分配权限，确保系统的安全。

　　第七关、重点在服务器

　　Web数据库的三层体系结构中，数据存放在数据库服务器中，大部分的事务处理及商业逻辑处理在应用服务器中进行，由应用服务器提出对数据库的操作请求。

　　理论上，既可以通过Web页面调用业务处理程序来访问数据库，也可以绕过业务处理程序，使用一些数据库客户端工具直接登录数据库服务器，存取操作其中的数据。所以，数据库服务器的安全设置至关重要。

　　用IDS(入侵检测系统)保卫数据库安全逐步普及，这种安全技术将传统的网络和操作系统级入侵探测系统(IDS)概念应用于数据库。应用IDS提供主动的、针对SQL的保护和监视，可以保护预先包装或自行开发的Web应用。

int lrs_disable_socket ( char *s_desc, int operation );