오늘은 날씨가 좋군요 ^^

상쾌하기도 하고~ 제가 12층에서 근무하는데 전경이 좋습니다 ^^

Data URI Support : Windows Internet Explorer 8

오늘은 이걸 알아보도록 하겠습니다.

먼저 IE8의 랜더링 화면을 보려면 Tool메뉴 - Developer Tools - View - Change Compatibility - Mode에서
Standards(Internet Explorer 8)을 선택해야 합니다. ㅎㅎ 잠시 팁이였구요.

Data URI... 과연 이것은 무엇일까요? 다들 아시나요?? 저는 이야기만 들어봤을뿐 실제로 사용해 본 적은 없었습니다.

그래서 이기능이 IE에서 지원이 안되고 있었는지 조차 별 관심이 없었던거죠.. 화이트페이퍼를 보면서 "이거 원래 안되었었나?"라는 의문이 들었죠. 근데 원래 지원안했답니다. ^^

테스트를 해보니 FF 2, FF 3, Safari 3, Opera 9.x 에서는 다 지원되는군요... 역시 IE는 외톨이였나봅니다. ^^

잠시 딴대로 이야기가 샜었는데.. 왜 Data URI를 사용할까요? MS에서 제공한 화이트페이퍼에는 이렇게 정의하고 있습니다.

"css나 image와 같은 작은 외부 자원들를 웹페이지에 직접적으로 삽입할 수 있게 한다"라고 되어있습니다.

그럼 왜 직접 삽입해야할까요? 이유는 보안입니다. 즉 이미지나 css등의 경로를 웹페이지에 적어주는 방식(<img src="/xxx/xxx.jpg" />)은 URI가 노출되어 해당 서버의 디렉토리 구조를 노출하게 됩니다. 또한 css의 경우도 마찬가지겠지요. 그럼 여기서 의문이 생기죠... data URI를 사용하면 어느정도까지 보안을 강화해 주는걸까요?

제가 테스트 해본바로는
1. URI 숨김으로 인한 서버의 디렉토리 구조 감춤
2. 웹페이지에 직접 해당 리소스를 넣음으로서 http connection을 통해 이미지를 가져오는 일이 없음, 즉 이미지를 별도로 다운로드하지 않음.

2번에서 알수있듯이 이미지자체를 웹페이지에 넣다보니 웹페이지 사이즈가 커짐을 알 수 있습니다. 당연하겠죠?

아래 그림은 네이버 로고를 Data URI로 넣은 모습입니다.

아래의 그림은 Data URI와 <img>를 함께 사용한 것입니다.

위 그림 두개에서 자세히 보셔야 할부분은 FireBug의 화면중 Net이란 곳이구요... Net은 실제 웹상에서
데이터가 network를 통해 브라우져가 해당 리소스를 다운받았다는 것을 표시해줍니다.

1번의 그림의 경우 이미지 다운이 안된것으로 표시가 되었고, 2번의 경우 그림이 다운된 것으로 표시가 되었습니다.

MS에서는 Object / Img / Link / Css 엘리먼트만을 지원한다고 하는군요.

백문이불여일견... 테스트한 html을 첨부하니 다운받으셔서 직접 테스트 해보시는게 가장 좋을것 같습니다.

테스트 파일 :




posted by blankus

오랜만에 포스팅을 하는 것 같습니다.

그동안 너무 방황하며 살았던것 같구요... 이제 따스한 봄(?)이 저멀리서 다가오고 있으니 마음도 추스리고

열심히 또 블로그질을 해야겠습니다.

그 시작으로 IE 8 beta 1이 선보였는데, 무엇이 어떻게 바뀌었는지를 알아보도록 하겠습니다.

1. Data URI Support
2. HTML Improvements and ACID2
3. Improved Namespace Support
4. DOM Core Improvements
5. CSS 2.1 Compliance
6. Selectors API
7. Circular-Memory-Leak Mitigration
8. Versioning and Cross-Document Interaction
9. Better AJAX development
10. Versioning and Internet Explorer Modes
11. Improved Protected-Mode API Support
12. Platform Performance Improvements

이 순서로 진행할 예정입니다.

posted by blankus

새해복 많이 받으세요 ^^

오랜만에 포스팅을 하는 것 같습니다. 이런 저런 일로 바쁘게 지내다 보니 한참을 잊고 있었네요..ㅎㅎ

오늘은 간만에 반가운 소식을 전해볼까 합니다. 이미 다들 알고 계실지도 모르겠지만..

Ajax의 XHR통신중 크로스 도메인이 상당히 불편해 하고 있는걸로 알고있습니다. 허나 W3C에서 이를 공식적으로 지원하기 위해
움직이고 있군요. http://www.w3.org/TR/access-control/ 이곳을 보시면 자세한 설명이 나와있으니, 참고하시면 되겠습니다.

허나 영어이기때문에.. 조금은 난해할 수 도 있지만, 저희는 글보다는 코드를 주로 보지 않습니까? ㅎㅎ

그럼 오늘은 이 기쁜(?)소식을 짧게 전하는 것으로 마치겠습니다.

posted by blankus

추석연휴는 잘 보내셨나요? ㅎㅎ 저는 조부모님댁이 서울이라... 회사서 휴일당직도 하고, 휴일같지 않은 휴일을 많이 보냈답니다.ㅎ

오늘은 자바스크립트 하이잭킹에 대해서 소개하겠습니다. Hijack이란 단어는 "강탈하다", "뺏다"의 뜻이 있습니다.
단어에서 느끼듯이 주제는 그러합니다. ^^. 이번 글은 www.fortifysoftware.com에서 제공한 pdf의 내용이며,
오역이 있더라도 잘봐주세요. 그리고 중요치 않다고 생각되는 부분은 과감하게 생략토록 할것이고, 문장의 매끄러움을 위해 의역도 포함했습니다.

Javascript Hijacking

요약

Ajax어플리케이션이라 불리우는 리치 웹 어플리케이션들은 데이터 전송기술로서 자바스크립트를 사용하여 만든다. 이번 지면에서는 제목처럼 자바스크립트 하이잭킹, 즉 취약성에 대해서 다룬다.
공격은 웹브라우저의 강제 SOP(Same Origin Policy)를 우회하는 <script>태그를 사용하여 시작된다.
전통적인 웹어플리케이션들은 취약하지 않았다. 왜냐하면, 과거의 것들은 데이터 전송기술로 자바스크립트를 이용하지 않았기 때문이다.

우리는 유명한 12개의 Ajax프레임워크를 분석했다.[ 서버사이드용 4개 : DWR(Direct Web Remoting), Atlas(ASP.NET Ajax), xajax, GWT(Google Web Toolkit), 클라이언트용 라이브러리 8개 : PrototypeJS, Script.aculo.us, Dojo, Moo.fx, jQuery, YUI, Rico, MochiKit]  
위의 것들중 유일하게 DWR 2.0만이 자바스크립트 하이잭킹을 막기위해 구현한 것이 존재했다. 대부분의 프레임워크들은 어떠한 보호장치도 제공하지 않았고, 그들의 문서에서 조차 보안에 관련된 내용을 언급하지 않았다.

우리는 두가지의 완화법에 대해서 논의할 것이다. 악의 있는 요청을 줄이는것과 자바스크립트를 직접실행하는 공격자에 대한 방어가 그것이다.

1. 소개
비록 'Web 2.0'이란 단어가 정확한 정의를 가지고 있지는 않지만, 최근엔 일반적으로 두가지로 사용되고 있다. 첫번째는 'Web 2.0'이 웹 어플리케이션으로 하여금 사회적 상호작용 또는 일반적 합의점을 제공하는 것이고 두번째는 웹 프로그래밍 기술이 풍부한 사용자의 인터페이스를 이끌도록 제공하는 것이다.
이러한 기술들이 때로는 Ajax라는 이름으로 구현되고 있다. 여기서는 자바스크립트 하이잭킹의 단어처럼 취약성에 대해서 논의할 것이다.  이것은 많은 리치 웹 어플리케이션에 의해 사용되는 데이터 전송기술을 이용하는  공격이다. 자바스크립트 하이잭킹은 비인증 공격자가 생성된 매쉬업중 하나를 사용하여 취약한 웹 어플리케이션으로부터 중요 데이터를 읽을 수 있도록 허용한다. 이러한 취약점은 이미 논의되었지만 웹프로그래머들은 이러한 문제점을 좌시했고, 심지어 많이 알려진 이 단어(하이잭킹)조차 모르고있다.

자바스크립트 하이잭킹은 널리 알려진 취약점의 다른 형태로 변형된다 : cross-site request forgery.
cross-site request forgery 공격은 취약한 웹사이트에게 HTTP Request를 하나 또는 여러개를 submit할때 공격이 시작된다. 일반적은 cross-site request forgery 공격은 데이트 무결점을 훼손시킨다. 이는 공격자에게 취약한 웹사이트의 저장된 정보를 수정할 수 있는 능력을 준다.

취약한 웹사이트는 이미 많은 곳에 존재한다. 자바스크립트 하이잭킹에 대해서 주장한 사람들중 하나인 Jeremiah Grossman은 Gmail의 취약성을 발견했고, 구글메일은 이문제를 수정했다.

posted by blankus

얼마전에 PrototypeJS가 1.6.0_rc0 버전이 공개되었습니다.
홈페이지에 공개된 내용은 간략하게 되어있어 어떤면이 변했는지 감으로만 알 수 있을뿐, 직접 코딩해보지 않으면 알 수 없는 법이므로 어떻게 달라졌는지 알아보도록 하겠습니다.

var Prototype = {
  Version: '1.6.0_rc0',
  Browser: {
    IE:     !!(window.attachEvent && !window.opera),
    Opera:  !!window.opera,
    WebKit: navigator.userAgent.indexOf('AppleWebKit/') > -1,
    Gecko:  navigator.userAgent.indexOf('Gecko') > -1 && navigator.userAgent.indexOf('KHTML') == -1,
    MobileSafari: !!navigator.userAgent.match(/iPhone.*Mobile.*Safari/)
  },
 ...........
}

if (Prototype.Browser.MobileSafari)
  Prototype.BrowserFeatures.SpecificElementExtensions = false;


우선 처음부분에서 달라진건 역시 버전이군요 ^^; 그리고 밑에 보면 모바일사파리라고 해서 아이폰에 대비한 모습도 보이는군요. 이제는 모바일 디바이스도 지원해야하는 세상이네요..ㅎㅎ 허나 제가 아이폰이 없는관계로 테스트는 --;; 못하겠습니다.

그다음에 크게 바뀐 것중 하나가 Class 쪽입니다.
기존에는 단순하게
var Class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);
    }
  }
}
이와 같은 형태였으나, 지금은 확 바뀌었군요. Class 관련 전체 코드는 아래와 같습니다.

var Class = {
  create: function(parent, methods) {
    if (arguments.length == 1 && !Object.isFunction(parent))
      methods = parent, parent = null;

    var method = function() {
      if (!Class.extending) this.initialize.apply(this, arguments);
    };

    method.superclass = parent;
    method.subclasses = [];

    if (Object.isFunction(parent)) {
      Class.extending = true;
      method.prototype = new parent();

      parent.subclasses.push(method);

      delete Class.extending;
    }

    if (methods) Class.extend(method, methods);
    method.prototype.constructor = method;

    return method;
  },

  extend: function(destination, source) {
    for (var name in source) Class.inherit(destination, source, name);
    return destination;
  },

  inherit: function(destination, source, name) {
    var prototype = destination.prototype, ancestor = prototype[name],
     descendant = source[name];
    if (ancestor && Object.isFunction(descendant) &&
        descendant.argumentNames().first() == "$super") {
      var method = descendant, descendant = ancestor.wrap(method);
      Object.extend(descendant, {
        valueOf:  function() { return method },
        toString: function() { return method.toString() }
      });
    }

    prototype[name] = descendant;

    if (destination.subclasses && destination.subclasses.length > 0) {
      for (var i = 0, subclass; subclass = destination.subclasses[i]; i++) {
        Class.extending = true;
        Object.extend(subclass.prototype, new destination());
        subclass.prototype.constructor = subclass;
        delete Class.extending;
        Class.inherit(subclass, destination.prototype, name);
      }
    }
  },

  mixin: function(destination, source) {
    return Object.extend(destination, source);
  }
};

무척이나 많이 바뀌었네요. 여기서 소스를 하나하나 뜯는것 보다, 바로 써먹을 수 있는것에 초점을 두겠습니다.
PJS 사이트에 예제가 하나 나와있긴하나 미완성 예제(제생각에 ^^)라 판단되어 조금 덧붙여봤습니다.
<script>
var Animal = Class.create({  
 initialize: function(name) {    
  this.name = name;  
 },  
 eat: function() {    
  return this.say("Yum!");  
 },  
 say: function(message) {   
  return this.name + ": " + message;  
 }
});

// subclass that augments a method
var Cat = Class.create(Animal, {  
 eat: function($super, food) {    
  if (food instanceof Mouse) return $super();    
  else return this.say("Yuk! I only eat mice.");  
  }
});

var Mouse = Class.create(Animal, {});
var Dog = Class.create(Animal,{})

var tom = new Cat('Toml');
var jerry = new Mouse('Jerry');
var goopy = new Dog('Goopy');

alert(tom.eat(jerry));
alert(tom.eat(goopy));

</script>

실행결과는 ? 그렇습니다. 첫번째 alert에는 Yum!, 다음 alert에는 Yuk! I only eat mice 라고 나옵니다.
여기서 중요한건 무엇일까요? 바로 메소드 오버라이드(override)가 가능하다는 것입니다. 오버라이드가 기본적으로 가능하려면,
클래스사이의 관계 즉, 수퍼클래스와 서브클래스의 개념을 지원해야 가능하다는 것이지요. 기존 1.5.1에서 클래스 상속이라고 했던것들은 모두 기존 메소드들의 대체였다면, 이번 버전에서의 상속은 같은 이름의 메소드가 있을경우 오버라이드 시키고 있습니다. PJS가 좀더 OOP에 한발짝 다가섰군요.

해당 소스의 자세한 분석은 다음에 하기로 하고 계속 되는 포스트에는 사용법에 맞춰 작성될것입니다.
요즘 하는일이 하도 많아서 언제쯤 분석하고 올릴 수 있을지 모르겠지만 ^^; 언젠가는 하겠죠? ㅎㅎ

posted by blankus

장마가 끝나고, 더위가 시작되고, 말복도 지나갔건만 아직도 밖엔 비가오고 불볕더위가 기승을 부리며 밤잠을 설치게 하고있습니다. 쉽게 힘든 하루하루를 보내고 있습니다..ㅎㅎ
오늘은 좀 시간이 되서 포스트를 하나 할까 합니다.

제목에서처럼 "선택과 효율"입니다. 말뜻에서 보이듯이 잘사용하면 좋지만 잘못사용하면 독이되는 것들입니다.

다른프로젝트에서 효율적인것이 자신에게 적용하면 독이될 수 있음을 명심하시고 , 선택은 여러분의 몫입니다.

자바스크립트 파일을 하나의 파일로 합치기

대부분 Ajax어플리케이션들은 수많은 js를 포함하기 마련입니다. 허나 다른 리소스들(이미지와 같은)은 http connection이 모두 사용되어 다운로드를 하지만 유독 js만은 하나의 커넥션으로만 진행되게 됩니다. 즉, 하나씩 다운로드하여 파싱이되고 메모리에 적재됩니다. 그리하여 js 를 하나로 합쳐서 배포하면 그만큼의 시간단축이 되므로 합쳐봅시다.

이번에 알려드릴 툴은 다들 아실지도 모르겠지만 bash쉘을 이용하는 것입니다. bash의 cat을 사용하면 많은 js들을 손쉽게 하나의 파일로 생성할 수 있습니다.

cat script1.js script2.js script3.js > all.js

이렇게만 해주시면 끝입니다 ^^; 너무 쉽나요? 그렇다면 윈도우에서는 어떻게 해야할까요?
cygwin이라는  오픈소스를 이용하면 됩니다.
www.cygwin.com에서 패키지를 다운받으셔서 설치하시면 bash쉘의 명령어를 사용하실 수 있습니다.
그럼 하나로 합쳐서 배포했는데 js를 수정하려면 all.js를 수정해야할까요? 아닙니다.
아래의 화면을 보시죠

[배포용]
<script src="all.js"></script>

[개발용]
<!--script src="all.js"></script-->
<script src="script1.js"></script>
<script src="script2.js"></script>
<script src="script3.js"></script>

이런식으로 관리하시면 되겠지요.

그리고 팁으로는, js를 합치실때는 반드시 개별파일의 마지막 한줄이 있어야 합니다. 만약 없다면 파일들이 중첩되는 부분이 생겨 오류를 발생시킵니다.



압축툴로 자바스크립트 압축하기
예전에  js 어플리케이션을 하다보면 둘중에 하나는 포기해야했습니다. 충분한 주석을 달아서 나중에 유지보수를 편하게 하느냐, 아니면 주석을 제거하여 파일사이즈를 줄여 다운로드를 조금이라도 빠르게 할것이냐.
하지만 이제 그런고민은 필요없을듯 합니다.
dojo툴킷에 포함된 압축툴을 사용하시면 js에 포함된 주석은 알아서 제거가되고 js를 압축해주기 때문이죠.
http://alex.dojotoolkit.org/shrinksafe/ 이곳에서 다운로드 하시면 되고, 자세한 사용법또한 있습니다.
그리고 한가지, 반드시 jdk 1.4이상이 있어야 한답니다 ^^
java -jar custom_rhino.jar -c all.js > all_comp.js 2>&1
이렇게 해주시면 all_comp.js라는 파일이 생깁니다.


브라우져 자바스크립트 cache 문제
작업하시다 보면 브라우져 js가 캐시되어 새로운 js를 서버에 올렸음에도 불구하고 새로운 js가 적용되지 않는 문제점이 있습니다.
보통 <script src="script1.js></script> 이렇게 사용합니다. 허나 아래와 같이 사용하시면 이러한 문제는 없어집니다.

처음에는 이렇게 해주시고,
<script src="script1.js?v=001"></script>

다음에 새로운 js를 서버에 올리셨으면
<script src="script1.js?v=002"></script>
이렇게 해주시면 브라우져는 새로운 js를 다운받아 실행하고 기존에 받아두었던 js는 더이상 cache시키지 않습니다. 이유는 브라우져는 script엘리먼트에 src속성의 값을 하나의 값으로 판단하기때문에 js다음에 붙는 더미들을 포함하여 기억하고 있는것입니다. 하여, v=001과 v=002가 붙은 js를 다른 파일로 인식하여 새로 받는 것이지요.

오늘은 여기까지만 하도록하겠습니다. 다른 팁들도 몇개있는데 나중에 다시 소개하도록 하겠습니다

posted by blankus

오늘도 무더위가 기승을 부리는군요;; 아직 장마철인데..이럽게 덥다니...OTL
이번 포스트는 신기한(?)것을 보여드릴려구요..ㅎㅎ
보통 Ajax를 사용할때 데이터를 json을 많이 사용하곤 합니다..xml보다는 경량이고 js에서 object로 인식이
되기때문에 사용성도 좋습니다.

그러나 흠이라고 한다면 간단한 json정도야 눈으로 보고 바로 알 수 있지만 길이가 길거나 복잡한 json이라면,
필요한 값을 한눈에 알아보기란 쉽지가 않습니다. 그래서 요런것이 등장했나 봅니다..ㅎㅎ

(DEMO)

시연은 직접 사이트를 이용하심이 좋겠습니다 ㅎㅎ 저것을 분석해서 이번프로젝트때 한번 써먹어봐야겠군요.
이번 포스트는 참으로 짧군요..ㅎㅎ 팁이다보니 정말 팁만 주네요 --;

소스 :

mktree.js

posted by blankus

기분좋은 월요일 아침입니다~ 오늘은 일찍출근해서 하나 포스트하고 업무를 시작하려고 합니다. ㅎㅎ
이번주제는 제목처럼 "왜 자바스크립트 파일을 하나로 합쳐서 배포해야하는가?" 라는 주제로 포스트를
해볼까 합니다. 여러분들은 알고 계신가요? 사실 많은 사람들이 좋다좋다~ 하니까 따라하고는 있지만 정확한 이유는 모르시지는 않은가요?
설령 그렇다 해도 걱정은 하지 마세요. 이제부터 알면 되잖아요 ㅎㅎ

이것을 이야기 하기전에 일단 Http Connection의 갯수부터 알아볼 필요가 있습니다.
왜? Browser가 서버와 통신하는 방법이 Http 이기 때문이죠. 브라우져는 특별한 애드온(activeX와 같은)이
없다면 기본적으로 Http를 사용하여 서버와 통신합니다. 그옛날 HTTP 1.0 일때는 http connection의 갯수가
4개였습니다. 허나 지금의 HTTP 1.1은 2개로 줄었죠. 혹자는 이렇게 말합니다. 줄일거라면 그냥 1개로 하지
2개는 뭐야?라고.. ㅎㅎ 저도 의문이군요.. http connection이 하는역할은 단순합니다. 서버와의 통신라인
갯수를 의미하고 서버로부터 정보를 받는거죠. 쉽게 서버와 클라이언트간의 파이프라인이라고 할까요?
이해되시죠? 좀더 쉽게 한마디로 정의하면 "클라이언트는 동시에 라인(http connection)을 두개이상 사용할 수 없다" 입니다.
이것과 자바스크립트 파일을 합치는거랑 무슨관계냐구요? 다음의 그림을 봅시다.

파이어버그로 js가 로드되는 모습을 덤프한 이미지입니다. 보시다 시피 파일이 여러개일때는 http connection의 갯수와는 상관없이 하나가 로드가 되어야 다른 하나를 로드합니다.왜 이런모습을 보일까요? 그이유는 제가 가장 먼저 포스트한 "Javascript에서의 runtime"부분에 보면 나와있습니다. 바로 브라우져의 자바스크립트 엔진이 <script>단위로 읽고 해석하고 로드하기 때문입니다. 즉 http connection는 의미가 없어지는 부분입니다. 그렇다면 자바스크립트 파일을 제외한 나머지는 어떤 모습일까요?
아래의 이미지를 봐주세요.

거의 동시에 모든파이을 받고 있습니다. 심지어는 파일을 받고있는 동안에도 다른하나의 파일이 받아지는 모습도 볼수있습니다. 첫번째 그림과는 사뭇 다른 모습이지요.

어떻습니까? 왜 자바스크립트의 파일을 하나로 합쳐서 로드해야하는지, 왜 그게더 효과적일 수 있는지 이유를 아시겠습니까? 그렇다고 모든 js 파일을 하나로 합쳐서 로드한다는 것은 상황에 따라서 안좋을 수 있습니다.
상황에 맞게 적절히 배합해서 사용하는게 가장 좋은모습이죠.
여러분들도 누군가가 무엇이 좋다고 한다면 한번쯤은 스스로 테스트를 하셔서 사용하시는게 좋을것 같습니다. 월요일 아침이라 부담이 적은 포스트를 하고 갑니다..ㅎㅎ

----------------------------------------------------------------------------
아래 커멘트에 AD님이 올려주신 내용을 참고하여 포스트를 이어보겠습니다. - 2007.07.22

--AD님의 글
http connection은 여러개가 생성될 수 있습니다.
만약 한 페이지에 html 1개+js 2개가 있다면 connection은 2개만 생성되는게 맞습니다만, html 1개+gif 9개가 있다면 connection은 10개가 생성됩니다.
browser 내부에서는 별도의 파일 다운로드 관련 thread(일의 단위)가 생성되며 따라서 파일은 병렬적으로 다운로드 됩니다. js는 왜 2개만 생성되냐면, 궁극적으로 js parser와 관련된 일이며, js parser가 병렬처리가 가능한 구조로 되어진다면, js파일도 여러개를 동시에 다운로드 받을 수 있게 됩니다.
--

여기서 의문점이 있습니다.
1. html갯수 + 이미지의 갯수 = 커넥션의 갯수
  --> 이미지가 총 100개라면 커넥션의 갯수가 총 101개가 되는 논리입니다만, 정확한 근거가 무엇인지 궁금합니다.

2. browser 내부에서는 별도의 파일 다운로드 관련 thread(일의 단위)가 생성
  --> winInet에 의해 서버당 http connection의 갯수가 제한됩니다.
Microsoft 참조글


오해의 소지가 있는것 같아 파이어버그외에 다른툴로 체크를 하였습니다(파이어버그는 정확한 시간이 나오지 않아 오해의 소지가 있습니다. 이것을 덤프한 제잘못이기도 하지요)

<iwatch 화면>

<firebug 화면>

캡쳐환경은 쿠키 및 임시파일 모두 삭제하고 테스트하였습니다.
보시다시피 파이어버그의 경우 시간의차이가 얼마나지 않을경우 같은 라인에 뿌려주고 있으며, iwatch의 경우는
아주 자세한 초까지 계산해주고 있습니다.

위 그림중에 빨간색으로 사각형체크가 되어있는 부분은 동시에 connection이 이루어진 startTime입니다. 빨간색사각형 체크가 안되어 있는 상단부분은 보시면 아시겠지만 logo.gif가 상당히 큰 파일이므로 커넥션 하나를 물고있으므로 이 logo파일이 로드되기전까지 1개의 커넥션이 계속 돌면서 작은파일들을 처리하다가 logo파일이 다 로드된 시점에서는 커넥션이 다시 2개가 되어 2개씩 받아짐을 확인할 수 있습니다.

위 내용은 ajaxian에서도 소개가 된 내용이며, 원 블로그글은 서버당 http connection의 갯수가 제한적이라 이를 해결해보고자 했던 내용(cname으로 해결)이 주였습니다(ajaxian 소개글 | 원블로그의 글)

위에서도 언급했지만 AD님께 어떠한 근거와 논리로 저러한 내용을 써주셨는지 궁금하며, 근거와 논리가 있으시면 다시한번 글을 남겨주시기 바랍니다.

------- 2007.07.23
AD님이 새로운 글을 트랙백을 통해 알려주셨습니다.
허나 그글을 읽고 아래와 같은 의문점이 드는군요. 물론 제글에 대한 명확한 반박근거도 없습니다.

테스트 url : htttp://www.blankus.net/test.html

1. tcpview를 통해 체크하신것이 전부인지요?
2. 작은 이미지라서 http connection이 순식간이라 그렇게 보인게 아닌가 한다구요?
3. 분명 AD님의 글에 의하면 html+이미지 갯수 = 커넥션 갯수라고 했는데 말을 바꾸셨군요?
4. IE 브라우저가 wininet을 이용하지 않는다구요?
5. FF는 또 다른 커넥션구조를 갖는다구요?
6. 그럼 두 브라우져는 W3C에 규정되어있는 HTTP 1.1에 어긋나게 설계가 되어있으며 표준을 준수하지 않는다는 말이군요?

위에 대한 답변을 제가해볼테니 만약 아니라고 생각하시면 조목조목따져 하나씩 반박해주시기 바랍니다.

1. 브라우저는 인터넷에서 리소스를 다운받을때 activex가 아닌이상 기본적으로 http 프로토콜을 통하여 처리가 됩니다. 말인즉, http connection이 발생하고 그 파이프라인을 통해 정보가 다운되는 것입니다. 그리고 tcpview를 근거로 제시하셨는데, 저또한 그프로그램으로 정보를 추출해본결과 아래와 같습니다.

보시다 시피 ie의 로컬소켓은 2개만 생성되었습니다. 근데 AD님이 포스트한것을 보면 분명 여러개이구요. 단언컨데 분명 Reg값이 2보다 큰값으로 되어있을겁니다. http 1.1규약에 의하면 http connection의 갯수는 분명 서버당 2개로 제한되게 하고 있습니다.다른 브라우저 또한 마찬가지이고요.

2. 작은이미지라서 커넥션이 빨리끊기고하여 2개씩 보일 수 있다구요? 참으로 어리석은 생각입니다.

보시다 시피 IE의 iwatch에서의 그림입니다. 시작되는 시간을 보시죠 처음부분 html이 다받아지고 동시에 두개의 다운로드가 시작되는 2번과 3번을 제외하고 동시에 시작하는 화면이 있나요? 자세히 시간을 비교해보세요... 거의 동시에 시작은되나, 2,3번을 제외하곤 작은 타임의갭이 있습니다.

FF의 firebug입니다. 정확하게 두개씩 다운받고 있는것을 보실수가 있습니다. 설마 저 그래프를 동시에 다운받기시작하여 저런 그래프가 생겼다고 말씀하실분은 없겠죠? 역시 firebug는 시간이 나오지 않아 동시에 시작한것처럼 보이는군요, 그래도 파이프라인이 두개라는건 확실하구요.

3. html+이미지 갯수 = http connection갯수 라는 논리의 근거를 제시해달라고 했더니 트랙백 글에선 말을 바꾸시던데 왜 그랬나요? 실제로 테스트해보니 생각과는 달랐나요? http 1.1의 규약처럼 reg값을 기본으로 변경(2개)하여 테스트해보세요. 그래도 이런 생각을 하게될까요?

4. IE가 wininet을 이용하지 않는다는 근거는 어떤것인가요? 자료를 첨부해주세요.

5.FF가 다른 커넥션구조를 갖는다고 어디에 누가그러던가요? 자료를 첨부해주세요

6. 4번과 같은 맥락인데, http connection의 갯수와 관련 IE가 W3C의 HTTP 1.1의 기준에 미달한다는 자료를 첨부해주세요.


posted by blankus

PJS를 이용해서 프로젝트를 진행하던중에 이상한 현상을 발견하게되었습니다.
게시판 페이징을 하면서 페이지번호 Element에 Event.observer를 할당하여 사용하고, Event가 필요없어지면 Event.stopObserving을 하는데, 여기서 메모리 누수가 발생하고 있었습니다.

일반적으로 생각하는건 아래와 같습니다.
1. 이벤트 설정 (Event.observe)
2. 이벤트 발생 (click...)
3. 이벤트 해지 (Event.stopObserving)
4. 이벤트 메모리 해지

하지만 4번이 제대로 되지 않는 현상이 발생하여 추적에 추적을 하였습니다(파이어버그 이용)
그랬더니 문제가 발생한 지점을 발견 이렇게 포스트하게 되었군요..ㅋㅋ

이벤트를 등록할때는 분명 _observeAndCache을 이용, observers 오브젝트에 이벤트관련 내용을 기록합니다. 허나, 이벤트를 삭제하는 stopObserving에서는 단순하게 이벤트를 삭제할뿐 observers 오브젝트에 기록한 이벤트 내용은 삭제하지 않고 계속 쌓아두고 오브젝트의 크기만을 늘리고 있었습니다.
물론 소스상에 unloadCache라는 것이 있어 observers 을 날려주고 있지만 이것을 기억하십시요.
unloadCache는 unload이벤트가 발생할때만 실행됩니다. 그러므로 Ajax를 통해 데이터를 받아오고 동적으로 이벤트를 Element에 설정했다면 unload이벤트는 발생하지도 않고 observers의 크기는 날로 커져만 갑니다. 이를 Prototype JS측에서는 알고 있는지 모르겠군요.

일단 제가 수정한 PrototypeJS의  소스는 아래와 같습니다.

  //Fix to prototype's  Event bug : Must decrease to Evnet.observers.length -> Memory leak
  //Added by blankus [www.blankus.net] 2007 - 07 - 13
  decreaseCache : function(elementId){
    if (!Event.observers) return;
 var tmp = [];
    for (var i = 0, length = Event.observers.length; i < length; i++) {
      //해당아이디의 이벤트를 삭제할때 observers의 내용에서도 해당아이디로 등록된 내용을 찾고,
      //만약 같은 내용이 있다면 그것만을 제외하고 새로운 오브젝트에 담아 새로운 Event.observers를 생성
      if(Event.observers[i][0]!=null && elementId != Event.observers[i][0].id) tmp.push(Event.observers[i]);
    }
 Event.observers = tmp;
  }

  stopObserving: function(element, name, observer, useCapture) {
    element = $(element);
    useCapture = useCapture || false;

    if (name == 'keypress' &&
        (Prototype.Browser.WebKit || element.attachEvent))
      name = 'keydown';

    if (element.removeEventListener) {
      element.removeEventListener(name, observer, useCapture);
    } else if (element.detachEvent) {
      try {
        element.detachEvent('on' + name, observer);
      } catch (e) {}
    }
 //Added by blankus 2007 - 07 - 13
 try{
  this.decreaseCache(element.id);
 }catch(e){}
  }

posted by blakus