未分类 - oyaji's Blog

pro git 的中文版

http://progit.org/book/zh/

只是放个链接在这儿，给需要的人。

创业模式

最近在从事相关网络方面的工作，就把看到的模式记录一下。

导读：美国商业模式咨询机构Board of Innovation本周撰文，评选出2010年十大震撼创业模式。

以下为文章概要：

1. PatientsLikeMe.com

PatientsLikeMe是一家病友社区平台。在这里，用户可以相互分享病历，寻找与自己症状相似的病友，从而提高医疗效果。大约有7万名病人在这里分享了病历。

2. Flattr.com

这是一个小额捐款服务，使用方法类似于Facebook的“Like”按钮：可以将“flattred”捐款按钮部署在相关文章一侧，如果读者愿意，即可点击该按钮进行捐款。在PayPal、万事达和其他金融机构纷纷冻结了维基解密的捐款渠道后，这家瑞典服务成为了维基解密的重要资金来源，仅一篇文章就为维基解密贡献了3500多次捐款。

3. Groupon.com

Groupon每天都会推出一个团购交易，当购买人数达到最低限时，即可生效。借助这一独特模式，Groupon成为了有史以来增速最快的企业，并在全球吸引了数以百计的模仿者。

4. Spotify.com

这款流媒体音乐服务虽然免费为用户提供音乐，但却可以通过广告获取收入。去年8月，索尼唱片和BMG唱片都表示，通过Spotify获得的收入已经超过苹果iTunes。该网站目前的付费用户约为75万。

5. PayWithaTweet.com

这个网站可以将用户的社交关系转变成真金白银。无需通过现金购买产品，只要向自己的Twitter粉丝发布产品宣传信息，即获得相应的商品。

6. HumbleBundle.com

这是一家游戏捆绑销售网站，由开发商将游戏捆绑在一起对外销售，出价则完全由用户自主决定，而且还会将一部分收入捐给慈善机构。

7. 免费应用配合收费道具

通过这种模式，用户可以免费获得游戏或应用，如果还想获得额外体验，就需要付费购买虚拟道具。

8. Quircky.com

这是一个社会化创造平台。投资者只需要将自己的创意提交给该网站，并交纳99美元的费用，即可由一些选定的设计师共同对产品进行设计和改进。供应者可以设定最低预购数，如果买家数量超过这一最低限制，即可投入生产。

9. AirBnb.com

该网站完全采用了P2P模式，将普通人的空闲房屋陈列出来，帮助用户获得廉价而有特色的旅行住处。AirBnb会从每笔交易中收取最高12%的佣金。

10. Kickstarter.com

用户可以借助该平台展示自己的创意并募集资金。一款名为iPod Nano Watch的创意已经吸引到1.5万美元的投资，投资人总数达到13512人。

Ruby on Rails Optimizing Performance

Ruby on Rails is very fun, i love it, but Ruby sometimes can be slow.. So here there are some hints to speed up your Ruby on Rails web application.

Rails Performance Tips

Common Performance Problems in Rails – Pros and con between SQLSessionStore and MemChacheStore session containers, tips on optimizing queries, and general information regarding how to avoid slow helpers.
The Adventures of Scaling: Stage 1, Stage 2, Stage 3, Stage 4 – A detailed explanation a Rails production architecture.
Optimizing Rails Resource Usage – A short list of top Rails optimization tips, which include the proper use of caching.
Sustainable Performance with Ruby on Rails – A 58 page PDF presentation describing railsbench, caching, session performance, and efficient Ruby code.
Rails performance tips – A discussion on eager loading, excluding unnecessary columns, indexing database columns, and caching.
Top 10 Ruby on Rails performance tips – Provides great tips to optimize your ruby code and how to handle finders.
Performance related changes in Rails 1.1 – Discussion of performance enhancements in rails 1.1.
Rails performance and caching, Part 2 – A discussing of Rails performance using caching.
Stefan Kaes – Rails Performance – RubyConf 2006 conference notes on the Rails Performance presentation given by Stefan Kaes.
Stefen Kaes – Optimizing Rails – Another post on the Rails 2006 presentation by Stefan Kaes on Rails Performance.
Rails performance with FastCGI and Apache – A blog post on performance with Apache.
Rails Performance Tool Box – A list of tools that come in handy when optimizing a Ruby on Rails application, which include query analyzer, query trace, and mtop.
Rails Caching Documentation – Documentation for action, page, and fragment caching.
The effect of using Rails fragment caching – Goes over the performance boost of using fragment caching.

Rails Performance Tools

Query Builder Plugin – Bypass the overhead of construct_finder_sql.
QueryTrace Plugin – Helps to identify the location/caller of bad queries.
MySQL Query Analyzer Rails Plugin – Helpful to analyze SQL queries.
Rails Log Analyzer – Reads the Rails log files and exposes potential points of optimization.
Railsbench – “A small collection of ruby and shell scripts which make measuring raw performance of rails apps a snap.

from http://www.tanasi.it/1072-ruby-on-rails-optimizing-performance.html

补充：http://www.dcmanges.com/blog/rails-performance-tuning-workflow

TDD推荐教程

最近，Dave Nicolette从Extreme Programming讨论组的一场讨论中提炼出来了一系列的TDD推荐教程。读者在这里可以看到如何快速上手TDD的分类教程列表。

教程

TDD系列

演讲幻灯片

视频录音

Jean Paul Boodhoo的教程

一步步学习TDD

最近Dave还往列表中添加了一本TDD相关书籍的草稿，这本书的作者是Steve Freeman和Nat Pryce，还正处于写作阶段。在InfoQ上也有很多TDD的相关资源。最近的一些内容包括：

查看英文原文 ： Recommended TDD Tutorials

from infoq cn

什么是OpenID?

OpenID是一种开放、离散式的用于用户数字标识的开源框架。

请让我们思考自己所拥有的在线帐号种类：博客、wiki、to-do list、个人相册。在网络应用日益充斥的今天，这些个人在线帐号可谓不胜枚举，而对帐号的需要也同样无处不在，乃至当我们想在好友博客上进行评论时都需要注册成为该博客系统的用户。于是作为终端用户，我们不得不在每个网站上设置帐号，并管理众多的帐号。而采用OpenID技术的话，你就无须再管理这些相互独立的帐号，而是通过认证服务器管理自己唯一的身份标识。

OpenID常见的应用场景：某用户试图登录一个外部网站。与提交用户名和密码的方式不同，他只提交了属于自己的一个URL，例如：http://johnsmith.example.com/

这个URL即指向了用户的OpenID认证服务器，同时又是用户的身份标识。因此外部网站使用此URL便可以找到用户的认证服务器，并询问认证服务器：“该用户声称他拥有此URL。而这个URL说明了你负责认证工作，那么请告诉我，该用户能否访问我的站点？”。认证服务器将提示用户登入认证系统，并询问用户是否允许和外部网站进行认证。如果用户同意的话，那么认证服务器将通知外部网站——用户已经通过认证。在上面，我们通过拟人化的表达方式来形象生动地诠释整个认证请求/回应过程。

用户可以使用同一个URL用作在任何支持OpenID认证的外部网站中使用的标识。这正是OpenID与其它传统认证方式的最大不同。通过使用URL，可以使外部站点非常容易地获取到负责认证工作的服务器位置。而只有认证服务器才需要输入密码来验证用户身份。其它希望验证用户身份的站点都将询问用户所注册的认证服务器。如果你正在使用支持OpenID的门户站点（比如AOL），那么你就可以使用现成的AOL即时消息登录帐号来登录AOL站点，而无需另外注册。因此，我们可以猜想Google和Yahoo也许已经开始着手建造他们的OpenID服务。

你一定想知道OpenID是如何实现分散化服务的？由于用户具有选择OpenID服务提供者的权利，因此你会在最初选择AOL作为OpenID提供者，而过一段时间后，可能觉得希望更换到另外一个OpenID提供者，此时你所需要做的就是修改以下的HTML标签：

<link rel="openid.server" href="http://openid.example.com/">

保存这些link元数据的最常见位置就是个人站点（比如博客）的根页面。

如何使用OpenID?

OpenID 绝妙地解决了多个帐号同步问题，但并不仅仅如此。例如，你可以利用它建立跨应用、跨域的单点登录（Single sign-on）。如果你使用同一个OpenID登入了博客和个人相册，那么你只需要在登录过程中进行一次认证。对于在此之后的每个需要登录的应用（在同一个session周期）只需提供OpenID，而不是传统的用户名和密码。

大多数OpenID提供者也提供了支持多个配置的功能。这样你就可以使用“Bob Smith”登录博客，而使用“Robert J Smith”登录企业wiki。随着OpenID提供者的日益成熟和OpenID功能上的提升，我们不久就会使用对来自伙伴公司OpenID认证服务器主机名的用户进行认证的服务。

哪些网站支持OpenID?

OpenID技术出现不久，便获得了在众多公共消费站点的热捧：Digg、Six Apart、Zoomr和AOL。其中AOL为老用户提供了OpenID支持，使得六千五百万的登录用户在一日之内就全部能够使用OpenID。目前已经具有超过九千五百万的用户能够使用 OpenID登录系统，并且每天都有25至50个站点加入到支持OpenID规范的队伍中。另外，OpenID增加了对Firefox3和微软 Windows Vista的支持。

下面是实现了OpenID代码库的语言列表：
        • C#
        • C++
        • Java
        • Perl
        • Python
        • Ruby
        • PHP
        • Coldfusion

OpenID社区维护了这些代码库的清单：http://openid.net/wiki/index.php/Libraries。在本文的后面，我们将讨论到OpenID的Java实现：OpenID4Java(http://www.openid4java.org)。

OpenID协议综述

OpenID协议非常易于扩展，下面的图表展示了OpenID2.0草案的基本工作流程。它展示了在终端用户、Relying Party站点（一个示例站点）和OpenID服务提供者之间的交互过程（最常见的认证流程）。

用户登入外部站点的过程主要分为以下七个步骤：

1. Relying Party站点请求用户标识

此步骤非常简单：用户提供一个字符串（以URL或者XRI格式）给外部站点，使后者能够识别用户。

        1. 外部站点请求用户发送标识。通常使用带有Open图标的文本输入框、用于提交信息的按钮组成的form来完成此功能。为了方便起见，文本输入框的name 属性应为openid_identifier，这样以便浏览器自动将其识别为一个OpenID登录form。
        2.用户输入标识，标识可能采用下面的形式：
        • URI/URL (通过http或者https)
        • XRI。XRI是一种广义的、分散式的URI。它能用于任何使用URI的地方。XRI主要采用以下形式：xri://authority/path?query#fragment。了解更多关于XRI的信息请看：XRI语法规范。

用户标识类似这个样子：http://myname.myhost.com/。外部站点经常将OpenID logo放置到其登录form上，这样可以使你很快地辨别出是否使用OpenID。

用户在点击位于外部站点登录页面上的“Login”按钮后便启动了认证过程。

2.“标准化”: Relying Party站点整理用户标识

用户输入了标识后，此标识便由外部站点进行整理（标准化）。由于标识可能使用XRI或者URI格式，因此整理的过程非常复杂：
        1.如果标识以xri://、xri://$ip或者xri://$dns*开头，那么我们要去掉这些头部标记。
        2. 如果余下字符串中的第一个字符是XRI的全局上下文符号（=、@、+、 $、!），那么此字符串为标准的XRI标识。否则，将被视为HTTP URL（如果http/https前缀没有定义，我们需要为其添加上http://）。当然，URL必须遵守URL命名规范。最终获得的URL就是一个标准的URL标识。

下面是一些示例：

下面的流程图描绘了标准化处理过程：

3.“发现”: Relying Party站点查询与OpenID服务器进行通讯的方式

外部站点使用标准化的标识来查询用于发起请求所必须的信息。对于“发现”阶段来讲，其使用的解析协议和获取的结果文档都取决于在标准化阶段决定的标识类型。这正是OpenID2.0规范的特殊之处。

快速参考:

        • XRI 解析:类似通过UDP将主机名解析为IP的DNS协议；它将XRI转换为XRDS。其目的是提供一种将厚重、通用的XRI格式转换为真实可用的描述符。

        • YADIS协议:将URL连接到XRDS上。这是一种非常简单的协议，它将当前的HTTP或者HTTPS URL直接指向XRDS。

        • XRDS：一种基于XML的XRI资源描述符。它被设计用来提供关于XRI的可用的、描述性信息。在OpenID应用场合中，XRDS用来描述 OpenID服务器，并且使用“priority”参数标识了用户对服务器的优选顺序。在下面的示例中，http: //www.livejournal.com/users/frank具有最高的优先权（最低的数值）：

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
  <XRD>
    <Service priority="50">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://www.myopenid.com/server</URI>
      <openid:Delegate>http://smoker.myopenid.com/</openid:Delegate>
    </Service>
    <Service priority="10">
      <Type>http://openid.net/signon/1.0</Type>
      <URI>http://www.livejournal.com/openid/server.bml</URI>      <openid:Delegate>http://www.livejournal.com/users/frank/</openid:Delegate>
    </Service>
    <Service priority="20">
      <Type>http://lid.netmesh.org/sso/2.0</Type>
      <URI>http://mylid.net/liddemouser</URI>
    </Service>
  </XRD>
</xrds:XRDS>

• 使用HTML代码。在HTML的<head>部分必须提供以下标签：

<link rel="openid2.provider" href="http://openid.com/server/endpoint/url"/>

可选的，如果用户使用委派（delegation）（就是用户宣称拥有一个不存在于该OpenID服务器上的本地标识），则需要使用下面的标签：

<link rel="openid2.local_id" href="http://openid.com/server/endpoint/url"/>

例如，某人正在使用openidprovider.com这个OpenID服务器来验证他在另一个OpenID服务器usersite.com上的身份，那么其本地标识将使用类似user.openidprovider.com的形式。

这个“发现”的过程允许外部站点知道两件事，其中一件是外部站点如何与OpenID服务器进行通讯：
        1.OpenID提供者端点URL：OpenID提供者的最终URL（服务器URL）。
        2.认证协议版本: OpenID认证使用的协议版本。

作为可选的，如果用户使用委派，那么外部站点将需要知道：
        1.用户宣称的标识：此标识为用户宣称属于自己的。它是在登录过程中用户提供过的标识。
        2.本地标识（OP-Local Identifier）:用户在其OpenID服务器上拥有的本地标识。

例如，用户使用http://www.example.com/作为其标识，但外部网站实际上通过https: //www.exampleprovider.com/endpoint/这个OpenID服务器来验证用户标识https: //exampleuser.exampleprovider.com/。那么在对http://www.example.com/执行发现的过程中，我们需要在XRDS文档的最后一个XRD成员中提供下面的XML片段

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>https://www.exampleprovider.com/endpoint/</URI>
  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>

4. Relying Party站点建立与OpenID服务器之间的关联(可选)

通过在外部站点和OpenID服务器之间的关联（association），我们可以建立一种在两者之间共享的加密通道，它可以用来验证后续的协议信息并降低通讯回合数。在OpenID规范中对于实际创建关联的过程进行了详尽的描述。简单来讲就是使用了一种Diffie-Hellman密钥交换算法来生成共享密钥。此密钥用于对信息进行签名。

这样使得外部站点和OpenID服务器之间能够安全地通讯。这里指的“安全性”是通过传输层（使用SSL）或者通过应用层的HMAC SHA1或者HMAC SHA256算法实现的。关联请求的成果就是assoc_handle（关联权柄），外部站点和OpenID服务器将在本次关联的后继活动中将它作为对消息进行加密的密钥。

关联阶段被标为“可选的”，这是因为OpenID协议还允许外部站点直接请求认证（不作关联）、并且接着请求对认证信息进行验证。这样外部站点可以不保有关联权柄信息，以实现无状态通讯。而这种方式被推荐用于执行与OpenID服务器之间的相关通讯，但如果不能使用此方式的话，就必须创建上面讲的关联方式。

5. Relying Party站点请求认证

我们通过使用重定向页面可以建立认证请求。请查看下表中的重要参数值，详细信息请参考OpenID相关信息格式文档：

请注意：外部站点并没有直接发送HTTP请求到OpenID服务器，而是重定向到OpenID服务器页面。由于这样使得OpenID服务器能够从用户浏览器中读取cookie而没有将任何认证细节泄露给外部站点，因此这个过程是安全的。

6. OpenID服务器回应认证请求

在接收到OpenID认证请求后，OpenID服务器必须决定允许还是拒绝此用户的认证。这将由用户从前是否在OpenID服务器上认证过决定。

请注意：OpenID服务器在接收认证请求信息时是具有控制权的。这意味着它不但能够异步地回应认证请求信息，并在它回应认证请求之前与用户进行一系列的交互。大多数认证服务器都提供给用户一个页面使其能够选择允许或者拒绝来自外部站点的认证请求。

一旦OpenID服务器已经回应了认证请求，那么它将创建一个如下描述的认证回应信息，低层信息细节请阅读OpenID协议文档：

此回应通过将用户重定向到外部站点的方式发送，以确保外部站点和OpenID服务器之间在认证请求/回应过程中没有直接通讯。

7. 验证间接回应

协议的最后一步是外部站点验证这个发自OpenID服务器的间接认证回应信息。

当外部站点接收到回应时，它必须在接受其内容之前进行下面的验证：
        • “openid.return_to”的参数值是否匹配当前请求的URL。这确保OpenID服务器重定向用户、发送回应信息到正确的URL。
        • 被发现的信息是否与回应信息相匹配。
        • 具有相同参数值的“openid.response_nonce”表示OpenID服务器遭到了重放攻击(reply attacks)。
        • 在回应信息中的签名是否有效、要求的签名域是否都被签名。这保证认证信息没有被篡改过。

协议扩展

OpenID协议提供了一个基本的认证机制。目前还有基于OpenID的其它可用协议：
        • Attribute Exchange：OpenID属性交换是一种用于在端点之间交换标识信息OpenID服务扩展。其提供了对标识信息的接收和存储。
        • Simple Registration：这是OpenID认证协议的扩展，它允许非常轻量级的配置交换。主要用于在终端用户使用web服务注册新帐号时传送八种常用的请求信息。

使用OpenID4Java实现OpenID协议

OpenID4Java是对OpenID1.1和2.0规范的实现，目前它通过code.google.com系统进行维护。此项目初始代码是由Sxip捐献出来的，而后Atlassian等公司参与进来，并为实现支持2.0规范（属性交换规范）的API贡献了大量的工作。

在使用OpenID4Java之前，你需要完成以下工作：
        • 下载OpenID4Java代码库，并将其安装到你的项目中。
        • 修改你的认证提示，使其询问用户的OpenID标识，而不是从前的用户名和密码。
        • 创建针对用户标识的认证请求，并将用户重定向到他们的OpenID服务器。
        • 在返回URL中接收OpenID提供者的认证回应并进行验证。

这样，你的web应用就会像在上面协议综述中的流程图所展示的“Relying Party”那样工作。

第一步是创建消费者对象，它将向认证服务器发出认证请求。这里我们将消费者对象视为一个贯穿应用的个体，以使相关的关联密钥能够保存在同一位置。因为当面临多个认证请求时，在不同的请求之间保存密钥将在两个端点（请求和回应端点）间引起下幅度的性能下降。

Sample Consumer代码片段：

/**
 * Sample Consumer (Relying Party) implementation.
 */
public class SampleConsumer
{
    public ConsumerManager manager;

    public SampleConsumer() throws ConsumerException
    {
        // instantiate a ConsumerManager object
        manager = new ConsumerManager();
    }

    ...
}

一旦用户提供了OpenID URL，你就需要获取OpenID认证服务器的端点URL，发送请求到此URL。而OpenID认证服务器的端点被确定后，你还要创建一个和服务器关联的共享密钥。

// discover the OpenID authentication server's endpoint URL
List discoveries = manager.discover(userSuppliedOpenID);

// attempt to associate with the OpenID provider
// and retrieve one service endpoint for authentication
DiscoveryInformation discovered = manager.associate(discoveries);

// store the discovery information in the user's session for later use
session.setAttribute("discovered", discovered);

以上的调用将完成：
        • 下载OpenID提供者列表（一般只有一个提供者）。返回结果将按照用户指定的优选顺序排列。
        • 通过关联获取和OpenID提供者之间的共享密钥。
        • 将关联（发现信息）保存，以备之后的使用。

我们现在需要将用户重定向到他们的OpenID提供者页面，并告诉OpenID提供者外部站点的地址（返回URL，这里就是你的站点），以使OpenID提供者知道在执行完认证后将用户发送到哪里。

// define the return path
String returnURL = "http://company.com/openidresponse.jsp";

// generate an AuthRequest message to be sent to the OpenID provider
AuthRequest authReq = manager.authenticate(discovered, returnURL);

// redirect the user to their provider for authentication
httpResp.sendRedirect(authReq.getDestinationUrl(true));

上面的代码将用户重定向到他们的OpenID提供者，在那里用户将被询问是否同意和你的站点进行认证。（请注意：无论用户同意“临时”授权给你的web应用、还是“总是”或者“不”授权，OpenID提供者都将保存此首选标识）。当用户再次访问你的web应用时，如果用户已经被OpenID提供者认证过并且在首次认证时选择了“总是”，那么此用户将可以访问你的web应用，而无需再次认证。

在认证用户之后，OpenID提供者将用户重定向到外部站点（由返回URL定义的web应用），并发送认证回应信息给你的web应用，而你的web应用将需要接收此回应。你可以显示错误信息或者将用户发送到“成功”页面，这完全取决于你的工作流。

这是处理来自OpenID提供者认证信息的最简单过程：

// extract the parameters from the authentication response
// (which comes in as a HTTP request from the OpenID provider)
ParameterList openidResp = new ParameterList(request.getParameterMap());

// retrieve the previously stored discovery information
DiscoveryInformation discovered = (DiscoveryInformation) session.getAttribute("discovered");

// extract the receiving URL from the HTTP request
StringBuffer receivingURL = request.getRequestURL();
String queryString = request.getQueryString();

if (queryString != null && queryString.length() > 0)
   receivingURL.append("?").append(request.getQueryString());

// verify the response
VerificationResult verification = manager.verify(receivingURL.toString(), openidResp, discovered);

// examine the verification result and extract the verified identifier
Identifier verified = verification.getVerifiedId();

if (verified != null)
    // success, use the verified identifier to identify the user
else
// OpenID authentication failed

查看完整的Sample Consumer代码：http://code.google.com/p/openid4java/wiki/SampleConsumer

结论

OpenID是通过标准化认证方式由互联网社区催生出来的综合效应。它完成了和SAML这些现存协议同样的事情，但它却易于安装、部署和维护。任何具备基本编程技能的人都能够在其现有或者新建的网站上部署OpenID技术。

OpenID已经获得愈加广泛的使用。我们有理由相信，在不久之后的公司之间、像Google和Yahoo这样的门户站点之间都将支持此技术，OpenID技术将随着互联网社区的发展而成为网站之间通用的主流认证方法。
关于OpenID技术的更多信息，请访问：http://openid.net/

原文（《Using OpenID》）作者简介

Justen Stepka是Atlassian的Crowd单点登录安全系统的项目管理者，同时也是OpenID4Java项目的提交者（committer）。Crowd团队目前正在开发实现OpenID2.0规范的服务站点。Justen从前是Authentisoft的CEO，该公司于2006年被Atlassian收购。

Shihab Hamid是在Atlassian工作的工程师，他主要负责用Crowd产品在OpenID集成方面的设计和开发。同时也是OpenID4Java项目的提交者。

相关资料

        • OpenID官方网站：http://openid.net/
        • OpenID工作过程：http://openid.net/about.bml
        • OpenID4Java项目主页：http://code.google.com/p/openid4java/wiki/ProjectHome_zh_CN
        • 下载OpenID4Java：http://code.sxip.com/openid4java/
        • 支持OpenID的各种代码库：http://www.openidenabled.com/
        • 目前支持OpenID的主要站点：http://iwantmyopenid.org/bounty/sponsors

代理服务概念

1. 什么是代理服务器(Proxy Server)

Web代理服务器(通常所说的代理服务器)是介于浏览器和Web服务器之间的一台服务器,当你通过代理服务器上网浏览时，浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。而且，大部分代理服务器都具有缓冲的功能，就好象一个大的Cache，它有很大的存储空间，它不断将新取得数据储存到它本机的存储器上，如果浏览器所请求的数据在它本机的存储器上已经存在而且是最新的，那么它就不重新从Web服务器取数据，而直接将存储器上的数据传送给用户的浏览器，这样就能显著提高浏览速度和效率。

　更重要的是：代理服务器是 Internet链路级网关所提供的一种重要的安全功能，它的工作主要在开放系统互联 (OSI) 模型的对话层。主要的功能有：
　　
　　1、连接Internet与Intranet 充当firewall（防火墙）：因为所有内部网的用户通过代理服务器访问外界时，只映射为一个IP地址，所以外界不能直接访问到内部网；同时可以设置 IP地址过滤，限制内部网对外部的访问权限；另外，两个没有互联的内部网，也可以通过第三方的代理服务器进行互联来交换信息。

　　2、共享因特网连接，节省IP开销：如前面所讲，所有用户对外只占用一个IP，所以不必租用过多的IP地址，降低网络的维护成本。这样，局域局内没有与外网相连的众多机器就可以通过内网的一台代理服务器连接到外网，大大减少费用。当然也有它不利的一面，如许多网络黑客通过这种方法隐藏自己的真实IP地址，而逃过监视。

　　3、提高访问速度，节约通信带宽。而且通常代理服务器都设置一个较大的硬盘缓冲区（可能高达几个GB或更大），当有外界的信息通过时，同时也将其保存到缓冲区中，当其他用户再访问相同的信息时，则直接由缓冲区中取出信息，传给用户，从而达到提高访问速度的目的。

1. 1 透明代理

让我们现在来想象一个联机状态，就是你有一整组内部网络，而这个内部网络都是透过 NAT 主机联机出去的。那么我们谈过，就是在一个内部网很大的情况下，使用 Proxy 是一个很不错的选择，因为至少他可以减轻带宽负荷！不过，遗憾的是，架设 Proxy 的时候，也要使用者在浏览器上面设置代理！那么有没有办法在『使用者不需要在浏览器上面进行任何配置，就可以实现以 Proxy 帮助使用者联接Internet？当然有啦！那就是 Transparent Proxy 啦！也有人翻译成『透明代理服务器』，其原理是：

当使用者经过 NAT 服务器来联机进入 Internet 时，假如使用的 Internet 协议为 80 (也就是 WWW) ，那么就将这个要求交给 Proxy 来工作，以达到代理服务器的功能。

呵呵！也就是说，当使用者是经过 NAT 主机联机出去时，只要让 NAT 主机发现『咦！你是要去读取 www 的资料对吧！好！那么这个动作由 Proxy 主机帮你搞定！』如此一来，使用者根本就不需要在浏览器上面配置 Proxy 的相关资料，因为这个动作是『由 NAT 主机自己决定的』，所以只要在 NAT 主机上面配置妥当即可，使用者不必配置任何资料

1.2 反向代理

理服务器是使用非常普遍的一种将局域网主机联入互联网的一种方式，使用代理上网可以节约紧缺的IP地址资源，而且可以阻断外部主机对内部主机的访问，使内部网主机免受外部网主机的攻击。但是，如果想让互联网上的主机访问内部网的主机资源（例如：Web站点），又想使内部网主机免受外部网主机攻击，一般的代理服务是不能实现的，需要使用反向代理来实现。

什么是反向代理呢？其实，反向代理也就是通常所说的WEB服务器加速，它是一种通过在繁忙的WEB服务器和Internet之间增加一个高速的WEB缓冲服务器（即：WEB反向代理服务器）来降低实际的WEB服务器的负载。典型的结构如下图所示：

Web服务器加速（反向代理）是针对Web服务器提供加速功能的。它作为代理Cache，但并不针对浏览器用户，而针对一台或多台特定Web服务器（这也是反向代理名称的由来）。实施反向代理（如上图所示），只要将Reverse Proxy Cache设备放置在一台或多台Web服务器前端即可。当互联网用户访问某个WEB服务器时，通过DNS服务器解析后的IP地址是Reverse Proxy Server的IP地址,而非原始Web服务器的IP地址,这时Reverse Proxy Server设备充当Web服务器，浏览器可以与它连接，无需再直接与Web服务器相连。因此，大量Web服务工作量被卸载到反向代理服务上。不但能够防止外部网主机直接和web服务器直接通信带来的安全隐患，而且能够很大程度上减轻web服务器的负担，提高访问速度。

2. 使用squid

squid是开源软件，性能优秀。并仍在世界各地的squid开发者的共同努力下，不断发展。

快速响应，减少网络阻塞,Squid将远程Internet对象保存为本地拷贝。当本地用户再次访问这些对象时，Squid可以直接快速地提供对这些对象的访问，而不必再次占用带宽访问远程服务器上的对象。

增强访问控制，提高安全性。可以针对特定的的网站、用户、网络、数据类型实施访问控制

squid可以工作在普通代理模式、透明代理模式各反向代理模

3. squid结构

多个squid代理服务器可以通过icp协议相互沟通，形成树形层次关系（父代理、兄弟代理、子代理），构建代理服务器群。

10>11

>10

这几天看了几位同行的年终总结，看着看着好像自己的脸变的有点发烫了，猛然间才意识到原来自己是这样茫然的过了一年又一年...

为此写下这点文字，算是自己的年度总结：

1. 以一个高速公里养护管理的项目贯穿始终

   前期的框架开发，系统基本模块和画面雏形功能的构建，由1人开发。
   后期1人接手后做变更维护。有难度的任务由前期的开发人员来调查解决。
   自己做客户沟通，需求定义，测试。

2. 电信项目中实现后台的数据加工处理部分

在北京联通114电话导航平台的建设中，实现了一个模块的后台数据仓库的建模，和数据加工的过程代码。

3. 在openbiz框架下实现了几个简单的业务功能

为一个国外房产经纪公司做了一个加工xml文件的界面
为一家钢材贸易公司做了一个简单的合同管理，和业务进行状态跟踪的系统

4. 有一个月时间在用CMS为一家公司搭建了网站

儿子后半年上学前班了，大概下午4点多就去接他，也算工作之一吧。

剩下的时间，饱食终日、闲暇闲散...

>11

1. 工作环境迁移到ubuntu下

2. 开发工具集中到ror下

3. 敏捷方法，敏捷团队，敏捷自己

4. 虽然已经很晚了，但还是觉得有必要再从coding开始下一阶段的人生...

回头看看这两年好像荒废了，在跌倒的地方爬起来。

好像是最后一次的机会了，不期待很精彩，只希望能有所突破

oyaji's Blog