HTTP streaming support listening at both IPv4 and IPv6

[ChowDPa02k]

Note: Please read FAQ before file an issue, see #2716

Description

Please description your issue here

1. SRS Version: 6.0.59(Bee) Windows Build

2. SRS Log:

[2023-07-22 20:11:38.163][WARN][2025][al8g3399][0] stats network use index=0, ip=192.168.1.10, ifname={404977E6-A52A-4A91-8D9A-956076CEE4F4}
[2023-07-22 20:11:38.163][WARN][2025][al8g3399][0] stats disk not configed, disk iops disabled.
[2023-07-22 20:11:38.163][INFO][2025][al8g3399] write log to console
[2023-07-22 20:11:38.163][INFO][2025][al8g3399] features, rch:on, dash:on, hls:on, hds:off, srt:off, hc:on, ha:on, hs:on, hp:on, dvr:on, trans:on, inge:on, stat:on, sc:on
[2023-07-22 20:11:38.164][INFO][2025][al8g3399] SRS on amd64 x86_64, conf:conf\live.conf, limit:1000, writev:1024, encoding:little-endian, HZ:1000
[2023-07-22 20:11:38.164][INFO][2025][al8g3399] mw sleep:350ms. mr enabled:on, default:0, sleep:350ms
[2023-07-22 20:11:38.164][INFO][2025][al8g3399] gc:on, pq:30000ms, cscc:[0,16), csa:on, tn:on(may hurts performance), ss:auto(guess by merged write)
[2023-07-22 20:11:38.164][INFO][2025][al8g3399] system default latency(ms): mw(0-350) + mr(0-350) + play-queue(0-30000)
[2023-07-22 20:11:38.164][WARN][2025][al8g3399][0] SRS/6.0.59 is not stable
[2023-07-22 20:11:38.164][INFO][2025][al8g3399] Run in single thread mode
[2023-07-22 20:11:38.168][INFO][2025][al8g3399] fingerprint=47:9E:E9:E2:6E:70:99:BF:27:F9:65:9F:4F:99:C4:14:69:34:DE:67:58:B7:04:BD:5D:71:32:01:E2:1A:5E:81
[2023-07-22 20:11:38.168][INFO][2025][al8g3399] CircuitBreaker: enabled=1, high=2x90, critical=1x95, dying=5x99
[2023-07-22 20:11:38.169][INFO][2025][al8g3399] http flv live stream, vhost=__defaultVhost__, mount=[vhost]/[app]/[stream].flv
[2023-07-22 20:11:38.169][INFO][2025][al8g3399] http: root mount to ./objs/nginx/html
[2023-07-22 20:11:38.169][INFO][2025][al8g3399] server main cid=al8g3399, pid=2025, ppid=1, asprocess=0
[2023-07-22 20:11:38.170][WARN][2025][al8g3399][22] SO_REUSEPORT is not supported util Linux kernel 3.9
[2023-07-22 20:11:38.170][INFO][2025][al8g3399] RTMP listen at tcp://0.0.0.0:1935, fd=6
[2023-07-22 20:11:38.170][WARN][2025][al8g3399][22] SO_REUSEPORT is not supported util Linux kernel 3.9
[2023-07-22 20:11:38.170][INFO][2025][al8g3399] RTMP listen at tcp://:::1935, fd=7
[2023-07-22 20:11:38.171][WARN][2025][al8g3399][22] SO_REUSEPORT is not supported util Linux kernel 3.9
[2023-07-22 20:11:38.171][INFO][2025][al8g3399] HTTP-API listen at tcp://0.0.0.0:1985, fd=8
[2023-07-22 20:11:38.171][WARN][2025][al8g3399][22] SO_REUSEPORT is not supported util Linux kernel 3.9
[2023-07-22 20:11:38.171][INFO][2025][al8g3399] HTTP-Server listen at tcp://0.0.0.0:8080, fd=9
[2023-07-22 20:11:38.171][INFO][2025][al8g3399] signal installed, reload=1, reopen=30, fast_quit=15, grace_quit=3
[2023-07-22 20:11:38.171][INFO][2025][al8g3399] http: api mount /console to ./objs/nginx/html/console
[2023-07-22 20:11:38.171][WARN][2025][al8g3399][22] SO_REUSEPORT is not supported util Linux kernel 3.9
[2023-07-22 20:11:38.171][INFO][2025][al8g3399] rtc listen at udp://0.0.0.0:8000, fd=10
[2023-07-22 20:11:38.183][INFO][2025][5665o2f9] Hybrid cpu=0.00%,22MB
[2023-07-22 20:11:38.183][WARN][2025][3637725h][22] use public address as ip: 240e:3b5:34e0:ad40::14, ifname={404977E6-A52A-4A91-8D9A-956076CEE4F4}
[2023-07-22 20:11:38.183][INFO][2025][3637725h] Startup query id=vid-315tn45, session=vid-5j902dd, eip=240e:3b5:34e0:ad40::14, wait=300s
[2023-07-22 20:11:38.183][INFO][2025][jwb80338] TCP: connection manager run, conns=0
[2023-07-22 20:11:38.525][INFO][2025][45l315j1] GB: connection manager run, conns=0
[2023-07-22 20:11:38.525][INFO][2025][6170bg9z] UDP #10 LISTEN at 0.0.0.0:8000, SO_SNDBUF(default=65536, expect=10485760, actual=10485760, r0=0), SO_RCVBUF(default=65536, expect=10485760, actual=10485760, r0=0)
[2023-07-22 20:11:38.525][INFO][2025][2se20893] RTC: connection manager run, conns=0

3. SRS Config:

listen              1935 [::]:1935;
max_connections     1000;
srs_log_tank        console;
daemon              off;

http_api {
    enabled         on;
    listen          1985 [::]:1985;
}

http_server {
    enabled         on;
    listen          8080 [::]:8080;
    dir             ./objs/nginx/html;
}

Replay

Please describe how to replay the bug?

Step 1: Change http_server listen port to the following:

http_server {
    enabled         on;
    listen          [::]:8080;
    listen          8080;
    dir             ./objs/nginx/html;
}

Use network analytics tool, to see SRS listen IPV6 only:

And cannot access srs player or srs console via 127.0.0.1:8080, but from IPV6 can do.

Step 2: Change http_server listen port to the following:

http_server {
    enabled         on;
    listen          8080 [::]:8080;
    dir             ./objs/nginx/html;
}

Use network analytics tool, to see SRS listen IPV4 only:

And cannot play http-flv by using address like http://[ipv6:add:ress::]:8080/live/livestream.flv, but from IPV4 can do.

Step 3: Change http_server listen port to the following:

http_server {
    enabled         on;
    listen          [::]:8080 8080;
    dir             ./objs/nginx/html;
}

Use network analytics tool, to see SRS listen IPV6 only:

Expect

We have a demand that getting HTTP-FLV stream from both tcp46, sometimes accessing via IP address only.

To be clear, primary connect from NAT traverse solution like Zerotier, but sometimes it will fail, then we connect SRS using alternative IPV6 Address directly. With the IPV6-only connection, HTTP-server listening at tcp4 won't work.

Throughout our tests, flv.js is the closest approach to real-time playback (except webrtc). When HTTP-server failed to directly connect ipv6 address, we have to use 3rd party player (e.g. VLC) to play RTMP, which will always 0.5s slower than flv.js.

[winlinvip]

We need to refine the endpoint discovering for listening. This technique means allow user listening at IPv4, IPv6, IPv4+IPv6 endpoints. But there are some bugs about this feature. Any patch is welcome.

[suzp1984]

srs/trunk/src/app/srs_app_server.cpp

Lines 333 to 338 in 427104f

	rtmp_listener_ = new SrsMultipleTcpListeners(this);
	api_listener_ = new SrsTcpListener(this);
	apis_listener_ = new SrsTcpListener(this);
	http_listener_ = new SrsTcpListener(this);
	https_listener_ = new SrsTcpListener(this);
	webrtc_listener_ = new SrsTcpListener(this);

rtmp already supported listen multi endpoints, use SrsMultipleTcpListeners to replace the SrsTcpListener will resolve this issue I guess.
Look the differences between SrsMultipleTcpListeners and SrsTcpListener:

srs/trunk/src/app/srs_app_server.cpp

Lines 574 to 590 in 427104f

	// Create RTMP listeners.
	rtmp_listener_->add(_srs_config->get_listens())->set_label("RTMP");
	if ((err = rtmp_listener_->listen()) != srs_success) {
	return srs_error_wrap(err, "rtmp listen");
	}
	// Create HTTP API listener.
	if (_srs_config->get_http_api_enabled()) {
	if (reuse_api_over_server_) {
	srs_trace("HTTP-API: Reuse listen to http server %s", _srs_config->get_http_stream_listen().c_str());
	} else {
	api_listener_->set_endpoint(_srs_config->get_http_api_listen())->set_label("HTTP-API");
	if ((err = api_listener_->listen()) != srs_success) {
	return srs_error_wrap(err, "http api listen");
	}
	}
	}

The SrsConfig::get_http_api_listen & string SrsConfig::get_http_stream_listen() also need to refactor to return a vec rather the first arg.

srs/trunk/src/app/srs_app_config.cpp

Lines 7641 to 7659 in 427104f

	string SrsConfig::get_http_api_listen()
	{
	SRS_OVERWRITE_BY_ENV_STRING("srs.http_api.listen"); // SRS_HTTP_API_LISTEN
	static string DEFAULT = "1985";
	SrsConfDirective* conf = root->get("http_api");
	if (!conf) {
	return DEFAULT;
	}
	conf = conf->get("listen");
	if (!conf || conf->arg0().empty()) {
	return DEFAULT;
	}
	return conf->arg0();
	}

[winlinvip]

@suzp1984 Yep, you are correct. With the multiple listener using a vector of ports, we can fix this issue, while also considering the bellow issues:

1. Listen at port, supported already.
2. Listen at port0, port1, ..., portN, partially supported.
3. Listen at ip0:port0, ip1:port1, ..., ipN:portN, I'm not sure.

We need to support a comprehensive solution about listening. Welcome to file a pullrequest about this feature, at where we can discuss the details.