RTMP(Real Time Messaging Protocol) + HLS 으로 실시간 방송 구현하기(기초 구성) - 1

구현 전 사전 간단한 개념.


1. RTMP(Real-Time Messaging Protocol) 

    1-1. 역할

        - 실시간 오디오/비디오 데이터를 Client -> Server 로 전달 하기 위한 전송 프로토콜

    1-2. 네트워크 특성

        - 기본 포트 : 1935

        - TCP 기반 연결 (지속 연결과 신뢰성 우선)

    1-3. 전송 방식

        - Push 방식

        - Client(OBS-RTMP)가 Server로 밀어 넣음

    1-4. 한계

        - 일부 브라우저 에선 직접 재생 불가 Safari에선 가능하지만 다른 브라우저는 hls.js로 화면을 송출 해야함.


2. NGINX-RTMP-MODULE

    2-1. 역할

        - RTMP Stream을 받아들이는 ingest Server

    2-2. 기능

        - RTMP 연결 수신 (listen 1935)

        - Stream Session 관리(Application, Stream Key)

        - Stream Life Cycle 관리 (on_publish, on_done, on_pley)

        - RTMP -> HLS 패키징(ts 기반)를 nginx-rtmp-module이 자체적으로 수행 가능(DASH 패키징은 불가능)

    2-3. FFmpeg 연동

        - exec 지시자를 통해 외부 FFmpeg 프로세스 실행

        - RTMP ingest 이후 트랜스코딩/재패키징을 외부로 위임 가능

        - NGINX-RTMP-MODULE 내에서 연동은 가능하지만 FFmpeg는 따로 컨테이너를 띄우는 방식으로 함.

    2-3. 한계

        - 인코딩 없음

        - 트랜스코딩 없음

        - DASH / CMAF 패키징 없음

        - HLS(ts) 패키징만 자체 지원


3.FFmpeg(오디오 / 비디오 처리용 멀티미디어 프레임워크)

    3-1. 역할

        - RTMP Stream 디코딩(필요 시)

        - 재인코딩(Transcoding)

        - 포맷 변환 및 패키징(Packaging)

    3-2. 대표 처리

        - 해상도 및 비트레이트 분기(ABR를 위해 다중 화질 스트림을 생성)

    3-3. 결과물

        - .ts, .m4s, .m3u8, .mpd 등

        - HTTP 기반 스트리밍 가능 형태


4.OBS Studio(RTMP client)

    4-1. 역할

        - 사용자 화면/카메라/오디오 캡처

        - Stream Key 지정

        - 실시간 인코딩 수행

    4-2. 인코딩

        - Video: H.264

        - Audio: AAC

    4-3. 출력

        - RTMP Push to Server


5. HLS(Http Live Streaming)

    5-1. 역할

        - 실시간/준실시간 오디오/비디오를 HTTP 기반으로 전달하기 위한 적응형 스트리밍 프로토콜

        - 브라우저/모바일 단말에서 재생 가능한 최종 배포 포맷

    5-2. 네트워크 특성

        - 전송 방식: HTTP/HTTPS

        - 포트: 80 / 443

        - CDN 친화적 (Segment는 캐시 가능, Playlist는 캐시 제어 필요)

        - TCP 기반(HTTP 위에서 동작)

    5-3. 전송 방식

        - Pull 방식

        - Client(Player)가 서버로부터 Segment 파일을 요청

        - 다중 화질 스트림 중 시청자의 네트워크 상태에 따라 적절한 화질을 자동으로 선택 및 전환할 수 있는 ABR 구조를 제공

    5-4. 구성 요소(HLS의 핵심 구조: .m3u8과 .ts의 관계)

        - Media Playlist

            - .m3u8

            - Master Playlist (Variant 선택)

            - Media Playlist (Segment 목록)

        - Media Segment

            - .ts(전통적)

            - .m4s(CMAF 기반)

        📌이 부분은 HLS 동작 원리이므로 추후에 설명.

    5-5. 특징

        - Safari / iOS 네이티브 지원

        - <video src="*.m3u8"> 로 바로 재생 가능

        - 라이브 / VOD 모두 지원

        - LL-HLS(Low Latency HLS) 지원가능

    5-6. 한계

        - DASH 대비 표준 유연성 낮음(Apple 주도)

        - 브라우저 DRM 확장성 제한적 (FairPlay 중심)

        - 전통 HLS(ts) 기준으로 초저지연에는 제약



6. 아키텍쳐 구조

        


7. 구현 코드

    7-1. docker-compose.yml

services:
  nginx-rtmp:
    image: alfg/nginx-rtmp:latest
    container_name: hls-nginx
    environment:
      RTMP_PORT: "1935"
      HTTP_PORT: "80"
    ports:
      - "1935:1935"
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf.template
      - ./www:/var/www/html
      - ./hls:/var/www/hls
    restart: unless-stopped


    7-2. nginx.conf
daemon off;
events { worker_connections 1024; }

rtmp {
    server {
        listen ${RTMP_PORT};
        chunk_size 4096;
       
        # OBS publish
        # EndPoint : rtmp://HOST:${RTMP_PORT}/live
        # RTMP URL EndPoint의 /live는 application 이름이며, application live {} 설정에 의해 결정된다.
        application live {
            live on;

            # RTMP -> HLS
            # RTMP ingest → (nginx 내부) HLS 패키징
            hls on;
            hls_path /var/www/hls;
            hls_fragment 5;
            hls_playlist_length 10;
        }
    }
}

http {
    # 응답 헤더/에러 페이지 등에 nginx 버전 노출을 줄임(보안/깔끔함)
    server_tokens off;
   
    # HTTP access log를 파일 대신 표준출력으로 보냄
    # Docker에서 로그 수집하기 좋음.
    access_log /dev/stdout combined;

    server {
        listen ${HTTP_PORT};
       
        # 정적 파일 제공 루트 디렉토리
        # index.html을 찾는 기준.
        root /var/www/html;

        location = / {
          try_files /index.html =404;
        }

        # HLS 제공 http://HOST:${HTTP_PORT}/live/hello.m3u8
        # hello는 OBS Studio에서 정한 Stream Key
        location /live/ {
            alias /var/www/hls/;
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
           
            # HLS는 “계속 바뀌는 라이브 파일”이므로 캐시로 오래 잡히면 문제가 됨.
            add_header Cache-Control no-cache;
            # CORS 허용.
            add_header Access-Control-Allow-Origin *;
        }
    }
}


    7-3. index.html

<!doctype html>
<html lang="ko">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <title>HLS Player</title>
  <style>
    body{font-family:system-ui,Segoe UI,Arial;margin:24px}
    video{width:min(960px,100%);background:#000;border-radius:12px}
    code{background:#f2f2f2;padding:2px 6px;border-radius:6px}
  </style>
</head>
<body>
  <h2>HLS Player</h2>
  <p>Stream: <code id="u"></code></p>
  <video id="v" controls autoplay muted playsinline></video>

  <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
  <script>
    const url = "http://localhost:8080/live/hello.m3u8";
    document.getElementById("u").textContent = url;

    const video = document.getElementById("v");
    if (Hls.isSupported()) {
      const hls = new Hls({
        lowLatencyMode: false
      });
      hls.loadSource(url);
      hls.attachMedia(video);
    } else if (video.canPlayType("application/vnd.apple.mpegurl")) {
      video.src = url; // Safari 등
    } else {
      document.body.insertAdjacentHTML("beforeend", "<p>HLS not supported</p>");
    }
  </script>
</body>
</html>

    7-4. 디렉토리 구조

    hls-live
        ├── docker-compose.yml
        ├── nginx.conf
        └── www
                └── index.html


   7-5. 실행 방법

        1. 디렉토리 구조 설정
        2. docker Desktop 실행
        3. wsl 실행
        4. hls-live (cd 로 들어감)
        5. docker compose up -d
        6. OBS Studio 실행
        7. Stream Key: hello, Server: rtmp://localhost:1935/live 방송 시작
        7. localhost:8080 으로 접속


8. 실행 결과


9. 레퍼런스

https://datatracker.ietf.org/doc/html/rfc8216

https://github.com/arut/nginx-rtmp-module

https://www.cloudflare.com/ko-kr/learning/video/what-is-http-live-streaming/

댓글

댓글 쓰기

이 블로그의 인기 게시물

[보안] CA인증서, 서버인증서, 클라이언트 인증서와 Openssl

이미지
📌​CA 인증서 ROOT 인증서로부터 시작하는 계층 구조    📍​ Root Certification, Intermediate Certification, Server Ceritification 루트 인증서(Root Certification) 최상위 인증 기관 (DigiCert, GlobalSign, GTS)이 발급하는 인증 운영체제(OS) 및 브라우저에서 기본적으로 신뢰하는 인증서 로 저장됨. 자체 서명(self-Signed) 이 되어있음 중간 인증서(Intermediate Certification) Root CA가 직접 웹사이트에 인증서를 발급하지 않고 중간 CA를 통해 인증서 발급 중간 CA는 루트 CA의 서명을 받은 인증 기관으로 직접적으로 서버 인증서를 발급 브라우저와 OS는 중간 인증서를 직접 신뢰하지 않지만 중간 인증서가 루트 CA에 의해 서명되었기 때문에 신뢰가 가능함 서버 인증서(Server Certification) 최종적으로 웹사이트에서 사용하는 인증서 중간 CA에 의해 서명됨 사용자의 브라우저는 루트 CA까지의 인증서 체인을 검증하여 인증서의 유효성을 확인 ✅​ 정리하면 루트 인증서 ➡️​ 중간 인증서 ➡️​ 서버 인증서 순으로 인증 체인이 이루어짐
자세한 내용 보기

TCP/UDP 통신 방식 (WireShark)

이미지
 📌TCP/UDP?  📍​ TCP TCP(Transmission Control Protocal) 전송 제어 프로토콜 3 - way handshake 를 통해 연결 설정, 4 - way handshake 를 통해 연결 해제 Client 와 Server는 1:1 연결 TCP는 데이터를 전송할 때 오류를 검사하여 전송된 데이터가 목적지에 온전하게 도달하도록 보장 (신뢰성이 높음) TCP는 전송이 실패한 경우 재전송 시도 TCP는 운영체제와 독립적으로 작동하므로 시스템과 디바이스 간 상호 운용성이 높음 전송단위는 Segment                 Segment  ❓ Header 의 구성요소 Source Port / Destination Port Sequence Number  Acknowledgment Number  Flags (SYN, ACK, FIN) Window Size Checksum Urgent Pointer Data 실제로 전송되는 애플리케이션 데이터 ✅ 정리하면 "Header(최소 20바이트)" + "DATA" 로 이루어져 있음   📍​ UDP UDP(User Datagram Protocal) 유저 데이터그램 프로토콜 UDP는 패킷을 더 적은 오버헤드로 전송하여 End to End 지연을 줄임 UDP는 일부 패킷이 누락되더라도 데이터를 전송  브로드캐스트 및 멀티캐스트 기능을 통해 하나의 UDP 전송을 여러 수신자에게 한 번에 전송 전송 단위는 Daragram              Datagram  ❓ Header의 구성요소 Source Port / Destination Port Length Checksum ( IPv6 에선 필수로 Checksum이 들어가야 함) Data 실제로 전송되는 애플리케이션 데이터 ✅ ...
자세한 내용 보기

HTTP/HTTPS 프로토콜의 개념과 작동 원리 (WireShark)

이미지
📌  HTTP/HTTPS? https://seo.tbwakorea.com/wp-content/uploads/2023/12/http-1.png HTTP(Hypertext Transfer Protocol) HTTP는 OSI 7 Layer에서  Application Layer 에 속함 HTTP는 숫자 코드 및 데이터 양식으로 다양한 유형의 HTTP 응답을 전송 200 - OK 🟩 ​ 302 - Found 🟨 400 - Bad Request 🟥 405 - Method Not Allowed 🟥 503 - Service Unavailable ❌ HTTPS(Hypertext Transfer Protocol Secure) = HTTP(Hypertext Transfer Protocol) + SSL(Secure Sockets Layer)  HTTPS는 HTTP의 확장 버전 (보안 강화) 📌  HTTP/HTTPS의 차이점 https://www.cloudflare.com/img/learning/security/glossary/what-is-ssl/http-vs-https.svg HTTPS를 사용하는 웹사이트 URL은 "https://" 로 시작함 HTTP는  "http://" HTTPS는 통신할 때  SSL/TLS  인증서를 이용해 통신 데이터를 암호화 HTTP는 HTTP/1 HTTP/2 TCP/IP를 사용하고 HTTP/3 QUIC 프로토콜을 사용함 Google에서 개발한 QUIC(Quick UDP Internet Connections) 기존의 TCP와 TLS를 개선하려는 목적에서 만들어짐 내장된 TLS 암호화 보유 UDP기반의 QUIC 프로토콜은 TCP기반의 HTTPS보다 월등히 빠름   특히 모바일 네트워크 환경에서 큰 성과를 거둠 (특히 Youtube 영상 버퍼 스트리밍) HTTPS는 SEO(Search Engine Optimization)...
자세한 내용 보기