基于web的信息交流系统有哪些

Web开发是一个指代网页或网站编写过程的广义术语。网页使用 HTML、CSS 和 JavaScript编写。这些页面可能是类似于文档的简单文本和图形。页面也可以是交互式的，或显示变化的信息。编写交互式服务器页面略微复杂一些，但却可以实现更丰富的网站。如今的大多数页面都是交互式的，并提供了购物车、动态可视化甚至复杂的社交网络等现代在线服务。

通俗的说,web开发就是我们说的做网站它分为网页部分,和逻辑部分也就是我们说的前台与后台前台负责与用户的交互,显示数据用到HTML显示数据,CSS控制样式,JS编写复杂交互后台编写处理这些逻辑的程序可以用C#,java,vbphp等语言

现在web应用程序已经和我们的生活息息相关,小到我们的博客,空间大到大型社交网站如facebook,人人等更复杂的如电子商务中的C2C,B2B等网站都给我们带来了很大的方便

web应用：常见的计数器、留言版、聊天室和论坛BBS等，都是Web应用程序，不过这些应用相对比较简单，而Web应用程序的真正核心主要是对数据库进行处理，管理信息系统（Management Information System,简称MIS）就是这种架构最典型的应用。MIS可以应用于局域网，也可以应用于广域网。目前基于Internet的MIS系统以其成本低廉、维护简便、覆盖范围广、功能易实现等诸多特性，得到越来越多的应用。

WebRTC给我们带来了浏览器中的视频、音频聊天体验。但个人认为，它最实用的特性莫过于DataChannel——在浏览器之间建立一个点对点的数据通道。在DataChannel之前，浏览器到浏览器的数据传递通常是这样一个流程：浏览器1发送数据给服务器，服务器处理，服务器再转发给浏览器2。这三个过程都会带来相应的消耗，占用服务器带宽不说，还减缓了消息从发送到接收的时间。其实最理想的方式就是浏览器1直接与浏览2进行通信，服务器不需要参与其中。WebRTC DataChannel就提供了这样一种方式。

如果对WebRTC和DataChannel不太了解的同学，可以先阅读如下文章：

- WebRTC的RTCDataChannel

- 使用WebRTC搭建前端视频聊天室——信令篇

- 使用WebRTC搭建前端视频聊天室——入门篇

当然服务器完全不参与其中，显然是不可能的，用户需要通过服务器上存储的信息，才能确定需要和谁建立连接。这里通过一个故事来讲述建立连接的过程：

不如钓鱼去

一些背景：

现在，老刘听说老姚钓鱼技术高超，想和老姚讨论钓鱼技巧。只要老刘和老姚相互之间知道对方的门牌号以及凭证，就可以串门了:

老刘和老姚相互之间知道了对方的门牌号和小区出入凭证，他们相互之间有什么需要交流的直接串门就行了，消息不再需要门卫老大爷来代为传达了

换个角度

我们把角色做一个映射：

于是乎故事就变成了这样：

这样，就建立了一个点对点的信道，流程如下所示：

故事

老刘和老姚已经可以相互串门了，经过一段时间的交流感情越来越深。老姚的亲友送了20斤葡萄给老姚，老姚决定送10斤给老刘。老姚毕竟年事已高，不可能一次带10斤。于是乎，老姚将葡萄分成了10份，每次去老刘家串门就送一份过去。

这里可以做如下类比：

这其实就是通过datachannel传输文件的方式，首先将文件分片，然后逐个发送，最后再统一的进行组合成一个新的文件

分片

通过HTML5的File API可以将type为file的input选中的文件读取出来，并转换成data url字符串。这也就为我们提供了很方便的分片方式：

组合

通过datachannel发送的分片数据，我们需要将其进行组合，由于是data url字符串，在接收到所有包之后进行拼接就可以了。拼接完成后就得到了一个文件完整的data url字符串，那么我们如何将这个字符串转换成文件呢？

方案一：直接跳转下载

既然是个dataurl，我们直接将其赋值给windowlocationhref自然可以下载，但是这样下载是没法设定下载后的文件名的，这想一想都蛋疼

方案二：通过a标签下载

这个原理和跳转下载类似，都是使用dataurl本身的特性，通过创建一个a标签，将dataurl字符串赋值给href属性，然后使用download确定下载后的文件名，就可以完成下载了。但是很快又有新问题了，稍微大一点的文件下载的时候页面崩溃了。这是因为dataurl有大小限制

方案三：blob

其实可以通过给a标签创建blob url的方式来进行下载，这个没有大小限制。但是我们手上是dataurl，所以需要先进行转换：

获得blob后，我们就可以通过URL API来下载了：

这里有几个点：

1 datachannel其实是可以直接传送blob的，但是只有ff支持，所以传data url

2 chrome下载是直接触发的，不会进行询问，firefox会先询问后下载，在询问过程中如果执行了revokeObjectURL，下载就会取消，囧

升级

如我们所知，WebRTC最有特点的地方其实是可以传输getUserMedia获得的视频、音频流，来实现视频聊天。但事实上我们的使用习惯来看，一般人不会一开始就打开视频聊天，而且视频聊天时很消耗内存的（32位机上一个连接至少20M左右好像，也有可能有出入）。所以常见的需求是，先建立一个包含datachannel的连接用于传输数据，然后在需要时升级成可以传输视频、音频。

看看我们之前传输的session description，它其实来自Session Description Protocol。可以看到wiki上的介绍：

这意味着什么呢？我们之前建立datachannel是没有加视频、音频流的，而这个流的描述是写在SDP里面的。现在我们需要传输视频、音频，就需要添加这些描述。所以就得重新获得SDP，然后构建offer和answer再传输一次。传输的流程和之前一样，没什么区别。但这一次，我们不需要传输任何的ice candidate，这里我曾经遇到了坑，经过国外大大的点拨才明白过来。

Peertc

我将datachannel和websocket组合，实现了一个构建点对点连接的库Peertc，它提供非常简洁的方式来建立连接和发送数据、文件和视频/音频流，详情见github。走过路过的记得star一下哦，有什么bug也非常希望能够提出来。

最后

WebRTC的点对点方式能够运用在很多场景：

- 如web qq这种Web IM工具，这就不说了

- 如象棋这种双人对战 游戏 ，每一步的数据服务器时不关心的，所以完全可以点对点发送

- 一对一在线面试、在线教育，这其实是即时通信的一个业务方向

基于web的好友聊天系统在国内外均得到了广泛的应用和发展。以下是关于国内外基于web的好友聊天系统的现状的一些细节： 国内： 1 微信：中国最大的即时通讯软件，可以在手机端、电脑端和网页端使用，提供了好友聊天、朋友圈分享、公众号订阅等功能。 2 QQ：中国最早的即时通讯软件，也可以在手机端、电脑端和网页端使用，提供了好友聊天、群组聊天、游戏等功能。 3 钉钉：一款专注于企业办公场景的即时通讯软件，可以在手机端、电脑端和网页端使用。 国外： 1 Facebook Messenger：属于Facebook旗下的即时通讯服务，可以在手机端和网页端使用，提供了好友聊天、群组聊天、语音、视频、表情等功能。 2 WhatsApp：世界上最大的即时通讯软件之一，可以在手机端和网页端使用，提供了好友聊天、群组聊天、语音、视频、表情等功能。 3 Telegram：一款安全、高速、简洁的即时通讯软件，可以在手机端、电脑端和网页端使用，提供了好友聊天、群组聊天、频道订阅、机器人等功能。 总的来说，基于web的好友聊天系统在国内外的应用非常广泛，不管是用于个人还是企业办公场景，都提供了许多丰富的功能。

我使用过两种解决方案解决这个问题。
首先不能用插件，那我们想使用QQ啊，MSN之类的完成客服就行不通。
方案一就是采用网页聊天的形式。客服人员和客户分别在不同的网页上及时交流。使用Ajax技术，当某一方发出消息之后，通过js脚本监视该应用端页面的输入端，将发出的消息发送给服务器，服务器将消息处理之后发送给另一方，另一方接受到消息之后局部页面刷新，将消息显示出来。
方案二，做一个Applet小程序实现TCP/IP通信，将这个程序嵌入到网页中，用户需要客服的时候运行Applet小程序就可以了。

2001年秋天互联网公司（dot-com)泡沫的破灭是互联网的一个转折点。许多人断定互联网被过分炒作，事实上网络泡沫和相继而来的股市大衰退看起来像是所有技术革命的共同特征。股市大衰退通常标志着蒸蒸日上的技术已经开始占领中央舞台。假冒者被驱逐，而真正成功的故事展示了它们的力量，同时人们开始理解了是什么将一个故事同另外一个区分开来。

“Web 20”的概念2004年始于出版社经营者O'Reilly和MediaLive International之间的一场头脑风暴论坛。身为互联网先驱和O'Reilly副总裁，Dale Dougherty指出，伴随着令人激动的新程序和新网站间惊人的规律性，互联网不仅远没有“崩溃”，甚至比以往更重要。更进一步说，那些得以活过泡沫破裂的公司之间似乎拥有某种相同点。难道是互联网泡沫破裂标志着互联网的一个转折点，因而导致了诸如“Web 20”这种运动？我们同意这种说法，“Web 20”的概念由此诞生了。Web20 则更注重用户的交互作用，用户既是网站内容的浏览者，也是网站内容的制造者。所谓网站内容的制造者是说互联网上的每一个用户不再仅仅是互联网的读者，同时也成为互联网的作者；不再仅仅是在互联网上冲浪，同时也成为波浪制造者；在模式上由单纯的“读”向“写”以及“共同建设”发展；由被动地接收互联网信息向主动创造互联网信息发展，从而更加人性化。

在那个会议之后的一年半的时间里，“Web 20”一词已经深入人心，从Google上可以搜索到47亿以上的链接。但是，至今关于Web 20的含义仍存在极大的分歧，一些人将Web 20贬低为毫无疑义的一个行销炒作口号，而其他一些人则将之理解为一种新的传统理念。

在我们当初的头脑风暴中，我们已经用一些例子进行展示，公式化地表达了我们对Web 20的理解：

这个列表还会不断继续下去。但是到底是什么，使得我们认定一个应用程序或

web20

一种方式为作为所谓“Web 10”，而把另外一个叫做“Web 20”呢？（这个问题尤为紧迫，因为Web 20的观念已经传播的如此广泛，以至于很多公司正在将这个词加到他们的行销炒作中，但却没有真正理解其含义。同时这个问题也尤为困难，因为许多嗜好口号的创业公司显然不是Web 20，而一些我们认为是Web 20的应用程序，例如Napster和BitTorrent，甚至不是真正适当的网络程序！）

然而，抛开纷繁芜杂的Web 20现象，进而将其放到科技发展与社会变革的大视野下来看，Web 20可以说是信息技术发展引发网络革命所带来的面向未来、以人为本的创新20模式在互联网领域的典型体现，是由专业人员织网到所有用户参与织网的创新民主化进程的生动注释。

Web20模式下的互联网应用具有以下显著特点：

Web20去中心化,开放,共享为显著特征

1用户分享。在Web20模式下，可以不受时间和地域的限制分享各种观点。用户可以得到自己需要的信息也可以发布自己的观点。

2信息聚合。信息在网络上不断积累，不会丢失。

3以兴趣为聚合点的社群。在Web20模式下，聚集的是对某个或者某些问题感兴趣的群体，可以说，在无形中已经产生了细分市场。

4开放的平台，活跃的用户。平台对于用户来说是开放的，而且用户因为兴趣而保持比较高的忠诚度，他们会积极的参与其中。

---