• 2010-06-06

    endlessssh – SSH 代理工具

    Views: 25971 | 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
  • 2010-06-03

    endless_tcp – 一种适应极端网络环境的网络软件架构

    Views: 21148 | No Comments

    TCP 是一种可靠连接的协议, 即使在恶劣的网络环境中(如丢包率高), 也能实现数据的可靠传输. 可以简单地和 UDP 对比. 使用 UDP 发出一份数据, 你无法通过 UDP 本身判断数据是否已经被对方收到. 但是使用 TCP, 你可以判断, 因为如果 TCP 无法保证对端收到数据, 连接便会使自己失败, 从而你得到一个通知.

    TCP 会话依赖于 IP 和端口, 也就是说, 一旦双方的任意一方的 IP 和端口发生了改变, TCP 连接就失效了. 另外, 虽然 TCP 有重传机制, 但重传失效的次数和时限用户转难控制. 为解决这两个问题, 需要实现一种不依赖于 IP/Port, 适应极其恶劣(超过 TCP 的容忍范围)的网络环境的连接协议, 称为 endless_tcp.

    Continue reading »

    Posted by ideawu at 2010-06-03 22:12:04 Tags:
  • 2010-06-01

    SSH ProxyCommand及其思想

    Views: 27507 | No Comments

    OpenSSH 的客户端有一个 ProxyCommand 的选项, 用于 SSH 客户端与服务器之间的隧道通信(tunneling). 所谓的隧道技术, 也称代理技术, 是网络通信技术的一个普遍概念, 就是把一条信道建立于另外一条信道之上.

    SSH 会话基于一个 TCP 连接. 如果我们把连接的两个端口各自的出口(也即入口)进行截获, 就可以用其它的信道来传输. 而且 SSH 仍然认为它用的是和另一端连接一条 TCP 连接.

    Continue reading »

    Posted by ideawu at 2010-06-01 00:47:42
  • 2009-10-22

    TCP读取报文不完整的问题分析(粘包,拆包)

    Views: 20995 | No Comments

    首先解释一下这个题目, "报文"指的是业务层自定义的报文, TCP是流式协议, 不像UDP那样是报文协议.

    某两个系统间进行网络交互, 请求报文的格式为:

    <json串>&sig=xxx

    请求方用PHP的stream_socket_sendto()进行发送. 服务器端使用Python的twisted框架. 上线后, 出现问题, 服务器端接收到的报文不完整. 例如, json串只读了一半, 或者缺少"&sig=xxx", 缺少的数据是随机的, 但只缺少尾部, 已经接收到数据没有差错.
    Continue reading »

    Posted by ideawu at 2009-10-22 19:21:02 Tags:
  • 2009-10-12

    编写基于TCP的应用程序

    Views: 21116 | 1 Comment

    这似乎是一个非常简单的话题, 就跟"是个人就能做网站"一样, 你可能也认为"是个人就能写使用TCP socket的网络程序". 不过, 下面介绍的几个基本的原理的做法, 你可能并没有理解.

    TCP是一种流式的协议, 简单的说, TCP不检查数据的语义, 更不会检查数据的边界, 而应用层一般使用的是报文协议, 所以会有所谓的"粘包""拆包"问题. 为此, 产生了一些特定的用法和模式.

    任何应用程序, 都必须先进行报文协议设计. 虽然有些人捂上耳朵叫道"我不需要报文协议", 但是, 他还是需要进行报文协议设计. 有几种方式可用来设计报文协议:

    1. 明确声明报文数据的长度.
    2. 使用分隔符.
    3. 发送方发送完数据后关闭连接.

    第3种是socket的特定用法.

    报文设计方法1: 明确声明报文数据的长度

    此种方法一般较为常用, 因为兼容性好性能高. 一会介绍方法2的时候你就知道了. 一般会在数据的最前面用固定的几个字节存储一个二进制整数, 显示后面的数据的长度. 不过, 这是比较接近硬件底层报文协议设计. 应用层一般不这样, 在数据的前端固定几个字节存储ASCII数字, 前端补字符串'0', 或者在数字串后面跟换行符'\n', 这是一种和2的方法的混用.

    报文设计方法2: 使用分隔符

    前面介绍方法1的时候提过了, 使用分隔符来分隔报文, 然后在一般的语言都有 split() 函数, 用起来简单. 不过, 使用分隔符有一个缺点, 就是要进行数据转义, 避免报文数据中带有分隔符, 那就不好了. 此种方法还有一个缺点, 就是要遍历每一个字节, 查找分隔符, 性能不好. 介绍方法1的时候, 因为我们明确知道是数字串后面跟换行符, 所以不需要转义, 不会有转义性能损失, 同时数字串一般很短, 也可以忽略遍历性能损失.

    报文设计方法3: 发送方发送完数据后关闭连接

    这是 HTTP 1.0 采用的方式, HTTP 1.0 会在发送完响应后关闭连接(当然, 发送完请求后不能关闭连接, 所以可想而知, HTTP 1.0 必然使用方法1或者方法2, 你可以自己去学习了解). 这种方法不常用, 因为适用场景非常窄, 功能差.

    Continue reading »

    Posted by ideawu at 2009-10-12 15:15:52
  • 2009-06-25

    fdevent – 方便的跨平台IO多路复用接口

    Views: 16123 | No Comments

    fdevent是一套方便的跨平台IO多路复用C语言接口, 主要想法来自 epoll 和 lighttpd 的 fdevent, 接口的使用几乎和 epoll 一样.

    示例

    while(1) {
        nfds = fdevents_wait(evs, 1000);
        if(nfds == 0){
            //printf("timeout\n");
            continue;
        }
    
        for(i = 0; i < nfds; i++) {
            fde = evs->events[i];
    
            if(fde->flags & FDEVENT_IN){
                // ...
            }
    
            if(fde->flags & FDEVENT_OUT){
                // ...
            }
        }
    }
    

    项目主页: http://www.ideawu.net/person/fdevent/

    Posted by ideawu at 2009-06-25 16:21:28
|<<<1234567>>>| 3/7 Pages, 38 Results.