서론: 파일 다운로드, 왜 항상 서버 탓만 할까?
파일 다운로드 속도가 답답할 정도로 느릴 때, 우리는 흔히 ‘서버가 문제네’ 혹은 ‘인터넷이 느린가?’라고 생각하곤 합니다. 하지만 만약 그 원인이 서버나 네트워크가 아닌, 바로 우리 컴퓨터에서 실행되는 프로그램 자체에 있다면 어떨까요? 오늘은 TCP/IP 통신 이면의 깊숙한 동작 원리를 통해 네트워크 속도 저하의 숨겨진 주범을 찾아내는 흥미로운 여정을 떠나보려 합니다. 이 글을 끝까지 읽으신다면, 네트워크를 바라보는 시야가 완전히 달라질 것입니다.
1. 서버의 준비: 거대한 파일을 잘게 나누는 과정
서버가 클라이언트에게 1.3MB 크기의 파일을 보낸다고 상상해봅시다. 서버 프로그램은 이 거대한 파일을 한 번에 통째로 읽어오지 않습니다. 보통 64KB와 같이 잘게 정해진 크기로 파일을 쪼개어 ‘버퍼(Buffer)’라는 임시 메모리 공간에 저장합니다. 이는 마치 거대한 책의 내용을 한 번에 옮기지 않고, 몇 페이지씩 나누어 옮기는 것과 같습니다. 이렇게 애플리케이션 버퍼로 가져온 데이터 덩어리는, 다시 통신을 담당하는 TCP 프로토콜의 전송 버퍼로 복사됩니다. 이제 데이터는 본격적인 전송을 위한 첫 단계를 마친 셈입니다.
2. 데이터의 위대한 여정: 직소 퍼즐과 택배 상자
TCP 버퍼로 넘어온 64KB 데이터는 이제 더 작은 단위인 ‘세그먼트(Segment)’로 분해됩니다. 이는 거대한 직소 퍼즐의 한 부분을 다시 개별 조각으로 나누는 것과 같습니다. TCP는 각 퍼즐 조각에 1번, 2번, 3번처럼 순서 번호를 붙여 분실이나 순서 뒤바뀜에 대비합니다. 이 번호 붙은 세그먼트(퍼즐 조각)는 ‘패킷(Packet)’이라는 택배 상자에 담깁니다. 그리고 이 패킷은 ‘프레임(Frame)’이라는 택배 트럭에 실려 클라이언트를 향한 머나먼 여정을 시작합니다. 흥미로운 점은, 목적지까지 가는 동안 택배 트럭(프레임)은 여러 번 바뀔 수 있지만, 그 안의 택배 상자(패킷)는 최종 목적지에 도착할 때까지 그대로 유지된다는 것입니다.
3. 클라이언트의 도착과 조립: “잘 받았어, 다음 것 보내줘!”
마침내 클라이언트 PC에 택배 트럭(프레임)이 도착하면, 택배 기사는 상자(패킷)를 꺼내고 그 안의 내용물인 퍼즐 조각(세그먼트)을 TCP 수신 버퍼에 전달합니다. TCP는 1번, 2번과 같이 순서대로 도착한 세그먼트들을 차곡차곡 조립하기 시작합니다. 그리고 중요한 행동을 하는데, 바로 서버에게 ‘잘 받았다’는 확인 응답, 즉 ‘ACK(Acknowledgment)’를 보내는 것입니다. 예를 들어 1번과 2번을 성공적으로 받았다면, “2번까지 잘 받았으니, 다음은 3번을 보내줘”라는 의미로 ‘ACK 3’이라는 메시지를 서버에 전달합니다. 서버는 이 ACK를 받아야만 비로소 다음 데이터를 안심하고 보낼 수 있습니다. 이 약속과 확인 과정이 TCP 통신의 신뢰성을 보장하는 핵심 원리입니다.
4. 속도의 진짜 비밀, TCP 윈도우: 범인은 바로 당신!
네트워크 속도의 비밀은 바로 클라이언트의 ‘TCP 수신 버퍼’ 크기에 있습니다. 이 버퍼의 남은 공간을 ‘윈도우 사이즈(Window Size)’라고 부릅니다. 클라이언트는 ACK를 보낼 때마다 “내 버퍼에 이만큼의 여유 공간(윈도우 사이즈)이 있어”라고 서버에게 알려줍니다. 서버는 이 정보를 보고, 클라이언트가 받을 수 있을 만큼만 데이터를 보냅니다. 그런데 만약 클라이언트의 응용 프로그램(웹 브라우저, 게임 등)이 TCP 버퍼에 쌓인 데이터를 아주 느리게 읽어간다면 어떻게 될까요? 버퍼는 금방 가득 차게 되고, 여유 공간(윈도우 사이즈)은 ‘0’에 가까워집니다. 이 ‘윈도우 사이즈 0’이라는 정보를 받은 서버는 전송을 멈추고 하염없이 기다리게 됩니다. 결국, 네트워크 속도 저하의 원인은 서버의 성능이나 네트워크 회선이 아니라, 수신 측 프로그램이 데이터를 제때 처리하지 못해 발생한 것입니다. 개발자라면 소켓에서 데이터를 최대한 빨리 읽어와 TCP 버퍼를 비워주는 것이 원활한 통신의 핵심임을 반드시 기억해야 합니다.
