2013년 10월 27일 일요일

클라이언트/서버 통신 원리(메인프레임에서 웹까지)


1. Client / Server System의 변천사


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

- 자원 : 데이터(ISAM, Database), CPU, 파일, 문서, 이미지, 멀티미디어 등등
- 서비스 : 고도의 CPU와 메모리를 통해서만 산출될 수 있는 계산 결과나 집중되고 통합된 데이터와 로직을 기반으로 한 비지니스 로직의 결과 등등

  • 엄청난 고가의 자원과 서비스가 집중된 중앙 서버에 집중되어 있던 메임프레임워크 시대를 지나 좀 더 비용을 절감하고 자원을 효과적으로 분산시키기 위해 C/S 시스템은 다양한 방식으로 발전되어왔다.
  • 어찌 보면, 메인프레임워크 시대 이후의 시스템에서 클라이언트, 서버라는 개념은 서로 상대적인 개념으로 변화되어 서버가 클라이언트의 역할을 그리고 그 반대의 역할을 수행하기도 한다.
  • 결과적으로 C/S 시스템은 자원을 공유하고 소통하기 위한 수단으로 소통을 위한 소통 쌍방간 또는 다자간에 약속된 규약을 정하고 그에 기반하여 통신하기 위한 다양한 통신 프로토콜(규약)을 정의하고 발전해나가는 과정이기도 하다.
  • C/S 시스템의 발전 과정은 좀 더 광범위하고 분산된 환경을 통합적으로 소통하고 공유하기 위해 좀 더 광범위하게 통일된 규약으로 모아져가는 경향이 있다.(HTTP, REST 등등)
참고 1

◎ 통신 프로토콜(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"라는 개념은 정확한 정의가 있다기 보다는 다소 모호하고 넓은 의미로 사용되고 있다.
참고 : 위키 - 리치 인터넷 애플리케이션

c/s 변천사

도표 설명
- 이 분류는 다소 도식적이고 인위적일 수 있으나 기술적 흐름을 이해하기 쉽게하기 위해 각 시기별로 지배적이고 중심적인 기술과 흐름에 따라 분류한 내용이다.
- 실제로 현재에 이르서도 메인프레임은 여전히 사용되고 있으며, 위의 모든 기술들은 시대 구분 상관없이 현재도 상존하고 있는 기술과 환경들이다.
- 현재는 메인프레임에서도 HTTP와 4GL 언어들을 사용하거나 Client/Server 모델 시스템에서도 HTTP를 통신 프로토콜로 사용하는 등 기술과 환경들이 상호 교체하며 사용되는 Crossover가 이뤄지고 있다.
- 국내에서는 RIA의 현재 흐름은 대부분 ActiveX를 이용한 방식을 취하고 있는데 이것은 RIA는 좀더 웹접근성이 보장된 방식을 통하지 않고는 결국 일부에서만 사용하는 폐쇄된 시스템이 될 것이면 결국 소멸될 가능성이 높다.
- RIA는 HTML5와 CSS3 등의 표준 웹 방식과 jquery 등의 범용적이고 표준에 가까운 라이브러리를 이용한 방식이 선호되고 있다. 그동안 대표적인 RIA로 언급되었던 Adobe사의 AIR도 ActiveX와 같이 플러그인이 설치되어야하는 기술이었으며 결국 Adobe사는 AIR에 대한 전망을 접기로 결정하고 개발과 지원을 하지 않기로 하였으며, HTML5에 더 많은 기술 연구에 집중하고 있다는 사실에서도 증명되고 있다.

참고 2

◎ Stateful / Stateless
  • 여기서 상태(State)란 과거의 동작(데이터 송수신 및 처리) 결과 내지 정보를 의미한다.
  • 비교
stateful / stateless
  • TCP/IP 통신은 전송계층(Transport layer)인 TCP 또는 UDP를 이용하여 응용 계층(Application layer) 구현을 자유롭게 할 수 있기 때문에 필요에 따라 Stateful / Stateless 모두 구현이 가능하다.
  • HTML5에서 지원하는 웹소켓은 양방향 통신이 가능한 Stateful 통신을 지원한다.
  • 한 때 클라이언트 / 서버 모델 환경에서 웹 환경으로 넘어가는 과도기에, Stateful 기반의 클라이언트 / 서버 통신 환경에 익숙한 설계자와 개발자들이 Stateless 기반의 웹 환경의 차이점을 이해하지 못해 혼란스러워 하기도 했다. 심지어 Stateless 웹 어플리케이션 설계를 Stateful 기반으로 설계하고 개발과장에서 뒤집어 지는 경우를 보기도 했다. 물론 지금도 간간이 Stateless 운영 원리를 무시한 설계와 개발을 하는 경우를 볼 수 있다.

2. Main Frame (메인프레임)


Mainframe과 터미널

  • 초창기 컴퓨팅 환경은 중앙 집중적인 메인프레임 컴퓨터를 근간으로 하는 시스템이었다.
  • 개인컴퓨터(PC) 개념이 없던 시대로 모든 애플리케이션은 메인 프레임 내에서 작동했다.
  • 모든 애플리케이션이 메인 프레임 내에서 작동했으므로 애플리케이션 간 통신은 파일이나 공유 메모리 혹은 데이터베이스를 통한 데이터 공유 정도로 충분했다. 그러므로 네트워크 통신에 대해 큰 비중이 없었다.
  • 하지만 메인프레임 시절에도 최소한의 네트워킹은 사용되었는데 메인프레임과 터미널(terminal) 간의 통신이었다. 메인프레임은 접근이 차단된 별도의 컴퓨터룸에 설치됐으며, 사용자들이 메인 프레임에 접근할 때는 터미널을 통해야만 했다.
  • 더미 터미널(dummy terminal)이 초창기에 사용됐고, 이 더미 터미널은 메인프레임과 텍스트 기반(현재 윈도우의 명령창 정도를 생각하면 되겠다)의 통신을 할 수 있었다.
  • 터미널과 메인프레임은 동축 케이블 등의 유선으로 연결되어 사용되었다. (point to point 방식)
  • 때로는 전화 모뎀(PPP) 등을 통해 통신을 했다. 더미 터미널은 80×25 수준의 텍스트 입·출력을 담당했으므로 메인 프레임과의 통신은 2400bps(bit per second) 정도의 대역폭을 가진 모뎀이면 충분했다. 아래 그림과 같이 터미널과 메인 프레임 사이에서 문자(character)를 주고 받는 통신 정도가 사용됐다.
  • 통신 프로토콜은 소수의 메임프레임을 제공하는 기업(IBM, DEC 등등)에서 각각 정의한 프로토콜이 사용되었다. TN3270과 같은 프로토콜은 IBM 메인프레임에서 사용한 대표적인 메인프레임 프로토콜이었다.

■ 잠깐 쉬어가기

'에일리언' 1편은 1979년에 만들어진 영화로 내용의 배경은 24세기 어떤 우주 공간이다. 영화에는 우주선 '노스트로모' 호의 메인 컴퓨터실에서 선원들이 메인컴퓨터를 이용하는 장면이 나온다. 그런데 메인컴퓨터 '마더'와 선원들의 인터페이스가 바로 대화형 프롬프트 방식의 더미 터미널이었다.(아래 사진 가운데) 소시적 기억으로는 화면에 밝은 전자 타이핑 소리를 내며 야광빛의 글자들이 모니터에 찍히는 장면은 근사하기 그지 없었다.
그런데 지금 되돌아보면 아래 사진과 같이 근사하고 화려한 메인컴퓨터실에 그것도 24세기에 사용하는 UI가 그저 터미널이었다니... 지금의 화려하고 다양한 UI 들과 시스템을 생각하면 웃음이 나온다. 영화는 당시 최고의 컴퓨터 시스템인 메인프레임과 터미널 기반의 환경에서 벗어나질 못하고 있다. 지금봐도 놀라운... 그로테스크하고 예술적인 영상미와 영화적 상상력을 보여주었지만 과학적 상상력 만큼은 그에 못미쳤던 모양이다. (그런 의미에서 아시모프나 클라크의 SF소설에서 담아내는 과학적 상상력은 정말 대단한 것이었다.)
여튼 그럼에도 불구하고 역시 에일리언 1편은 상영 당시 최고의 상상력과 재미를 부여했던 몇 손가락 안에 드는 SF영화의 수작임은 분명하다.

3. Client / Server 모델


● 클라이언트 / 서버 모델 발달 배경
  • 마이크로프로세서가 발달함에 따라 대형 메인 프레임에 준하는 워크스테이션 컴퓨터들과 개인용 컴퓨터 (PC) 가 등장하였다.
  • UNIX 등 다양한 컴파일러와 개발에 유현한 서버급 운영체제와, 윈도우 등의 화려한 GUI 기반의 운영체제가 일반화되었다.
  • 그러나 워크스테이션급 서버 등은 메인프레임워크의 강력한 기능을 동등하게 제공할 수 없었다. 하지만 기업에서 비용절감의 요구가 부각되면서 워크스테이션급 서버가 차츰 메인프레임워크를 대체하게 되었고 메인프레임워크에 몰려있던 기능을 여러 대의 워크레스테이션 서버로 분산시키는 방식을 사용하였다.
  • 대신 서버 컴퓨터들을 네트워크로 연결하고 서로 통신하는 것이 중요한 요소로 떠오르게 됐다. 이러한 환경의 요구와 네트워크 환경의 발달에서 OSI, TCP/IP 등의 네트워크 프로토콜 계층 구조가 정의되고 발전하였다.
  • 네트워크 통신의 발달로 서버 간 통신 뿐만 아니라 서버와 PC 간의 통신도 발전하여 클라이언트 / 서버 모델이 확산되었다.
  • 네트워크 / 서버 모델을 통해 서버의 일부 기능 (주로 업무 로직)을 클라이언트에 분산시켜 서버의 기능을 감소시키도록 했다.
  • 서버들 혹은 클라이언트와 서버 사이의 네트워크는 이 당시 널리 보급되기 시작한 TCP/IP 프로토콜이 사용됐다. 값 싼 이더넷(Ethernet)과 간편한 TCP/IP 프로토콜은 클라이언트·서버 환경에서 서버와 서버, 클라이언트와 서버를 손쉽게 연결할 수 있는 매개체가 됐다.

● 클라이언트 / 서버 모델 통신 원리


(1) 클라이언트/서버 모델의 구성과 통신 원리
  • 일반적으로 클라이언트/서버 모델의 아키텍처 구성요소는 사용자 인터페이스 (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개)의 프로토콜들로 구성되어 있다.
참고 3
◎ 주요 통신 프로토콜과 소켓
통신 프로토콜과 소켓



  • 하드웨어의 물리적 장치를 통해 특화된 네트워크 프로그램을 작성하기 위해서는 Application Layer(응용 계층)에서 소켓을 통해 Transport Layer(전송 계층)의 TCP 또는 UDP를 사용하여 개발해야 한다. 소켓은 '응용 계층'에서 TCP/IP를 사용할 수 있는 일종의 창구역할로서 API 라이브러리다.
  • '응용 계층'에 개발되는 네트워크 통신 프로그램은 통신 양방간 또는 다자간의 약속된 규약이 정의되고 구현된다. 즉, 이것도 일종의 프로토콜로서 FTP(파일 전송), telnet, SMTP(메일 전송), POP3(메일 수신)등이 대표적인 응용 계층 상의 프로토콜이다.
  • 네트워크/서버 모델 프로그램 역시 해당 응용프로그램을 사용하는 주체(기업, 기관 등의 특정 단체나 업체 등등)의 필요에 의한 통신 규약을 정의하고 사용한다.(USER Protocol : 참고 3의 붉은 글씨 참조)
  • 초창기 클라이언트/서버 환경에서 애플리케이션 사이의 통신은 네트워크 패킷(packet) 기반의 전문 방식이 주로 사용됐다. 전문 통신 방식이란 통신에 참여하는 애플리케이션들이 주고 받을 데이터의 포맷을 서로 약속(프로토콜)한 후 약속된 데이터 패킷을 전송하고 수신하는 것을 말한다.
  • 아래 그림의 예와 같이 통신을 위한 패킷을 정의하고 이 데이터 패킷을 애플리케이션이 주고 받게 된다. 클라이언트는 약속된 데이터 패킷의 포맷에 맞춰 패킷을 생성, 서버로 전송한다. 서버는 패킷을 읽어 들이고 패킷에 기록된 데이터를 해석해 필요한 서버 측 작업을 수행하고 그 결과를 데이터 패킷에 기록해 클라이언트로 반환하는 것이다.
데이터패킷 예

<데이터 전문 패킷 예>

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

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

(2) 미들웨어

  • 기존의 전문 방식의 클라이언트/서버 통신은 개발 생산성이 너무 낮았고 애플리케이션들이 복잡해짐에 따라 수 백 수 천 개의 데이터 패킷 정의를 요구했다. 또한 과거 메인 프레임에서 가능했었던 트랜잭션 처리와 같은 고급 데이터 처리 기법 역시 새로운 클라이언트/서버 환경에 요구됐다.
  • 따라서 클라이언트와 서버 사이에 데이터 패킷 생성 및 전달과 더불어 네트워크 상에 분산돼 있는 서버들을 찾아주는 네이밍(naming) 서비스, 트랜잭션 서비스 등을 제공하는 미들웨어(middleware)들이 등장하기 시작했다.
  • 이러한 미들웨어를 통해 개발자는 클라이언트와 서버 측에서 애플리케이션 비즈니스 로직에 관련된 핵심코드만을 작성하는 편리성을 제공하고 이를 통해 생산성을 높일 수 있도록 했다.
  • 미들웨어를 사용하면 더 이상 개발자가 Socket API를 직접 액세스할 필요가 없어지며 복잡한 TCP/IP 오류 처리 등을 고려하지 않아도 되었다.
(3) 미들웨어의 종류(통신 미들웨어)


○ 원격 프로시저 호출(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 등도 여기서 발전된 기술이다. (아래 그림의 스텁은 SOAP을 사용해본 개발자라면 낯익을 것이다.)


○ 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를 보완하는 기능으로 사용되고 있다.[t]
○ 트랜잭션 프로세싱 모니터(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로 구성되기도 한다.

4. Web 통신 원리


● 웹의 발달 배경
  • 점차 인터넷이 대중화됨에 따라 애플리케이션들은 기업 내부 뿐 아니라 기업 외부와도 통신할 필요가 제기됐다.
  • 그런데 이 시기에 애플리케이션 통신에 사용됐던 IIOP, DCOM, RMI는 서로 호환되지 않았다. IIOP는 CORBA 표준을 준수하는 애플리케이션들끼리만 사용이 가능했고, DCOM은 마이크로소프트의 운영체제들에서만 사용 가능했으며, RMI는 Java 플랫폼에서만 사용 가능했다.
  • 그리고 이들은 모두 바이너리 포맷의 데이터를 주고 받는 통신 인터페이스들이므로 그 내용이 복잡하고 이해하기 어려웠다. 또한 일부 기술들은 내부 작동 방식이 공개되지도 않았다. 따라서 Java 기반의 클라이언트가 COM 기반의 컴포넌트를 호출할 수 없었으며 그 반대도 마찬가지였다.
  • 즉, 서로 다른 기술을 사용해 개발된 애플리케이션(클라이언트 및 컴포넌트)은 서로 통신할 방법이 없었던 것이다.
  • 이런 이유에서 과거의 전문 방식의 통신을 추가적으로 개발해야 하는 고통이 따르기도 했다. 또 이들 통신 기술들은 인터넷을 고려하지 않은 통신 기법들이었기 때문에 방화벽을 통과하기 매우 어려웠다. 상호 운영성의 문제가 발생한 것이다.
  • HTTP는 인터넷의 표준으로 어떠한 플랫폼에서도 사용 가능한 프로토콜이므로 그 어떤 개인이나 기업도 HTTP를 인터넷 표준으로서 인정한다.
  • 상호 운영성이 뛰어난 HTTP 표준 프로토콜을 통해 C/S 모델의 여러가지를 대체 가능한 기술들이 발달되었다.

● 웹 HTTP 통신 원리


(1) 도메인 주소를 통한 IP Address 획득
  • 웹 통신의 클라이언트는 기본적으로 도메인(Domain) 주소를 통해 웹서버에 접근한다.
  • 사람들이 기억하기 쉽고 사용하기 편리하기 위해 인터넷에서는 도메인네임(Name)이라는 또 다른 주소를 제공한다.
  • 도메인 네임 서버(Domain Name Server - DNS Server)에서 도메인 네임을 관리한다.
  • 컴퓨터가 속한 기관이나 국가에 따라서 계층적으로 형성한다.
  • 일반적으로 “컴퓨터이름.기관이름.기관종류.국가이름” 형태로 사용한다. 미국의 경우는 마지막에 국가가 없이 .edu, .com, .net 등을 사용한다. (예: multi.hansung.ac.kr , xguru.net)
참고 4

- 인터넷상의 모든 도메인은 ".(dot)" 또는 루트(root)라 불리는 도메인 아래에 역트리(Inverted tree)구조로 계층적으로 구성되어 있다.
- 루트 도메인 바로 아래의 단계를 1단계 도메인 또는 최상위도메인(TLD, Top Level Doamin)이라고 부르며, 그 다음 단계를 2단계 도메인(SLD, Second Level Domailn)이라고 부른다.
- 도메인은 일반최상위도메인(gTLD: Generic Top Level Domain)과 국가최상위도메인(ccTLD: Country Code Top Level Domain)로 구분할 수 있으며 여기서 일반최상위도메인은 다시 스폰서도메인(Sponsored TLD)과 언스폰서도메인(Unsponsored TLD)으로 구분된다.

  • 웹 HTTP는 TCP/IP 프로토콜 기반이며, Application Layer(응용 계층)에 위치한 프로토콜이다.
  • 일반적으로 브라우저를 통해 통신을 하는데 다른 Application Layer(응용 계층)의 프로토콜과 마찬가지로 내부적으로 소켓 통신을 사용한다.
  • 그렇기 때문에 기본적으로 Internet Layer(인터넷 계층)의 IP에 접근할 수 있어야 한다. 그래서 웹은 DNS 서버를 통해 도메인 주소에서 IP 주소를 얻어온다. 그 과정은 아래와 같다.(하바드 대학의 예 - 참고 : HTTP and the Apache Web Server)
1) 사용자 클라이언트(브라우저)에서 사용자의 기본 DNS 서버로 요청2) 사용자의 기본 DNS 서버로부터 루트 서버에 요청
3) ".edu" 네임 스페이스(or .com, .gov, .net, .uk, .kr, etc.) 대해 루트 서버로 요청
4) 기본 "harvard.edu" DNS 서버에 요청
5) 기본 "dce.harvard.edu" DNS 서버에 요청
6) DNS서버로부터 해당 DNS에 해당되는 IP주소를 받음



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

  • HTTP에 대한 자세한 내용은 다음 챕터에서 다룬다. ( HTTP 프로토콜 )
[참고 사이트]
- 애플리케이션 통신 방법의 변천사
- TCP/IP Network Programming Design Patterns in C++

링크 목록
작성자: 시간:

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)