신규: Helius가 Light Protocol을 인수했습니다
스팸을 QUIC하게 완화하는 방법: Solana와 QUIC의 모든 것
블로그/기초

스팸을 QUIC하게 완화하는 방법: Solana와 QUIC의 모든 것

Developer Experience EngineerX의 0xIchigoLinkedIn의 0xIchigoGitHub의 0xIchigo
읽는 데 12분

이 글에서는 무엇을 다루나요?

Solana는 현재 시장에서 가장 빠르고 확장성이 뛰어난 블록체인입니다. 빠른 트랜잭션 속도로 잘 알려져 있어 다양한 사용 사례에 적합한 체인입니다. 이러한 성과에도 불구하고 Solana 네트워크는 다운타임과 관련된 공포, 불확실성, 의심을 뜻하는 이른바 FUD의 대상이 되어 왔습니다. 과거에는 이러한 FUD가 타당한 우려였지만, 현재는 근거가 없습니다. 그 이유는 무엇일까요? Solana Labs 엔지니어들은 지난 1년 동안 다양한 네트워크 업그레이드를 진행했습니다. 가장 주목할 만한 변화는 트랜잭션 수신에 사용하던 Solana의 맞춤형 원시 UDP 기반 프로토콜을 QUIC으로 교체한 것입니다.

이 글에서는 네트워크 프로토콜과 TCP, UDP의 작동 원리를 살펴보고 QUIC이 두 프로토콜을 어떻게 개선하는지 알아봅니다. 이어서 Solana에 초점을 맞춰 QUIC이 제공하는 구체적인 이점을 설명합니다. 이 네트워크 업그레이드가 Solana에 중요한 기술적 이정표인 이유를 종합적으로 이해하는 것이 이 글의 목표입니다.

Solana 네트워크 업그레이드

2022년 12월 13일, Solana Foundation은 “Solana 네트워크 업그레이드”라는 제목의 소식을 게시했습니다. 이 글에서는 네트워크에 적용 중인 여러 업그레이드와 각각의 진행 상황을 설명했습니다. 업그레이드 목록은 다음과 같습니다.

QUIC

  • 현재 Mainnet-beta에서 운영 중

스테이크 가중 QoS

  • 현재 Mainnet-beta에서 운영 중

수수료 시장

  • 현재 Mainnet-beta에서 운영 중이며 RPC 및 지갑 지원이 곧 제공될 예정입니다
  • 진행 상황은 여기에서 확인할 수 있습니다

트랜잭션 크기 확대

  • 현재 개발 중

압축 투표 상태

  • 현재 Testnet에서 운영 중

Solana가 과거에 다운타임을 겪었던 주요 원인 중 하나는 스팸이었습니다. 몇 가지 사례는 다음과 같습니다.

  • 2021년 9월 14일 Grape IDO 스팸
  • 2022년 1월 6~12일 발생한 DDoS 공격
  • 2022년 4월 30일~5월 1일 발생한 NFT 민팅 스팸

QUIC 도입 이후 Solana에서는 스팸과 관련된 다운타임이 보고되지 않았습니다. 이는 QUIC이 Solana의 네트워크 트래픽과 데이터 수신을 개선한 중요한 성과임을 보여줍니다. QUIC을 알아보기 전에 먼저 네트워크 프로토콜의 작동 원리를 살펴봐야 합니다. 네트워크의 기본 원리를 더 잘 이해하면 QUIC이 Solana 네트워크에 미치는 실질적인 영향을 파악할 수 있습니다.

네트워크 프로토콜이란 무엇인가요?

네트워크 프로토콜은 같은 네트워크에 있는 기기 간에 데이터를 전송하는 방법을 규정한 일련의 규칙입니다. 네트워크 프로토콜을 사용하면 연결된 기기는 내부 구조나 설계와 관계없이 서로 원활하게 통신할 수 있습니다.

파리의 한 레스토랑에서 친구와 마주 앉아 있다고 상상해 보세요. 두 사람 모두 프랑스어로 대화하기로 결정하면 대화가 자연스럽게 이어집니다. 프랑스어를 사용하기로 한 공동의 결정은 양측이 이해하는 문법 규칙, 어휘, 발음 체계에 합의한 것과 같습니다.

프랑스어가 파리의 레스토랑에서 나누는 대화의 “프로토콜” 역할을 하는 것처럼, 네트워크 프로토콜도 연결된 네트워크 기기에서 비슷한 방식으로 작동합니다. TCP, UDP 또는 QUIC을 사용하기로 결정하는 것은 정보 교환을 위한 정해진 규칙과 관례에 합의하는 것입니다. 특정 네트워크 프로토콜을 따르면 연결된 기기들이 혼선 없이 서로를 이해할 수 있습니다.

TCP란 무엇인가요?

전송 제어 프로토콜(Transmission Control Protocol, TCP)은 네트워크의 두 엔드포인트 간에 데이터 스트림을 전송하기 위한 표준 통신 인터페이스입니다. Vint Cerf와 Bob Kahn은 단일 구조의 전송 제어 프로그램을 개발했고, 이를 TCP와 인터넷 프로토콜(IP)로 구성된 모듈형 아키텍처로 분리했습니다. 전체 프로토콜 모음은 TCP/IP라고 합니다. 이 글에서 TCP라는 약어는 전체 프로토콜 모음이 아니라 전송 제어 프로토콜만을 의미합니다.

TCP는 연결 지향형입니다. 데이터를 전송하기 전에 클라이언트와 서버 사이에 연결을 설정해야 합니다. TCP는 연결을 설정하기 위해 동기화(SYN), 동기화-확인(SYN-ACK), 확인(ACK)의 3단계 핸드셰이크를 사용합니다. SYN은 악수를 청하며 상대방에게 대화할 준비가 되었는지 묻는 것과 같습니다. SYN-ACK은 상대방이 악수하며 대화할 준비가 되었다고 말하고 계속할지 묻는 것입니다. ACK는 다시 악수하며 대화를 계속하겠다고 답하는 것입니다. 이렇게 세션이 설정됩니다. 양측은 서로 연결되었다는 사실을 알고 있으며 정보를 공유할 준비가 되었다는 데 동의합니다.

TCP는 데이터를 패킷으로 나누어 네트워크를 통해 전송합니다. 각 패킷에는 소량의 추가 데이터가 포함됩니다. 이 추가 데이터에는 손실되거나 순서가 어긋난 패킷을 감지하는 데 쓰이는 시퀀스 번호와 패킷 내부의 오류를 감지할 수 있는 체크섬이 포함됩니다.

대화가 중단되면 상대방의 말을 정확히 들었는지 확인하기 위해 다시 말해 달라고 요청합니다. TCP는 자동 재전송 요청(Automatic Repeat Request, ARQ)을 통해 중단을 비슷한 방식으로 처리합니다. 문제가 발생하면 ARQ가 송신자에게 손상되거나 손실된 패킷을 다시 보내도록 요청합니다. 그런 다음 TCP는 데이터 전송 속도를 낮추도록 알리고, 전송 중일 수 있는 미확인 패킷 수를 제한합니다. 오류가 해결되면 TCP는 혼잡을 방지하는 메커니즘을 적용하면서 속도를 점진적으로 높입니다.

TCP는 모든 트래픽의 순서를 보장하므로 모든 사용 사례에 적합한 프로토콜은 아닙니다. 데이터 일부가 손실되거나 손상되면 그 패킷 이후의 모든 데이터가 기다려야 합니다. 하지만 기다릴 필요가 없다면 어떨까요?

UDP란 무엇인가요?

사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)은 네트워크를 통해 데이터를 전송하는 데 사용되는 표준 통신 인터페이스입니다. TCP와 달리 UDP는 비연결형이며 데이터 패킷의 전달, 순서 또는 중복 여부를 보장하지 않습니다. UDP에는 핸드셰이크 과정이 없으므로 기반 네트워크의 불안정성이 데이터 전송에 그대로 영향을 줄 수 있습니다. 목적지와의 연결 설정에 시간을 쓰지 않기 때문에 다른 프로토콜보다 빠릅니다. 하지만 이 특성 때문에 UDP를 “신뢰할 수 없는 데이터그램 프로토콜(Unreliable Datagram Protocol)”이라고 부르기도 합니다.

UDP는 네트워크를 통해 데이터그램을 전송하는 방식으로 작동합니다. 데이터그램은 출발지에서 목적지까지 라우팅하는 데 필요한 정보를 포함한, 보다 독립적인 데이터 단위입니다. 이 정보가 자체적으로 포함되어 있으므로 라우팅할 때 다른 데이터그램에 의존하지 않습니다. 데이터그램은 헤더와 데이터로 구성됩니다. 헤더에는 각각 16비트 길이인 네 개의 필드가 있습니다. 선택적 출발지 포트, 목적지 포트, 길이, 선택적 체크섬입니다. 전송 과정은 다음과 같습니다.

  • 송신 애플리케이션이 UDP 소켓을 생성합니다
  • 송신 애플리케이션이 전송할 데이터를 UDP 데이터그램에 넣고, 목적지 포트와 기타 관련 정보를 담은 헤더를 추가합니다
  • 데이터그램을 라우팅 및 전달을 위해 IP 계층으로 보냅니다
  • IP 계층이 데이터그램을 UDP 계층으로 전달하며 이때 헤더가 제거됩니다
  • 지정된 포트에서 수신 대기 중인 애플리케이션으로 데이터그램을 보냅니다

UDP를 시끄럽고 붐비는 방 건너편에 있는 사람과 대화하는 상황에 비유해 보세요. 상대방이 들었는지 걱정하거나 답을 기다리지 않고 소리칩니다. 긴 대화를 나누지 않고 메시지를 빠르게 전달하려는 것입니다. 상대방이 말한 내용을 전부 듣지 못했을 수도 있어 위험하지만, 매우 효과적일 수도 있습니다.

TCP처럼 더 신뢰할 수 있는 방식이 있는데도 UDP 같은 비연결형 통신 프로토콜을 사용하는 이유는 무엇일까요? UDP는 시간에 민감한 애플리케이션이나 일부 데이터 손실을 허용할 수 있는 상황에서 매우 유용합니다. 친구들과 비디오 게임을 할 때 몇 프레임이 누락되는 편이 계속 멈추고 버퍼링되는 것보다 훨씬 낫습니다. UDP는 VoIP 통화, 도메인 이름 시스템(DNS) 쿼리, 모니터링 및 로깅에도 사용됩니다.

QUIC: 효율성과 신뢰성의 균형

QUIC은 2013년 Google의 Jim Roskind가 설계한 현대적인 전송 계층 프로토콜입니다. TCP의 신뢰성과 UDP의 낮은 지연 시간이라는 이점을 결합해 빠르고 안전한 비동기 통신에 최적화된 환경을 제공합니다. QUIC은 TCP의 특징인 보안 세션과 고급 흐름 제어 전략을 UDP가 제공하는 더 유연하고 빠른 프레임워크에 통합했다는 점에서 차별화됩니다.

QUIC은 암호화 키와 프로토콜 세부 정보의 교환을 초기 핸드셰이크에 통합해 연결 설정을 간소화합니다. 이 과정은 항상 전송 계층 보안(TLS)으로 안전하게 암호화됩니다. 이 프로토콜은 UDP를 통한 다중화 연결을 지원하므로 여러 독립적인 데이터 스트림이 서로 영향을 주지 않고 각 엔드포인트에 도달할 수 있습니다. QUIC은 각 스트림의 흐름을 독립적으로 제어합니다. 따라서 한 스트림에서 오류가 발생해도 다른 스트림을 방해하지 않습니다. 이는 TCP 연결에서 자주 발생하는 문제인 HOL 블로킹, 즉 첫 번째 패킷 때문에 패킷 행렬 전체가 큐에서 대기하는 현상을 방지하는 데 도움이 됩니다.

패킷이 손실되거나 손상되면 QUIC은 데이터를 지능적으로 재전송해 통신의 무결성과 연속성을 유지합니다. 또한 QUIC은 네트워크 환경 변화에 강합니다. 각 패킷에는 출발지와 관계없이 서버 연결을 고유하게 식별하는 연결 식별자가 포함됩니다. 모든 패킷에 이 ID가 있으므로 다른 패킷을 보내 연결을 다시 설정할 수 있으며, 기존 연결도 계속 유효합니다. 비유하자면 다른 방으로 이동해도 대화가 끊기지 않고 자연스럽게 이어집니다.

다시 한번 붐비는 방에서 친구와 대화한다고 상상해 보세요. 이번에는 암호화된 무전기를 사용해 안전하고 명확하게 대화할 수 있습니다. 여러 주제로 대화를 나누는 동안 친구는 각 메시지를 들을 때마다 엄지손가락을 들어 확인해 줍니다. 친구가 이해하지 못한 표정을 지으면 해당 메시지를 다시 말해 어떤 내용도 잘못 전달되지 않도록 합니다. 두 사람 중 한 명이 다른 방으로 이동해도 대화는 끊기지 않습니다. 이것이 바로 QUIC의 핵심입니다. 견고하고 적응력이 뛰어나며 효율적인 통신입니다.

Solana가 QUIC을 구현하는 방식

QUIC은 Solana에 다음과 같은 여러 이점을 제공합니다.

  • 연결 설정 시간 단축: QUIC은 핸드셰이크 프로세스를 최적화해 지연 시간을 최소화합니다
  • 다중화 및 효율적인 패킷 관리: QUIC은 HOL 블로킹 없이 여러 데이터 스트림을 동시에 처리해 트랜잭션 처리량과 효율성을 높입니다
  • 적응성 및 복원력: 이 프로토콜은 변화하는 네트워크 환경에 적응하도록 설계되었습니다. 이는 Solana와 같은 분산형 탈중앙화 시스템에 꼭 필요한 요건입니다
  • 네트워크 최적화를 위한 맞춤화: QUIC은 유연성이 높아 Solana처럼 특정 네트워크 성능 및 보안 목표에 맞춘 구현이 가능합니다

QUIC은 사용자 트랜잭션을 수신하는 포트에 추가되었습니다. 이를 통해 특정 주체의 트래픽을 제한하고 네트워크가 실제 트랜잭션 처리에 집중할 수 있습니다. QUIC은 Solana에서 운영 중이며 릴리스 1.13.4부터 Mainnet-beta에 완전히 도입되었습니다. 통합 이후 네트워크의 안정성과 처리량이 눈에 띄게 개선되었습니다.

이러한 발전에도 불구하고 최근의 네트워크 혼잡으로 인해 Solana의 이전 UDP 구현과 비교한 QUIC의 컴퓨팅 효율성을 두고 논쟁이 벌어졌습니다. 비판하는 측은 원시 UDP 방식을 사용할 때 검증인이 핸드셰이크 스팸과 암호화를 관리하는 대신 트랜잭션 처리에만 집중할 수 있었다고 지적합니다. 또한 Solana 구현에서는 키 교환과 검증이 초기 핸드셰이크에 포함되지 않습니다. Solana는 IP 주소를 검증하기 위해 “챌린지 패킷”을 보내는 QUIC 옵션을 사용합니다. 이 챌린지의 핵심은 핸드셰이크 첫 단계에서 인증서를 검증하는 대신, IP 검증 후 핸드셰이크 두 번째 단계에서 검증하는 것입니다. 지난 2월 Solana의 네트워크 중단을 서비스 거부로 볼 수도 있기 때문에, Solana가 스팸이나 DDoS 공격과 관련된 다운타임을 겪었는지는 여전히 논쟁의 여지가 있습니다.

네트워크가 발전함에 따라 네트워크에 적용된 구현을 지속적으로 검토하고 개선하는 것이 중요합니다. QUIC은 TCP와 UDP의 여러 문제를 해결하려 하지만, 지금까지의 결과를 돌아보면 그 효과에는 논쟁의 여지가 있습니다. 하드웨어에서 어떻게 작동하는지도 중요하게 고려해야 합니다. TCP는 구조가 단순하기 때문에 하드웨어에서 QUIC보다 훨씬 효율적으로 작동합니다. AES 명령어 세트를 사용하면 TCP 기반 프로토콜이 QUIC보다 처리량이 높고 TPS 측면에서도 더 효율적이라고 충분히 주장할 수 있습니다.

특히 Jump Crypto 팀은 QUIC의 한계를 확장하고 있습니다. 이 팀은 Solana의 새로운 검증인 클라이언트인 Firedancer를 개발하면서 자체적으로 견고하고 확장 가능한 구현을 만들었습니다. Firedancer의 네트워킹은 하드웨어 가속 부하 분산 방식인 수신 측 스케일링을 활용하도록 처음부터 설계되었습니다. 이 병렬 아키텍처를 통해 각 CPU 코어가 유입 트래픽의 일부를 효율적으로 처리할 수 있습니다. 팀은 다음과 같이 게시했습니다.

Firedancer의 QUIC 기술 이정표에 관한 데모와 스레드는 여기에서 확인할 수 있습니다.

결론

축하합니다! 이 글에서는 TCP와 UDP의 역할과 이들이 QUIC으로 발전한 과정에 초점을 맞춰 네트워크 프로토콜의 기본 원리를 살펴봤습니다. 또한 Solana의 QUIC 구현을 알아보고 네트워크 개선에서 QUIC이 담당한 핵심 역할을 설명했습니다. QUIC을 통해 스팸 및 DDoS 공격에 대한 Solana 네트워크의 복원력은 향상되었지만, 네트워크가 성장하면서 컴퓨팅 효율성과 세부 구현 방식을 둘러싼 과제와 논쟁도 드러났습니다.

QUIC은 처리량이 높고 지연 시간이 짧은 네트워크를 구현하려는 Solana의 핵심 목표를 잘 보여줍니다. 다중화와 패킷 손실 복구 기능은 Solana를 성능 및 확장성 논의의 최전선에 올려놓았습니다. Firedancer 팀의 구현은 QUIC의 뛰어난 적응성을 보여주며, 변화하는 네트워크 요구 사항에 맞춘 최적화의 잠재력을 입증합니다.

Solana 개발자가 QUIC을 이해하면 애플리케이션 아키텍처부터 트랜잭션 오류에 이르는 다양한 주제에서 더 나은 결정을 내릴 수 있습니다. Solana는 끊임없이 발전하며 QUIC도 마찬가지입니다. Solana에서 성능이 뛰어난 애플리케이션을 구축하려면 최신 네트워크 변경 사항을 지속적으로 확인해야 합니다. 개발자가 아니더라도 QUIC을 기술적으로 더 깊이 이해하면 Solana가 왜 속도와 확장성으로 잘 알려진 고성능 블록체인인지 이해하는 데 도움이 됩니다.

익명의 독자 여러분, 여기까지 읽어주셔서 감사합니다! 아래에 이메일 주소를 입력하고 Solana의 새로운 소식을 빠짐없이 받아보세요. 더 깊이 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 이어가세요.

추가 자료 / 더 읽어보기

Helius 구독하기

최신 Solana 개발 소식을 확인하고 새 게시물 알림을 받아보세요

확대 이미지