네트워크 혼잡과 관련해서 가장 흔한 문제는 데이터 전송이 가능해지면 송신 시스템이 그 즉시 전송할 수 있는 최대 속도로 데이터를 전송한다는 것이다. 사용자가 큰 파일을 요청하면 서버는 그 파일을 즉시 최대 속도로 전송하려 한다.
서버가 이렇게 동작하면 신속하게 전송을 완료할 수 있을 것처럼 보이지만 실제로는 문제가 있다. 송신 시스템과 수신 시스템 사시에 어떤 병목이 있는데 전송이 폭주하면 즉시 그런 병목에서 네트워크 혼잡 문제가 발생한다. 사용자는 데이터가 폭주한 다음에 시스템이 분실된 하나 또는 그 이상의 세그먼트를 복구하면서 갑자기 멈추고 다시 데이터 폭주가 일어나는 것을 볼 수 있다. 이런 상황을 피하고자 사용하는 기술이 '느린 시작(slow start)'이다.
또 느린 시작은 수신 확인 타이머가 만료되거나 ICMP Source Quench 에러 메시지가 수신되어 혼잡 윈도우가 세그먼트 하나의 크기로 축소되는 치명적인 네트워크 혼잡 문제로부터 복구하기 위해서 사용된다.
느린 시작은 혼잡 윈도우의 크기를 기하 급수적으로 확대시키며 동작한다. 어떤 세그먼트가 전송되어 수신이 확인되면, 혼잡 윈도우는 (가상 회선의 MTU / MRU 크기에 의해 정해지는) 한 세그먼트의 데이터 크기만큼 확대되어 더 많은 데이터를 전송하도록 허용한다.
예를 들어, 혼잡 윈도우가 한 세그먼트의 크기로 설정되어 있다면 (또 한 세그먼트의 크기는 초기 설정 과정에서 정해진 값으로 설정되었다면), 시스템은 한 세그먼트만을 전송할 것이다. 이 세그먼트의 수신이 확인되면 혼잡 윈도우의 크기가 한 세그먼트만큼 확대되어 시스템이 동시에 두 세그먼트를 전송하도록 허용하게 된다. 전송 버퍼에 있는 다음 두 세그먼트가 전송되어 두 세그먼트 모두 수신이 확인되면, 혼잡 윈도우의 크기는 또 다시 두 배로 확대되어 총 4개의 세그먼트로 설정된다. (그림 7 - 12)에 나타난 것처럼 반드시 모든 세그먼트의 수신이 확인되어야 혼잡 윈도우가 확대될 수 있는 것은 아니다. (*이 블로그에서는 그림 생략. 책 사세요! ;) )
새롭게 연결된 경우에는 네트워크 혼잡이 감지되거나 혼잡 윈도우의 크기가 수신 시스템의 Window 필드로 통보되는 수신 윈도우의 크기와 같아질 때까지 계속 이 과정이 반복된다. 윈도우의 크기를 서서히 확대하는 과정이 성공하면, 가상 회선이 수신 시스템의 수신 버퍼 크기로 흐름이 제어되는 최대 속도로 동작하게 된다. 그러나 확대하는 과정에서 네트워크 혼잡이 감지되면, 혼잡 윈도우의 크기는 마지막으로 성공한 값에서 고정된다. 그 후에 발생하는 네트워크 혼잡 문제는(앞서, '혼잡 윈도우의 크기 결정'에서 다룬 것처럼) 혼잡 윈도우의 크기를 축소시킬 것이다.
네트워크 혼잡이 발생하여 혼잡 윈도우의 크기를 복구하는 데 느린 시작을 사용하는 것이라면, 혼잡 윈도우의 크기가 원래 크기의 반에 이를 때까지 계속되며, 그 시점부터는 혼잡 회피 기술을 호출하여 계속해서 혼잡 윈도우 크기를 확대한다. 머지 않아 네트워크 혼잡이 또 발생할 수 있으므로 TCP는 느린 시작을 통해 혼잡 윈도우를 기하 급수적으로 확대시키는 대신 혼잡 회피 기술을 통해 조심스럽게 선형적으로 확대시킨다.
느린 시작은 RFC 1122에서 그 사용이 의무화되었지만, 그 절차는 RFC 2001이 발행될 때까지 제대로 문서화되지 않았다. 따라서, 많은 초기 시스템은 여기서 설명된 느린 시작 루틴을 포함하지 않았다.
또 RFC 2414는 느린 시작의 초기 값으로 RFC 2581(TCP 혼잡 제어)에서 제안된 1개의 세그먼트 대신 4개의 세그먼트를 사용하라고 권장하고 있다. 느린 시작의 초기 값을 4개의 세그먼트로 설정하는 것은 하나 이상의 세그먼트를 전송하는 애플리케이션의 성능을 향상시킨다. 예를 들어, 어떤 애플리케이션이 두 세그먼트를 전송해야 하는데 초기 혼잡 윈도우가 '한 세그먼트'로 고정되어 있다면, 애플리케이션은 그 중 한 세그먼트만 전송할 수 있다. 수신 시스템은 모든 애플리케이션 데이터를 수신하지 못하게 되며, 지연된 수신 확인 기법은 확인 메시지의 전송을 길게 지연시킨다. 그러나 초기 혼잡 윈도우 크기를 '두 세그먼트'로 설정하면 송신 시스템은 두 개의 완전한 크기의 세그먼트를 전송할 수 있게 되어, 수신 시스템이 즉시 확인 메시지를 전송할 수 있게 된다. RFC 2414의 제안이 연결의 확대 속도를 증폭시키고는 있지만 실험 단계의 문서이므로 출하되는 TCP 제품에 구현할 의무는 없다.
Quotes from Internet Core Protocols, Eric A. Hall, O'Reilly, 인터넷 핵심 프로토콜 가이드, 한빛미디어
서버가 이렇게 동작하면 신속하게 전송을 완료할 수 있을 것처럼 보이지만 실제로는 문제가 있다. 송신 시스템과 수신 시스템 사시에 어떤 병목이 있는데 전송이 폭주하면 즉시 그런 병목에서 네트워크 혼잡 문제가 발생한다. 사용자는 데이터가 폭주한 다음에 시스템이 분실된 하나 또는 그 이상의 세그먼트를 복구하면서 갑자기 멈추고 다시 데이터 폭주가 일어나는 것을 볼 수 있다. 이런 상황을 피하고자 사용하는 기술이 '느린 시작(slow start)'이다.
또 느린 시작은 수신 확인 타이머가 만료되거나 ICMP Source Quench 에러 메시지가 수신되어 혼잡 윈도우가 세그먼트 하나의 크기로 축소되는 치명적인 네트워크 혼잡 문제로부터 복구하기 위해서 사용된다.
느린 시작은 혼잡 윈도우의 크기를 기하 급수적으로 확대시키며 동작한다. 어떤 세그먼트가 전송되어 수신이 확인되면, 혼잡 윈도우는 (가상 회선의 MTU / MRU 크기에 의해 정해지는) 한 세그먼트의 데이터 크기만큼 확대되어 더 많은 데이터를 전송하도록 허용한다.
예를 들어, 혼잡 윈도우가 한 세그먼트의 크기로 설정되어 있다면 (또 한 세그먼트의 크기는 초기 설정 과정에서 정해진 값으로 설정되었다면), 시스템은 한 세그먼트만을 전송할 것이다. 이 세그먼트의 수신이 확인되면 혼잡 윈도우의 크기가 한 세그먼트만큼 확대되어 시스템이 동시에 두 세그먼트를 전송하도록 허용하게 된다. 전송 버퍼에 있는 다음 두 세그먼트가 전송되어 두 세그먼트 모두 수신이 확인되면, 혼잡 윈도우의 크기는 또 다시 두 배로 확대되어 총 4개의 세그먼트로 설정된다. (그림 7 - 12)에 나타난 것처럼 반드시 모든 세그먼트의 수신이 확인되어야 혼잡 윈도우가 확대될 수 있는 것은 아니다. (*이 블로그에서는 그림 생략. 책 사세요! ;) )
새롭게 연결된 경우에는 네트워크 혼잡이 감지되거나 혼잡 윈도우의 크기가 수신 시스템의 Window 필드로 통보되는 수신 윈도우의 크기와 같아질 때까지 계속 이 과정이 반복된다. 윈도우의 크기를 서서히 확대하는 과정이 성공하면, 가상 회선이 수신 시스템의 수신 버퍼 크기로 흐름이 제어되는 최대 속도로 동작하게 된다. 그러나 확대하는 과정에서 네트워크 혼잡이 감지되면, 혼잡 윈도우의 크기는 마지막으로 성공한 값에서 고정된다. 그 후에 발생하는 네트워크 혼잡 문제는(앞서, '혼잡 윈도우의 크기 결정'에서 다룬 것처럼) 혼잡 윈도우의 크기를 축소시킬 것이다.
네트워크 혼잡이 발생하여 혼잡 윈도우의 크기를 복구하는 데 느린 시작을 사용하는 것이라면, 혼잡 윈도우의 크기가 원래 크기의 반에 이를 때까지 계속되며, 그 시점부터는 혼잡 회피 기술을 호출하여 계속해서 혼잡 윈도우 크기를 확대한다. 머지 않아 네트워크 혼잡이 또 발생할 수 있으므로 TCP는 느린 시작을 통해 혼잡 윈도우를 기하 급수적으로 확대시키는 대신 혼잡 회피 기술을 통해 조심스럽게 선형적으로 확대시킨다.
느린 시작은 RFC 1122에서 그 사용이 의무화되었지만, 그 절차는 RFC 2001이 발행될 때까지 제대로 문서화되지 않았다. 따라서, 많은 초기 시스템은 여기서 설명된 느린 시작 루틴을 포함하지 않았다.
또 RFC 2414는 느린 시작의 초기 값으로 RFC 2581(TCP 혼잡 제어)에서 제안된 1개의 세그먼트 대신 4개의 세그먼트를 사용하라고 권장하고 있다. 느린 시작의 초기 값을 4개의 세그먼트로 설정하는 것은 하나 이상의 세그먼트를 전송하는 애플리케이션의 성능을 향상시킨다. 예를 들어, 어떤 애플리케이션이 두 세그먼트를 전송해야 하는데 초기 혼잡 윈도우가 '한 세그먼트'로 고정되어 있다면, 애플리케이션은 그 중 한 세그먼트만 전송할 수 있다. 수신 시스템은 모든 애플리케이션 데이터를 수신하지 못하게 되며, 지연된 수신 확인 기법은 확인 메시지의 전송을 길게 지연시킨다. 그러나 초기 혼잡 윈도우 크기를 '두 세그먼트'로 설정하면 송신 시스템은 두 개의 완전한 크기의 세그먼트를 전송할 수 있게 되어, 수신 시스템이 즉시 확인 메시지를 전송할 수 있게 된다. RFC 2414의 제안이 연결의 확대 속도를 증폭시키고는 있지만 실험 단계의 문서이므로 출하되는 TCP 제품에 구현할 의무는 없다.
Quotes from Internet Core Protocols, Eric A. Hall, O'Reilly, 인터넷 핵심 프로토콜 가이드, 한빛미디어