Open Oscar Server：复活AIM与ICQ的开源即时通讯服务器

一段互联网记忆的复活

对于经历过2000年前后互联网黄金时代的用户来说，AIM（AOL Instant Messenger）和ICQ这两个名字承载着无数即时通讯的青春记忆。那个标志性的"嘟嘟"提示音、那句经典的"Uh-oh!"，以及在好友列表中焦急等待对方上线的时光，都是一代网民挥之不去的共同回忆。

从历史维度来看，这两款软件在即时通讯发展史上的地位举足轻重。ICQ由以色列公司Mirabilis于1996年推出，是第一款真正意义上在全球范围内大规模流行的互联网即时通讯工具，它的名字本身就是"I Seek You"的谐音，开创了在线状态显示、离线消息等如今看来理所当然的功能范式。ICQ还引入了一个在当时极具辨识度的设计——每位用户被分配一个纯数字的UIN（Universal Internet Number），早期注册的低位数UIN（如五位、六位数字）后来甚至成为一种数字身份的"稀缺资源"，在eBay等平台上被高价交易。1998年，AOL以4.07亿美元的天价收购了Mirabilis，将ICQ纳入旗下，与自家的AIM形成双线布局。与ICQ的数字ID不同，AIM采用的是可自定义的"屏幕名称"（Screen Name）系统，用户可以选择个性化的英文昵称作为身份标识，这一设计深度融入了美国青少年的在线社交文化——许多人的AIM屏幕名称成为了他们最早的"网络身份"。AIM在北美市场的统治力更为惊人——在其巅峰时期的2001年前后，AIM占据了北美即时通讯市场超过50%的份额，同时在线用户数突破1800万，几乎成为美国青少年社交生活的标配工具。

然而，即时通讯的竞争格局在2000年代中后期发生了剧烈变化。微软的MSN Messenger（后更名为Windows Live Messenger）凭借与Windows操作系统的深度捆绑在全球范围内迅速崛起；Skype将语音通话引入即时通讯领域，重新定义了用户对通讯软件的功能预期；而2007年iPhone发布后，移动互联网时代的到来更是彻底改写了游戏规则——WhatsApp、微信、iMessage等移动优先的通讯应用迅速占领市场，桌面端即时通讯软件的用户基数急剧萎缩。AIM在2017年正式关闭，ICQ也在2024年停止服务（此前它已于2010年被俄罗斯互联网公司Digital Sky Technologies收购，后归属Mail.ru集团），这些曾经风靡全球的聊天软件似乎彻底退出了历史舞台。

就在大多数人以为这段历史已经画上句号的时候，一个名为 Open Oscar Server 的开源项目悄然出现在Hacker News上，吸引了一批怀旧派技术爱好者的目光。这是一个完全开源的服务器端实现，能够兼容原生的AIM和ICQ客户端——换句话说，如果你还保存着当年的老旧客户端程序，现在可以在自己的服务器上重建那段聊天体验。

什么是OSCAR协议

协议背景与逆向工程历程

要理解Open Oscar Server的价值，首先需要了解它所实现的OSCAR（Open System for CommunicAtion in Realtime）协议。这是AOL专门为AIM和ICQ开发的即时通讯协议。虽然名字中带有"Open"这个词，但在很长一段时间里，OSCAR实际上是一个封闭的、没有公开文档的私有协议。

从技术架构上看，OSCAR是一种基于TCP连接的二进制协议，这与后来流行的基于XML文本的XMPP（Extensible Messaging and Presence Protocol）协议形成了鲜明对比。XMPP脱胎于1999年由Jeremie Miller创建的Jabber项目，它选择了人类可读的XML作为数据格式，这使得开发者可以直接用文本工具查看和调试通讯内容；而OSCAR选择二进制编码则是出于当时带宽极为有限的现实考量——在56K拨号上网的年代，每一个字节都弥足珍贵，二进制协议的数据效率优势是显而易见的。

OSCAR的协议栈采用了分层设计。最底层是FLAP（Frame Layer Protocol），它负责在TCP连接之上提供基本的数据帧封装。每个FLAP帧由一个6字节的固定头部组成：1字节的起始标记（固定为0x2A）、1字节的帧类型（frame type）、2字节的序列号和2字节的数据长度，随后是可变长度的有效载荷。FLAP定义了几种帧类型——SIGNON帧用于连接初始化、DATA帧承载实际的业务数据、ERROR帧用于错误通知、SIGNOFF帧用于断开连接，以及KEEP_ALIVE帧用于维持长连接。在FLAP之上，是核心的SNAC（Simple Network Atomic Communication）分层通信架构：每个SNAC包由一个family ID和一个subtype ID标识，不同的family负责不同的功能模块——例如family 0x0001处理通用服务、family 0x0002处理位置信息、family 0x0003处理好友列表、family 0x0004处理消息传递。这种FLAP+SNAC的两层架构在当时相当先进——FLAP层处理传输可靠性和帧分界问题，SNAC层专注于业务逻辑的模块化组织——但由于整个协议栈都是二进制编码且没有官方文档，外部开发者想要理解和实现它，就只能依赖逆向工程手段。

多年来，逆向工程社区通过抓包分析、二进制逆向等手段，逐步揭开了OSCAR协议的技术细节，包括登录握手流程、消息封包格式、好友列表同步机制等。在这一过程中，开源即时通讯客户端项目发挥了关键作用。最具代表性的是Gaim（后更名为Pidgin）项目及其底层通讯库libpurple——这个支持多协议的开源客户端在实现OSCAR兼容的过程中，积累了大量关于协议行为的实证知识。libpurple的OSCAR协议实现代码至今仍然是研究该协议最权威的非官方参考之一，其中包含了大量通过反复试验和抓包比对得到的协议行为注释。此外，像Miranda IM、Adium等第三方客户端也各自对OSCAR协议的不同版本和功能子集进行了独立的逆向实现。

值得一提的是，AOL对第三方客户端的态度经历了从积极打压到默许容忍的转变——早期AOL曾频繁修改协议细节以封杀第三方客户端，甚至在2000年前后与开源社区展开了一场颇为戏剧性的"猫鼠游戏"。在这场对抗中，AOL曾采取的手段包括修改服务器端的协议握手签名、在登录流程中注入新的验证步骤、甚至向第三方客户端用户发送警告消息。AOL还曾尝试通过其早期的TOC（OSCAR的简化版文本协议，最初作为官方提供的有限开放接口）来引导第三方开发者远离直接实现OSCAR协议。然而，开源社区往往能在数小时到数天内破解新的限制措施，这场技术对抗最终随着AIM市场份额的逐渐萎缩而不了了之。正是这些前辈们数年乃至十数年的积累，为今天Open Oscar Server这类项目的诞生奠定了不可或缺的基础。

协议级兼容的核心意义

Open Oscar Server最核心的价值在于协议级别的兼容。用户无需修改或重新编译原始的AIM/ICQ客户端软件，只需将客户端的服务器地址指向自建的Open Oscar Server实例，即可完成登录、添加好友、收发消息等操作。这种"即插即用"的兼容方式，极大降低了怀旧用户重温经典的技术门槛。

这里值得做一个对比来理解其独特性：如果AOL当年选择的是XMPP这样的开放标准协议，那么服务器关闭后，社区可以非常容易地用Ejabberd、Prosody等成熟的开源XMPP服务器来承接。XMPP在2004年被IETF标准化为RFC 3920/3921，其联邦化（federation）架构允许不同服务器之间互相通信，这意味着即使某一个服务器运营商退出，用户的社交网络也不会因此断裂。但OSCAR作为私有二进制协议，其服务器端从未被公开实现过，这意味着Open Oscar Server的开发者需要从零开始，仅凭社区多年积累的逆向工程知识来构建一个完整的服务器端实现。这一工程量和技术难度远超简单的"部署一个开源服务器"——开发者需要重建整个服务器端状态机，包括认证服务、BOS服务、好友列表存储、消息路由引擎以及多服务间的会话管理，所有这些都必须精确匹配客户端预期的协议行为。

技术价值与应用场景

数字文物的活态保护

从技术史与数字文化保护的角度看，Open Oscar Server具有独特的意义。软件有生命周期，当官方服务器关闭后，即使客户端程序还能启动，也会因为无法连接后端服务而变成一块"砖头"。Open Oscar Server所做的，本质上是一种数字文物的活态保护——它不是把老软件封存进博物馆的展柜，而是让它们重新运转、重新可交互。

这种"活态保护"的理念在更广泛的数字保护运动中正在获得越来越多的关注和认可。Internet Archive（互联网档案馆）长期以来通过Wayback Machine保存网页快照，但对于需要服务器端配合才能运行的交互式软件，静态存档显然远远不够。Internet Archive也在这个方向上进行了积极探索——其"软件图书馆"项目通过在浏览器中运行DOSBox、MAME等模拟器，让用户可以直接在网页上体验数千款经典软件和游戏，但这种方案对于需要网络后端的在线服务仍然力有不逮。在法律层面，美国版权局在DMCA（数字千年版权法案）第1201条的豁免审查中，已经多次讨论过废弃在线服务的保护问题。DMCA第1201条本身禁止规避技术保护措施（如DRM），但每三年一次的豁免审查程序允许特定类群在特定条件下获得例外。电子前沿基金会（EFF）在2015年和2018年的豁免审查周期中积极推动了两项关键豁免：一是允许对已停服在线游戏的服务器端进行逆向工程和模拟（最终在2015年获得有限批准），二是将这一豁免范围扩展到更广泛的"创意性联网软件"（2018年取得进展）。这些法律讨论的背景直接关系到Open Oscar Server这类项目的合法性与未来空间，尽管豁免条款中仍附有诸多限制条件——例如要求相关活动必须出于保护目的而非商业目的。

类似的开源复活项目在游戏领域早已屡见不鲜，各种私服模拟器让停服的网络游戏得以延续生命。例如《星球大战：星系》（Star Wars Galaxies）停服后，SWGEmu项目通过逆向工程重建了整个游戏服务器端；《城市英雄》（City of Heroes）的社区服务器至今仍维持着活跃的玩家群体。而在即时通讯领域，Open Oscar Server填补了一块相对空白的拼图，为AIM和ICQ这类经典软件提供了持续存活的可能。

隐私与数据自主可控

除了怀旧价值之外，自建OSCAR服务器还带来了实实在在的隐私优势。在AIM和ICQ的鼎盛时期，所有聊天数据都必须经过AOL的中心化服务器。事实上，AOL在隐私方面的记录并不光彩——2006年的"AOL搜索数据泄露事件"中，AOL研究部门公开发布了65万用户的2000万条搜索记录，虽然这一事件主要涉及搜索引擎而非即时通讯，但它深刻揭示了中心化服务对用户数据的潜在风险。更值得注意的是，在美国国家安全局（NSA）前雇员斯诺登于2013年披露的"棱镜计划"（PRISM）文件中，AOL被列为参与数据共享的科技公司之一，这意味着通过AOL服务器传输的通讯数据在理论上可能被情报机构访问。而通过Open Oscar Server，用户可以在自己完全掌控的硬件上运行即时通讯服务，聊天数据不再流向任何第三方。

当然，在当前的自托管即时通讯生态中，用户其实已经有不少成熟的选择。Matrix协议及其客户端Element提供了去中心化、端到端加密的现代通讯方案——Matrix采用联邦化架构，各个"homeserver"之间通过Server-Server API进行通信，用户数据分布在各自的服务器上，同时通过Olm/Megolm加密库实现了与Signal协议类似的端到端加密能力。XMPP生态系统中的Conversations、Gajim等客户端搭配Ejabberd或Prosody服务器同样可以实现完全自主可控的通讯，XMPP通过XEP-0384（OMEMO）扩展也已支持基于Signal协议的端到端加密。与这些现代方案相比，基于OSCAR协议的自建方案在安全性和功能丰富度上显然不具备竞争优势——OSCAR协议设计于1990年代，原生并不支持端到端加密等现代安全特性，其消息在客户端与服务器之间即便使用了SSL/TLS传输加密，服务器端仍然可以看到明文内容。但Open Oscar Server的价值并不在于作为一个"最佳实践"的通讯解决方案，而在于它提供了一种独一无二的历史体验和文化连接。

对于注重数据自主权的技术爱好者、小型团队或实验性社群来说，这提供了一种既有趣又实用的私密通讯替代方案。

协议学习与网络编程研究素材

对于协议开发者和网络编程学习者来说，Open Oscar Server也是一份难得的学习材料。通过阅读其源码，可以了解一个真实世界的、经过十数年时间考验的即时通讯协议是如何设计的，涵盖登录认证、状态同步、消息路由、好友列表管理等经典通讯系统设计问题。

OSCAR协议中蕴含着许多值得深入研究的设计决策。例如，其登录流程采用了一种基于挑战-响应（challenge-response）的认证机制，客户端首先连接到认证服务器（Authorizer），通过验证后获得一个临时cookie，再使用这个cookie连接到实际的BOS（Basic OSCAR Service）服务器——这种"两阶段登录"的设计与现代OAuth认证流程有着异曲同工之妙。在OAuth 2.0中，用户首先在授权服务器上完成身份验证并获得授权码（authorization code），再用这个授权码换取访问令牌（access token）来访问资源服务器——两者的核心思路都是将"身份验证"和"服务访问"解耦到不同的服务端点上，从而实现更灵活的架构扩展和更精细的安全控制。又如，OSCAR的好友列表（称为Server-Side Information，SSI）同步机制涉及版本号比对和增量更新——客户端在本地缓存好友列表及其版本时间戳，登录时将本地版本号发送给服务器，服务器仅在版本不匹配时才下发变更的条目，而非每次都传输完整列表。这种设计思路与现代分布式系统中的乐观并发控制、HTTP的ETag/If-None-Match条件请求机制，乃至git的增量同步策略都有着相通的哲学。相比纯粹的教科书示例，这种来自生产环境的代码更具参考价值。

开源社区的怀旧文化

说个细节，Open Oscar Server在Hacker News上的热度并不算高——仅获得了个位数的点赞和寥寥数条评论。但这恰恰反映了这类项目的真实定位：它并非面向大众的商业产品，而是服务于一个高度垂直、充满技术情怀的小众群体。

开源世界的魅力正在于此。总有一些开发者愿意花费大量业余时间，去复活那些商业公司早已放弃的软件和服务。他们的动机往往不是盈利，而是纯粹的技术挑战、怀旧情感，或是对数字遗产的守护意识。这种"用爱发电"的精神，恰恰是开源生态中最动人的部分之一。这种精神在更广泛的"复古计算"（retrocomputing）社区中同样蓬勃发展——从运行在树莓派上的BBS系统（如Synchronet BBS，至今仍维持着活跃的拨号和Telnet用户社区），到模拟早期Macintosh的Mini vMac项目，到完整重现Windows 3.1体验的虚拟机镜像，一个庞大而热情的社区持续致力于让过去的技术在今天保持可触、可用、可理解。这一运动的核心信念可以用计算机历史博物馆（Computer History Museum）的策展理念来概括：最好的保护不是把硬件锁在玻璃柜里，而是让人们能够亲手操作、亲身体验。类似地，Archive Team——一个由互联网活动家Jason Scott发起的志愿者组织——长期从事濒临消失的网络服务数据抢救工作，从GeoCities到Google+，他们在服务关闭前紧急爬取和归档用户生成的内容，其工作理念与Open Oscar Server所践行的"活态保护"一脉相承。

现实局限与兼容性挑战

当然，也需要客观看待此类项目面临的现实局限：

• 客户端兼容性问题：原始的AIM/ICQ客户端在现代操作系统上运行可能遇到障碍。老旧的Windows版客户端在Windows 11上未必能顺利启动——许多早期版本依赖于已被弃用的Win32 API调用或特定版本的运行时库（如旧版Visual C++ Redistributable）。macOS用户面临的问题可能更多——自从Apple在macOS Catalina（10.15，2019年发布）中彻底移除了对32位应用的支持后，大量经典软件都无法在新系统上原生运行，而AIM for Mac的最后几个版本恰好都是32位应用。用户可能需要借助虚拟机（如VirtualBox中运行Windows XP）或兼容层（如Wine/CrossOver）来运行这些经典客户端。此外，一些老客户端内置的SSL/TLS证书早已过期，且它们可能仅支持SSL 3.0或TLS 1.0等已被现代安全标准淘汰的旧版协议，网络连接层面也可能需要额外配置——例如在服务器端降级TLS版本要求或配置特殊的证书信任链。
• 用户规模受限：缺乏庞大的活跃用户基础，自建服务器更多是作为技术演示或小圈子内部使用，很难重现当年数亿用户同时在线的热闹场景。即时通讯的核心价值在于网络效应——梅特卡夫定律（Metcalfe's Law）指出，通讯网络的价值与用户数量的平方成正比。一个只有十几人的自建OSCAR服务器，在功能上与当年的AIM完全一致，但在体验上却有着天壤之别。
• 功能完整度存疑：逆向工程实现的协议兼容通常难以做到100%完美，某些高级功能（如文件传输、语音聊天、自定义表情等）可能存在缺失或运行不稳定的情况。OSCAR协议在其生命周期中经历了多个版本的迭代，不同年代的客户端可能使用略有差异的协议变体，这进一步增加了全面兼容的难度。特别是AIM在后期版本中引入的一些功能（如AIM Pages个人主页集成、AIM Phoneline网络电话服务等）涉及OSCAR协议之外的额外服务端组件，这些功能的复现几乎不在开源项目的可行范围之内。

这些限制并不影响项目本身的价值，但用户在部署使用前应该对此有合理预期。

技术怀旧的长远价值

Open Oscar Server或许永远不会成为一个热门的明星项目，但它所代表的意义超越了软件本身。在一个应用快速更迭、线上服务说关就关的时代，这类开源复活项目提醒我们一个容易被忽视的事实：技术不应该只有"向前看"的一面，回望和保存那些塑造了互联网历史的工具与协议，同样有着不可替代的价值。

对于那些还记得当年在AIM上和朋友彻夜长聊的用户来说，能够重新看到熟悉的登录界面、听到那声标志性的提示音，本身就是这个项目最好的回报。而对于更广泛的技术社区而言，Open Oscar Server也是一次关于协议开放性、数字遗产保护与开源精神的生动实践。

核心要点