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

이것을 이야기 하기전에 일단 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
Tip  |  2007/07/16 09:28
이 글의 트랙백 주소 :: http://www.blankus.net/trackback/21
.
blankus 님의 블로그에서 트랙백 합니다. =============================== 우리가 실제로 웹 페이지에 접속할 때 생성되는 connection의 개수는 얼마나 될까? 일반 사용자들이야 궁금해 할일이 없겠지만, 서...
.
최근 자바스크립트의 사용량이 많아지면서 트래픽도 덩달아 증가하고 있다. CPU 연산 의존도가 높은 자바스크립트는 당장 필요치않은 라이브러리들까지 처리하려니 브라우저도 죽을 맛이다....
.
http connection이 스크립트 처리는 하나뿐이 못하다는 사실.. 처음 알았음..
2007/07/22 11:45 댓글에 댓글수정/삭제
포스팅 해주신 내용 잘 보았습니다. 생각지도 못했던 곳에서 분리하지 말아야 될 근거를 찾으셨군요.^^
첨언 하자면~ 네트워크 측면에서 별도의 js파일을 이용하는 경우 패킷의 overhead가 발생할 수 있습니다. 파일이 쪼개져 있으면, 그만큼 길이가 작은 패킷이 많이 생성되고, 전체적으로 보았을 때 트래픽이 많이 발생 될 수 있습니다. 또한, 운영체제의 입장에서 보더라도 이런식으로 connection이 많이 발생하게 되면 port를 할당하는 작업에 있어서 그만큼 overhead가 심해질 수 있구요~
(네트워크 망이 좋아지면서 이정도는 무시해도 될 수준의 overhead가 되어 버렸지만.. -ㅅ- connection이 많아 질 때 왜 overhead가 심해지는지 궁금하실 분도 계셔서.. 적어놓습니다~@_@;;)
.
2007/07/22 11:53 댓글에 댓글수정/삭제
그리고 첨언하자면, http connection은 여러개가 생성될 수 있습니다.
만약 한 페이지에 html 1개+js 2개가 있다면 connection은 2개만 생성되는게 맞습니다만, html 1개+gif 9개가 있다면 connection은 10개가 생성됩니다.
browser 내부에서는 별도의 파일 다운로드 관련 thread(일의 단위)가 생성되며 따라서 파일은 병렬적으로 다운로드 됩니다. js는 왜 2개만 생성되냐면, 궁극적으로 js parser와 관련된 일이며, js parser가 병렬처리가 가능한 구조로 되어진다면, js파일도 여러개를 동시에 다운로드 받을 수 있게 됩니다. (아직까진 이런 구조를 만들 필요가 없기 때문에 현재의 구조를 가지고 있지 않나 생각을 해 봅니다. interpreter 입장에서 보면.. 저런 구조를 가지려면 후방참조의 개념이 들어가서.. 굉장히 복잡해지거든요.)

따라서

"클라이언트는 동시에 라인(http connection)을 두개이상 사용할 수 없다"

라는 말은 오해의 소지가 있을 수 있을것 같아서 적습니다.

P.S. 실제로 2번째 그림에서는 동시 connection이 8개가 발생한 것을 보실 수 있습니다.
2007/07/22 17:33 수정/삭제
위에 내용을 더 첨부하여으니 참고하시고 AD님의 의견에 힘을 더해줄 자료 및 근거를 기대하겠습니다.
.
2007/07/22 23:26 댓글에 댓글수정/삭제
트랙백 전송하였습니다~ :) 참고로 제가 설명드렸던 부분은 AJAX 뿐만이 아닌, 전체 Browser 입장에서의 connection 개수 입니다.
.
2007/07/23 01:54 댓글에 댓글수정/삭제
좋은글 잘 읽었습니다. 저도 이 문제를 놓고 고민한 끝에 생각해 낸 것이 동적인 자바스크립트 호출이였습니다.(사실, 브라우저의 로드를 줄이기 위함이였지만) 메인 프레임격 자바스크립트 파일만 헤더에서 로드하고 조각 애플리케이션은 필요한 때에만 동적으로 호출하는 것도 효과가 있습니다. 참고로 트랙백 겁니다.
.
2007/07/23 12:01 댓글에 댓글수정/삭제
아.. 아래도 질문이 있었는데 제가 확인을 하지 못했었습니다. 지금 수정하였습니다~

그리고..

"확실하지 않은 자료와 생각으로 다른사람에게 피해를 입히는 일은 없었으면 하며, 다시는 저런 거짓된 정보를 제 블로그에 덧글을 달지 않길 바랍니다."

라고 말씀하셨습니다만, 만약 blankus님께서 잘못된 정보를 올리셨지만, 확실히 아는 사람이 없어서 묵인된 자료라면 어떻게 보증을 하실것인지 궁금하네요. 만약 정말 확실하고 올바른 글이라고 하더라도 잘못알고 있는 사람이 아니면, 어디까지나 토론정도는 할 수 있지 않을까 합니다.

저도 traffic쪽은 평소에 관심이 있던 부분이라.. 더 나은 결과를 얻을 수 있지 않을 까 해서 comment를 작성하였던 것이었습니다. 오해 없으셨으면 좋겠습니다 :)

저도 언제나 제가 잘못 알고 있었던 사실이 있었다면, 전적으로 수용하겠다고 생각하고 있습니다^^ 아직은 잘 모르는 부분이 있어서 그렇다고 너그러이 이해해주시면 감사하겠습니다.
2007/07/23 13:13 수정/삭제
그렇습니다. 제가 올린 포스트가 잘못되었을 수도 있습니다. 하지만 적어도 테스트와 전문가에게 확인을 하고 포스트를 하기때문에 그런 오류를 범할 가능성은 적습니다. 또한 오류가 있더라도 확인하고 수정할 수 있습니다. 그것은 제가 블로그 소개에도 올렸것입니다.
.
2007/07/23 12:08 댓글에 댓글수정/삭제
그리고 한가지 궁금한 점이 있습니다. HTTP 1.1에서는 2개의 connection을 제한으로 하였는데... registry를 바꿈으로써 사용자는 HTTP 1.1규약을 어기고 다운로드 할 수 있는것인가요?

제 생각에는 규약이 아니라 권고안 같습니다만.. (권고안이라는것이 아니라 순전히 제 생각입니다;;)

HTTP 1.1에서 connection을 제약하는 규약이 있다면.. 혹시 자료를 구할 수 있는지 궁금합니다^^
AJAX가 아니라 HTTP 1.1에서요. AJAX에서 connection이 2개까지 인 이유는 인터넷에 있는거같은데.. HTTP 1.1에 대한 규약이 보이질 않아서요.^^;;

이쪽에는 문외한이라.. @_@;;
2007/07/23 13:20 수정/삭제
HTTP 1.1를 설명하면서 사용한 "규약"이란 단어는 강제성을 띄는게 아닌 "서로 협의된내용을 지키는" 의미로 사용된 단어입니다(사전적 의미)그러므로 브라우져에서 초기에 제공되는 http connection의 갯수 2개는 규약이지만, 사용자 또는 프로그램에 변경될 수 있는 강제성이 없는 의미기도 합니다. "권고"와 "규약"은 서로 다르다고 생각합니다. 표준안이 대두되면서 "권고"의 단어를 자주 사용하지만 "표준"이란 단어의 의미를 생각하시면 "규약"이 맞다고 개인적으로는 생각하고 있습니다.

그리고 2개의 커넥션을 "제약"하는게 아니라 "규약"하고 있으며 규약에 대한 내용은 HTTP 1.1에 대한 W3C의 내용을 참고하시고, 더불어 microsoft에 게시된 게시물을 참조하시면 되겠습니다.
.
2007/07/23 13:21 댓글에 댓글수정/삭제
http 1.1 스펙은 아래의 주소에 있습니다.
http://www.w3.org/Protocols/rfc2616/rfc2616.html
2007/07/23 13:41 수정/삭제
아.. 네~ 좋은 자료 감사드립니다.^^ 권고안이기 때문에 IE에서는 지키지 않는 내용이었나 보네요.

바쁘실텐데.. 어제 오늘 많은 가르침 감사드립니다. 그리고 혹시 뜻하지 않게 저의 글로 마음이 상하셨다면 사과드립니다. :)
.
2007/07/23 14:27 댓글에 댓글수정/삭제
IE에서 테스트를 좀 더 수행해 보았습니다. 학교 PC와 해당 서버 세팅을 초기화 하니, blankus님이 말씀하신것과 같이 connection의 수가 제한되어 있는것 같습니다. :) 테스트 환경이 달라서 이런일이 벌어지는 것 같네요.^^; 잘못된 내용 사과드립니다^^
.
나그네
2007/07/25 16:36 댓글에 댓글수정/삭제
두 분의 논쟁.. 재미있게 보았습니다..
아.. 죄송합니다.. 장난스럽다는 뜻이 아니고, 유익하고, 도움이 많이되었다는 말입니다.. 또, 두 분다 대단하다고 생각됩니다...
요즘 모두 개발이 3D라 회피하는데, 이런 모습을 보니 즐겁군요..

암튼 고생하셨구.. 앞으로도 좋은 글 많이 부탁드립니다..
2007/07/26 09:08 수정/삭제
제가 대단하진 않습니다. 다만 다들 아시면서 모른척했을뿐 입니다. ^^
"모른척"은 무관심일수도 있고, 무시일시도 있습니다만, 어떤상황에선 그 "모른척"이 도움이 될수도있다는 사실을 알아주셨으면 해서~ 포스트하게 되었습니다. ㅎ. 앞으로도 자주 들려주시고 좋은말씀 해주세요
.
2007/11/02 17:34 댓글에 댓글수정/삭제
두분 논쟁에 많은 것을 알....것같습니다.(아직 다 모르기 때문에..^^;;;) 부디 감정적 언쟁이 아닌 지적 논쟁이 되었으면 합니다.
저는 아직도 블로그 내용을 전적으로 믿어버리는 습관이 있어서리..
사실 멀 알아야 그에 대한 진실여부를 판단하니까요..ㅋㅋ 암튼 앞으로도 많이 배우겠습니다. 두분 모두 홧튕하세여~~~^^
2007/11/07 21:40 수정/삭제
지적해주신 내용 겸허히 받아드리겠습니다. 자주 들려주셔서 좋은 말씀도 많이해주시고~ 방명록에도 자주 글남겨주세요..ㅎㅎ
.
이름 ::   비밀번호 :: 홈페이지 :: 비밀글
등록