Calls self-hosted deployment
모든 플랜 에서 사용 가능
Cloud 와 self-hosted 배포판
이 문서는 Calls 플러그인을 자체 호스팅된 배포 환경에서 성공적으로 사용하는 방법에 대한 정보를 제공합니다. 또한 가장 일반적인 배포 전략과 함께 예시 다이어그램을 제공하며, 녹음 및 전사 서비스의 배포 지침을 제공합니다.
Terminology
WebRTC : 통화가 구현된 기본 프로토콜/사양 세트입니다.
RTC (Real Time Connection) : 실시간 연결. 이는 미디어 트랙 (오디오/비디오/화면)을 전송하는 데 사용되는 채널입니다.
WS (WebSocket) : WebSocket 연결. 이는 연결 설정을 위해 사용되는 채널입니다 (시그널링 과정).
NAT (Network Address Translation) : IP 주소를 매핑하는 네트워킹 기술입니다.
STUN (Session Traversal Utilities for NAT) : WebRTC 클라이언트가 NAT를 통과하는 데 도움을 주기 위해 사용되는 프로토콜/서비스입니다. 서버 측에서는 주로 인스턴스의 공용 IP를 찾는 데 사용됩니다.
TURN (Traversal Using Relays around NAT) : 엄격한 방화벽 뒤의 WebRTC 클라이언트가 미디어 릴레이를 통해 통화에 연결하는 데 도움을 주기 위해 사용되는 프로토콜/서비스입니다.
플러그인 구성 요소
Calls 플러그인 : 이것은 주요 진입 점이며 채널 통화를 활성화시키기 위한 요구 사항입니다.
rtcd : 이것은 WebRTC 연결에 관련된 모든 기능과 데이터 처리를 오프로드하는 선택적 서비스입니다. 아래에서 언제, 왜 rctd 를 사용해야 하는지 자세히 알아보세요.
요구 사항
서버
Mattermost 서버를 안전한 (HTTPs) 연결 상에서 실행해야 합니다. 이는 클라이언트에서 기기 (예: 마이크, 화면)를 캡처할 수 있도록 허용하는 필수 요구 사항입니다. 자세한 정보는 TLS 구성 섹션을 참조하세요.
아래의 네트워크 요구 사항 를 참조하세요.
클라이언트
클라이언트는
RTC Server Port로 구성된 UDP 포트를 통해 호출을 호스팅하는 인스턴스에 연결(데이터 전송 및 수신)할 수 있어야 합니다. 이를 수행할 수 없는 경우, 연결성을 달성하기 위해 TURN 서버를 사용해야 합니다.플랫폼이나 운영 체제에 따라 클라이언트가 애플리케이션 (예: 브라우저, 데스크톱 앱)에 추가 권한을 부여하여 오디오 입력을 캡처하거나 화면을 공유할 수 있도록 허용해야 할 수 있습니다.
네트워크
서비스 |
포트 |
프로토콜 |
출처 |
대상 |
목적 |
API (Calls 플러그인) |
80,443 |
TCP (수신) |
Mattermost 클라이언트 (웹/데스크톱/모바일) |
Mattermost 인스턴스 (Calls 플러그인) |
클라이언트에서 Calls 플러그인으로 HTTP 및 WebSocket 연결을 허용합니다. 이 API는 Mattermost와 동일한 연결에서 노출되므로 일반적으로 변경할 필요가 없습니다. |
RTC (Calls 플러그인 또는 |
8443 |
UDP (수신) |
Mattermost 클라이언트 (웹/데스크톱/모바일) |
Mattermost 인스턴스 또는 |
|
RTC (Calls 플러그인 또는 |
8443 |
TCP (수신) |
Mattermost 클라이언트 (웹/데스크톱/모바일) |
Mattermost 인스턴스 또는 |
|
API ( |
8045 |
TCP (수신) |
Mattermost 인스턴스(들) (Calls 플러그인) |
|
|
STUN (Calls 플러그인 또는 |
3478 |
UDP (송신) |
Mattermost 인스턴스(들) (Calls 플러그인) 또는 |
구성된 STUN 서버들 |
(옵션) Calls 플러그인 또는 |
제한 사항
Mattermost 클라우드에서 채널당 최대 200명의 참가자가 통화에 참여할 수 있습니다.
Mattermost 자체 호스팅 배포에서 기본 최대 참가자 수는 무제한입니다. 호출 당 권장 최대 참가자 수는 200명입니다. 이 설정은 시스템 콘솔 > 플러그인 관리 > Calls > 최대 통화 참가자 에서 변경할 수 있습니다. 호출당 참가자의 총 수에는 제한이 없으며 이 값은 지원되는 값이 크게 인스턴스 리소스에 따라 달라집니다. 자세한 내용은 아래 성능 섹션 를 참조하십시오.
구성
자체 호스팅 Mattermost 고객을위한 calls 플러그인은 사전 패키지화되어 설치되고 활성화됩니다. 사용자가 이를 사용할 수 있도록하려면 시스템 콘솔 에 구성이 있습니다.
운영 모드
Mattermost 서버가 실행되는 방식에 따라 Calls 플러그인이 작동하는 여러 모드가 있습니다. rtcd 및 Selective Forwarding Unit (SFU)에 대한 섹션인 rtcd 서비스 를 참조하십시오.
Mattermost deployment |
SFU |
SFU deployment |
|---|---|---|
단일 인스턴스 |
통합 |
|
단일 인스턴스 |
rtcd |
|
고가용성 클러스터 |
통합 |
클러스터형 |
고가용성 클러스터 |
통합 |
단일 핸들러 |
고가용성 클러스터 |
rtcd |
단일 인스턴스
통합
이는 단일 Mattermost 인스턴스 설정에 플러그인을 처음 설치할 때의 기본 모드입니다. WebRTC 서비스는 플러그인 자체에 통합되어 Mattermost 서버와 함께 실행됩니다.
rtcd
외부, 전용 및 확장 가능한 WebRTC 서비스(rtcd)가 모든 통화 미디어 라우팅을 처리하는 데 사용됩니다.
고가용성 클러스터
클러스터
고가용성 클러스터에서 플러그인을 실행할 때의 기본 모드입니다. 모든 Mattermost 노드는 플러그인의 인스턴스를 실행하며 이 인스턴스에는 WebRTC 서비스가 포함되어 있습니다. 호출은 기존 로드 밸런서를 통해 모든 사용 가능한 노드에 분산되며 호출은 초기 웹소켓 연결이 이루어진 인스턴스에서 호스팅됩니다 (가장 먼저 참여한 클라이언트). 단일 호출은 단일 클러스터 노드에서 호스팅됩니다.
단일 핸들러
이는 클러스터의 노드 중 하나만 호출을 호스팅하도록 하는 대안 모드입니다. 플러그인은 여전히 모든 노드에서 실행되지만 모든 호출은 핸들러 노드를 통해 라우팅됩니다. 이 모드는 특별한 환경 변수를 설정하여 인스턴스를 실행하여 활성화해야 합니다 (MM_CALLS_IS_HANDLER=true).
rtcd (고가용성)
성능
통화 성능은 주로 두 가지 리소스에 따라 달라집니다: CPU 및 대역폭 (네트워크 지연 및 전체 처리량). 최종 소비는 미디어를 송수신하는 클라이언트 수의 이차적 성장을 나타냅니다.
예를 들어 10 참가자 중 2 명이 음소거되지 않은 단일 통화는 일반적으로 동일한 통화의 음소거되지 않은 참가자 1 명인 경우의 리소스의 두 배를 소비합니다. 최종적으로 성능에 영향을 미치는 것은 서버 전체의 동시 미디어 흐름 (입/출력) 수입니다.
벤치마크
여기에는 전용 rtcd 인스턴스에서 수행된 내부 성능 테스트의 결과 중 일부가 있습니다.
Calls |
Users/call |
Unmuted/call |
Screen sharing |
CPU (avg) |
Memory (avg) |
Bandwidth (in/out) |
Instance (EC2) |
|---|---|---|---|---|---|---|---|
100 |
8 |
2 |
no |
60% |
0.5GB |
22Mbps / 125Mbps |
c6i.xlarge |
100 |
8 |
2 |
no |
30% |
0.5GB |
22Mbps / 125Mbps |
c6i.2xlarge |
100 |
8 |
2 |
yes |
86% |
0.7GB |
280Mbps / 2.2Gbps |
c6i.2xlarge |
10 |
50 |
2 |
no |
35% |
0.3GB |
5.25Mbps / 86Mbps |
c6i.xlarge |
10 |
50 |
2 |
no |
16% |
0.3GB |
5.25Mbps / 86Mbps |
c6i.2xlarge |
10 |
50 |
2 |
yes |
90% |
0.3GB |
32Mbps / 1.33Gbps |
c6i.xlarge |
10 |
50 |
2 |
yes |
45% |
0.3GB |
32Mbps / 1.33Gbps |
c6i.2xlarge |
5 |
200 |
2 |
no |
65% |
0.6GB |
8.2Mbps / 180Mbps |
c6i.xlarge |
5 |
200 |
2 |
no |
30% |
0.6GB |
8.2Mbps / 180Mbps |
c6i.2xlarge |
5 |
200 |
2 |
yes |
90% |
0.7GB |
31Mbps / 2.2Gbps |
c6i.2xlarge |
Dedicated service
엔터프라이즈 고객을 위해, 전용 서비스 를 통해 성능 비용을 줄일 수 있는 방법을 제공하여 통화를 더욱 확장할 수 있습니다.
로드 테스트
통화의 성능 영향을 시뮬레이션하고 측정할 수 있는 로드 테스트 도구 를 제공합니다.
모니터링
플러그인과 외부 rtcd 서비스는 성능을 모니터링하기 위해 프로메테우스 메트릭스를 노출합니다. Grafana에서 가져올 수 있는 공식 대시 보드 가 제공됩니다. Prometheus를 설정하고 Grafana를 통해 메트릭을 시각화하는 방법에 대한 자세한 내용은 성능 모니터링 를 참조하세요.
통화 플러그인 메트릭
통화 플러그인의 메트릭은 공개적으로 노출되는 /plugins/com.mattermost.calls/metrics API 엔드포인트를 통해 노출됩니다.
프로세스
mattermost_plugin_calls_process_cpu_seconds_total: 사용자 및 시스템 CPU 시간의 총합 (초).mattermost_plugin_calls_process_max_fds: 최대 열린 파일 디스크립터 수.mattermost_plugin_calls_process_open_fds: 열린 파일 디스크립터 수.mattermost_plugin_calls_process_resident_memory_bytes: 상주 메모리 크기 (바이트).mattermost_plugin_calls_process_virtual_memory_bytes: 가상 메모리 크기 (바이트).
WebRTC 연결
mattermost_plugin_calls_rtc_conn_states_total: RTC 연결 상태 변화의 총 수.mattermost_plugin_calls_rtc_errors_total: RTC 오류의 총 수.mattermost_plugin_calls_rtc_rtp_bytes_total: 바이트 단위로 보낸/받은 RTP 패킷의 총 수.
참고: v0.16.0에서 제거됨
mattermost_plugin_calls_rtc_rtp_packets_total: 보낸/받은 RTP 패킷의 총 수.
참고: v0.16.0에서 제거됨
mattermost_plugin_calls_rtc_rtp_tracks_total: 수신/발신 RTP 트랙의 총 수.
참고: v0.16.0에서 추가됨
mattermost_plugin_calls_rtc_sessions_total: 활성 RTC 세션의 총 수.
데이터베이스
mattermost_plugin_calls_store_ops_total: DB 저장 작업의 총 수.
웹소켓
mattermost_plugin_calls_websocket_connections_total: 활성 웹소켓 연결의 총 수.mattermost_plugin_calls_websocket_events_total: 웹소켓 이벤트의 총 수.
WebRTC 서비스 메트릭
rtcd서비스의 메트릭은 /metrics API 엔드포인트를 통해 노출됩니다.
프로세스
rtcd_process_cpu_seconds_total: 사용자 및 시스템 CPU 시간의 총합 (초).rtcd_plugin_calls_process_max_fds: 최대 열린 파일 디스크립터 수.rtcd_plugin_calls_process_open_fds: 열린 파일 디스크립터 수.rtcd_plugin_calls_process_resident_memory_bytes: 상주 메모리 크기 (바이트).rtcd_plugin_calls_process_virtual_memory_bytes: 가상 메모리 크기 (바이트).
WebRTC 연결
rtcd_rtc_conn_states_total: RTC 연결 상태 변화의 총 수.rtcd_rtc_errors_total: RTC 오류의 총 수.rtcd_rtc_rtp_bytes_total: 바이트 단위로 보낸/받은 RTP 패킷의 총 수.
참고: v0.10.0에서 제거됨
rtcd_rtc_rtp_packets_total: 보낸/받은 RTP 패킷의 총 수.
참고: v0.10.0에서 제거됨
rtcd_rtc_rtp_tracks_total: 수신/발신 RTP 트랙의 총 수.
참고: v0.10.0에서 추가됨
rtcd_rtc_sessions_total: 활성 RTC 세션의 총 수.
웹소켓
rtcd_ws_connections_total: 활성 웹소켓 연결의 총 수.rtcd_ws_messages_total: 받거나 보낸 웹소켓 메시지의 총 수.
시스템 튜닝
많은 통화를 호스팅하거나 많은 참가자를 가진 통화를 원하는 경우, 다음과 같은 플랫폼별 (Linux)튜닝을 살펴보세요 (현재 플러그인의 공식 지원 대상은 Linux뿐입니다):
# 수신 UDP 버퍼의 최대 버퍼 크기를 16MB로 설정
net.core.rmem_max = 16777216
# 송신 UDP 버퍼의 최대 버퍼 크기를 16MB로 설정
net.core.wmem_max = 16777216
# 연결된 각 소켓에 대해 보내야 하는 제어 메시지에 필요한 메모리를 필요에 따라 할당할 수 있도록 함
net.core.optmem_max = 16777216
rtcd 서비스
- orphan
- nosearch
노트
rtcd 서비스는 Enterprise 요금제에서만 이용할 수 있습니다.
- 시작-이후
- nosearch
Calls 플러그인에는 오디오 및 스크린 공유 데이터를 라우팅하는 내장형 Selective Forwarding Unit (SFU) 이 있습니다. 이것은 위의 #modes-of-operation 섹션에서 설명된 integrated 옵션입니다. 그러나 SFU 기능은 외부 rtcd 인스턴스로 별도로 배포될 수 있습니다.
rtcd서비스를 사용하는 이유
이 섹션에서는 언제 그리고 왜 기관에서 rtcd 를 사용하고 싶어할지에 대해 이해하는 데 도움이 될 것입니다.
Note
rtcd 는 독립된 서비스로서 운영 복잡성과 유지 관리 비용이 들고, 엔터프라이즈 라이선스가 필요합니다. Calls를 평가하는 사람들과 Mattermost의 많은 소규모 인스턴스의 경우, 통합 SFU(Calls 플러그인에 포함된 하나)가 초기에 충분할 수 있습니다.
rtcd 서비스를 호스팅하는 것이 권장됩니다.
주요 Mattermost 서버의 성능. Calls 플러그인이 SFU를 실행할 때, 통화 트래픽은 다른 모든 Mattermost 서비스를 실행 중인 서버의 처리 부하에 추가됩니다. Calls 트래픽이 증가하면 이러한 서비스들의 응답성에 부정적인 영향을 미칠 수 있습니다.
rtcd서비스를 사용하면 호출 트래픽 처리가 해당rtcd인스턴스로 격리되며 CPU 사용량 증가를 최소화하여 비용을 절감합니다.Calls 제품의 성능, 확장성 및 안정성. Calls 트래픽이 증가하거나 전반적인 용량이 더 필요한 경우,
rtcd서버를 추가하여 부하를 균형있게 분산시킬 수 있습니다. 추가 혜택으로, Mattermost 트래픽이 증가하거나 Mattermost 인스턴스를 다시 시작해야 하는 경우에도 현재 통화 중인 사람들에게 영향을 미치지 않으며 현재 통화가 끊어지지 않습니다.
여기에는 일부 주의 사항이 적용됩니다. 웹 소켓 이벤트(예: 이모티콘 반응, 손 올리기, 음소거/해제)는 주요 Mattermost 서버가 다운될 때 전송되지 않습니다. 그러나 호출 자체는 주요 서버가 재시작하는 동안 계속됩니다.
쿠버네티스 배포. 쿠버네티스 배포에서는
rtcd가 강력히 권장되며, 현재 Calls를 실행하는 유일한 공식 지원 방식입니다.기술적 이점. 전용
rtcd서비스는 레이턴시가 대개 처리량보다 중요한 실시간 오디오/비디오 트래픽을 위해 시스템/네트워크 수준에서 최적화되고 조정되었습니다.
일반적으로, 고성능 및 확장 가능한 배포에 대한 우선적인 솔루션이 rtcd 입니다. rtcd 를 사용하면 Mattermost 서버가 높은 수의 통화를 호스트하는 동안 최소한의 영향을 받을 것입니다.
수평 확장성
Calls의 수평 확장성을 사용하는 지원되는 방법은 DNS 기반 로드 밸런싱 방식입니다. 이는 rtcd 서비스가 어떻게 배포되었는지에 관계없이(본래 인스턴스, 쿠버네티스 또는 다른 방식) 구현할 수 있습니다.
이를 위해서는 RTCD Service URL 가 여러 IP 주소로 해석되는 호스트 이름을 가리키도록 설정되어야 합니다. Mattermost Calls 플러그인은 그런 다중 호스트들 사이에서 호출들을 자동으로 분배할 것입니다.
예상되는 요구 사항은 다음과 같습니다.
새로운
rtcd인스턴스가 배포되면, DNS 레코드에 추가되어야 합니다. 그러면 플러그인 측에서 이를 감지하고 새 호스트에 통화를 할당할 수 있게 될 것입니다.rtcd인스턴스가 다운되면, DNS 레코드에서 제거되어야 합니다. 그러면 플러그인 측에서 이를 감지하고 해당 호스트에 새로운 통화를 할당하지 않을 것입니다.
Note
로드 밸런싱은 호출 수준에서 수행됩니다. 이는 단일 호출이 항상 단일 rtcd 인스턴스에서 실행됨을 의미합니다.
현재로서 동일한 호출에 속한 세션을 다중 인스턴스의 그룹으로 분산시키는 지원은 현재 지원되지 않습니다.
녹화 및 전사 구성
통화를 녹화하고 전사하기 위해선 calls-offloader 작업 서비스를 구성해야 합니다. 여기에서는 여기 에서 이를 어떻게 수행해야 하는지 읽어볼 수 있습니다. 이 서비스와 관련된 성능 및 확장성 권장 사항은 여기 에서 찾을 수 있습니다.
Note
쿠버네티스 클러스터에 서비스를 배포하는 경우, Helm 차트 의 후속 섹션을 참조하십시오.
calls-offloader 서비스가 실행된 후 녹화는 통화 녹화 활성화 구성 설정을 통해 명시적으로 활성화되어야 하며 서비스의 URL은 작업 서비스 URL 을 사용하여 구성되어야 합니다.
통화 전사는 통화 전사 활성화 구성 설정을 통해 활성화할 수 있습니다.
Note
통화 전사 기능은 Calls 버전 v0.22.0에서 사용 가능합니다
쿠버네티스 배포
Calls 플러그인은 쿠버네티스와 잘 통합되도록 설계되었으며 배포에 대한 향상된 확장성과 통제를 제공합니다.
다음은 쿠버네티스 클러스터에 rtcd 독립 서비스를 배포하는 방법을 보여주는 샘플 다이어그램입니다:
만약 Mattermost가 쿠버네티스 클러스터에 배포되지 않았고 이러한 배치 유형을 사용하려면, 쿠버네티스 오퍼레이터 가이드 를 방문하십시오.
Helm 차트
쿠버네티스 배포에서 Calls 관련 구성 요소 및 서비스를 배포하는 권장 방법은 공식으로 제공된 Helm 차트를 사용하는 것입니다. 이러한 서비스를 배포하는 방법에 대한 자세한 정보를 포함한 관련 문서는 mattermost-helm 리포지터리에서 찾을 수 있습니다:
자주 묻는 질문
암호화가 있나요?
미디어(오디오/비디오)는 WebRTC의 일부로 보안 규격을 사용하여 암호화됩니다. 주로 DTLS와 SRTP의 조합입니다. 현재 설계에서 모든 미디어는 Mattermost를 통해 전달되어 완전히 접근 가능한 것처럼 보입니다. 그런 다음 미디어는 클라이언트로 다시 암호화되어 전송 중에 안전하게 보호됩니다. 즉: 참가자 클라이언트 및 Mattermost 서버만이 암호화되지 않은 통화 데이터에 액세스할 수 있습니다.
외부 서비스가 포함되어 있나요?
사용된 유일한 외부 서비스는 Mattermost 공식 STUN 서버( stun.global.calls.mattermost.com )입니다. 이것은 기본적으로 구성된 것입니다. 이 서비스는 사적 주소를 찾기 위해 주로 사용됩니다 만약 ICE 호스트 재정의 옵션을 통해 제공되지 않은 경우 Mattermost 인스턴스의 IP 주소가 전달되는 유일한 정보입니다. ICE 호스트 재정의 설정이 제공된 경우 이 서비스가 불필요한 경우에 제거할 수 있습니다.
UDP 사용이 필수인가요?
네, UDP는 피어 간의 최소 레이턴시를 가능하게하여 실시간 미디어를 제공하기 위해 권장되는 프로토콜입니다. 그러나 제한이나 엄격한 방화벽으로 인해 UDP를 사용할 수 없는 클라이언트를 대비하기 위한 몇 가지 가능한 해결책이 있습니다.
플러그인 버전 0.17 및
rtcd버전 0.11부터 RTC 서비스는 UDP 연결에 추가로 TCP 연결을 수신할 것입니다. 올바르게 구성된 경우 (예: 80 또는 443과 같이 흔히 허용된 포트를 사용하여) UDP 채널을 통해 연결할 수 없을 때 TCP를 통해 클라이언트가 직접 연결하는 것이 가능합니다.외부 TURN 서버를 통해 호출을 실행하고 TCP에서 수신하고 피어 간 모든 미디어 트래픽을 릴레이합니다. 그러나 가능한 경우 피하는 것이 좋은 하위 최적화 솔루션이며 이로 인해 추가된 지연 및 인프라 비용이 발생할 수 있습니다.
TURN 서버가 필요한가요?
구성된 UDP 포트를 통해 연결할 수 없는 클라이언트가 있다고 예상할 때 TURN이 필요합니다. 이는 매우 제한적인 방화벽 때문에 발생할 수 있으며, 이러한 방화벽은 표준이 아닌 포트를 외부 방향으로 차단하거나 UDP 프로토콜을 사용하지 못하도록 하는 경우가 있습니다 (예: 일부 기업용 방화벽). 이러한 경우에는 연결성을 허용하기 위해 TURN이 필요합니다.
우리는 안정적이고 성능이 우수한 TURN 서비스 구현인 coturn 을 공식적으로 지원하고 권장합니다.
기존 Mattermost 앞에 있는 리버스 프록시와 어떻게 작동하나요?
통화에 전용 서버가 필요한가요, 아니면 Mattermost와 동시에 실행될 수 있나요?
이 플러그인은 다양한 방식으로 작동할 수 있습니다. 기본적으로 호출은 Mattermost의 일부로 실행되는 플러그인에 의해 완전히 처리됩니다. 계산 및 대역폭 비용을 맡고 추가로 확장할 수도 있습니다(엔터프라이즈 전용).
Mattermost와 rtcd 간의 트래픽을 내부로 유지해야 하나요, 아니면 공개로 열어야 하나요?
가능한 경우, Mattermost 클러스터와 전용 rtcd 서비스 간의 통신을 동일한 비공개 네트워크로 유지하는 것이 좋습니다. 이렇게 함으로써 배포와 보안을 크게 간소화할 수 있습니다. rtcd 의 HTTP API를 공개 인터넷에 노출시킬 필요는 없습니다.
문제 해결
연결 문제
통화가 연결되지 않거나 시간 초과되는 경우, 플러그인 구성 또는 네트워킹 수준에서 잘못 구성된 것으로 추측됩니다.
예를 들면, RTC 서버 포트 (UDP) 또는 RTC 서버 포트 (TCP) 가 열리지 않거나 올바르게 전달되지 않았을 수 있습니다.
연결성 확인
데이터가 흐를 수 있는지 확인하는 간단한 방법은 netcat 명령 줄 도구를 사용하여 일부 테스트를 수행하는 것입니다.
Calls를 실행하는 호스트 (일반적으로 Mattermost 인스턴스 자체 또는 선택한 설정에 따라 rtcd 를 실행하는 호스트)에서 다음을 실행합니다:
nc -l -u -p 8443
클라이언트 측(즉, 일반적으로 Mattermost 데스크톱 앱 또는 브라우저를 실행하는 데 사용하는 기기)에서 다음을 실행합니다:
nc -v -u HOST_IP 8443
연결이 성공하면 양쪽의 입력을 입력하고 엔터 키를 눌러 텍스트 메시지를 송수신할 수 있습니다.
네트워크 패킷 디버깅
네트워킹 문제를 고급으로 디버깅하는 더 나은 방법은 tcpdump 명령 줄 유틸리티를 사용하여 임시로 호출을 호스팅하는 인스턴스로부터 들어오고 나가는 네트워크 패킷을 모니터링하는 것입니다.
서버 측에서 다음을 실행합니다:
sudo tcpdump -n port 8443
이 명령은 포트 8443 을 통해 전송되거나 수신되는 모든 네트워크 패킷의 정보(소스 및 대상 주소)를 출력합니다. 이는 데이터가 인스턴스로 들어오고 나가는지 확인하는 좋은 방법으로 네트워크 구성 문제를 빠르게 식별하는 데 사용할 수 있습니다.
