[네트워크] 클라이언트/서버 통신 원리

1. Client / Server System의 변천사

클라이언트/서버(이하 C/S) 시스템은 서버에 있는 풍부한 자원들과 서비스를 통합된 방식으로 제공받기 위한 시스템입니다.

자원: 데이터(ISAM, Database), CPU, 파일, 문서, 이미지, 멀티미디어 등등

서비스: 고도의 CPU와 메모리를 통해서만 산출될 수 있는 계산 결과나 집중되고 통합된 데이터와 로직을 기반으로 한 비즈니스 로직의 결과 등등

- 엄청난 고가의 자원가 서비스가 집중된 중앙 서버에 집중되어 있던 메임프레임워크 시대를 지나 좀 더 비용을 절감하고 자원을 효과적으로 분산시키기 위해 C/S 시스템은 다양한 방식으로 발전되어 왔다.

- 어찌보면, 메인프레임워크 시대 이후의 시스템에서 클라이언트, 서버라는 개념은 서로 상대적인 개념으로 변화되어 서버가 클라이언트의 역할을 그리고 그 반대의 역할을 수행하기도 한다.

- 결과적으로 C/S 시스템은 자원을 공유하고 소통하기 위한 수단으로 소통을 위한 소통 쌍방간 또는 다자간에 약속된 규약을 정하고 그에 기반하여 통신하기 위한 다양한 통신 프로토콜(규약)을 정의하고 발전해나가는 과정 이기도 하다.

- C/S 시스템의 발전과정은 좀 더 광범위하고 분산된 환경을 통합적으로 소통하고 공유하기 위해 좀 더 광범위하게 통일된 규약으로 모아져가는 경향이 있다. (HTTP, REST 등)

* 통신 프로토콜(Communications protocol)

통신 서비스 또는 기능 수행을 위해 관련 통신 당사자간 교환하는 정보의 종류와 표현 형식, 교환 절차, 그리고 교환 과정에서 실행해야 할 행위(actions)에 관한 규약(specification).

대표적인 통신 프로토콜로는 IBM의 폐쇄형 망 구조인 SNA(System Network Architecture)와 개방형 망구조인 TCP/IP가 있습니다. TCP/IP 응용 계층에 적용 확장된 프로콜로는 전자 우편 서비스를 위한 SMTP(Simple Mail Transfer Service), 파일 전송 서비스를 위한 FTP(File Transfer Protocol), 망 관리(Network Management) 서비스를 위한 SNMP(Simple Network Management Protocol), 그리고 우리가 주로 다루게 될 웹 서비스(Web Service)를 위한 HTTP(Hyper Text Transfer Protocol) 등이 있습니다.

* RIA(Rich Internet Application)

웹 애플리케이션의 장점은 유지하면서 기존 웹 브라우저 기반 인터페이스의 단점인 늦은 응답 속도, 데스크톱 애플리케이션에 비해 떨어지는 조작성 등을 개선하기 위한 기술의 통칭입니다. 즉, 별도의 설치가 필요 없는 웹 브라우저 기반의 애플리케이션 배포 장점과 서버 측 웹 서비스와의 연동, 마크업 언어 기반의 선언적 애플리케이션 구성 등은 유지하면서 데스크톱 애플리케이션과 대등한 사용자 경험을 주는 것을 목표로 하는 기술입니다.
흔히 어도비 플래시 기반 플렉스나 마이크로소프트 실버라이트, 자바FX 등 별도의 런타임 시스템을 가진 기술을 지칭하는 용어로 사용되나 웹 브라우저에서 실행되는 애플리케이션의 사용자 인터페이스를 향상하는 기법인 Ajax, 사용자 인터페이스 관점에서 많은 발전을 가져올 HTML5 등에 기반한 애플리케이션을 지칭하기도 합니다. 별도의 런타임 시스템을 가진 기술의 경우 애플리케이션은 브라우저 내에서 플러그인으로 실행되기도 하고 단독으로 실행되는 경우도 있습니다. 이 같이 "RIA"라는 개념은 정확한 정의가 있다기 보다는 다소 모호하고 넓은 의미로 사용되고 있습니다.

 

이 분류는 다소 도식적이고 인위적일 수 있으나 기술적 흐름을 이해하기 쉽게하기 위해 각 시기별로 지배적이고 중심적인 기술과 흐름에 따라 분류한 내용입니다. 실제로 현재에 이르서도 메인프레임은 여전히 사용되고 있으며, 위의 모든 기술들은 시대 구분 상관없이 현재도 상존하고 있는 기술과 환경들입니다.

현재는 메인프레임에서도 HTTP와 4GL 언어들을 사용하거나 Client/Server 모델 시스템에서도 HTTP를 통신 프로토콜로 사용하는 등 기술과 환경들이 상호 교체하며 사용되는 Crossover가 이뤄지고 있습니다. 국내에서는 RIA의 현재 흐름은 대부분 ActiveX를 이용한 방식을 취하고 있는데 이것은 RIA는 좀더 웹접근성이 보장된 방식을 통하지 않고는 결국 일부에서만 사용하는 폐쇄된 시스템이 될 것이면 결국 소멸될 가능성이 높습니다.

RIA는 HTML5와 CSS3 등의 표준 웹 방식과 jquery 등의 범용적이고 표준에 가까운 라이브러리를 이용한 방식이 선호되고 있습니다. 그동안 대표적인 RIA로 언급되었던 Adobe사의 AIR도 ActiveX와 같이 플러그인이 설치되어야하는 기술이었으며 결국 Adobe사는 AIR에 대한 전망을 접기로 결정하고 개발과 지원을 하지 않기로 하였으며, HTML5에 더 많은 기술 연구에 집중하고 있다는 사실에서도 증명되고 있습니다.

 

 

* Stateful / Stateless

 

여기서 상태(State)란 과거의 동작(데이터 송수신 및 처리) 결과 내지 정보를 의미합니다.

 

 

- TCP/IP 통신은 전송계층(Transport layer)인 TCP 또는 UDP를 이용하여 응용 계층(Application Layer) 구현을 자유롭게 할 수 있기 때문에 필요에 따라 Stateful / Stateless 모두 구현이 가능합니다.

- HTML5에서 지원하는 웹소켓은 양방향 통신이 가능한 Stateful 통신을 지원합니다.

- 한 때 클라이언트/서버 모델 환경에서 웹 환경으로 넘어가는 과도기에, Sateful 기반의 클라이언트/서버 통신 환경에 익숙한 설계자와 개발자들이 Stateless 기반의 웹환경의 차이점을 이해하지 못해 혼란스러워 하기도 했습니다. 심지어 Stateless 웹 애플리케이션 설계를 Stateful 기반으로 설계하고 개발과정에서 뒤집어 지는 경우를 보기도 했습니다. 물론 지금도 간간이 Stateless 운영원리를 무시한 설계와 개발을 하는 경우를 볼 수 있습니다.

 

 

Client / Server 모델

---

 

(1) 클라이언트 / 서버 모델 발달 배경

- 마이크로프로세서가 발달함에 따라 대형 메인 프레임에 준하는 워크스테이션 컴퓨터들과 개인용 컴퓨터(PC)가 등장하였습니다.

- UNIX 등 다양한 컴파일러와 개발에 유연한 서버급 운영체제와, 윈도우 등 화려한 GUI 기반의 운영체제가 일반화되었습니다.
- 그러나 워크스테이션급 서버 등은 메인프레임워크의 강력한 기능을 동등하게 제공할 수 없었습니다. 하지만 기업에서 비용절감의 요구가 부각되면서 워크스테이션급 서버가 차츰 메인프레임워크를 대체하게 되었고 메인프레임워크에 몰려있던 기능을 여러 대의 워크스테이션 서버로 분산시키는 방식을 사용하였습니다.

- 대신 서버 컴퓨터들을 네트워크로 연결하고 서로 통신하는 것이 중요한 요소로 떠오르게 되었습니다. 이러한 환경의 요구와 네트워크 환경의 발달에서 OSI, TCP/IP 등의 네트워크 프로토콜 계층 구조가 정의되고 발전하였습니다.

- 네트워크 통신의 발달로 서버 간 통신 뿐만 아니라 서버와 PC 간의 통신도 발전하여 클라이언트/서버 모델이 확산되었습니다.

- 네트워크/서버 모델을 통해 서버의 일부 기능(주로 업무 로직)을 클라이언트에 분산시켜 서버의 기능을 감소시키도록 했습니다.

- 서버들 혹은 클라이언트와 서버 사이의 네트워크는 이 당시 널리 보급되기 시작한 TCP/IP 프로토콜이 사용되었습니다. 값 싼 이더넷(Ethernet)과 간편한 TCP/IP 프로토콜은 클라이언트, 서버 환경에서 서버와 서버, 클라이언트와 서버를 손쉽게 연결할 수 있는 매개체가 되었습니다.

 

(2) 클라이언트/서버 모델의 구성과 통신 원리

- 일반적으로 클라이언트/서버 모델의 아키텍처 구성요소는 사용자 인터페이스(User Interface)를 담당하는 프리젠테이션 로직(Presentation logic), 업무 프로세스(Business Process)를 정의한 애플리케이션 로직(Application logic), 데이타 서비스(Data Service)를 담당하는 데이터베이스(Database)로 구성 됩니다.
- 이들 구성요소의 위치나 역할에 따라 2계층 구조(2-tier Architecture)와 3계층 구조(3-tier Architecture)로 분류됩니다.

- 클라이언트/서버 시스템의 구성요소 중 가장 중요한 것이 네트워크입니다. 앞에서도 언급했듯이, 클라이언트/서버 모델이 발전하게 된 배경에는 당시 브릿지(Bridge), 라우터(Router), 게이트웨이(Gateway)와 같은 접속장치의 발달로 LAN/WAN 기술이 빠른 속도로 발전하고 있었기 때문입니다.

- 발전된 LAN/WAN 네트워크 통신 환경에 따라 그에 맞는 다양한 프로토콜이 표준화되는 시도가 이루어 졌습니다. 가장 대표적인 것인 국제표준화기구(ISO)에서 개발한 OSI 7계층 모델(말 그대로 구현된 것이 아니라 일종의 표준 설계안)입니다. OSI 프로토콜은 프로토콜들의 계층별 집합입니다.

- 클라이언트/서버 모델에서 주료 사용되는 프로토콜은 TCP/IP 프로토콜입니다. TCP/IP 프로토콜은 OSI 모델이 설계되는 것과 병행해서 개발되었던 프로토콜로서 좀 더 간단하고 유연성이 뛰어나 실제 현장에서는 대부분 TCP/IP 프로토콜이 사용되고 있습니다. TCP/IP 역시 계층별 프로토콜의 집합으로서 OSI 모델과 달리 4개(또는 5개)의 프로토콜로 구성되어 있습니다.

 

 

- 하드웨어의 물리적 장치를 통해 특화된 네트워크 프로그램을 작성하기 위해서는 Application Layer(응용 계층)에서 소켓을 통해 Transport Layer(전송 계층)의 TCP 또는 UDP를 사용하여 개발해야 합니다. 소켓은 '응용 계층'에서 TCP/IP를 사용할 수 있는 일종의 창구역할로서 API 라이브러리입니다.

- '응용 계층'에 개발되는 네트워크 통신 프로그램은 통신 양방간 또는 다자간의 약속된 규약이 정의되고 구현됩니다. 즉, 이것도 일종의 프로토콜로서 FTP(파일 전송), telnet, SMTP(메일 전송), POP3(메일 수신)등이 대표적인 으용 계층 상의 프로토콜 입니다.

- 네트워크/서버 모델 프로그램 역시 해당 응용프로그램을 사용하는 주체의 필요에 의한 통신 규약을 정의하고 사용합니다.

- 초창기 클라이언트/서버 환경에서 애플리케이션 사이의 통신은 네트워크 패킷(packet) 기반의 전문 방식이 주로 사용되었습니다. 전문 통신 방식이란 통신에 참여하는 애플리케이션들이 주고받을 데이터의 포맷을 서로 약속(프로토콜)한 후 약속된 데이터 패킷을 전송하고 수신하는 것을 말합니다.

- 아래 그림의 예와 같이 통신을 위한 패킷을 정의하고 이 데이터 패킷을 애플리케이션이 주고 받게 됩니다. 클라이언트는 약속된 데이터 패킷의 포맷에 맞춰 패킷을 생성, 서버로 전송합니다. 서버는 패킷을 읽어 들이고 패킷에 기록된 데이터를 해석해 필요한 서버 측 작업을 수행하고 그 결과를 데이터 패킷에 기록해 클라이언트로 반환하는 것입니다.

struct DataPacket1 {
	int size;
	int cmd;
	char accountid[16];
	double amount;
}

struct DataPacket2 {
	int size;
	int cmd;
	char from_accountid[16];
	char to_accountid[16];
	double amount;
}

아래 그림은 가장 기본적인 소켓 통신의 Workflow를 표현한 것입니다. 클라이언트에서 DataPacket1 포맷의 데이터를 보내면 서버에서는 DataPacket2 포ㅓ맷의 데이터를 보내주는 것을 약속한(규약) 예제로 표현하였습니다.

 

자바에서도 소켓 클래스를 지원합니다. 아래 그림은 자바 소켓 통신의 기본적인 Workflow를 표현한 내용입니다.

 

 

 

미들웨어

---

- 기존의 전문 방식의 클라이언트/서버 통신은 개발 생산성이 너무 낮았고 애플리케이션들이 복잡해짐에 따라 수 백 수 천 개의 데이터 패킷 정의를 요구했습니다. 또한 과거 메인 프레임에서 가능했었던 트랜잭션 처리와 같은 고급 데이터 처리 기법 역시 새로운 클라이언트/서버 환경에 요구됐습니다.

- 따라서 클라이언트와 서버 사이에 데이터 패킷 생성 및 전달과 더불어 네트워크 상에 분산돼 있는 서버들을 찾아주는 네이밍(naming) 서비스, 트랜잭션 서비스 등을 제공하는 미들웨어(middleware)들이 등장하기 시작했습니다.

- 이러한 미들웨어를 통해 개발자는 클라이언트와 서버 측에서 애플리케이션 비즈니스 로직에 관련된 핵심코드만을 작성하는 편리성을 제공하고 이를 통해 생산성을 높일 수 있도록 했습니다.

- 미들웨어를 사용하면 더 이상 개발자가 Socket API를 직접 액세스할 필요가 없어지며 복잡한 TCP/IP 오류 처리 등을 고려하지 않아도 되었습니다.

 

 

원격 프로시저 호출(RPC - Remote Procedure Call)

- 네트워크로 연결된 서버 상의 원격 프로시저를 호출할 수 있는 기능을 제공

- 클라이언트에서 입력 값을 실어 원격 서버에 있는 프로시저를 호출하게 되고 호출된 프로시저는 수행된 결과를 클라이언트 프로세스에게 전달하는 방법을 취합니다.

- DCE/RPC(OSF의 표준 미들웨어), SAP사 ERP R/3의 원격 함수 호출(Remote Function Call) 형태의 기술, JAVA의 RMI

- IBM의 CICS6000, Transac의 ENCINA, BEA의 TUXEDO 등의 TP-MONITOR 내부에서도 공통적으로 사용하는 기술

- RPC는 현재에도 모든 기술에 녹아들어 사용되고 있는 기반 통신 기술이 되고 있습니다. 현재에 사용되는 SOAP/REST 등도 여기서 발전된 기술입니다.

 

 

 

DCE(Distributed Computing Environment)

- OSF(Open Software Foundation)에 의해 미들웨어의 표준으로 발표되었습니다.

- DCE는 단순한 애플리케이션 통신을 위한 미들웨어는 아니며, 분산 애플리케이션과 OS 사이에 위치하여 분산에 관련된 서비스를 통합적으로 제공하는 분산 컴포넌트 집합입니다.

- OS나 네트워크 등 자원에 독립적으로 분산된 어플리케이션을 통하여 여러 대의 이기종 컴퓨터의 자원을 공유하고, 서로 협력하는 분산 컴퓨팅 환경을 조성하였습니다.

- 그러나 DCE는 메모리를 비롯한 많은 자원을 요구하고 있고, 개발자들에게 다양한 프로그래밍 기술을 요구하였습니다. 또한 DCE를 지원하는 개발 도구들이 부족하여, 일반 기업에서는 크게 환영받지 못했습니다.

- DCE의 핵심 기술은 오늘날 중요한 컴퓨팅 영역인 보안, World Wide Web, 분산객체 등에서 사용되고 있습니다.

 

 

메세지 지향 미들웨어(MOM)

- MOM(Message-Oriented Middleware)은 네트워크 상에서 메시지를 전달하는 운반자입니다.

- 메시지 통신은 메세지의 보내기, 받기와 같은 단순한 수행으로 이루어지며, 일반적으로 전자우편시스템 등에서 많이 사용되어지고 있습니다.

- MOM은 메시지 보내기와 받기의 두 개의 프로세스가 활동적으로 메시지를 교환하는 모델과 하나의 프로세스가 일정한 큐(Queue)에 메세지를 저장하는 메세지 큐잉(Message Queuing) 모델(예: IBM의 MQ시리즈, Microsoft사의 MSMQ)로 나눌 수 있습니다.

- RPC와 마찬가지로 MOM 또한 표준 API를 제공함으로 시스템간 독립적인 통신을 하는데, RPC가 동기적(synchronous)이라면 MOM은 비동기적(Asynchronous)인 통신을 합니다. 그래서 MOM은 RPC를 보완하는 기능으로 사용되고 있습니다.

 

 

트랜잭션 프로세싱 모니터(TP-MONITOR)

 

- 많은 양의 데이터를 처리해야하는 시스템들은 안정된 트랜잭션을 요구하는데, 이것의 해결책으로 사용된 도구가 트랜잭션 프로세싱 모니터(TPM)입니다.

- C/S에서 사용되는 TPM은 일반적으로 분산 트랜잭션 모니터(Distributed Transaction Monitor)라고 합니다.

- TP-MONITOR의 대표적인 제품으로는 OSF/DCE를 기반으로 하는 Transac의 ENCINA, IBM CICS/6000과 BEA의 TUXEDO, TOPEND, Tmaxsoft의 Tmax 등이 있습니다.

- 여러 소프트웨어 상호간의 혼합된 환경에서 어플리케이션 개발의 능력과 부가적 서비스를 제공합니다. 즉, 통신 미들웨어 기능 외에 트랜잭션 협력 서비스, 안정적인 메세지 큐잉 시스템, 일의 흐름 관리 및 개발의 통합적인 서비스들을 제공합니다.

 

 

ORB(Object Request Broker)

- ORB는 지역 및 원격지에 위치한 객체들 사이의 통신을 담당하는 핵심기술로서 대부분의 객체지향 미들웨어에서 핵심 기술로 사용됩니다.

- ORB는 RPC의 형태를 기본적으로 수용하고 있고, RPC와 같이 어플리케이션에서 어플리케이션으로의 통신으로 호출과 답변(CALL-AND-RETURN)의 방식을 적용하지만, 객체기반의 구조를 가지고 있습니다.

- ORB는 객체지향 언어의 장점인 재사용성이라는 강점을 가지고 있습니다.

- ORB는 표준 인터페이스를 사용하여 객체들을 개발하도록 되어 있습니다. 표준 객체들 사이의 통신은 플랫폼에 독립적이며, 분산된 여러 객체 서버들과도 쉽게 연결이 가능하도록 설계되어 있습니다.

- ORB 인터페이스는 인터페이스 정의 언어인 IDL을 사용하며, 하나의 객체와 다른 객체 사이의 인터페이스를 정의하게 됩니다.

- Microsoft사의 DCOM+와 OMG의 CORBA 모델의 핵심 컴포넌트로 사용/응용되고 있습니다.

 

 

어플리케이션-TO-Database 방식의 DB 미들웨어

- DB 미들웨어는 하나의 애플리케이션을 특정 DB로 연결해주는 소프트웨어를 말합니다.

- 보통 클라이언트에게 공통의 SQL 호출 인터페이스를 제공함으로써 여러 종류의 DB에 쉽게 접근할 수 있도록 하는 역할을 합니다.

- DB 인터페이스의 표준인 SAG(SQL Access Group)에서 정의한 CLI(Call Level Interface)

- ODBC / OLEDB - MS, RDA(Remote Database Access - 표준) / DRDA(Distributed Relational Data Access) - IBM 등이 대표적인 것들입니다.

- C/S 구조로 보면 DB 미들웨어는 2-계층 모델에서 주로 사용되어 졌습니다.

 

이런 다양한 미들웨어는 여러 단계에 나뉘어 또는 병렬 처리되는 방식 등으로 구성되어 3-TIER 내지 N-TIER로 구성되기도 합니다.

 

 

Web 통신의 원리

---

- 웹 HTTP는 TCP/IP 프로토콜 기반이며, Application Layer(응용 계층)에 위치한 프로토콜입니다.

- 일반적으로 브라우저를 통해 통신을 하는데 다른 Application Layer(응용 계층)의 프로토콜과 마찬가지로 내부적으로 소켓 통신을 사용합니다.

- 그렇기 때문에 기본적으로 Internet Layer(인터넷 계층)의 IP에 접근할 수 있어야 합니다. 그래서 웹은 DNS 서버를 통해 도메인 주소에서 IP 주소를 얻어옵니다. 그 과정은 아래와 같습니다.

 

 

서버 작동과 클라이언트 호출 과정은 C/S 모델에서의 소켓 통신과 비슷합니다. 단, C/S 모델에서 사용하는 데이터 전문(패킷) 대신 HTTP 프로토콜에서 정의한 전문과 헤더를 통해 통신을 처리합니다.