네이글 알고리즘(Nagle's algorithm)은 TCP에서 이미 보낸 데이터의 확인 응답이 오기 전까지 새로 쓰인 작은 데이터를 모아 두었다가 한꺼번에 보내, 작은 패킷이 너무 많이 생기는 것을 막는 방법이다. 존 네이글(John Nagle)이 1984년 RFC 896에서 제안했다.
작은 패킷 문제
네이글은 포드 에어로스페이스 앤드 커뮤니케이션스(Ford Aerospace and Communications Corporation) 소속으로 1984년 1월 6일 RFC 896을 썼다.[1] 이 문서는 표준을 정하지 않는다고 밝히고 IP/TCP 인터네트워크의 혼잡 제어를 다루며, TCP 구현의 문제로 작은 패킷 문제와 소스 퀜치 문제를 든다.[1] 네이글은 작은 패킷 문제가 풀리면 소스 퀜치 문제가 훨씬 다루기 쉬워진다고 보았다.[1]
키보드에서 입력한 글자를 TCP로 하나씩 보내면 데이터 1바이트마다 헤더 40바이트가 붙은 41바이트 패킷이 하나씩 전송되며, RFC 896은 이를 4000%의 오버헤드라고 설명한다.[1] 한가한 네트워크에서는 이 오버헤드를 견딜 만하지만, 붐비는 네트워크에서는 혼잡 때문에 데이터그램이 손실되고 재전송이 일어나며, 심하면 TCP 연결이 끊긴다.[1]
RFC 896에 따르면 이 문제는 1960년대 후반 Tymnet에서 처음 다루어졌다.[1] Tymnet은 작은 패킷을 200~500밀리초 동안 붙들어 두어 글자가 더 들어오기를 기다렸다가 보냈고, 사용자가 받아들이기 쉽도록 캐리지 리턴 같은 제어 문자가 오면 이 지연을 없앴다.[1] 네이글은 이 방식의 결점이 모두를 만족시키는 시간 제한을 찾기 어렵다는 것이라고 짚었다.[1] 초당 1000만 비트 이더넷에서 빠르게 반응하도록 정한 시간 제한은 왕복 시간이 5초인 붐비는 네트워크에서 혼잡 붕괴를 막기에 너무 짧고, 반대로 그런 네트워크에 맞춘 시간 제한은 이더넷 사용자를 답답하게 한다는 것이다.[1]
방식
RFC 896이 내놓은 해법은, 사용자에게서 새 데이터가 도착했을 때 이전에 보낸 데이터 가운데 아직 확인되지 않은 것이 있으면 새 TCP 세그먼트를 보내지 않는 것이다.[1] 이 보류는 무조건 적용되며 타이머나 데이터 크기를 따지는 검사 같은 다른 조건이 필요 없고, 구현에는 대개 TCP 프로그램 안의 한두 줄이면 된다고 한다.[1]
보내기를 미룬 데이터는 상대 호스트에서 확인 응답이나 창 갱신이 오면 그때 보내진다.[1] 연결이 놀고 있을 때는 사용자가 쓸 때마다 패킷이 바로 나가므로 교착이 생기지 않으며, 정상적인 TCP 재전송 논리는 건드리지 않아 손실된 메시지도 문제가 되지 않는다고 네이글은 설명했다.[1]
2022년의 RFC 9293은 이를 이렇게 정리한다. 확인되지 않은 데이터가 있으면 송신 TCP는 PSH 비트와 상관없이 모든 사용자 데이터를 버퍼에 담아 두고, 이미 보낸 데이터가 확인되거나 최대 크기 세그먼트를 보낼 수 있게 될 때까지 기다린다.[2]
효과
RFC 896은 키 입력을 200밀리초마다 한 글자씩 보내는 텔넷 연결을 예로 든다.[1] 왕복 시간이 50밀리초인 이더넷에서는 글자가 입력될 때마다 연결이 놀고 있어 글자가 바로 전송되므로 사용자가 지연을 느끼지 않는다.[1] 왕복 시간이 5초인 장거리 회선에서는 첫 글자만 바로 전송되고 이어지는 24글자는 첫 패킷의 확인 응답이 올 때까지 쌓였다가 한 패킷에 실려 나가며, 이때 오버헤드가 320%로 줄고 응답 시간은 늘지 않는다.[1]
파일 전송에서는 두 경우 모두 데이터를 가득 채운 창이 유지되어 처리량이 같다.[1] 왕복 시간이 5초인 회선에서 100킬로바이트 파일을 보내는 데 타이머 방식은 250초, 이 방식은 254초가 걸려 차이는 시작 때뿐이라고 RFC 896은 계산했다.[1] 네이글은 검토한 모든 경우에서 이 방식이 다른 두 방식의 98% 이상 성능을 내고 먼 거리 회선의 텔넷에서는 성능을 크게 높인다고 썼다.[1] 포드 에어로스페이스의 소프트웨어 공학 네트워크는 이 방식을 모든 TCP 연결에 쓰며, 이더넷 위에서 화면 편집기를 돌리거나 멀리 있는 TOPS-20 호스트와 통신해도 성능이 좋아졌다고 한다.[1]
표준과 끄기
1989년 RFC 1122는 TCP가 작은 세그먼트를 합치려고 네이글 알고리즘을 구현하는 것이 좋다고 하면서, 응용 프로그램이 연결 하나마다 이를 끌 수 있는 방법이 반드시 있어야 한다고 정했다.[3] RFC 1122는 실시간 화면 갱신처럼 작은 데이터 세그먼트를 최대한 빠르게 흘려보내야 하는 응용 프로그램은 이 알고리즘을 꺼야 한다고 설명한다.[3] RFC 9293도 같은 요구를 이어받아, TCP가 네이글 알고리즘을 구현하는 것이 좋고 응용 프로그램이 연결마다 끌 방법이 있어야 한다고 정한다.[2]
지연 확인 응답과의 상호작용
RFC 9293은 네이글 알고리즘과 지연 확인 응답 사이에 문제가 될 수 있는 상호작용이 있어, 일부 구현이 네이글 알고리즘을 조금 바꾸어 쓴다고 밝힌다.[2] 지연 확인 응답은 받는 쪽이 세그먼트마다 확인 응답을 보내지 않고 줄여서 보내는 방식이며, RFC 9293은 TCP가 이를 구현하는 것이 좋되 지연은 0.5초보다 짧아야 한다고 정한다.[2] RFC 9293의 부록은 흔한 운영체제에서 두 알고리즘이 기본으로 켜져 있고, 요청과 응답을 주고받는 응용 프로그램에서는 이 조합이 성능을 떨어뜨릴 수 있다고 설명한다.[2] 이를 개선하는 변형이 일부 운영체제에 구현되어 있으며, 많은 응용 프로그램이 소켓 옵션으로 네이글 알고리즘을 그냥 꺼 버린다고 한다.[2] RFC 9293은 이 변형을 표준에 넣지는 않았다고 밝힌다.[2]
출처
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 John Nagle (1984년 1월 6일). “Congestion Control in IP/TCP Internetworks”. 《RFC Editor》 (영어). 2026년 11월 8일에 확인함.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 W. Eddy (2022년 8월). “Transmission Control Protocol (TCP)”. 《RFC Editor》 (영어). 2026년 11월 8일에 확인함.
- ↑ 3.0 3.1 R. Braden (1989년 10월). “Requirements for Internet Hosts -- Communication Layers”. 《RFC Editor》 (영어). 2026년 11월 8일에 확인함.