L4S로 네트워크 지연 줄이기

♪ ♪

안녕하세요 저는 Shawn입니다 Internet Technologies 팀 엔지니어죠 오늘은 앱에서 L4S를 통해 네트워크 딜레이를 줄이는 방법에 대해 말씀드리려고 합니다 L4S가 나타내는 것은 각각 '저대기시간' '저손실' '확장 가능 처리량'입니다 네트워크 대기 시간이 사용자 경험에 영향을 미칠 수 있는 앱의 성능을 극적으로 개선하는 놀라운 기술입니다 혜택을 몇 가지 들어보면 말이죠 콘텐츠 로딩 타임 감소 영상 품질 개선 사용자 간 즉각 반응 협력 확대가 있습니다

오늘은 먼저 L4S의 작동 원리를 탐색하고 이게 네트워크 대기 시간을 어떻게 줄여주는지 보겠습니다 그다음 L4S에 대해 앱을 준비시키는 방법과 서버에서 L4S를 켜는 방법에 대해 알아보고요 마지막으로 L4S 네트워크를 구성하고 앱을 테스트하기 위해 취해야 하는 단계를 살펴봅시다 먼저 L4S의 장점과 작동 원리를 살펴볼게요

복잡한 네트워크의 경우 실시간 음성이나 영상 등의 특성에 의존하는 앱에 있어서는 특히 문제가 됩니다 네트워크가 한번에 너무 많은 기기에서 사용되면 이런 종류의 앱에서는 대기 시간과 패킷 손실이 늘어나고는 하죠 예를 들어 동일한 네트워크를 사용 중인 다른 누군가가 영화를 보고 있다면 화상 회의 중인 여러분의 영상이 끊기거나 멈추는 현상을 경험할 수 있게 되는 겁니다 L4S가 그런 상황에서 얼마나 도움이 되는지 보여드리려고 두 기기 사이에서 영상 통화를 할 수 있는 샘플 앱을 만들었는데요 이 샘플 앱으로 다른 시간에 이루어진 영상 통화 두 차례의 예시를 보여드릴게요 하나는 L4S를 끈 상태 다른 하나는 켠 상태입니다 두 통화 모두 대역폭이 낮은 동일한 제한 네트워크를 사용했고요 같은 네트워크를 동시에 활발하게 사용 중인 다른 기기들도 있습니다 어떻게 돌아가는지 함께 보시죠 두 영상 품질에서 극명한 차이가 보일 겁니다 왼쪽 영상은 영상이 간혹 멈추거나 지연되죠 특히 움직일 때요 하지만 오른쪽에서는 영상이 매끄럽게 즉각 반응하죠 눈에 띄는 지연은 발생하지 않았습니다 이제 어떤 차이가 있는지 이해하기 위해 두 영상을 함께 분석해 봅시다 이 데모에서 L4S는 모든 주요 네트워킹 지표에서 앱이 상당한 개선을 달성할 수 있도록 해줬는데요 먼저 영상 통화 중 패킷 왕복 시간의 분포를 살펴볼게요 왕복 시간이 더 짧다는 것은 네트워크에서 배터리 대기 시간이 더 짧다는 것을 뜻합니다 이런 상호작용 앱 같은 경우 꼬리 대기 시간이 중요하죠 사용자가 경험할 수 있는 최악의 경우를 보여주니까요 우리 테스트 네트워크에서는 최소 왕복 시간이 20밀리초였네요 하지만 L4S가 없다면 패킷 왕복 시간은 최대 45밀리초가 될 겁니다 그런데 L4S를 켤 경우에는 대기 시간이 최악이라고 해도 50%까지 줄어들어 결국 25밀리초 미만이 되죠

이번에는 패킷 손실에 대해 이야기해 보죠 패킷 손실이 낮다는 것은 기기 간 연결의 신뢰 가능성이 더 높다는 겁니다 기존 시스템 패킷 손실율은 40% 이상이었습니다 하지만 L4S에서는 패킷 손실이 거의 없죠 데이터 손실로 인한 프레임 드롭이나 멈춤이 적다는 겁니다 대기 시간과 패킷 손실율이 개선되었다는 것은 영상 통화의 렌더링 지표가 더 낫다는 것과 같은 말이죠 먼저 영상 통화 멈춤 비율을 살펴봅시다 멈춤 비율이 낮다는 것은 통화 중 정지가 적었다는 거죠 L4S가 없는 경우에는 간혹 영상 멈춤을 경험할 수 있었습니다 그런데 L4S를 켰을 때는 그게 거의 다 사라졌죠

다음으로는 수신 비디오의 프레임 레이트를 볼게요 이 레이트가 더 높고 일관적이라는 것은 영상 통화의 질이 더 좋고 매끄러웠다는 겁니다 L4S를 켠 경우에는 그 수치가 대부분 초당 25프레임 이상이었죠 그런데 기존 시스템에서는 초당 0프레임도 나타났습니다 그럼 영상이 완전히 멈췄다는 건데요 종합해 보면 이런 개선은 제한 네트워크 내에서도 훨씬 더 나은 사용자 경험을 선사합니다 L4S를 채택하여 여러분의 앱에도 이런 개선을 이루어 보세요 이제 L4S의 작동 원리를 살펴보겠습니다

앞서 놀랍게 개선된 결과를 살펴볼 수 있었는데요 L4S가 대기열과 패킷 손실을 줄였기 때문이었죠 먼저 네트워크에 대기 시간이 어떻게 생기는 건지 살펴봅시다 패킷이 앱에서 송신되면 여러 네트워크 홉을 통해 라우팅되고 나서 서버에 도달합니다 패킷이 통과하는 이 홉들을 '네트워크 패스'라고 하는데요

하나의 네트워크 경로에서는 데이터를 엔드투엔드로 가장 느린 홉이 지원하는 속도에서만 전달할 수 있습니다 이걸 '병목 현상'이라고 하죠 이는 많은 사람들에게 인터넷 서비스 제공을 연결하는 것으로 이 연결이 처리할 수 있는 가장 높은 속도가 해당 경로에서 지원하는 최대 처리량을 결정합니다 송신자가 최대 처리량을 초과하는 경우에는 병목 지점에서 대기열이 생겨 이후 패킷에도 지연이 발생하죠 L4S가 없다면 대기열은 계속 늘어나 더이상의 패킷을 받아들일 수 없게 될 겁니다 이렇게 되면 패킷이 드롭되어 대기 시간과 처리량 모두에 영향이 가죠 L4S는 클라이언트와 서버 병목지점 사이의 협력을 통해 이 문제를 해결했습니다 L4S가 있으면 패킷을 보내는 클라이언트나 서버에는 네트워크 폭주 공동 관리 예정 신호를 보내야 하는데요

이를 위해서 L4S를 이용할 수 있는 송신자는 '명시적 폭주 통지'라는 기술을 사용할 겁니다 ECN이라고도 알려져 있죠 패킷을 보낼 때 송신자는 L4S가 지원된다고 알려줍니다 패킷의 IP 헤더에 있는 ECN 비트를 사용해서 말이죠 L4S 홉이 이런 패킷을 받게 되는 경우 그 패킷들에 L4S 대기열 관리를 적용하죠

대기열이 병목 지점에서 구축을 시작하면 L4S 대기열 관리는 폭주가 있다고 알립니다 패킷에서 다른 ECN 라벨을 설정해서 말이죠 이 라벨은 네트워크가 패킷을 다음 홉으로 전송하기 전에 폭주를 경험했다는 것을 나타냅니다 수신자는 이 패킷을 받자마자 폭주 표시된 패킷의 수를 세고 그 수를 다시 송신자에 보고합니다 송신자가 이 수를 받게 되면 피드백을 사용해 네트워크의 폭주를 이해하죠 그럼 송신자는 송신 속도를 조정합니다 병목 지점에서의 폭주 수준에 따라서요 그래야 최대 처리량을 넘지 않을 수 있으니까요 송신자는 이 조절을 통해 병목 지점에서 패킷의 긴 대기열 구축을 피할 수가 있습니다 이는 L4S가 처리량 최대화와 낮은 엔드투엔드 대기 시간을 동시에 달성할 수 있게 해주죠 이제 이 협력체가 사용자들에게 그 혜택을 전달하기 위해 우린 뭘 해야 할지 살펴봅시다 먼저 앱 준비 방법을 알아볼게요 URLSession과 Network 프레임워크에서 네트워킹 API를 사용하는 게 가장 좋은 방법인데요 앱이 이 프레임워크들에서 HTTP/3나 QUIC을 사용한다면 L4S는 자동 지원됩니다 앱 코드 변경을 할 필요가 없죠 대신 HTTP/2나 TCP를 사용한다면 이 프로토콜에 다운 가능한 L4S 지원 기능이 iOS 17과 macOS Sonoma에 탑재되어 있습니다 이는 앱에 L4S 지원을 추가하기 위한 최적의 방법이죠 코드 변경이 필요하지 않으니까요 하지만 앱이 커스텀 프로토콜을 사용한다면 L4S 지원을 위해 구현해야 할 것들이 몇 가지 존재합니다 RFC 9330은 L4S 요건을 배울 수 있는 좋은 시작점이 되는데요 몇 가지 새로운 동작을 구현해야 할 겁니다 한 예로, 프로토콜은 네트워크로부터 폭주 피드백을 이해하고 나서 그에 맞게 송신 속도를 조정해야 합니다 그러려면 확장 가능한 폭주 제어 알고리즘이 필요하죠 그다음, 네트워크가 ECN 비트를 통과시킬 때만 L4S 트래픽을 보내도록 해야 하고요 그래서 ECN 검증 메커니즘을 구현해야 합니다 ECN 블리칭과 같이 ECN을 방해할 수 있는 네트워크 문제를 점검하는 메커니즘을요 프로토콜이 수신자로 작동해도 네트워크의 ECN 피드백을 송신자에게 되돌려 주는 중계 메커니즘도 필요합니다 만약 Network 프레임워크를 기반으로 한다면 패킷 메타데이터에서 ECN 프로퍼티를 사용해 커스텀 프로토콜에 대한 ECN 플래그 송수신이 가능하죠 소켓을 사용 중이라면 세트 소켓 옵션을 사용하거나 메시지 시스템 호출을 송수신해 ECN 플래그를 송수신합니다

이렇게 L4S를 위한 앱 준비 방식을 살펴봤는데요 이제 서버 구축 방법을 탐색해 보도록 합시다 만약 앱이 QUIC을 사용하고 있다면 서버의 QUIC 구현에도 L4S와 ECN 마킹에 대한 지원이 필요합니다 서버 쪽에서 이용 가능한 구현 QUIC은 많습니다 ECN, L4S 작동 방법을 서버 제공자에 문의해 보세요 아직 L4S 트래픽 송신을 지원하지 않는다면 ECN이 L4S 트래픽을 송신하게 할 수 있습니다 이제 L4S 완전 지원을 적극 장려해야겠죠

앱이 TCP를 사용하는 경우 서버의 TCP 구현에 L4S 지원이 주가되어야 합니다 Linux 기반 서버에서는 이를 위해 GitHUb 페이지의 지시 사항을 확인해 주세요 이 영상과 관련된 항목의 글에서 더 많은 상세 내용을 알아보실 수 있습니다 다른 서버 플랫폼의 경우 서버 제공자에 문의하시고요 L4S 지원을 위해 필요한 추가적인 구성이나 변경 사항이 있을 수 있으니까요 여기까지 L4S를 위한 앱과 서버 구축 방법을 봤으니 L4S 네트워크를 구축해 앱을 테스트하는 법을 알아보죠 먼저, L4S를 가능케 하는 요소는 무엇이었나요? 네트워크는 ECN 마킹을 막아서는 안 됩니다 ECN 마킹은 송수신자와 병목 지점이 네트워크에 대한 정보를 주고 받을 때 사용되거든요 만약 이를 막는다면 L4S 작동이 안 될 겁니다 개발자 문서에 추가 툴과 지시 사항이 있으니 네트워크와 ECN의 호환 가능성 검증에 사용해 보시길 바랍니다 네트워크 병목 현상은 L4S 대기열 관리를 지원합니다 이건 L4S의 혜택을 얻으려면 필수 사항이죠 호환 가능성 검증이 이루어지면 L4S 대기열 관리를 병목 지점에 추가해야 합니다 L4S 대기열 관리를 지원하는 테스트 네트워크 구축에 가장 좋은 방법은 인터넷 공유를 사용하는 겁니다

macOS Sonoma에서 인터넷 공유는 L4S 대기열 관리를 지원하죠 인터넷 공유를 통해 Mac이 만든 네트워크에 합류한다면 Mac 자체가 해당 기기와 서버 사이의 추가 네트워크 홉이 될 겁니다 Mac이 네트워크에서 병목 지점이 되도록 구성하면 그곳을 지나는 트래픽에 L4S 대기열 관리를 적용해 완전한 L4S 네트워크를 구축할 수 있게 해줄 겁니다 macOS에서 인터넷 공유를 가능하게 하려면 System Settings의 Internet Sharing 페이지를 탐색해야 합니다 노출 버튼을 클릭해 공유할 인터페이스와 테스트 기기를 연결할 인터페이스를 선택하세요

Mac이 이 네트워크의 병목 지점으로 작동하게 하려면 대역폭을 줄여야 합니다 Terminal에서 ifconfig 명령문을 사용하세요 두 인터페이스 모두에 대해서요 그리고 이 명령문에서 인터페이스 이름을 사용 중인 인터페이스의 이름으로 변경해 주세요 en1과 같이요 다음으로 테스트 기기에서 네트워크를 연결하여 앱에서 L4S의 장점이 보이는지 확인해 보세요 Mac의 대역폭 감소를 취소하려면 리부팅하거나 동일한 ifconfig 명령문을 실행해 대역폭을 초당 10MB가 아닌 0MB로 변경하세요

iOS 17과 macOS Sonoma에서는 L4S가 사용자들에게 무작위로 계속해서 뻗어나갈 겁니다 테스트 기기에서 L4S를 키려면 Developer Settings에서 L4S를 켜주세요 macOS에서는 테스트 하기 전에 이 기본 명령문을 실행시켜 L4S를 켤 수 있습니다 네트워크나 서버가 L4S를 지원하지 않는다면 기존 모드에서 TCP와 QUIC이 계속 작동할 겁니다 다만 L4S를 켜서 앱에서 문제가 발견되는지 테스트 해야 합니다 문제가 발생할 경우 Feedback Assistant를 사용해 피드백을 제공해 주세요 개발자 문서에서는 디버깅과 L4S에 관해 또 다른 정보를 제공 중이니 참고하세요 앱과 네트워크에서 L4S를 통해 대기 시간과 패킷 손실을 줄여 너무 좋습니다

여러분의 앱에 대해서도 L4S를 지원하는 네트워크와 그렇지 않은 네트워크에 대해 iOS 17과 macOS Sonoma에서 테스트해 보세요 서버나 CDN 제공자가 앱 서버에서 L4S 지원을 아직 하지 않는다면 한번 협력해 보세요 Feedback Assistant를 사용해 앱에서 L4S를 켰을 때 발생하는 문제에 대해 보고해 주시고요 시청해 주셔서 감사합니다 L4S로 훨씬 멋진 앱을 만들어 주시길 기대할게요 ♪ ♪