每个时代都有一群爱“玩”的人，比如瓦特玩出了蒸汽机，……
近年来，以智能手机、智能硬件为代表的电子产品技术飞速……
也许我们有听过NASA、ESA、Jaxa这些高大上的宇航机构，但……
艾迈斯半导体中文原名奥地利微电子，2014年才正式更名。……
演讲人：李东咸， 张乃千时间： 10:00:00
演讲人：彭煜歆时间： 10:00:00
演讲人：杜复旦时间： 10:00:00
预算：小于￥5,000预算：小于￥5,000
基于OPenWrt开源系统的无线视频监控智能车设计
[导读]引入了一种基于开源系统的无线视频监控智能车设计方案，该方案利用双核、双系统的开源硬件来搭建智能车的基础设备，再利用开源的OpenWrt系统构建基于REST API的用户交互接口。用户可以通过该接口控制智能车的运动，以及获取传感器数据，最后利用基于Web的开源摄像头采集系统MJPEG―STREAM搭建视频监控系统。本方案可降低开发成本、提高开发效率，具有较高的应用价值。
摘要：引入了一种基于开源系统的无线视频监控智能车设计方案，该方案利用双核、双系统的开源硬件来搭建智能车的基础设备，再利用开源的OpenWrt系统构建基于REST
API的用户交互接口。用户可以通过该接口控制智能车的运动，以及获取传感器数据，最后利用基于Web的开源摄像头采集系统MJPEG&STREAM搭建视频监控系统。本方案可降低开发成本、提高开发效率，具有较高的应用价值。
关键词：OpenWMJPEG&STREAM;开源;ATmega32U4;Atheros AR9331
随着计算机科学技术的不断发展，各种智能化的设备也应运而生，特别是近期无人遥控飞机新闻的频繁曝光，从明星求婚到快递运送，都体现了无人遥控设备将是未来产业发展和创新应用的一个新起点。然而目前无人机在多数情况下只用于航拍或空中测绘，而对于室内应用，如对无尘、防盗，以及环境参数要求较高的企业仓储管理来说，无人机在续航和室内定向巡航方面就显现出了劣势;而对于如地震、泥石流等自然灾害中常见的狭窄处补给物资的运输和地下生命的探测，无人机的功能则大打折扣。
基于以上这些原因，本文提出了一种基于开源硬件的无线遥控视频监控智能车的设计，把开源硬件和Linux系统相结合，把视频监控车变为一个带WiFi功能的智能设备，用户可以通过合理的系统配置，使智能车加入已有的WiFi网络，从而使用户可以通过无线方式实现对智能车运动的控制和实时视频监控画面的传输，解决了因某些原因导致一些场所无法进入时，对内部环境的监控和物资运输的问题。同时，采用开源硬件也避免了硬件设备高额的设计费用和调试费用，为今后智能设备的开发及应用提供一种新的解决思路。
1 系统总体设计
本设计采用双核、双系统的方式进行架构设计，从而明确各子系统的责任，减轻硬件系统的负担，提高各子系统的内聚性，并降低各子系统间的耦合性。其中，智能车控制系统采用基于AVR内核的ATmega32U4芯片，该芯片的时钟频率为16
MHz，具有20个数字接口、12个模拟接口，以及7个PWM接口，同时内建的USB通信功能可以省去外围电路中UART转USB的设计。而无线视频监控系统则采用目前公认的相对稳定的WiFi解决方案，即Atheros
AR9331芯片方案，该芯片采用MIPS架构，CPU主频达到400 MHz，并且只需要3.3
V就可以实现超低功耗的802.11n协议。因此对于本系统来说只需要一个5
V的USB接口就可以为整个系统实现供电以及程序的烧录等功能，使得系统的开发极为方便。
此外在软件运行过程中，用户可以通过智能系统提供的REST
API轻松地实现与智能车系统之间的通信，并控制智能车的各种运动、避障，甚至在智能车自动控制和手动控制之间进行切换;同时，在视频监控系统中内建了基于嵌入式Linux的Open
Wrt系统，并基于该系统搭建了实时视频传输系统&&MJPEG-STREAM，用户只需要使用HTTP接口就可以方便地实现实时图像数据的传输。
硬件方面采用了开源的设计，通过全世界硬件工程师的不断改进和完善，保障了硬件系统的稳定，同时开源设计也节约了大量的前期硬件开发成本，提高了硬件系统的开发效率，降低了开发成本。而在软件方面，其主要特点体现在用户接口上，不论智能车控制系统还是视频监控系统，均采用HTTP通信方式，可以实现对各类终端设备的支持，如移动终端、PC端，甚至Web端。系统结构如图1所示。
2 MJPEG&STREAM视频流的实现
MJPEG&STREAM是一个基于&运动图像压缩技术&的摄像头图像采集系统，并且该系统通过Web方式进行实时图片传输，用户只需要利用浏览器就可以实现视频监控等工作，同时由于该系统采用开源方式进行开发，因此对该系统的任何修改和使用都不存在版权的问题，降低了视频开发的成本，提高了开发的效率。
本项目基于OpenWrt系统对MJPEG&STREAM的构建，而OpenWrt也是一个开源的嵌入式Linux系统，其包含3000多个软件包，用户只需要通过简单的指令就可以实现软件的下载、编译、安装和使用，具体构建步骤如下：
①更新OpenWrt的软件源。
OpenWrt：～# opkg update
②下载并安装UVC摄像头驱动，安装结束后插入摄像头，如果在OpenWrt的/dev目录下看到video0文件，则表示安装成功。
OpenWrt：～#opkg install kmod-video-uvc
③下载并安装MJPEG&STREAM开源库。
OpenWrt：～# opkg install mjpeg&streamer
④连接摄像头，启动MJPEG&STREAM，并设置其输出的分辨率和地址。
OpenWrt：～# mjpg_streamer-i&input_uvc.so/dev/video0&r
640x480&-o&output_http.so-p 8080-w/www/webcam&
⑤最后在浏览器中输入以下地址，就可以进行视频监控。
http：//local_ip：8080? action=snapshot
http：//local_ip：8080/?action=stream
3 REST接口的设计
REST(Representational State Trans fer)即表述性状态传递，是Roy
Fielding博士在2000年提出的一种软件架构风格，是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。其定义了一组体系架构原则，开发人员可以根据这些原则设计以系统资源为中心的Web服务，包括使用不同语言编写的客户端如何通过HTTP处理和传输资源状态。目前
REST已经成为最主要的Web服务设计模式。
在本项目中REST接口主要实现3方面的应用，分别为监控摄像头的多角度转动、智能车的运动控制，以及各类传感器实时数据的获取，具体如下。
①监控摄像头的多角度转动：包含控制水平舵机和垂直舵机的角度，其中垂直方面以摄像头面向地面为0&，向上为0～180&，而水平向左为0&，向右为0～180&，但当用户没有设定角度时，则传递默认值10给后端进行处理，具体如表1所列。
②智能车的运动控制：包含控制车辆的前进、后退、转弯，以及停止等操作，同时需要用户传递车辆前进、后退、转弯的速度值给系统，否则系统将使用默认值向后端系统进行传递，如表2所列。
③各类传感器实时数据的获取：要获取传感器参数，首先要获取各类传感器的类型，因此本系统要提供一个接口来返回本系统包含的所有传感器类型，然后再通过该类型获取相应传感器当前实时的数据，如表3所列。
4 CGI程序的设计
在本项目中除了通过REST API接收到用户的各类请求之外，更为重要的是在分析和辨识这些请求后，能够利用串口通信把这些指令发送给ATmega
32U4进行处理，而要把REST接口和本地应用相结合的桥梁就是CGI。
CGI(Common Gateway
Interface)是万维网技术中最重要的技术之一，是本地应用程序与Web服务器之间的接口标准和信息传递的规范。通过CGI可以使Web服务器执行本地应用程序，并将它们的输出发送给Web浏览器，使得Web页面由单一的静态展示变为完整的交互媒体。
首先本项目采用双核、双系统的方式进行架构，因此在Atheros AR9331和ATmega32U4之间采用串口作为数据通信的方式，另外由于在Atheros
AR9331上部署了基于Linux系统的OpenWrt，而Linux系统对于串口的操作非常方便，因此在接收到用户的REST请求之后，只需要按照
CGI程序的编写规范获取用户的请求数据，并从中解析出请求类型和请求参数即可，最后通过串口把这些请求和参数发送给ATmega32U4进行后期处理，具体流程如图2所示。
5 智能车控制系统的设计
智能车控制系统主要包含3方面内容，即智能车运动控制、摄像头云台控制，以及各类传感器的数据获取。通过接收前端用户的指令，并经过CGI程序的分析和传递，用户就可以利用任意平台中的HTTP访问来控制智能车和云台的运动，以及获取传感器的数据。
5.1 智能车运动系统的设计
本系统中智能车运动系统的电机驱动采用ST公司的典型双H桥直流电机驱动芯片L298N，该芯片具有较强的驱动能力，最多可提供2 A的峰值电流和46
V的峰值电压，此外由于L298N只提供2路驱动，但本项目需要使用对4路步进电机的驱动，因此采用对原来的2路输出进行扩展，把其变为4路两相输出，使得把左、右两边独立的4路输出合并为左、右两边2路的输出，具体如表4所列。
在表4中EA和EB分别表示左、右电机的PWM速度，当PWM越高时，智能车的运动速度越快;I1、I2和I3、I4分别表示左、右两个电机的转向，0、1时为顺时针，1、0时为逆时针。
5.2 摄像头云台系统的设计
本系统中摄像头云台控制系统主要采用RobotBase生产的RB-421一维度舵机进行控制，该舵机可以精准地进行水平或垂直方向转动角度。
舵机控制系统主要由舵机控制线传送可变PWM脉冲来进行控制。通常舵机的基准信号周期为20 ms，宽度为1.5
ms，当传输该PWM信号为基准信号时，舵机处于最大角度和最小角度的中间位置，即90&位置。
当PWM信号的周期为0.5 ms时，舵机所处的位置为0&，而当PWM信号周期为2.5
ms时，舵机所处的位置为180&，如果此时传输的PWM信号保持不变，那么舵机的位置就不发生变化，直到所受的外力大于其自身的最大扭力，舵机才会发生角度的变化。具体PWM与角度的关系如图3所示。
5.3 智能车传感器系统的设计
本系统中采用了多种传感器，例如通过灰度传感器实现智能车的自动巡视功能，通过超声波传感器和舵机的结合实现小车180&的避障，通过红外传感器实现尾部障碍物的躲避，以及通过温湿度、烟雾等环境传感器来获取实时环境参数。
当用户向智能车发送传感器数据请求时，系统通过CGI把请求发送到ATmega32U4芯片，该芯片与各类请求类型进行匹配从而运行相应的传感器处理函数，并通过串口发送至CGI程序，最后CGI程序通过Web的方式把数据呈现在用户面前，其流程如图4所示。
本文讨论了基于开源硬件的无线视频监控智能车的主要技术，通过双核、双系统的架构提高了系统整体的稳定性，并减轻了各模块的工作负担;其次在本系统中用户指令和视频监控均采用HTTP方式进行数据交互，使得本系统能够通过任何终端对智能车进行控制，扩大了系统的应用范围和应用场合，摆脱了以往只有专用设备才能进行控制的局面。
最后，本系统中不论软件还是硬件都采用开源设计，大大降低了系统开发成本，提高了系统开发的效率。本项目通过整合多方面的资源，为今后智能设备以及无人驾驶技术的开发提供了一种可行的方法，具有一定的应用价值。
瑞典网站监测服务公司Pingdom日前发布了最近网页软件使用报告。调私峁允荆谌蚺琶1万位的网站中，开源软件的使用率高达75%。Pingdom此次调说亩韵笾饕Alexa全球排名最高的1万个网站。Pingdom的调查结果显......关键字：
在比尔&盖茨退休前的一周召开了一场会议，会议的主题是关于开源软件。那是2008年夏天，多年以来开源社区将微软公司视作头号公敌。七年以前，微软CEO史蒂夫&鲍尔默（Steve Ballmer）曾将L......关键字：
等开源社区曾经是微软的心腹大患，如今后者却改弦更张，希望加强合作。图为Linux发行版Ubuntu。　　北京时间4月13日早间消息，微软(微博)正在创建新的全资子公司Microsoft Open Technologies，专注于与开源社区的......关键字：
&如果有一件事是我们在2015年必须学会的，那就是我们不应该低估开源的力量。&&软件在世界范围内免费共享是旧观念了。&一个名叫Richard Stallman的人在80年代初九开始宣扬这个思想......关键字：
大家一定还记得Sony的智能型手表：Smartwatch，4月中旬的时候刚刚上架发售。现在官方又在这款智能手表中继续加码，新的SDK更新加入了一些开源代码支持，包括音乐播放器和游戏扩展包。也就是说，除了支持Android通用的......关键字：
有时候我们常常为忘记了重要的密码而感到头大，而现在这项新技术的到来让我们再也不用担心。这是一项新的安全技术：Neurosecurity(神经安全)，它结合了密码学和神经科学，可以在人的大脑中储存一个密码。而且这个密码......关键字：
我 要 评 论
热门关键词&毕设进入了纠结阶段，所以需要一些Breakthrough。
现在卡在了视频的采集上，我原先的想法是，将摄像头采集到的数据压缩成mp4格式，然后将mp4的视频流发布到网络中，然后我找来mp4的格式解析文档读，结果一塌糊涂，格式还是比较复杂的，并且从摄像头采集到的数据的压缩的过程也比较麻烦，现在没有时间处理了。于是，我就想起了我的老朋友：mjpg-stream。
mjpg-stream是一个使用网络摄像头监控软件，最令我注意的是，mjpg-stream是开源的，并且代码十分短小，并且很容易编译成功，于是我从大硬盘中翻出了这个两年前把玩过得老家伙。说来也神奇，mjpg-stream在浏览器中的效果就是一张图片而不是视频流，我用wireshark抓包后分析，发现里面的response数据中Content-type的值是multipart，于是我觉得这个应该就是问题的关键。经过Google查找后，发现这个在HTTP中叫做长连接，长连接以前听说过没有具体了解过。于是继续学习。习得此文：
/zhjxiao/archive//1820563.html
说道HTTP长连接技术就不能不提服务器推送功能，最著名的就是twitter主页的推送功能，以前一直以为是Ajax搞得，后来才知道是长连接，当然也有别的方式，比如WebSocket等。
简单说说resopnse数据中Content-type的这个值的作用，具体的可以到上面的链接中查看。
长连接HTTP和普通的HTTP不同在于&服务器并不推送整个报文，而是每次发送部分数据&，HTTP可以保持连接，于是可以保证信息的即时传达。
在mjpg-stream中使用了长连接技术，首先浏览器请求
GET /?action=stream HTTP/1.0
之后mjpg-stream返回数据
HTTP/1.0 200 OK
Connection: close
Server: MJPG-Streamer/0.2
Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0
Pragma: no-cache
Expires: Mon, 3 Jan :56 GMT
Content-Type: multipart/x-mixed-boundary=boundarydonotcross
--boundarydonotcross
这里面的Content-Type就是关键地方了，multipart表示需要长连接，x-mixed-replace表示使用后来的数据替换之前的数据，boundary表示每个数据块的边界，正如其名。而boundarydonotcross就是边界符了，一个数据块以boundarydonotcross字符串为结尾。
这个response是只发送一次的。
继续看wireshark的结果：
Content-Type: image/jpeg
Content-Length: 24038
X-Timestamp:
服务器返回新的数据，这里的Content-Type表示这个数据块是jpeg图片，Content-Length，图片的大小，X-Timestamp貌似是一个mjpg-stream内建的标签，我也不清楚是什么，作用不大，我猜想应该是配合别的客户端使用的。之后就是图片的二进制数据了。
服务器一直不断的发送这个数据，然后浏览器就可已不断的接收数据并显示。
我编写了一个Python脚本，用来验证我的结论。代码如下
import socket
def getResponse(requestString):
method_end = requestString.find(&\r\n&)+2
requestStrs = requestString[method_end::].split(&\r\n&)
request = {}
for i in range(0, len(requestStrs)):
requestSplit = requestStrs[i].split(&: &)
if len(requestSplit) & 1:
request[requestSplit[0]] = requestSplit[1]
return request
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('127.0.0.1', 8888))
sock.send(&GET /?action=stream HTTP/1.0\r\n\r\n&)
headrecv = sock.recv(1024)
head_request = getResponse(headrecv)&
print head_request
if head_request.has_key(&Content-Type&) and head_request[&Content-Type&].find(&multipart&) & 0:
print &badHead&
while True:
imageHead = sock.recv(30*1024)
# print imageHead
image_response = getResponse(imageHead)
if image_response.has_key(&Content-Length&):
imageLen = int(image_response[&Content-Length&])
print imageLen
image = &&
if len(imageHead) & 100:
# we had recv the image
image = imageHead[78::]
print image
print &have recv&
image = sock.recv(30*1024)
print image
print &not recv&
bound = image.find(&boundarydonotcross&)
image = image[:bound:]
print image[-100::]
imageFile = open(&%03dcam.jpg&%index, &wb&)
imageFile.write(image)
imageFile.close()
index += 1
在操作过程中我发现，有时候sock.recv得到的response头数据带着图片数据，有时没有。这就是代码中的have recv和not recv的含义。我不太清楚原因，但程序可以使用，并在同一目录下产生很多图片，就是每一帧了。
转引用的一篇文章
服务器推送(Server Push)
推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。服务器发送一批数据，浏览器显示这些数据，同时保证与服务器的连接。当服务器需要再次发送一批数据时，浏览器显示数据并保持连接。以后，服务器仍然可以发送批量数据，浏览器继续显示数据，依次类推。
客户端拉曳(Client Pull)
在客户端拖曳技术中，服务器发送一批数据，在HTTP响应或文档头标记中插入指令，让浏览器&在5秒内再次装入这些数据&或&10秒内前往某URL装入数据&。当指定的时间达到时，客户端就按照服务器的指示去做，或者刷新当前数据，或者调入新的数据。
其实push 和 pull 这两种技术手段非常不同，但目的几乎一致，都是为了给最终用户方便的提供最新信息。
在服务器推送技术中，HTTP 连接一直保持着，直到服务器知道自己已结束发送数据并发送一个结束信号，或者客户端中断连接。而在客户端拖曳技术中，并不保持HTTP连接，相反，客户端被告知合时建立新连接，以及建立连接是获取什么数据。
在服务器推送中，奇妙之处在于&multipart/mixed&格式的MIME，它能够使一个报文（或HTTP响应）包含许多数据项、在客户端拖曳中，奇妙之处在于HTTP响应头标（或等效的HTML元素），它能告知客户端在指定的延时时间后执行何种动作。
服务器推送通常效率要比客户端拖曳效率高，因为它不必为后续数据建立新的连接。由于始终保持连接，即使没有数据传输时也是这样，因此服务器必须愿意分配这些TCP/IP端口，对于TCP/IP端口数有限的服务器这将是一个严重的问题。
客户端拖曳效率低，因为这必须每次为传送数据建立新的连接。但是它不必始终保持连接。
在实际情况中，建立HTTP连接通常需要花费相当多的时间，多达一秒甚至更多。因此从性能上考虑，服务器推送对于最终用户更有吸引力，特别是对于需要经常更新信息的情况下。
服务器推送相对客户端拖曳的另一点优势是，服务器推送相对比较容易控制。例如，服务器每一次推送时都保持一个连接，但它又随时可以关闭其中的任何连接，而不需要在服务器上设置特殊的算法。而客户端拖曳在同样的情况下要麻烦许多，它每次要与服务器建立连接，服务器为了处理将客户端拖曳请求与特定的最终用户匹配等情况，需要使用相当麻烦的算法。
如果实现服务器推送的CGI程序是使用Shell脚本语言编写的，有时会存在一些问题。例如，客户端最终用户中断连接，Shell程序通常不能注意到，这将使资源毫无用处的浪费掉，解决这一问题的办法是用Perl或者C来编写这类CGI程序，以使用户中断连接时能够结束运行。
如上所述，在服务器推送中，多个响应中连接始终保持，使服务器可在任何时间发送更多的数据。一个明显的好处是服务器完全能够控制更新数据的时间和频率。另外，这种方法效率高，因为始终保持连接。缺点是保持连接状态会浪费服务器端的资源。服务器推送还比较容易中断。
接下来就大概说说服务器推送技术
服务器在响应请求时，HTTP使用MIME报文格式来封装数据。通常一个HTTP响应只能包含一个数据块。但MIME有一种机制可用一个报文（或HTTP响应）表示将多个数据块，这种机制就是成为&multipart/mixed&的标准MIME类型。multipart/mixed报文大体格式如下：
Content-type:multipart/boundary=ThisRandomString
--ThisRandomString
Content-type:text/plain
第一个对象的数据。
--ThisRandomString
Content-type:text/plain
第二个对象的数据。
--ThisRandomString--
上述报文包括两上数据块，二者的类型都是&text/plain&。最后一个&ThisRandomString&后的两条短线（--）表示报文结束，后面没有数据。
对于服务器推送，使用一个&multipart/mixed&类型的变种--multipart/x-mixed-replace。这里，&x-&表示属于实验类型。&replace&表示每一个新数据块都会代替前一个数据块。也就是说，新数据不是附加到旧数据之后，而是替代它。
下面是实际使用的&multipart/x-mixed-replace&类型：
Content-type:multipart/x-mixed-boundary=ThisRandomString
--ThisRandomString
Content-type:text/plain
第一个对象的数据
--ThisRandomString
Content-type:text/plain
第二个（最后一个）对象的数据。
--ThisRandomString--
使用这一技术的关键是，服务器并不是推送整个&multipart/x-mixed-replace&报文，而是每次发送后数据块。
HTTP连接始终保持，因而服务器可以按自己需要的速度和频率推送新数据，两个数据块之间浏览器仅需在当前窗口等候，用户甚至可以到其他窗口做别的事情，当服务器需要发送新数据时，它只是源（ABC输入法没那个字*&^$#）传输管道发送数据块，客户端相应的窗口进行自我更新。
在服务器推送技术中，&multipart/x-mixed-replace&类型的报文由唯一的边界线组成，这些边界线分割每个数据块。每个数据块都有自己的头标，因而能够指定对象相关的内容类型和其他信息。由于&multipart/x-mixed-replace&的特性是每一新数据块取代前一数据对象，因而浏览器中总是显示最新的数据对象。
&multipart/x-mixed-replace&报文没有结尾。也就是说，服务器可以永远保持连接，并发送所需的数据。如果用户不再在浏览器窗口中显示数据流，或者浏览器到服务器间的连接中间（例如用户按&STOP&按钮），服务器的推送才会中断。这是人们使用服务器推送的典型方式。
当浏览器发现&Content-type&头标或到达头标结束处时，浏览器窗口中的前一个文档被清除，并开始显示下一个文档。发现下一个报文边界时，就认为当前数据块（文档）已经结束。
总之，服务器推送的数据由一组头标（通常包括&Content-type&）、数据本身和分割符（报文边界）三部分组成。浏览器看到分割符时，它保持状态不变，直到下一个数据块到达。
将以上概念进行用编程方法实现，就可以得到实际的服务器推送程序。例如，下面的Unix shell程序将使浏览器每5秒显示一次服务器上的进程列表：
echo &HTTP/1.1 200&
echo &Content-type: multipart/x-mixed-boundary=--ThisRandomString--&
echo &--ThisRandomString--&
while true
echo &Content-type: text/html&
echo &h2Processes on this machine updated every 5 seconds/h2&
echo &time:&
echo &plaintext&
echo &--ThisRandomString--&
注意到，边界设置在sleep语句之前发送，这能够确保浏览器清除其缓冲区，并显示所接收到的最新数据。
NCSA HTTPD用户在内容类型中不能使用空格，包括边界参数。NCSA HTTPD只能将不带空格字符的字符串作为内容类型。如果在内容类型行中存在空格（冒号后面的空格除外），空格后的任何文本都会被删除。
下面的示例是正确的：
Content-type: multipart/x-mixed-boundary=ThisRandomString
而下例则不能正常工作，因为它在中间有空格：
Content-type: multipart/x-mixed- boundary=ThisRandomString
服务器推送的另一个优点是它可以针对单个内联图象进行。包括图象的文档可以由服务器定时或定周期进行更新。而实现这一点非常简单：只需使IMG元素的SRC属性指向推送一系列图象的URL即可。
如果服务器推送用于单个内联图象，文档中的图象就会一次次被新推送来的图象所代替，而文档本身不需变化（假设文档没有进行服务器推送）。这样，WEB页面中有限的动画就可以为静态画面所代替。
客户端拖曳
客户端拖曳的一个简单用法是使文档按固定周期自动重载。例如，考虑下面的HTML文档：
&META HTTP-EQUIV=&Refresh& CONTENT=1&
&TITLE&Document ONE&/TITLE&
&H1&This is Document ONE!&/H1&
Here's some text.&P&
如果将它载入支持动态文档的浏览器（Netscape 1.1以上，Internet Explorer和Mosaic也支持客户端拖曳），它将每隔一秒将自己重载一次。
由于META元素实际是在HTML文档中模拟HTTP响应头标，所以它能够告知浏览器将自身信息当作HTTP响应使用。上例中的META标记相当于：
这样，实际上就是HTTP头标告知浏览器每一秒更新一次文档。如果需要延时是12秒，那么就是这样的指令：
&META HTTP-RQUIV=&Refresh& CONTENT=12&
那么它等效于：
Refresh:12
关于客户端的拖曳我也懒的继续写下去，关于怎么使客户端自动申请其他URL的数据话，请使用如下：
&META HTTP-EQUIV=&Refresh& CONTENT=&12;URL=http://icools.yeah.net/&&
注意的是，此处的URL不能使用相对路径，必须全部指定。
其中时间间隔可以设置为0，这样浏览器在当前文档显示完毕后，以最快的速度载入新的数据！
旗下网站：
与非门科技(北京)有限公司 All Rights Reserved.
京ICP证:070212号
北京市公安局备案编号： 京ICP备：号}