신뢰적이란?
TCP는 신뢰적인 연결지향형 프로토콜이다.
여기서 신뢰적이라는 단어의 의미는 무엇일까?
간단히 말하면 송신자가 보낸 데이터를 수신자가 순서대로 정확하게 받을 수 있다는 것을 의미한다.
현실적인 상황
데이터를 멀리 떨어진 컴퓨터(종단 시스템)끼리 데이터를 주고받는 상황에서
데이터 발신자는 패킷의 오류와 손실없이 정확하게 가길 바란다.
하지만 실제로는 여러 라우터를(트랜스포트 하위 계층을) 거치면서 비트 오류도 발생하고 손실도 발생한다.
이번 글에서는 TCP를 알아보기 전에 이 신뢰적인 데이터 전송 구현 방법을 단계적으로 생각해본다.
이상적인 상황에서 현실적인 상황으로 조건을 점점 붙혀나가면서 개선해볼 것이다.
비트 오류 & 손실
여기서 비트 오류와 손실을 헷갈려선 안된다.
바나나라는 데이터를 바, 나, 나라는 패킷으로 전송하는 상황을 가정했을 때 둘은 다음과 같은 차이가 있다.
비트 오류 :
바,믋(오류),나
손실 :바,나(누락)
1. 비트 오류도 손실도 없는 상황
하위 계층이 각자의 역할을 완벽하게 해내고 있는 아주 이상적인 상황이다.
이 경우 발신자는 그냥 보내면되고 수신자는 그냥 받으면 된다.
어떠한 오류, 손실도 없고 잘보내진다는 가정을 한 상황이기 때문에
수신자가 잘받았다는 피드백도 필요없다.
2. 비트 오류가 발생하는 상황
이제 1번 상황에서 패킷 전송 시 비트 오류가 발생할 수 있다고 가정해보자.
비트 오류를 어떻게 대응할까?
하위 계층에서 발생한 비트 오류에 대응하려면 어떻게 해야할까?
가장 먼저 수신자가 비트 오류를 검출할 수 있어야 한다.
비트 오류를 검출하는 방법은 앞서 3-2에서 확인한 체크섬 필드를 사용한다면 검출할 수 있을 것이다.
비트 오류를 검출하면 끝일까?
아니다. 발신자로부터 오류가 발생한 패킷을 다시 받아야 한다.
패킷을 다시 받기 위해서 수신자는 패킷 수신에 대한 피드백을 발신자에게 전달해야 하고,
발신자는 수신자가 잘못 받은 패킷을 다시 보내주어야 한다.
즉 수신자의 피드백과 발신자의 재전송 기능이 필요하다.
추가되는 기능
1. 비트 오류 검출
2. 수신자 피드백
3. 재전송
구현
비트 오류 검출은 체크섬 필드로,
수신자 피드백은 {ACK, NAK}로 구현하면 된다.
ACK는 긍정 확인응답, NAK는 부정 확인응답으로 전화 통화할 때를 생각하면 된다.
발신자: 잘지내니?
수신자: 응ACK
발신자: 언제 한 번 밥이나 먹자.
수신자: 뭐라고? 잘 안들려.NAK
2.1 수신자 피드백도 오류가 발생할 수 있다.
2번 상황은 발신자에서 수신자로 가는 패킷의 비트 오류에 대응하기 위해서
체크섬 비트, 수신자 피드백(ACK, NAK)을 사용했다.
하지만 수신자 피드백도 오류가 발생할 수 있다는 치명적인 결함이 있다.
수신자 피드백 오류는 어떻게 대응할까?
오류 검출은 똑같이 체크섬 필드를 활용하면 충분하다.
중요한 것은 패킷의 비트 오류를 복구해야 한다.
비트 오류를 복구하는 방법은 3가지 방법이 있다.
방법 1) 수신자처럼
{ACK, NAK}를 도입한다.
방법 2) 오류를 복구할 수 있을 만큼 체크섬 필드를 키운다.(발신자가 바로 복구 가능)
방법 3) 단순하게 현재 패킷을 재전송한다.(= 중복 패킷을 전송한다.)
TCP를 포함한 모든 현존하는 데이터 전송 프로토콜은 방법 3을 채택했다.
구현
방법 3은 발신자 측에서 오류가 검출되면 중복 패킷을 수신자에게 재전송하는 방법이다.
이 방법을 적용하기 위해서는 수신자는 중복 패킷이라는 것을 확인할 수 있어야 한다.
어떻게 중복 패킷을 판단할 수 있을까?
패킷에 순서 번호(sequence number)를 부여하면 된다.
이전 순서 번호와 중복된 패킷이 온다면 패킷을 버리면 그만이다.
여기서 패킷의 순서 번호가 0과 1만 사용되는 것을 알 수 있다.
0과 1만 사용하는 이유는 순서번호는 오버헤드이기 때문이다.
애플리케이션 데이터인 바, 나, 나를 보내는게 목적이고, 순서 번호는 부가적인 정보이다.
바나나가 편지라면 순서번호는 편지봉투이다.
편지봉투가 편지보다 훨씬 커지는 것은 효율적이지 못하다.
지금은 발신자가 하나를 보내고 수신자의 응답이 올 때까지 대기하는 방식이기 때문에 1비트만으로도 충분히 표현할 수 있다.
2.2 이제 NAK는 필요하지 않다.
순서 번호(sequence number)가 생기면서 중복 패킷이 전달가능해지므로 NAK는 불필요해진다.
ACK의 순서 번호를 이전 패킷으로 준다면 어짜피 발신자는 재전송할 것이다.
이러면 NAK를 사용하는 방식과 차이가 없기 때문에 ACK로 통합한다.
3. 비트 오류와 손실이 발생하는 상황
이제 2번 상황에서 패킷 전송 시 패킷 손실이 발생할 수 있는 상황을 가정해보자.
패킷 손실을 어떻게 대응할까?
하위 계층에서 발생한 패킷 손실에 대응하려면 어떻게 해야 할까?
여기서는 발신자가 손실된 패킷을 검출하고 회복하도록 만들어보겠다.
발신자가 패킷 손실 문제를 해결하려면 패킷을 보내고 일정한 주기동안 수신자로부터 확인 응답이 오지 않는다면 재전송하여 해결할 수 있다.
즉, 충분한 시간안에 확인 응답이 오지 않는다면 타임아웃을 발생시키면 된다.
타임아웃 시간은 어떻게 설정할까?
설정된 타임아웃 시간은 시스템마다 다르고, 타임아웃 시간 설정은 정답이 없는 문제이다.
발신자와 수신자간의 왕복시간과 네트워크 지연시간을 고려해서 타임아웃 시간을 충분하게 설정해야 한다.
실제 상황에서 채택한 접근 방식은 손실이 일어났을 만한 충분한 시간에 재전송하는 것이다.
이 설정된 타임아웃 시간이 짧으냐 기냐에 따라서 장단점이 있다.
타임아웃 시간이 짧다.
장점 : 손실 발생시 빠르게 회복
단점 : 네트워크 부하 증가 (너무 짧아서 ACK가 늦게 오기전에 재전송해버릴 수 있음)
타임아웃 시간이 길다.
장점 : 네트워크 부하 감소
단점 : 손실 발생시 느리게 회복
이러한 장단점때문에 타임아웃 시간을 적절하게 잡는 것은 중요한 문제이다.
(이 주제는 이후 글에서 TCP를 배우며 다룰 것이다.)
구현
정리
지금까지 이상적인 하위 채널에서부터 비트 오류와 패킷 손실이 발생하는 하위 채널까지
상황을 추가해가며 신뢰적인 데이터 전송을 구현하기 위해 여러 기능들을 추가해봤다.
오류가 발생했을 때는 오류 검출을 위해 체크섬 비트를 도입했고, 이 검출한 오류에 대응하기 위해 수신자 피드백과 재전송을 도입했다.
그리고 마지막으로 손실이 발생했을 때는 타임아웃을 통해서 이를 해결했다.
하지만 이 글에서 생각해본 신뢰적인 데이터 전송 방식은 미흡한 부분이 있다.
먼저 한 번에 하나의 패킷을 보내고 수신자의 응답을 기다리고 있다.
이 미흡한 부분이 어떤 문제를 발생시키고 어떻게 개선해야하는지 다음 글에서 알아보자.
출처 및 참고
