자바스크립트 재발견

최근에 자바스크립트를 다시 공부하고 있다.
정확히 말하면 자바스크립트 책을 제대로 본게 거의 처음인거 같다.
자바스크립트 언어 자체에 대해서 그다지 신뢰하지도 않고, 맘만 먹으면 언제든 쉽게 다가갈수 있을꺼란 생각에서 얕잡아 봤다고 해야 옳은거 같다.
그동안 자바스크립트는 일관성이 없었다!
좋게 얘기하면 똑똑한 브라우저와 맡물려서 융통성이 너무 좋았던 것이고, 단일화된 국내 환경에서 IE환경에 맞추려다보니 대강 짜맞춰도 잘 돌아갔던 이유이다.
또한 스크립트의 신뢰성이랄까? 언어 자체가 갖고 있는 확장성이 그다지 좋지 않았기 때문에 비즈니스 로직을 모두 서버에서 구성했었다.

최근에 web2.0의 추세로 자바스크립트를 다시 돌아본다.
정확히 얘기하면 나의 주업무가 인터넷뱅킹으로 바뀌면서 웹프로그래밍으로 방향이 바꼈기 때문일 것이다. 이제 나는 진짜 웹프로그래머가 된 것이다.
그래서 책을 두권 샀다. 그 동안 사고 싶어도 맘에 드는 책이 없어서 고민했었는데, 마침 따끈따끈한 책 두권이 나와서 바로 구매했다.
책은 아주 맘에 들었고, 자바스크립트를 제대로 공부하고 있다.

아마도 그동안 IE의 독보적인 위치와 표준을 따르지 않는 행태로 인해서 자바스크립의 발전에 해악이 있었음에 틀림없다. 계속해서 표준 스펙들과 버전들이 속속들이 나오고 있고, 그것을 제대로 준수하는 괜찮은 브라우저들이 쏟아져 나오고 있지만, 아직까지도 IE의 울타리를 벗어나기는 쉽지 않아 보인다.
그래서 자바스크립트를 제대로 구현하기가 아직도 어렵다.

하지만 예전에 비해서는 그 형태가 잡혀가고 있는데,
아마도 W3C와 ECMA의 표준제정, Firefox의 힘이 가장 크지 않았나 싶다.
IE의 고집이 꺽이는 모습이 곳곳에서 많이 보이고 있기 때문이다. - Event 관련 함수들에서 IE가 ECMA 표준들을 울며 겨자 먹기식으로 따르고 있다. 하지만 하위 버전과의 호환성으로 인해서 아직도 애매하다.

자바스크립트... 괜찮은 언어이다.
웹을 발전시킨 일등 공신중에 하나이며, 앞으로 앞을 이끌어갈 최강의 전사임에도 두 말이 없다.
어떻게 자바스크립트가 객체지향언어라고 하는지 늘 의구심이 들었었는데... 100% 순수한 객체지향은 아닐지라도 그 한계를 생각한다면 아주 훌륭한 OOP임에는 틀림없다.

바램이 있다면 이왕 공부하기로 한거 IE와 Firefox가 사이좋게 잘 지냈으면 좀 편해질텐데...

P.S 1) 이 글을 쓰면서 IE vs. Netscape의 브라우저 전쟁으로 인해 항상 cross script을 짜야 했던 시절이 생각난다. 그때는 제발 한넘이 빨리 이기길 바랬었는데... ^^
2) IE에서 스크립트를 분석하기 용이한 툴이 있어서 소개한다.
그냥 인터넷에서 "Internet Explorer Developer Toolbar" 라고 치면 MSDN의 다운로드 사이트로 연결된다.

올해 예상되는 14가지 보안 트렌드

올해 MS의 새 운영체제 윈도 비스타가 국내에 정식 출시되고, 웹2.0 기반의 서비스가 활발하게 공급될 것으로 예상되는 등 IT분야의 새로운 변화가 일어날 것으로 보인다. 아울러 VoIP와 인터넷폰 등 모바일 기기의 성능 향상도 급속도로 이루어질 것으로 전망된다. 이러한 환경의 변화는 새 환경을 노리는 보안 위협과 궤를 같이해 사용자에게 다가설 것이다. 올해 예측되는 보안 이슈를 14가지로 구분해 분석해 본다.


MS 윈도 비스타 상의 보안
MS 인터넷 익스플로러7과 보안
본격적인 웹2.0 시대 돌입과 보안
모바일 기기용 악성코드
VoIP와 인터넷 폰 상의 보안
사회 공학적 해킹
피싱 본격화
은폐 기법 무력화 vs 우회 기술
전통적 바이러스 제작 기법 유행
개인 정보 유출로 파생될 이슈 증가
악성코드와 혼합된 스파이웨어 기승
웹 사이트 공격 지속적 증가
애플리케이션 취약점 위협 증가
Mac OS X 보안 위협 증가

출처명 : 경영과 컴퓨터 [2007년 2월호]

히말라야 현자의 모래시계와 시간 다스리기

난 시간이 모래처럼 손에서 빠져나가 되돌아오지 않는다는 것을 배웠지. 시간을 현명하게 쓰는 사람은 풍성하고 생산적이고 만족스러운 삶을 보상받네.
'시간을 다스리는 것은 삶을 다스리는 것'이라는 원칙을 배우지 못하면, 자신의 엄청난 잠재력을 깨닫지 못하지.

시간은 멋진 잣대야. 특권을 가졌든 아니든, 텍사스에 살든 도쿄에 살든 우리는 모두 하루 24시간을 사네. 이 시간을 이용하는 방식에 따라 '행복한 삶을 일구는 사람들'과 '그냥 하루하루 사는 사람들'로 나뉘게 되지.
로빈 샤르마의 '나를 발견한 하룻밤 인생수업' 중에서 (더난출판, 190p)



시간을 다스리는 삶.
누구에게나 공평하게 주어진 '하루 24시간'의 시간을 제대로 다스리는 사람만이 행복한 삶을 살아갈 수 있다.
시간을 현명하게 다스리기 위해서는 우선 시간의 '소중함'을 명확히 인식해야 한다. 히말라야의 깊은 산중에 사는 수도자들이 지니고 있다는 모래시계. 그 현자들은 어릴 때부터 모래시계를 지니고 살아간다고 한다.
"우리는 무소유의 청빈하고 소박한 삶을 살지만, 시간을 존중하며 시간이 흐르는 것을 인식한답니다. 이 작은 모래시계는 우리가 언젠가는 죽는 존재임을 매일 일깨워주지요. 우리에게 목적을 향해 나아가되, 온전하고 생산적인 나날을 살아가라고 말해주지요."

우리가 모래시계를 바라보며 모래처럼 손에서 빠져나가 되돌아오지 않는 시간의 소중함을 인식한다면, 하루 하루, 한 시간 한 시간을 바라보는 생각이 바뀔 것이다.

시간의 소중함을 인식했다면 이제 시간을 '계획'해야한다. 하루의 계획을, 일주일의 계획을, 한 달의 계획을 미리 세워놓는 것. 한 시간 일찍 출근해 그날의 계획을 짜고, 일요일 저녁에 한 시간을 내서 다음주의 계획을 정리해보는 것. 이렇게 계획에 시간을 '투자'하는 것이 반드시 필요하다.

시간을 현명하게 다스리는 사람은 시간계획을 통해 무엇이 중요한지, 무엇이 중요하지 않은지 인식하고, 주체적으로 '선택'할 수 있게 된다. 그리고 이런 과정을 통해 하고 싶고 또 해야하는 일을 할 수 있는 시간을 '만들어 낼' 수 있다.
그래서 항상 정신없이 바쁜 모습이 아니라 '여유'있는 모습 속에서 시간을 생산적으로, 의미있게 사용할 수 있게 된다. 행복한 삶으로 가는 길은 바로 여기에 있다.

"예병일의 경제노트(2007/05/15)" 의 것을 마치 내것인냥 ... 써본다.

HTTP/1.0 vs. 1.1

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로의 성능적인 면과 시간의 최소화에 중점을 두고 있다.

출처 : [직접 서술] RFC 1945 - Hypertext Transfer Protocol -- HTTP1.0 RFC 2616 - Hypertext Transfer Protocol -- HTTP1.1

참고 : 상혁아빠 블로그 - HTTP Status Code

참고 : TONG - HTTP Status Code