[PonsWarp] ACK 하나 때문에 전송이 멈추고 살아났다

전송이 빠른데도 수신 쪽이 밀리면서 멈추는 장면이 있었다. 처음에는 더 빠르게 보내면 해결될 것 같았다. 실제로는 속도를 올릴수록 브라우저 버퍼가 먼저 한계에 닿았다. 큰 파일에서 마지막 몇 퍼센트가 깨지는 이유도 그곳에 있었다.

ACK를 브레이크로 보기

ACK는 받았다는 표시만이 아니었다. 수신자가 다음 조각을 받을 준비가 됐다는 신호로 사용해야 했다. 보내는 쪽이 자기 속도만 믿고 계속 밀어 넣으면 전송은 빨라 보이지만 실제로는 더 빨리 깨진다.

속도보다 끝까지 도착하는 흐름

브라우저 메모리, 수신 속도, 저장 방식, ACK와 백프레셔는 따로 볼 수 없었다. 방 안의 작은 부가 기능으로 시작한 파일 전송이 파일 크기 때문에 회의방 전체의 리듬을 흔들었다. 이 문제를 분리해 PonsWarp의 기준을 최고 속도에서 끝까지 살아남는 흐름으로 바꿨다.

ACK 하나가 전송을 멈추게 만든 것은 실패가 아니었다. 언제 멈춰야 하는지를 프로토콜에 넣을 수 있게 된 순간이었다. 멈춤이 명시되면 수신자가 따라온 뒤 다시 보낼 수 있고, 사용자는 거의 끝났는데 사라지는 파일을 덜 만나게 된다.

마치며

대용량 전송에서 중요한 것은 계속 보내는 능력이 아니라 멈출 수 있는 규칙이다. ACK와 백프레셔는 속도를 포기한 장치가 아니라 끝까지 도착하기 위한 흐름 제어였다.