idea's blog

StunLink 用 C# 语言编写, 可以穿透绝大多数 NAT 和防火墙, 在局域网中的传输速度能达到 8M/s 的速度, 它基于 UDP, 使用与 TCP 类似的滑动窗口机制保证可靠传输. StunLink 的使用方法很简单:

StunLink link = new StunLink();
link.RemoteInfo["IP"] = "1.2.3.4";
link.RemoteInfo["Port"] = "20000";
link.RemoteInfo["Password"] = "einj8ds1mx2";
try{
	link.Connect();
}catch{
	// 连接失败.
}
// Connect 方法成功返回后已经建立了连接.

byte[] buf = ...
link.Send(buf);
int len = link.Receive(buf);
...

一个比较常见的误解就是, 认为即时消息必须是 P2P 方式的. 这并不是普遍情况. 对于最具代表性的文本通讯, QQ, XMPP 等都不是 P2P 的, 而是经过中转服务器中转. 下面是可能的原因:

1. P2P 连接并不总是能建立, 也就是说在某些情况下 P2P 是不可行的.
2. 假设这样的情况, 一个节点向另一个节点发送了一条消息, 然后过了一个小时又发送另一条消息. 这是很常见的情况. 如果使用 P2P, 那么就需要在这一个小时内保持一条 P2P 连接(如 TCP 连接)或者建立两次连接. 这显示增加了系统的复杂性, 不如通过中转服务器进行中转简单.
3. 通讯记录有时需要被保存和过滤(可能是政府的要求).

还有就是带宽问题. 在某些情况(有时是常见的)下, A 与 B 直接连接的带宽并不比 A 和 B 之间经过 R 中转的带宽高. 有一次我和一位朋友要传输大概 100 MB 的文件, 开始我们使用了聊天工具的 P2P 传输, 发现速率只有几 K. 后来我决定让他把文件传到我的网站空间的 FTP 上, 然后我再到该 FTP 上取. 估算的速率有 500 K 以上.

带宽问题是由基础网络造成的. 有一个极端的例子, 我经过美国的节点中转数据的速率要比在同一个城市内的网通和电信之间的直接通信要快得多!

还有一个比较重要的例子就是 HTTP 代理服务器, 我们花钱通过一个代理服务器来访问某些网站, 以代替我们直接连接这些网站的服务器.

传输协议是客观存在的, 即使你的传输不使用任何已经公开的协议, 你也是在使用一种未公开的协议. 传输协议必须保证基础的要求:

1. 错误控制
2. 流量控制

数据常常可以划分为帧(或者报文, 分段等), 假设报文的在传输中不会出现损坏, 报文要么丢失, 要求完整地到达目的. ARQ(Automatic Repeat reQuest )是一种错误控制机制, 但是也常常具有流量控制的功能.

ARQ 有如下几种: Stop-and-wait ARQ(停止等待 ARQ), Go-Back-N ARQ(回退 N 帧 ARQ) and Selective Repeat ARQ(选择重传 ARQ).

Stop-and-wait ARQ 是其它两种的基础. 其隐含了"一个传输例程的 Stop-and-wait ARQ"这样的意思. Go-Back-N ARQ 是"多个传输例程的 Stop-and-wait ARQ", 并且为了管理这些例程, 额外添加了其它的协议.

使用 tcpdump 分析一个 TCP 连接从建立到交互的过程, 发现交互过程中的第一个数据报文的序号总是从 1 开始. 这让我很奇怪, 因为我记得第一个序号就是握手过程中商定的序号. 后来才发现, 这是 tcpdump 的一个特性, 它默认将序号显示为与 ISS, IRS 的偏移值, 通过 -S 选项可以禁用这个特性.

在 TCP 的慢启动和拥塞控制中, 当发生拥塞时, TCP 进行慢启动, 当慢启动进行到一定阀值后进行拥塞避免. 正如 "TCP/IP 协议详解" 中提到的, "慢启动" 这个术语并不准确, 拥塞窗口在慢启动期间以指数速率增长. 在拥塞避免算法进行时, 拥塞窗口以线性速率增长, 每次加 1.

这两个算法可以用编程语言来实现:

using System;

class Test
{
    static int cwnd1 = 1;
    static int cwnd2 = 1;
    static int ssthresh = 64;

    public static void Main(){
        int step = 20;
        for(int i=0; i<step; i++){
            grow1();
            grow2();
            Console.WriteLine("{0,8}\t{1,8}", cwnd1, cwnd2);
        }
    }

    // 完全指数增长.
    static void grow1(){
        int num = cwnd1;
        for(int n=0; n<num; n++){
            cwnd1 += 1;
        }
    }

    // 先指数增长, 然后加性增长.
    static void grow2(){
        int wnd = cwnd2;
        int ssthresh_var = 0;
        for(int n=0; n<wnd; n++){
            if(cwnd2 < ssthresh){
                cwnd2 += 1;
            }else{
                if (++ssthresh_var == wnd) {
                    ssthresh_var = 0;
                    cwnd2 += 1;
                }
            }
        }
    }
}

TCP/IP 源码的一个疑问:

TCP/IP 详解 1 这样描述: 设置拥塞窗口 cwnd 为1, 发送 1 个报文段, 收到一个 ACK 后, cwnd 加 1, 然后发送 2 个, 收到 2 个 ACK 后, cwnd 加 2, 然后发送 4 个...

这确实是指数增长, 但是, 因为延时 ACK 的存在, 发送的2个报文段可能只收到 1 个 ACK, 所以 cwnd 只增加 1 而不是增加 2. 在延时 ACK 影响的范围内, 这是线性增长.

希望熟悉 TCP/IP 的朋友帮忙解惑, 十分感谢!

Google Talk 是 Google 公司的一项基于开放协议之上的即时消息(Instant Messaging, IM)服务. Google 开放了它的 IM 服务, 所以你可以开发你自己的 Google Talk 服务的客户端, 或者整合 Google Talk 服务到你自己的服务中.

为了达到上面的目标, Google 提供了一个开放源代码的 C++ 库, libjingle. Google 将 libjingle 以一个自己创造的协议进行开放源代码, Google 称之为 "a Berkeley-style license". Google 同时提供了一系列非常详细, 组织良好的文档, 放在其网站上(Google Talk Developer Home Page).

本网站上的内容为 Google Talk Developer Home Page 网站上英文内容的中文翻译. 这项翻译工作是本人的个人行为, 基于爱好和学习的目的, 同时为了方便有意学习 Google Talk 开发但不方便阅读英文的中文使用者.

翻译内容链接: ##待定##