博客的二级域名,用JSP程序如何实现?服务器要如何配置?
服务器针对WIN平台和LINUX平台要分别如何设置?
WEB服务器采用APACHE TOMCAT
在网上找的资料,有提到:
1、Apache模块 mod_rewrite,这个模块能实现像博客中国的二级域名功能吗,有没有相关程序例子?
2、域名泛解析,这个似乎要对服务器进行操作,具体如何解决?
如果不是单独的服务器,是购买的虚拟目录,又有什么办法来通过JSP程序来实现二级域名功能?
比如:http://www.blogcn.com/的个人博客二级域名功能是如何实现的
博客中国注册地址:http://sys2.blogcn.com/control/user...ethod=inputUser
有兴趣研究的朋友可以注册看看这个流程,注册成功后就有个二级域名,比如:test.blogcn.com
然后就可以直接用二级域名访问他的博客地址,而不是像过去的那个www.blogcn.com/test来访问,就是IE地址保持的是test.blogcn.com实现上访问的是www.blogcn.com/test
这是怎么做到的,用JSP来实现?
给个具体的例子,或者解决此问题的链接。
多谢

解决方案 »

  1.   

    个人认为,JSP程序是不可以实现的.
    因为对xxx.blogcn.com的处理并不是由www.blogcn.com来完成的.你可以看一下我ping这几个地址时,产生的结果:
    Microsoft Windows [版本 5.2.3790]
    (C) 版权所有 1985-2003 Microsoft Corp.C:\Documents and Settings\Administrator>ping xiaowang.blogcn.comPinging b.blogcn.z.cdn20.com [125.221.46.209] with 32 bytes of data:Reply from 125.221.46.209: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.209: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.209: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.209: bytes=32 time=17ms TTL=51Ping statistics for 125.221.46.209:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 17ms, Maximum = 17ms, Average = 17msC:\Documents and Settings\Administrator>ping xiaoli.blogcn.comPinging b.blogcn.z.cdn20.com [125.221.46.210] with 32 bytes of data:Reply from 125.221.46.210: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.210: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.210: bytes=32 time=17ms TTL=51
    Reply from 125.221.46.210: bytes=32 time=17ms TTL=51Ping statistics for 125.221.46.210:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 17ms, Maximum = 17ms, Average = 17msC:\Documents and Settings\Administrator>从上面可以看出,xxx.blogcn.com是由一个集群b.blogcn.z.cdn20.com完成的.
    我用google查找了cdn20.com的相关信息,并没有任何相关的资料,
    我推测是一个顶级域名管理网站,正是它来管理www.blogcn.com域名,并且xxx.blogcn.com也是由它来管理的.怎样对上面的推测进行验证呢?
    只要使用tracert命令,来查看去往www.blogcn.com的数据路由就可以了.结果如下所示:C:\Documents and Settings\Administrator>tracert www.blogcn.comTracing route to www.blogcn.z.cdn20.com [125.221.46.209]
    over a maximum of 30 hops:  1    <1 ms    <1 ms    <1 ms  219.228.125.254
      2     1 ms    <1 ms    <1 ms  10.19.68.249
      3     1 ms     1 ms     1 ms  10.3.2.73
      4     1 ms     1 ms     1 ms  10.3.2.41
      5     1 ms     1 ms     1 ms  10.3.0.10
      6     1 ms     2 ms     1 ms  202.120.201.205
      7     2 ms     2 ms     1 ms  202.120.201.198
      8     2 ms     1 ms     1 ms  202.112.53.189
      9     8 ms     7 ms     7 ms  202.112.53.137
     10     8 ms     8 ms     7 ms  202.112.36.250
     11    18 ms    18 ms    17 ms  202.112.53.109
     12    17 ms    45 ms    40 ms  202.112.53.110
     13    18 ms    17 ms    17 ms  125.221.46.253
     14    18 ms    17 ms    17 ms  125.221.46.209Trace complete.C:\Documents and Settings\Administrator>通过我一系列的测试,发现,不论是解析请求,还是页面请求服务,请求都转发到了两台主机上,125.221.46.209和125.221.46.210
    于是,我telnet到125.221.46.209的80端口上,
    HTTP/1.0 400 Bad Request
    Server: Cdn Cache Server V2.0
    Date: Tue, 22 Jul 2008 10:03:02 GMT
    Content-Type: text/html
    Content-Length: 1405
    Expires: Tue, 22 Jul 2008 10:03:02 GMT
    Via: 1.0 hzkd209:80 (Cdn Cache Server V2.0)
    Proxy-Connection: close<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
                                                                                                          <HTML><HEAD>
                                                                                                                      <META
    HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
    ...省略
    失去了跟主机的连接。C:\Documents and Settings\Administrator>至此,所有问题得到了解决...因为我发现了这个主机是一台叫做Cdn Cache Server的服务器,所有的这些服务,都是这台服务器完成的,这是一台什么东西呢?
    再问Google,答案见下一帖.
      

  2.   

    网络加速器是的全称Content Delivery Network,(缩写:CDN)即内容分发网络。它的原理是通过将网站的内容发布到最接近用户的cache(缓存)服务器内,使大部分客户就近访问cache服务器取得所需的内容,解决Internet网络拥塞状况,提高用户访问网站的响应速度,如同提供了多个分布在各地的克隆站点一般.
    CDN的技术原理 
        
    在描述CDN的实现原理,让我们先看传统的未加缓存服务的访问过程,以便了解CDN缓存访问方式与未加缓存访问方式的差别:  由上图可见,用户访问未使用CDN缓存网站的过程为:用户向浏览器提供要访问的域名;    
    浏览器调用域名解析函数库对域名进行解析,以得到此域名对应的IP地址;    
    浏览器使用所得到的IP地址,域名的服务主机发出数据访问请求;    
    浏览器根据域名主机返回的数据显示网页的内容。 
       
    通过以上四个步骤,浏览器完成从用户处接收用户要访问的域名到从域名服务主机处获取数据的整个过程。CDN网络是在用户和服务器之间增加Cache 层,如何将用户的请求引导到Cache上获得源服务器的数据,主要是通过接管DNS实现,下面让我们看看访问使用CDN缓存后的网站的过程:   通过上图,我们可以了解到,使用了CDN缓存后的网站的访问过程变为:   用户向浏览器提供要访问的域名;    
    浏览器调用域名解析库对域名进行解析,由于CDN对域名解析过程进行了调整,所以解析函数库一般得到的是该域名对应的CNAME记录,为了得到实际IP地址,浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址;在此过程中,使用的全局负载均衡DNS解析,如根据地理位置信息解析对应的IP 地址,使得用户能就近访问。    
    此次解析得到CDN缓存服务器的IP地址,浏览器在得到实际的IP地址以后,向缓存服务器发出访问请求;    
    缓存服务器根据浏览器提供的要访问的域名,通过Cache内部专用DNS解析得到此域名的实际IP地址,再由缓存服务器向此实际IP地址提交访问请求;    
    缓存服务器从实际IP地址得得到内容以后,一方面在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成数据服务过程;    
    客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。 通过以上的分析我们可以得到,为了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置,直接使用被加速网站原有的域名即可访问),又要在为指定的网站提供加速服务的同时降低对ICP的影响,只要修改整个访问过程中的域名解析部分,以实现透明的加速服务.  
      

  3.   

    总结帖:
    从上面的实验和分析,得出:Blogcn.com并没有使用程序技术解决这个问题,而是使用的硬件.并且是一台比DNS服务器更接近用户的服务器.
    它中途截获了域名解析请求,并使用自己的机制,即把xxx.blogcn.com解析为实际IP的方式,返回给用户.上面的结论倒是让我更坚定了,程序里是很难解决这个问题的观点,即使解决了,也会有很严重的性能问题.