TASFA: 파일 전송의 꽃, 미디어를 지원하기까지

첫 단추: 기본 TASFA에서 TASFA-MEDIA로

일단, 기본 TASFA의 경우 간단한 HTML, PNG 등을 퍼 나르기엔 좋았지만, 특정 청크를 시작 지점으로 하여 비디오 스트리밍을 하기에는 충분하지 못하였습니다. 또한, TASFA는 초기 아이디어에서 검증용 프로토콜이지 병렬성을 충분히 강화한 프로토콜이 아니었습니다. 솔직하게 말하자면, 나이지리아<=>한국 거리에서 터져 나가는 기묘하기 짝이 없는 RTT나 잡아 내려고 헛짓을 하던 것이 시초니까요.

블로그의 참고용 이미지 하나 못 올리면, 말주변이 없는 저는 죽어 나갑니다.

그래서 굉장히 단순무식하게, "나는 경상도 사람이고 사나이니까" 같은 마음으로 무턱대고 TASFA 검증 레이어를 통해 이미지가 죽지 않고 도달하게 만들었습니다.

TASFA의 페이싱 등은 비교적 명확합니다. 순서없이 보내고 순서를 맞추며, Wynn 엡실론, Aitken Delta Square 등을 이용해서 다음 패킷까지의 지연 등을 예측하여서, 모든 송수신을 결정론적인 연산 안에 가두어 네트워크의 응답을 가능한 한 클라이언트가 예측 가능하게 만들기 위한 것이 곧 TASFA의 알파이자 오메가입니다.

그러나, 이것은 역시 문제를 불러 일으켰습니다.

TASFA는 항상 첫 청크부터 받는다

기본적으로 TASFA는 주소 0부터 순차 청크 검사를 수행하며, 중간에 청크가 빠지면 재전송 요청을 합니다. 이것은 작은 파일에서는 유효하지만, 100MB짜리 라이브 콘서트 실황을 보낼 때는 유효하지 못합니다. 따라서, 씨없는수박 김대중 아저씨의 멋진 블루스 한 곡조를 들으려면 이런 일이 벌어졌습니다.

영상 하나 보려고 5분을 기다려야 해?

TASFA-MEDIA: 100M 회선에서도 1000M 못지 않은 경험을

이런 문제를 가장 빠르게 해결하는 것은 작은 청크를 아주 많이 동시에 보내서, 클라이언트에서 결합하는 것이었습니다. 직관적으로 비유하자면, 모래시계 뒤집듯 모래를 빠르게 반대로 흘려 보낸다고 해야겠죠. 작은 청크들은 찔끔찔끔 클라이언트에 도달해서 일종의 방진인 지수귀문도의 규칙에 따라 순서 복구 후 조립되었습니다.

1000M 기가비트 인터넷: 이건 모래시계가 아닌 고무 호스잖아

일단, 1000M 짜리 기가비트 인터넷은 고무 호스같았습니다. 이걸 모래알 1개에 빗대어 연결하면, 유리는 박살나겠죠. 그것과 마찬가지로, 인턴십이 끝나고 본가에 내려와서 사랑스런 나의 블로그에 접속하자마자 크롬 브라우저는 싸이버 싸이코 증세를 보이며 죽었습니다!

네, 말 그대로 창이 깨지고 난리가 났습니다. 이것을 방지하기 위해서는 병렬성 강도를 낮추고, 1개의 청크를 키우는 것이 해법이었습니다.

TASFA-FAST: 데이비드는 안정제가 필요해요

싸이버 싸이코에 걸린 데이비드가 제정신을 되찾기 위해 안정제를 꽂습니다. 걱정스럽게 쳐다보던 우리의 귀여운 레베카가 호떡처럼 눌려 죽은 것은 뒤로 하고...

우선, 1000M이라는 이 폭주하는 사이보그에게는 안정제가 필요합니다. 즉 힘은 빌리되 폭주를 하지 않게 해야 한단 것이죠. 이 때, 앞선 고무 호스 비유를 생각해 보면, 병렬성을 줄인다는 것이 와닿습니다.

여러분, 1000개의 고무 호스가 물을 쏩니다. 아니, 1개로도 사람이 죽습니다. 모 농성에서 시위자 백 모 씨가 몇 년 전 투쟁하다 산화하셨죠.

보세요, 서버는 대통령이고 독재자입니다. 클라이언트는 서버의 압제 아래에서 파리 목숨이죠. 클라이언트가 피켓만 들고 있으면, 서버는 경찰 차를 끌고 고무 호스를 쏩니다. 1개로도 죽는데, 10개면 클라이언트의 살이 터져 나갑니다.

그렇다면 이토록 위험한 고무 호스를 수십 개 쏟아붓자는 것은 현실이었으면 살인 병기입니다. 따라서, 고무 호스는 적절한 개수로, 적절한 수압으로 사용해야 합니다.

그러나, 모래 1알이 모래시계에서 떨어지는 속도로 물을 흘려 보내려고 하면 몇 방울 흘려 보내려고 해도 이미 호스 벽에 묻어 사라질 겁니다. 마찬가지로, UDP 기반의 HTTP/3에서는 벽에 묻는 물을 통제하는 것이 일입니다.

비유하자면, QUIC은 고무고, 패킷은 물입니다. 그리고 사용자가 애플리케이션 계층에서 1L의 물을 정확하게 받으려면, "1ml 모자라니 다시 주세요" 같은 것을 영민하게 하는 편이 고무 호스를 뿌려 주는 서버 그리고 통에 물을 받는 클라이언트 양쪽에게 안전합니다.

현재의 결론

현재의 결론은 단순합니다. 간단한 이미지는 기본 TASFA, 미디어일 경우 100M에서 TASFA-MEDIA, 500M 이상에서 TASFA-FAST를 사용합니다.

스트리밍의 UX는 단순하고, 사용자는 많은 것을 느끼지 못합니다. 하지만 뒤에서의 최적화는 기술자의 영역입니다. 개발자라는 기술자는 시계공과 달리 무브먼트로 예술을 하지도 못합니다.

빠른 유튜브 스트리밍은 아름답지만, 우리는 그 뒷부분을 모릅니다. 예쁜 웹사이트는 눈이 즐겁지만, 우리는 그 웹사이트가 React.JS를 쓰는지 Next.js를 쓰는지도 모릅니다.

그러나, 프로그래머라는 기술인은 그런 것이라고 믿습니다.

보이지 않는 것에서 보이는 것을 아름답게 한다면, 과시하지 못해도 좋은 것이 기술일까요.