컴퓨터 네트워크 3. 트랜스 포트 계층

본 장은 애플리케이션 계층과 네트워크 계층 사이에 존재하는 트랜스포트 계층을 다룰 것이다. 트랜스포트 계층은 상위 계층에게 직접 통신 서비스를 제공해주는 중요한 기능을 가지고 있다. 글에서는 트랜스포트 계층의 원리와 이 원리들이 트랜스포트 계층 프로토콜에 어떻게 구현되어 있는지를 중심으로 알아볼 것이다. 특히 TCP,UDP 트랜스포트 계층 프로토콜을 자세히 다루어볼 것이다.

 

 

 

 

1. 트랜스포트 계층이란?

트랜스포트 계층은 애플리케이션 프로세스 간의 '논리적 통신(logical communication)'을 제공한다. 논리적 통신이란 애플리케이션의 관점에서 보면 프로세스들이 동작하는 호스트들이 실제로는 떨어져 있어도 직접 연결된 것처럼 보이게 해준다는 것을 의미한다. 트랜스포트 계층의 프로토콜은 네트워크의 가장자리 단에 위치하기 때문에 네트워크 라우터가 아닌 종단 시스템에서 구현된다. 자세히 말하자면 애플리케이션이 수,송신한 메시지를 트랜스포트 계층 패킷으로 캡슐화해 상,하위 계층으로 전달해준다. 트랜스포트 계층은 네트워크 계층과 역할은 비슷하지만 이 역할을 수행하는 위치가 다르다. 트랜스포트 계층 프로토콜은 서로 다른 호스트에서 동작하는 프로세스들 사이의 논리적 통신을 제공하지만, 네트워크 계층 프로토콜은 호스트들 사이의 논리적 통신을 제공한다. 이 차이를 예를 들어서 이해해보자.
두 집 간의 우편을 통한 통신을 가정해보자. 한 가정에서 가족 구성원들이 보낸 편지를 모아서 우편 배달원에게 전달해주는 사람의 역할은 트랜스포트 계층 프로토콜의 역할과 같다. 모아진 편지를 목적지의 가정에 전달해주는 우편집배원의 역할이 네트워크 계층 프로토콜의 역할이라고 할 수 있다. 가족들의 편지를 모아서 우편 배달원에게 전달해주는 사람(트랜스포트 계층 프로토콜)은 우편 집배원(네트워크 계층 프로토콜)이 어떤 경로로 어떻게 목적지엑 전달해주는지 관심 없다. 마찬가지로 각 계층의 프로토콜들은 하위 계층에서 어떻게 메시지가 전송되는지 모른다. 단지 자신의 계층에서 프로세스의 메시지를 전달할 뿐이다. 그렇다면 어떻게 프랜스포트 계층 프로토콜들이 편지를 모으고 다시 분배하는지 알아보자.
위에서 말한 편지를 모으고 분배하는 것을 네트워크 식으로 말하자면 호스트-호스트 전달을 프로세스-프로세스 전달로 확장한다고 말한다. 이를 "트랜스포트 다중화(transport multiplexing)'와 '역다중화(demultiplexing)'이라고 부른다. 이러한 서비스는 트랜스포트 계층 프로토콜인 UDP와 TCP 둘 모두가 제공하는 서비스다. 하나의 호스트는 여러 개의 네트워크 애플리케이션 프로세스를 가질 수 있기 때문에(ex: http,FTP ...) 호스트는 자신에게로 오는 수많은 메시지를 이 각각의 애플리케이션에 분배해야 할 필요성이 있다. 이 과정이 어떻게 가능한지 살펴보자. 네트워크 애플리케이션은 전 글에서 언급한 것과 같이 프로세스가 소켓을 가지고 있는 구조이다. 이 소켓은 각각의 애플리케이션에 따라 식별자를 통해 구분할 수 있다. 수신 측 호스트는 수신한 트랜스포트 계층 세그먼트에서 이 소켓을 구분하는 식별자 필드를 포함하고 있는데, 트랜스포트 계층이 이 필드를 통해 소켓을 식별하고 알맞게 분배해준다. 식별자 필드는 정확하게 말하자면, 출발지 포트번호 필드와 목적지 포트 번호 필드로 이루어져 있다. 이 과정을 역다중화라고 하는 것이다. 반대로 송신측 호스트에서 데이터를 모아 헤더 정보를 통해 캡슐화하고 이를 목적지에 전달하기 위해 네트워크 계층으로 넘겨주는 것을 다중화라고 한다. 호스트의 각 소켓이 부여받은 포트 번호를 통해 메시지들이 역다중화되고, 네트워크 계층에게 넘겨주면 송신 측 호스트가 식별자 필드의 목적지 포트 번호로 다시 메시지를 분배하는 역다중화가 이루어지는 것이다.

우편을 모으고 나누는 것은 트랜스포트 다중화와 역다중화와 같다

 

 

 

 

2. 비연결형 트랜스포트 UDP

트랜스포트 계층에 대해 알아보았으니 대표적인 트랜스포트 계층 프로토콜인 UDP에 대해서 알아보자. UDP는 전 글에서 말했던 것처럼 최소한의 서비스만을 제공하는 프로토콜이다. 메시지가 잘 전달되는 것을 보장해주지 않고, 순서대로 도착함을 보장해주지 않는다. 사실 UDP는 다중화/역다중화 서비스와 간단한 오류 검사(체크섬을 이용한)를 제외한 모든 서비스를 제공하지 않는 프로토콜이다. 또 UDP는 메시지를 전달하기 전에 핸드 셰이크를 하지 않는 비연결형 트랜스포트 프로토콜이기도 하다. 여기까지만 보면 UDP 프로토콜을 선택할 이유가 없어보인다. 하지만 많은 네트워크 애플리케이션들이 메시지를 전송할 때 UDP 프로토콜을 이용한다. 그 이유는 다음과 같다.

 

1. 연결 설정이 없어 빠르게 동작한다.

2. 연결 상태를 유지하지 않아 더 많은 클라이언트와 통신할 수 있다.

3. 패킷의 헤더가 작아 오버헤드 또한 작다.

4. 애플리케이션 레벨에서 데이터의 전송률을 더 정교하게 제어할 수 있다.

 

이러한 장점으로 인해 UDP 프로토콜은 일부 스티리밍 프로토콜이나 네트워크 관리에 사용되는 'SNMP(simple network management protocol)',호스트 네임을 IP주소로 변환시켜주는 DNS 프로토콜에 사사용된다. 이 프로토콜들은 작은 양의 데이터 손실을 감수할 수 있으며 혼잡제어 서비스보단 일정량의 요구되는 전송률을 더 원하기 때문이다.
또 UDP는 체크섬을 이용한 간단한 오류 검출을 제공한다. 체크섬이란 데이터그램 안에 있는 모든 데이터는 16비트 워드 단위로 더하고, 이에 대하여 다시 1의 보수를 수행해 이루어진다. 이 결과값이 UDP 세그먼트의 체크섬 필드에 입력된다. 수신자는 수신한 데이터그램과 체크섬을 모두 더한 결과가 1111111111111111이면 손실없는 데이터를 제공받았다고 판단한다. 반대로 비트 중 하나라도 0이 존재한다면 데이터에 손실이 발생했음을 알 수 있다. 물론 링크 계층 프로토콜이 다양한 오류 검사(체크섬, CRC, 패리티 체크)를 제공하지만 몇몇 링크는 이러한 오류 검출을 제공하지 않을 수도 있기 때문에, 트랜스포트 계층에서 오류 검사를 제공해야만 한다. 이를 '종단간의 원리(end-end principle)'이라고 한다. 정확한 종단간의 원리는 다음과 같다.

'어떤 기능은 종단 기반으로 구현되어야 하므로, 하위 레벨에 위치한 기능들은 상위 레벨에서 이 기능들을 제공하는 비용을 비교했을 때 중복되거나 거의 유용하지 않을 수 있다'

즉 하위 계층에서 오류 검출 서비스를 제공할 수 있다고 해서 상위 계층이 이러한 서비스 제공을 포기해서는 안된다는 것이다.

 

3. 신뢰성 있는 데이터 전송

UDP에 대한 내용을 마치고 TCP에 대한 설명으로 들어가기 전에, TCP가 제공하는 신뢰적인 데이터 전송의 원리에 대해 알아보자. 위에서 언급한 종단간의 원리에 따라, 하위 계층이 신뢰적 데이터 전송을 보장할 수 있다고 해도 모든 채널이 보장하지는 않기 때문에 트랜스포트 계층에서 신뢰적 데이터 전송을 보장할 필요성이 있다. 그래서 이런 신뢰적 데이터 전달 프로토콜의 과정을 살펴보아 이 서비스가 어떻게 구현되는지 알아보고자 한다. 이를 위해 몇몇 과정을 통해 조금씩 복잡해지는 일련의 프로토콜을 알아보자.

 

1. 완벽하게 신뢰적인 채널 상에서의 신뢰적인 데이터 전송 : rdt 1.0

처음에는 모든 채널이 완벽하게 신뢰적이어서 데이터가 손실될 가능성이 없다고 가정하자. 이러한 상태에서는 수신자와 송신자가 단순히 데이터를 주고받는 과정만이 필요하다. 즉 송신 측은 상위 레벨로부터 데이터를 전달받고 이를 패킷으로 만들어 즉시 수신 측에게 보낸다. 그 후 수신 측은 송신 측에서 온 패킷을 전달받아 다시 데이터로 만든 후 상위 레벨로 전달한다. 이런 완전히 신뢰적인 채널에서는 수신자가 어떠한 피드백을 제공할 필요도 없으며 송신자가 패킷을 전달할 타이밍을 조절할 필요도 없다.

 

2. 비트 오류가 있는 채널 상에서의 신뢰적인 데이터 전송 : rdt 2.0

이제는 점점 현실적인 상황으로 들어가자. 이번에는 패킷 안의 비트들이 하위 레벨에서 손상될 수도 있다고 가정하는 모델이다. 하지만 일단 전송된 패킷들은 순서대로 수신된다고 가정하자. 이 상태에서는 송신자가 전달 과정 중 비트 오류가 발생할 가능성을 염두해 수신자로부터 어떠한 피드백을 받아야 한다.(전달받은 데이터가 오류가 있는지, 없는지) 그래서 수신 측은 긍정 확인응답 ACK와 부정 확인응단 NAK를 통해 이러한 피드백을 송신 측에게 제공한다. 피드백을 받은 송신 측은 데이터가 손실되었다는 응답을 받은 경우(NAK) 다시 패킷을 전송한다. 이러한 재전송을 기반으로 한 전송 프로토콜을 'ARQ(automatic repeat request)' 프로토콜이라고 한다. 이러한 ARQ를 사용한 프로토콜은 수신 측이 패킷을 보내고 송신 측이 보낸 확인응답을 전달받을 때까지 다음 패킷을 보내지 않는다. 이러한 행동 때문에 rdt 2.0은 '전송 후 대기(stop and wait)' 프로토콜이라고도 불린다. 여기까지 rdt 2.0은 완벽한 프로토콜로 보이지만 치명적인 결함이 하나 있다. ACK,NAK 응답 자체가 손실될 가능성을 고려하지 않았다는 것이다. 이 경우 송신자가 왜곡된 응답 패킷을 받았을 때 다시 패킷을 전송할 수 있지만, 수신자는 이 패킷이 다음 명령에 대한 패킷인지, 아니면 재전송한 패킷인지 모른다는 것이 문제이다.(수신자는 응답이 잘 도착했는지 여부를 모르므로) 이러한 문제를 해결하기 위해 rdt 2.0은 패킷에 순서번호 필드를 만듦으로서 해결한다. 송신자는 0 또는 1을 번갈아 붙이는 순서번호를 패킷에 첨부한다. 수신자는 받은 패킷의 순서번호를 확인해 이것이 재전송한 패킷인지, 다음 명령의 패킷인지를 판단한다.(패킷의 순서는 0 다음 1, 다음 0 이므로) 더 발전된 형태는 NAK 확인응답을 사용하지 않는 대신 최근 정확하게 수신된 패킷에 대해 ACK를 한번 더 송신함으로써 같은 효과를 얻는다. 송신 측은 같은 패킷에 대해 두 번의 ACK가 온 경우 그 다음 패킷이 전달되지 않았다는 것을 알 수 있다. 이경우 ACK 응답은 전달받은 패킷의 순서번호를 같이 첨부해야 한다.

 

3. 비트 오류와 손실 있는 채널 상에서의 신뢰적 데이터 전송 : rdt 3.0

마지막으로 가장 현실적인 모델인 rdt 3.0에 대해 알아보자. 이 모델은 비트가 손상되는 것 외에도 하위 레벨에서 패킷을 손실하는 경우도 포함한다. 이런 상황에서 프로토콜은 패킷이 손실된 것을 어떻게 검출할 것이며, 손실된 것을 검출했을 때 어떤 행동을 할 것인지를 결정해야 한다. 수신자는 ACK 패킷 자체를 받지 못했을 경우가 발생할 수도 있다. 이 경우 수신자는 충분한 시간을 기다린 후 ACK패킷이 손실되었다고 판단한 후 패킷을 다시 전달할 수 있다. 이 시간이 길어질수록 전송률은 낮아질 것이다. 너무 짧으면 응답패킷이 올바르게 도착하기도 전에 중복 패킷을 전달하고 말 것이다. 일반적으로 기다리는 시간은 수신자와 송신자 간의 왕복 지연 시간에 수신자의 처리시간을 더한 것이지만, 이를 파악하는 것은 불가능하다. 그래서 수신자는 카운트다운 타이머를 설정한 후 타이머가 만료되면 손실 판단 여부를 떠나 일단 패킷을 재전송한다. 이러한 방법으로 송신자는 패킷이 손실된 경우, ACK 패킷이 손실될 경우 모두 패킷을 재전송하게 된다.

 

4. 파이프라인된 신뢰적 데이터 전송 프로토콜

위의 rdt 프로토콜들은 모두 확인응답이 오기 전까지 다음 패킷을 보내지 않는 전송 후 대기 프로토콜이다. 이러한 방식은 안전할 수는 있지만 전송률에 있어 큰 손해를 보게 된다. 그래서 파이프라인된 프로토콜은 여러 개의 패킷을 한번에 전송하고, 여러 개의 확인 응답을 통해 전송여부를 확인한다. 이러한 프로토콜을 구현하기 위해서는 우선 순서번호의 크기가 커져야 하고, 버퍼링 기능이 필요하며, 다른 오류 회복 기법이 필요하다. 파이프라인된 신뢰적 데이터 전송 프로토콜에서 사용되는 오류 회복 기법은 'N부터 반복(go back N)'과 '선택적 반복(selective repeat) 등이 있다.
선택적 반복(GBN) 프로토콜은 윈도우라고 불리는 일정한 패킷 순서번호의 양을 유지하는 오류 회복 기법이다. GBN은 송신자가 확인응답을 기다리지 않고 여러 패킷을 전송할 수 있지만 파이프라인에서 확인응답이 안된 패킷의 최대 허용 수는 윈도우 크기보다 크지 않아야 한다. 송신자는 ACK 패킷이 손실되면 타임아웃 이벤트의 발생으로 전송되었지만 확인응답되지 않은 모든 패킷을 다시 송신한다. 물론 이 패킷들의 양을 윈도우 사이즈보다 작을 것이다. GBN 프로토콜은 패킷 하나의 오류 때문에 여러 패킷들을 다시 파이프라인으로 보내야 하는 불필요함이 발생하게 된다. 그래서 선택적 반복(SR) 프로토콜은 이러한 문제를 해결하기 위해 수신자에서 오류가 발생한 패킷을 수신했다고 의심되는 패킷만을 재송신한다. 이는 수신자와 송신자가 각각의 개별적인 확인응답을 하고, 각기 다른 윈도우를 가지며, 수신자는 윈도우 크기(N) 아래의 수신에 대해서도 확인응답을 보냄으로서 구현할 수 있다. 여기서 발생할 수 있는 문제는 윈도우 크기가 너무 클 경우 송신자가 보낸 패킷의 순서번호가 새로 보낸 명령인지, ACK 패킷의 분실로 인해 다시 보낸 명령인지 분간할 수 없다는 것이다. 이 문제를 해결하기 위해서는 윈도우 크기가 순서번호 공간 크기의 절반보다 작거나 같아야 한다.

확인 후 응답 프로토콜의 단점을 극복하기 위해 파이프라인 방식의 프로토콜이 등장하였다

 

4. 연결지향형 트랜스포트: TCP

이제까지 TCP가 제공하는 서비스인 신뢰적인 데이터 전송을 다루었으니, 본격적으로 TCP에 대해 알아보자.
TCP의 가장 큰 특징은 애플리케이션 프로세스가 다른 프로세스에게 메시지를 보내기 전에 두 프로세스가 핸드 셰이크를 먼저 해야 한다는 것이다. 이러한 특징 때문에 TCP는 '연결지향형(connection-oriented)'라고 불린다. 또 TCP는 두 호스트 간의 데이터 연결이 두 방향으로 동시에 흐를 수 있으므로 '전이중(full-duplex) 서비스'를 제공하며, 항상 단일 송,수신자 사이의 '점대점(point to point)' 서비스이다.

본격적으로 TCP의 서비스를 알아보자. 우선 클라이언트 프로세스는 서버 프로세스와의 연결을 위해 세그먼트를 주고 받는다. 이후 클라이언트 프로세스는 세번쨰 세그먼트를 페이로드와 함께 보냄으로써 세 방향 핸드셰이크가 이루어진다. TCP에서는 이 세그먼트에서 순서번호 필드와 확인응답 필드를 포함하고 있다. 이 필드는 TCP의 신뢰적 데이터 전송에서 중요한 위치를 차지한다. 이 순서번호의 확인을 통해 어떤 패킷이 손실되었는지 파악할 수 있기 때문이다. TCP는 타이머를 패킷을 보낼 때마다 활성화 시킴으로서 타임아웃 이벤트가 발생할 시 해당 세그먼트를 재전송하여 확인응답 패킷의 손실에도 대비할 수 있다.
TCP는 '흐름제어 서비스(flow control service)' 또한 제공한다. 흐름제어 서비스는 수신 호스트가 너무 많은 데이터의 도착으로 인해 오버플로를 일으키지 않도록 적절한 양의 데이터를 전송할 수 있게 해주는 서비스이다. 이 서비스는 송신자가 수신 윈도우라는 변수를 유지함으로서 가능하다. 수신 호스트의 버퍼의 크기는수신 버퍼에 저장된 바이트의 수-버퍼로부터 읽힌 데이터의 마지막 바이트 수 보다 작거나 같다. 수신 윈도우는 버퍼의 여유 공간으로 설정되어, 버퍼의 크기에서 받은 바이트 수-읽힌 바이트 수를 뺀 값과 같다. 송신 호스트는 이 윈도우의 크기를 수신  측으로부터 전달받아 보내는 데이터 양을 적절하게 조절할 수 있다. 윈도우가 가득 차 송신이 불가능해 수신이 윈도우 크기를 대답하지 못할 경우를 대비해 송신 호스트는 작은 데이터를 지속적으로 전달해준다.
마지막으로 TCP의 '혼잡제어 서비스(congestion control service)'는 네트워크 전체의 혼잡을 줄이기 위해 TCP가 제공하는 서비스이다. TCP는 패킷이 전송되고 확인응답이 오기까지의 시간인 RTT를 이용해 네트워크의 혼잡도를 측정한다. TCP의 혼잡제어는 슬로 스타트, 혼잡 회피, 빠른 회복으로 대표되는 3가지 모드를 전환함으로써 보낼 수 있는 패킷의 양인 혼잡 윈도우의 크기를 조절한다. 이 조절은 가법적 증가, 승법적 감소로 일컫어지며 윈도우의 크기는 임계치에 달할때까지 1 MSS씩 가법적으로 증가해 임계치에 도달하면 절반으로 승법적으로 감소된다.

TCP는 호스트 간의 핸드 셰이크를 통해 통신을 연결한다

 

여기까지 트랜스포트 계층에 대한 전반적인 소개와 신뢰적인 데이터 전송의 원리, 대표적인 트랜스포트 계층의 프로토콜인 UDP와 TCP에 대하여 알아보았다. TCP와 UDP에 대한 이해를 통해 어떻게 트랜스포트 계층이 애플리케이션 계층의 메세지를 받아 캡슐화하여 하위 계층으로 전달하는지 알 수 있다. 여기까지가 네트워크 가장자리의 끝이다. 다음 링크 계층은 네트워크의 코어 단을 다루게 된다.