Attribution/Share Alike 2.0 licenseblankus 님의 블로그에서 트랙백 합니다. ===============================
아래 글에서도 밝혔듯이, HTML에서 페이지를 로딩할 때 생성되는 HTTP Connect을 알아보았다.
분석을 하기 전 최대한 논쟁을 정리하기 위해 용어 정리 및 몇가지 사항을 나열해보도록 하겠다.
* HTTP Connection: "TCP connection 중 client에서 web server로 연결되는" connection을 의미한다. 정확히는 web browser에서 web server의 daemon 또는 service가 제공하는 port로 연결할 때 발생하는 connection을 의미한다. (보통 web server가 제공하는 port는 80번 포트이므로, client가 80번 포트로 연결한다면 HTTP connection이 발생한다고 볼 수 있다. 포트 번호를 변경한다면 물론 80번 이외의 포트로 연결하더라도 HTTP connection을 의미한다.)
이는 HTTP라는 Protocol자체의 connection를 나타내며, HTTP이라는 Protocol이 TCP라는 Protocol을 이용하기 때문에 "TCP를 이용한 프로토콜 중 하나"라고 할 수 있으며 따라서 위와 같은 설명이 가능하다.
* wininet: wininet.dll 라이브러리 형태로 제공된다. Gopher, FTP, HTTP와 같은 protocol들을 좀 더 편하게 이용할 수 있도록 Windows에서 제공하는 API를 의미한다.
The Windows Internet (WinINet) application programming interface (API) enables applications to interact with Gopher, FTP, and HTTP protocols to access Internet resources.
(출처: http://msdn2.microsoft.com/en-us/library/aa383630.aspx)
* winsock: winsock.dll 또는 wsock32.dll, ws2_32.dll로 제공된다. Windows상에서 socket을 server 혹은 client를 제작할 때 사용하기 위한 library로, 보통 TCP의 전송 계층부터 응용 계층까지 작성할 때 이용할 수 있다.
Winsock provides a Service Provider Interface for creating Winsock services, commonly referred to as the Winsock SPI. Two types of service providers exist: transport providers and namespace providers.
(출처: http://msdn2.microsoft.com/en-us/library/ms737522.aspx)
용어 정리가 끝났으니 다시 HTTP Connection에 대해 살펴보도록 하자.
살피기 전에 blankus님께서 질문해주신 부분을 답변하도록 하겠다.
===============================================================================
blankus님의 Q:
제 테스트는 IE-iwatch / FF-firebug를 통하여 덤프를 떴으며, IE가 wininet을 이용하지 않는다는 것은 처음듣는군요. wininet의 서버당 연결제한수는 HTTP 스펙을 따르는것인데 말이죠. 그리고 http connection고 tcp connection을 헛깔리시는게 아닌가 합니다.
A:
제가 "최소한 IE에서는 저 API를 사용하지 않는것으로 보이며, 80번 포트로 바로 접속해서 결과를 얻어오고 파싱한다고 유추해 낼 수 있습니다."
라고 말한것과 같이, 이것은 제 추측이며 실제로 internet explorer의 dependency를 체크하면 wininet은 분명히 사용하고 있고, winsock은 사용하지 않고 있습니다.
이렇게 보면 제가 말한게 당연히 틀리게 됩니다. 이부분은 인정합니다. 그럼에도 불구하고 제가 wininet을 사용하지 않는다고 생각한 이유는 저 document에서 wininet은 같은 host에 connection의 개수가 여러개 맺어짐을 tcpview를 이용하여 확인하였기 때문입니다.
실제로 wininet을 이용했는데 저렇게 connection이 발생할 수 있다면 자신들이 작성한 문서의 내용을 지키지 않았다고 생각할 수 밖에 없습니다. 그래서 제가 저런 말을 한것입니다. 실제로 어떤 룰에 의해 저렇게 결과가 나오는지는 소스를 보거나 disassembly 해보기 전까지는 모르는 일이죠. wininet에 있는 export되지 않은 다른 API를 사용했을 수도 있구요. M$에서 이런일이 워낙 많기 때문에(apache가 IIS를 따라가지 못하는 이유같이 M$에서는 자체적으로 documentation 되지 않은 내용을 많이 사용하는 사례가 있어서요.) 그렇게 생각을 하고 저렇게 결론을 지은것이죠.
분명히 우리 눈에 TCP connection이 여러개 맺어진 게 볼 수 있는데.. 문서상에서는 아니라고 하니 말입니다.
"wininet을 사용하기는 하지만 사용하지 않는?" 기괴한 상황이라고 볼 수 있습니다.
그리고, TCP connection이 서버의 80번 포트에 발생한다면, 그것은 HTTP connection이라고 할 수 있는걸로 알고 있습니다만. 이 부분에 대해 제가 잘못 알고 있는것인지 궁금합니다. HTTP 자체가 TCP에 근간을 하고 있는 protocol이거든요. 따라서, HTTP connection은 TCP connection중 HTTP port를 이용할 때의 connection 이라 볼 수 있습니다.(보통 80번 포트이죠.)
서버에 방화벽을 개발 할 때, HTTP 방화벽은 80번 포트로 지나다니는 패킷을 파악합니다. 이것은 HTTP라는 것 자체가 TCP에 속하기 때문에 가능하며, TCP 패킷을 필터링 한다면 자연스럽게 HTTP도 필터링이 가능한 것이구요.
그래서 제가 생각하는 HTTP와 TCP connection의 관계는 HTTP < TCP 라고 생각하는 바입니다.
===============================================================================
답변은 여기까지로 하고, 나머지 부분을 보자. 오늘의 글은 dependency를 기준으로 설명할 예제이다.
이쪽 부분은 요즘에 수행하는 프로젝트와 관련이 있는 부분이라서, 나한테도 도움이 될 것 같아서 쓰잘데기 없어보여도;; 정리를 해 놓았다.
아래 그림은 FF에서 과연 wininet을 사용할까? 라는 의문에서 조사를 한 결과이다. "DI"아이콘은 PE Explorer에서 delay import를 나타낸다고 하는데, 정확하지는 않지만 아마도 import section에는 명시되어 있지 않지만 import를 할 가능성이 있는 모듈을 의미하는 것 같다.
아래의 dependency는 실제 사용하지 않는 dll까지 나타나며, 그 이유는 만약 FF가 shell32.dll을 사용한다면 그 안에 있는 dll 까지 표시되기 때문이다. 따라서 실제로 사용될지는 import section을 살펴보아야 한다.
위의 그림에서 확인하였듯이, 우선 FF는 winsock, wininet을 사용 할 가능성을 보이고 있다. 그러면 import section을 보도록 하자.
import section의 shell32.dll에서, wininet에 관련된 함수는 전혀 call 하지 않는 모습을 볼 수 있다. 결론은 winsock만을 이용한다는 것. winsock을 이용하는 부분은 nspr4.dll을 따라가보면 알 수 있다.
왜 좋은 socket 표준 함수를 놔두고 winsock32의 함수들이 왜 저렇게 표시되는지는 알 수 없다; 아마도 WSA~ 류의 함수들이 def파일에 의해 'mangled' 당한게(?)아닐까 생각한다. (필자는 wsock32.dll보단 ws2_32.dll을 이용하기 때문이다) 이게 아니라면, 묵시적 연결을 통해 socket을 사용할 수도 있다. (하지만 보통 socket programming에서는 이렇게 사용하지 않는다)
FF에서 wininet을 이용하지 않는것을 파악했으니 이제 IE를 살펴보도록 하자.
IE에서 wininet을 참조한다. 얘도 바로 import 하지 않고 shell32.dll을 거친다. 물론 import section을 확인해봐야겠지.
확인 결과 SHELL32.147을 호출한다. 이게 무엇일까? 알수 없다. 아마도 내 생각엔, 이걸 보기보다는 저 아래에 있는 ieframe.dll을 보아야 하지 않을까 생각하는데.. 추적 끝에 직접적으로 wininet을 호출하는 부분을 찾을 수 없었다. 그러면 어디로 숨은걸까? 그건 IE 개발자한테에게로 -_-..
(아마도 이 부분에서 HttpRequest~~에 대한 논란이 발생되었을 수도 있다. 하지만 직접적으로 import 하는 부분에는 HttpRequest~ 가 없는걸 확인할 수 있다. (mangle될 수도 있다. 이건 M$ 마음이기 때문에 내가 알아낼 수 있는 길이 없다)
원래대로라면.. 아래에서 볼 수 있듯이.. 얘네를 호출해야되는데 말이다. 알수없는 M$.
실제로 앞에서 언급하였듯이 소스 코드를 보거나, disassembly하기 전까지는 정확히 어떤 API를 사용하는지 알 수 없다. M$의 document에서 자신들은 wininet에 호스트 접속 수를 제한하였다고 하였는데..
IE가 만약에 document에 나온대로 wininet을 이용하고 HttpRequest~ API를 이용하는것과 같이 충실히 따라주었다면 절대 아래 포스팅 한 글같이는 나오지 않을 것이다.
이 부분에 있어서 필자는 내부적으로 socket을 이용하지 않을까 라는 추측을 해 보았으며, 이 socket을 이용한 API가 wininet에 undocumented 상태로 있을지도 모르는 일이다. (진실은 저넘어에)
마지막으로 FF에서 아래 포스팅 한 글대로 테스트를 하였을 때 결과다. 스샷은.. 힘들어서 되도록이면 생략하도록 하겠다.
이 테스트를 위해.. 오늘 FF를 설치하였다 :)
(필자는 업종이 웹쪽이 아니다보니.. 평소에 FF를 사용하지 않는다;; )
* 크기가 24,159,200 Byte인 HTML 문서에 접속 할 경우 (1개의 connection)
IE와 동일하다. 1개의 HTTP connection이 발생한다.
* 크기가 4,840,000 인 js 파일을 15개 포함하는 HTML 문서에 접속 할 경우
IE와 동일하다. 한번에 1개의 JS 파일을 다운로드 한다. 여러개를 동시에 받은 뒤 나중에 파싱을 하는게 어떨까.. 라고도 생각을 해본다.^^;
-- 나중에 페이지를 옮기려니 오류가 나면서 종료된다^^;; FF의 버그인듯.
-- 재시작 하니 FF 세션 복구 기능이 있군! 역시 좋다;;
* 크기가 1,550,742 인 gif 파일을 19개 포함하는 HTML 문서에 접속 할 경우
"IE와는 다르게 그림 파일을 2개씩 받아온다." 이 부분에서 blankus 님과 다른 의견을 보인게 아닐까 한다. 하지만 FF에서는 wininet을 사용하지 않을 확률이 매우 높기 때문에 내부적인 정책으로 생각해 볼 수 있다. 하지만 어떠한 경우에도 레지스트리의 MaxConnectionsPerServer 값과는 상관이 없는 듯 하다. 필자는 원래부터 MaxConnectionsPerServer 값을 10(0xa)으로 해놓고 사용중이기 때문이다.
(솔직히 이부분은 FF의 소스를 분석해보기 전까지는 모르는 일이다.)
개인적인 생각으로는, 2개정도씩 불러오면 되겠지 라고 생각을 해서 이렇게 한 것 같다.
(멀티플렉싱 기법을 이용하지 않는 스레드 2개를 파일 다운로드에 쓰면 이렇게 될 수 있다. 멀티플렉싱 쓰면 IE와 같이 스레드 2개에서 파일을 여러개 다운로드 할 수 있다)
결론은, (휴 힘들다^^;;) IE에서 HTTP Connection의 제약은 없다고 판단되며, FF에서는 wininet을 통한 제약이 아닌, 자체적인 정책에 의해 그림파일과 같은 파일의 다운로드 개수를 제한하는것을 볼 수 있다. 이것은 MaxConnectionsPerServer값을 수정해 본 결과 M$문서에 언급되어 있는 내용과 다르다고 생각할 수 있다.
성능상의 문제로 제약해놓고... 자기네들은 지키지 않는 M$를.. 뭐라고 해야될까.
===================== 나중에 발견한 blankus님의 질문에 대한 답변입니다^^;; (위에선 이부분을 못봤네요)
1. 브라우저는 인터넷에서 리소스를 다운받을때 activex가 아닌이상 기본적으로 http 프로토콜을 통하여 처리가 됩니다. 말인즉, http connection이 발생하고 그 파이프라인을 통해 정보가 다운되는 것입니다. 그리고 tcpview를 근거로 제시하셨는데, 저또한 그프로그램으로 정보를 추출해본결과 아래와 같습니다.
=> 물론 HTTP를 이용합니다(첨언하자면 HTTP에서 P가 protocol이기 때문에 HTTP프로토콜이란 말은 엄밀히 따지면 아닙니다^^). 위에서 설명한것과 같습니다. wininet과는 상관이 없는 것 같네요. 제가 FF를 사용하지 않다 보니, IE만으로 테스트를 하였었습니다. FF를 고려하지 못한 이 부분은 사과드리겠습니다^^
2. 작은이미지라서 커넥션이 빨리끊기고하여 2개씩 보일 수 있다구요? 참으로 어리석은 생각입니다.
=> 1번과 동일합니다. 실제 IE에서 테스트 했을 당시 이미지들의 로딩이 불규칙적으로 되는것을 확인할 수 있었습니다. ms까지 나오는 툴이 없어서 스샷은 첨부하지 못했습니다.
3. html+이미지 갯수 = http connection갯수 라는 논리의 근거를 제시해달라고 했더니 트랙백 글에선 말을 바꾸시던데 왜 그랬나요? 실제로 테스트해보니 생각과는 달랐나요? http 1.1의 규약처럼 reg값을 기본으로 변경(2개)하여 테스트해보세요. 그래도 이런 생각을 하게될까요?
=> 1번과 동일합니다. 추가하자면, 말바꾼적은 없구요~ http connection의 최대 갯수 라고 해야 정확할 것 같습니다. 글 쓰다보니 "최대" 자를 빼먹은점 사과드립니다. HTTP 1.1의 규약을 제가 잘 모르기도 하지만요^^
4. IE가 wininet을 이용하지 않는다는 근거는 어떤것인가요? 이부분은 참으로 이해가 안가는 부분이군요. 자료를 첨부해주세요.
=> 위에서 그림을 첨부하여 설명드렸습니다.
5.FF가 다른 커넥션구조를 갖는다고 어디에 누가그러던가요? 자료를 첨부해주세요
=> 소스 분석까지는 곤란하겠습니다. 위의 import section을 통해 매우 높은 확률로 wininet을 사용하지 않는다는것을 보실 수 있습니다. 일반 socket을 사용할 확률이 높죠
6. 4번과 같은 맥락인데, http connection의 갯수와 관련 IE가 W3C의 HTTP 1.1의 기준에 미달한다는 자료를 첨부해주세요.
=> 음.. 이 질문에 대해서는 답변해드리기가 힘듭니다. 제 지식이 짧아서요^^; 솔직히 HTTP 1.1에서 connection의 개수가 2개로 정해졌다는 내용이 있는지도 잘 모릅니다.^^; 저는 보여지는 내용을 토대로 작성하였으며, 이 질문에 대해서는 문서를 찾아봐야되는데.. 관련 지식이 매우 부족해서 답변해드릴수가 없습니다~
아래 글에서도 밝혔듯이, HTML에서 페이지를 로딩할 때 생성되는 HTTP Connect을 알아보았다.
분석을 하기 전 최대한 논쟁을 정리하기 위해 용어 정리 및 몇가지 사항을 나열해보도록 하겠다.
* HTTP Connection: "TCP connection 중 client에서 web server로 연결되는" connection을 의미한다. 정확히는 web browser에서 web server의 daemon 또는 service가 제공하는 port로 연결할 때 발생하는 connection을 의미한다. (보통 web server가 제공하는 port는 80번 포트이므로, client가 80번 포트로 연결한다면 HTTP connection이 발생한다고 볼 수 있다. 포트 번호를 변경한다면 물론 80번 이외의 포트로 연결하더라도 HTTP connection을 의미한다.)
이는 HTTP라는 Protocol자체의 connection를 나타내며, HTTP이라는 Protocol이 TCP라는 Protocol을 이용하기 때문에 "TCP를 이용한 프로토콜 중 하나"라고 할 수 있으며 따라서 위와 같은 설명이 가능하다.
* wininet: wininet.dll 라이브러리 형태로 제공된다. Gopher, FTP, HTTP와 같은 protocol들을 좀 더 편하게 이용할 수 있도록 Windows에서 제공하는 API를 의미한다.
The Windows Internet (WinINet) application programming interface (API) enables applications to interact with Gopher, FTP, and HTTP protocols to access Internet resources.
(출처: http://msdn2.microsoft.com/en-us/library/aa383630.aspx)
* winsock: winsock.dll 또는 wsock32.dll, ws2_32.dll로 제공된다. Windows상에서 socket을 server 혹은 client를 제작할 때 사용하기 위한 library로, 보통 TCP의 전송 계층부터 응용 계층까지 작성할 때 이용할 수 있다.
Winsock provides a Service Provider Interface for creating Winsock services, commonly referred to as the Winsock SPI. Two types of service providers exist: transport providers and namespace providers.
(출처: http://msdn2.microsoft.com/en-us/library/ms737522.aspx)
용어 정리가 끝났으니 다시 HTTP Connection에 대해 살펴보도록 하자.
살피기 전에 blankus님께서 질문해주신 부분을 답변하도록 하겠다.
===============================================================================
blankus님의 Q:
제 테스트는 IE-iwatch / FF-firebug를 통하여 덤프를 떴으며, IE가 wininet을 이용하지 않는다는 것은 처음듣는군요. wininet의 서버당 연결제한수는 HTTP 스펙을 따르는것인데 말이죠. 그리고 http connection고 tcp connection을 헛깔리시는게 아닌가 합니다.
A:
제가 "최소한 IE에서는 저 API를 사용하지 않는것으로 보이며, 80번 포트로 바로 접속해서 결과를 얻어오고 파싱한다고 유추해 낼 수 있습니다."
라고 말한것과 같이, 이것은 제 추측이며 실제로 internet explorer의 dependency를 체크하면 wininet은 분명히 사용하고 있고, winsock은 사용하지 않고 있습니다.
이렇게 보면 제가 말한게 당연히 틀리게 됩니다. 이부분은 인정합니다. 그럼에도 불구하고 제가 wininet을 사용하지 않는다고 생각한 이유는 저 document에서 wininet은 같은 host에 connection의 개수가 여러개 맺어짐을 tcpview를 이용하여 확인하였기 때문입니다.
실제로 wininet을 이용했는데 저렇게 connection이 발생할 수 있다면 자신들이 작성한 문서의 내용을 지키지 않았다고 생각할 수 밖에 없습니다. 그래서 제가 저런 말을 한것입니다. 실제로 어떤 룰에 의해 저렇게 결과가 나오는지는 소스를 보거나 disassembly 해보기 전까지는 모르는 일이죠. wininet에 있는 export되지 않은 다른 API를 사용했을 수도 있구요. M$에서 이런일이 워낙 많기 때문에(apache가 IIS를 따라가지 못하는 이유같이 M$에서는 자체적으로 documentation 되지 않은 내용을 많이 사용하는 사례가 있어서요.) 그렇게 생각을 하고 저렇게 결론을 지은것이죠.
분명히 우리 눈에 TCP connection이 여러개 맺어진 게 볼 수 있는데.. 문서상에서는 아니라고 하니 말입니다.
"wininet을 사용하기는 하지만 사용하지 않는?" 기괴한 상황이라고 볼 수 있습니다.
그리고, TCP connection이 서버의 80번 포트에 발생한다면, 그것은 HTTP connection이라고 할 수 있는걸로 알고 있습니다만. 이 부분에 대해 제가 잘못 알고 있는것인지 궁금합니다. HTTP 자체가 TCP에 근간을 하고 있는 protocol이거든요. 따라서, HTTP connection은 TCP connection중 HTTP port를 이용할 때의 connection 이라 볼 수 있습니다.(보통 80번 포트이죠.)
서버에 방화벽을 개발 할 때, HTTP 방화벽은 80번 포트로 지나다니는 패킷을 파악합니다. 이것은 HTTP라는 것 자체가 TCP에 속하기 때문에 가능하며, TCP 패킷을 필터링 한다면 자연스럽게 HTTP도 필터링이 가능한 것이구요.
그래서 제가 생각하는 HTTP와 TCP connection의 관계는 HTTP < TCP 라고 생각하는 바입니다.
===============================================================================
답변은 여기까지로 하고, 나머지 부분을 보자. 오늘의 글은 dependency를 기준으로 설명할 예제이다.
이쪽 부분은 요즘에 수행하는 프로젝트와 관련이 있는 부분이라서, 나한테도 도움이 될 것 같아서 쓰잘데기 없어보여도;; 정리를 해 놓았다.
아래 그림은 FF에서 과연 wininet을 사용할까? 라는 의문에서 조사를 한 결과이다. "DI"아이콘은 PE Explorer에서 delay import를 나타낸다고 하는데, 정확하지는 않지만 아마도 import section에는 명시되어 있지 않지만 import를 할 가능성이 있는 모듈을 의미하는 것 같다.
아래의 dependency는 실제 사용하지 않는 dll까지 나타나며, 그 이유는 만약 FF가 shell32.dll을 사용한다면 그 안에 있는 dll 까지 표시되기 때문이다. 따라서 실제로 사용될지는 import section을 살펴보아야 한다.
위의 그림에서 확인하였듯이, 우선 FF는 winsock, wininet을 사용 할 가능성을 보이고 있다. 그러면 import section을 보도록 하자.
import section의 shell32.dll에서, wininet에 관련된 함수는 전혀 call 하지 않는 모습을 볼 수 있다. 결론은 winsock만을 이용한다는 것. winsock을 이용하는 부분은 nspr4.dll을 따라가보면 알 수 있다.
왜 좋은 socket 표준 함수를 놔두고 winsock32의 함수들이 왜 저렇게 표시되는지는 알 수 없다; 아마도 WSA~ 류의 함수들이 def파일에 의해 'mangled' 당한게(?)아닐까 생각한다. (필자는 wsock32.dll보단 ws2_32.dll을 이용하기 때문이다) 이게 아니라면, 묵시적 연결을 통해 socket을 사용할 수도 있다. (하지만 보통 socket programming에서는 이렇게 사용하지 않는다)
FF에서 wininet을 이용하지 않는것을 파악했으니 이제 IE를 살펴보도록 하자.
IE에서 wininet을 참조한다. 얘도 바로 import 하지 않고 shell32.dll을 거친다. 물론 import section을 확인해봐야겠지.
확인 결과 SHELL32.147을 호출한다. 이게 무엇일까? 알수 없다. 아마도 내 생각엔, 이걸 보기보다는 저 아래에 있는 ieframe.dll을 보아야 하지 않을까 생각하는데.. 추적 끝에 직접적으로 wininet을 호출하는 부분을 찾을 수 없었다. 그러면 어디로 숨은걸까? 그건 IE 개발자한테에게로 -_-..
(아마도 이 부분에서 HttpRequest~~에 대한 논란이 발생되었을 수도 있다. 하지만 직접적으로 import 하는 부분에는 HttpRequest~ 가 없는걸 확인할 수 있다. (mangle될 수도 있다. 이건 M$ 마음이기 때문에 내가 알아낼 수 있는 길이 없다)
원래대로라면.. 아래에서 볼 수 있듯이.. 얘네를 호출해야되는데 말이다. 알수없는 M$.
실제로 앞에서 언급하였듯이 소스 코드를 보거나, disassembly하기 전까지는 정확히 어떤 API를 사용하는지 알 수 없다. M$의 document에서 자신들은 wininet에 호스트 접속 수를 제한하였다고 하였는데..
IE가 만약에 document에 나온대로 wininet을 이용하고 HttpRequest~ API를 이용하는것과 같이 충실히 따라주었다면 절대 아래 포스팅 한 글같이는 나오지 않을 것이다.
이 부분에 있어서 필자는 내부적으로 socket을 이용하지 않을까 라는 추측을 해 보았으며, 이 socket을 이용한 API가 wininet에 undocumented 상태로 있을지도 모르는 일이다. (진실은 저넘어에)
마지막으로 FF에서 아래 포스팅 한 글대로 테스트를 하였을 때 결과다. 스샷은.. 힘들어서 되도록이면 생략하도록 하겠다.
이 테스트를 위해.. 오늘 FF를 설치하였다 :)
(필자는 업종이 웹쪽이 아니다보니.. 평소에 FF를 사용하지 않는다;; )
* 크기가 24,159,200 Byte인 HTML 문서에 접속 할 경우 (1개의 connection)
IE와 동일하다. 1개의 HTTP connection이 발생한다.
* 크기가 4,840,000 인 js 파일을 15개 포함하는 HTML 문서에 접속 할 경우
IE와 동일하다. 한번에 1개의 JS 파일을 다운로드 한다. 여러개를 동시에 받은 뒤 나중에 파싱을 하는게 어떨까.. 라고도 생각을 해본다.^^;
-- 나중에 페이지를 옮기려니 오류가 나면서 종료된다^^;; FF의 버그인듯.
-- 재시작 하니 FF 세션 복구 기능이 있군! 역시 좋다;;
* 크기가 1,550,742 인 gif 파일을 19개 포함하는 HTML 문서에 접속 할 경우
"IE와는 다르게 그림 파일을 2개씩 받아온다." 이 부분에서 blankus 님과 다른 의견을 보인게 아닐까 한다. 하지만 FF에서는 wininet을 사용하지 않을 확률이 매우 높기 때문에 내부적인 정책으로 생각해 볼 수 있다. 하지만 어떠한 경우에도 레지스트리의 MaxConnectionsPerServer 값과는 상관이 없는 듯 하다. 필자는 원래부터 MaxConnectionsPerServer 값을 10(0xa)으로 해놓고 사용중이기 때문이다.
(솔직히 이부분은 FF의 소스를 분석해보기 전까지는 모르는 일이다.)
개인적인 생각으로는, 2개정도씩 불러오면 되겠지 라고 생각을 해서 이렇게 한 것 같다.
(멀티플렉싱 기법을 이용하지 않는 스레드 2개를 파일 다운로드에 쓰면 이렇게 될 수 있다. 멀티플렉싱 쓰면 IE와 같이 스레드 2개에서 파일을 여러개 다운로드 할 수 있다)
결론은, (휴 힘들다^^;;) IE에서 HTTP Connection의 제약은 없다고 판단되며, FF에서는 wininet을 통한 제약이 아닌, 자체적인 정책에 의해 그림파일과 같은 파일의 다운로드 개수를 제한하는것을 볼 수 있다. 이것은 MaxConnectionsPerServer값을 수정해 본 결과 M$문서에 언급되어 있는 내용과 다르다고 생각할 수 있다.
성능상의 문제로 제약해놓고... 자기네들은 지키지 않는 M$를.. 뭐라고 해야될까.
===================== 나중에 발견한 blankus님의 질문에 대한 답변입니다^^;; (위에선 이부분을 못봤네요)
1. 브라우저는 인터넷에서 리소스를 다운받을때 activex가 아닌이상 기본적으로 http 프로토콜을 통하여 처리가 됩니다. 말인즉, http connection이 발생하고 그 파이프라인을 통해 정보가 다운되는 것입니다. 그리고 tcpview를 근거로 제시하셨는데, 저또한 그프로그램으로 정보를 추출해본결과 아래와 같습니다.
=> 물론 HTTP를 이용합니다(첨언하자면 HTTP에서 P가 protocol이기 때문에 HTTP프로토콜이란 말은 엄밀히 따지면 아닙니다^^). 위에서 설명한것과 같습니다. wininet과는 상관이 없는 것 같네요. 제가 FF를 사용하지 않다 보니, IE만으로 테스트를 하였었습니다. FF를 고려하지 못한 이 부분은 사과드리겠습니다^^
2. 작은이미지라서 커넥션이 빨리끊기고하여 2개씩 보일 수 있다구요? 참으로 어리석은 생각입니다.
=> 1번과 동일합니다. 실제 IE에서 테스트 했을 당시 이미지들의 로딩이 불규칙적으로 되는것을 확인할 수 있었습니다. ms까지 나오는 툴이 없어서 스샷은 첨부하지 못했습니다.
3. html+이미지 갯수 = http connection갯수 라는 논리의 근거를 제시해달라고 했더니 트랙백 글에선 말을 바꾸시던데 왜 그랬나요? 실제로 테스트해보니 생각과는 달랐나요? http 1.1의 규약처럼 reg값을 기본으로 변경(2개)하여 테스트해보세요. 그래도 이런 생각을 하게될까요?
=> 1번과 동일합니다. 추가하자면, 말바꾼적은 없구요~ http connection의 최대 갯수 라고 해야 정확할 것 같습니다. 글 쓰다보니 "최대" 자를 빼먹은점 사과드립니다. HTTP 1.1의 규약을 제가 잘 모르기도 하지만요^^
4. IE가 wininet을 이용하지 않는다는 근거는 어떤것인가요? 이부분은 참으로 이해가 안가는 부분이군요. 자료를 첨부해주세요.
=> 위에서 그림을 첨부하여 설명드렸습니다.
5.FF가 다른 커넥션구조를 갖는다고 어디에 누가그러던가요? 자료를 첨부해주세요
=> 소스 분석까지는 곤란하겠습니다. 위의 import section을 통해 매우 높은 확률로 wininet을 사용하지 않는다는것을 보실 수 있습니다. 일반 socket을 사용할 확률이 높죠
6. 4번과 같은 맥락인데, http connection의 갯수와 관련 IE가 W3C의 HTTP 1.1의 기준에 미달한다는 자료를 첨부해주세요.
=> 음.. 이 질문에 대해서는 답변해드리기가 힘듭니다. 제 지식이 짧아서요^^; 솔직히 HTTP 1.1에서 connection의 개수가 2개로 정해졌다는 내용이 있는지도 잘 모릅니다.^^; 저는 보여지는 내용을 토대로 작성하였으며, 이 질문에 대해서는 문서를 찾아봐야되는데.. 관련 지식이 매우 부족해서 답변해드릴수가 없습니다~
