linuxism

데이터베이스 언어는 데이터베이스를 구축하고 이용하기 위한 데이터베이스 시스템과의 통신 수단이다.

(1) 데이터베이스 언어의 종류

① 데이터 정의어(DDL; Data Definition Language)

데이터베이스 구조와 관계, 데이터베이스 이름, 데이터 항목, 키 값의 규정, 데이터형과 한계 규정, 데이터 액세스 방법 등을 규정

② 데이터 조작어(DML; Data Manipulation Language)

주프로그램에 내장되어 데이터베이스를 실질적으로 운영

질의어(Query Language) : 데이터베이스를 단말 사용자가 이용하도록 만든 언어로 자연어이며, 대화식 사용

데이터 부속 언어(Data Sublanguage) : 응용 프로그램과 DBMS를 연결하는 도구로 호스트 언어(Cobol, C 등)로 작성된 응용 프로그램 속에서 사용되는 명령어의 집합

③ 데이터 제어어(DCL; Data Control Language)

데이터베이스를 올바르게 공용하기 위해 여러 가지 규정이나 기법을 통하여 제어해야 함

데이터 제어어는 데이터를 보호하기 위한 데이터 보안, 데이터 무결성, 데이터 회복과 병행 수행을 제어할 수 있는 명령어 포함됨

(2) 상용화되는 데이터베이스 언어의 종류

SQL(Structured Query Language) : 관계형 데이터베이스 언어로 가장 일반적으로 사용됨

IMS(Information Management System) : 계층적 데이터베이스 언어

DBTG(DataBase Task Group) : 데이터베이스 언어 협회(CODASYL)에서 개발한 네트워크형 데이터베이스 언어

TOTAL : 미국에서 개발된 네트워크형 데이터베이스 언어

dBASE : Ashton-Tate사에서 개발한 PC용 데이터베이스 언어

HTTP는 사용자에게 보다 좋은 Internet을 서비스하기 위해 제정이 되었다. 특히 사용자나 서버 모두에게 성능의 향상과 요구되는 시간의 최소화에 중점을 두고 있다. HTTP/1.0에서는 없거나 미약하여 HTTP/1.1에서 향상된 기능은 우선 지속적인 연결을 해 주는 persistent connection의 특징과 pipeline의 기능 및 전송하는 데이터의 양을 줄이는 데이터의 압축방식과 proxy server와 cache의 사용을 둘 수 있다.

HTTP의 기본구조와 1.0의 문제점과 이를 1.1에서 해결하는 방식에 대해서 살펴보자. HTTP는 기본적으로 MIME 형태로 이루어지며 request/response의 방식에 기반을 두고 있다. HTTP 1.0의 구조 및 문제점을 살펴보면, HTTP 1.0은 단순하게 open/operation/close의 방식을 취하고 있어서 단순하다. TCP connection당 하나의 URL만 fetch하며 매번의 request/response가 끝나면 연결이 끊기므로 매 번 필요할 때 마다 다시 연결을 해야 하므로 속도가 떨어진다. 그리고 한번에 얻어서 가져올 수 있는 데이터의 양이 제한되어 있다. 나아가 URL의 크기도 작다.

HTTP/1.0에서는 connection은 TCP의 open/close을 위한 flow의 제한으로 인해서 bandwidth가 적게 할당되어 연결된다. 그래서 congestion information의 손실로 인해서 disconnect가 될 수 있다. 계속되는 disconnection현상으로 인해서 한 서버에 계속에서 접속을 시도하게 되어서 과부하가 걸리게 되고 결국에는 성능이 떨어지게 된다. 이러한 문제점을 해결하기 위해서 HTTP/1.1에서는 multiple request에 대한 처리를 가능하게 해준다. 즉, request가 많이 서버에 전달되면 서버에서는 serial하게 response을 해 주어 해결을 하고 있다. 즉, request/response가 pipeline의 방식으로 진행이 가능하다.

HTTP/1.0에서는 client가 IP address와 서버가 1:1관계에 있다고 가정을 두고 있다. 그래서 request와 response는 직접 전달되고 있다고 인식한다. 하지만 HTTP/1.1에서는 하나의 IP address로 multiple web site를 지원이 가능하다. 즉 한 인터넷 주소로 여러 web site의 연결이 가능하다. 이때 client와 server는 Host request-header를 반드시 포함하고 있어야 하며 이 header를 주고 받아야 한다.

HTTP/1.1은 HTTP의 Internet에서의 impact를 줄이고 HTTP를 Internet Protocol에 잘 적용이 되도록 해주고 빨리 수행이 되도록 cache를 두어 성능을 향상하고 있다. 그리고 HTTP/1.0과 호환이 가능하다. 과거의 HTTP/1.0에서는 request와 response 메시지 모두에 적용되며 메시지의 body에는 영향을 주지 않는다. 기본적으로 HTTP/1.0에서는 Date와 Pragma를 사용하는데 이는 서버와 클라이언트의 현재시간을 알려주고 cache를 제어하기 위해 사용되는 method였으나 HTTP/1.1에서는 Pragma가 사용되지 않는다. 이 cache의 사용으로 인해 해결해야 할 부분이 있다.

즉 cache를 이용하여 어떻게 semantic하게 transparency를 제공하고 어느 적정한 수준이상의 cache가 사용되어 data가 저장되어 있는 경우 cache의 내용을 비워 주어야 한다. 이 과정은 reliable한 cache의 사용과 cache의 burst해지는 현상 등을 해결하기 위해 도입되었다.

그리고 HTTP/1.0에서는 주로 Last-Modified, 즉 Dates에만 의존해서 cache를 다루었지만 HTTP/1.1에서는 1.0에서 지원해 주는 기능 이외에 client에서 사용 가능한 미디어 타입을 명시하여 지원을 해 주고 있으며 또한 사용가능한 character set, 제공되는 encoding 방식과 인식 가능한 언어 등을 request header에 명시하여 메시지를 전달한다. 그리고 cache의 내용이 적절한지의 여부를 판단하기위해 If-Match, If-None-Match를 사용하고 있다.

또한 If-Range및 If-Unmodified-Since등을 비교하여 method를 수행할 수 있도록 하고 있다. 이 cache는 서버에 노출되어 있으므로 불필요한 자료를 막거나 주의를 요하는 자료 등은 저장하지 말아야 한다. 따라서 cache의 control에 주의를 요해야 한다. 특히 cache의 재사용을 하거나 하는 경우에는 proxy를 두어서 cache를 control하고 있다.

이때 물론 개인적인 data의 경우에는 이 proxy를 사용하지 말아야 한다. 이때 Max-Forwards를 두어서 거쳐 갈 수 있는 최대 proxy의 수를 제한할 수 있고, Proxy-Authentication을 두어 proxy server가 비공개인경우 사용자 인증을 위해 사용이 된다. Resource의 일부만을 받고 이어받기의 기능을 지원하기 위해서 Range의 새로운 header가 추가 되었다.

이제 response의 header의 내용을 살펴보면, 우선 HTTP/1.0에서는 location과 server및 WWW-Authenticate을 이용하고 있다. HTTP/1.1에서는 client에서 request를 보낸 이후 server에서 응답 메시지를 생성하기까지의 시간을 나타내는 age가 도입되었고, 만약 서버가 proxy server인 경우 사용자 인증을 요구하는 Proxy-Authenticate라는 헤더필드를 지원하고 있다. 그 이외에 Public, Retry-After, Warning 등의 정보가 추가되었다.

HTTP method는 우선 HTTP/1.0에서는 GET, HEAD, POST의 method가 사용되고 있는데 GET은 Request-URI에서 지정한 어떤 정보이든 Entity Body로 전달해 달라는 요청으로 이 Request-URI가 어떤 실행프로그램을 명시한 경우에는 이 프로그램의 실행결과를 전달하라는 의미이다. HAED의 경우는 Header의 정보만 요구하는 method이고 POST는 Request 메시지의 body에 포함된 자원을 Request-URI로 넘겨주는 경우 사용한다.

HTTP/1.1에서는 통신과 관련된 선택사항들에 대한 정보를 요구하는 경우 OPTION의 method를 지원하고 있으며, Request 메시에 포함되어 있는 data를 지정한 Request-URI로 저장하기 위한 PUT을 두고 있다. 또 특정한 resource를 지우기 위해 DELETE를 두고 있으며 최종 destination까지의 Loopback을 테스트하기 위한 TRACE method가 있다.

앞에서도 언급했지만 HTTP/1.0에서 매번 필요시에만 connection을 open하고 close하는 기능을 해결하기 위해서 HTTP/1.1에서는 multiple connection을 open할 수 있도록 하고 있다. 뿐만 아니라 몇몇 entity의 경우에는 그 길이를 모르므로 이를 해결하기 위해서 chunked encoding을 도입하여서 해결하고 있다. 그리고 전송한 data를 압축해서 전달이 가능하도록 하고 있어서 전달하고자 하는 data의 양을 줄인다.

이상에서 살펴보았듯 HTTP/1.0에서 HTTP/1.1로의 성능적인 면과 시간의 최소화에 중점을 두고 있다.

----------------------------------------------------------------------------------

출처를 밝힙니다..

(출처 : 'HTTP/1.0의 문제점과 1.1에서 해결한 방식' - 네이버 지식iN)
집필자 : zion707  (2004-05-18 15:18)