게임 핑 튀는 이유, 다운로드가 회선 앞 줄을 채워서다

집에서 누가 큰 게임이나 영상을 내려받기 시작하면, 하던 게임의 핑이 갑자기 튄다. 내려받는 데이터가 회선의 느린 구간 앞 줄을 가득 채우면, 게임 신호도 그 줄 끝에 서서 차례를 기다리기 때문이다. 줄이 길수록 핑은 길어지지만, 다운로드 속도는 거의 그대로다. 장비에 쌓인 줄이 지나치게 길어져 핑이 튀는 이 현상을 버퍼블로트(bufferbloat)라고 한다.

크림색 카드. 왼쪽 위에 굵은 두 줄 제목 「게임 핑 튀는 이유, / 다운로드가 회선 앞 줄을 채워서다」가 있고 「줄」만 파란색이다. 그 아래 회색 부제는 「느린 구간 앞에 쌓인 줄 끝에서 게임 신호도 차례를 기다린다」다. 부제 아래로 안쪽이 흰 세로 깔때기가 카드 폭을 거의 다 차지하고, 아래로 좁아진 목에서 좁은 통로가 카드 아래 끝까지 이어진다. 목 바로 위에 같은 크기의 회색 사각 블록 열두 개가 아래부터 한 개, 세 개, 다섯 개, 세 개로 쌓여 줄을 이룬다. 맨 위 블록 줄의 오른쪽 끝에 파란 마름모 하나가 얹혀 있고, 파란 선이 깔때기 오른쪽 바깥의 파란 테두리 이름표 「게임 신호」(게임패드 아이콘)로 이어진다. 통로 안에서는 짙은 블록이 간격을 두고 하나씩 내려간다. 왼쪽 바깥의 회색 이름표 「내려받는 데이터」(내려받기 아이콘)가 점선으로 블록 더미를, 목 오른쪽 아래의 회색 이름표 「느린 구간」이 점선으로 좁은 목을 가리킨다. 숫자와 축은 없다.

막히지 않았을 때 왕복 시간이 10 ms 도 안 되던 길에서, 1.2초가 넘는 지연이 찍혔다. 벨 연구소(Bell Labs)의 짐 게티스(Jim Gettys)가 2011년 ACM Queue 에 실은 글에서 꺼낸, 자기 집 회선의 기록이다. 그 시각 그는 집에서 MIT 로 20 GB 의 데이터를 올리고(업로드하고) 있었다. 보낸 패킷(데이터 꾸러미)이 꽤 사라졌고, 웹 페이지를 여는 일도 괴로웠다고 그는 적었다.

이상한 점은 따로 있었다. 메일을 읽으려고 전송을 몇 번 잠깐 멈추면, 집 인터넷은 거의 곧바로 멀쩡해졌다. 그래서 집에서 「오늘 인터넷이 느리다」는 말이 나와도, 그가 원인을 찾으러 들여다볼 때면 문제는 사라져 있었다. 네트워크를 살피려고 문제를 일으키던 큰 전송부터 멈췄기 때문이다.

게임을 하는 집이라면 이 장면이 낯설지 않다. 누가 큰 게임을 내려받기 시작하면 하던 게임의 핑이 튀고, 다운로드가 끝나면 가라앉는다. 누가 다운로드하면 왜 게임 핑이 튈까?

내려받는 데이터가 회선의 느린 구간 앞 장비에 선 줄을 가득 채우면, 게임 신호도 그 줄 끝에서 차례를 기다린다. 줄이 길수록 핑도 길어진다. 이렇게 줄이 지나치게 길어 핑이 튀는 현상을 버퍼블로트라고 부른다. 회선이 꽉 찬 동안 핑이 튄 만큼이 곧 그 줄에서 기다린 시간이다. 같은 원리로, 사진·영상을 올리는 동안에는 핑이 더 크게 튄다는 측정도 있다.

핑에는 무엇이 들어 있을까

속도 측정 회사 우클라(Ookla)는 핑을, 요청을 보낸 뒤 내 기기가 응답을 받기까지 걸리는 시간으로 설명한다. 내가 보낸 신호가 상대에게 갔다가 돌아오는 시간이라 왕복 지연 시간(RTT)이라고도 부른다. 이 시간은 한 덩어리가 아니다. 게티스와 그 글을 함께 쓴 니컬스(Nichols)는, 패킷이 겪는 지연을 셋으로 나눴다. 선을 타고 건너가는 전송 지연, 장비가 패킷을 다루는 처리 지연, 그리고 차례를 기다리는 대기열 지연이다.

장비는 내보낼 데이터를 잠시 쌓아 두었다가 차례대로 보낸다. 이렇게 데이터가 서 있는 줄을 대기열(큐)이라 하고, 그 줄을 담아 두는 장비 안의 메모리를 버퍼라고 한다. 줄은 들어오는 속도가 내보내는 속도보다 빠를 때 생긴다. 그래서 빠른 길이 느린 길로 좁아지는 자리, 그 바로 앞의 장비에 줄이 선다.

줄에서 기다리는 시간은 셈이 간단하다. 쌓인 양을 빠지는 속도로 나누면 된다. 미국 가정 회선을 잰 순다레산(Sundaresan) 연구팀은 버퍼 크기가 같으면 줄에서 기다리는 시간이 빠지는 속도에 반비례한다고 적었다. 단위는 맞춰야 한다. 회선 속도는 1초에 보내는 비트 수로, 버퍼는 바이트 수로 적으므로 바이트에 8을 곱한다. 이 글에서 1 KB 는 1,024 바이트다.

256 KB 가 꽉 찬 줄을 20 Mbps 회선이 비우려면 105 ms 가 걸린다(256 × 1,024 × 8 ÷ 2,000만). 같은 줄을 8 Mbps 로 비우면 262 ms, 2 Mbps 로 비우면 1,049 ms 다. 사용자가 자기 회선을 재는 측정 프로그램인 넷알라이저(Netalyzr)의 기록에서는, 올리기 쪽 버퍼로 128 KB 와 256 KB 가 흔했다. 넷알라이저 연구팀은 8 Mbps 의 빠른 올리기 회선에서도 이런 버퍼가 파일을 주고받는 동안 250 ms 를 더할 수 있다고 썼다. 256 KB 를 8 Mbps 로 비우는 262 ms 와 맞먹는다.

여기서 105 ms 는 줄에서 기다리는 시간이지 핑 자체가 아니다. 핑은 여기에 원래의 왕복 시간을 더한 값이다. 이 셈은 웨이팅 시간 계산, 앞 팀 수를 입장 속도로 나눈다에서 본 식당 줄 셈과 같은 꼴이다. 줄이 가득 서 있는 동안에는, 그 줄을 비우는 시간만큼 핑이 늘어난다.

다운로드는 왜 줄을 꽉 채울까

앞의 105 ms 는 줄이 꽉 찼다고 놓고 셈했다. 다운로드 프로그램이 쓰는 전송 규칙(TCP)은 흔히 패킷을 잃어버리는 것을 신호로 보내는 양을 고른다. 인터넷 기술 문서 RFC 8289 의 설명은 이렇다. 잃지 않는 동안에는 왕복마다 패킷 하나씩(「one packet per round-trip time」) 보내는 양을 천천히 늘린다. 잃은 것을 알면 절반으로 줄인다(「reduce its window by a factor of two」). 그러니 다운로드는 줄이 넘쳐 패킷을 잃을 때까지 보내는 양을 늘린다.

줄은 보통 꽉 차면 뒤에 온 것부터 버린다. RFC 7567 은 이 방식이 줄을 꽉 찬, 또는 거의 꽉 찬 상태로 오래 머물게 한다고 쓴다. 줄이 다 찼을 때에야 패킷을 버려 넘쳤다는 신호를 주기 때문이다. 버퍼가 크면 이 신호도 늦게 닿는다. 받는 쪽이 패킷이 버려진 것을 알려면 부푼 줄이 다 빠져나가야 한다. 게티스와 니컬스는 이 시간이 막히지 않았을 때 왕복 시간의 몇 배가 될 수 있다고 적었다(「can take many times the uncongested RTT」).

이 줄을 직접 돌려 볼 수 있다. 그림 1는 20 Mbps 회선 하나에서 다운로드를 15초 동안 걸고, 그동안 게임 신호의 핑을 잰 시뮬이다. 버퍼 크기 칸을 64 KB 에서 1,024 KB 까지 바꿀 수 있다.

크림색 카드. 제목은 「버퍼를 키우면 핑만 길어진다」이고 「핑만」이 파란색이다. 그 아래 「버퍼 256 KB」 옆에 64·256·512·1,024 눈금이 붙은 가로 게이지가 256 까지 채워져 있다. 그 아래 칩 셋이 나란히 있다. 파란 테 칩 「핑 중앙값 91 ms」(작은 글씨 「다운로드 중 · 시작 1초 뒤부터」), 「꽉 찬 줄을 비우는 시간 105 ms」, 「다운로드 속도 19.9 Mbps」다. 아래 그래프의 가로축은 시간 0~21초, 세로축은 「핑 (0.2초마다 가장 큰 값, ms)」이고 눈금은 0~400 이다. 3~18초에 옅은 회색 띠 「다운로드 중」이 깔려 있고, 20 ms 높이에 회색 점선과 이름표 「조용할 때 20 ms」가 있다. 짙은 선 하나가 조용한 동안 점선에 붙어 있다가, 다운로드가 시작되자 약 125 ms 까지 솟은 뒤 66 ms 로 내려온다. 그 뒤 약 13.5초까지 천천히 125 ms 로 오르다 한 번 뚝 떨어지고, 다시 오르다 다운로드가 끝나면 20 ms 로 돌아온다. 4~18초에 걸친 파란 가로선이 91 ms 높이에서 중앙값을 가리킨다. 아래 회색 글씨는 「이 시뮬의 설정 — 20 Mbps 회선 · 기준 왕복 20 ms · 다운로드 하나 · 한 번의 실행」이다.
그림 1. 다운로드 중 게임 신호의 핑(그래프·첫째 칩)과 다운로드 속도(셋째 칩)를 버퍼 256 KB 에서 본 판. 버퍼 크기마다 시뮬을 한 번씩 돌린 값이다.

병목은 20 Mbps 회선 한 곳(통신사 쪽 장비의 줄)이고, 막히지 않았을 때의 왕복은 20 ms 로 두었다. 게임 신호는 서버가 20 ms 마다 100 바이트씩 보낸다고 가정했다 — 문헌에 게임 패킷의 크기와 간격은 없다. 다운로드는 앞의 전송 규칙을 흉내 낸 연결 하나다. 실제 전송 규칙의 세부, 여러 연결, 와이파이의 흔들림, 회선 속도의 변화는 흉내 내지 못한다. 중앙값 같은 요약값은 다운로드 시작 1초 뒤부터 셌고, 그래프는 그 1초도 그대로 그린다. 한국 가정 회선을 잰 값이 아니다.

이 시뮬의 설정에서 버퍼를 64 → 256 → 1,024 KB 로 키우면, 다운로드 중 핑 중앙값은 37 → 91 → 239 ms 로 길어졌다. 조용할 때는 20 ms 였다. 그래프에서 핑이 천천히 오르다 한 번씩 뚝 떨어지는 자리는, 줄이 넘쳐 패킷을 잃은 다운로드가 보내는 양을 절반으로 줄인 순간이다. 다운로드가 시작된 직후 핑이 크게 솟는 것은, 처음에 보내는 양을 빠르게 늘리다 줄이 넘친 자리다. 버퍼가 커서 줄이 이렇게 늘 길게 서 있는 현상이 버퍼블로트(bufferbloat)다. 게티스가 늦어도 2010년 12월에 자기 블로그에서 붙인 이름이다.

그렇다고 다운로드가 빨라지지는 않았다. 그림의 셋째 칩을 보면, 버퍼를 64 KB 에서 16배로 키우는 동안 다운로드 속도는 어느 버퍼에서나 19.9 Mbps 그대로였다. 니컬스와 제이콥슨(Jacobson)은 이렇게 늘 서 있는 줄을 두고 「It creates large delays but no improvement in throughput.」라고 썼다. 지연은 크게 만들면서 다운로드 속도는 조금도 늘리지 않는다는 말이다. 버퍼를 키울수록 줄은 길어지고, 길어진 만큼 게임 신호가 기다린다.

내 핑 튀는 이유가 줄 때문인지 어떻게 알까

줄은 회선이 꽉 찬 동안에만 핑을 늘린다. 순다레산 연구팀은 이것을 「Buffering only affects latency during periods when the access link is loaded」라고 적었다. 그래서 조용할 때와 바쁠 때의 핑을 나란히 재면, 그 차이가 줄에서 기다린 몫이다. 앞의 시뮬이라면 256 KB 버퍼에서 핑 중앙값이 20 ms 에서 91 ms 로 늘었으니, 게임 신호는 줄에서 71 ms 쯤을 보낸 셈이다. 넷알라이저도 조용할 때와 속도 시험 중의 지연 차이로 버퍼를 쟀다.

  1. 집에서 아무도 내려받거나 올리지 않을 때, 속도 측정 사이트에서 핑을 재어 적어 둔다.
  2. 큰 다운로드를 걸어 두고 몇 초 넘게 지난 뒤 다시 잰다. 게티스와 니컬스는 장비의 버퍼를 다 채우는 데 10초가 걸릴 수도 있다고 적었다. 측정 사이트가 내려받는 동안의 핑을 따로 보여 주면(우클라의 「Download Ping」) 그 값도 함께 본다. 올리기도 같은 식으로 잰다(「Upload Ping」).
  3. 두 값의 차이가 크면 버퍼블로트를 의심한다. 몇 ms 부터 문제라는 기준은 이 글이 참고한 문헌에 없다.

공유기가 지원한다면, 줄이 길어지지 않게 장비가 직접 다스리는 기능인 대기열 관리를 켠다. 공유기용 운영체제 OpenWrt 에서는 따로 설치해 쓰는 SQM(스마트 대기열 관리)이 이 기능이고, 방식은 FQ-CoDel 이나, 그와 같은 계열의 cake 를 고른다(원리는 뒤의 「좋은 줄과 나쁜 줄」 절에서 본다). 우선순위만 바꾸는 「QoS」와 SQM 은 다른 기능이다. 국산 공유기의 비슷한 메뉴가 실제로 무엇을 하는지는 공식 문서로 확인하지 못했다. OpenWrt 문서는 내려받기·올리기 속도를 조용할 때 잰 값의 90% 로 넣으라고 쓴다(「Enter your Download and Upload speeds to 90% of the results you tested during Preparation.」). 그만큼 다운로드 속도를 내주는 대신, 공유기가 줄을 짧게 지켜 핑이 덜 튄다.

올리기 중에는 왜 더 크게 튈까

같은 버퍼라면 줄에서 기다리는 시간은 빠지는 속도에 반비례한다(「inversely proportional to the draining rate」). 그리고 집 회선은 올리기 쪽 길이 훨씬 좁은 경우가 많았다. 2009~2010년 넷알라이저 기록에서 사용자가 집 회선이라고 밝힌 세션은 평균 내려받기 6.2 Mbps, 올리기 1.6 Mbps 였다.

순다레산 연구팀이 미국 통신사 8곳의 가정 회선을 잰 자료에서, 올리기가 꽉 찰 때 지연이 늘어나는 배율은 내려받기가 꽉 찰 때보다 훨씬 컸다. 저자들은 내려받기 쪽 회선이 대개 더 넓어 통신사 쪽에 쌓이는 줄이 짧기 때문일 것이라 보았다. 다만 이 설명에는 「plausible」(그럴듯한)이라는 단서를 달았다. 같은 연구팀은 모뎀 세 대의 올리기 회선에 데이터를 쏟아부어 보았다. 최악의 지연은 0.8초, 약 1.6초, 10초 넘게까지 벌어졌다.

이 글의 시뮬에서 같은 256 KB 버퍼를, 게티스 집의 올리기 속도에서 빌린 2 Mbps 회선 앞에 두었다. 올리는 동안 핑 중앙값은 616 ms(최대 1,073 ms)였다. 20 Mbps 로 내려받을 때의 91 ms 보다 여섯 배 넘게 길다. 처음에 본 그의 1.2초도 올리기 중에 잰 것이고, 이 시뮬의 최댓값과 자릿수가 같다. 재현했다는 말은 아니다.

그러니 게임 핑이 튈 때는 누가 내려받는지만 볼 일이 아니다. 사진·영상 올리기, 백업, 클라우드 동기화처럼 무언가를 올리는 일도 함께 의심해야 한다. 같은 크기의 줄이라도 좁은 쪽 길에서는 몇 배 오래 기다린다.

좋은 줄과 나쁜 줄은 머문 시간으로 가른다

그렇다면 줄을 아예 없애면 될까? 그렇지는 않다. 데이터는 한꺼번에 몰려 오기도 하는데, 줄은 그것을 받아 두었다가 고르게 내보낸다. RFC 8289 는 이런 줄을 「좋은 줄」이라 부르고, 대략 한 왕복 안에 사라진다고 적었다. 「나쁜 줄」은 그보다 오래 눌러앉아 지연만 만든다. 니컬스와 제이콥슨의 설명으로는, 연결이 막 시작할 때 서는 큰 줄도 꼭 필요하다.

CoDel(Controlled Delay — 지연을 다스린다는 뜻)은 이 둘을 가르는 규칙이다. 줄의 길이 대신, 패킷 하나하나가 줄에서 머문 시간을 본다. 머문 시간은 회선 속도와 상관없이 쓸 수 있고, 사용자가 겪는 지연과 바로 이어지기 때문이다(니컬스·제이콥슨). 머문 시간이 5 ms 를 넘는 상태가 100 ms 넘게 이어지면, 패킷을 하나 버려 보내는 쪽에 속도를 줄이라고 알린다.

FQ-CoDel 은 흐름(한 프로그램이 주고받는 데이터 줄기)마다 줄을 나눈 CoDel 이다. 그러면 조금씩 보내는 흐름은 큰 다운로드 뒤에 서지 않고 먼저 나가는 경향이 생긴다. RFC 8290 은 인터넷 주소 찾기(DNS 조회)·원격 접속(SSH)·인터넷 전화(VoIP) 같은 흐름이 이렇게 되는 「경향」(「tend to fall in this category」)이 있다고 썼다. 그 목록에 게임은 없다. 게임은 대기열 관리 일반을 다룬 RFC 7567 에서, 줄을 짧게 유지하는 일이 특히 중요한 쓰임 가운데 하나(「gaming」)로 나온다.

그림 2는 같은 시뮬에서 다섯 방식을 견준 결과다(20번 돌린 평균). 다운로드 중 핑 중앙값은 큰 버퍼 그대로 91 ms, 버퍼를 작게(32 KB) 26 ms, 병목 장비에 CoDel 22 ms, 병목 장비에 FQ-CoDel 20 ms, 공유기에서 90% 로 묶고 FQ-CoDel 21 ms 였다. 다운로드 속도는 차례로 회선 속도의 99·98·93·93·84% 였다.

크림색 카드. 제목은 「줄을 다스리면 핑이 조용할 때로 돌아온다」이고 「줄을 다스리면」이 파란색이다. 부제는 「다운로드 중 게임 신호의 핑 · 20 Mbps 회선」이다. 범례는 회색 띠 「가운데 80%(10~90 백분위)」, 점 「중앙값」, 세로 눈금 「가장 큰 값」이다. 가로 카드 다섯 장이 위에서부터 「큰 버퍼 그대로」, 「버퍼를 작게(32 KB)」, 「병목 장비에 CoDel」, 「병목 장비에 FQ-CoDel」, 「공유기에서 90% 로 묶고 FQ-CoDel」 순으로 놓이고, 카드마다 같은 핑 트랙 위에 띠·점·눈금이 있다. 카드 오른쪽 글자와 칩은 차례로 「중앙값 91 ms」와 「다운로드 속도 99%」, 「중앙값 26 ms」와 「다운로드 속도 98%」, 「중앙값 22 ms」와 「다운로드 속도 93%」, 「중앙값 20 ms」와 「다운로드 속도 93%」, 「중앙값 21 ms」와 「다운로드 속도 84%」다. 첫 카드의 띠는 71~119 ms 에 걸쳐 있고 점이 검은색이다. 나머지 넷은 20 ms 세로 점선 가까이 모여 있고, 맨 아래 카드만 파란 테두리에 파란 점이다. 가로축 눈금은 0~120, 축 이름은 「핑(ms)」이고, 점선 아래 이름표는 「↑ 조용할 때 20 ms」다. 아래 회색 글씨 두 줄은 「이 시뮬의 설정 — 20 Mbps · 버퍼 256 KB(작게 = 32 KB) · 20번 돌린 평균 · 속도가 일정하고 다운로드가 하나라 작은 버퍼가 실제보다 좋아 보인다」다.
그림 2. 같은 시뮬(20 Mbps · 256 KB)에서 다섯 방식을 20번씩 돌려 평균한, 다운로드 중 게임 신호의 핑 분포.

줄을 다스린 세 방식의 핑은 20~22 ms 로 조용할 때와 거의 같았다. 이 시뮬에서는 줄을 짧게 지키기만 해도, 큰 다운로드가 도는 동안 게임 신호가 거의 기다리지 않았다. 「버퍼를 작게」가 좋아 보이는 것은, 회선 속도가 일정하고 다운로드가 하나뿐인 이 시뮬의 한계다. 속도가 바뀌거나 데이터가 몰려 오면 작은 버퍼는 다운로드 속도를 잃는다. 또 「병목 장비에」가 붙은 두 방식은 줄이 서는 통신사 쪽 장비가 그 규칙을 쓸 때의 값이다. 집에서 내 공유기로 할 수 있는 것은 맨 아래 방식 하나다.

공유기 설정은 줄이 공유기 안에 설 때만 듣는다

줄은 가장 느린 구간 바로 앞의 장비에 선다. 케이블 모뎀을 쓰는 집이라면 올리기 쪽 줄은 모뎀에 선다. 니컬스와 제이콥슨은 그 자리를 사용자가 손댈 수 없는 봉인된 장비 안이라고 적었다. 회선이 가장 느린 구간이면 내려받기 쪽 줄은 통신사 쪽 장비에 선다. 게티스와 니컬스는 내려받는 데이터가 통신사 망 가장자리의 부푼 버퍼를 거쳐 온다고 적었다(「viewing downloads through bloated buffers at the provider edge」).

이런 장비의 줄에는 공유기 설정이 닿지 않는다. 속도를 측정치의 90% 로 넣는 OpenWrt 설정이 여기서 일한다. 공유기가 회선보다 조금 느리게 내보내면, 가장 느린 구간이 공유기가 된다. 그러면 줄이 공유기 안으로 옮겨 와, 공유기의 대기열 관리가 다스릴 수 있다. 니컬스와 제이콥슨이 이 방법을 적은 것은 올리기 쪽에 대해서였다. 내려받기 쪽에 같은 원리를 잇는 것은 이 글의 추론이다.

그림 2의 맨 아래 방식이 이 경우다. 통신사 쪽 256 KB 줄은 그대로 두고, 공유기가 18 Mbps 로 내보내며 FQ-CoDel 을 쓰게 했다. 핑 중앙값은 21 ms, 다운로드 속도는 84% 였다.

그림 3는 그대로 둘 때와 90% 로 묶을 때 줄이 서는 자리를 견준 그림이다.

크림색 카드. 제목은 「공유기가 가장 느려야 공유기 설정이 듣는다」이고 「가장 느려야」가 파란색이다. 위아래 두 띠가 있고, 띠마다 아이콘이 붙은 상자 다섯 개 「게임 서버」, 「통신사 쪽 장비」, 「모뎀」, 「공유기」, 「PC·노트북」이 가로로 놓인다. 상자 위로는 서버에서 PC 로 가는 선 「내려받기」가, 아래로는 PC 에서 서버로 가는 선 「올리기」가 지나간다. 위 띠(회색 이름표 「그대로 두면」)에서는 내려받기 선 위의 짙은 블록 아홉 개가 통신사 쪽 장비 위에, 올리기 선 아래의 회색 블록 일곱 개가 모뎀 아래에 쌓여 있다. 두 장비를 점선 테두리가 감싸고, 그 아래 이름표는 「내 손이 닿지 않는 곳」이다. 공유기 상자 안은 점선 칸 「비어 있음」이다. 아래 띠(파란 테두리 이름표 「공유기에서 속도를 90% 로 묶으면」)에서는 통신사 쪽 장비와 모뎀 곁의 블록이 사라지고, 공유기 상자 안에 가로 칸 셋이 생긴다. 위 칸에 짙은 블록 셋, 가운데 칸에 파란 마름모 하나, 아래 칸에 회색 블록 둘이 있고, 이름표는 「줄이 공유기 안으로」다. 아래 회색 글씨 두 줄은 「줄은 가장 느린 구간 바로 앞 장비에 선다」와 「내려받기 쪽 줄이 공유기로 옮겨 오는 그림은 이 글의 추론(시뮬로 재현) — 원문 서술은 올리기 쪽(모뎀)」이다.
그림 3. 줄이 서는 자리. 아래 띠에서 내려받기 쪽 줄이 공유기로 옮겨 오는 것은 이 글의 추론을 시뮬로 재현한 것이고, 원문의 서술은 올리기 쪽(모뎀)에 대한 것이다.

와이파이가 가장 느린 구간이면 줄은 또 다른 곳에 선다. 올릴 때는 노트북이 데이터를 내보내는 쪽이라, 노트북의 와이파이가 가장 좁은 길이면 줄은 그 바로 앞인 노트북 안에 선다. 게티스도 와이파이가 나빴던 올리기 시험에서 줄이 노트북에 섰다고 적었다. 회선 쪽이 가장 느린 집이라면, 공유기에서 내주는 속도 조금이 줄을 내 손이 닿는 곳으로 옮기는 대가다.

내려받을 때도 올릴 때도, 줄은 가장 느린 곳 앞에 선다

쌓인 양을 빠지는 속도로 나누는 셈 하나가 여러 장면을 함께 설명한다. 어느 장면이든 줄은 가장 느린 구간 바로 앞에 선다. 회선이 가장 느린 집에서 큰 게임을 내려받으면, 게임 신호는 통신사 쪽 장비의 줄에서 기다린다. 케이블 모뎀으로 사진을 올리면 모뎀의 줄에서 기다리고, 올리는 쪽 회선이 더 좁은 집이라면 더 오래 기다린다. 올릴 때 노트북의 와이파이가 가장 느렸던 게티스의 시험에서는 줄이 노트북 안에 섰다. 줄이 늘 차 있을 만큼 큰 버퍼는 다운로드 속도에 보태는 것 없이 핑만 늘린다.

더 읽기