[TIL] 차근차근 CS (6) - 흐름 제어 기법

Today I Learned

흐름 제어(Flow Control)는 송신측과 수신측 간의 데이터 처리 속도 차이로 인해 수신 버퍼가 넘쳐 데이터가 손실되는 것을 방지하고자 송신측의 데이터 전송량을 조절하는 기법. 주로 데이터 링크 계층과 전송 계층에서 사용된다. 플로우 컨트롤이라고 하니 뭔가 힙합 용어 같기도 하다.

 

대표적인 흐름 제어 기법은 다음과 같다. 우선 네트워크 통신 시 '정지-대기(Stop-and-Wait)'와 '슬라이딩 윈도우'가 있다.

 

정지-대기는 송신측이 하나의 프레임을 전송한 후 ACK를 받을 때까지 다음 프레임 전송을 대기하는 기법. 엄청 간단하다. ACK를 기다리는 동안 다음 프레임을 보내지 않는다. 다만 다음 프레임을 보내지도 않기 때문에 왕복 시간(RTT)이 길수록 회선 활용도가 낮아진다.

 

여기에 오류 검출과 재전송 등 일련의 오류 제어 매커니즘을 더한 방식은 'Stop-and-Wait ARQ(Automatic Repeat reQuest; 자동 재전송 요구)'이 된다. 일정 시간 내 ACK가 오지 않으면 해당 프레임을 재전송하고, 프로토콜에 따라 부정 확인 응답(NAK)을 받았을 때도 재전송을 한다. 다만 ACK를 기다리며 전송량을 제한하는 것은 흐름 제어이고, 손실되거나 오류가 발생한 데이터를 재전송하는 것은 오류 제어라는 점은 구분할 필요가 있다.

 

슬라이딩 윈도우는 송신측에 허용된 윈도우 범위 안에서 각 데이터에 대한 ACK를 기다리지 않고 여러 데이터를 연속으로 전송하는 방식이다. 새 데이터를 확인하는 ACK가 도착하면 송신 윈도우가 앞으로 이동하고, 그만큼 추가 데이터를 보낼 수 있게 된다. 윈도우가 충분히 크면 ACK를 기다리는 동안에도 데이터를 전송할 수 있기 때문에 정지-대기의 비효율성을 개선할 수 있다. 물론 윈도우를 모두 채우면 얘도 정지-대기와 비슷하게 전송 여유가 생길 때까지 기다려야 한다.

 

현대 TCP 통신에서도 슬라이딩 윈도우를 사용한다. TCP에서는 프레임 대신 세그먼트를 전송하고 윈도우 크기는 바이트 단위로 관리. 수신측은 추가로 받아들일 수 있는 데이터의 양을 수신 윈도우(rwnd)로 송신측에 알려준다. 이 값은 수신 버퍼의 여유에 따라 달라진다. 다만 TCP 전송량은 수신 윈도우만으로 결정되지는 않는다. 네트워크의 혼잡을 고려하는 혼잡 윈도우(cwnd)에도 제한되며, 기본적으로 두 값 중 더 작은 값이 ACK를 받지 않은 상태로 전송해 둘 수 있는 데이터 양의 한도인 셈이다. 수신측이 감당할 수 있는 양을 고려하는 것은 흐름 제어이고, 네트워크가 감당할 수 있는 양을 고려하는 것은 혼잡 제어다.

 

백엔드에서는 과도한 요청으로부터 서비스를 보호하기 위해 레이트 리미팅(Rate Limiting)이라는 기법을 사용한다. 일정 시간 동안 허용할 요청 수를 제한하는 애플리케이션 수준의 트래픽 제어다. 예를 들어 미친 클라이언트가 초당 수천 건의 요청을 보낸다고 가정해보자. DB 커넥션 풀이 고갈되거나 컴퓨팅 자원이 부족해져 응답 지연과 장애가 발생할 수 있다. 만약 클라우드 환경이었다면 어마어마한 과금 폭탄을 맞을 수도 있을 테다.

 

레이트 리미팅을 적용하면 허용량을 초과한 HTTP 요청에 429 Too Many Requests로 응답할 수 있다. 이런 요청 제한은 DDoS 공격을 완화하는 데도 도움이 된다. 다만 여러 출처에서 공격 요청이 들어오면 각 출처의 요청량이 제한 이하라도 전체 트래픽은 서버의 처리 능력을 넘을 수 있다는 점. 출처별 레이트 리미팅만으로는 충분하지 않을 수 있다. 

---

Today I Listened to