• 2013-08-05

    WebRTC源码架构浅析

    Views: 46418 | No Comments

    Google 在2010年花了6千8百万美元收购了大名鼎鼎的 Global IP Sound/Solutions (GIPS) 公司, 得到了它的 VoIP 相关技术的专利和软件. 第二年, Google就把这些软件开源了, 不过, 不是作为独立的软件, 而且也和原来的软件功能大不一样, 而是作为所谓的 WebRTC 方案的一部分.

    GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大, 单单是从 trunk 中获取的代码和数据就达到1.2G还多.

    不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:

    1. 应用层, 即 WebRTC 技术. 此部分的技术主要是浏览器开发者需要, 但因为其是太过于顶层的应用技术, 过于偏向某一方面, 所以可取可不取.

    2. 网络层, 主要是 libjingle. libjingle 就是 Google Talk 所使用的网络框架. 但 libjingle 并没开源服务器端的代码和技术, 再者, 网络层的可替换性很强, 各家公司总是设计自己的私有网络协议和架构, 所以, libjingle 的作用就是作为一个学习的对象.

    3. 语音和视频引擎, 这部分才是原来 GIPS 公司的专利和核心技术! 所以, 要详细解读一番.

    Continue reading »

    Posted by ideawu at 2013-08-05 00:24:01 Tags: , , , , ,
  • 2013-03-21

    高性能并发网络服务器设计与实现

    Views: 25980 | 5 Comments

    我在公司介绍的"高性能并发网络服务器设计与实现"PPT.

    Posted by ideawu at 2013-03-21 19:56:42
  • 2010-08-22

    Master-Workers 模式处理高负载

    Views: 25563 | 7 Comments

    对于高负载的网络服务器, 瓶颈几乎总是在等待 IO, 而 CPU 的计算能力往往不是最先遇到的问题. 你的服务器程序, 接收客户端的请求, 可能还要连接另一台网络服务器, 一起合作处理客户端的请求. 很多情况下, 你无法把客户端的连接以及与另一台服务器的连接统一处理, 不可避免地要出现等待. 这时, 只能使用多进程或者多线程.

    Master-Workers(管理者-工作者)模式是处理这种情况的主要方式, 只要有 IO 等待或者其它耗时的操作, 都交互若干个工作者之一处理, 这样, 后续的请求不会被阻塞, 从而实现高负载.

    目录:

    下文中有时用"进程"一词同时指代进程和线程, 它们的区别主要考虑的是通信方式.
    Continue reading »

    Posted by ideawu at 2010-08-22 16:03:57
  • 2010-07-16

    经典的”服务器最多65536个连接”误解

    Views: 43157 | 9 Comments

    "因为TCP端口号是16位无符号整数, 最大65535, 所以一台服务器最多支持65536个TCP socket连接." - 一个非常经典的误解! 即使是有多年网络编程经验的人, 也会持有这个错误结论.

    要戳破这个错误结论, 可以从理论和实践两方面来.

    理论

    系统通过一个四元组来唯一标识一条TCP连接. 这个四元组的结构是{local_ip, local_port, remote_ip, remote_port}, 对于IPv4, 系统理论上最多可以管理2^(32+16+32+16), 2的96次方个连接.

    因为对于同一台服务器来说, 一般只有一个 local_ip, 那么, 同一台服务器可以管理 2^(16+32+16) 个连接. 而一个服务(进程, 如 Nginx 进程)一般只监听一个 local_port, 那么, 同一台服务就可以管理 2^(32+16) 个连接. 而如果从一台远端机器(所谓的 client)来连接这台服务器上的一个服务, 那么 local_ip, local_port, remote_ip 这3个变量是固定的, 那么, 就只能建立 2^16=65536 个连接了. 这就是经典的误解的来源!

    如果不仅仅考虑TCP, 则是一个五元组, 加上协议号(TCP, UDP或者其它).

    Continue reading »

    Posted by ideawu at 2010-07-16 16:44:50
  • 2010-07-07

    TCP协议思想和技术的广泛应用

    Views: 29591 | 1 Comment

    TCP 协议是大量重要的网络和通讯的思想和技术的集合体. 这些思想和技术被应用在 TCP 身上, 另一方面, 学习 TCP 可以了解这些思想和技术. 通讯的思想和技术不仅仅可以应用狭义的数据通讯上, 也可以应用在广义的信息通讯上, 后者一般可以理解为应用层的交互协议, 例如即时通讯(IM)的聊天协议.

    首先, TCP 协议是一种可靠的传输协议. 这种可靠性可以从两方面理解: 1. TCP 保证数据的有序性和无差错; 2. TCP 尽最大努力确保数据被接收.

    有序和无差错可能比较好理解, 但"最大努力"则和我们一般理解的"可靠"有较大差别. 首先, TCP 尽最大努力传输数据, 一旦发送方无法保证数据传输到接收方, 它将通过断开连接(使连接失效)来声明这一点. 其次, TCP 可以明确地告诉一个数据分段已经被对方接收, 但无法准确的断定未被确认的数据没有被对方接收, 也就是说, 数据可能没有被对方接收, 也能已经被对方接收. 这种对传输失败的不确定性, 显然是对可靠性的一个重大打击. "两军队问题(Two Army Problem)"说明了这一点, 事实上, 我们无法判断一个确认(ACK)是丢失了还是没有发出.

    Continue reading »

    Posted by ideawu at 2010-07-07 12:16:47
  • 2010-06-06

    endlessssh – SSH 代理工具

    Views: 24108 | 9 Comments

    新建了一个开源项目 endlessssh, 用于 SSH 代理(不是 SSH 作为代理, 而是 SSH 使用代理), 放在 Google Project Hosting. 工具有两个特点:

    1. Tunneling SSH over REAL HTTP(完善中)

    让 SSH 工作在 HTTP 协议上, 从而穿越防火墙.

    2. 持续的会话

    即使 TCP 网络连接断开(这时, SSH 会话会失效), SSH 会话仍然保持, 直到网络重连后, 会话继续.

    项目地址: http://code.google.com/p/endlessssh/

    补充:

    谢谢评论中 Zealot 朋友的推荐.

    大概看了下类似的一个 GNU 项目 httptunnel(http://www.nocrew.org/software/httptunnel.html). 这个项目所使用的交互过程更像是 HTTP 交互, 在一个 HTTP 报文中包含自己的多个报文. httptunnel 没有确认机制, 也没有会话保持机制. 不过, httptunnel 可以值得借鉴.

    Posted by ideawu at 2010-06-06 15:17:22
|<<<1234567>>>| 2/7 Pages, 37 Results.