web系统是什么？

web系统有两种模式C/S、B/S。C/S是客户端/服务器端程序，也就是说这类程序一般独立运行。而B/S就是浏览器端/服务器端应用程序，这类应用程序一般借助IE等浏览器来运行。WEB应用程序一般是B/S模式。Web应用程序首先是“应用程序”，和用标准的程序语言，如C、C++等编写出来的程序没有什么本质上的不同。然而Web应用程序又有自己独特的地方，就是它是基于Web的，而不是采用传统方法运行的。换句话说，它是典型的浏览器/服务器架构的产物。

一个Web系统是由完成特定任务的各种Web组件（web components)构成的并通过Web将服务展示给外界。在实际应用中，Web应用程序是由多个Servlet、JSP页面、HTML文件以及图像文件等组成。所有这些组件相互协调为用户提供一组完整的服务。

更多相关知识可参考：http://baikebaiducom/linkurl=M13m0JAbq0AjRa8YH0W7sEgMf1nMIrgorLkMbiD1xxOqCzzVLLYUEmmVbAafrXhu

分类: 电脑/网络 >> 互联网

问题描述:

web20到底怎么架构

主要使用什么技术

现在还是个概念吗

如果要学web20,得先从哪下手

谢谢!

解析:

Web 20是一个新生的术语，它的应用可以让人了解目前万维网正在进行的一种改变——从一系列网站到一个成熟的为最终用户提供网络应用的服务平台。这种概念的支持者期望Web 20服务将在很多用途上最终取代桌面计算机应用。Web 20并不是一个技术标准，不过它包含了技术架构及应用软件。它的特点是鼓励作为资讯最终利用者透过分享，使到可供分享的资源变得更丰盛；相反的，过去的各种网上分享方式则显得支离破碎。

概览

Web（在这里，指代“Web 10”）最早的概念包括不常更新（甚至不更新）的静态HTML页面。而时代的成功则是依靠一个更加动态的Web（指代“Web 15”），其中CMS（内容管理系统）可以从不断变化的内容数据库中即时生成动态HTML页面。从这两种意义上来说，所谓的眼球效应则被认为是固有的Web感受，也因此页面点击率和外观成为了重要因素。

Web 20的支持者认为Web的使用正日渐以交互性和未来的社会性网络为导向，所提供的服务内容，通过或不通过创建一个可视的、交互的网页来充分挖掘网络效应。某种观点认为，和传统网站相比，Web 20的网站更多表现为Point of presence或者是依赖用户的门户网站。

另一方面，其实早在1999年，著名的管理学者彼得·杜拉克 (Peter F Drucker)就曾指出当时的资讯科技发展走错了方向，因为真正推动社会进步的，是"Information Technology"里的"Information"，而不是"Technology"。若然单单着重技术层面而忽略了资讯的话，就只是一具空的躯壳，不能使社会增值。而Web 20很明显是透过参与者的互动：不论是提供内容、为内容索引或评分，都能够使他们所使用的平台增值。透过参与者的互动，好的产品或资讯本着它的口碑，从一小撮使用者扩展到一大班人，一但超过了临界质量，就会“像病毒一样广泛留传”(葛拉威尔，2002)。

该词的来源

有不少人以为"Web 20"是一个技术的标准，其实这是个美丽的误会，因为Web 20只是一个用来阐述技术转变的术语。这个术语是由O'Reilly Media的Dale Dougherty 和 MediaLive 的 Craig Cline 在共同合作的脑力激荡(brain storming)会议上提出来的。Dougherty提出了Web目前正处于复兴时期，有着不断改变的规则和不断演化的商业模式。而Dougherty则是举例说明——“DoubleClick是Web 10，Google AdSense 则是Web 20。 Ofoto是Web 10；Flickr 则是Web 20”，而不是给出确切的定义，和补充一个商业前景，同时O'Reilly Media、Battelle和MediaLive 在2004年10月启动了第一个Web 20大会。第二次的年会已在2005年10月举办。

在他们的会议开场白上，O'Reilly和Battelle总结了他们认为的表现了Web 20应用特色的一些关键原则：

将Web作为平台；

驾驭群体智慧

资料将变成未来的“Intel Inside”；

软件不断发行与升级的循环将会终结（“永久的Beta版”）

轻量型程序设计模型；

通过内容和服务的联合使轻量的业务模型可行；

软件执行将跨越单一设备

丰富的使用者体验

分享和参与的架构 所驱动的网络效应；

通过带动分散的、独立的开发者把各个系统和网站组合形成大汇集的改革；

拉动长尾的能力;

快速的反应与功能新增

双向的互动

这种软件发布中的版本号的使用从某一方面也暗示了整个Web已经被看作是一种有着重大增值意义的新产品，而且正在被重新编写和发布。

同语义网的比较

对于Web 20这个词的一个较早的出现是作为语义网的同义词。这两个概念有点相似而且是互补的。结合了基于标签的Folksonomy(分众分类法)的社会性网络系统如FOAF和XFN，以及通过Blog和Wiki进行发表，已经创建了一个语义环境的天然基础。

技术

Web 20技术基础比较复杂而且还在演化中，但可以肯定的是包括服务器端软件、内容联合组织、消息协议、基于标准的浏览器和各种不同的客户端应用程序。（一般会避免使用非标准浏览器的一些增强功能和插件）这些不同但是互补的方法提供了Web20信息存储、创建和分发的能力，这些能力远远超出了先前人们对网站的期望。

如果一个网站使用了以下一些技术作为特色的话，就说他是利用了Web 20技术：

技术方面：

CSS, 语义化有效的XHTML标记，和Microformats

不突出的丰富应用技术（例如Ajax）

数据的联合，RSS/ATOM

RSS/ATOM数据的聚合

规则且有意义的URL

支持对网志发帖子

REST 或者是XML Web服务API

某些社会性网络方面

通用概念：

网站不能是封闭的——它必须可以很方便地被其他系统获取或写入数据。

用户应该在网站上拥有他们自己的数据。

完全地基于Web —— 大多数成功的Web 20网站可以几乎完全通过浏览器来使用

内容联合组织

Web 20的首要的也是最重要的发展，包括了使用标准化协议的网站内容的联合，这可以让最终用户在其他环境中使用网站的数据，包括另一个网站、浏览器插件、或者一个单独的桌面应用程序。这些联合协议包括RSS，资源描述框架（RDF），和Atom，这些都是基于XML的。特别的协议如FOAF和XFN（XHTML朋友网络）——这两者都是为了社会性网络开发的——扩展了网站的功能或者可让最终用户不集中于网站就可以进行交互。参见microformats，以查询更多的专门数据格式。

由于发展太快，很多这些协议都是事实上的标准而不是正式的标准。

Web服务

双向的消息协议是Web 20架构的关键元素之一。两个主要的类型是RESTful和SOAP方法。REST（Representational State Transfer）表示了一种Web服务 客户端传送所有的事务的状态。SOAP（Simple Object Access Protocal）和类似的轻量方法都依赖服务器来保存状态信息。两种情况下，服务是通过一个API调用的。这个API常常是根据网站的特殊需求定义的，但是标准的Web服务API（例如，给Blog发帖）的API依然被广泛使用。一般来说Web服务的通用语言是XML，但并不一定，还存在大量不同的其他语言，如JSON，YAML等。

最近，出现了一个被称之为Ajax的混合形式，用来增强基于浏览器的Web应用的用户体验。这可以用于一些特别的形式（如Google Maps、UrMap）或是一些开放的形式，可以直接利用Web服务API、数据联合，甚至是绘画。

宽泛得说，联合是一种Web服务的形式，但是Web服务形式的使用却不是很常见的。

参见 WSDL（Web服务描述语言）和Web服务规范表。

服务器软件

Web 20 的功能是在已有的Web服务器架构上建立的，但是更加强调后台软件。数据联合不仅仅是名称上和内容管理发布方法不同，而且Web服务要求更加强壮的数据库和工作流的支持，并且变得与传统的企业内部网的应用服务器功能更加相似。供应商不管是用一个通用服务器方法，可以把所有需要的功能都集中到一个服务器平台上，或者是一个Web服务器插件的方法，可以使用增强了API接口的标准发布工具和其他工具。不管选择的是哪种途径，Web 20的进化不会为这些选择做出重大改变。

社会影响

Web 20中出现的数据联合和消息传送能力，提出了潜在的一种可能性——在完全不同的在线社区之间创建一个更加紧密的社会构造。同时还出现了一些新的术语来 性地代表这些共同的社团，包括blogshpere：网志的世界，syndisphere：内容联合发布，以及 wikisphere，然而其他的观察者认为这些措辞和内在的含义太空泛了。

商业影响

可能的由Web 20带来的指数级增长的业务的原因，可归结为以人为本的消费和以计算机为本的消费的区别。

对于价值的鉴定和消费的过程中无需不同人为参与，由于Web 20的出现，也是完全可能的事情了。各个组织会不断使用诸如RSS/Atom/RDF之类的联合格式来联合他们的价值提案。除了价值的联合外，Web服务终点发布将简化联合的价值的消费过程。

事实上，至今没有人能给Web20下一个明确的定义。每个人眼中的Web20都有不同的表述。 技术研究者眼中的Web20是SNS、BLOG等社会性软件的兴起； 博客们则认为Web20是人与人之间更为便捷的互动； 在风险投资商眼中，Web20又代表了新的商业机会和行业游戏规则。

而从行销者的角度来看，Web20则至少意味着三个方面的内容： 一种创新的媒介形式、一个集中的社群环境，以及一种全新行销理念。

目前逐渐盛行的BLOG行销被认为是Web20行销的典型形式之一。

早期的网络行销不外乎是透过电子邮件发送、弹出式视窗、横幅式广告等几种手法。 最常见的例子就是入口网站将其网页上的广告空间待价而沽，等到广告商上门之后，入口网站再依点选率或是摆放时间的长短来收取费用。 这样的缺点是，广告商永远无法知道你所摆放的广告是不是真的接触到你的目标客户，还是只是在茫茫的网海中找寻一两个真正有需求的消费者。 就像是Tim O'Reilly所说的一样，如果Web 10的代表者是Netscape，那Web 20的代表就是Google。 Google一改以往广告商寻找消费者的思考模式，而改以消费者自行查询广告的思维模式来经营。 Google将首页保持干净，但在关键字搜寻的时候提供你想要查找资讯的相关广告，不但确保每一个点选进网站的浏漤者都是对该资讯有兴趣的潜在消费者，也一并解决了消费者对广告视窗扰人的困扰。 而前一阵子Google推出的Google Page也有异曲同工之妙，利用免费提供部落格服务的形式，从中搜集更多消费者的习性，其中的用意就是要为消费者量身订做一个个人化的Google。

一种是将服务器托管到机房，非常省心；

一种方法就是找电信接个专网，独立的ip，然后让网管绑定域名就可以了。像qq公司就是类似这种，他们有自已的机房

当然你自己在服务器上还得装很多软件

比如网站需要的运行环境：iis60

net运行框架framewor

数据库：mysql或者sqlserver

文件上传下载软件：leapftp

还有服务器的安全你得设置好，很多问题的，不是那么简单的事情

就是B/W/C/D/C结构

B: Browser; W: Web Server; C: CRUBA Server; D: Database; C: Client

传统的Web数据库B/W/D结构也逐渐暴露出了许多不足：

　　（1）由于浏览器只是为了进行Web浏览而设计的，当其应用于Web应用系统时，许多功能不能实现或实现起来比较困难。比如：通过浏览器进行大量的数据的录入，或进行报表答应都是非常困难和不便的。

　　（2）复杂应用构造困难。虽然可以用ActiveX，Java等技术开发较为复杂的应用，但是相对于发展已经非常成熟C/S的一系列应用工具来说，这些技术的开发复杂，并没有完全成熟的技术供使用。

　　（3）Web Server成为Database的唯一的客户端，所有对数据库的连接都通过该服务器实现，Web服务器同时要处理与客户请求及数据库服务器的连接，当访问量大时，Server负载过重。

21 Web数据库的五层体系结构

　　正是由于B/W/D结构自身具有的这些弱点，为了改善其不足，在其基础上，提出了一新的结构体系—— B/W/C/D/C结构

五层体系结构有如下优点：

　　（1）充分发挥了B/S结构与C/S结构系统的优势，扬长避短。充分考虑用户利益，保证浏览查询者操作方便的同时也使得系统的更新简单，维护简单灵活，易于操作。

　　（2）信息发布端采用B/S结构，保持了瘦客户端的优点。装入客户机的软件可以采用统一的WWW浏览器。而且由于WWW浏览器和网络综合服务器都基于工业标准，可以在所有平台上工作。客户机或服务器的操作系统也可以完全统一，客户端存在的各种问题迎刃而解。

　　（3）数据库端采用C/S结构，通过ODBC/JDBC进行连接。这一部分的功能只涉及到系统维护，数据更新等，客户端很少，不存在完全采用C/S结构带来的客户端维护工作量大等缺点。并且，在客户端上可以构造非常复杂的应用，界面友好灵活，易于操作，能解决许多B/S存在的固有的缺点。

　　（4）许多原有的基于C/S结构的系统可以非常容易地升级到五层体系结构，只需要开发用于发布的WWW界面，可以保留原有的C/S结构的某些子系统，充分地利用现有资源。使得现有系统或资源无需进行大的改造即可以连接使用，保护了用户以往的投资。

　　（5）由于应用了CORBA服务器，对数据库的访问提供了一个统一的接口，使CORBA服务器具有共享性，形成了模块性更强的结构，更易扩充，升级。

1-技术有什么区别

首先通信上目前的主流是HTTP协议和SOCKET这两种(HTML5提供了一种新的协议，WebScoket，对此了解并不多，因此不做评论，以免误导)。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

（注：在HTTP 11中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。）

Socket又称"套接字"，应用程序通常通过"套接字"向网络发出请求或者应答网络请求。

以J2SDK-13为例，Socket和ServerSocket类库位于http://javanet包中。ServerSocket用于服务器端，Socket是建立网络连接时使用的。在连接成功时，应用程序两端都会产生一个Socket实例，操作这个实例，完成所需的会话。对于一个网络连接来说，套接字是平等的，并没有差别，不因为在服务器端或在客户端而产生不同级别。不管是Socket还是ServerSocket它们的工作都是通过SocketImpl类及其子类完成的。（摘自百科）

在WEB服务器中，一般情况是只需要使用HTTP协议的。因为它不太需要去与浏览器进行主动推送，只需要响应浏览器的访问就足够了

而在游戏服务器，这样的连接方式肯定是不够用的。很多时候游戏服务器是需要主动推送消息，如系统广播。

2-思维有什么区别

WEB服务器并不需要高频即时通讯，对响应速度要求不高。而游戏服务器，大多数是需要很及时的响应速度（暂不讨论弱联网游戏）。如DOTA，这种竞技类型的游戏，1秒就能发生很多事。

因此，在思考方向上，WEB服务器应该考虑是的多平台的兼容，大量用户访问的高并发。

而游戏服务器应该考虑的是高频通讯，高并发。

3-架构的侧重点有什么区别

在架构上面，一般访问量不是很大的网站是只有一台服务器的，访问量高的才会进行分布式设计或者集群设计。

而大部分游戏服务器都是需要分布式设计的。

在现有的网络游戏服务器端架构中，多是以功能和场景来划分服务器结构的。具体的划分是根据项目的需求进行的，并没有一个十分通用的架构。

以上是比较常见的结构，客户端登录的时候，连接GateServer，然后由GateServer去连接LoginServer进行登录。登录后通过CenterServer转发到GameServer（GameServer即是服务器大区）。

而其中的DCServer，主要的功能是缓存玩家角色数据，保证角色数据能快速的读取和保存。

LogServer便是保存日志的了。

4-本质有无区别

本质上，两者并无区别，只是需求不同，侧重点不同罢了。

基于请求的框架较早出现，它用以描述一个web应用程序结构的概念和传统的静态Internet站点一样，是将其机制扩展到动态内容的延伸。对一个提供HTML和等静态内容的网站，网络另一端的浏览器发出以URI形式指定的资源的请求，Web服务器解读请求，检查该资源是否存在于本地，如果是则返回该静态内容，否则通知浏览器没有找到。Web应用升级到动态内容领域后，这个模型只需要做一点修改。那就是web服务器收到一个URL请求（相较于静态情况下的资源，动态情况下更接近于对一种服务的请求和调用）后，判断该请求的类型，如果是静态资源，则照上面所述处理；如果是动态内容，则通过某种机制（CGI、调用常驻内存的模块、递送给另一个进程如Java容器）运行该动态内容对应的程序，最后由程序给出响应，返回浏览器。在这样一个直接与web底层机制交流的模型中，服务器端程序要收集客户端籍get或post方式提交的数据，转换，校验，然后以这些数据作为输入运行业务逻辑后生成动态的内容（包括HTML、JavaScript、CSS、等）。

基于组件的框架采取了另一种思路，它把长久以来软件开发应用的组件思想引入到web开发。服务器返回的原本文档形式的网页被视为由一个个可独立工作、重复使用的组件构成。每个组件都能接受用户的输入，负责自己的显示。上面提到的服务器端程序所做的数据收集、转换、校验的工作都被下放给各个组件。现代web框架基本上都采用了模型、视图、控制器相分离的MVC架构，基于请求和基于组件两种类型大都会有一个控制器将用户的请求分派给负责业务逻辑的模型，运算的结果再以某个视图表现出来，所以两大分类框架的区别主要在视图部分，基于请求的框架仍然把视图也就是网页看作是一个文档整体，程序员要用HTML、Javascript和CSS这些底层的代码来写“文档”，而基于组件的框架则把视图看作由积木一样的构件拼成，积木的显示不用程序员操心（当然它们也是由另一些程序员开发出来的），只要设置好它绑定的数据和调整它的属性，把他们大大从编写HTML、Javascript和CSS这些界面的工作中解放出来。 基于请求的和基于组件的两种框架各有优劣。虽然一眼看上去后者有很大的吸引力，普通的web开发人员只要使用专门的公司或开源组织提供的组件就可以轻松开发出好用漂亮的界面，但是有几种因素综合起来不利于这种理想中的方案。要编写一个没有潜在问题的、跨浏览器的、显示美观并且有足够灵活性可以调整的服务器端组件是需要高水平的技能、丰富的经验和较多时间的，即使付出这些成本，也不能完全避免使用者失望的情况。

综合来看，基于请求的框架要程序员自己动手的地方比较多，但也因此可以更精细地控制HTML、CSS和Javascript这些最终决定应用程序界面的代码，特别是如果要在界面上有创新，尝试新的视觉效果和用户操作，必然选择基于请求的框架。基于组件的框架可以提高开发界面的效率，前提是选用的组件质量优秀。