Intro
TCP의 제어 기능 3가지에 대해 알아보자
1. TCP의 제어 기능 3가지
- TCP는 원활한 통신을 위해 전송하는 데이터를 제어하는 기능을 프로토콜 자체에 포함하고 있으며, 이는 크게 3가지로 분류할 수 있다.
- 첫째, 전송되는 데이터의 양을 조절하는 흐름제어
- 둘째, 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 오류제어
- 셋째, 네트워크 혼잡에 대처하는 혼잡제어
1.1 흐름제어
- 송신 측과 수신 측이 서로 데이터를 주고 받을 때, 여러가지 요인에 의해 두 종단점 간에 처리 속도가 서로 달라질 수 있다.
이때 데이터를 받는 수신 측의 처리 속도가 송신 측보다 빠른 경우에는 사실 문제가 발생하지 않는다.
그러나 수신 측의 처리 속도보다 송신 측이 더 빠른 경우 문제가 생긴다. - 수신 측이 자신의 수신버퍼 안에있는 데이터를 처리하는 속도보다 송신 측이 데이터를 전송하는 속도가 더 빠르다면 수신측의 수신버퍼는 언젠가 꽉 차버릴 것이기 때문이다.
- 그래서 송신 측은 수신 측의 응답 내용과 속도를 파악하고 자신이 얼마나 빠르게, 많은 데이터를 전송할 지 결정해야 한다. 이것이 TCP의 흐름제어이다.
1.1.1 Stop and wait

- 상대방에게 데이터를 보낸 후 잘 받았다는 응답이(ACK) 올 때까지 기다리는 방식으로 핑퐁 방식이라고도 한다.
- Stop and wait 으로 흐름제어를 할 경우 단순히 상대방이 응답을 하였을 때 데이터를 보내면 되기 때문에 구현자체도 간단하고 개발자가 작동 원리를 파악하기도 쉬운 편이다.
- 그러나 간단한만큼 비효율적이라고도 할 수 있다.
수신 측에게 응답이 올 때까지 기다렸다가 데이터를 보내는 것은 응답성이 너무 떨어지기 때문이다. - 따라서 오늘날의 TCP에서는 Stop and wait 방식을 사용하지 않는다.
1.1.2 Sliding window

- Sliding window 방식은 수신 측에서 응답을(ACK) 줄 때 윈도우 사이즈를(수신 버퍼 크기) 함께 알려주는 것을 이용해 수신 측의 데이터 처리 상황을 미리 알고 데이터의 흐름을 제어하는 방식이다.
- 굳이 수신 측으로부터 매번 응답을(ACK) 기다리지 않아도 수신 측이 처리할 수 있는 크기의 양을 알고 있으므로 송신 측에서 데이터를 보내기 전에 앞으로 어떻게 처리될 것인지 예측이 가능한 것이다.
- 추가로 송신 측은 수신 측에서 알려준 윈도우 사이즈만 믿고 앞으로 보낼 수 있는 데이터 크기를 판단하는 것이 아니라 RTT(Round Trip Time)를 통해서 보정된 윈도우 사이즈 크기를 가지고 앞으로 보낼 수 있는 데이터 크기를 판단하고 있다.
- Sliding window 방식은 하나 보내고 응답 받고 하나 보내는 Stop and Wait 보다 확실히 전송 속도 측면에서 빠르기도 하고, 송신 측과 수신 측의 지속적인 커뮤니케이션을 통해 윈도우 크기 또한 유연하게 조절할 수 있기 때문에 오늘날의 TCP에서는 기본적으로 슬라이딩 윈도우를 사용하여 흐름 제어를 하고 있다.
1.2 오류제어
- TCP는 통신 중에 오류가 발생하면 오류를 인지하고 이를 제어한다.
- 즉, 재전송 기반 오류 제어 ARQ(Automatic Repeat Request)를 사용하여 오류를 인지하고 이를 해결한다.
- 하지만 실제로 수 많은 데이터를 주고 받아야 하는 네트워크 상황에서 이러한 재전송 방식은 그 자체로 비효율적이기 때문에 이러한 재전송을 최대한 적게하는 방식으로 TCP는 오류를 제어하고 있다.
1.2.1 ARQ (Automatic Repeat Request)
- 통신중에 어떤 오류가 발생하여 송신 측에서 수신 측으로부터 응답을(ACK) 받지 못했다면 오류로 판단하고 데이터를 재전송하는 방식을 사용하여 오류 발생 상황을 해결한다는 의미이다.
1.3 혼잡제어
- 혼잡 제어란 네트워크의 혼잡 상태를 파악하고 이 상태를 해결하기 위해 데이터 전송을 제어하는 것을 뜻한다.
- 네트워크는 워낙 광대하기 때문에 정확히 어디서 어떤 이유로 전송이 느려지는지는 파악하기 힘들지만, 응답성 저하에 대한 여부는 각 종단점(End Point)에서도 파악이 가능하다.
데이터를 보냈는데 수신 측으로부터 응답이 늦게오거나 오지않으면 문제가 있는 것으로 판단하면 되기 때문이다. - 네트워크에 이상이 생겼을 때 위에서 설명한 흐름 제어나 오류 제어 기법만을 사용한다면 재전송이라는 작업이 불필요하게 반복될 수 밖에 없는데, 이미 네트워크에 이상이 발생한 시점이라면 재전송은 굉장한 트래픽 낭비가 될 것이다.
- 이를 해결하기 위해 TCP는 네트워크의 혼잡 상태를 감지하게 되면 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이것이 바로 혼잡 제어이다.