kkckc의 일상

이번 시간에는 쿠키(cookie)와 세션(session)에 대해서 살펴보도록 하겠습니다. 이 기술은 웹에서 로그인 상태를 유지하거나, 데이터를 저장하기 위하여 사용됩니다. :)

HTTP(Hypertext Transfer Protocol)에서 서버와 클라이언트 간의 통신은 아래 그림과 같이 요청과 응답으로 동작합니다.

위와 같은 형태는, 문서의 제공을 주 목적으로 하기 때문에, 서비스를 제공하기 위해서는 몇 가지 어려움이 존재합니다. 특히 서버의 입장에서 보면, 다음과 같은 어려운 점들이 있습니다. 주1)

첫째, 클라이언트와 서버간에 연결이 유지되지 않는다는 점입니다. 클라이언트는 자기 필요할 때만 페이지를 요청하고, 서버에게 데이터를 받고 접속을 끊어 버리게 됩니다. 서버의 입장에서 보면, 능동적으로 무언가를 할 수도 없고, 클라이언트는 자기 필요한 말만 하고 접속을 끊어버리기 때문에, 서비스를 제공하기가 참 난감합니다.

둘째, 클라이언트가 데이터를 요청할 때에, 서버는 클라이언트가 누가 누구인지 구별할 수가 없다는 것입니다. 아래 그림의 예를 보겠습니다. (서버가 클라이언트로부터 받는 메시지는 아래 그림 중 파란색의 메시지입니다)

서버의 입장에서 보면 요청 메시지(Request: 위의 GET이라고 쓰여진 부분)가 다 똑같이 생긴 터로, 서버는 누가 삼순이인지 누가 영심인지 알아볼 수가 없습니다. 그렇다면 우리가 사용하는 웹 서비스들은 어떤 방법으로 삼순이와 영심이를 구별할까요? 주2)

가장 간단한 방법은 두 사람에게 고유한 번호를 부여하는 것입니다. 학교에서 학생들에게 학번을 부여해서, 학생들을 구별하는 것과 같이, 서버도 클라이언트들에게 고유한 번호를 부여해서, 클라이언트들을 구별할 수 있습니다.

예를 들면, 아래의 그림과 같이 삼순이가 접속해서 로그인 했을 때, 서버는 삼순이에게 임의의 고유한 ID (예: 1번)을 부여할 수 있습니다.

삼순이는 이후의 모든 요청 메시지에 "Cookie: SESSIONID=1" 이라는 이름표를 붙여서, 자신의 아이디를 증명합니다. 즉, 삼순이의 모든 요청 메시지는 자신의 임시 ID (1번) 와 함께 전달되기 때문에, 서버는 이 값을 통해 삼순이를 구별할 수 있습니다.

동일하게, 영심이도 아래와 같이 서버로부터 아이디를 부여 받을 수 있습니다.

이와 같은 방법으로 서버는 삼순이와 영심이를 구별할 수 있습니다. 즉, 각 사용자를 구별하여 서비스를 제공할 수 있고. 또한 이를 응용하여, 각 사용자에게 부여된 ID를 통해 서버에 필요한 데이터들을 저장할 수도 있습니다. 세션(session)은 이 논리적 연결을 의미합니다. 주3)

보통의 경우는 서버는 삼순이가 로그인 하는 순간 세션을 생성하고, 일정기간동안 사용하지 않거나, 브라우저를 닫거나, 로그아웃 하는 순간 세션을 종료하게 됩니다. 또한, 삼순이가 로그아웃 했다가 다시 로그인하게 되면 새로운 세션 (예: 3번)을 새로 생성 및 할당하게 됩니다. 주4)

쿠키(Cookie)

세션의 목적과 유사하게, 쿠키의 목적은 제한된 상황에서 웹 서비스를 제공하기 위하여 사용됩니다. 다음과 같은 상황에서 서버가 장바구니 데이터를 어떻게 처리할 수 있을지 생각해봅시다.

서버는 영심이의 장바구니에 고기가 있다는 것을 어떻게 기억할 수 있을까요? 물론, 세션을 사용하여도 됩니다. 세션을 사용하면 서버는 각 사용자를 구별할 수 있기 때문에, 영심이의 장바구니 내용을 기억할 수 있습니다. 그러나, 서버는 영심이의 장바구니 내용을 길게(2012년 10월 13일까지) 저장하고 싶고, 서버가 이 내용을 수고스럽게 기억하고 싶지는 않은 상황을 생각해봅시다. 이런 상황에서 쿠키는 유용합니다.

쿠키는 저장해야 할 데이터들을, 서버가 클라이언트에게 위임하는 방식입니다. 서버는 클라이언트에게 "(1) 네가 기억하고 있다가, 알려줘" 라고 명령한 후, (2) 클라이언트로부터 내용을 전달받게 됩니다. 기본 원리는 아래와 같습니다.

실제의 메시지는 아래와 같습니다.

메시지의 의미는 다음과 같습니다.

(1) 서버는 Set-Cookie라는 메시지를 통해 클라이언트에게 "cart=meat"라는 내용을 2013년 10월 13일까지 기억하도록 명령합니다. (Set-Cookie: cart=meat, 13 Oct 2013 00:00:00 GMT;)

(2) 이 메시지를 받은 클라이언트는 이후의 모든 요청 메시지에, 서버가 기억하라고 시킨 "cart=meat" 메시지를 함께 붙여서 보내게 됩니다. (Cookie: cart=meat)

쿠키는 텍스트로 된 간단한 내용(예: 장바구니)을 저장하기 위하여 주로 사용되며, 여러 목적에 맞게 응용이 가능합니다. 실제로, 우리가 살펴본 세션 또한 내부적으로는 쿠키를 응용한 방법입니다. (위의 세션 예제 메시지를 보시면 쿠키 메시지를 확인할 수 있습니다.)

여기까지 읽으시면서 어떤 분들은 서버가 시키는 대로 클라이언트가 무조건 쿠키를 생성 하면, 뭔가 문제가 생기지 않을까 하는 의문이 생기셨을 것입니다. 맞습니다. 그래서, 각 브라우저들은 검증되지 않은 사이트에 들어갈 때마다 '쿠키를 사용할까요?'라고 한번씩 더 물어보게 됩니다. 또한, 브라우저에서 쿠키 값들을 종종 지워주는 이유도 이러한 부작용을 방지하기 위해서입니다. 그러나, 쿠키는 브라우저 내부에서만 작동되기 때문에, 내 컴퓨터를 해롭게 하더라도, 쿠키 파일이 무겁게 쌓이거나, 브라우저가 엄청 느려지거나 정도의 소소한(?) 해악 정도만 끼칠 수 있기 때문에, 크게 걱정하실 필요는 없습니다. ;;;

주1) 이를 전문용어로는 stateless라고 합니다. 각 연결(Request/Response)이 각각 독립적으로 동작한다는 뜻입니다.

주2) 각 클라이언트의 구별을 위하여, 대부분의 웹 서버(JSP, PHP, ASP)는, 오늘 설명한 세션의 방식을 사용하지만, 기술적으로 클라이언트의 IP를 이용해서 각각을 구별하는 것도 가능합니다. [1]

주3) HTTP에서는 세션을 웹에서의 데이터 저장공간과 동일해서 보는 경우도 있지만, 세션의 정의는 다음과 같습니다.

(1) 망 환경에서 사용자 간 또는 컴퓨터 간의 대화를 위한 논리적 연결.

(2) 프로세스들 사이에 통신을 수행하기 위해서 메시지 교환을 통해 서로를 인식한 이후부터 통신을 마칠 때까지의 기간

[출처: 네이버 검색, 정보통신용어사전]

주4) 세션을 유지한다 라는 것은 '서버 자원을 사용한다' 라는 것과 동일 의미이기 때문에. 상황에 맞는 관리가 필요합니다. 서버는 각 정책을 만들어서 세션을 유지합니다

참고사이트:

[1] WIKI, Cookie, http://en.wikipedia.org/wiki/HTTP_cookie

[2] WIKI, Session, http://en.wikipedia.org/wiki/Session_%28computer_science%29

[3] WIKI, STATELESS, http://en.wikipedia.org/wiki/Stateless_protocol

오늘은 내가 입력한 정보(예: 아이디, 패스워드)가 어떻게 서버에 전달되는지, 그 방법을 살펴보겠습니다. 사실 원리는 간단하지만, 의외로, 2000년대 초반만 하더라도 이 원리를 조금 응용해서 해킹 아닌 해킹이 이루어지기도 했었답니다.

우리가 웹 브라우저를 통해 인터넷을 사용할 때, 내 컴퓨터와 서버는 무조건 아래와 같은 방식으로 데이터를 주고 받게 됩니다.

이야기 드린 것과 같이, 주고받는 데이터의 기본적인 형태는 아래와 같은 형태로 동작합니다. 예를 들면, 사용자가 구글로 요청(Request) 메시지를 보내면, 구글은 해당되는 HTML 페이지를 응답(Response) 하는 형태입니다.

사용자가 보내는 요청(Request) 메시지를 해석하면 다음과 같습니다.

그렇다면 아래와 같은 경우,요청 메시지는 어떤 모습일까요?

이 경우에도 메시지는 크게 다르지 않습니다. 예를 들어, 철수가 이메일과 비밀번호를 입력하고 로그인 버튼을 누르는 순간 브라우저는 이메일과 비밀번호를 포함한 GET 메시지를 아래와 같이 조립해서 서버에 전달합니다.

요청 메시지는 조금 전에 살펴본 것과 유사하지만, 다른 점이 있다면, 페이지 이름 뒤에 물음표(?)가 붙은 후에, 전달하려고 하는 값들이 AND(&)로 연결됩니다. 조금 더 자세하게 살펴보면, 위의 값1, 값2의 내용은 아래와 같습니다.

서버는 이 값들을 바탕으로, 올바른 사용자인지 아닌지 판단한 후, 아이디와 패스워드가 정확하다면, 사용자를 로그인 시킵니다.

이러한 메시지 전달 방식은 다양한 곳에 쓰이게 되는데, 예를 들면, 클리앙에서 게시물을 클릭하였을 때, 보여지는 화면은 아래와 같습니다.

위 페이지에서 브라우저 주소 창의 값은 이렇게 생겼습니다. 형태는 아까 보신 것과 똑같습니다. :)

이 주소 값은 서버에게 하단의 두 개 값을 전달한 결과라는 것을 알 수 있습니다.

두 값이 무엇을 의미하는지는 쉽게 짐작할 수 있습니다. bo_table는 게시판 종류를 (news), wr_id는 게시물 번호(1311656)를 나타냅니다. 그래서, 웹 브라우저 주소 창에서 wr_id만 다른 번호로 바꾸어 주시면, 바로 다른 게시물을 보는 일도 가능합니다.

이미 많은 분들이 알고 있겠지만, 위와 같은 방법을 조금 응용하면 금지된 몇 가지의 일들도 가능합니다. 예를 들어 수강신청 확인 페이지에서 F11을 눌러서 주소 창이 보이게 한 다음에 내 학번 부분을 다른 사람의 학번으로 고치면 친구의 수강신청 내용을 볼 수 있게 되거나, 영어 시험 점수 확인 사이트에서 다른 사람의 등록 번호를 넣으면 그 사람의 시험 성적이 보이게 되기도 합니다. 심지어 인터넷 초창기의 외국 쇼핑몰들은 위의 방법들을 응용하면 해킹 아닌 해킹도 가능했다고 합니다. 물론 지금은 많은 사이트에서 이런 방법을 막아놓았습니다.

위와 같은 문제를 방지할 수 있는 가장 쉬운 방법은 메시지를 보낼때 GET이라는 방법이 아니라 POST라는 방법으로 보내는 것입니다. 이런 경우 브라우저는 값을 숨긴 채로 서버에 내용을 보내게 됩니다.

[POST 방법으로 보내기 위해서는, 단순히 HTML 소스 코드에서 메시지 보내는 부분을 POST로 설정하면 됩니다.]

POST의 경우에 실제로 전달되는 메시지는 아래와 같습니다.

방금 살펴본 방법과 유사하지만, 자세히 보시면, 메시지의 맨 앞에 보이는 부분이 GET에서 POST로 바뀌었고, 전달 값들은 하단에 따로 적혀져 있게 됩니다. 이와 같이 POST를 사용해서 메시지를 보내게 되면, 웹 브라우저 주소 창에는 어떤 메시지를 보내는지 보이지 않기 때문에, 사용자는 이 값들을 직접 조작할 수 없습니다.

그럼에도 불구하고, 위와 같은 방법도 사실은 메시지가 다 보이기 때문에 안전하지는 않습니다. 그런 이유로, 최근에는 중요한 메시지는 내용을 아예 암호화 해서 보내는 방법이 선호됩니다 :)

다음시간에는 인터넷 상에서 데이터를 저장하는 방법인 쿠키에 대해서 알아보도록 하겠습니다.

HTML(Hypertext Markup Language)은 문서를 위한 용도로 개발된 언어입니다. 이를 인터넷 상에서 사용하기 위해서는 HTML 문서를 가져와서 전달하는 프로그램이 필요합니다. 이러한 프로그램을 웹 서버라고 부릅니다. 사실 웹 서버라고 해서, 대단한 프로그램은 아니고, 컴퓨터에 띄워 놓으면 인터넷을 통해 HTML 문서를 전달하는 프로그램입니다.

  웹 서버의 기본 기능은 위의 그림과 같이 HTML문서를 가져와서 전달하는 것입니다. 그러나, 이러한 방법은 단순히 저장되어 있는 문서만을 제공하기 때문에, 다양한 서비스(예: 이 메일, 게시판, 주식정보 등)를 제공 할 수 없습니다. 예를 들어 주식 정보를 제공하는 사이트가 있다고 생각해봅니다. 문서의 내용은 시간에 따라 새로운 내용이 업데이트 되어야 합니다.

  위의 그림은 1월 7일과 8일의 결과가 다릅니다. 즉, 하얀색 글씨는 고정되어 있는 글씨이지만, 노란 색 글씨는 실시간으로 업데이트 되어야 하는 부분입니다.

<HTML 문서를 가져오기> - 일반적인 방법

  하지만, 주식 서비스와 같이 실시간으로 내용이 변해야 하는 경우에는, 위와 같은 방법으로는 사용이 어렵습니다. 그래서, 프로그래머들은 필요할 때마다 프로그램을 통해 HTML 문서를 작성하는 방법을 생각해냅니다. 주1)

<프로그램으로 HTML 만들기> - CGI 방법

  예를 들면, 아래와 같은 프로그램을 통해, 메시지를 만들게 됩니다. .

<프로그램으로 HTML 만들기> - 간단한 프로그램 부분

  날짜와 가격은 변하는 수(variable)이기 때문에 따로 '$날짜'와 '$가격'과 같이 따로 받아오게 됩니다. 이 값들을 바탕으로, 웹 서버는 HTML로 텍스트를($output)을 직접 만들어 전달합니다.

  즉 위와 같이, 문서를 달라는 요청이 있을 때, 문서를 직접 조립해서 주는 것이지요. 이러한 방식으로 웹 페이지를 만드는 방식을 CGI(Common Gateway Interface)라고 부릅니다. 이러한 패러다임은 단순히 문서를 제공하는 것에서 확장되어, 다양한 서비스(이 메일, 게시판, 뉴스 등)를 제공할 수 있게 만드는 기반이 됩니다. 다양한 웹 프로그래밍 언어들(PHP, JSP, ASP 등등) 또한 이에서 파생되었다고 볼 수 있습니다. [1]

웹 프로그래밍의 가계도 - 서버 [2]

CGI 식으로 웹 서비스를 만들기 위해서는 고려해야 할 사항이 많습니다. 미리 약속된 웹 규격도 맞춰야 하고 (HTTP), 성능도 나와야 하고, 사용자에 대한 정보도 저장해야 하고(Session), 확장성도 고려해야 하고, 보안도 생각해야 합니다. 사실은 이것 외에도 고려해야 할 사항이 꽤 있습니다. 그에 비해서, 웹 프로그래밍 언어(예: PHP, JSP, ASP)들은 위에서 열거한 기본 기능들을 기본적으로 제공하면서, 좀 더 쉽게 사용할 수 있는 편의성과 함께 자신들만의 장점들을 제공합니다. 주2) 주3)

  예를 들어 찜닭을 만든다고 생각해 보겠습니다.
(1) CGI 식으로 만든다면…… 먼저 닭부터 잡아야 합니다. 그리고, 털도 뽑고, 양념도 어느 정도 직접 만들어야 합니다.
(2) 웹 프로그래밍 언어 식으로 만든다면, 슈퍼에서 닭과 양념장을 사서 쉽게 만들 수 있습니다. 심지어 어떤 제품들은 전자레인지에 데우기만 하면 완성되는 제품들도 있습니다. (예: Ruby on Rails)

  그래서, CGI가 나쁘냐고 물어보신다면, 꼭 그렇지는 않습니다. CGI식으로 찖닭을 만드는 경우 시간도 오래 걸리고, 만드는 사람에 따라 맛은 보장되지 않습니다만, 반대로 환상의 찜닭을 만들 수도 있습니다. 동일하게, 전자레인지용 찜닭의 경우는 쉽게 만들 수 있고, 일정한 맛은 보장되지만, 품질을 어느 정도 포기해야 할 수도 있습니다.

  다음 이야기에서는 내가 입력한 정보(예: 아이디, 패스워드)가 어떻게 서버에 전달되는지, 그 방법에 대해서 살펴보겠습니다. :)

[1] CGI에 대한 내용의 WIKI
http://ko.wikipedia.org/wiki/%EA%B3%B5%EC%9A%A9_%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4_%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4

[2]http://upload.wikimedia.org/wikipedia/commons/e/e4/Web_development_timeline.png

  주1) 실제의 서버에서는 요청이 있을 때마다 매 순간 페이지를 생성하지는 않습니다. 계속 동일한 내용을 보내주어야 한다면, 매 순간 HTML 문서를 새로 만드는 것이 아닌, 이전에 미리 만들어놓은 HTML문서를 돌려줍니다. 이 방법을 캐쉬(Cache)라고 합니다.

주2) 엄밀히 말하면, 웹 프로그래밍 언어가 기본 기능을 제공하는 것이 아니라, 웹 서버(Web Application Server)나 서버 모듈이 제공한다고 볼 수 있습니다.

주3) 각 웹 프로그래밍 언어들은 자신만의 장점들을 가지고 있는 경우가 많습니다. PHP(Personal Home Page Tools)은 누구나 쉽게 만들 수 있도록 개발된 언어이고, ASP는 윈도우(.NET) 환경에서 사용되도록 고려되었습니다. JSP는 JAVA기반으로 어떤 컴퓨터나 OS(Linux, Windows 등)에서도 잘 동작합니다.

초창기 웹은 단순히 멀티미디어 문서의 작성과 이를 공유하기 위한 목적으로 만들어졌습니다. 웹을 구성하는 언어인 HTML(Hyper Text Markup Language)는 1980년대에 처음 아이디어가 나왔지만, 1991년에야 처음으로 시작되었습니다. [1] 서비스가 만들어 진지 20년이 되지 않는 것이지요. 이러한 웹의 나이는 컴퓨터 시스템의 역사 속에서도 상대적으로 어린 편에 속합니다. 그러나, 1980년대 이후의 개인용 컴퓨터(PC)의 보급과 1990년대 인터넷의 폭발적인 성장 앞에서 웹은 가장 대중화된 서비스로 자리잡습니다.

1990년 ~ 2008년 세계 인터넷 사용자수 [WorldBank]

웹에서 사용되는 언어인 HTML(HyperText Markup Language)의 기본 기능은 '(1) 스타일(예: 밑줄, 굵게)이 있는 문서 + (2) 문서간 링크' 라고 생각하시면 큰 무리가 없을 것 같습니다. 그렇다면, 문서에 스타일이나 링크를 어떻게 저장하는 것일까요? 옷을 사면 옷에 태그(꼬리표, Tag)를 붙여서 태그에 옷의 크기, 가격 등을 따로 표시하는 것과 같이, HTML도 태그라는 방법을 통해 필요한 정보를 표시합니다. 아래 그림에서 <B>, <U>와 같이 텍스트에 따로 정보를 표시해준 부분을 태그라고 부릅니다. HTML은 미리 약속된 태그의 정보를 통해 스타일 및 링크를 표현합니다.

인터넷 익스플로러나 파이어 폭스와 같은 웹 브라우저를 통해 코드부분을 불러오면, 위의 그림과 같이 태그의 내용을 '해석(Interpret)'해서 보여줍니다. 기본적인 웹 브라우저의 기능은 인터넷에 있는 HTML 문서를 받아온 후 위의 그림과 같이 해석해서 보여주는 것입니다. 이러한 태그들의 사용 방법은 표준으로 미리 약속되어 있습니다. 예를 들면 <B>는 굵게, <U>는 밑줄 이런 식으로 미리 정해져 있는 것이지요. 어떤 사람이 <B>가 아니라 <BOLD>를 쓰고 싶더라도, 미리 약속된 표준들을 지키지 않으면 브라우저에서 이를 해석할 수 없게 됩니다. 국제기관에서는 이에 대해서 표준안(RFC: Request for Comments)을 만들었는데, HTML의 경우 RFC 1866 이라는 문서를 통해 사용법을 명시하고 있습니다. [2] 표준이라고 말하면, 뭔가 대단해 보이지만, 사실 설명한 것과 같이 "<B>라고 하면 굵게 표시하기로 한다" 와 같은 정해진 약속이나, "어떻게 표시하면 문제 생길 수 있으니 웬만하면 하지 말 것(Recommendation)", "이건 꼭 적어줘야 함(Mandatory)" 뭐 이런 내용들의 리스트랍니다. 사실, 태그 등은 표준에서 지원하지 않는 방법으로 작성 하더라도, 브라우저에서 지원한다면 기술적으로는 문제가 없습니다. 그러나, 편의성 측면에서는 문제가 생길 수 있습니다. 예를 들면 초창기의 브라우저들은 표준에 없는 태그들을 지원해서, 익스플로러에서 보이는 페이지가 넷스케이프 (파이어폭스의 전신입니다)에서 잘 안보이거나, 그 반대의 현상이 나타나기도 했습니다.

인터넷과 프로토콜

HTML은 텍스트(HyperText)를 태그(Tag)를 이용해서 정보(스타일, 링크 등)를 저장한 언어입니다. 그러나, 인터넷 상에서 HTML을 주고 받기 위해서는 정해진 규칙이 필요합니다. 프로토콜(Protocol)의 의미는 인터넷 상에서 미리 정해진 통신 규약을 의미하는데, 대단한 건 아니고, 미리 약속해 놓은 규칙입니다. 예를 들면, 철수라는 사람이 중국집 컴퓨터에 접속해서 "BBB"라고 보내면, 중국집에서는 "배고파"라고 해석하고, "볶음밥"이라는 응답을 보내기로 미리 규칙을 만들었다고 생각해봅시다, 이것도 일종의 프로토콜입니다. 프로토콜은 실제로 약속을 정하기 나름입니다. 표준을 만드는 사람들은 HTML문서를 인터넷 상에서 주고 받는 방식에 대해서도 표준 규약을 만들었는데, 이를 HTTP(HyperText Transfer Protocol)라고 부릅니다. [3] 풀어 이야기하면 "정보가 들어간 텍스트(HyperText)를 전송하는 프로토콜(규칙)"이라는 뜻입니다. 웹 브라우저에 주소 창에서 자동으로 HTTP라고 붙게 되는 것을 많이들 보셨을 텐데요, 바로 그겁니다! J

이 HTTP 프로토콜의 기본은 의외로 간단합니다. 내 컴퓨터를 클라이언트(Client)라고 부르고, 우리가 접속하는 컴퓨터(예를 들면 구글에서 서비스를 제공하는 컴퓨터)를 서버(Server)라고 부르겠습니다. HTML은 철저하게 다음과 같은 절차로 움직입니다. 주1)

(1) 클라이언트는 서버에게 HTML 페이지를 달라고 요청합니다. (용어로는 Request라고 합니다.)

(2) 서버는 클라이언트에 HTML 페이지를 넘겨줍니다. (용어로는 Response라고 합니다)

클라이언트는 무조건 능동적으로 요청하고, 서버는 무조건 수동적으로 1회 응답하는 것이 두 컴퓨터의 역할입니다. 메시지를 서로 주고 받는 것은 우리가 메신저나 카카오톡 같은 곳에서 메시지를 주고 받는 것으로 생각하면 무난합니다. (서버는 절대 먼저 나에게 말을 걸지 않습니다. 내가 말하면 대꾸할 뿐입니다! 그것도 말 걸 때마다 딱 한번씩만 대꾸합니다) 아래는 전송되는 메시지의 예입니다.

좀 더 쉽게 해석하면 아래와 같은 말이지요 :)

클라이언트는 필요한 페이지나 이미지 등이 있을 때마다, 위와 같은 방법으로 매번 일일이 서버에게 요청합니다. 다음은 실제로 메시지를 주고 받는 것을 캡춰한 것입니다. 주2)

위의 예는 텍스트를 통해 서버와 클라이언트 간의 Request와 Response 메시지의 전송을 보여주고 있습니다. 이러한 Request/Response 방식의 전송 방식은 단순하기 때문에, 본래의 목적인 문서를 전송하는 데에 최적화 되어 있습니다. 즉, 다시 말하면 HTTP가 제공할 수 있는 서비스의 한계는 분명합니다. 왜냐하면 서버는 무조건 클라이언트의 요청에 수동적으로 응답해야 하기 때문입니다. 서버는 클라이언트로 데이터를 직접 전송해 줄 수 없습니다. 예를 들어 웹으로 체스 게임 서비스를 만든다고 생각해보겠습니다.

(1) 사람1이 말을 움직여 움직인 위치를 서버로 보냅니다. (사람1 -> 서버)

(2) 서버는 사람1에게 잘 옮겼다고 응답합니다.

(3) 그러나 사람2는 내 차례가 진행되었는지 아닌지를 알 수 없습니다. 왜냐하면, 서버는 클라이언트로 직접 내용을 보낼 수 없기 때문입니다. (말씀 드렸듯이 HTTP에서 서버는 클라이언트의 요청에 대해서만 수동적으로 대답합니다)

이러한 명확한 한계는 웹을 통해 다양한 서비스(증권, 게임 등등)와 요구사항을 제공해야 하는, 현대의 웹 환경에서 액티브엑스(ActiveX)나 플래시(Flash) 등을 필요로 하게 되는 배경이 되기도 합니다.

다음 이야기에서는 고정된 문서인 HTML 문서로 어떻게 웹 서비스를 할 수 있는지, CGI(Common Gateway Interface)패러다임에 대해서 살펴보겠습니다.

주1) 실제의 HTTP 프로토콜의 규약은 문서를 저장하는 PUT, 문서를 지우는 DELETE 등의 여러 가지 액션을 가지지만, 일반적으로는 GET과 POST 명령이 사용됩니다.

주2) 윈도우의 command (cmd)에서 'telnet google.com 80'을 누르고 위의 Request 메시지를 입력 후 엔터 키를 두 번 누르시면 동일한 화면을 볼 수 있습니다.

[1] http://ko.wikipedia.org/wiki/HTML

[2] RFC 1866, HTML 2.0, http://www.rfc-editor.org/rfc/rfc1866.txt

[3] RFC 2616, HTTP 1.1, http://www.w3.org/Protocols/rfc2616/rfc2616.html