# 웹 터미널 연결과 입력 지연을 이해하는 독립 학습 노트

이 노트는 공개용으로 일반화한 설명이다. 실제 접속 주소, 계정, 내부 IP, 포트, 토큰, 운영 식별자, 인증 설정값은 포함하지 않는다. WebRTC는 검토안이며 현재 운영에는 적용하지 않았다.

## 1. 웹 터미널의 역할 분담

브라우저의 xterm.js는 화면을 그리고 키 입력을 읽는다. 명령은 원격 PC의 셸이 실행한다. PTY는 프로그램이 터미널처럼 입출력할 수 있게 해 주는 가상 장치다. tmux는 작업 세션을 유지해 브라우저 연결 종료와 작업 종료를 분리한다.

현재 경로는 브라우저 → 인증 경계 → 암호화된 WebSocket 중계와 Tunnel → PC 안의 터미널 서비스 → PTY, tmux, 셸이다. 셸 출력은 반대 방향으로 돌아온다. WSS는 TLS로 보호한 WebSocket이며, 매 키 입력마다 새 연결을 만드는 방식이 아니다.

## 2. 인증과 암호화는 다른 역할

계정과 OTP는 누구인지 확인한다. 서버의 인증 증명 검사는 소유자, 유효기간, 대상 서비스가 맞는지 판단한다. 일회용 접속권은 재사용을 막고, 현재 조작권 검사는 다른 브라우저나 만료된 연결의 입력을 차단한다. 입력이 없을 때 잠금과 인증 만료도 필요하다.

암호화는 통신 내용을 보호하고, 권한 확인은 누가 조작할 수 있는지 결정한다. 현재 중계 서비스가 TLS를 종료하므로 해당 서비스 제공자를 신뢰한다. 브라우저의 악성 스크립트나 확장 프로그램까지 암호화로 막을 수는 없다.

## 3. 키 입력이 화면에 나타나는 순서

키 입력 → 브라우저 전송 → 네트워크 → 서버와 셸 → echo 반환 → 브라우저 화면 갱신.

격리된 로컬 실험에서 서버와 WebSocket을 포함한 일반 문자 왕복은 중앙값 0.617ms, p95 0.880ms였다. 이것은 인터넷을 통한 실제 접속자의 왕복 시간이 아니다.

Chrome의 동일 출력 렌더 비교는 기본 렌더러 p95 평균 9.067ms, WebGL 8.833ms였다. 차이는 약 0.23ms다. 로컬 셸 echo까지 포함하면 기본 9.167ms, WebGL 9.367ms였다. GPU 교체가 전체 입력 반응을 개선했다고 판단하지 않았다. 각 렌더 조건은 100표본씩 세 번 비교했고, onRender는 실제 모니터 픽셀 표시 시점과는 다르다.

외부 경로 우회는 관측했지만, 실제 사용 중인 인증된 WebSocket RTT는 별도 측정이 필요하다. 페이지 로딩 시간, 로컬 처리 시간, 렌더링 시간을 섞어 원인을 확정하지 않는다.

## 4. WebRTC는 무엇인가

WebRTC는 실시간 영상, 음성뿐 아니라 RTCDataChannel로 텍스트와 바이너리 데이터를 주고받을 수 있는 기술이다. 별도 VPN 클라이언트 없이 브라우저에서 사용할 수 있다.

검토안은 기존 계정과 OTP 로그인을 유지하고, 인증된 두 끝점이 연결 정보를 교환한 뒤 터미널 데이터를 직접 주고받는 것이다. WebRTC는 사용자 로그인이나 서비스 권한 판단을 대신하지 않는다.

- Signaling: 서로 연결할 방법과 암호화 연결에 필요한 정보를 교환한다.
- ICE: 직접 또는 중계 후보 중 실제 연결되는 경로를 검사한다.
- STUN: 공유기 밖에서 보이는 주소를 발견하는 데 도움을 준다. 데이터 중계 서버가 아니다.
- TURN: 직접 연결이 어려울 때 데이터를 전달하는 중계 서버다. 미리 구성해야 사용할 수 있다.
- DTLS: DataChannel의 데이터를 끝점 사이에서 암호화한다. TURN 중계에서도 이 암호화는 유지된다.

## 5. WebRTC 검토안의 두 경로

직접 경로: 브라우저 ↔ 암호화된 DataChannel ↔ 원격 PC.
중계 경로: 브라우저 ↔ TURN ↔ 원격 PC. 데이터는 끝점 사이에서 암호화된다.

인증과 signaling은 데이터가 직접 흐르는 경우에도 필요하다. 직접 연결 실패 시 TURN이 없다면 연결이 실패할 수 있고, 기존 WSS로 복귀하려면 그 동작을 별도로 구현해야 한다. 공용 Wi-Fi라고 모두 실패하는 것도, 가정용 망이라고 모두 직접 연결되는 것도 아니다. TURN이 기존 WSS보다 반드시 느리거나 빠르다고 말할 수도 없다.

## 6. 안전하게 만들려면 추가로 확인할 것

새 통신 모듈의 패킷 처리, 암호화 라이브러리, 메시지와 메모리 제한을 관리해야 한다. 인증 후 연결을 만들고, 연결 후에도 조작권과 만료를 검사한다. 연결 전환 때 두 경로가 동시에 입력을 받거나 불확실한 명령을 다시 실행하지 않게 한다. 웹 페이지와 signaling 제공자에 대한 신뢰도 남는다.

## 7. 이번 결정과 다음 판단

WebRTC, 예측 입력, GPU 렌더러 교체는 운영에 적용하지 않았다. 현재 인증과 WSS를 유지하고, 연결 진단으로 실제 왕복과 화면 갱신을 구분한다. 진단 기능은 숫자를 보여 주는 기능이지 속도를 높이는 기능이 아니다.

판단 기준: 왕복이 길면 경로를, 대량 출력에서만 느리면 출력 제어를, 화면 갱신이 느리면 렌더러를 점검한다. 공개 설명에는 접근에 필요한 실제 운영 정보와 비밀값을 넣지 않는다.

## 공개 참고 자료

- https://developers.cloudflare.com/network/websockets/
- https://xtermjs.org/docs/guides/security/
- https://webrtc.org/getting-started/peer-connections
- https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels
- https://www.rfc-editor.org/rfc/rfc8827.html
- https://www.rfc-editor.org/rfc/rfc8831.html