sgcWebSockets는 박스에 모든 주요 Delphi 실시간 클라이언트와 서버를 제공해요 — 따라서 질문은 더 이상 “Pascal에서 이것을 할 수 있나요?”가 아니라 “어떤 프로토콜이 작업에 맞나요?”가 됩니다.
“Delphi에서 실시간 통신”은 포괄적인 용어예요 — 실제로는 각각 다른 지연 시간, 순서, 팬아웃, NAT 통과 및 인프라 속성을 가진 여섯 가지 근본적으로 다른 네트워크 프리미티브를 다뤄요. 잘못 선택하면 몇 달이 걸려요: 폴링 REST 루프를 출시하고, 확장성 한계에 부딪히고, WebSocket 계층을 개조한 다음, 트래픽이 근본적으로 pub/sub이기 때문에 MQTT가 더 잘 맞았을 것임을 발견해요. 이 페이지는 짧고 단호한 가이드예요.
행을 스캔하세요; 가장 많은 녹색이 있는 열이 이깁니다.
| 필요 | WebSocket | SSE | HTTP/2 푸시 | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| 양방향 | 예 | 아니오 (서버→클라이언트만) | 아니오 | 예 (pub/sub) | 예 (pub/sub) | 예 (피어) |
| 팬아웃 브로드캐스트 | 서버 구현 | 클라이언트별만 | 스트림별만 | 네이티브 (토픽) | 네이티브 (익스체인지) | 아니오 (1:1) |
| 브라우저 지원 | 예 | 예 | 예 | WebSocket 통해 | WebSocket 통해 | 예 |
| 기업 프록시를 통해 | wss://443 통해 | 예 (HTTP처럼 보임) | 예 | WSS 통해 | WSS 통해 | 종종 (TURN) |
| 보장된 전달 | 앱 수준 | 앱 수준 | 앱 수준 | QoS 1/2 | Ack됨 | SCTP 신뢰성 |
| 저대역폭 장치 | 중간 | 낮음 | 중간 | 우수 | 중간 | 중간 |
| P2P / NAT 통과 | 아니오 (서버) | 아니오 | 아니오 | 아니오 (브로커) | 아니오 (브로커) | 예 (ICE) |
| 종단 간 암호화 | TLS 홉별 | TLS 홉별 | TLS 홉별 | TLS 홉별 | TLS 홉별 | DTLS-SRTP E2E |
| 서버를 Delphi에서 실행 가능 | 예 | 예 | 예 | 외부 브로커 사용 | 외부 브로커 사용 | 예 (시그널링 + STUN/TURN) |
기본 선택. 양방향, 낮은 오버헤드, 모든 브라우저에서 작동. 실시간 대시보드, 채팅, 협업 편집, 사용자 정의 애플리케이션 프로토콜에 선택하세요. 컴포넌트 →
트래픽이 서버 → 클라이언트만이고 가장 간단한 모델을 원할 때 선택하세요: 텍스트를 스트리밍하는 장기 HTTP 응답. 라이브러리 없이 모든 브라우저에 내장되어 있어요. SSE →
주 문서와 함께 하위 리소스(CSS, JS, JSON)를 사전 예방적으로 보내는 데 사용하세요 — 왕복을 줄여요. 범용 “푸시” 채널이 아니에요. HTTP/2 →
IoT, 텔레메트리, 모바일 존재, 연결된 차량용 pub/sub. QoS 1/2, retained 메시지, last-will, 작은 와이어 오버헤드. 브로커가 필요해요. MQTT →
엔터프라이즈 메시징: 영구 큐, 익스체인지, 라우팅 키, 데드 레터 처리, RabbitMQ / Azure Service Bus / IBM MQ. 풍부한 라우팅이 필요할 때 MQTT보다 선택하세요. AMQP →
NAT 통과가 있는 직접 피어-투-피어 — 협업용 데이터 채널, 결국 오디오/비디오. E2E 암호화 P2P의 유일한 옵션. WebRTC →
각 프로토콜에 연결할 수 있는 최소한의 Delphi 스니펫 — 동일한 라이브러리, 동일한 컴포넌트 패턴.
WS := TsgcWebSocketClient.Create(nil);
WS.URL := 'wss://echo.websocket.events';
WS.OnMessage := DoMessage;
WS.Active := True;
WS.WriteData('hello');SSE := TsgcWSPClient_SSE.Create(nil);
SSE.URL := 'https://stream.example.com/events';
SSE.OnEvent := DoEvent;
SSE.Active := True;MQTT := TsgcWSPClient_MQTT.Create(nil);
MQTT.Client := WSClient;
MQTT.OnMQTTPublish := DoMqttPublish;
WSClient.Active := True;
MQTT.Subscribe('sensors/+/temperature', mtqsAtLeastOnce);AMQP := TsgcWSPClient_AMQP.Create(nil);
AMQP.Client := WSClient;
AMQP.OnAMQPMessage := DoAmqpMessage;
WSClient.Active := True;
AMQP.Consume('orders');H2 := TsgcHTTP2Client.Create(nil);
H2.Host := 'api.example.com';
H2.Port := 443;
H2.TLS := True;
H2.OnResponse := DoResponse;
H2.Connect;
for i := 1 to 10 do H2.Get(Format('/items/%d', [i]));RTC := TsgcWSPClient_WebRTC.Create(nil);
RTC.Client := WSSignal;
RTC.IceServers.Add.URL := 'stun:stun.l.google.com:19302';
RTC.OnDataChannelMessage := DoP2PMessage;
WSSignal.Active := True;
RTC.CreateDataChannel('chat', True, True);
RTC.CreateOffer;2초마다 Get을 호출하고 응답을 비교하고 있다면 답은 거의 항상 SSE(서버→클라이언트만) 또는 WebSocket(양방향)이에요. CPU 및 대역폭 절감은 일상적으로 95 % 이상이에요.
트래픽이 근본적으로 토픽 기반 팬아웃(텔레메트리를 게시하는 장치, 구독하는 대시보드)이라면 사용자 정의 JSON-over-WebSocket 프로토콜을 실행하는 것은 MQTT를 잘못 재구현하는 것이에요. 브로커를 사용하세요.
HTTP/2 푸시 약속은 하위 리소스 최적화이며 일반 푸시 채널이 아니에요. 장기 서버-투-클라이언트 스트림의 경우 여전히 SSE, WebSocket 또는 MQTT를 원해요.
주력 전송.
IoT 및 텔레메트리 pub/sub.
다중화 HTTP 및 푸시.
피어-투-피어 데이터 채널.
간단한 서버→클라이언트 스트리밍.
RabbitMQ, Service Bus, IBM MQ를 통한 엔터프라이즈 메시징.
실용적인 SSE 예제.
nginx / Envoy / ALB를 WebSocket 및 HTTP/2 앞에 두는 방법.