none
IIS 설정 중 HTTP 연결 유지 관련 문의 드립니다. RRS feed

  • 질문

  • 안녕하세요?

    어쩌다 보니 늦은 시간에 질문을 올리게 되네요. 늘 도움 주셔서 감사합니다.

     

    IIS6.0을 사용하고 있는데요.

     

    평소 당연시 사용한다고 여겼던 옵션에 대한 궁금증이 생겨서 문의 드립니다.

     

    HTTP 연결 유지 구성 관련 옵션과 연결 제한 시간은 기본적으로 120초로 되어 있네요.

     

    해당 설정을 풀었을 경우와 유지했을 때의 장단점이 있는지요?

     

    특히 성능에 대한 이슈가 많다고 하던데요...^^

    2007년 10월 9일 화요일 오후 2:59

답변

모든 응답

  • 안녕하세요?
    말씀하신대로 연결 시간 제한과 HTTP 연결 유지 구성 옵션은 성능과 많은 연관 관계를 갖고 있습니다.

    연결 시간 제한의 경우 기본 120초로 되어 있는데요. 연결시간이 짧게 되어 있다고 좋은 것도 아니고

    그렇다고 너무 길어서도 안되는 설정입니다. 세션이 오래 유지된다는 얘기는 그 만큼의 Resource를 필요로

    하기 때문에 경우에 따라 굉장히 중요한 옵션일 수 있습니다.

     

    먼저 단점에 대해서 간단히 살펴 보면 HTML 문서와 열 개의 이미지를 가진 표준 웹 페이지가 있다고 가정합니다.

    표준 HTTP에서 웹 클라이언트는 각 파일을 별도의 연결을 통하여 요청합니다. 즉, 클라이언트는 서버에 연결하여

    문서 파일을 요청하고 응답을 수신한 다음 연결을 끊게 되는데. 새로 요청 할 때 마다 이와 같은 방법으로

    클라이언트는 이러한 과정을 문서 내의 각 이미지마다 반복하게 된다는 것 입니다.

    즉 Resource에 과도한 영향을 미칠 수 있는 결과를 갖게 됩니다.

     

    장점을 간단히 말씀 드리면 클라이언트가 각 요청마다 새로 연결을 열지 않고, 열린 연결을 계속 유지하는 것입니다.


    자세한 내용은 아래의 링크를 참조하세요..^^

     

    Enabling HTTP Keep-Alives to Keep Connections Open (IIS 6.0)

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ko/library/iis/ea116535-8eb9-4c80-8b14-b34418dbfe42.mspx

     

     

    Top Ten Ways To Pump Up IIS Performance

    http://www.microsoft.com/technet/technetmag/issues/2005/11/PumpUpPerformance/default.aspx?loc=ko/

     

    성능에 대한 이슈는 어떤 APP든지 많은 시간을 투자해서 최적화 해야 할 텐데요.

    관련해서 아래의 링크들을 참조해 보시면 좋을 것 같습니다.


    성능 조정

    http://technet2.microsoft.com/WindowsServer/ko/Library/d92d338e-efdc-4e11-83a7-9af34c8bb5291042.mspx


    ConnectionTimeout 메타베이스 속성 (IIS 6.0)

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ko/library/iis/73566f83-c257-4941-8ed8-7ae45b2e7985.mspx

     

    Administering Network Resources (IIS 6.0)

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ko/library/iis/4998a9d1-3d36-4c10-bce0-01858985f1d7.mspx

     

    연결 시간 제한 설정

    http://technet2.microsoft.com/WindowsServer/ko/Library/98009b9c-9f7b-4aa4-b642-3d88e2f8812d1042.mspx


    2007년 10월 9일 화요일 오후 11:25
  • 일반적인 웹페이지가 아닌, 메세지 서비스용일 경우에도 연결유지옵션을 활성화 시키는게 좋을 듯 합니다.

     

    일반적인 생각으론 모든 클라이언트가 단 1번만 호출함으로, 굳이 연결유지를 시킬 필요가 있을까 생각이 들지만.

    연결유지를 하지 않고 서비스를 하는 경우

    대부분 서버에서 소켓 close가 먼저 호출되는 경우가 많습니다.

     

    다양한 클라이언트일 경우 서버에서 먼저 close할 경우, 클라이언트가 그냥 죽어 버리거나,

    정확한 흐름을 못타는 경우, 서버는 다량의 TIME_WAIT 상태에 빠질 가능성이 많습니다.

    초당 1000Request이상 호출될 경우, 아무리 tcpip parameter(TcpTimedWaitDelay)를 조정한다고 해도,

    최소 30초는 유지 됨으로 1000*30 = 30,000개의 tcp세션이 늘 남아 있게 되고, 조금만 과부하가 걸려도

    503오류가 빈번할 수 있습니다.

     

    연결유지옵션을 활성화 시켜 놓으면

    대부분 클라이언트측에서 close를 먼저 실행하게 되고( 연결유지시간을 한 5초정도 한다면)

    서버측에서 오류가 발생하더라도 5초후엔 close가 실행되기 때문에

    논리적으로도 tcp의 half-close구조에 좀더 부합되지 않나 싶습니다.

     

    경험상으로 봐도

    먼저 close한 측에 FIN_ACK에 대한 응답과정인 FIN_WAIT_1, FIN_WAIT_2가 발생하는 경우는 별로 없고

    FIN_ACK에 대한 ACK를 받은후 일정시간동안 상대방의 FIN_ACK를 받지 못해서(명시적으로 close 않해서)

    TIME_WAIT상태에 빠지는 경우가 많았습니다.

     

    사실 이 구조가 좀 헛갈리는 부분이 있긴 하죠~~

    한가지 저도 확인이 않되는 부분은

    연결유지를 한 상태에서

     

    웹페이지에서 response.end() 나 response.close()를 호출한 경우

    실제 tcp의 close 제어패킷인 FIN_ACK가 함수호출시점에서 날라가는지

    아님. 제 생각되로 연결유지제한시간 이 지난 후 날라가는지....

     

    이것만 확인되면,

    좀더 정확한 답변이 될것 같습니다.

    ( 시간을 내서 패킷 필터링을 해 봐야 겠네요...저도 너무 궁금함)

     

    그럼.

     

     

     

     

    2008년 1월 18일 금요일 오전 8:41
  •  

    웹페이지에서 response.end() 나 response.close()를 호출한 경우

    실제 tcp의 close 제어패킷인 FIN_ACK가 함수호출시점에서 날라가는지

    아님. 제 생각되로 연결유지제한시간 이 지난 후 날라가는지....

     

    => 함수 호출 후 날아갑니다. Call Stack을 보면 그렇습니다.

    만약 연결유지제한시간을 넘길동안 response.end()나 response.close()가 없으면, iis에서 response.close()를 호출합니다.

     

    2008년 1월 18일 금요일 오후 12:56