[Comet 강좌 with ASP.NET]
작성자 : 박경훈 작성일 : 2010-08-16
E-mail : hoonsbara골뱅hanmail.net Homepage : http://http://www.twitter.com/_HOONS
E-mail : hoonsbara골뱅hanmail.net Homepage : http://http://www.twitter.com/_HOONS
연재순서
1회 | 2010. 06 | 코멧의 소개와 활용전략
2회 | 2010. 07 | 닷넷을 활용한 코멧 구현 전략
3회 | 2010. 08 | 코멧을 이용한 웹 채팅 만들기
1회 | 2010. 06 | 코멧의 소개와 활용전략
2회 | 2010. 07 | 닷넷을 활용한 코멧 구현 전략
3회 | 2010. 08 | 코멧을 이용한 웹 채팅 만들기
| 기술 | 장점 | 단점 |
| iframe | 구현이 쉽다 로딩이 표시된다. | IE에서 딸깍딸깍 소리가 난다. 크로스 도메인을 지원하지 않는다. |
| htmlFile | 크로스 도메인을 어느 정도 사용할 수 있다. 로딩바 표시나 딸깍 로딩소리를 없앨 수 있다. Chunked인코딩을 이용해서 스트리밍 서비스를 제공할 수 있다. | IE에서만 동작된다. |
| JSONP | 크로스 도메인 문제를 해결할 수 있다. 로딩바 표시나 별도의 소리가 나지 않는다. | Chunked 인코딩을 이용할 수 없다. |
| XMLHttpRequest | XmlHttpRequest 최신 브라우저에서는 스트리밍 서비스를 구현할 수 있다. | 크로스 도메인을 지원하지 않는다. |
[표1] 롱폴링을 위한 기술들
커넥션 관리 이슈
롱폴링의 경우 서버에서 커넥션을 물고 있기 때문에 커넥션 관리 이슈를 빼놓고 생각해 볼 수 없다. 기존의 폴링은 커넥션을 자주 연결하고 끊기 때문에 서버 트래픽이나 서버 CPU의 영향을 주게 된다면 커넥션을 물고 있을 경우 가장먼저 생각해 봐야 하는 것이 메모리 이슈이다. 그리고 두 번째는 브라우저에서 한 사이트당 최대 커넥션 수를 제한하고 있기 때문에 잘못 했다가는 사이트가 먹통이 되어 버리는 브라우저의 이슈가 있다.
그렇다면 먼저 메모리 이슈부터 살펴보도록 하겠다. 물론 커넥션당 하나의 스레드가 할당될 것이고 어떤 작업을 하게 되느냐에 따라서 CPU 비용을 사용하게 될 수도 있지만 적절히 스레드를 쉬어가면서 운영을 하게 되면 일반적으로 CPU 때문에 크게 이슈가 되지는 않을 것이다. 그것보다도 서버를 운영하다 보면 부딪치게 되는 이슈가 바로 메모리 이슈이다. 보통 스레드와 스택기반의 커넥션을 이루게 될 경우 한 사용자 당 약 2메가 정도를 예상해 봐야 할 것이다.
이 수치는 약 오천 명이 동시 접속을 이루게 될 경우 10기가 정도의 메모리가 소모된다는 것이다. 하지만 웹에 오천 명이 동시에 접속한다는 것 자체가 굉장히 대단한 수치이다. 대한민국 국민의 0.01%가 모두 한 사이트에 들어와서 특정 서비스를 이용하고 있다는 것이기 때문이다. 때문에 대규모의 서비스가 아닐 경우라면 크게 걱정하지 않아도 될 것이다. 물론, 국내에서 몇 손가락 안에 드는 그런 어마어마한 사이트에서 웹 채팅을 구현한다고 한다면 각각 서버를 분할해서 구현해야 할 것이다. 하지만 이 내용은 이번 기사의 범위에서 벗어나므로 다루지 않도록 하겠다.
두 번째로 생각해 볼 이슈는 바로 브라우저의 커넥션 제한 이슈이다. 브라우저는 각각의 최대 커넥션 개수를 가지고 있다. 즉, 최대 커넥션 개수 범위 안에서 커넥션을 공유하면서 서버와 통신을 하게 되는 것이다. 하지만 롱폴링을 이용하게 되면 하나의 커넥션을 헌납해야 한다. 다음 [표1]은 각 브라우저 별로 커넥션 수를 보여주고 있다.
[표1] 브라우저별 커넥션 수
원래 HTTP 프로토콜에서 권고하는 도시 커넥션 수는 2개였고, 지금도 그러하다. 하지만 파이어폭스3가 발표될 때 6개로 확장을 시작하였고, 크롬도 그에 맞서 6개로 확장하여 지원하고 있다. 그에 맞서 IE8도 6개로 확장하였다. 왜냐하면 이 커넥션 숫자가 바로 웹 사이트를 다운로드 하는 속도와 아주 밀접하게 연결이 되어있기 때문이다. 하지만 조금 오래된 브라우저들은 여전히 2개의 커넥션만 허용하고 있기 때문에 웹사이트가 먹통이 되거나 굉장히 느려질 수 있기 때문에 커넥션 관리를 철저하게 해주어야 한다.
롱폴링의 경우 서버에서 커넥션을 물고 있기 때문에 커넥션 관리 이슈를 빼놓고 생각해 볼 수 없다. 기존의 폴링은 커넥션을 자주 연결하고 끊기 때문에 서버 트래픽이나 서버 CPU의 영향을 주게 된다면 커넥션을 물고 있을 경우 가장먼저 생각해 봐야 하는 것이 메모리 이슈이다. 그리고 두 번째는 브라우저에서 한 사이트당 최대 커넥션 수를 제한하고 있기 때문에 잘못 했다가는 사이트가 먹통이 되어 버리는 브라우저의 이슈가 있다.
그렇다면 먼저 메모리 이슈부터 살펴보도록 하겠다. 물론 커넥션당 하나의 스레드가 할당될 것이고 어떤 작업을 하게 되느냐에 따라서 CPU 비용을 사용하게 될 수도 있지만 적절히 스레드를 쉬어가면서 운영을 하게 되면 일반적으로 CPU 때문에 크게 이슈가 되지는 않을 것이다. 그것보다도 서버를 운영하다 보면 부딪치게 되는 이슈가 바로 메모리 이슈이다. 보통 스레드와 스택기반의 커넥션을 이루게 될 경우 한 사용자 당 약 2메가 정도를 예상해 봐야 할 것이다.
이 수치는 약 오천 명이 동시 접속을 이루게 될 경우 10기가 정도의 메모리가 소모된다는 것이다. 하지만 웹에 오천 명이 동시에 접속한다는 것 자체가 굉장히 대단한 수치이다. 대한민국 국민의 0.01%가 모두 한 사이트에 들어와서 특정 서비스를 이용하고 있다는 것이기 때문이다. 때문에 대규모의 서비스가 아닐 경우라면 크게 걱정하지 않아도 될 것이다. 물론, 국내에서 몇 손가락 안에 드는 그런 어마어마한 사이트에서 웹 채팅을 구현한다고 한다면 각각 서버를 분할해서 구현해야 할 것이다. 하지만 이 내용은 이번 기사의 범위에서 벗어나므로 다루지 않도록 하겠다.
두 번째로 생각해 볼 이슈는 바로 브라우저의 커넥션 제한 이슈이다. 브라우저는 각각의 최대 커넥션 개수를 가지고 있다. 즉, 최대 커넥션 개수 범위 안에서 커넥션을 공유하면서 서버와 통신을 하게 되는 것이다. 하지만 롱폴링을 이용하게 되면 하나의 커넥션을 헌납해야 한다. 다음 [표1]은 각 브라우저 별로 커넥션 수를 보여주고 있다.
[표1] 브라우저별 커넥션 수
원래 HTTP 프로토콜에서 권고하는 도시 커넥션 수는 2개였고, 지금도 그러하다. 하지만 파이어폭스3가 발표될 때 6개로 확장을 시작하였고, 크롬도 그에 맞서 6개로 확장하여 지원하고 있다. 그에 맞서 IE8도 6개로 확장하였다. 왜냐하면 이 커넥션 숫자가 바로 웹 사이트를 다운로드 하는 속도와 아주 밀접하게 연결이 되어있기 때문이다. 하지만 조금 오래된 브라우저들은 여전히 2개의 커넥션만 허용하고 있기 때문에 웹사이트가 먹통이 되거나 굉장히 느려질 수 있기 때문에 커넥션 관리를 철저하게 해주어야 한다.
세번째 강좌에서는 특이하게도 chunked transfer 형식을 빌려서 만들었음.
Comet wikipedia 같은 곳에서 보면 multipart response를 사용하는 것이 일반적인 것 같던데..
하지만 두 방법 모두 http transfer를 위해 socket connection 연결한 상태에서 respone를 나눠서 계속 보내는 것이라 socket connection 유지 및 관리에서 문제가 되지 않을까?
* [참고] HTTP Chunked Transfer
- http://tools.ietf.org/html/rfc2616 ( 3.6.1 Chunked Transfer Coding )
: 일반적인 HTTP transfer는 한번의 request에 대해서 한번의 response로 끝나게 된다. ( 1xx continue 경우 제외), 하지만 특정 소스(live stream 같이 전체 size를 판단하지 못하고 client의 capability상 전체 size를 한번에 보내지 못할 경우, 아님 편의상)를 임의 사이즈(chunk)로 나눠서 전달할 수 있다. (HTTP 1.1 에만 국한)
* [참고] HTTP Multipart response : - http://www.ietf.org/rfc/rfc1521.txt (Section 7.2)
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html
댓글 없음:
댓글 쓰기