[feature] TCP proxy supporting

[benja-wu]

Background

• Easegress works as an L7-level proxy with multiple useful features. But it can't work as an L4-level proxy.

Requirement

• Make Easegress as an L4-level proxy as well

Discussion

Question 1: Which kind of instance should this feature belong to?

• Currently, Easegress has a big catalog as TafficGate for specified application protocols, such as HTTP, MQTT, and WebSocket.
• There is a system-level controller called TrafficController, which manages HTTP-protocol-based HTTPServer and Pipeline by namespace.

Propose to add a new TCPProxy as HTTPServer. Other application level protocol implementations which are using TCP connection directly can be benefited from this TCPProxy managed by TrafficController

Question 2: Are there some awesome, open-sourced packages can we directly import？

• The goproxy[1] seems to be a quite popular proxy implemented in Golang.

Question 3: How many basic features should a TCP proxy supported?

• TLS supporting: multiple certificates supporting?
• Multiple backends load-balancing: Round Robin, Weight Round Robin, Random...?
• Timeout: sending timeout, connection timeout, receiving timeout?
• Limited connection: reusing NewLimitListener in Easegress's util pkg?

Propose to confirm the TCPProxy spec firstly. In this spec, it should have a load balance type, listening port, backend array, TLS certificate encoding in base64, and so on...

Question 4: Should we introduce these advanced features in the future?

• Health checking: such as NGINX[3]
• Failover: such as Google Cloud balancing[4]
  .....

Summary

• This is a draft design for the opening discussion. It's welcome to join us for telling your requirements and user scenarios, and let's figure out the basic, core features it should have together. Since Easegress is focusing on modern traffic orchestrating, some nice-to-have advanced feature we can hold it on and plan it implemented in the future.
• Once we come to a Version 1 conclusion for this TCPProxy, PR for this implementation is also welcomed!

References

1. https://github.com/snail007/goproxy
2. https://doc.traefik.io/traefik/routing/services/
3. https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-health-check/
4. https://cloud.google.com/load-balancing/docs/tcp

[benja-wu]

@jxd134 @siaron
Maybe we can figure out the design here together. :-)

[jxd134]

(1) we should seperate tcp/udp proxy with httpserver.
(2) we can use http balance method for tcp/udp proxy (expect headerhash);
(3) there is no need to add tcp/udp pipeline like httppipeline right now;
(4) which indicators of tcp/udp are counted? eg: connection num/send/recv bytes/packet num;
(5)health check is invalid for tpc/udp proxy.

[ccwxl]

Question 3: These are very useful function support.
What easegress has some introductory materials for developers. I just started go language .thanks

[benja-wu]

Question 3: These are very useful function support.
What easegress has some introductory materials for developers. I just started go language .thanks

Yes, here is an Easegress development guide.

[nevill]

We have to discuss the spec first. Let me think of an example for this feature.

kind: TCPServer
name: server-demo
port: 10080
rules:
    backend: tcp-demo

---

name: tcp-demo
kind: TCPPipeline
flow:
  - filter: proxy
filters:
  - name: proxy
    kind: TCPProxy
    mainPool:
      servers:
      - url: tcp://127.0.0.1:9095
      - url: tcp://127.0.0.1:9096
      - url: tcp://127.0.0.1:9097

Or, even we can have TCP servers behind HTTPServer, like

kind: HTTPServer
name: server-demo
port: 10080
keepAlive: true
https: false
rules:
  - paths:
    - pathPrefix: /pipeline
      backend: tcp-demo

---

name: tcp-demo
kind: TCPPipeline
flow:
  - filter: proxy
filters:
  - name: proxy
    kind: TCPProxy
    mainPool:
      servers:
      - url: tcp://127.0.0.1:9095
      - url: tcp://127.0.0.1:9096
      - url: tcp://127.0.0.1:9097

[jxd134]

@nevill My implementation tends to be the second.
HttpPipeline unable to adapt to tcp bidirectional stream.
Now what is confused is how the tcp data stream is passed in the filters.

The handler I designed is as follows（like netty）：

type (
	// Layer4Handler is the common handler for the all backends
	// which handle the traffic from layer4(tcp/udp) server.
	Layer4Handler interface {
		InboundHandler(ctx context.Layer4Context, object interface{})
		OutboundHandler(ctx context.Layer4Context, object interface{})
	}

	// Layer4MuxMapper gets layer4 handler pipeline with mutex
	Layer4MuxMapper interface {
		GetHandler(name string) (Layer4Handler, bool)
	}
)

[xxx7xxxx]

We will hold the 4-layer traffic support until imminent requirement.

[jigarpatel1007]

Really exciting direction here — thanks for opening this.

I’d like to second the value of native TCP proxy support, especially for telecom or BSS platforms where L4 traffic (SCTP/TCP-based protocols, custom charging interfaces, etc.) are common.

---

💡 Suggestion: “TCPProxy Lite” Initial Scope (Prioritizing Real-World Use)

Since the full TCPProxy filter and pipeline system is still conceptual, maybe we could define a minimal “Phase 1” spec to start delivering real value and get early feedback:

Proposal: kind: TCPProxyLite

name: basic-tcp-proxy
kind: TCPProxyLite
port: 15000
backends:
  - 127.0.0.1:8081
  - 127.0.0.1:8082
lbStrategy: round-robin
connectionTimeout: 30s

Let me know if a scoped MVP like TCPProxyLite would be welcome — happy to help outline a real-world use case from telecom traffic patterns.