标签 github 下的文章

Caddy,一个用Go实现的Web Server

这是一个Web Server的时代,apache2nginx共舞,在追求极致性能的路上,没有最高,只有更高。但这又是一个追求个性化的时代,有些Web Server并没有去挤“Performance提升”这一独木桥,而是有着自己的定位,Caddy就是这样一个开源Web Server。

Caddy的作者Matt Holt在caddy官网以及FAQ中对caddy的目标阐释如下: 其他Web Server为Web而设计,Caddy为human设计。功能定位上,与经常充当最前端反向代理的nginx不同,caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性,使用配置简单。并且得益于Go的跨平台特性,caddy很容易的支持了三大主流平台:Windows、 Linux、Mac。在Caddy开发者文档中,我们可以看到caddy还可以在Android(linux arm)上运行。caddy目前版本为0.7.1,还不稳定,且后续版本可能变化较大,甚至与前期版本不兼容,因此作者目前不推荐caddy在生产环境被 重度使用。

关注caddy,是因为caddy填补了go在通用web server这块的空白(也许有其他,但我还不知道),同时Web server in go也“响应”了近期Golang去C化的趋势(Go 1.5中C is gone!),即便caddy作者提到caddy的目标并非如nginx那样。但未来谁知道呢?一旦Go性能足够高时,一旦caddy足够稳定时,自然而 然的就会有人将其用在某些应用的生产环境中替代nginx或apache2了。一套全Go的系统,在部署、运维方面也是有优势的。

一、安装和运行caddy

和诸多go应用一样,我们可以直接从caddy的github.com releases页中找到最新发布版(目前是0.7.1)的二进制包。这里使用的是caddy_darwin_amd64.zip。

下载解压后,进入目录,直接执行./caddy即可将caddy运行起来。

$caddy
0.0.0.0:2015

在浏览器里访问localhost:2015,页面上没有预期显示的类似"caddy works!”之类的默认Welcome页面,而是“404 Not Found"。虽然这说明caddy已经work了,但没有一个default welcome page毕竟对于caddy beginer来说并不友好。这里已经向作者提了一个sugguestion issue

二、caddy原理

Go的net/http标准库已经提供了http server的实现,大多数场合这个http server都能满足你的需要,无论是功能还是性能。Caddy实质上也是一个Go web app,它也import net/http,嵌入*http.Server,并通过handler的ServeHTTP方法为每个请求提供服务。caddy使用 http.FileServer作为处理 静态文件的基础。caddy的诱人之处在于其middleware,将诸多middleware串成一个middleware chain以提供了灵活的web服务。另外caddy中的middleware还可以独立于caddy之外使用。

caddy从当前目录的Caddyfile(默认)文件中读取配置,当然你也可以通过-conf指定配置文件路径。Caddyfile的配置格式 的确非常easy,这也符合caddy的目标。

Caddyfile总是以站点的Addr开始的。

单一站点的Caddyfile样例如下:

//Caddyfile
localhost:2015
gzip
log ./2015.log

Caddy也支持配置多个站点,类似virtualhost的 配置(80端口多路复用):

//Caddyfile
foo.com:80 {
    log ./foo.log
    gzip
}

bar.com:80 {
    log ./bar.log
    gzip
}

为了实现风格上的统一,单一站点也最好配置为如下这种格式(代码内部称之为    Server Block):

localhost:2015 {
    gzip
    log ./2015.log

}

这样Caddyfile的配置文件模板样式类似于下面这样:

host1:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}

host2:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}
… …

关于middleware,在caddy文档中有较为详细的说明和例子。对于caddy这样一个年轻的开源项目而言,其文档还算是相对较全的,虽 然现在还不能和nginx、 apache比。

caddy中的middleware就是一个实现了middleware.Handler接口的struct,例如gzip这个 middleware:

// middleware.go
type Middleware func(Handler) Handler
type Handler interface {
        ServeHTTP(http.ResponseWriter, *http.Request) (int, error)
}

// gzip/gzip.go
type Gzip struct {
    Next middleware.Handler
}

func (g Gzip) ServeHTTP(w http.ResponseWriter, r *http.Request) (int, error) {
    if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
        return g.Next.ServeHTTP(w, r)
    }
    …. …
    gz := gzipResponseWriter{Writer: gzipWriter, ResponseWriter: w}

    // Any response in forward middleware will now be compressed
    status, err := g.Next.ServeHTTP(gz, r)
    … …
}

middleware.Handler的函数原型与http.Handler的不同,不能直接作为http.Server的Handler使用。caddy使用了下面这个idiomatic go pattern:

type appHandler func(http.ResponseWriter, *http.Request) (int, error)

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if status, err := fn(w, r); err != nil {
        http.Error(w, err.Error(), status)
    }
}
当然这个pattern有很多变种,但思路大致类似。一个middleware chain大致就是handler1(handler2(handler3))的调用传递。

前面说过caddy是基于http.FileServer的静态文件Web Server,FileServer总会作为middleware chain的最后一环,如果没有配置任何middleware,那你的server就是一个静态文件server。

三、caddy典型应用

【静态文件Server】

caddy的最基础应用实际就是一个静态文件Server,底层由http.FileServer承载,当然caddy封装了http.FileServer,做了一些拦截处理,最后将w, r传递给http.ServeContent去处理文件数据。

第一次执行./caddy,实际上就启动了一个静态文件Server。但这个server不默认支持你navigate directory。如果你知道website root目录(如果没有指定root,则caddy执行的当前路径会作为website的root路径)下的文件名,比如foo.txt,你可以在浏览器 中输入:localhost:2015/foo.txt,caddy会执行正确的服务,浏览器也会显示foo.txt的全文。

对于静态文件Server,caddy支持在website的root路径下首先查找是否有如下四个文件:

//caddy/middleware/browse/browse.go
var IndexPages = []string{
    "index.html",
    "index.htm",
    "default.html",
    "default.htm",
}

如果查到有其中一个,则优先返回这个文件内容,这就是静态站点的首页。

如果要支持目录文件列表浏览,则需要为website配置browse middleware,这样对于无index file的目录,我们可以看到目录文件列表。

localhost:2015 {
    browse
}   

【反向代理】

caddy支持基本的反向代理功能。反向代理配置通过proxy middleware实现。

localhost:2015 {
    log ./2015.log

    proxy /foo localhost:9001
    proxy /bar localhost:9002
}

当你访问localhost:2015/foo时,实际上访问的是9001端口的服务程序;
当你访问localhost:2015/bar时,实际上访问的是9002端口的服务程序。

【负载均衡】

Caddy支持负载均衡配置,并支持三种负载均衡算法:random(随机)、least_conn(最少连接)以及round_robin(轮询调度)。

负载均衡同样是通过proxy middleware实现的。

localhost:2015 {
    log ./2015.log

    proxy / localhost:9001 localhost:9003 {
        policy round_robin
    }
    proxy /bar localhost:9002 localhost:9004 {
        policy least_conn
    }
}

【支持fastcgi代理】

caddy同样支持fastcgi代理,可以将请求通过fastcgi接口发送给后端的实现fastcgi的server。我们以一个"hello world"的php server为例。

mac os上自带了php-fpm,一个实现了fastcgi的php cgi进程管理器。caddy将请求转发给php-fpm监听的端口,后者会启动php-cgi解释器,解释index.php,并将结果返回给caddy。

mac os上的php-fpm默认没有随机启动。我们需要简单配置一下:

$mkdir phptest
$mkdir -p phptest/etc
$mkdir -p phptest/log
$cd phptest
$sudo cp /private/etc/php-fpm.conf.default ./etc
$cd ./etc

$sudo chown tony php-fpm.conf.default
$mv php-fpm.conf.default php-fpm.conf

编辑php-fpm.conf,保证下面两项是非注释状态的:

error_log = log/php-fpm.log
listen = 127.0.0.1:9000
 

我们通过network socket进行fastcgi通信。

回到phptest目录下,执行:

php-fpm -p ~/test/go/caddy/phptest

执行后,php-fpm就会转入后台执行了。

接下来我们来配置Caddyfile:

localhost:2015 {
    fastcgi / 127.0.0.1:9000 php
    log ./2015.log
}

这里配置的含义是:将全部请求转发到9000端口,这里的php是一个preset(预配置集合),相当于:

ext   .php
split .php
index index.php

我们在phptest目录下创建一个index.php文件,内容如下:

<?php echo "Hello World\n"; ?>

好了,现在启动caddy,并使用浏览器访问localhost:2015试试。你会看到"Hello World"呈现在浏览器中。

【git push发布】

对于一些静态站点,caddy支持git directive,实现在server启动以及运行时定期git pull你的项目库,将最新更新pull到server上。

caddy文档中给出两个例子:

第一个是一个php站点,定期pull项目库,实现server更新:

git git@github.com:user/myphpsite {
    key /home/user/.ssh/id_rsa
}
fastcgi / 127.0.0.1:9000 php

第二个是一个hugo支撑的静态站点,每次pull后,执行hugo命令生成新的静态页面:

git github.com/user/site {
    path  ../
    then  hugo –destination=/home/user/hugosite/public
}

注意:git directive并非middleware,而是一个单独的goroutine实现的。

四、小结

caddy的功能不局限于上面的几个例子,上面只是几个最为常见的场景而已。caddy目前还很年轻,应用不多,但知名golang网站 gopheracademy.com(GopherCon组织方)是由Caddy support的。caddy还在积极进化,有兴趣的Gopher可持续关注。

ngrok原理浅析

之前在进行微信Demo开发时曾用到过ngrok这个强大的tunnel(隧道)工具,ngrok在其github官方页面上的自我诠释是 “introspected tunnels to localhost",这个诠释有两层含义:
1、可以用来建立public到localhost的tunnel,让居于内网主机上的服务可以暴露给public,俗称内网穿透。
2、支持对隧道中数据的introspection(内省),支持可视化的观察隧道内数据,并replay(重放)相关请求(诸如http请 求)。

因此ngrok可以很便捷的协助进行服务端程序调试,尤其在进行一些Web server开发中。ngrok更强大的一点是它支持tcp层之上的所有应用协议或者说与应用层协议无关。比如:你可以通过ngrok实现ssh登录到内 网主 机,也可以通过ngrok实现远程桌面(VNC)方式访问内网主机。

今天我们就来简单分析一下这款强大工具的实现原理。ngrok本身是用go语言实现的,需要go 1.1以上版本编译。ngrok官方代码最新版为1.7,作者似乎已经完成了ngrok 2.0版本,但不知为何迟迟不放出最新代码。因此这里我们就以ngrok 1.7版本源码作为原理分析的基础。

一、ngrok tunnel与ngrok部署

网络tunnel(隧道)对多数人都是很”神秘“的概念,tunnel种类很多,没有标准定义,我了解的也不多(日常工作较少涉及),这里也就不 深入了。在《HTTP权威指南》中有关于HTTP tunnel(http上承载非web流量)和SSL tunnel的说明,但ngrok中的tunnel又与这些有所不同。

ngrok实现了一个tcp之上的端到端的tunnel,两端的程序在ngrok实现的Tunnel内透明的进行数据交互。

ngrok分为client端(ngrok)和服务端(ngrokd),实际使用中的部署如下:

内网服务程序可以与ngrok client部署在同一主机,也可以部署在内网可达的其他主机上。ngrok和ngrokd会为建立与public client间的专用通道(tunnel)。

二、ngrok开发调试环境搭建

在学习ngrok代码或试验ngrok功能的时候,我们可能需要搭建一个ngrok的开发调试环境。ngrok作者在ngrok developer guide中给出了步骤:

$> git clone https://github.com/inconshreveable/ngrok
$> cd ngrok
$> make client
$> make server

make client和make server执行后,会建构出ngrok和ngrokd的debug版本。如果要得到release版本,请使用make release-clientmake release-server。debug版本与release版本的区别在于debug版本不打包 assets下的资源文件,执行时通过文件系统访问。

修改/etc/hosts文件,添加两行:

127.0.0.1 ngrok.me
127.0.0.1 test.ngrok.me

创建客户端配置文件debug.yml:

server_addr: ngrok.me:4443
trust_host_root_certs: false
tunnels:
      test:
        proto:
           http: 8080

不过要想让ngrok与ngrokd顺利建立通信,我们还得制作数字证书(自签发),源码中自带的证书是无法使用的,证书制作方法可参见《搭建自 己的ngrok服务》一文,相关原理可参考《Go和HTTPS》一文,这里就不赘述了。

我直接使用的是release版本(放在bin/release下),这样在执行命令时可以少传入几个参数:

启动服务端:
$> sudo ./bin/release/ngrokd -domain ngrok.me
[05/13/15 17:15:37] [INFO] Listening for public http connections on [::]:80
[05/13/15 17:15:37] [INFO] Listening for public https connections on [::]:443
[05/13/15 17:15:37] [INFO] Listening for control and proxy connections on [::]:4443

启动客户端:
$> ./bin/release/ngrok -config=debug.yml -log=ngrok.log -subdomain=test 8080

有了调试环境,我们就可以通过debug日志验证我们的分析了。

ngrok的源码结构如下:

drwxr-xr-x   3 tony  staff  102  3 31 16:09 cache/
drwxr-xr-x  16 tony  staff  544  5 13 17:21 client/
drwxr-xr-x   4 tony  staff  136  5 13 15:02 conn/
drwxr-xr-x   3 tony  staff  102  3 31 16:09 log/
drwxr-xr-x   4 tony  staff  136  3 31 16:09 main/
drwxr-xr-x   5 tony  staff  170  5 12 16:17 msg/
drwxr-xr-x   5 tony  staff  170  3 31 16:09 proto/
drwxr-xr-x  11 tony  staff  374  5 13 17:21 server/
drwxr-xr-x   7 tony  staff  238  3 31 16:09 util/
drwxr-xr-x   3 tony  staff  102  3 31 16:09 version/

main目录下的ngrok/和ngrokd/分别是ngrok和ngrokd main包,main函数存放的位置,但这里仅仅是一个stub。以ngrok为例:

// ngrok/src/ngrok/main/ngrok/ngrok.go
package main

import (
    "ngrok/client"
)

func main() {
    client.Main()
}

真正的“main”被client包的Main函数实现。

client/和server/目录分别对应ngrok和ngrokd的主要逻辑,其他目录(或包)都是一些工具类的实现。

三、第一阶段:Control Connection建立

在ngrokd的启动日志中我们可以看到这样一行:

[INFO] Listening for control and proxy connections on [::]:4443

ngrokd在4443端口(默认)监听control和proxy connection。Control Connection,顾名思义“控制连接”,有些类似于FTP协议的控制连接(不知道ngrok作者在设计协议时是否参考了FTP协议^_^)。该连接 只用于收发控制类消息。作为客户端的ngrok启动后的第一件事就是与ngrokd建立Control Connection,建立过程序列图如下:

前面提到过,ngrok客户端的实际entrypoint在ngrok/src/ngrok/client目录下,包名client,实际入口是 client.Main函数。

//ngrok/src/ngrok/client/main.go
func Main() {
    // parse options
    // set up logging
    // read configuration file
    …. …
    NewController().Run(config)
}

ngrok采用了MVC模式构架代码,这既包括ngrok与ngrokd之间的逻辑处理,也包括ngrok本地web页面(用于隧道数据的 introspection)的处理。

//ngrok/src/ngrok/client/controller.go
func (ctl *Controller) Run(config *Configuration) {

    var model *ClientModel

    if ctl.model == nil {
        model = ctl.SetupModel(config)
    } else {
        model = ctl.model.(*ClientModel)
    }
    // init the model
    // init web ui
    // init term ui
   … …
   ctl.Go(ctl.model.Run)
   … …
  
}

我们来继续看看model.Run都做了些什么。

//ngrok/src/ngrok/client/model.go
func (c *ClientModel) Run() {
    … …

    for {
        // run the control channel
        c.control()
        … …
        if c.connStatus == mvc.ConnOnline {
            wait = 1 * time.Second
        }

        … …
        c.connStatus = mvc.ConnReconnecting
        c.update()
    }
}

Run函数调用c.control来运行Control Connection的主逻辑,并在control connection断开后,尝试重连。

c.control是ClientModel的一个method,用来真正建立ngrok到ngrokd的control connection,并完成基于ngrok的鉴权(用户名、密码配置在配置文件中)。

//ngrok/src/ngrok/client/model.go
func (c *ClientModel) control() {
    … …
    var (
        ctlConn conn.Conn
        err     error
    )
    if c.proxyUrl == "" {
        // simple non-proxied case, just connect to the server
        ctlConn, err = conn.Dial(c.serverAddr, "ctl", c.tlsConfig)
    } else {……}
    … …

    // authenticate with the server
    auth := &msg.Auth{
        ClientId:  c.id,
        OS:        runtime.GOOS,
        Arch:      runtime.GOARCH,
        Version:   version.Proto,
        MmVersion: version.MajorMinor(),
        User:      c.authToken,
    }

    if err = msg.WriteMsg(ctlConn, auth); err != nil {
        panic(err)
    }

    // wait for the server to authenticate us
    var authResp msg.AuthResp
    if err = msg.ReadMsgInto(ctlConn, &authResp); err != nil {
        panic(err)
    }

    … …

    c.id = authResp.ClientId
    … ..
}

ngrok封装了connection相关操作,代码在ngrok/src/ngrok/conn下面,包名conn。

//ngrok/src/ngrok/conn/conn.go
func Dial(addr, typ string, tlsCfg *tls.Config) (conn *loggedConn, err error) {
    var rawConn net.Conn
    if rawConn, err = net.Dial("tcp", addr); err != nil {
        return
    }

    conn = wrapConn(rawConn, typ)
    conn.Debug("New connection to: %v", rawConn.RemoteAddr())

    if tlsCfg != nil {
        conn.StartTLS(tlsCfg)
    }

    return
}

ngrok首先创建一条TCP连接,并基于该连接创建了TLS client:

func (c *loggedConn) StartTLS(tlsCfg *tls.Config) {
    c.Conn = tls.Client(c.Conn, tlsCfg)
}

不过此时并未进行TLS的初始化,即handshake。handshake发生在ngrok首次向ngrokd发送auth消息(msg.WriteMsg, ngrok/src/ngrok/msg/msg.go)时,go标准库的TLS相关函数默默的完成这一handshake过程。我们经常遇到的ngrok证书验证失败等问题,就发生在该过程中。

在AuthResp中,ngrokd为该Control Connection分配一个ClientID,该ClientID在后续Proxy Connection建立时使用,用于关联和校验之用。

前面的逻辑和代码都是ngrok客户端的,现在我们再从ngrokd server端代码review一遍Control Connection的建立过程。

ngrokd的代码放在ngrok/src/ngrok/server下面,entrypoint如下:

//ngrok/src/ngrok/server/main.go
func Main() {
    // parse options
    opts = parseArgs()
    // init logging
    // init tunnel/control registry
    … …
    // start listeners
    listeners = make(map[string]*conn.Listener)

    // load tls configuration
    tlsConfig, err := LoadTLSConfig(opts.tlsCrt, opts.tlsKey)
    if err != nil {
        panic(err)
    }
    // listen for http
    // listen for https
    … …

    // ngrok clients
    tunnelListener(opts.tunnelAddr, tlsConfig)
}

ngrokd启动了三个监听,其中最后一个tunnelListenner用于监听ngrok发起的Control Connection或者后续的proxy connection,作者意图通过一个端口,监听两种类型连接,旨在于方便部署。

//ngrok/src/ngrok/server/main.go
func tunnelListener(addr string, tlsConfig *tls.Config) {
    // listen for incoming connections
    listener, err := conn.Listen(addr, "tun", tlsConfig)
    … …

    for c := range listener.Conns {
        go func(tunnelConn conn.Conn) {
            … …
            var rawMsg msg.Message
            if rawMsg, err = msg.ReadMsg(tunnelConn); err != nil {
                tunnelConn.Warn("Failed to read message: %v", err)
                tunnelConn.Close()
                return
            }
            … …
            switch m := rawMsg.(type) {
            case *msg.Auth:
                NewControl(tunnelConn, m)
            … …
            }
        }(c)
    }
}

从tunnelListener可以看到,当ngrokd在新建立的Control Connection上收到Auth消息后,ngrokd执行NewControl来处理该Control Connection上的后续事情。

//ngrok/src/ngrok/server/control.go
func NewControl(ctlConn conn.Conn, authMsg *msg.Auth) {
    var err error

    // create the object
    c := &Control{
        … …
    }

    // register the clientid
    … …
    // register the control
    … …

    // start the writer first so that
    // the following messages get sent
    go c.writer()

    // Respond to authentication
    c.out <- &msg.AuthResp{
        Version:   version.Proto,
        MmVersion: version.MajorMinor(),
        ClientId:  c.id,
    }

    // As a performance optimization,
    // ask for a proxy connection up front
    c.out <- &msg.ReqProxy{}

    // manage the connection
    go c.manager()
    go c.reader()
    go c.stopper()
}

在NewControl中,ngrokd返回了AuthResp。到这里,一条新的Control Connection建立完毕。

我们最后再来看一下Control Connection建立过程时ngrok和ngrokd的输出日志,增强一下感性认知:

ngrok Server:

[INFO] [tun:d866234] New connection from 127.0.0.1:59949
[DEBG] [tun:d866234] Waiting to read message
[DEBG] [tun:d866234] Reading message with length: 126
[DEBG] [tun:d866234] Read message {"Type":"Auth",
"Payload":{"Version":"2","MmVersion":"1.7","User":"","Password":"","OS":"darwin","Arch":"amd64","ClientId":""}}
[INFO] [ctl:d866234] Renamed connection tun:d866234
[INFO] [registry] [ctl] Registered control with id ac1d14e0634f243f8a0cc2306bb466af
[DEBG] [ctl:d866234] [ac1d14e0634f243f8a0cc2306bb466af] Writing message: {"Type":"AuthResp","Payload":{"Version":"2","MmVersion":"1.7","ClientId":"ac1d14e0634f243f8a0cc2306bb466af","Error":""}}

Client:

[INFO] (ngrok/log.Info:112) Reading configuration file debug.yml
[INFO] (ngrok/log.(*PrefixLogger).Info:83) [client] Trusting root CAs: [assets/client/tls/ngrokroot.crt]
[INFO] (ngrok/log.(*PrefixLogger).Info:83) [view] [web] Serving web interface on 127.0.0.1:4040
[INFO] (ngrok/log.Info:112) Checking for update
[DEBG] (ngrok/log.(*PrefixLogger).Debug:79) [view] [term] Waiting for update
[DEBG] (ngrok/log.(*PrefixLogger).Debug:79) [ctl:31deb681] New connection to: 127.0.0.1:4443
[DEBG] (ngrok/log.(*PrefixLogger).Debug:79) [ctl:31deb681] Writing message: {"Type":"Auth","Payload":{"Version":"2","MmVersion":"1.7","User":"","Password":"","OS":"darwin","Arch":"amd64","ClientId":""}}
[DEBG] (ngrok/log.(*PrefixLogger).Debug:79) [ctl:31deb681] Waiting to read message
(ngrok/log.(*PrefixLogger).Debug:79) [ctl:31deb681] Reading message with length: 120
(ngrok/log.(*PrefixLogger).Debug:79) [ctl:31deb681] Read message {"Type":"AuthResp","Payload":{"Version":"2","MmVersion":"1.7","ClientId":"ac1d14e0634f243f8a0cc2306bb466af","Error":""}}
[INFO] (ngrok/log.(*PrefixLogger).Info:83) [client] Authenticated with server, client id: ac1d14e0634f243f8a0cc2306bb466af

四、Tunnel Creation

Tunnel Creation是ngrok将配置文件中的tunnel信息通过刚刚建立的Control Connection传输给 ngrokd,ngrokd登记、启动相应端口监听(如果配置了remote_port或多路复用ngrokd默认监听的http和https端口)并返回相应应答。ngrok和ngrokd之间并未真正建立新连接。

我们回到ngrok的model.go,继续看ClientModel的control方法。在收到AuthResp后,ngrok还做了如下事情:

//ngrok/src/ngrok/client/model.go
 
   // request tunnels
    reqIdToTunnelConfig := make(map[string]*TunnelConfiguration)
    for _, config := range c.tunnelConfig {
        // create the protocol list to ask for
        var protocols []string
        for proto, _ := range config.Protocols {
            protocols = append(protocols, proto)
        }

        reqTunnel := &msg.ReqTunnel{
            … …
        }

        // send the tunnel request
        if err = msg.WriteMsg(ctlConn, reqTunnel); err != nil {
            panic(err)
        }

        // save request id association so we know which local address
        // to proxy to later
        reqIdToTunnelConfig[reqTunnel.ReqId] = config
    }

    // main control loop
    for {
        var rawMsg msg.Message
       
        switch m := rawMsg.(type) {
        … …
        case *msg.NewTunnel:
            … …

            tunnel := mvc.Tunnel{
                … …
            }

            c.tunnels[tunnel.PublicUrl] = tunnel
            c.connStatus = mvc.ConnOnline
           
            c.update()
        … …
        }
    }

ngrok将配置的Tunnel信息逐一以ReqTunnel消息发送给ngrokd以注册登记Tunnel,并在随后的main control loop中处理ngrokd回送的NewTunnel消息,完成一些登记索引工作。

ngrokd Server端对tunnel creation的处理是在NewControl的结尾处:

//ngrok/src/ngrok/server/control.go
func NewControl(ctlConn conn.Conn, authMsg *msg.Auth) {
    … …
    // manage the connection
    go c.manager()
    … …
}

func (c *Control) manager() {
    //… …

    for {
        select {
        case <-reap.C:
            … …

        case mRaw, ok := <-c.in:
            // c.in closes to indicate shutdown
            if !ok {
                return
            }

            switch m := mRaw.(type) {
            case *msg.ReqTunnel:
                c.registerTunnel(m)

            .. …
            }
        }
    }
}

Control的manager在收到ngrok发来的ReqTunnel消息后,调用registerTunnel进行处理。

// ngrok/src/ngrok/server/control.go
// Register a new tunnel on this control connection
func (c *Control) registerTunnel(rawTunnelReq *msg.ReqTunnel) {
    for _, proto := range strings.Split(rawTunnelReq.Protocol, "+") {
        tunnelReq := *rawTunnelReq
        tunnelReq.Protocol = proto

        c.conn.Debug("Registering new tunnel")
        t, err := NewTunnel(&tunnelReq, c)
        if err != nil {
            c.out <- &msg.NewTunnel{Error: err.Error()}
            if len(c.tunnels) == 0 {
                c.shutdown.Begin()
            }

            // we're done
            return
        }

        // add it to the list of tunnels
        c.tunnels = append(c.tunnels, t)

        // acknowledge success
        c.out <- &msg.NewTunnel{
            Url:      t.url,
            Protocol: proto,
            ReqId:    rawTunnelReq.ReqId,
        }

        rawTunnelReq.Hostname = strings.Replace(t.url, proto+"://", "", 1)
    }
}

Server端创建tunnel的实际工作由NewTunnel完成:

// ngrok/src/ngrok/server/tunnel.go
func NewTunnel(m *msg.ReqTunnel, ctl *Control) (t *Tunnel, err error) {
    t = &Tunnel{
      … …
    }

    proto := t.req.Protocol
    switch proto {
    case "tcp":
        bindTcp := func(port int) error {
            if t.listener, err = net.ListenTCP("tcp",
               &net.TCPAddr{IP: net.ParseIP("0.0.0.0"),
               Port: port}); err != nil {
                … …
                return err
            }

            // create the url
            addr := t.listener.Addr().(*net.TCPAddr)
            t.url = fmt.Sprintf("tcp://%s:%d", opts.domain, addr.Port)

            // register it
            if err = tunnelRegistry.RegisterAndCache(t.url, t);
               err != nil {
                … …
                return err
            }

            go t.listenTcp(t.listener)
            return nil
        }

        // use the custom remote port you asked for
        if t.req.RemotePort != 0 {
            bindTcp(int(t.req.RemotePort))
            return
        }
        // try to return to you the same port you had before
        cachedUrl := tunnelRegistry.GetCachedRegistration(t)
        if cachedUrl != "" {
            … …
        }

        // Bind for TCP connections
        bindTcp(0)
        return

    case "http", "https":
        l, ok := listeners[proto]
        if !ok {
            … …
            return
        }

        if err = registerVhost(t, proto, l.Addr.(*net.TCPAddr).Port);
           err != nil {
            return
        }

    default:
        err = fmt.Errorf("Protocol %s is not supported", proto)
        return
    }

    … …

    metrics.OpenTunnel(t)
    return
}

可以看出,NewTunnel区别对待tcp和http/https隧道:

- 对于Tcp隧道,NewTunnel先要看是否配置了remote_port,如果remote_port不为空,则启动监听这个 remote_port。否则尝试从cache里找出你之前创建tunnel时使用的端口号,如果可用,则监听这个端口号,否则bindTcp(0),即 随机选择一个端口作为该tcp tunnel的remote_port。

- 对于http/https隧道,ngrokd启动时就默认监听了80和443,如果ngrok请求建立http/https隧道(目前不支持设置remote_port),则ngrokd通过一种自实现的vhost的机制实现所有http/https请求多路复用到80和443端口上。ngrokd不会新增监听端口。

从下面例子,我们也可以看出一些端倪。我们将debug.yml改为:

server_addr: ngrok.me:4443
trust_host_root_certs: false
tunnels:
      test:
        proto:
           http: 8080
      test1:
        proto:
           http: 8081
      ssh1:
        remote_port: 50000
        proto:
            tcp: 22
      ssh2:
        proto:
            tcp: 22

启动ngrok:

$./bin/release/ngrok -config=debug.yml -log=ngrok.log start test test1  ssh1 ssh2

Tunnel Status                 online
Version                       1.7/1.7
Forwarding                    tcp://ngrok.me:50000 -> 127.0.0.1:22
Forwarding                    tcp://ngrok.me:56297 -> 127.0.0.1:22
Forwarding                    http://test.ngrok.me -> 127.0.0.1:8080
Forwarding                    http://test1.ngrok.me -> 127.0.0.1:8081
Web Interface                 127.0.0.1:4040

可以看出ngrokd为ssh2随机挑选了一个端口56297进行了监听,而两个http隧道,则都默认使用了80端口。

如果像下面这样配置会发生什么呢?

      ssh1:
        remote_port: 50000
        proto:
            tcp: 22
      ssh2:
        remote_port: 50000
        proto:
            tcp: 22

ngrok启动会得到错误信息:
Server failed to allocate tunnel: [ctl:5332a293] [a87bd111bcc804508c835714c18a5664] Error binding TCP listener: listen tcp 0.0.0.0:50000: bind: address already in use

客户端ngrok在ClientModel control方法的main control loop中收到NewTunnel并处理该消息:

    case *msg.NewTunnel:
            if m.Error != "" {
                … …
            }

            tunnel := mvc.Tunnel{
                PublicUrl: m.Url,
                LocalAddr: reqIdToTunnelConfig[m.ReqId].Protocols[m.Protocol],
                Protocol:  c.protoMap[m.Protocol],
            }

            c.tunnels[tunnel.PublicUrl] = tunnel
            c.connStatus = mvc.ConnOnline
            c.Info("Tunnel established at %v", tunnel.PublicUrl)
            c.update()

五、Proxy Connection和Private Connection

到目前为止,我们知道了Control Connection:用于ngrok和ngrokd之间传输命令;Public Connection:外部发起的,尝试向内网服务建立的链接。

这节当中,我们要接触到Proxy Connection和Private Connection。

Proxy Connection以及Private Connection的建立过程如下:

前面ngrok和ngrokd的交互进行到了NewTunnel,这些数据都是通过之前已经建立的Control Connection上传输的。

ngrokd侧,NewControl方法的结尾有这样一行代码:

    // As a performance optimization, ask for a proxy connection up front
    c.out <- &msg.ReqProxy{}

服务端ngrokd在Control Connection上向ngrok发送了"ReqProxy"的消息,意为请求ngrok向ngrokd建立一条Proxy Connection,该链接将作为隧道数据流的承载者。

客户端ngrok在ClientModel control方法的main control loop中收到ReqProxy并处理该消息:

case *msg.ReqProxy:
            c.ctl.Go(c.proxy)

// Establishes and manages a tunnel proxy connection with the server
func (c *ClientModel) proxy() {
    if c.proxyUrl == "" {
        remoteConn, err = conn.Dial(c.serverAddr, "pxy", c.tlsConfig)
    }……

    err = msg.WriteMsg(remoteConn, &msg.RegProxy{ClientId: c.id})
    if err != nil {
        remoteConn.Error("Failed to write RegProxy: %v", err)
        return
    }
    … …
}

ngrok客户端收到ReqProxy后,创建一条新连接到ngrokd,该连接即为Proxy Connection。并且ngrok将RegProxy消息通过该新建立的Proxy Connection发到ngrokd,以便ngrokd将该Proxy Connection与对应的Control Connection以及tunnel关联在一起。

// ngrok服务端
func tunnelListener(addr string, tlsConfig *tls.Config) {
    …. …
    case *msg.RegProxy:
                NewProxy(tunnelConn, m)
    … …
}

到目前为止, tunnel、Proxy Connection都已经建立了,万事俱备,就等待Public发起Public connection到ngrokd了。

下面我们以Public发起一个http连接到ngrokd为例,比如我们通过curl 命令,向test.ngrok.me发起一次http请求。

前面说过,ngrokd在启动时默认启动了80和443端口的监听,并且与其他http/https隧道共同多路复用该端口(通过vhost机制)。ngrokd server对80端口的处理代码如下:

// ngrok/src/ngrok/server/main.go
func Main() {
    … …
 // listen for http
    if opts.httpAddr != "" {
        listeners["http"] =
          startHttpListener(opts.httpAddr, nil)
    }

    … …
}

startHttpListener针对每个连接,启动一个goroutine专门处理:

//ngrok/src/ngrok/server/http.go
func startHttpListener(addr string,
    tlsCfg *tls.Config) (listener *conn.Listener) {
    // bind/listen for incoming connections
    var err error
    if listener, err = conn.Listen(addr, "pub", tlsCfg);
        err != nil {
        panic(err)
    }

    proto := "http"
    if tlsCfg != nil {
        proto = "https"
    }

   … …
    go func() {
        for conn := range listener.Conns {
            go httpHandler(conn, proto)
        }
    }()

    return
}

// Handles a new http connection from the public internet
func httpHandler(c conn.Conn, proto string) {
    … …
    // let the tunnel handle the connection now
    tunnel.HandlePublicConnection(c)
}

我们终于看到server端处理public connection的真正方法了:

//ngrok/src/ngrok/server/tunnel.go
func (t *Tunnel) HandlePublicConnection(publicConn conn.Conn) {
    … …
    var proxyConn conn.Conn
    var err error
    for i := 0; i < (2 * proxyMaxPoolSize); i++ {
        // get a proxy connection
        if proxyConn, err = t.ctl.GetProxy();
           err != nil {
            … …
        }
        defer proxyConn.Close()
       … …

        // tell the client we're going to
        // start using this proxy connection
        startPxyMsg := &msg.StartProxy{
            Url:        t.url,
            ClientAddr: publicConn.RemoteAddr().String(),
        }

        if err = msg.WriteMsg(proxyConn, startPxyMsg);
            err != nil {
           … …
        }
    }

    … …
    // join the public and proxy connections
    bytesIn, bytesOut := conn.Join(publicConn, proxyConn)
    …. …
}

HandlePublicConnection通过选出的Proxy connection向ngrok client发送StartProxy信息,告知ngrok proxy启动。然后通过conn.Join方法将publicConn和proxyConn关联到一起。

// ngrok/src/ngrok/conn/conn.go
func Join(c Conn, c2 Conn) (int64, int64) {
    var wait sync.WaitGroup

    pipe := func(to Conn, from Conn, bytesCopied *int64) {
        defer to.Close()
        defer from.Close()
        defer wait.Done()

        var err error
        *bytesCopied, err = io.Copy(to, from)
        if err != nil {
            from.Warn("Copied %d bytes to %s before failing with error %v", *bytesCopied, to.Id(), err)
        } else {
            from.Debug("Copied %d bytes to %s", *bytesCopied, to.Id())
        }
    }

    wait.Add(2)
    var fromBytes, toBytes int64
    go pipe(c, c2, &fromBytes)
    go pipe(c2, c, &toBytes)
    c.Info("Joined with connection %s", c2.Id())
    wait.Wait()
    return fromBytes, toBytes
}

Join通过io.Copy实现public conn和proxy conn数据流的转发,单向被称作一个pipe,Join建立了两个Pipe,实现了双向转发,每个Pipe直到一方返回EOF或异常失败才会退出。后续在ngrok端,proxy conn和private conn也是通过conn.Join关联到一起的。

我们现在就来看看ngrok在收到StartProxy消息后是如何处理的。我们回到ClientModel的proxy方法中。在向ngrokd成功建立proxy connection后,ngrok等待ngrokd的StartProxy指令。

    // wait for the server to ack our register
    var startPxy msg.StartProxy
    if err = msg.ReadMsgInto(remoteConn, &startPxy);
             err != nil {
        remoteConn.Error("Server failed to write StartProxy: %v",
                   err)
        return
    }

一旦收到StartProxy,ngrok将建立一条private connection:
    // start up the private connection
    start := time.Now()
    localConn, err := conn.Dial(tunnel.LocalAddr, "prv", nil)
    if err != nil {
       … …
        return
    }
并将private connection和proxy connection通过conn.Join关联在一起,实现数据透明转发。

    m.connTimer.Time(func() {
        localConn := tunnel.Protocol.WrapConn(localConn,
             mvc.ConnectionContext{Tunnel: tunnel,
              ClientAddr: startPxy.ClientAddr})
        bytesIn, bytesOut := conn.Join(localConn, remoteConn)
        m.bytesIn.Update(bytesIn)
        m.bytesOut.Update(bytesOut)
        m.bytesInCount.Inc(bytesIn)
        m.bytesOutCount.Inc(bytesOut)
    })

这样一来,public connection上的数据通过proxy connection到达ngrok,ngrok再通过private connection将数据转发给本地启动的服务程序,从而实现所谓的内网穿透。从public视角来看,就像是与内网中的那个服务直接交互一样。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats