독립형 OWIN 기반 웹 서버 – NOWIN

보통 닷넷에서 독립형 웹 서비스를 구현할 때 HttpListener 를 쓸 것이다. node.js 처럼 쉽게 구축이 가능하기 때문이다.

물론 그럴 일은 없겠지. 아무래도 안정화된 IIS로 다들 쓸텐데.

그러고 보니 MS도 OWIN 웹 서버인 Katana 를 만들어서 아직까지는 실험적으로 배포하고 있긴 하다. (모노 지원은 개나 줘버리고)

OWIN 표준은 1.0 으로 안정화가 되어 있지만, 이는 기본적인 웹 서비스를 위한 스펙이며, 아직 부가적인 요소 (웹소켓 등)은 표준을 만들고 있는 중이다.

그러는 와중에 드디어 내가 바랬던 프로젝트가 있었으니.. 바로, NOWIN 으로 OWIN 표준 기반 웹 서버다.

https://github.com/Bobris/Nowin

이녀석은 닷넷 4.5로 만든 웹 서버인데, 가장 큰 특징은 HttpListener 를 안썼다는 것이다.

무슨 소리냐고? 지랄같이 제한적인 기본적인 웹 서버 클래스를 안썼다는 것이다.

이말인 즉슨, 직접 웹서버를 닷넷으로 구현했다는 것이다.

이렇게 되면 모노 지원은 이미 따놓은 당상이며, 웹소켓도 아무렇지도 않게 지원된다.

윈도우 7이나 2008 R2 라도, 닷넷 4.5 깔면은 순수 닷넷으로 웹소켓과 웹서버를 한번에 휘어잡을 수 있게 된다.

아파치의 NIO같은 Non-Blocking I/O 를 직접 구현함으로써 극대화한 웹 서버가 이 프로젝트의 특징이다.

아시다시피 네이티브 웹소켓은 윈도우 2012 에 들은 IIS8에 채용되었다.

지금 윈도우 2012 로 닷넷 돌리는 곳이 얼마나 있을까. 가뜩이나 윈도우 라이센스 하면 치가 떨리는데.

프로젝트가 제시한 특징을 알아보자.

  • Http 1.0 와 1.1 클라이언트를 SocketAsyncEventArgs 클래스를 이용하여 가장 빠르게 인터넷을 구현
  • KeepAlive, 비테스트 파이프라인, 요청/응답에 자동 chunked en/decoding 기능 구현
  • 모든 개체에 비동기를 실현하였으며, 자동으로 병렬 코어로 작동하도록 구현
  • SSL 은 .Net SSL 스트림으로 동일한 보안 시스템 구현
  • WebSockets 을 독립적으로 작동할 수 있다! 따라서 SignalR 을 HttpListener 내장된 Win8 보다 더 빠르게 작동시킬 수 있다.
  • 현재 연결 수, 최대 할당 연결, 할당이 필요한 지 추적하는 기능을 제공한다.
  • 연결당 20kb RAM 정도가 소요되며 대부분 재사용된다. 하지만 절대 할당이 해제되지 않는다.
  • 기본적으로 최대 요청/응답 크기는 8KB 이다.
  • Nuget 으로 쉽게 사용이 가능하며, 종속성이 없다.

보아라. 종속성이 없다고 한다. 닷넷의 코어 기능만을 사용하여 웹 서버를 구현한 것이다. 이제 닷넷판 Netty 가 나온 것인가?

그렇다면 사용법을 알아보자.

Microsoft.Owin.Hosting nuget 사용시 샘플

static class Program
{
    static void Main(string[] args)
    {
        var options = new StartOptions
        {
            ServerFactory = "Nowin",
            Port = 8080
        };

        using (WebApp.Start<Startup>(options))
        {
            Console.WriteLine("Running a http server on port 8080");
            Console.ReadKey();
        }
    }
}

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.Use(context =>
        {
            if (context.Request.Path == "/")
            {
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync("Hello World!");
            }

            context.Response.StatusCode = 404;
            return Task.Delay(0);
        });
    }
}

빌더를 사용한 Https 샘플

var builder = ServerBuilder.New().SetPort(8888).SetOwinApp(SomeOwinApp);
builder.SetCertificate(new X509Certificate2("certificate.pfx", "password"));
using (builder.Start())
{
    Console.WriteLine("Listening on port 8888. Enter to exit.");
    Console.ReadLine();
}

마치 node.js 의 http API 와 흡사하다. 거기에다가 대리자를 통한 비동기 처리를 구현하였다.

이정도면 원하는 웹 서버를 쓰기 좋지 아니한가? 모노라도?

안타깝게도 아직까지는 안정성과 보안성을 검증하지 못하였다. 계속 테스트 중이며, 아직 실제로 쓰기에 보장이 전혀 없다.

Fork 는 12 지만 실제 참여자는 2명이다. 아는사람인지 알 턱은 없지만.

하지만 그래도 같이 테스트하고 참여해 볼 만 하다. 순수 닷넷으로 이정도를 구현했으면, 자바 부럽지 않은 웹 어플리케이션이 탄생해도 무방하지 아니한가? 이 NOWIN 을 통하여 Nancy 와 SignalR 조합이면 웹 어플리케이션에 두려움은 없을 것이란 생각이 자꾸 든다. 오호.

물론 ASP.NET 기반은 이걸로 동작이 어려울 것이다. ASP.NET MVC 등이 100% OWIN에도 동작하지 않는 이상은.

왜냐면 이들은 HttpListener 기반으로 돌아간다. 호환성은 망했어요.

닷넷에 이 프로젝트는 심히 기대대뇐 프로젝트다. 계속 눈여겨보고 테스트해야겠다.

근데 나 지금 회사에서 자바개발중이라서 아마 안될거야..

집에서 해야겠네.. 흑.

composite / 2014년 1월 8일 / 미분류 / 0 Comments

SignalR 원래 웹소켓 기능 없었다.

닷넷 개발자분들 죄송하지만 착각하지 마시지요. 없습니다.

ASP.NET 에 SignalR 을 적용하여 웹소켓 구현하기란 글을 봤다.

하지만 ASP.NET 에 웹소켓 구현 못한다. 절대로.

왜냐? IIS 가 지원을 안해주기 때문이다. 윈섭 2012 전까지는!

IIS 는 톰캣처럼 잦은 연구와 참여, 업데이트가 안되고, 메이저 업뎃마다 구매해야 한다. 서버와 같이.

그렇다 보니 기존 인프라에 웹소켓을 지원하려면 node.js 같은 오픈소스를 쓰던가 해야 한다.

갑자기 삼천포로 흘러갔네..

이제 윈섭 2012에서 네이티브 웹소켓이 지원되고, 마소가 공식적으로 SignalR 을 지원하기 때문에 웹소켓 된다는 소리는 이제 해도 된다. 단, 서버 환경이 윈섭 2012이고 SignalR 버전이 2.x 라면.

그럼 웹소켓 없으면 뭘로 통신을 주고받냐고?

Comet 안해보셨나.. 새삼스럽게…

  • HTML 스트리밍 (Transfer-encoding: chunked)
  • 롱 폴링(Long Polling)
  • 걍 폴링(Polling)

코멧 기술은 훈스닷넷 가면 졸라 친절하게 가르쳐 주니 거기서 배우고 오도록. (http://www.hoons.net/Lecture/View/521)

대신 웹소켓이 아니라서 node.js 처럼 성능을 기대하긴 어렵지만, SignalR은 정말 대단하다고밖에 못하겠다.

조또 없는 마소의 IIS 웹환경을 최대한 활용하여 성능을 이끌어낸 것도 용하다.

이건 SignalR에게 있어 최강점이 아닐까 싶다.

결론! 웹소켓 기능은 없었다. 원래부터. 그리고 쓰고싶으면 Self Hosting 쓰던지 윈섭 2012 깔던지.. 아니면 node.js 같은 다른 솔루션 써야 한다.

자바? 자바는 Self Hosting 기반의 웹 프로젝트가 많기 때문에 긴말 안한다. 웹서버 구버전 또는 JEUS만 아니면 웹소켓 된다.

composite / 2013년 11월 20일 / 미분류 / 0 Comments

한국에서 윈도우 서버 제품군 비용이 쓸데없이 높은 이유

웹 서버 순위 포스트를 쓰고 갑자기 문득 떠올랐다.

사실 윈도우 서버는 패키지 구매 비용이 비싸지 거기서 웹 어플리케이션 세팅 비용은 타 운영체제보다도 낮다.

리눅스보다도 싸다. (근데 요즘 전체적인 비용은 리눅스가 우월하긴 하지만 그닥 큰 차이는 없다.)

근데 한국은 이상하게 유독 전체적인 비용이 비싸다. 그런 인식이 강하다.

옛날는 그래도 리눅스와 삐까떴다. 왜냐? 리눅스는 무료긴 한데 세팅이 좀 빡셌으니..

하지만 요즘은 리눅스에 자동설치 패키지 방법이 도입되고 난 후 비용이 줄었다.

그래봐야 리눅스는 세팅비용이라는 함정이 있어 비용을 윈도우처럼 크게 줄이지는 못한다.

그래도 둘다 편해지긴 편해졌다.

중소기업부터 국가기관까지 오픈소스(?)인 자바를 도입하고, 그 외 언어는 배제하고 있다.

사실 전체적인 비용을 따지면 PHP 사이트 구축이 가장 유리하다. 대국민 사이트에서 PHP만으로도 돌릴 수 있는데도 불구하고 (전자민원같은거 빼고.) 죄다 자바다. 그냥 보여주기식 사이트도 마찬가지다. 국가기관 이벤트 홈페이지 (예를들면 엑스포 안내 및 교통정보 등을 알리는 안내 사이트만 딸랑)까지 스프링에 스트럿츠 돌리는 거품 쩌는 웹사이트도 있다. (로비먹였겠지..ㅋㅋ)

사실 윈도우는 패키지가 유료다. 스탠다드가 100만원 간다. 라이센스에 따라 몇천만원 호가하기도 한다.

근데.. 세팅비용은 싸다. 원래 싸다. 거기다가 어떤 프로그램을 쓰던 마소는 상관 안한다. 불법만 아니면.

근데 비싸다고 하다.

우리나라 종특중에 이게 있다. 겉모습만 보고 판단한다. 하지 말래도 결국 하게 된다. 사회 시스템이 그런 구조다.

그래서 결국 하나만 집중하게 된다. 자바 뿐이다. 오로지.

근데 이상하게 C/C++ 개발은 비주얼 스튜디오로 개발하고 MS 컴파일러로 돌려 윈도우에만 돌린다.

오픈소스 권장하는 정부라면서 뭔가 앞뒤가 안맞는다.ㅋㅋ

어쨌든. 겉모습에는 윈도우 패키지가 비싸다. 그래서 꺼린다.

하지만 윈도우로 돌렸던 업체는 더욱 더 꺼린다. 세팅 비용도 만만찮게 비싸기 때문이다. 왜일까?

이유는 간단하다. 윈도우 시스템을 건드려야 직성이 풀리는 기획성과 개발성에 있다.

이렇게 비용을 올려버린다. 당연히 윈도우 시스템을 건드리고 환경 바꾸니 비용이 올라갈 수밖에 없다.

하지만 효율성은 떨어지고 유지보수가 어려워진다. 결국 그 비싼 시스템은 쓰레기조각이 되고 만다.

우리나라 패키지 시장이 정말 이렇게 심각했었다. 이제는 몇년 쓰고 버리자는 인식이 IT에서 너무 강해졌다고밖에.

옛날 닷넷으로 만든 ERP를 접해본 적이 있다. 세팅을 해봤다. 세팅 순서는 이렇다.

  1. 윈도우 깐다.

  2. REGEDIT 켜서 레지 등록한다. (알고보니 앱 세팅정보를 여따가 넣었다.)

  3. 앱의 ini 정보를 수정한다 (web.config는 장식이었나?)

  4. web.config를 수정하는데 수정 내용은 ini 참조와 레지 참조

  5. machine.config 수정한다. (보안등급 확 내리는게 한국IT 종특이다.)

  6. IIS 세팅한다 (이건 허무맹랑하게 끝날 줄 알았는데 무슨 가상폴더가 이리 많아..)

  7. COM+ 모듈 깐다.. (하아..)

  8. 웹서버 켜고 DB연결 되고 이것저것 되는지 테스트한다.

이렇다.

일반적으로 웹 앱은 이렇게 한다.

  1. IIS에 웹 앱 경로 집어넣고 웹사이트 추가한다.

  2. web.config 를 환경에 맞게 수정한다.

  3. 돌리고 테스트한다.

정말 쉽다. 근데 이게 보안에 취약하단다.. 미친..

(암호화가 안되있다는 이유라고 하는데 옛ERP도 실상 암호화도 없고 리플렉터로 뚫리고 경로 뽀록나면 다 뚫리는 구조다)

비용이 왜 높은가. 정말 쉽다. 이렇게 모순된 인식과 세팅 방법에 있었다. 더 이상 할말이 없다.

덤으로 졸랭 개발하기도 쉬운 액티브엑스가 왜 비용이 비싼가 했더니..

  1. 윈도우 비스타 이상 관리자 권한 요구

  2. 64비트 환경 적용 (이건 뭐 어쩔수 없다지만)

  3. 보안설정을 최대한 낮춰 액티브엑스가 보호하도록 유도

<

p>

이렇다. 배포는 아주 쉽다.

어쨌든, 이런 모순된 인식과 비싼 비용이지만 오히려 보안에 취약한 서버 환경을 불러오고 말았다.

이런 면에서는.. 자바가 유리하다. 사실. 시스템에 별다른 세팅 안해도 되니까.

한국 IT가 보안에 이렇게 취약한 원흉은 바로 이런 모순된 시스템 환경 설정이 불러온 재앙이 아닐까 싶다.

비용 비싸고, 보안에 취약하고. 단점이란 단점 다처먹고도 아직도 우리나라 IT는 정신 못차렸다.

우리나라는 공급자가 하라는대로 안하고 멋대로 하고 문제생기면 마소한테 따지는 이상한 나라다.

더 웃긴점은, 공급자가 이것도 수용하준다는거다.

이런 모순된 세팅과정과 비용, 그리고 비효율성, 취약한 보안.

IT에 종사하는 여러분들도 어쩌면 그 문제에 직면하고 있을지도 모른다.

composite / 2013년 6월 19일 / 미분류 / 0 Comments

심심하면 보는 2012 전 세계 웹 서버 순위

2012년 기준이지만, 다들 관심 없나보다. 워낙 자바만 고집하는게 한국사회라. 좀 병신같지만.

그래도 웹 서버 점유율은 잠시 웃어주고 넘어가자.

  1. 단연 Apache. 오픈소스지만 오랜 노하우와 초보부터 프로까지 접할 수 있는 접근성이 큰 요인으로 작용한다.

    딱히 무슨 말이 필요한가. PHP와 Apache는 여전히 최상의 조합인데.

  1. 비즈니스 앱에서 독보적인 마소의 IIS. 비즈니스에서는 윈도우 서버 구매비용에 비해 낮은 구축 비용과 세팅 비용이 매력으로

   작용해서 아직도 많이 쓰고 있는 편이다. 여전히 IIS 6을 돌리고 있는 웹사이트가 많으며

   (.NET 3.5 이하 또는 기존 ASP가 많이 호스팅되다 보니.)

   IIS 7 이상은 마소 파트너가 아닌 이상.. 스타트업 업체도 이걸로 구축하는 업체가 많지 않다. 초기 비용이 비싸니까..ㅋㅋ

   그래서 마소가 WebsiteSpark, BizSpark 같은 프로그램 운영해도 아는사람 많지 않은게 함정.

  1. 추월하고 있는 Nginx. 웹 서버 성능이 최강이라 알려져 있다. 특히 리버스 프록시에 강해서 WAS 따로 둬도 강력할 정도.

    WAS는 Web Application Server는 다들 알겠지만 자바에 한정짓지 마라. 자바 뿐만 아니다. 괴발자들아.

    자바를 비롯해 닷넷도 WAS가 가능하고(물론 ASP.NET 종속적이 아니면), 뜨고 있는 node.js 와 Ruby, Python 같은

    여러 서버 스크립트도 WAS 로 돌려 Nginx 에서 호스팅이 가능하고, 새로 뜨고 있는 스타트업 웹사이트에서도 그렇게 쓰고

    있다. 요즘 스타트업 사이트들이 그런 식으로 돌리다 보니 추월한 것이지.

    nginx와 PHP 조합? 단연 우수하다. 아파치 조합보다 더 빠른 성능을 자랑한다.

  1. 갑자기 다시 뜨고 있는 lighttpd. 이녀석은 애초부터 HTTP 서버에 군더더기를 제거해 HTTP 서버”만” 돌리겠다는 이념(?)으로

    만들고 있는 오픈소스 서버다. 그렇다 보니 서버 분산과 클라우드, CDN의 유행이 퍼지면서 정적 컨텐츠를 빠르게 전달하는

    용도로 주목을 받고 있는 듯 하다. 여태까지 잠잠해지다가 뜬 거 보면. 내 개인적인 생각이지만.

    예를 들면 css나 js, 이미지 같은 서버단 처리가 없는 정적 컨텐츠 말이다.

  1. 구글은 구글에 구걸하면 구할수 있습니까?

전 세계 웹 서버 점유율에서 한국의 경우는 “당연히” 아파치가 우세하다. 일본도 마찬가지고. 근데 중국은 IIS.. 읭?

어쨌든 지금 웹 서버와 개발 트랜드가 조금씩 변화하고, 뜨고 있는 언어가 늘어나면서 경쟁은 치열해 지고 있는 것이 현실이다.

그래봐야 님은 자바에 아파치 톰캣이면 어느 누구도 두렵지 않다고 하겠지만. 아니면 닷넷의 경우 IIS가.

근데.. 님들아. PHP가 웹 사이트 언어 순위 아직도 1위랍니다. 앞으로도 1위고. 의미없는 언어우월주의 허세떨지 마시길 괴발자님.

참고자료

May 2012 Web Server Survey – http://news.netcraft.com/archives/2012/05/02/may-2012-web-server-survey.html

Most popular web servers by country – http://w3techs.com/blog/entry/most_popular_web_servers_by_country

Poll Results: Server side language of choice? – http://css-tricks.com/poll-results-server-side-language/

composite / 2013년 6월 13일 / 미분류 / 0 Comments