ngrok支持tcp tunnel和http以及https,但是ngrok的tcp代理似乎优化不够好,当一段时间闲置tcp连接的话,再连接会出现连接不上的问题。

首先来看看ngrok的tcp tunnel的原理: 假设ngrok的client端配置文件如下

#填写服务器域名和连接端口
server_addr: ngrok.domain.com:4444
trust_host_root_certs: false
tunnels:
 adb:
 #这里的remote_port是指从ngrok.domain.com:5555->被代理端的5555端口
  remote_port: 5555
  proto:
  #使用tcp协议
   tcp: 5555
sequenceDiagram
被代理端-->ngrok client: \n
ngrok client->>ngrok server: 连接请求tls
ngrok server->>ngrok client: 鉴定确认连接请求tls
ngrok client->>被代理端: 建立tcp连接
ngrok client->>ngrok server: 请求监听5555端口
ngrok server->>ngrok client: 已经监听5555端口
用户端->>ngrok server: 建立和ngrok server的5555端口的tcp连接
ngrok server->>ngrok client: 请求ngrok client建立连接
ngrok client->>ngrok server: 建立专门用于5555的tcp连接
ngrok client->>被代理端: 传输来自sever 5555 tcp连接的流量到被代理端

可以发现一共三条tcp连接,一条是被代理端到ngrok client的和ngrok client到ngrok server端的

还有就是用户端到ngrok server的。

代码原理就是把流量透传,位于ngrok代码的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
}

利用两个go 执行方法,io.Copy(to,from)传输流量。 但是这样子闲置tcp连接一段时间的话,这三条tcp连接都有可能因为路由网络问题,其实已经断开了,但是linux服务没有响应过来。

我们怎么解决呢?业界的做法是用心跳包,但是别忘了,这里的三个tcp连接都是透明传输的,因此没有任何额外的心跳包协议可以定义。不能修改和增加任何tcp的流量包。

这时候我们可以用keepalive,这是在TCP中一个可以检测死连接的机制。

工作原理是:摘自百度百科 keepalive原理很简单,TCP会在空闲了一定时间后发送数据给对方: 1.如果主机可达,对方就会响应ACK应答,就认为是存活的。 2.如果可达,但应用程序退出,对方就发FIN应答,发送TCP撤消连接。 3.如果可达,但应用程序崩溃,对方就发RST消息。 4.如果对方主机不响应ack, rst,继续发送直到超时,就撤消连接。这个时间就是默认 的二个小时。

linux的默认keepalive时间是2小时。所以我们需要在代码里加上。

检查了下ngrok的监听连接代码:conn/conn.go

func Listen(addr, typ string, tlsCfg *tls.Config) (l *Listener, err error) {
	// listen for incoming connections
	listener, err := net.Listen("tcp", addr)
	if err != nil {
		return
	}

	l = &Listener{
		Addr:  listener.Addr(),
		Conns: make(chan *loggedConn),
	}

	go func() {
		for {
			rawConn, err := listener.Accept()
      if err != nil {
				log.Error("Failed to accept new TCP connection of type %s: %v", typ, err)
				continue
			}

			c := wrapConn(rawConn, typ)
			if tlsCfg != nil {
				c.Conn = tls.Server(c.Conn, tlsCfg)
			}
			c.Info("New connection from %v", c.RemoteAddr())
			l.Conns <- c

发现没有做keepAlive处理

因此在rawConn, err := listener.Accept()之后增加keepAlive代码。

if rawConn, ok := rawConn.(*net.TCPConn); ok {
				err := rawConn.SetKeepAlive(true)
				if err != nil {
					fmt.Println(err.Error())
				}
				err = rawConn.SetKeepAlivePeriod(time.Minute)
				if err != nil {
					fmt.Println(err.Error())
				}
			}

同样找到另一段代码:位于server/tunnel.go

/ Listens for new public tcp connections from the internet.
func (t *Tunnel) listenTcp(listener *net.TCPListener) {
	for {
		defer func() {
			if r := recover(); r != nil {
				log.Warn("listenTcp failed with error %v", r)
			}
		}()

		// accept public connections
		tcpConn, err := listener.AcceptTCP()

		if err != nil {
			// not an error, we're shutting down this tunnel
			if atomic.LoadInt32(&t.closing) == 1 {
				return
			}

			t.Error("Failed to accept new TCP connection: %v", err)
			continue
		}
		conn := conn.Wrap(tcpConn, "pub")
		conn.AddLogPrefix(t.Id())
		conn.Info("New connection from %v", conn.RemoteAddr())

		go t.HandlePublicConnection(conn)

同样需要在AcceptTCP之后增加keepalive设置

err1 := tcpConn.SetKeepAlive(true)
		if err1 != nil {
			fmt.Println(err1.Error())
		}
		err2 := tcpConn.SetKeepAlivePeriod(time.Minute)
		if err2 != nil {
			fmt.Println(err2.Error())
		}

全部补上之后,重新编译server和client,发现tcp连接即时好长一段时间不使用也没有问题。