Think Outside The Box

성인광고 등록 방지할수 있는 간단한 예방책을 소개합니다.

1. 게시판 폼페이지에서 아래의 항목을 추가 한다.
<input type="hidden" name="sessionid" value="<%=session.SessionID%>">

- 대부분의 성인광고는 처리페이지에 값을 일괄적으로 전송하기때문에 폼페이지에서 입력된 값인지를 확인해야한다.
- 세션아이디값을 처리페이지로 넘겨 현세션과 동일한지를 비교한다. 1 코드처럼 폼페이지에서 세션아이디값을 같이 처리페이지로 전송한다.

2. 처리페이지에 아래코드를 추가 한다.
<%
if not request("sessionid") = session.SessionID then
    Response.Write    "<script language=javascript>"& vbCrLf &_
                    "    alert('올바른접근이아닙니다.');"& vbCrLf &_
                    "    history.back();"& vbCrLf &_
                    "</script>"
    Response.End
end if
%>

 - 폼페이지에서 넘어온 세션아이디값과 현 세션아이디값을 비교하요 폼페이지를 통해서 넘어온 값인지를 확인한다.

웹사이트를 운영하다 보면 이미지 파일을 함부로 다운로드 받지 못하도록 이미지의 경로를 노출시키고 싶지 않은 경우가 있다. 여기서는 ASP를 이용한 간단한 방법을 살펴보도록 하겠다. 우선 간단한 예제부터 살펴보도록 하자. 아래 샘플 이미지가 있는데 이 이미지는 여기서 살펴볼 방법에 의해 이미지를 로드한 것이다.

<img src="/etc/codeexample/asp/19444.asp?FName=020129p_01.jpg">
 
이미지의 경로가 .gif나 .jpg가 아니라 .asp인 asp파일로 되어 있다. 즉, asp 파일 안에서 적절한 이미지를 불러 오는 것이다. 그렇다면 /etc/codeexample/asp/19444.asp의 내용은 어떻게 되어 있을까?

<%
Option Explicit
 
'Referer를 먼저 구한다.
Dim strBuffer, FilePath
strBuffer = Request.ServerVariables("HTTP_REFERER")
'만일 referer가 http://korea.internet.com/channel/content.asp였다면
strBuffer = mid(strBuffer, InStr(strBuffer,".") + 1)
'이 상태에서의 strBuffer = internet.com/channel/content.asp가 됨
strBuffer = left(strBuffer, InStr(strBuffer, "/") - 1)
'이 상태에서의 strBuffer =  internet.com이 됨
 
'실제 이미지가 들어있는 디렉토리를 지정.
'다른 웹사이트일 수도 있고 다른 디렉토리일 수도 있다.
'이 값은 자신의 환경에 맞게 수정하기 바란다.
'사람들이 예측할 수 없는 이름을 사용하는 것이 좋다.
FilePath = "/images/photoshop/"
 
'만일 referer에 internet.com이 포함되어 있으면...
'referer도 자신의 환경에 맞게 수정하기 바란다.
If strBuffer = "internet.com" then
        '이미지 경로 완성
        FilePath = FilePath + Request.QueryString("FName")
Else
        '에러 이미지 경로!!
        FilePath = "/images/error.gif"
End If
'원하는 이미지 불러옴
Response.Redirect(FilePath)
%>
 

여기서 살펴본 내용은 사실 완벽한 것이 아니다. 여러 허점이 보이는 그런 코드이다. 페이지에 나타난 이미지를 캡쳐하거나 복사하는 등 여러 가지 막기 어려운 부분이 여전히 남아 있다. 여기서 사용한 방법과 자바스크립트를 이용하면 이미지를 불법으로 가져가는 것을 조금 더 귀찮게 만들 수는 있다. 자바스크립트를 이용한 방법은 다음 글을 참조하기 바란다.

ASP가 여러 사람 먹여 살리는 것 같습니다. 1996년 당시, CGI가 판을 칠 때 슬그머니 나타난 ASP. 전 아직도 그 때 당시를 잊지 못합니다. 이렇게 쉬운 것도 있구나... DOS에서 C와 C++을 하다가 윈도상에서 DB를 해야 했을 때 VB, 델파이 등 여러 가지를 시도하다 MS-Access를 만났을 때와 마찬가지로 그 감동은 엄청난 것이었습니다. MS에서 제공해주는 기본적인 예제와 메뉴얼로 이렇게 저렇게 해보다 결국 하나하나 화면이 만들어지는 그 감동. 프로그래머라면 누구나 느끼시는 것일 겁니다. IIS가 웹서버 시장의 절반정도를 차지하고 있는 작금의 현실은 그대로 ASP에 대입된다고 볼 수 있겠죠. 그만큼 사용자나, 개발자가 많다는 얘깁니다. 작설하고.. 본론으로 들어가죠.

자, ASP는 자바스크립트와 자바의 관계처럼 VB와 연관이 있습니다. 즉, VB 스크립트를 주로 사용하기 때문이죠.
이제부터 간단하게나마 syntax들을 훑어봅시다.

1. <%로 시작해서 %>로 끝난다. 문장은 엔터를 만나면 종결됩니다.
2. 변수는 선언해줘도 되고(Dim 구문), 그렇지 않아도 됩니다. 하지만, 시스템이 커질수록 선언해 주는 것이 디버깅 등에 도움이 됩니다. Option Explicit 명령을 써서 강제로 변수를 선언하게 해 줄 수 있습니다. 또한, 자바스크립트와 마찬가지로 형을 선언하지 않습니다.
3. 주석은 ' 뒤에
4. include로 필요한 스크립트 파일을 불러올 수 있습니다.
<!--#Include File="xxx.asp"--> 처럼 파일을 지정할 수도 있고,
<!--#Include Virtual="/inc/xxx.asp"--> 처럼, 가상경로의 파일을 지정할 수 있습니다.
5. 반복문
For Next
     eg. For i=1 to 10
           Next
For Each
    eg. arr=Array("A","B","C")
          For Each item in Arr
          Next
Do Until
    eg. Do Until RS.EOF
          Loop
6. 조건문
If Then
Select Case
    eg. Select Case i
          Case 1:
          Case 2:
          End Select
7. 함수 
여러 군데서 반복해서 쓰여지는 구문일 경우 Sub 프로시져를 사용합니다.(Sub ~ End Sub)
값을 되돌려 받아야 할 경우 Function 프로시져를 사용합니다.(Function ~ End Function)
Exit문을 쓰면 sub, function, 반복문 등을 빠져나올 수 있습니다.

8. 가장 많이 사용되는 DB에 관련된 오브젝트, 프라퍼티, 메쏘드는 다음과 같습니다.

앞서 말한 4가지 중 어떤 것이 주된 원인이 되는지 정형화시키기는 사실 매우 어렵다. 그러나, 일반적으로 분류해 보면, 컴포넌트의 오류와 데이터베이스의 오류가 대부분이다. 혹은 이 둘의 복합적인 양상을 띠게 된다.

일반적으로 컴포넌트 오류로 인한 문제는, 주기적으로 이 컴포넌트와 관계된 오류 메시지가 웹 로그에 나타나므로 그 문제점의 발생 및 수정은 비교적 쉽다. 간혹, 컴포넌트 문제가 아니라 웹 서버 자체의 설치 문제와 관계된 사항들에 의해 시스템 에러를 받기도 한다.

이러한 문제들은 디버거를 사용하여 해결하는 경향이 크다. 웹 사이트 자체를 디버깅 모드로 운영하면서 생기는 여러 결함들을 잡아 낼 것을 일반적으로 권하고 있다.

컴포넌트 오류가 아닌 경우에는 정말 어딘가의 병목이 있어서이다. 이 경우가 가장 잡기 어려운 에러이며, 보통 데이터베이스 응답 지연으로 인해 문제가 야기된다. 단순한 예로, 데이터베이스 커넥션을 열기 위한 라이선스가 충분하지 않아 문제를 야기하기도 하며, 소통을 위한 프로토콜 정보가 맞지 않아(즉 보안 프로토콜을 사용할 때), 느려지면서 서버가 죽어버리기도 한다. 이런 문제로 인해 죽는 서비스는 CPU 사용량도, 메모리 사용량도, 심지어 웬만한 변수도 다 정상이다. ASP Queue만이 증가할 뿐, 서버는 아무런 이상 증상을 보이지 않는다.

이렇게 특히 ASP 병목이 있을 때, 쉽게 그 문제를 확인하는 방법은 HTML 파일에 대해서는 응답 지연이 오지 않으면서 ASP 파일만이 응답 지연이 발생하는지 여부를 알아보는 것이 가장 빠르다. 물론 최소한 풀링으로 동작하는 서로게이트를 사용하여야 하고(가급적 독립이 좋긴 하지만, 성능상의 희생이 따르기 때문에) Inetinfo.exe 자체의 상태와 dllhost.exe의 상태를 파악하는 것이다.


DLLHOST.EXE의 과부하와 시스템 문제.

DLLHOST.EXE는 COM(+) 서로게이트를 위한 파일이다. 서로게이트란 DLL을 사용할 수 있도록 베이스 프로세스를 형성해 주는 역할 정도로 이해하면 크게 다르지 않다.

서로게이트를 이용하는 까닭은, 동시에 여러 개의 웹 서버가 운영되는 시스템에서, 하나의 가상 서버에 과부하가 걸렸을 경우, 다른 웹 서버 시스템으로 이런 문제가 전이되지 않도록 하기 위해서이다.

일반적으로, 죽는 웹 서버들 중 일부는 DLLHOST의 과부하(CPU 50%이상 독점 점유)로 인해 발생되며, 이는 서로게이트되고 있는 웹 서비스를 중지한다고 해서 회복되지 않는다. 웹 서비스 전체를 다시 시작해도 그대로 CPU를 점유하는 경우가 많으며, 대부분의 해결책은 재부팅이다.

DLLHOST의 CPU 점유 원인은 생각보다 많다. 일반적으로 ASP Requests Queue 값과 정비례하는 수가 많은데, 이 역시 두 가지 부류로 나뉘게 된다. 가령 일시적 병목 현상이 걷잡을 수 없는 상황으로 발전하는 예를 들 수 있다. 즉, 어떤 이유에서 서버가 잠시 느려진 상황에, 처리용량보다 많은 요청이 들어와서, 큐잉이 생기는 경우 점점 처리용량은 줄어들고 큐잉은 길어지는 상황이 발생하는 것이다. 최악의 경우 Server Too Busy 메시지를 끝으로 죽어버린다. 그런데, 일반적인 경우는 프로그램 외적인 측면에서 찾는 것이 좋다.

최근 DLLHOST CPU 점유율을 가장 높인 일등공신은 웜이다. 웹 사이트 프로그램을 가장하여 해당 대역을 스캔하는 악성 코드 등이 CPU 점유율을 무지막지하게 높이는 수가 많으며, 주기적인 스캔 등으로 악성 코드의 잠입을 막는 방법을 생각해 볼 수 있다. 특히 주기적으로 시스템에 부하가 걸리거나, 네트워크 모니터 결과 ARP 신호가 엄청나게 증가하고 있으면 이는 필시 웜이 동작하는 것으로 볼 수 있다.

웜이 아니라면, DLLHOST CPU 점유율이 올라가는 까닭은 서버사이드의 과중한 프로그램 부하 때문일 수 있다. 가령, 암호화/복호화를 지속적으로 반복하거나, COM(+) 기반 서버 컴포넌트가 많은 경우 이런 문제를 생각해 볼 수 있다. 굳이 이 뿐만 아니라, ASP 등의 과중한 코드 등도 이러한 문제를 야기하게 된다. 이에 대한 해결책은 의외로 간단하다. 서버를 증설하면 된다. 혹은, 비즈니스 로직을 바꾸던가 프로그램을 재설계하는 것을 권한다.

만일 풀링이나 격리 모드로 시스템을 동작시킨다면 DLLHOST의 과부하는 원격에서도 탐지할 수 있다. HTML 파일의 응답 속도는 무척 빠르지만 ASP, ActiveX Server Component 의 호출은 무척 느려지는 현상이 발생하기 때문이다.

튜닝 포인트라는 개념은, 실제로 웹 서버의 아주 특수한 부분에 의해 생긴 문제가 전체적으로 확대되어 발생하다는 것이다. 이것은 고속도로에서 흔히 보는 병목 현상과 마찬가지다. 도로 중간에서 사고가 났을 경우, 해당 도로는 마비되지만, 실제로 도로 전 구간이 마비된 것은 아니다.

이런 병목 지점에서 외부의 급격한 리퀘스트를 받게 될 때, 웹 서버는 자기가 처리할 수 있는 양 이상의 값을 받게 된다. 일단 시스템 구조상 이 값은 큐에 삽입된다. 그리고, 큐보다 많이 들어오는 값들은 튕겨 나간다. 이 튕겨 나갈때 나타나는 에러는 Server Too Busy 라는 메시지이다.

그런데, 이 병목 지점이 형성되는 것은 사용 상황과 보조 서버들의 상황, 혹은 여타 외부적인 변수를 매우 많이 받는다. 따라서, ASP Tuning 을 한다고 해서 무조건 커넥션 스트링의 건전성과 CreateObject 구문의 단속만 하는 것은 경우에 따라서 별다른 도움이 되지 못할 수 있다. 물론, CreateObject 구문을 단속하면, 개체의 효율성이 증가하기 때문에 다소간 빠르게 전체적인 처리를 할 수 있겠지만, 웹 서버가 죽을 정도의 병목을 해결할 만한 근원적인 해결책은 되지 못한다.

큐를 넘어서서 서버가 응답 불능으로 들어가는 것은, 보편적으로 입출력을 받는 프로그램이면 동일하게 나타나는 것이다. 가령, 포그라운드에 돌아가는 프로그램이 입력값을 받아 처리하는 것인데, 무작위로 계속 입력값을 주면 결국 프로그램이 이상하게 작동하는 가능성이 높아짐을 볼 수 있다. 멀티쓰레딩을 완벽하게 쓰는 프로그램들은 이런 문제로 인해 중단될 가능성이 더욱 높다.

따라서, 튜닝의 가장 근본적인 해결책은, 전체 프로그램의 플로우차트나 비즈니스 로직이 된다.

자 그렇다면 튜닝의 목적은 병목을 잡는 것이며, 병목은 큐가 쌓이는 지점이라고 이야기했다. 그리고 추가로 이야기하는 몇 가지 팁은 큐가 쌓이더라도 곧바로 시스템이 응답없음 상황으로 빠지는 것은 아니다. 시스템에 따라서 약간의 지연 효과가 발생되며(즉 큐를 처리하기 위해서 시스템이 좀 고생을 하며) 이후 시스템이 다운된다. 이런 메커니즘은 일반적인 OS와 시스템들이 모두 겪는 현상이기는 하지만, 이론적으로 왜 그런 문제들이 발생하는지 체계적으로 설명되지는 않는다.

여기서부터는 실제로 이론적 측면보다는 관리자의 노련함이 필요하다. 이단 관리자는 다음 중 무엇이 이러한 병목을 일으키는지 원인을 파악해 보아야 한다.

1. 정말 접속이 많아서
솔직히, 이 해결책은 돈 들이라는 신호라고 생각할 수밖에 없다.
하드웨어적 한계를 벗어난 경우가 많다. 특정 시점에만.
예를 들어, 밤 10시마다 이벤트를 하는 사이트를 생각할 수 있다.

2. 메모리 누수, 혹은 메모리 침범 에러
Component 의 문제이다. Third-Party Component등이 이 문제를 종종 발생하게 한다.

3. 데이터베이스 병목
쿼리하러 간 쓰레드들이 돌아오지 않을 때 발생한다.

4. 네트워크 병목
혼잡시간 때 DB로 들어가는 선을 끊어 보면 웹서버는 곧 다운된다.

5. 기타.
관계 컴포넌트들의 응답 없음 등이 문제가 될수도 있고, 악의적인 DDOS 공격일 수 있다. 만일 사이트가 죽는 원인이 사이트가 주기적으로 과도한 패킷에 의한 공격이라면, 이는 적절한 보안 대책을 수립하여야 한다. 해당 시간 전후로의 네트워크 모니터링으로 확인이 가능하다.

Server.CreateObject 구문을 단속하지 않으면 대용량 시스템에 문제가 많다는 사실은 오래 전부터 있어 온 이야기이다. 그러나, 실제 저 문제에 의해 죽는 시스템은 생각보다 많지 않다.

웹 사이트 성능을 측정하면서 많은 부분 간과하는 것이 바로 CPU와 메모리에 지나칠 정도로 집착하는 것이다. 실제로 죽는 웹 서버는 메모리 소요량이 많아서도 아니며, CPU 점유율이 많아서도 아니다. 간혹 CPU 점유율이 많은 서버가 존재할 수는 있겠지만, 이는 데이터베이스 등에서 병목을 일으키는 예가 된다.

따라서, 죽는 웹 서버는 일반적으로 성능 모니터링을 하지 않아도 죽는 것을 감을 잡는다. 노련한 엔지니어라면, 시스템이 돌아가는 상황을 조금만 보더라도 "이 시스템은 언제쯤 죽을 것인지" 판단이 서기 마련이다. 사실상, 시스템 성능 모니터를 필자도 거의 이용해 보지 않았으며, 시스템 성능 모니터가 제시하는 값이 사실이라 믿기도 어렵다. 일단 성능을 재는 것은 불확정성의 원리를 따르기 때문이다. 물론, 아주 미션크리티컬한 서버를 특수한 환경에서 시스템 성능을 측정하여, 해당 값을 항상 유지하도록 관리자에게 권고하려면 그나마 좋은 방편일 수 있겠다.

성능상의 문제로 죽는 웹 서버는 일반적으로 다음과 같은 현상을 지닌다.

1. 평소에는 멀쩡하다.
2. 어느날 좀 이상하다.
3. 새벽에 갑자기 죽어버린다.

혹은,

1. 아침에는 멀쩡했다.
2. 그러다 갑자기 죽었다.
3. 재부팅하니 몇시간 간다.
4. 그러다 또 죽었다.
5. CPU/메모리 점유율은 거의 없다.
6. 혹시 해킹이 아닐까? 하고 생각하기 시작한다.
7. 죽는 시간을 대충 감을 잡는다.
8. 죽기 전 재빨리 재시작하는 프로그램을 짜고 입 씻는다.

와 같은 프로세스를 처리하는 것이 일반적이다.

자 그럼 성능 문제로 인해 죽는 웹 서버가 왜 발생할까? 왜 이 서버들이 어느 순간 갑자기 죽게 되는 것일까.

실제로, 이러한 서버군은 평소에 아무리 값을 잰다고 해도 재어지지 않는다. 그러면 이런 서버들을 어떻게 다루어야 할까? 지금부터 말하는 튜닝 포인트라는 개념이 여기서 등장하게 된다.

1년에도 수십개의 프로그래밍 언어가 새롭게 발표가 되고있지만 사람들에게 호평을 받는 프로그래밍 언어는 불과 1-2개에 불과 하다. ASP도 이런 무수히 많은 언어들 중에서 하나이다.
앞 컨텐츠에서 설명했던 4세대 웹언어라 불리는 ASP, PHP, JSP에 대해서 알아봅시다....

ASP는 MS기반의 웹프로그래밍 언어라 정의를 내린다.NT라는 서버를 기반으로한 웹서버 기술인 IIS을 바탕으로 해서 작동을 하며,MS사에서 나온 MS-SQL과 완벽하게 호완을 한다.
또한 크리스털 리포트등의 기능, 오브젝트의 활용성, 엑셀과의 100% 호환, 등의 MS제품군과의 완벽에 가까운 호완성을 자랑한다. 또한 VB나 VC등의 기술로 제작된 콤포넌트도 활용을 할 수가 있어서 서버스크립트형 언어와 클라이언트 스크립트형 언어의 장점을 고루 갖추었다.

PHP는 UNIX C를 기반으로 하여 나온 멀티프로세싱 기반의 언어이다. UNIX C의 특징을 살려 만들었기 때문에 아파치 서버와 같은 UNIX 호완 서버에서 작동을 하며, 유닉스의 GNU에 맞게 My-SQL을 기본적인 DB로 사용을 한다. 무엇보다 PHP는 서버구축이 거의 무료에 가깝다는 장점때문에 많은 사랑을 받았지만, 보안과 관련된 문제가 많이 대두되는 현재에서는 포트의 보안결핍등의 문제로 인해서 대형 웹 사이트 시장에서는 밀리고 있는 추세이다. 대표적인 보드 시스템으로 제로보드가 있다.

JSP는 JAVA의  플렛폼 기술을 기반으로한 프로그래밍 언어라 정의를 한다. JAVA의 장점인 클래스를 활용한 스레딩 기술로 속도는 느리지만 보안성에 있어서 호평을 받고 있다. 은행이나 금융권의 홈페이지에서 주로 사용하고 있다. 네이버 블로그는 JSP와 JPQ기술이 혼합된 형태라 볼수가 있다. JSP는 ORACLE DB서버에서 주로 사용을 하고 있으며, 최근 JPQ나 Bins 등의 어플리케이션형 자바기술의 지원으로 손쉽게 접근 할 수 있다. 대표적인 보드 시스템으로는 피터보드가 있다.

이 3가지의 웹스크립트언어가 웹시장의 90%이상을 점령하고 잇고, 앞으로도 무궁한 성장을 할 전망이다. 서버기반의 스크립트 언어는 기본적으로 소스가 오브젝트형식의 컴파일을 한번더 거치기때문에 보안성의 측면에서도 효율적이고, 코드의 융통성이 높아 고수준의 웹 어플리케이션 지원에 무리가 없다.

HTML언어 하나만으로도 완벽하다고 느낀 시절도 있었습니다...^^
도대체 근데 왜 ASP를 사람들이 그토록 많이 쓸까욤?ㅋㅋ

SGML (Standard Generalized Markup Language)
이름하여 출판 표준웹언어라 칭하기도 하는 SGML을 기반으로 하여 HTML이 나왔다.
SGML은 출판에서 레이아웃이나 글자사이의 간격, 어렵게 말하면 문서의 마크업 언어나 태그 셋을 어떻게 정의할 것인가에 대한 표준이다.

즉 출판쪽을 생업으로 하시는 분들이 짚고 넘어가야 할 부분이다.
메뉴얼만 1000페이지가 넘는 장엄한 SGML이란 언어에 사람들은 너무나 힘들어 했다.

이런 상황에서 웹이란 매체에 쉽게 접근하고자 HTML이란 언어가 SGML에서 필수적인 태그셋만 모아서 만들어진 것이다.

HTML은 SGML의 단점인 어렵다는 점을 극복하는데 너무나 열중한 나머지 기본적인 디자인만을 제외하고는 표현할 수 있는 규모가 너무나 작았다. 그렇게 해서 기본 HTML을 좀더 효율적으로 사용하기 위해서 나온 것들이 스크립트하던지, 레이어라는 기술들이다.

이런 기술들 만으로 부족해서 사용자들은 기존의 프로그래밍 언어에서 사용되던 기술들을 웹에서도 사용할 수 있는 어플리케이션의 개념을 도입하고 싶어했다. 그래서 C 나 BASIC과 같은 프로그래밍 언어로 작업된 프로그램을 웹에서 사용하는 개념인 CGI기술이 나오게 된것이다. 물론 그 과정중에 HTML을 동적으로 표현해 보려는 3HTML이나 DHTML, SHTML등의 방법론적인 언어들이 나오기도 했지만 CGI를 따를 자가 없었다..

그럼 왜 CGI를 사용하지 않고 사람들은 ASP를 사용할까?
그 이유를 알기 위해서 CGI의 작동원리를 알아본다면. CGI는 서버와 클라이언트의 관계에서 클라이언트가 서버에게 예를들어 3*4라는 질문을 던진다면 서버의 컴퓨터는 직접 자신의 프로세스와 메모리를 사용하여 3*4를 연산한 결과값인 12를 클라이언트에게 전송을 해준다.

이런 관계가 100개 1000개로 늘어난다면 서버의 컴퓨터에서는 엄청난 양의 부하가 걸릴것이다.

반면 ASP는 클라이언트가 3*4를 물어본다면 서버는 클라이언트에게 곱셈을 가능하게 만드는 기술을 전송시켜주고, 클라이언트의 컴퓨터에서 3*4가 연산이 된 결과값인 12가 클라이언트의 요청에 응답을 하게 된다.

이런 차이점이 같은 성능의 컴퓨터에서 회원수 1640명의 커뮤니티를 운영할 수 있는 CGI와 10만명 이상의 커뮤니티를 운영할 수 잇는 ASP의 효율로 나타난다.

즉 메모리와 프로세스같은 필수적인 리소스적인 측면에서 훨씬 우위를 점할 수가 있게되는 것이다.

1세대 SGML에서 파생된 HTML
2세대 HTML의 응용 -DHTML,SHTML에이은
3세대 프로그래밍을 응용한 CGI도 이젠 한물이가고,
4세대라 불리는 서버스크립트 기반의 ASP,PHP,JSP등의 언어가 나온것이다..

ASP가 뭔지도 모르고 클릭해 보신분들은 뭔가염..ㅠ.ㅠ

ASP는 쉽게 말하게 Active Server Pages 즉 동적인 서버 페이지라는 의미를 가지고 있습니다.
Application service provider로 풀어 설명되는 응용서비스 제공자를 의미하지는 않습니다..^^

지금 배우기 시작하면 이미 늦은게 아니냐 하고 생각하시는 분들도 있겠지만...ㅋㅋ

절대 느린것은 아닙니다. 물론 한국의 경우에는 워낙 IT와 관련된 이력들이 많아서 다소 ASP의 활용성에 비해서 사회적 위치가 높은 편은 아니지만, 단순한 ASP가 아니라 조금만 응용시킨다면, 무궁무진한 발전의 가능성을 가지고 있습니다.

외국의 경우에는 이제 겨우 HTML의 단계를 지나 CGI를 활용하는 단계라서 ASP로 만들어진 홈페이지를 구경하기가 쉽지가 않죠.

결론적으로 말하면 열심히 해보세요...ㅋㅋ

오늘은 일단 HTML과 ASP의 차이점에 대해서만 공부해 보겠습니다.

어렵게 보이나요?

쉽게 말해서 우리가 인터넷 브라우저의 주소창에 www.abcd.com/index.html 이라 친다면 abcd라는 컴퓨터에서 index.html 파일을 다운 받아와서 컴퓨터에서 읽히게 됩니다.

왼쪽의 컴퓨터를 클라이언트, 오른쪽의 웹서버컴퓨터를 서버라 보통 말을 하죠.

 HTML: 클라이언트 중심 / 정형화된 소스 / 보안성 없음/게시판 불가능


3년전인가.. 네이버 블로그(http://blog.naver.com/romu.do)에 연재를 하던 ASP관련 기본 강의를
요기로 옮겨왔습니다..^^ 최신 내용이 아니더라도 이해하고 봐주시길...