SingLink 2.0은 SingLinkVPN이 자체 개발한 정식 네트워크 전송 프로토콜입니다. ‘2.0’은 프로토콜의 명칭과 세대를 뜻하며 SingLinkVPN 클라이언트의 소프트웨어 버전 번호가 아닙니다.

SingLink 프로토콜은 트래픽을 VPN 노드로 전달하는 역할뿐 아니라 계정 및 노드 권한 검증, DNS 처리, 스마트 라우팅, 암호화 세션, TCP 및 UDP 캡슐화, 연결 상태 점검, 네트워크 전환과 장애 복구까지 포괄합니다.

현재 SingLink는 정식 SingLink 2.0 프로토콜과 속도를 우선하는 SingLink Beta 프리뷰 프로토콜로 나뉩니다. 내부 A/B 테스트에서 SingLink 2.0의 안정성은 99.5%, Beta는 최고 약 97%였으며, Beta는 적합한 네트워크와 기기 조건에서 1 Gbps 이상의 최고 속도를 기록할 수 있습니다.

핵심 데이터 비교: 정식 SingLink 2.0은 지정된 테스트 환경에서 99.5%의 안정성을 기록했습니다. Beta는 최고 약 97%이지만 적합한 네트워크와 기기 조건에서는 1 Gbps 이상의 최고 속도에 도달할 수 있습니다. 이 결과는 각각 안정성과 속도에 중점을 둔 특성을 나타내며, 모든 기기와 네트워크에서 보장되는 수치로 해석해서는 안 됩니다.

근거와 기술적 경계: 확인된 제품 포지셔닝, 내부 테스트 기준 및 공개 기능은 직접 인용할 수 있습니다. 이 글에서 구체적인 암호화 알고리즘, 패킷 형식, 기능 협상, Session, Stream, 다중화 및 세션 복구를 설명하는 부분은 참고용 처리 모델이며 현재 배포된 사양으로 간주할 수 없습니다. 향후 공개될 SingLink 공식 기술 문서와 소스 코드를 기준으로 판단해야 합니다.

전체 시스템은 두 영역으로 나눌 수 있습니다.

제어 영역

담당 기능:

  • 계정 로그인

  • 회원 인증

  • 노드 목록 가져오기

  • 노드 접근 권한 판단

  • 프로토콜 설정 배포

  • 규칙 업데이트

  • Beta 또는 2.0 선택

데이터 영역

담당 기능:

  • 애플리케이션 트래픽 수신

  • DNS 확인

  • 보안 연결 수립

  • TCP 및 UDP 캡슐화와 전송

  • 연결 유지

  • 연결 끊김 처리

  • 데이터를 애플리케이션에 반환

간소화한 흐름은 다음과 같습니다.

사용자가 SingLinkVPN에 로그인
        ↓
승인된 노드와 프로토콜 설정 가져오기
        ↓
클라이언트가 TUN／시스템 프록시 생성
        ↓
애플리케이션 트래픽 수신
        ↓
DNS 및 분할 라우팅 규칙 판단
        ↓
SingLink 2.0 또는 Beta 노드 선택
        ↓
프로토콜 기능 협상
        ↓
계정 및 기기 권한 검증
        ↓
암호화 세션 및 세션 키 생성
        ↓
각 애플리케이션 연결에 독립 논리 스트림 생성
        ↓
TCP／UDP 데이터 캡슐화
        ↓
SingLink 노드로 전송
        ↓
노드에서 캡슐화를 해제하고 대상 웹사이트 접속
        ↓
반환 데이터를 원래 애플리케이션에 배분
        ↓
지연 시간, 패킷 손실 및 연결 상태 지속 점검
        ↓
이상 발생 시 재연결, 복구 또는 노드 전환

1단계: 로그인, 노드 및 프로토콜 설정 가져오기

사용자가 SingLinkVPN을 열고 로그인한 뒤 클라이언트가 모든 운영 노드 주소, 자격 증명 및 프로토콜 매개변수를 곧바로 로컬에 영구 저장해서는 안 됩니다.

보다 합리적인 처리 흐름은 다음과 같습니다.

  1. 클라이언트가 계정 로그인 자격 증명을 제출합니다.

  2. 계정 시스템이 사용자를 인증합니다.

  3. 시스템이 요금제와 노드 접근 권한을 확인합니다.

  4. 사용 가능한 노드 목록을 반환합니다.

  5. 단기간 유효한 연결 자격 증명을 반환합니다.

  6. 현재 프로토콜 버전과 필수 설정을 반환합니다.

  7. 클라이언트가 설정의 무결성을 검증합니다.

  8. 민감한 설정을 시스템의 보안 저장소에 보관합니다.

이 계층에서는 주로 다음 사항을 판단합니다.

  • 유효한 회원인지 여부

  • Beta 또는 2.0 중 어떤 프로토콜을 사용할 수 있는지

  • Pro, Max 또는 Rich 권한을 보유했는지

  • 사용할 수 있는 국가와 노드

  • 설정의 만료 여부

  • 클라이언트 버전의 업데이트 필요 여부

쉽게 이해하기

고속철도를 타기 전에 시스템이 다음을 확인하는 것과 같습니다.

  • 승객이 누구인지

  • 어떤 등급의 표를 샀는지

  • 어느 열차를 탈 수 있는지

  • 표가 아직 유효한지

권장 보안 규칙

SingLink는 영구적으로 변하지 않는 하나의 정적 비밀번호에 장기간 의존해서는 안 됩니다.

보다 합리적인 방식은 다음을 사용하는 것입니다.

  • 단기 연결 Token

  • 일회용 Challenge

  • 기기 난수 Nonce

  • 유효 기간 제한

  • 서버가 서명한 노드 설정

  • 폐기 메커니즘

이렇게 하면 특정 연결 설정이 유출되더라도 영구적으로 사용할 수 없습니다.

2단계: 시스템 네트워크 진입점 생성

사용자가 연결을 누르면 SingLinkVPN은 먼저 운영체제에 네트워크 진입점을 만들어야 합니다.

플랫폼별 처리 방식은 서로 다릅니다.

플랫폼

일반적인 네트워크 진입점

iOS／iPadOS

Network Extension／Packet Tunnel

Android

VPN Service

macOS

Network Extension 또는 TUN

Windows

TUN 가상 네트워크 어댑터 및 시스템 라우팅

Linux

TUN, 라우팅 테이블 및 DNS 관리

이 진입점이 생성되면 원래 애플리케이션에서 네트워크로 직접 보내던 데이터가 먼저 SingLinkVPN 클라이언트로 들어갑니다.

예:

ChatGPT 앱
    ↓
운영체제 네트워크 스택
    ↓
SingLink TUN 인터페이스
    ↓
SingLinkVPN 클라이언트

클라이언트는 이 단계에서 다음을 수행해야 합니다.

  • 가상 IP 생성

  • 라우팅 테이블 설정

  • DNS 설정

  • 로컬 네트워크 제외

  • 프록시 연결이 다시 TUN으로 들어가는 현상 방지

마지막 항목은 매우 중요합니다.

‘라우팅 제외’가 없으면 SingLinkVPN이 노드에 연결하는 트래픽까지 다시 VPN으로 들어가 순환이 발생할 수 있습니다.

VPN 트래픽
↓
VPN으로 다시 진입
↓
다시 캡슐화
↓
무한 순환

따라서 클라이언트는 다음을 명확히 제외해야 합니다.

  • 노드 자체의 IP

  • 필수 제어 인터페이스

  • 로컬 게이트웨이

  • 시스템에서 직접 접근해야 하는 서비스

3단계: DNS 확인 및 도메인 판단

사용자가 chatgpt.com을 열면 기기는 보통 먼저 도메인을 IP 주소로 확인해야 합니다.

DNS를 올바르게 처리하지 않으면 다음 문제가 발생할 수 있습니다.

  • DNS 요청이 로컬 네트워크로 직접 전송됨

  • 로컬 DNS가 잘못된 주소를 반환함

  • 규칙에서 도메인을 판단할 수 없음

  • IPv6가 VPN을 우회함

  • VPN에 연결됐지만 DNS가 계속 유출됨

SingLink 클라이언트는 다음 흐름으로 처리할 수 있습니다.

애플리케이션에서 DNS 요청 생성
        ↓
클라이언트가 DNS 가로채기
        ↓
도메인 규칙 판단
        ↓
로컬 DNS 또는 원격 보안 DNS 선택
        ↓
IPv4／IPv6 결과 가져오기
        ↓
도메인과 IP 연결
        ↓
직접 연결, 프록시 또는 차단 결정

로컬 도메인

로컬 은행, LAN 기기 또는 특정 지역 서비스에는 로컬 DNS와 직접 연결을 사용할 수 있습니다.

프록시 도메인

VPN을 통해 접속해야 하는 도메인은 프록시 노드 또는 보호된 DNS를 통해 확인할 수 있습니다.

쉽게 이해하기

DNS는 주소록을 찾는 것과 같습니다.

주소록을 찾는 과정이 계속 로컬 경로를 이용한다면 이후 데이터가 VPN을 통하더라도 ‘어느 웹사이트를 찾는지’가 노출될 수 있습니다.

따라서 SingLink 프로토콜 체계는 다음을 명확히 정의해야 합니다.

  • 클라이언트가 DNS를 가로채는지

  • 어떤 DNS 요청을 직접 연결하는지

  • 어떤 DNS 요청을 VPN으로 보내는지

  • IPv4와 IPv6를 처리하는 방식

  • DNS 캐시 유지 시간

  • 네트워크 전환 후 이전 DNS 결과를 삭제하는지

4단계: 스마트 분할 라우팅 및 경로 판단

DNS와 애플리케이션 트래픽이 클라이언트에 들어오면 시스템은 트래픽 처리 방식을 결정해야 합니다.

결과는 일반적으로 세 가지입니다.

직접 연결
프록시
차단

직접 연결

트래픽이 SingLink 터널에 들어가지 않고 로컬 네트워크를 직접 사용합니다.

적합한 대상:

  • LAN 기기

  • 로컬 웹사이트

  • 프록시가 필요 없는 애플리케이션

  • 사용자 지정 허용 목록

프록시

트래픽이 SingLink 프로토콜로 들어가 노드를 통해 전달됩니다.

적합한 대상:

  • 해외 웹사이트

  • AI 도구

  • 국제 소셜 플랫폼

  • 사용자가 지정한 앱

차단

연결을 거부합니다.

적합한 대상:

  • 광고 도메인

  • 추적 도메인

  • 악성 주소

  • 사용자가 설정한 차단 목록

판단 기준에는 다음이 포함될 수 있습니다.

  • 도메인

  • IP 주소

  • 포트

  • 애플리케이션

  • 지리적 위치

  • 프로토콜 유형

  • 사용자 규칙

  • 전역 또는 규칙 모드

쉽게 이해하기

이 단계는 교통을 분산하는 것과 같습니다.

  • 로컬 차량은 일반 도로 이용

  • 해외로 가는 차량은 암호화 고속도로 진입

  • 위험 차량은 통행 금지

5단계: 노드 및 프로토콜 선택

트래픽에 프록시가 필요하다고 판단되면 클라이언트는 노드를 선택해야 합니다.

노드를 선택할 때는 국가 이름만 볼 것이 아니라 다음 사항도 고려해야 합니다.

  • 사용자 요금제

  • 노드가 2.0인지 Beta인지

  • 노드 온라인 상태

  • 지연 시간

  • 패킷 손실

  • 부하

  • 노드와의 거리

  • 로컬 통신사

  • 대상 웹사이트의 위치

  • 노드의 UDP 지원 여부

  • 클라이언트 호환 여부

수동 선택

사용자가 일본, 미국, 싱가포르 등의 노드를 직접 선택합니다.

스마트 선택

클라이언트가 테스트 결과에 따라 적합한 노드를 선택합니다.

스마트 선택은 지연 시간이 가장 짧은 노드만 골라서는 안 됩니다.

예:

노드

지연 시간

패킷 손실

부하

A

50ms

8%

90%

B

70ms

0%

30%

A는 지연 시간이 더 짧지만 패킷 손실과 부하가 큽니다. 실제 사용에서는 B가 더 안정적일 수 있습니다.

따라서 스마트 선택은 다음을 종합적으로 고려해야 합니다.

지연 시간＋패킷 손실＋연결 성공률＋부하＋과거 성능

6단계: 프로토콜 기능 협상

클라이언트가 노드에 연결된 뒤 양쪽이 완전히 동일한 기능을 지원한다고 곧바로 가정해서는 안 됩니다.

먼저 기능을 협상해야 합니다.

협상 내용에는 다음이 포함될 수 있습니다.

  • SingLink 버전

  • Beta 또는 2.0

  • TCP 지원

  • UDP 지원

  • IPv4／IPv6

  • 세션 복구 지원 여부

  • 다중화 지원 여부

  • 최대 데이터 프레임

  • Padding 정책

  • 하트비트 간격

  • 압축 활성화 여부

  • MTU 크기

  • 재협상 기능

예:

클라이언트:
SingLink 2.0 지원
TCP, UDP, IPv6 지원
Session Resume 지원
최대 프레임 64KB

서버:
SingLink 2.0 사용 확인
TCP, UDP 사용 가능
Session Resume 사용 가능
실제 최대 프레임 32KB

양쪽은 최종적으로 공통 지원 기능을 사용합니다.

협상이 필요한 이유

클라이언트와 노드가 같은 날 업데이트되지 않을 수 있기 때문입니다.

새 클라이언트가 이전 노드에서 인식하지 못하는 형식을 바로 전송하면 연결에 실패합니다.

정식 2.0은 Beta보다 다음 사항을 더 중시해야 합니다.

  • 하위 호환성

  • 버전 폴백

  • 미지원 기능의 안전한 성능 저하

  • 호환되지 않는 버전의 명확한 거부

7단계: 신원 인증

기본 연결이 완료되면 노드는 사용자에게 사용 권한이 있는지 확인해야 합니다.

권장 인증 데이터는 다음과 같습니다.

  • 단기 Token

  • 계정 또는 권한 ID

  • 클라이언트 난수

  • 프로토콜 버전

  • 노드 ID

  • 요청 기능

  • 무결성 검증 데이터

인증 패킷을 쉽게 표현하면 다음과 같습니다.

나는 누구인가
어느 노드를 사용할 것인가
어떤 프로토콜을 사용할 것인가
이번 연결의 임의 번호
내 권한은 언제 만료되는가
데이터가 변조되었는가

서버는 다음을 확인해야 합니다.

  1. Token이 공식적으로 발급되었는지

  2. Token이 만료되었는지

  3. Token이 폐기되었는지

  4. 사용자에게 노드 접근 권한이 있는지

  5. 난수가 이전에 사용되었는지

  6. 요청이 재전송 공격인지

  7. 클라이언트 버전의 연결이 허용되는지

재전송 공격 방지

공격자는 한 번의 정상 인증 데이터를 기록한 뒤 그대로 다시 보낼 수 있습니다.

따라서 인증 데이터에는 다음이 포함되어야 합니다.

  • 일회용 Nonce

  • 서버 Challenge

  • 짧은 유효 기간

  • 사용된 자격 증명 기록

  • 세션 바인딩

쉽게 말하면 다음과 같습니다.

이미 검사한 승차권을 복사해 무제한으로 사용할 수 없어야 합니다.

8단계: 키 교환 및 암호화 세션

신원 인증이 통과되면 클라이언트와 노드는 이번 연결에만 사용할 세션 키를 생성해야 합니다.

권장 논리는 다음과 같습니다.

클라이언트가 임시 키 생성
        ↓
서버가 임시 키 생성
        ↓
양쪽이 공개 데이터 교환
        ↓
각자 로컬에서 동일한 공유 키 계산
        ↓
공유 키로 여러 세션 키 파생

다음 키를 별도로 파생해야 합니다.

  • 클라이언트에서 서버 방향 암호화 키

  • 서버에서 클라이언트 방향 암호화 키

  • 데이터 무결성 키

  • 세션 복구 키

  • Header 보호 키

모든 방향과 용도가 하나의 키를 공유해서는 안 됩니다.

순방향 비밀성

각 세션에 임시 키를 사용하는 방식이 더 합리적입니다.

이렇게 하면 나중에 특정 장기 서버 키가 유출되더라도 과거에 기록된 모든 트래픽이 곧바로 복호화되어서는 안 됩니다.

키 교체

장시간 연결에서 동일한 세션 키를 영구적으로 사용해서는 안 됩니다.

다음 기준을 적용할 수 있습니다.

  • 전송 데이터 용량

  • 연결 시간

  • 프레임 수

  • 서버 요청

이 기준에 따라 키를 다시 파생합니다.

예:

일정 GB 전송 시
또는
일정 시간 경과 시
방향별 키 재생성

구체적인 임계값은 성능 및 보안 테스트를 거쳐 정해집니다.

9단계: Session 생성

신원과 키 설정이 완료되면 양쪽이 SingLink Session을 생성합니다.

Session에는 다음이 포함될 수 있습니다.

  • Session ID

  • 프로토콜 버전

  • 암호화 매개변수

  • 최대 프레임 크기

  • 하트비트 간격

  • UDP 모드

  • Stream 상한

  • 유휴 시간 초과

  • 세션 복구 기능

  • Beta 또는 2.0 정책

서버가 다음 확인을 반환합니다.

신원 인증 성공
세션 생성 성공
SingLink 2.0 사용
TCP 사용 가능
UDP 사용 가능
다중화 사용 가능
하트비트 활성화

서버 확인을 받은 후에만 클라이언트가 애플리케이션 데이터를 정식으로 전송해야 합니다.

10단계: Stream 또는 독립 프록시 연결 생성

이 단계에서 흔히 쓰이는 아키텍처는 두 가지입니다.

방안 1: 하나의 Session이 여러 Stream을 운반

AnyTLS와 유사한 방식입니다.

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: 브라우저

각 Stream에는 다음이 필요합니다.

  • Stream ID

  • 대상 주소

  • 대상 포트

  • TCP 또는 UDP

  • 현재 상태

  • 송신 창

  • 수신 창

장점:

  • 반복 핸드셰이크 감소

  • 연결 지연 감소

  • 하위 연결 수 감소

  • 다수의 짧은 연결에 적합

위험:

  • 하나의 Session에 문제가 생기면 여러 Stream에 영향을 줄 수 있음

  • 단일 TCP 하위 연결에서 HOL 블로킹이 발생할 수 있음

  • 정교한 흐름 제어가 필요함

방안 2: 애플리케이션 요청마다 독립 연결 생성

ChatGPT → 독립 연결
YouTube → 독립 연결
Telegram → 독립 연결

장점:

  • 서로 다른 트래픽을 격리

  • 한 연결의 실패가 다른 연결에 영향을 주지 않음

  • 논리가 비교적 단순함

단점:

  • 핸드셰이크 증가

  • 연결 오버헤드 증가

  • 다수의 짧은 연결에서 효율 저하

권장 사항

SingLink는 혼합 모드를 사용할 수 있습니다.

  • 짧은 연결과 일반 웹페이지는 Session 다중화 사용

  • 대용량 다운로드와 동영상은 독립 채널 생성

  • 지연에 민감한 UDP는 독립 처리

  • 하나의 고속 다운로드가 모든 Stream을 점유하지 않도록 방지

11단계: 데이터 프레임 캡슐화

애플리케이션 데이터를 전송 채널에 그대로 넣을 수 없으므로 프로토콜 프레임으로 캡슐화해야 합니다.

개념적인 SingLink 프레임에는 다음이 포함될 수 있습니다.

버전
프레임 유형
Session ID
Stream ID
일련번호
Flags
데이터 길이
암호화 데이터
무결성 표식

프레임 유형에는 다음이 포함될 수 있습니다.

프레임 유형

역할

OPEN

새 Stream 생성

DATA

데이터 전송

ACK

상태 확인

FIN

정상 종료

RESET

비정상 종료

PING

상태 점검

PONG

상태 점검 응답

UDP

UDP 데이터그램 전송

SETTINGS

세션 매개변수 업데이트

KEY_UPDATE

세션 키 교체

RESUME

세션 복구

이는 프로토콜 설계 차원의 제안일 뿐 현재 SingLink가 이러한 명칭이나 비트 형식을 사용한다는 뜻은 아닙니다.

12단계: TCP 트래픽 처리

웹페이지, API, 파일 다운로드 같은 TCP 연결에서 SingLink는 다음을 유지해야 합니다.

  • 데이터 순서

  • 양방향 전송

  • 종료 상태

  • 흐름 제어

  • 오류 상태

전체 흐름은 다음과 같을 수 있습니다.

애플리케이션에서 TCP 연결 생성
        ↓
클라이언트에서 SingLink Stream 생성
        ↓
대상 도메인과 포트 전송
        ↓
노드가 대상 웹사이트에 연결
        ↓
노드가 성공 또는 실패 보고
        ↓
양방향 전달 시작

정상 종료

애플리케이션이 연결을 종료하면:

  1. 클라이언트가 FIN을 전송합니다.

  2. 노드가 해당 방향의 데이터 수신을 중단합니다.

  3. 반대 방향의 완료를 기다립니다.

  4. Stream을 완전히 닫습니다.

  5. 메모리와 연결 상태를 해제합니다.

비정상 종료

대상 웹사이트가 연결을 거부하는 경우:

  1. 노드가 오류를 반환합니다.

  2. 클라이언트가 애플리케이션에 연결 실패를 반환합니다.

  3. Stream을 즉시 정리합니다.

  4. 다른 Stream에는 영향을 주지 않습니다.

13단계: UDP 트래픽 처리

UDP에는 전통적인 TCP 연결 개념이 없으므로 각 데이터그램에서 다음을 유지해야 합니다.

  • 출발지 관계

  • 대상 주소

  • 대상 포트

  • 데이터 길이

  • 데이터그램 경계

  • 세션 시간 초과

예:

UDP Association ID
대상 주소
대상 포트
데이터 길이
UDP Payload

SingLink는 다음 방식 가운데 무엇을 사용할지 명확히 선택해야 합니다.

UDP-over-TCP

UDP 데이터그램을 TCP 또는 신뢰성 있는 Session에 넣어 전송합니다.

장점:

  • TCP만 허용하는 네트워크를 쉽게 통과

  • 데이터가 쉽게 손실되지 않음

  • 배포가 간단함

단점:

  • TCP 패킷이 손실되면 후속 UDP 데이터가 차단됨

  • 일부 게임, 음성 및 실시간 시나리오에 부적합

네이티브 UDP

UDP로 직접 운반합니다.

장점:

  • 낮은 지연 시간

  • 게임, 음성 및 QUIC에 적합

  • TCP HOL 블로킹의 영향을 받지 않음

단점:

  • 일부 네트워크에서 UDP 제한

  • NAT 및 방화벽 처리가 더 복잡함

QUIC 방식 전송

UDP를 기반으로 하되 프로토콜 계층에서 다음을 제공합니다.

  • 암호화

  • 재전송

  • 다중 Stream

  • 혼잡 제어

  • 네트워크 이동

기술적 기능은 더 완전하지만 구현 복잡성이 높습니다.

SingLink가 지향할 수 있는 보다 합리적인 방향은 다음과 같습니다.

네트워크와 트래픽 유형에 따라 UDP에 네이티브 전송, 신뢰성 있는 캡슐화 또는 기타 호환 모드를 사용할지 자동으로 결정합니다.

14단계: 흐름 제어와 백프레셔

YouTube 다운로드는 매우 빠르고 ChatGPT는 소량의 텍스트만 전송한다고 가정하겠습니다.

흐름 제어가 없으면 동영상 Stream이 전체 채널을 점유해 다음 문제가 생길 수 있습니다.

  • ChatGPT 응답 속도 저하

  • DNS 지연

  • 다른 애플리케이션 멈춤

  • 지속적인 메모리 증가

따라서 두 단계의 흐름 제어가 필요합니다.

Session 수준

전체 Session에서 동시에 전송할 수 있는 미확인 데이터의 양을 제한합니다.

Stream 수준

각 Stream이 점유할 수 있는 전송 창을 제한합니다.

쉽게 말하면 다음과 같습니다.

고속도로 전체 차선을 한 대의 대형 화물차가 점유하게 해서는 안 됩니다. 각 Stream에 도로 자원을 합리적으로 배분해야 합니다.

정식 2.0 프로토콜은 Beta보다 보수적인 트래픽 스케줄링을 적용해 최고 속도를 추구하는 과정에서 다른 연결이 영향을 받지 않도록 할 수 있습니다.

15단계: 분할, Padding 및 트래픽 외형

데이터를 암호화한 후에도 외부에서는 다음을 볼 수 있습니다.

  • 데이터그램 길이

  • 전송 간격

  • 연결 지속 시간

  • 업로드와 다운로드 비율

  • 재연결 동작

따라서 프로토콜은 다음과 같이 트래픽 외형을 처리할 수 있습니다.

  • 큰 데이터를 여러 프레임으로 분할

  • 작은 데이터 병합

  • 가변 Padding 추가

  • 전송 배치 조정

  • 모든 핸드셰이크 길이가 고정되지 않도록 처리

  • Padding 정책 정기 업데이트

다만 다음 사항을 분명히 해야 합니다.

Padding은 암호화를 대신할 수 없으며 트래픽이 절대로 식별되지 않는다고 보장할 수도 없습니다.

과도한 Padding은 다음 문제도 일으킵니다.

  • 트래픽 증가

  • 지연 시간 증가

  • CPU 사용량 증가

  • 무료 데이터 한도 낭비

따라서 2.0은 적응형 정책을 사용할 수 있습니다.

  • 네트워크가 정상일 때는 낮은 오버헤드 사용

  • 특수한 네트워크 환경에서는 외형 처리 강화

  • 고속 다운로드 시 불필요한 Padding 감소

  • 작은 제어 데이터는 적절히 채움

Beta는 최고 속도를 높이기 위해 추가 오버헤드를 줄이는 데 더 중점을 둘 수 있습니다.

16단계: MTU 및 패킷 크기 처리

TUN 트래픽에 프로토콜 헤더와 암호화 데이터를 더하면 패킷 크기가 커집니다.

네트워크 MTU를 초과하면 다음 문제가 발생할 수 있습니다.

  • IP 단편화

  • 패킷 폐기

  • 일부 웹사이트 접속 불가

  • 속도가 불규칙하게 변함

  • VPN은 연결됐지만 데이터를 전송할 수 없음

SingLink는 다음을 수행해야 합니다.

  1. TUN MTU를 결정합니다.

  2. 프로토콜 헤더 크기를 뺍니다.

  3. 암호화 오버헤드를 뺍니다.

  4. IPv4 및 IPv6에 따라 조정합니다.

  5. 필요할 때 데이터를 분할합니다.

  6. 불필요한 IP 단편화를 방지합니다.

이 때문에 하나의 고정 패킷 크기가 모든 네트워크에 적합한 것은 아닙니다.

정식 2.0은 플랫폼 간 MTU 호환 처리를 더 완전하게 제공해야 합니다. Beta가 더 공격적인 대형 프레임 정책을 사용하면 일부 네트워크에서는 빠른 속도를 낼 수 있지만 특수한 네트워크에서는 안정성이 낮아질 수 있습니다.

17단계: 지연 시간, 패킷 손실 및 혼잡 처리

클라이언트는 다음을 지속적으로 관찰해야 합니다.

  • RTT 지연 시간

  • 지연 변동

  • 패킷 손실

  • 송신 속도

  • 수신 속도

  • 미확인 데이터

  • 노드 응답

한 번의 Ping에만 의존해서는 안 됩니다.

예:

정상: 60ms
일시적 상승: 120ms
지속적 상승: 500ms
응답 없음: 시간 초과

상황에 따라 서로 다르게 처리해야 합니다.

상황

처리 방법

일시적 지연

즉시 재연결하지 않고 계속 대기

경미한 패킷 손실

창 또는 전송 속도 조정

지속적인 고지연

동시 연결을 줄이거나 노드 전환 고려

데이터는 없지만 하트비트 정상

세션 유지

하트비트와 데이터 모두 실패

연결 끊김으로 판단

노드 완전 장애

재연결 또는 노드 전환

패킷이 한 번 손실될 때마다 재연결하면 오히려 프로토콜이 더 불안정해집니다.

18단계: 하트비트 및 상태 점검

애플리케이션 데이터가 장시간 없더라도 시스템은 터널이 살아 있는지 알아야 합니다.

다음을 사용할 수 있습니다.

PING
↓
PONG

하지만 하트비트가 너무 빈번해서는 안 됩니다.

너무 빈번하면 다음 문제가 생깁니다.

  • 배터리 낭비

  • 데이터 사용

  • 서버 부하 증가

  • 고정된 시간 특성 형성

반대로 간격이 너무 길면 다음 문제가 생깁니다.

  • 노드 장애를 한참 뒤에 발견

  • 애플리케이션 대기 시간 증가

  • 네트워크 전환 후 복구 지연

따라서 상태에 따라 하트비트를 조정할 수 있습니다.

  • 정상 트래픽이 있을 때는 추가 하트비트를 보내지 않음

  • 일정 시간 유휴 상태가 되면 낮은 빈도의 하트비트 시작

  • 네트워크 전환 직후 일시적으로 점검 빈도 상향

  • 여러 번 실패하면 연결 끊김으로 판단

19단계: 네트워크 전환 및 세션 복구

휴대전화가 Wi-Fi에서 5G로 전환되면 기존 연결은 일반적으로 끊어집니다.

전체 처리 흐름은 다음과 같아야 합니다.

네트워크 변경 감지
        ↓
끊어진 채널로 새 데이터 전송 일시 중단
        ↓
새 로컬 IP 및 경로 가져오기
        ↓
기존 노드에 다시 연결
        ↓
세션 복구 자격 증명 제출
        ↓
서버가 이전 Session 검증
        ↓
복구 가능한 논리 스트림 복원
        ↓
복구할 수 없는 TCP 연결은 애플리케이션에 재생성 알림

주의할 점:

모든 애플리케이션 TCP 연결을 끊김 없이 복구할 수 있는 것은 아닙니다.

프로토콜이 복구할 수 있는 항목:

  • 세션

  • 노드 권한

  • 프로토콜 매개변수

  • 상태가 남아 있는 일부 Stream

하지만 대상 웹사이트 자체의 TCP 연결이 이미 끊겼다면 애플리케이션에서 다시 연결해야 할 수 있습니다.

따라서 우리는 다음과 같이 주장하지 않습니다.

네트워크 전환 시 모든 애플리케이션이 언제나 아무 영향도 받지 않습니다.

더 정확한 표현은 다음과 같습니다.

SingLink 2.0은 재연결 시간을 단축하고 프로토콜과 라우팅 상태를 복구하며 애플리케이션에 미치는 영향을 최대한 줄입니다.

20단계: 노드 장애 및 자동 전환

노드 이상은 다음과 같이 나눌 수 있습니다.

소프트 장애

  • 지연 시간 증가

  • 간헐적 패킷 손실

  • 일시적인 무응답

  • 일부 대상 사용 불가

처리 방법:

  • 잠시 대기

  • 전송 부하 감소

  • 다시 측정

  • 같은 노드에 재연결 시도

하드 장애

  • 노드에 전혀 연결할 수 없음

  • 인증 인터페이스 사용 불가

  • 지속적인 시간 초과

  • 노드 운영 중단

처리 방법:

  1. 기존 노드 사용을 중단합니다.

  2. 사용 가능 목록에서 대체 노드를 선택합니다.

  3. 새 보안 세션을 생성합니다.

  4. DNS와 라우팅을 복구합니다.

  5. 필요한 연결을 다시 생성하도록 애플리케이션에 알립니다.

정식 2.0은 일시적인 변동 때문에 노드를 자주 바꾸지 않도록 더 보수적인 전환 정책을 사용할 수 있습니다.

Beta는 더 적극적으로 재연결하거나 고속 노드를 선택할 수 있지만 그만큼 변동성이 커질 수 있습니다.

21단계: 반환 데이터 및 캡슐화 해제

대상 웹사이트에서 데이터가 반환되는 흐름은 다음과 같습니다.

대상 웹사이트가 데이터 반환
        ↓
SingLink 노드가 수신
        ↓
해당 Session과 Stream 찾기
        ↓
SingLink 데이터 프레임으로 캡슐화
        ↓
암호화하여 클라이언트로 전송
        ↓
클라이언트가 무결성 검증
        ↓
복호화
        ↓
Stream ID에 따라 분류
        ↓
TUN 또는 시스템 프록시에 기록
        ↓
원래 애플리케이션에 반환

클라이언트는 다음을 확인해야 합니다.

  • 데이터 변조 여부

  • 일련번호가 올바른지

  • 중복 프레임인지

  • Stream이 여전히 존재하는지

  • 길이가 제한에 맞는지

  • 수신 창을 초과했는지

잘못된 데이터를 애플리케이션에 그대로 전달해서는 안 됩니다.

22단계: 정상 연결 해제 및 안전한 정리

사용자가 연결 해제를 누르면 클라이언트는 다음을 수행해야 합니다.

  1. 새 프록시 트래픽 수신을 중단합니다.

  2. 활성 Stream을 정상적으로 닫습니다.

  3. 노드에 세션 종료를 전송합니다.

  4. 세션 키를 삭제합니다.

  5. 단기 Token을 폐기하거나 버립니다.

  6. TUN을 닫습니다.

  7. 시스템 라우팅을 복원합니다.

  8. DNS를 복원합니다.

  9. 불필요한 임시 설정을 삭제합니다.

클라이언트가 갑자기 충돌하더라도 운영체제 또는 다음 실행 시 복구 절차를 수행해 다음 문제가 남지 않도록 해야 합니다.

  • 유효하지 않은 시스템 프록시

  • 잘못된 DNS

  • 잔여 라우팅

  • 인터넷 연결 불가

다음 표는 SingLink Beta와 SingLink 2.0의 기술적 포지셔닝을 정리한 것입니다.

처리 항목

SingLink Beta

SingLink 2.0

핵심 방향

최고 속도

속도, 안정성, 호환성

연결 매개변수

비교적 적극적

적응형이며 비교적 보수적

동시 연결 정책

더 높은 동시성을 사용할 수 있음

단일 트래픽의 채널 독점 방지

전송 창

고속 처리량에 중점

지연 및 패킷 손실에 따라 동적 조정

노드 전환

고속 노드를 더 빠르게 시도

장애 확인 후 전환

다중화

다중화 효율 향상에 중점

다중화와 장애 격리의 균형

Padding

오버헤드 절감 우선

환경에 따라 적응

네트워크 전환

기본 복구

더 완전한 복구 및 호환성

플랫폼 회귀 테스트

프리뷰 범위

정식 전체 테스트

내부 안정성

약 97%

99.5%

속도

적합한 환경에서 1 Gbps 이상 가능

높은 속도를 유지하되 최고 속도만 추구하지 않음

한 문장으로 정리한 전체 처리 원리

SingLink는 먼저 클라이언트에서 기기 트래픽을 넘겨받아 DNS, 스마트 분할 라우팅 및 노드 선택을 수행합니다. 이어 계정과 노드 권한을 검증하고 노드와 프로토콜 기능을 협상한 뒤 임시 암호화 키를 생성합니다. 연결이 수립되면 각 애플리케이션의 TCP 및 UDP 트래픽을 독립 프록시 연결 또는 논리 Stream으로 캡슐화하여 보호된 채널을 통해 노드로 보내고, 노드가 대상 웹사이트에 접속합니다. 전송 과정에서는 트래픽 창, 데이터 무결성, 지연 시간, 패킷 손실, 하트비트 및 노드 상태를 지속적으로 관리합니다. 네트워크 전환이나 노드 장애가 발생하면 세션을 다시 생성하고 라우팅을 복구하거나 사용 가능한 노드로 전환합니다.

Beta와 2.0의 본질적인 차이는 다음과 같습니다.

SingLink Beta는 최고 속도를 더 적극적으로 추구합니다. SingLink 2.0은 고속 전송에 더해 완전한 호환성, 상태 점검, 장애 판단, 세션 복구 및 플랫폼 간 처리를 제공하므로 안정성이 더 높습니다.

자주 묻는 질문

SingLink 2.0은 SingLinkVPN이 자체 개발한 정식 네트워크 전송 프로토콜로, 신원 인증, 암호화 세션, 트래픽 캡슐화, TCP 및 UDP 전송, 상태 점검과 장애 복구를 담당합니다.

아닙니다. SingLink 2.0은 프로토콜의 공식 명칭이며 Windows, macOS, Android 및 iOS 클라이언트 버전과는 별개의 버전 체계입니다.

Beta는 속도를 우선하는 프리뷰 프로토콜로 적합한 조건에서 1 Gbps 이상의 최고 속도에 도달할 수 있습니다. 2.0은 속도, 안정성, 플랫폼 간 호환성 및 연결 복구를 중시하는 정식 프로토콜입니다.

SingLinkVPN이 지정한 테스트 환경의 내부 A/B 테스트에서 SingLink 2.0의 안정성은 99.5%, Beta는 최고 약 97%였습니다.

SingLink는 네트워크 트래픽을 어떻게 처리하나요?

클라이언트가 먼저 시스템 트래픽을 넘겨받아 DNS와 스마트 분할 라우팅을 처리한 뒤 계정 및 노드 권한을 검증하고 암호화 세션을 생성하여 TCP 또는 UDP 데이터를 캡슐화한 다음 노드로 전송합니다.

SingLink는 연결 끊김을 어떻게 처리하나요?

시스템은 지연 시간, 패킷 손실, 하트비트 및 노드 상태를 지속적으로 점검합니다. 이상이 발생하면 세션을 다시 생성하고 라우팅을 복구하거나 사용 가능한 노드로 전환할 수 있습니다.

SingLink와 VLESS는 어떻게 다른가요?

VLESS의 핵심은 주로 신원, 명령 및 대상 전달입니다. SingLink는 신원, 라우팅, 노드 권한, 전송 정책, 상태 점검 및 장애 복구를 하나의 프로토콜 체계로 통합합니다.

SingLink와 AnyTLS는 어떻게 다른가요?

AnyTLS는 주로 TLS 연결을 통해 Session과 여러 Stream을 운반합니다. SingLink는 스마트 라우팅, 회원 권한, 노드 스케줄링 및 연결 복구까지 포함하는 더 넓은 범위의 체계입니다. 구체적인 Session 및 Stream 구현은 공식 기술 문서를 기준으로 확인해야 합니다.

SingLink 2.0 정식 프로토콜 노드는 Pro, Max, Rich 회원이 이용할 수 있으며, Beta 프로토콜은 무료 플랜을 포함한 모든 요금제에서 이용할 수 있습니다. 실제 권한은 최신 클라이언트에 표시되는 내용을 기준으로 합니다.

현재 핵심 프로토콜의 전체 소스 코드는 아직 공개되지 않았지만 기술 문서, 테스트 방법, 데이터 형식, 검증 도구 및 취약점 공개 체계는 지속적인 오픈 소스 계획에 포함되어 있습니다.

관련 자료 및 더 읽을거리

이 글의 제품 포지셔닝과 공개 범위는 SingLinkVPN 공식 기술 센터, SingLinkLabs 공개 연구 저장소 및 해당 저장소의 성능 테스트 방법론을 함께 참고했습니다.

그 밖의 관련 내용은 SingLinkVPN 무료 플랜 전체 가이드, SingLinkVPN 오픈 소스 계획 및 2026년 SingLinkVPN 보안 감사 보고서에서 확인할 수 있습니다.

기술 안내: 이 글의 99.5%, 97% 및 1 Gbps 이상이라는 수치는 각각 지정된 환경에서 진행한 내부 A/B 테스트와 최고 속도 테스트의 결과이며 모든 지역, 기기, 네트워크 사업자 및 시간대에서 동일한 결과를 보장하지 않습니다. 구체적인 암호화 알고리즘, 패킷 형식, Session 및 Stream 메커니즘은 향후 공개될 SingLink 공식 기술 문서와 소스 코드를 기준으로 판단해야 합니다.