Multiplexing/Demultiplexing과 신뢰적 데이터 전송 프로토콜

Multiplexing / Demultiplexing

전송 계층은 상위 계층인 애플리케이션 계층에서 소켓을 사용해 전달한 데이터를 세그먼트로 만든다. 여러 소켓에서 각자의 메시지를 전송 계층으로 전달하면 그걸 하나의 세그먼트로 묶는다는 의미에서 multiplexing이라고 한다.

반대로 Demultiplexing은 세그먼트를 전송받는 전송 계층에서 수행하는 것으로, 세그먼트에 담긴 데이터를 알맞는 소켓에 각자 전달해주는 것이다.

어떻게?

세그먼트는 헤더와 데이터로 이루어져 있다. 헤더는 여러 필드로 구성되어 있는데 그 중에 source port와 dest port 등의 필드를 통해 디멀티플렉싱을 할 수 있게 된다.

UDP vs TCP의 디멀티플렉싱

UDP: dest IP와 dest port 두 개를 사용해서 디멀티플렉싱한다.

TCP: UDP가 사용하는 두 개와 더불어 source port와 source IP까지 포함해서 총 네 개의 필드를 사용해서 디멀티플렉싱을 한다.

(정확히 말하면 IP에 대한 필드는 전송 계층의 헤더가 아닌 네트워크 계층의 '패킷'의 헤더에 있다.)

• UDP: dest IP, dest port 두 필드가 같으면 같은 소켓으로 간다
• TCP: dest IP, dest port가 같아도 source IP나 source port가 다르면 다른 소켓으로 올린다

전송하는 컴퓨터의 IP는 물론 소켓마다 받는 컴퓨터에게도 1:1 대응하는 소켓을 가지는 것이다. 그래서 TCP에서의 경우를 Connection-oriented demux라고 한다.

참고: 여기서 궁금한 점이, dest port가 같은데 어떻게 각자 다른 소켓으로 연결한다는 말이지? 포트번호는 소켓에 부여되는 게 아니라 프로세스에 부여되는 것이라고 한다.

UDP의 세그먼트 헤더

필드는 네 개가 있다:

• source port
• dest port
• length
• checksum: 전송 과정 중 에러가 발생했는지 확인할 수 있는 필드. 에러가 있으면 소켓으로 전달하지 않고 드랍한다.

UDP도 최소한 1) 멀티플렉싱/디멀티플렉싱과 2) 에러 확인 두 기능은 제공해준다.

신뢰적 데이터 전송 (Reliable Data Transfer)

Reliable: 데이터가 유실되지 않고 전부 전송된다는 의미다.

TCP는 앞서 본 것처럼 소켓끼리 1:1 연결을 제공하면서 reliable한 연결을 보장하는 것 같이 보이지만, 실제로 TCP 통신도 매우 불안정하다고 한다. packet error, packet loss가 발생한다. 그래서 안정적인 데이터 전송 프로토콜을 고안해보자.

필요한 메커니즘들

1. 에러 감지 (checksum)

전송 과정에서 발생한 비트 에러를 감지한다.

2. 피드백

• Acknowledgements (ACKs) : 수신자가 발신자에게 패킷이 제대로 도착했음을 명시적으로 알려주는 방법
• Negative Acknowledgements (NAKs) : 수신자가 발신자에게 패킷에 에러가 있었음을 명시적으로 알려주는 방법

3. 재전송

• NAK 시에는 해당 패킷을 다시 전송한다
• 발신자는 수신자로부터 ACK가 오면 다음 패킷을 전송한다

위의 세 메커니즘들로 언뜻 보면 충분할까?

4. 시퀀스 번호

만약 수신자가 전송하는 피드백(ACK, NAK)에 에러가 있다면? 피드백을 받았는지에 대한 피드백을 또 전송해야 되나? 그럼 그 피드백에서 또 에러가 발생한다면? 그래서 이런 방식으로는 해결할 수 없다.

그래서 피드백에 에러가 있으면 발신자는 NAK일 수 있으니 해당 패킷을 무조건 다시 전송한다. 그러면 수신자 측에서는 이 패킷이 새로운 패킷인지 아니면 이전에 받은 패킷이 중복된 것인지 어떻게 알 수 있을까?

그래서 각 패킷별로 번호(시퀀스)를 붙여 해결한다.

그런데 시퀀스를 0,1,2, ... 이렇게 계속 무한대로 붙여나가야 하나? 그런데 우리가 가정한 이 프로토콜에서는 한 번에 하나의 패킷을 순차적으로 전송한다. 그래서 0과 1 두 개를 돌려쓰면 된다 (패킷의 개수 mod 2).

NAK-free 방식

시퀀스를 사용한다면 NAK를 사용하지 않으면서 구현할 수 있다. 수신자는 패킷 번호를 담은 ACK를 보낸다. 에러가 있는 패킷을 받으면 이전 패킷의 ACK를 보낸다. 그러면 발신자는 패킷을 다시 전송한다.

5. 타이머

만약에 패킷이 유실되어 아예 도착하지 않았다면, 영원히 피드백을 기다릴 수 없으니 타이머를 설정하고 정해진 시간 안에 피드백이 오지 않으면 유실로 간주하고 재전송하면 된다.

그런데 타이머의 시간은 어떻게 정해야 될까?

• 타이머의 시간이 너무 짧으면: 네트워크 사용량이 많다는 단점(premature timeout 경우)이 있다
• 타이머의 시간이 너무 길면: 네트워크 사용량이 줄지만 데이터 전송 과정 자체의 시간이 길어질 수 있다는 단점이 있다

Pipelined Protocols

이렇게 5가지 메커니즘 (에러 감지, 피드백, 재전송, 시퀀스, 타이머)을 사용해서 패킷을 순차적으로 하나씩 전송하는 프로토콜을 고안해봤는데, 실제로 TCP도 이와 유사한 방식(규칙은 똑같다)을 사용한다.

그런데 지금 고안한 프로토콜은 너무 단순하고, 그래서 비효율적이다. 한 번에 하나의 패킷을 전송하면 안정적이지만 매우 비효율적이다.

Go-Back-N (GBN)

이 프로토콜은 '윈도우(window)'라는 단위로 한 번에 여러 패킷을 보낸다.

예를 들어 윈도우 사이즈가 5라면, 한 번에 0,1,2,3,4번 패킷을 전송한다. 수신자 측에서는 맞게 수신한 패킷 번호별로 ACK를 보낸다. 3번 패킷에서 에러가 발생하면 ACK2까지 피드백을 보낸다 (cumulative ACK라고 한다).

그러면 발신자는 다시 3번부터 윈도우 사이즈에 맞게 5개의 패킷 3,4,5,6,7을 보낸다.

이 방식은 위에서 고안한 프로토콜보다 더 효율적일 수 있지만 그래도 중복되는 패킷을 여러 번 전송해야 될 수 있다는 점에서 아직도 많이 비효율적이다.

Selective Repeat (SR)

이 방식에서는 cumulative ACK가 아니라 모든 패킷에 대해 ACK를 보낸다. 0,1,2,3,4 중에서 3번 패킷에서 오류가 발생했으면 ACK는 0,1,2,4번만 보낸다.

시퀀스 번호는?

그런데 위의 방법에서 문제가 패킷 번호를 어떻게 해야 되는지에 대한 문제가 남는다. 윈도우 사이즈가 5라고 하면 시퀀스 번호 몇 개를 써야 할까?

문제 상황 예시:

윈도우 사이즈가 3이고 패킷 번호를 0,1,2,3 이렇게 네 개를 사용한다고 가정해보자.

1. 처음에 0,1,2를 전송했고 수신자는 모두 잘 전달받아서 ACK를 전송했지만 그 피드백들이 모두 유실되었다고 하자
2. 그러면 발신자는 timeout되니 다시 모든 패킷을 재전송
3. 수신자는 3,0,1을 기다리는데 도착한 0,1,2 중에 0과 1이 중복된 패킷인걸 알아내지 못한다

해결 방법:

이걸 해결하는 것은 간단한데 시퀀스 번호를 늘리면 되는 것이다. 윈도우 사이즈의 2배 개수의 시퀀스 번호를 사용하면 겹칠 일이 없다.

N개를 보냈을 때 a개의 에러가 발생한다고 하면 N+a개의 시퀀스 번호를 사용하면 되는데, N개 안에서 발생할 수 있는 패킷 오류의 수는 N이니까 N+N을 사용하는 것이다.

Selective Repeat이 그러면 최선일까?

이제 시퀀스 번호 문제도 해결됐는데 그러면 이 방법이 최선일까? 지금 사용되고 있는 TCP는 이 방법을 사용할까?

구현에 비용이 너무 많이 든다고 한다 (비용이라 함은 컴퓨팅 자원의 소모가 크다는 말). 그래서 실제로 TCP에서는 Go-Back-N과 Selective Repeat의 장점을 잘 섞어서 사용 중이라고 한다.

각 방식의 장단점:

• GBN의 장점: Selective Repeat 방식처럼 복잡한 관리가 필요하지 않다는 점
• Selective Repeat의 장점: GBN처럼 중복된 패킷을 여러 번 재전송할 필요가 없다는 점

이런 장점들이 있는 것 같은데 이들을 어떻게 섞었다는 걸까? TCP는 기본적으로 GBN의 cumulative ACK 방식을 사용하면서, Fast Retransmit 같은 기법으로 Selective Repeat의 장점을 일부 가져온다고 볼 수 있다.

정리

신뢰적 데이터 전송을 위해서는 다음 5가지 메커니즘이 필요하다:

1. 에러 감지 (checksum)
2. 피드백 (ACK/NAK)
3. 재전송
4. 시퀀스 번호
5. 타이머

그리고 효율성을 위해 pipelining을 도입하면서 Go-Back-N과 Selective Repeat 같은 프로토콜이 등장했고, 실제 TCP는 이들의 장점을 조합해서 사용하고 있다는 점이다.