Practical guide to content delivery networks 1-6

728x90

2.2.4.2 Plug-Ins 플러그인은 브라우저의 확장 기능으로서 작동하는 컴퓨터 프로그램으로, 웹 페이지 내에서 멀티미디어 콘텐츠를 표시하는 등의 특정 기능을 추가합니다. Shockwave, RealPlayer, QuickTime과 같은 멀티미디어 관련 플러그인이 그 예입니다. 또한 NetZip과 Neptune과 같은 유틸리티 플러그인 프로그램도 있습니다. NetZip은 데이터 압축을 가능하게 하며, Neptune은 Netscape에서 ActiveX를 지원하여 Microsoft의 Internet Explorer와 유사하게 작동하도록 합니다.

원래 Microsoft는 Internet Explorer를 Netscape와 호환되도록 만들기 위해 많은 노력을 기울였습니다. JavaScript, HTML, 플러그인까지 Internet Explorer는 Netscape와 유사하게 작동했습니다. 사실 초기 버전의 Internet Explorer는 Netscape 플러그인 디렉토리도 읽을 수 있었습니다. 불행히도 Internet Explorer가 시장 점유율을 확대하면서 Netscape와의 호환성은 감소했습니다.

그림 2.7 Chrome 브라우저에서 제어되는 프로그램 보기 (Microsoft Explorer 대신)

그림 2.7은 Internet Explorer 브라우저에서 플러그인을 보는 방법을 보여줍니다. 이 예에서는 먼저 브라우저의 메뉴 바에서 도구를 선택한 다음 “프로그램”이라는 탭을 클릭합니다. 그런 다음 “추가 기능 관리” 버튼을 선택하면 “추가 기능 관리”라는 대화 상자가 표시됩니다. 추가 기능(add-ons)이라는 용어는 이제 Internet Explorer를 포함한 많은 브라우저에서 브라우저와 관련된 플러그인을 통해 제어할 수 있는 모든 프로그램을 지칭하는 데 사용됩니다. 실제로 그림 2.7을 주의 깊게 살펴보면 Sun Microsystems 항목 아래에 Java 플러그인이 입력된 것을 알 수 있습니다.

2.2.4.3 Java Java는 컴파일과 해석이 모두 가능한 특이한 고급 프로그래밍 언어입니다. Java 프로그램은 컴파일러를 사용하여 먼저 Java 바이트코드라고 하는 중간 언어로 번역됩니다. 이는 플랫폼에 독립적인 코드로, 이후 Java 플랫폼의 인터프리터에 의해 해석됩니다. 인터프리터는 코드를 작은 구성 요소로 나누어 각 Java 바이트코드 명령이 컴퓨터에서 실행되도록 합니다. Java 프로그램의 컴파일은 한 번만 발생하지만, 해석은 프로그램이 실행될 때마다 이루어집니다.

2.2.4.3.1 Java Bytecodes Java 바이트코드는 Java 가상 머신(Java VM)이라고 불리는 장치의 기계 코드 명령으로 볼 수 있습니다. 웹 브라우저에 포함된 모든 Java 인터프리터(애플릿을 실행할 수 있는 브라우저 포함)와 개발 도구는 Java VM의 구현으로 간주될 수 있습니다. 따라서 Java 바이트코드는 프로그래머가 어떤 Java VM에서도 작동할 수 있는 소프트웨어를 개발할 수 있게 하며, 플랫폼에 Java 인터프리터만 포함되어 있다면 플랫폼 독립성을 유지할 수 있습니다. Java VM에 대해 이해한 후 이제 Java가 제공하는 또 다른 기능에 대해 알아보겠습니다. 그 기능은 Java API입니다.

2.2.4.3.2 The Java API Java 응용 프로그래밍 인터페이스(Java API)는 호출될 때 미리 정의된 기능을 수행하는 미리 정의된 소프트웨어 구성 요소 모음입니다. Java API는 관련 클래스와 인터페이스의 라이브러리로 그룹화되며, 각 라이브러리는 패키지라고 합니다.

2.2.4.3.3 Java Programs 가장 일반적인 Java 프로그램 유형은 애플릿과 애플리케이션입니다. 두 가지 중에서 독자들이 더 익숙한 것은 아마도 Java 애플릿일 것입니다. Java 애플릿은 Java 지원 브라우저 내에서 실행되는 프로그램을 나타냅니다. 즉, 애플릿은 HTML 웹 페이지에 포함될 수 있는 Java로 작성된 프로그램을 의미합니다. Java 지원 브라우저를 사용하여 Java 애플릿이 포함된 페이지를 보면, 애플릿의 코드는 서버에서 클라이언트로 전송되어 브라우저의 Java 가상 머신에 의해 실행됩니다. 이에 비해 애플리케이션은 Java 지원 컴퓨터 플랫폼에서 직접 실행되는 독립 실행형 프로그램을 나타냅니다.

Java 애플리케이션에는 짧게 논의할 만한 다양한 종류가 있습니다. 첫째, 서버라고 불리는 특별한 유형의 Java 애플리케이션은 네트워크의 클라이언트를 지원합니다. Java 서버의 예로는 웹 서버, 프린트 서버, 프록시 서버 및 Java 애플리케이션을 전송하는 기타 유형의 서버가 있습니다. 또 다른 유형의 Java 프로그램은 서블릿(servlet)으로, 서버에서 실행되는 애플릿으로 볼 수 있습니다. 서블릿은 CGI 스크립트를 대신하여 대화형 웹 애플리케이션을 구축하는 데 일반적으로 사용됩니다.

언급할 가치가 있는 또 다른 유형의 Java 프로그램은 자바스크립트(JavaScript)입니다. 자바스크립트는 크로스 플랫폼 객체 기반 스크립팅 언어입니다. 자바스크립트는 웹 브라우저를 포함한 다른 제품 및 애플리케이션에 임베드하기 위해 설계된 작고 간결한 언어입니다. 브라우저 내부에서 자바스크립트는 환경의 객체들과 연결될 수 있으며, 결과적으로 그 환경에 대한 프로그램 제어를 제공합니다.

자바스크립트는 배열(Array), 날짜(Date), 수학(Math)와 같은 핵심 객체 집합뿐만 아니라 언어 요소라고 불리는 핵심 연산자, 제어 구조, 명령문 집합을 포함합니다. 이러한 핵심 자바스크립트는 클라이언트 측 및 서버 측 작업을 위해 확장될 수 있습니다. 클라이언트 측에서는 핵심 자바스크립트가 브라우저 제어를 어느 정도 제공하는 객체를 제공하여 사용자가 폼에 요소를 넣거나 웹 페이지를 탐색할 수 있도록 확장됩니다. 반면 서버 측 자바스크립트는 서버에서 자바스크립트를 실행하는 데 필요한 요소를 제공함으로써 핵심 스크립팅 언어를 확장합니다. 서버 측 자바스크립트 확장의 한 예는 백엔드 데이터베이스와 통신하는 애플리케이션이 될 수 있습니다.

JavaScript 프로그램을 웹 페이지에 통합하는 것은 HTML <SCRIPT> 태그를 사용하여 이루어집니다. 다음 HTML 코드는 JavaScript 프로그램을 HTML 웹 페이지에 통합하는 예를 보여줍니다:

<HTML>
  <HEAD>
    <TITLE>JavaScript Example</TITLE>
    <SCRIPT LANGUAGE="JavaScript">
      MsgBox "Welcome to popcorn.com."
    </SCRIPT>
  </HEAD>
</HTML>

2.2.4.4 VBScript Microsoft의 Visual Basic Scripting(VBScript)은 Java 애플릿보다 더 강력하고 잠재적으로 더 위험한 HTML 확장 기능으로 볼 수 있습니다. VBScript는 Windows Script를 사용하여 호스트 애플리케이션과 통신합니다. Windows Script를 사용할 때, Microsoft의 Internet Explorer 및 기타 호스트 애플리케이션은 각 스크립팅 구성 요소에 대해 별도의 코딩이 필요하지 않으며, 컴퓨터가 스크립트를 컴파일하고, 진입점을 얻고 호출하며, 심지어 스크립팅을 위한 표준 언어 런타임을 생성할 수 있게 합니다. 클라이언트-서버 환경에서 VBScript를 지원하는 브라우저는 웹 페이지에 포함된 스크립트를 받아들이며, 브라우저는 해당 스크립트를 해석하고 처리합니다.

JavaScript를 웹 페이지에 포함시키는 것과 마찬가지로, VBScript의 통합도 HTML <SCRIPT> 태그를 사용하여 이루어집니다. 다음 HTML 코드는 VBScript를 HTML 웹 페이지에 통합하는 예를 보여줍니다:

<HTML>
  <HEAD>
    <TITLE>VBScript Example</TITLE>
    <SCRIPT LANGUAGE="VBScript">
      MsgBox "Welcome to popcorn.com."
    </SCRIPT>
  </HEAD>
</HTML>

SCRIPT LANGUAGE 태그를 사용하여 웹 브라우저는 해당 코드를 어떻게 해석할지 알게 됩니다. Netscape 브라우저와 Microsoft Internet Explorer의 일부 버전은 JavaScript를 지원하지만, VBScript는 후자의 브라우저만 지원합니다.

브라우저가 웹 페이지에 포함된 특정 스크립팅 언어를 지원하지 않으면, 일반적으로 스크립트를 웹 페이지의 일부로 표시하거나 스크립트를 보이지 않게 숨깁니다. 후자의 경우는 스크립트가 주석 태그()로 감싸져 있을 때 발생하며, 브라우저에서 해당 스크립트는 무시됩니다. 예를 들어, 이전 스크립트 예제로 돌아가서 스크립트를 다음과 같이 감싸면, VBScript를 지원하지 않는 브라우저에서 무시됩니다:

<HTML>
  <HEAD>
    <TITLE>VBScript Example</TITLE>
    <SCRIPT LANGUAGE="VBScript">
      <!--
      MsgBox "Welcome to popcorn.com!"
      -->
    </SCRIPT>
  </HEAD>
</HTML>

2.2.4.5 ActiveX ActiveX는 애플리케이션이 정보를 공유하는 방법을 정의하는 일련의 규칙을 나타냅니다. Microsoft에서 개발한 ActiveX는 Object Linking and Embedding(OLE)과 Component Object Model(COM)이라는 두 가지 Microsoft 기술에 뿌리를 두고 있습니다.

프로그래머는 C, C++, Java, Visual Basic 등 다양한 프로그래밍 언어로 ActiveX 컨트롤을 개발할 수 있습니다. ActiveX 컨트롤은 Java 애플릿과 유사한 것으로 볼 수 있습니다. 그러나 디스크 작업을 수행할 수 없는 Java 애플릿과 달리, ActiveX 컨트롤은 Windows 운영 체제에 완전한 접근 권한을 가집니다. 이러한 기능 덕분에 ActiveX 컨트롤은 Java 애플릿보다 더 강력하지만, 그만큼 보안 위험도 따릅니다. 이러한 위험을 통제하기 위해, Microsoft는 브라우저가 ActiveX 컨트롤을 다운로드하기 전에 이를 식별하고 인증할 수 있는 등록 시스템을 개발했습니다.

2.3 Server Operations

클라이언트-서버 모델이 그림 2.1에 나타난 것처럼, 서버 계층은 하나 이상의 컴퓨터로 구성될 수 있습니다. 클라이언트-서버 모델에서 항상 웹 서버가 존재할 것으로 예상되지만, 웹 서버가 애플리케이션 서버와 통신할 가능성도 있습니다. 애플리케이션 서버는 다시 애플리케이션 서버 자체에 존재하거나 백엔드 데이터베이스 또는 독립 디스크의 중복 배열(RAID)과 같은 별도의 장치에 위치한 데이터베이스와 통신할 수 있습니다. 이 섹션에서는 웹 서버 작동 방식과 애플리케이션 서버 및 데이터베이스와의 연결 방식을 간략하게 살펴보겠습니다.

2.3.1 Evolution

현대의 웹 서버는 미국 국립 초고속 컴퓨팅 응용 센터(NCSA)에서 개발된 웹 서버의 후손으로 볼 수 있습니다. 이곳에서 Netscape로 발전한 브라우저인 Mosaic이 개발되었으며, 유럽 입자 물리 연구소(CERN)에서도 웹 서버가 개발되었습니다. 1990년대 후반 NCSA와 CERN에서 클라이언트 브라우저 및 웹 서버 소프트웨어 작업이 진행됨에 따라, 인터넷 상의 상업적 애플리케이션이 급속히 확장되었고, 이에 따라 소프트웨어 개발자들은 이 급성장하는 시장을 위해 제품을 제공하기 시작했습니다.

오늘날 선택할 수 있는 웹 서버 프로그램의 수는 제한적이지만, 각각의 운영 방식은 유사합니다. 즉, 웹 클라이언트와 서버 간의 모든 통신은 HTTP를 사용하며, 웹 서버는 운영 체제에 특정 포트를 통해 통신을 수락할 준비가 되었음을 알리면서 작동을 시작합니다. HTTP의 경우 80번 포트가 사용되며, 이는 TCP를 통해 전송되고, 보안 HTTP(HTTPS)를 사용하는 경우에는 443번 포트가 사용됩니다.

Program	Operating Environment
Internet Information Server	Microsoft에서 Windows 2000/2003 Server에 번들로 제공하는 제품
Apache	오픈 소스 무료 HTTP 서버로 UNIX, Linux 및 Windows에서 작동
SunONE (Java System으로 이름 변경)	원래 Netscape와 Sun Microsystems가 공동 개발한 제품으로, Windows 및 UNIX에서 작동
WebSTAR	4D, Inc.에서 제공하는 서버 제품군으로, Macintosh 플랫폼에서 작동
Red Hat Content Accelerator	Linux 환경에서 정적 웹 페이지만 지원하는 커널 기반 웹 서버

표 2.8 일반적인 웹 서버 애플리케이션 프로그램

2.3.2 Common Web Server Programs 여러 운영 체제에서 작동하는 다양한 웹 서버 애플리케이션 프로그램이 있습니다. 일부 웹 서버 프로그램은 Intel Pentium 및 AMD 플랫폼에서 여러 버전의 Windows에서 작동하도록 설계된 일반 서버 소프트웨어에 번들로 제공됩니다. 다른 웹 서버 프로그램은 UNIX 및 Linux 운영 체제에서 작동합니다. 표 2.8은 인기 있는 웹 서버 프로그램과 해당 프로그램의 운영 환경에 대한 간단한 설명을 나열합니다.

2.3.2.1 Server Characteristics 일반적으로 웹 서버는 두 가지 별도의 디렉터리 구조를 가진다고 볼 수 있습니다. 하나는 운영 체제에 의해 생성되는 디렉터리 구조로, 디스크 드라이브의 시작 부분에서 시작되며 루트 디렉터리를 나타냅니다. 두 번째 디렉터리는 디스크 드라이브의 웹 문서가 일반적으로 저장되는 위치에서 시작됩니다. 이 웹 디렉터리도 루트를 가지며, 이를 문서 루트 또는 홈 디렉터리의 로컬 경로라고 부릅니다.

그림 2.8의 왼쪽 부분은 Microsoft Internet Information Server의 기본 웹 사이트 속성 대화 상자를 보여주며, 홈 디렉터리 탭이 선택된 상태입니다. 로컬 경로가 C:\inetpub\wwwroot로 표시되며, 이는 클라이언트 쿼리에 응답하여 서버 콘텐츠가 제공되는 기본 홈 디렉터리를 나타냅니다. “찾아보기” 버튼을 클릭하면, 그림 2.8의 오른쪽에 표시된 폴더 찾기 창이 열립니다.

이제 컴퓨터 URL 또는 사이트 이름이 www.popcorn.com 이고 wwwroot 디렉터리에 “welcome”이라는 문서를 저장했다고 가정해 보겠습니다. 그러면 C:\inetpub\wwwroot\welcome은 welcome 문서의 디렉터리 주소를 나타냅니다. 따라서 http://www.popcorn.com 이라는 URL 요청은 경로 C:\inetpub\wwwroot\welcome.html에서 Welcome 웹 페이지를 반환하게 됩니다. 위의 설명을 통해, 웹 서버가 URL 요청을 컴퓨터의 웹 홈 페이지 또는 문서 루트의 디렉터리 구조로 매핑하는 방식을 알 수 있습니다.

그림 2.8 루트 또는 홈 디렉터리는 디스크 루트와 관련하여 지정됩니다.

로컬 경로 또는 문서 루트를 지정할 수 있을 뿐만 아니라, 서버 운영자는 웹 서버를 구성하여 다른 컴퓨터의 공유 폴더에서 콘텐츠를 생성하거나 URL로 리디렉션을 설정할 수 있습니다. 후자의 경우, 한 디렉터리에서 다른 위치(같은 컴퓨터이거나 수천 마일 떨어진 다른 컴퓨터)에 있는 곳으로 요청을 리디렉션할 수 있습니다.

현대의 웹 서버는 언급할 만한 몇 가지 특성을 가지고 있습니다. 그 중 하나는 동일한 컴퓨터에서 여러 사이트를 지원할 수 있는 기능이며, 다른 하나는 다른 서버의 문서 루트 또는 인터넷 디렉터리에서 문서를 제공하는 기능입니다. 첫 번째 특성은 가상 호스팅(virtual hosting)이라고 불리며, 다른 서버에서 문서를 제공하는 기능은 웹 서버를 프록시 서버(proxy server)로 만듭니다. 웹 페이지 지원 외에도, 현대의 웹 서버는 FTP, Gopher 전송 및 데이터베이스 액세스를 지원합니다. 웹 서버는 또한 CGI 스크립트와 서블릿(servlets)을 실행하는데, 서블릿은 컴파일된 Java 클래스입니다. CGI 스크립트와 서블릿은 클라이언트-서버 작업을 크게 향상시킬 수 있으므로, 이 둘에 주목해 보겠습니다.

2.3.2.1.1 CGI Scripts Common Gateway Interface(CGI)는 외부 애플리케이션과 서버 간의 인터페이스를 표준화한 것입니다. CGI의 필요성을 이해하려면, 기본 HTML로 작성된 문서는 정적이어서 변경되지 않는다는 점을 인식해야 합니다. 예를 들어, 주문을 하거나 주식 가격이나 특정 지역의 날씨와 같은 항목을 요청할 때는 동적 정보를 출력할 도구가 필요합니다. CGI 프로그램은 실시간으로 실행되어 동적 정보를 출력할 수 있는 도구를 제공합니다.

Common Gateway Interface라는 용어는 웹의 초기 개발 시기로 거슬러 올라가며, 당시 기업들은 다양한 데이터베이스를 웹 서버에 연결하려고 했습니다. 이 연결 과정에서는 웹 서버에서 실행되어 데이터베이스 프로그램으로 관련 정보를 전송하고, 데이터베이스 쿼리 결과를 수신하여 클라이언트에 반환하는 프로그램이 필요했습니다. 서버와 데이터베이스 간의 연결 과정이 게이트웨이처럼 작동했기 때문에, 이 표준을 Common Gateway Interface라고 부르게 되었습니다.

CGI 프로그램은 특정 컴퓨터에서 실행될 수 있는 모든 언어로 작성될 수 있습니다. 따라서 C, C++, Fortran, PERL, Visual Basic 등은 CGI 프로그램에서 사용할 수 있는 언어입니다. UNIX 환경에서는 CGI 프로그램이 /cgi-bin 디렉터리에 저장됩니다. Microsoft Internet Information Server 환경에서는 CGI 프로그램이 C:\inetpub\wwwroot\scripts에 위치합니다. 이 위치는 PERL과 같은 스크립팅 언어로 개발된 CGI 프로그램을 저장하는 곳입니다.

CGI 스크립트의 가장 일반적인 용도 중 하나는 폼 제출입니다. 서버에서 실행되는 CGI 스크립트가 클라이언트에서 전송된 폼의 항목을 처리합니다. CGI 스크립트는 HTML 내에서 URL을 직접 지정하거나 자바스크립트와 같은 다른 스크립팅 언어 내에서 호출할 수 있습니다.

2.3.2.1.2 Servlets 서블릿은 컴파일된 Java 클래스를 나타냅니다. CGI와 유사하게, 서블릿은 서버에서 실행되며 HTML을 통해 호출됩니다. 웹 서버가 서블릿 요청을 받으면, 해당 요청은 서블릿 컨테이너로 전달됩니다. 컨테이너는 서블릿을 로드한 후, 서블릿이 완료되면 컨테이너가 다시 초기화되어 서버로 제어가 반환됩니다.

CGI와 유사하지만, 서블릿은 서버 프로세스로 실행되며 Java API에 직접 접근할 수 있기 때문에 더 빠를 수 있습니다. 서블릿은 Java로 작성되기 때문에 플랫폼에 독립적입니다.

서블릿에 대한 논의를 마치기 전에, 서블릿과 관련된 Java Server Pages(JSP)에 대해 간단히 언급하겠습니다. JSP는 서블릿과 유사하게 HTML 문서에 동적 콘텐츠와 처리를 제공합니다. JSP는 보통 서버 측 스크립팅 언어로 사용되며, JSP 컨테이너에 의해 서블릿으로 변환됩니다. 애플리케이션 서버로 넘어가기 전에, Microsoft 서버 표준인 ISAPI에 대해 몇 가지 설명을 덧붙이겠습니다.

2.3.2.1.3 ISAPI Internet Server API(ISAPI)는 Microsoft 서버에 특화된 표준으로, DLL을 서버의 주소 공간에 로드하여 스크립트를 해석합니다. CGI와 유사하지만, ISAPI는 서버가 CGI 스크립트처럼 새 실행 파일을 생성할 필요가 없기 때문에 더 빠릅니다. 대신 DLL이 로드되어 스크립트를 해석하는 역할을 합니다.

2.3.3 Application Servers

그림 2.1로 다시 돌아가면, 애플리케이션 서버가 기존의 웹 서버와 함께 2계층 장치를 나타낸다는 것을 알 수 있습니다. 실제로 웹 서버와 애플리케이션 서버는 동일한 컴퓨터에 존재할 수도 있고 별도의 컴퓨터에 있을 수도 있습니다. 애플리케이션 서버는 일반적으로 앱서버(appserver)라고도 하며, 클라이언트와 조직의 백엔드 데이터베이스 간의 애플리케이션 작업을 처리하는 프로그램에서 특정 소프트웨어 애플리케이션을 실행하는 컴퓨터에 이르기까지 그 범위가 다양합니다. 이 섹션에서는 여러 애플리케이션 서버 모델과 애플리케이션 서버와 3계층 데이터베이스 사이에 사용할 수 있는 다양한 인기 소프트웨어 제품에 대해 집중적으로 살펴보겠습니다.

2.3.3.1 Access 많은 클라이언트에게 애플리케이션 서버에 대한 접근은 투명하게 이루어집니다. 클라이언트는 브라우저를 사용하여 웹 서버에 접속합니다. 웹 서버는 코딩에 따라 요청을 애플리케이션 서버로 전달하는 여러 방법을 제공할 수 있습니다. 이러한 방법 중 일부로는 CGI, Microsoft의 Active Server Pages(ASP), 그리고 Java Server Pages(JSP)를 사용하는 것이 포함됩니다.

Active Server Page(ASP)는 사용자에게 전송되기 전에 웹 서버에서 처리되는 하나 이상의 스크립트를 포함하는 HTML 페이지입니다. ASP 파일은 HTML 파일에 VBScript 또는 JavaScript 문장을 포함하거나 ActiveX Data Objects 프로그램 문장을 파일에 사용하는 방식으로 생성됩니다. 이에 비해, Java Server Page는 웹 페이지에서 서블릿을 사용하여 서버에서 Java 프로그램의 실행을 제어합니다.

2.3.3.2 Java Application Servers Java 애플리케이션 서버는 Java 2 플랫폼, 엔터프라이즈 에디션(J2EE)을 기반으로 합니다. J2EE는 일반적으로 클라이언트 계층, 중간 계층, 그리고 엔터프라이즈 정보 시스템(EIS) 계층을 포함하는 다계층 모델을 사용하며, EIS 계층에는 애플리케이션, 파일 및 데이터베이스가 저장됩니다. 중간 계층에는 웹 서버와 EJB(Enterprise Java Bean) 서버가 포함될 수 있습니다.

J2EE를 사용할 때는 데이터베이스에 접근할 수 있어야 합니다. J2EE를 사용할 때는 JDBC(Java Database Connectivity), API(Application Program Interfaces), SQLJ(구조화된 질의 언어 - Java), 또는 JDO(Java Data Objects)를 사용하여 데이터베이스에 접근할 수 있습니다. JDBC는 Java 프로그래밍 언어와 다양한 데이터베이스 간의 데이터베이스 독립적인 연결성을 제공하는 산업 표준 API를 나타냅니다. SQLJ는 Java와 함께 SQL을 사용하는 사양을 나타내며, JDO는 평범한 Java 객체(Plain Old Java Objects, POJOs)를 엔터프라이즈 아키텍처의 어느 계층에서든지 지속되게 만드는 표준 Java 모델을 나타냅니다. 그림 2.9는 J2EE 플랫폼이 사용될 때 세 계층이 서로 어떻게 관련되어 있는지 보여줍니다. 그림 2.9를 살펴보면, EJB(Enterprise Java Beans)가 Java 2 플랫폼을 위한 서버 측 컴포넌트 아키텍처를 나타냄을 알 수 있습니다. EJB는 Java 기반의 분산형, 보안성, 이식성이 뛰어난 애플리케이션 개발을 가능하게 합니다.

EJB에는 두 가지 유형이 있습니다: 엔터티 빈(Entity Beans)과 세션 빈(Session Beans)입니다. 엔터티 빈은 특수한 속성을 가진 객체를 나타내며, 세션 빈과 같은 일반 객체는 프로그램이 종료되면 사라지지만, 엔터티 빈은 명시적으로 삭제될 때까지 유지됩니다. 따라서 네트워크의 어떤 프로그램이든 이를 찾을 수 있다면 엔터티 빈을 사용할 수 있습니다.

영구 저장소에서 데이터를 쉽게 찾을 수 있기 때문에 엔터티 빈(entity beans)은 일반적으로 데이터베이스 내에 저장됩니다. 이를 통해 엔터티 빈은 서버에서 실행될 수 있습니다. 프로그램이 엔터티 빈을 호출하면 제어가 서버로 넘어가며, 프로그램 스레드는 실행을 멈춥니다. 작업이 완료되면 제어가 호출한 프로그램으로 돌아가고, 프로그램은 실행을 재개합니다.

2.3.3.3 General Server Tools 애플리케이션 서버에 대한 논의를 마치며, ColdFusion과 ODBC라는 두 가지 일반 서버 도구와 Microsoft의 .NET Framework라는 특화된 도구 모음을 간단히 살펴보겠습니다.

ColdFusion은 원래 Macromedia에서 개발되었고 현재는 Adobe Systems에서 판매하는 인기 있는 개발 도구입니다. ColdFusion의 초기 사용 목적은 데이터베이스를 HTML 웹 페이지에 통합하는 것이었습니다. ColdFusion 웹 페이지는 ColdFusion Markup Language(CFML)로 작성된 태그를 포함하며, 이를 통해 C++와 같은 복잡한 언어를 사용할 필요 없이 데이터베이스와 통합이 가능합니다. 예를 들어, ColdFusion을 사용하여 사용자에게 성별과 나이를 묻는 웹 페이지를 만들 수 있으며, 이러한 정보는 웹 서버가 데이터베이스를 쿼리하여 사용자의 브라우저에 표시할 보험료를 HTML 코드로 제공하는 데 사용됩니다.

두 번째 도구인 ODBC (Open Database Connectivity) 는 SQL Access Group에서 개발한 표준 데이터베이스 접근 방식입니다. 애플리케이션과 DBMS 사이에 데이터베이스 드라이버라는 중간 계층을 삽입하여, 데이터를 처리하는 DBMS에 관계없이 모든 애플리케이션에서 데이터를 접근할 수 있게 합니다. 데이터베이스 드라이버는 애플리케이션의 데이터 쿼리를 DBMS가 이해할 수 있는 명령어로 변환하며, 이를 위해 애플리케이션과 DBMS는 ODBC를 준수해야 합니다.

클라이언트-서버 작업에서 사용되는 도구에 대한 논의를 마치기 전에, Microsoft의 .NET Framework라는 특화된 도구 모음에 대해 알아보겠습니다.

2.3.3.4 Microsoft's .NET Framework Microsoft의 .NET Framework는 자사의 .NET 플랫폼을 위한 소프트웨어 인프라를 나타내며, 웹 서비스와 애플리케이션을 개발하고 운영할 수 있는 공통 환경을 제공합니다. .NET은 서버 중심 컴퓨팅 모델을 사용하는 인터넷 및 웹 전략으로도 간주될 수 있습니다.

.NET은 애플리케이션 간 통신을 위한 HTTP, 인터넷 애플리케이션 간 데이터 교환을 위한 표준 형식인 XML(eXtensible Markup Language), 웹 서비스를 요청하기 위한 표준인 SOAP(Simple Object Access Protocol), 웹 서비스를 검색하고 발견하기 위한 표준인 UDDI(Universal Description, Discovery, and Integration) 등의 일련의 인터넷 표준을 기반으로 구축되었습니다.

NET Framework는 Microsoft의 Windows 운영 체제에서 설치할 수 있으며, 웹 서비스를 통한 소프트웨어 제공 메커니즘으로 작동합니다. .NET은 일반적인 프로그래밍 문제에 대한 많은 코드화된 솔루션을 포함한 대형 라이브러리와, 프레임워크를 위해 특별히 작성된 프로그램 실행을 관리하는 가상 머신 역할을 하는 소프트웨어 모듈을 포함합니다. .NET Framework에는 ADO.NET(프로그래머가 Java Persistence API와 유사하게 데이터 및 데이터 서비스를 액세스하는 데 사용할 수 있는 소프트웨어 컴포넌트 집합) 및 ASP.NET(HTTP, HTML, XML 및 SOAP를 통해 웹 서비스가 애플리케이션, 서비스 및 장치에 연결할 수 있도록 하는 기능)을 비롯한 공통 클래스 라이브러리가 포함됩니다. 클래스 라이브러리를 통해 프로그래머는 광범위한 기능을 갖춘 애플리케이션을 개발할 수 있으며, 이를 자신의 코드와 결합하여 맞춤형 애플리케이션을 제작할 수도 있습니다.

.NET Framework의 핵심 기능 중 하나는 Common Language Runtime(CLR) 입니다. CLR은 .NET Framework의 가상 머신 구성 요소로, 메모리 관리, 보안, 예외 처리를 포함한 특정 매개변수 내에서 프로그램 작업이 수행되도록 보장하며, 모든 .NET 프로그램은 CLR의 감독 하에 실행됩니다.

.NET Framework는 언어에 구애받지 않으며, 이론적으로 플랫폼 독립적입니다. 현재 C++, C#, Visual Basic, Microsoft의 JavaScript 버전인 JScript, COBOL 및 많은 타사 언어를 지원합니다.

.NET Framework 3.0 버전은 Windows Server 2008과 Windows Vista에 포함되어 있으며, 3.5 버전은 2009년에 Windows 7에서 출시되었습니다. .NET Framework 제품군에는 모바일 또는 임베디드 장치용 버전도 포함됩니다. .NET Compact Framework라는 이름의 버전은 Windows CE 플랫폼에서 사용할 수 있으며, 스마트폰과 같은 Windows Mobile 장치에서도 사용할 수 있습니다. 2000년 발표 이후, .NET은 다양한 Microsoft 제품에 통합되었습니다. 이러한 제품에는 Visual Studio .NET, Visual Basic .NET 및 다양한 Windows 버전이 포함되며, 인터넷 서비스를 개발하고 운영하는 데 필요한 빌딩 블록을 제공합니다.

이제 클라이언트-서버 작업에서 사용되는 도구에 대해 이해했으니, 클라이언트와 서버 계층 간의 거리가 증가함에 따라 아키텍처의 효율성에 대해 살펴보며 이 장을 마무리하겠습니다.

2.4 Distance Relationship

3계층 클라이언트-서버 모델에서 첫 번째와 두 번째 계층은 일반적으로 서로 분리되어 있으며, 세 번째 계층은 보통 두 번째 계층과 함께 위치합니다. 따라서 계층 간의 거리 관계를 분석할 때, 3계층 모델을 2계층 모델로 간주할 수 있습니다. 즉, 클라이언트와 서버 간의 거리가 증가함에 따라 클라이언트-서버 아키텍처에 미치는 영향을 분석할 수 있습니다. 이 과정에서 두 가지 인기 있는 TCP/IP 도구를 사용할 수 있습니다. 그 도구들은 현대 운영 체제에 포함된 Ping 및 Traceroute 프로그램입니다.

2.4.1 Using Ping

그림 2.10 Ping을 사용하여 Yahoo.com까지의 왕복 지연 시간 측정

Ping 유틸리티 프로그램은 기본적으로 정의된 목적지로 4개의 데이터 패킷을 전송합니다. 이 목적지는 호스트 주소나 점선 10진수 주소로 지정할 수 있습니다. 패킷을 수신한 대상은 원래 보낸 곳으로 패킷을 반사합니다. 패킷을 전송한 사람은 각 패킷을 언제 전송했는지 알고 있으므로 왕복 지연 시간을 계산할 수 있습니다. Ping은 인터넷 제어 메시지 프로토콜(ICMP)을 사용하여 작동합니다. ICMP 유형 8(에코) 메시지가 지정된 목적지로 전송되며, 해당 목적지는 ICMP 유형 0(에코 응답) 메시지로 응답합니다.

클라이언트-서버 작업에 미치는 거리의 영향을 설명하기 위해, 이 글의 저자가 조지아주 메이컨에 있는 자신의 컴퓨터와 미국에 위치한 서버 하나, 그리고 이스라엘에 위치한 서버 하나 간의 왕복 지연 시간을 살펴보겠습니다. 그림 2.10은 Yahoo 서버에 대한 핑을 보여줍니다. 참조된 그림의 항목을 살펴보면, IP 주소 216.109.112.135에서 4개의 응답이 나열되어 있으며, 이는 Yahoo 서버의 IP 주소를 나타냅니다. 왕복 지연 시간은 “time =“로 표시되며, 각각 20, 20, 11, 20 밀리초로 나와 있습니다. 마지막 응답 라인 아래에는 목적지에 대한 핑의 통계 요약이 생성됩니다. Yahoo에 대한 핑 예시에서, 평균 왕복 지연 시간이 17 밀리초로 표시되었습니다.

두 번째 예로, 저자는 이스라엘에 위치한 데이터 통신 세미나 기관인 logtel.com 서버에 핑을 시도했습니다. 그림 2.11은 해당 위치에 대한 핑 결과를 보여줍니다. 예상할 수 있듯이, 클라이언트와 서버 간의 거리 증가로 인해 왕복 지연 시간이 상당히 늘어났습니다. 그러나 분명하지 않을 수 있는 점은 지연 시간이 약 10배 정도 증가했다는 것입니다. 즉, Yahoo에 대한 핑의 평균이 17밀리초인 반면, Logtel 서버에 대한 핑은 평균 171밀리초로 증가한 이유입니다.

그림 2.11 Ping을 사용하여 서울에 위치한 서버까지의 왕복 지연 시간 측정

2.4.2 Using Traceroute

Traceroute는 이름 그대로 출발지에서 목적지까지의 경로를 추적하는 프로그램입니다. Microsoft Windows에서는 프로그램 이름이 Tracert로 축약되었습니다. (Mac Traceroute)

Tracert는 IP 헤더의 TTL(Time-to-Live) 필드를 변화시키는 일련의 ICMP Echo 메시지를 호출합니다. 첫 번째 IP 데이터그램은 TTL 필드 값이 1로 설정되어 전송됩니다. 따라서 데이터그램이 목적지로 가는 경로상의 첫 번째 라우터에 도착하면, 라우터는 TTL 필드 값을 1 감소시켜 결과적으로 0이 되면 데이터그램이 폐기되고 ICMP 메시지 유형 11(시간 초과)이 원래 보낸 곳으로 반환됩니다. 이 ICMP 메시지에는 라우터의 IP 주소와 라우터에 대한 추가 정보가 포함될 수 있습니다. 원래 보낸 사람은 TTL 값을 1 증가시켜 Ping을 재전송하고, 데이터그램이 경로상의 첫 번째 라우터를 통과할 수 있게 합니다. 두 번째 라우터는 다시 ICMP 유형 11 메시지를 반환하고, 이 과정은 Tracert 프로그램의 Ping이 목적지에 도달하거나 프로그램에서 사용되는 기본 홉(hop) 수에 도달할 때까지 계속됩니다.

그림 2.12, 2.13 Tracert를 사용하여 작성자의 컴퓨터에서 Yahoo 서버까지의 경로 추적

그림 2.12는 조지아주 메이컨에 있는 작성자의 컴퓨터에서 Yahoo 서버까지의 경로를 추적하기 위해 Microsoft Tracert 프로그램을 사용하는 예시를 보여줍니다. 이에 비해, 그림 2.13은 Tracert 프로그램을 사용하여 이스라엘에 위치한 Logtel 서버까지의 경로를 추적하는 예시를 보여줍니다.

Tracert의 두 가지 사용을 비교해보면, Yahoo.com까지는 8번의 라우터 홉이, Logtel 서버까지는 17번의 홉이 있다는 것을 알 수 있습니다. 각 라우터 홉은 처리 시간이 필요하므로, 출발지에서 목적지까지 거치는 라우터 홉의 수에 따라 지연 시간의 일부가 발생한다고 할 수 있습니다. 그러나 라디오 해설자 폴 하비(Paul Harvey)가 자주 말하듯, “그게 이야기의 전부는 아닙니다.” Figure 2.13에 나와 있는 Logtel.com에 대한 Tracert를 주의 깊게 살펴보면, 처음 10번의 홉 동안 지연 시간이 20밀리초 미만이었다는 것을 알 수 있습니다. 11번째 홉에 이르러서야 지연 시간이 눈에 띄게 증가했으며, 3번의 추적 중 어느 것이냐에 따라 20밀리초에서 90밀리초 또는 100밀리초로 증가했습니다. 10번째 홉에서는 라우터 설명에 따르면 뉴욕시에 위치해 있었고, 11번째 홉에서는 트래픽을 이스라엘로 전달하는 게이트웨이로 보입니다. 12번째 홉에서는 라우터 설명이 이스라엘에 있다고 나타냅니다. 따라서 약 7080밀리초의 지연 시간은 11번째 홉에서 이스라엘로 트래픽을 전달하는 게이트웨이에서 발생하며, 추가로 100120밀리초의 지연 시간은 뉴욕 게이트웨이와 이스라엘 사이의 전파 지연으로 인한 것입니다. 패킷이 이스라엘에 도착한 후, 12번째 홉에서 17번째 홉까지의 지연 시간은 약 10밀리초입니다. 즉, 주요 지연 원인은 동부 해안에서 이스라엘로 트래픽을 전달하는 게이트웨이와 전파 지연입니다.

만약 접속하는 Client가 미국에 위치하고 있고 이스라엘에 고객이 있다면, 앞서 논의한 Tracert 결과는 반대로 나타날 것입니다. 즉, 이스라엘 사용자는 뉴욕시에 위치한 피어링 포인트를 통해 트래픽이 전달되면서 전파 지연으로 인해 병목 현상을 경험할 것입니다. 이 상황은 서유럽, 남미, 일본, 중국, 그리고 전 세계의 다른 지역 사용자들로도 확장될 수 있습니다. 이 사용자들이 미국에 위치한 서버에 접근할 때, 피어링 포인트를 통과하는 트래픽과 전파 지연으로 인해 병목 현상을 겪을 수 있습니다. 이러한 지연을 완화하기 위해서는 귀사의 조직이 중복 정보를 저장하는 서버를 최종 사용자와 더 가까운 곳에 배치할 수 있으며, 이것이 바로 콘텐츠 전송 네트워킹의 핵심 논리입니다. 그러나 전 세계에 분산된 위치에 서버를 배치할 수 있는 기업은 가장 큰 기업들뿐이므로, 대부분의 콘텐츠 전송 방식은 제3자가 이 서비스를 제공하는 데 의존하고 있습니다.

저작자표시

'📚 Book' 카테고리의 다른 글

Practical guide to content delivery networks 1-7 (0)	2024.10.19
Practical guide to content delivery networks 1-5 (0)	2024.10.07
Practical guide to content delivery networks 1-4 (0)	2024.10.04
Practical guide to content delivery networks 1-3 (0)	2024.09.25
Practical guide to content delivery networks 1-2 (0)	2024.09.23

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

Practical guide to content delivery networks 1-6

2.3 Server Operations

2.3.1 Evolution

2.3.3 Application Servers

2.4 Distance Relationship

2.4.1 Using Ping

2.4.2 Using Traceroute

'📚 Book' 카테고리의 다른 글

2.3 Server Operations

2.3.1 Evolution

2.3.3 Application Servers

2.4 Distance Relationship

2.4.1 Using Ping

2.4.2 Using Traceroute

'📚 Book' 카테고리의 다른 글

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

2.3.1 Evolution

2.4.1 Using Ping

'📚 Book' 카테고리의 다른 글

2.3.1 Evolution

2.4.1 Using Ping

'📚 Book' 카테고리의 다른 글

개인정보

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역