search

ossrs / srs

SRS is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181.
https://ossrs.io
MIT License
25.45k stars 5.35k forks source link

HTTP streaming support listening at both IPv4 and IPv6 #3701

Open ChowDPa02k opened 1 year ago

ChowDPa02k commented 1 year ago

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
  1. 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:

image

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:

image

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:

image

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 commented 6 months ago

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 commented 6 months ago

https://github.com/ossrs/srs/blob/427104f1dab86f5afc7d7b49b02ed27d03ef9346/trunk/src/app/srs_app_server.cpp#L333-L338 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: https://github.com/ossrs/srs/blob/427104f1dab86f5afc7d7b49b02ed27d03ef9346/trunk/src/app/srs_app_server.cpp#L574-L590

The SrsConfig::get_http_api_listen & string SrsConfig::get_http_stream_listen() also need to refactor to return a vec rather the first arg. https://github.com/ossrs/srs/blob/427104f1dab86f5afc7d7b49b02ed27d03ef9346/trunk/src/app/srs_app_config.cpp#L7641-L7659

winlinvip commented 5 months ago

@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.