HTTP长连接服务器端推技术收藏

 HTTP长连接服务器端推技术 收藏

新一篇: 使用 .NET 实现 Ajax 长连接 | 旧一篇: 使用 jQuery 简化 Ajax 开发



 

服务器推送(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/mixed;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-replace;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秒显示一次服务器上的进程列表:
#!/bin/sh
echo "HTTP/1.1 200"
echo "Content-type: multipart/x-mixed-replace;boundary=--ThisRandomString--"
echo ""
echo "--ThisRandomString--"
while true
do
echo "Content-type: text/html"
echo ""
echo "h2Processes on this machine updated every 5 seconds/h2"
echo "time:"
date
echo "p"
echo "plaintext"
ps -el
echo "--ThisRandomString--"
sleep 5
done
注意到,边界设置在sleep语句之前发送,这能够确保浏览器清除其缓冲区,并显示所接收到的最新数据。
NCSA HTTPD用户在内容类型中不能使用空格,包括边界参数。NCSA HTTPD只能将不带空格字符的字符串作为内容类型。如果在内容类型行中存在空格(冒号后面的空格除外),空格后的任何文本都会被删除。
下面的示例是正确的:
Content-type: multipart/x-mixed-replace;boundary=ThisRandomString
而下例则不能正常工作,因为它在中间有空格:
Content-type: multipart/x-mixed-replace; 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标记相当于:
Refresh:1
这样,实际上就是HTTP头标告知浏览器每一秒更新一次文档。如果需要延时是12秒,那么就是这样的指令:
<META HTTP-RQUIV="Refresh" CONTENT=12>
那么它等效于:
Refresh:12

关于客户端的拖曳我也懒的继续写下去,关于怎么使客户端自动申请其他URL的数据话,请使用如下:
<META HTTP-EQUIV="Refresh" CONTENT="12;URL=http://icools.yeah.net/">
注意的是,此处的URL不能使用相对路径,必须全部指定。

其中时间间隔可以设置为0,这样浏览器在当前文档显示完毕后,以最快的速度载入新的数据!

<think>我们正在讨论如何实现电脑和手机之间的数据同步或内容荐。根据用户的问题,我们需要设计一个技术方案来实现跨设备(电脑和手机)的个性化送,包括数据同步和内容荐。参考引用[1]中提到:多模态融合、多源数据整合、动态荐等概念,这些都可以应用到我们的方案中。同时,引用[2]中提到了数据库设计、前后台数据同步、小程序开发等技术点。引用[4]则提到了实时数据采集、用户画像、动态调整等。因此,我们可以设计一个包含以下组件的系统:1.用户数据采集:在电脑端和手机端采集用户行为数据(如浏览记录、点击行为、使用时长等)。2.多源数据整合:将来自不同设备(电脑、手机)和不同来源(如社交媒体、地理位置、搜索历史等)的数据进行整合。3.用户画像构建:基于整合后的数据,构建动态更新的用户画像(包括兴趣、习惯、偏好等)。4.跨设备标识:使用统一的用户标识(如账户系统)来关联同一用户在不同设备上的行为。5.内容荐引擎:根据用户画像,利用荐算法(如协同过滤、基于内容的荐等)生成个性化内容。6.实时数据同步:通过消息队列或实时数据库同步不同设备间的状态和数据。7.送服务:将荐内容送到用户当前活跃的设备上,并确保设备间的同步(例如在手机上开始阅读一篇文章,可以在电脑上继续)。具体技术方案如下:###1.数据采集与同步-**设备端数据采集**:在电脑端(如桌面应用、浏览器插件)和手机端(如APP、小程序)植入数据采集SDK,收集用户行为数据。-**数据传输**:使用HTTPS协议将数据安全传输到服务器。考虑使用压缩和批量上传以减少流量消耗。-**实时同步机制**:使用WebSocket或MQTT协议实现设备间的实时通信。例如,当用户在手机上收藏了一篇文章,电脑端可以实时收到通知并更新本地数据。###2.用户画像与多源数据整合-**数据存储**:使用分布式数据库(如MongoDB)存储用户行为数据,使用图数据库(如Neo4j)存储用户关系网络。-**用户画像构建**:利用大数据处理框架(如Spark)进行数据分析,提取用户特征(兴趣标签、行为模式等)。参考引用[4]中的“多维度、动态更新的学生画像”,我们可以构建动态更新的用户画像。-**多设备数据关联**:通过用户登录的统一账户系统,将不同设备的数据关联到同一个用户ID下。###3.荐引擎-**算法选择**:结合协同过滤(基于用户相似性和物品相似性)和基于内容的荐(分析内容特征)。此外,可以引入深度学习模型(如神经网络)进行更精准的荐。-**实时荐**:使用流处理框架(如Flink)处理实时数据,动态调整荐内容。例如,当用户正在用手机看科技新闻,那么电脑端的荐可以实时调整,增加科技类内容。###4.送与跨设备同步-**送服务**:使用送通知服务(如FirebaseCloudMessagingforAndroid,ApplePushNotificationServiceforiOS)向设备发送送。对于电脑端,可以使用Web送(如ServiceWorker)或桌面应用通知。-**状态同步**:设计一个状态同步服务,记录用户在各设备上的操作状态(如阅读进度、收藏状态等)。当用户切换设备时,自动同步状态。###5.安全与隐私-数据传输和存储采用加密(如TLS,AES加密)。-遵守隐私法规(如GDPR),提供用户控制选项(如允许用户关闭数据采集)。###系统架构图我们可以用文字描述系统架构:```用户设备(手机、电脑)->数据采集SDK->数据传输(HTTPS)->数据存储(分布式数据库)->用户画像服务(实时更新)->荐引擎(离线训练+实时预测)->送服务->用户设备```此外,还需要一个账户服务来管理用户登录和跨设备关联。###示例代码(数据同步)以下是一个简化的数据同步服务示例(使用WebSocket实现实时同步):```javascript//WebSocket服务器(Node.js示例)constWebSocket=require('ws');constwss=newWebSocket.Server({port:8080});//存储每个用户的设备连接(key:userId,value:设备连接的数组)constuserConnections=newMap();wss.on('connection',(ws,req)=>{//假设连接建立时传递了userId(实际中应通过认证)constuserId=req.url.split('?')[1].split('=')[1];if(!userConnections.has(userId)){userConnections.set(userId,[]);}constconnections=userConnections.get(userId);connections.push(ws);//当收到一个设备发来的数据更新时,广播给该用户的其他设备ws.on('message',(message)=>{connections.forEach(connection=>{if(connection!==ws&&connection.readyState===WebSocket.OPEN){connection.send(message);}});});ws.on('close',()=>{//移除关闭的连接constconnections=userConnections.get(userId);constindex=connections.indexOf(ws);if(index!==-1){connections.splice(index,1);}});});```在客户端(浏览器或移动端),我们可以建立WebSocket连接并监听消息,当收到消息时更新本地数据。###引用参考我们参考了引用[1]中多模态融合和多源数据整合的思想,以及引用[4]中动态更新用户画像和实时调整荐内容的技术。同时,引用[2]中关于前后台数据同步和数据库设计的经验也为我们提供了借鉴。§§相关问题§§1.如何确保跨设备数据同步的实时性和一致性?2.在构建用户画像时,如何处理不同设备上的异构数据?3.荐系统如何平衡准确性和实时性?4.如何保护用户隐私并让用户信任这种跨设备数据同步?</think>### 个性化跨设备数据同步与内容技术方案 实现电脑和手机间的个性化数据同步与内容荐,需要结合多源数据整合、用户画像建模和实时同步技术。以下是核心方案: #### 一、技术架构 ```mermaid graph LR A[终端设备] --> B[数据采集层] B --> C[统一用户画像] C --> D[智能荐引擎] D --> E[跨设备同步服务] E --> A ``` #### 二、关键技术实现 1. **统一用户标识系统** - 通过$OAuth2.0$单点登录建立跨设备身份关联 - 设备指纹技术生成唯一设备ID:$deviceID = hash(IMEI + MAC + 硬件特征)$ - 实现同一用户多设备绑定:$$ \text{用户}U_i \leftrightarrow \{ device_{pc}, device_{phone} \} $$ 2. **多源数据采集与整合** - 采集维度: - 行为数据:浏览时长$t_b$、点击率$CTR$、交互频率$f_i$ - 内容特征:文本关键词$K_w$、图像特征$F_{img}$、元数据$M_d$ - 环境数据:地理位置$G_{pos}$、设备类型$D_t$、网络状态$N_s$ - 参考引用[1]的多模态融合技术,建立统一数据湖 3. **动态用户画像构建** - 特征工程: $$ \text{兴趣向量} \vec{I} = [w_1 \cdot tag_1, w_2 \cdot tag_2, \cdots, w_n \cdot tag_n] $$ - 权重$w_i$随行为动态更新:$w_i^{t+1} = \alpha \cdot w_i^t + (1-\alpha) \cdot \Delta w_i$ - 引用[4]的实时追踪技术,实现画像分钟级更新 4. **跨设备同步引擎** ```python def sync_data(user_id, device_type, data_payload): # 检查同步策略 if device_type == "MOBILE" and data_payload['priority'] > THRESHOLD: # 实时同步关键数据 push_to_pc(user_id, data_payload) else: # 批量同步常规数据 add_to_sync_queue(user_id, data_payload) # 更新设备状态映射 update_device_state(user_id, device_type, data_payload['sync_token']) ``` 5. **个性化荐系统** - 混合荐算法: $$ RecScore = \beta \cdot CF_{score} + (1-\beta) \cdot CBF_{score} $$ - $CF_{score}$:协同过滤得分 - $CBF_{score}$:基于内容过滤得分 - 设备场景适配: ```mermaid graph TD A[荐请求] --> B{设备类型} B -->|手机| C[移动场景优化] B -->|电脑| D[深度内容荐] C --> E[碎片化+位置感知] D --> F[复杂交互+多标签] ``` #### 三、实施步骤 1. **数据层建设** - 建立用户行为数据仓库(参考引用[2]) - 实现设备间数据格式标准化:$JSON \leftrightarrow Protocol Buffers$ 2. **同步策略设计** | 数据类型 | 手机→电脑 | 电脑→手机 | 触发条件 | |---|---|---|---| | 操作历史 | 实时同步 | 延迟同步 | WiFi环境 | | 收藏内容 | 增量同步 | 全量同步 | 内容更新 | | 偏好设置 | 双向实时 | 双向实时 | 即时修改 | 3. **荐场景实现** - **内容延续场景**:手机上阅读文章→电脑荐相关论文 - **跨设备提醒**:电脑购物车商品→手机送折扣信息 - **场景自适应**:$ \text{荐权重} = f(设备类型, 网络环境, 使用时段) $ #### 四、技术挑战与解决方案 1. **数据一致性** - 采用CRDT(无冲突复制数据类型)算法:$$ \text{状态} S = merge(S_{pc}, S_{phone}) $$ - 实现最终一致性模型 2. **隐私保护** - 联邦学习框架:$ \text{模型更新} = \sum_{i=1}^n \Delta W_i \big|_{device_i} $ - 差分隐私技术添加噪声:$ \epsilon\text{-DP机制} $ 3. **性能优化** - 移动端使用SQLite缓存高频数据 - 电脑端采用LevelDB存储历史行为 - 引用[3]的渐进式更新策略降低负载 ### 典型应用场景 1. **工作流延续**:手机拍摄文档→电脑自动OCR识别 2. **媒体消费**:手机观看视频→电脑荐延伸内容 3. **购物体验**:电脑浏览商品→手机送店铺优惠券 > 该方案整合了多源数据融合[^1]、实时画像更新[^4]和渐进式部署[^3]等关键技术,可实现秒级延迟的跨设备个性化体验。实际部署需考虑用户隐私偏好设置和数据加密传输[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值