커널 모드 웹 서버 : 영리한 최적화 또는 보안 악몽?

한 사용자가 2011 년부터 IIS가 다른 (* nix) 웹 서버보다 훨씬 빠르다는 링크를 게시 하는 해커 뉴스 스레드를 읽었 습니다 . 또 다른 사용자는 IIS가 HTTP.sys라는 커널 모듈 을 사용하여 IIS가 이점을 얻는다고 설명하면서 대답 합니다 . 아시다시피, 2015 년에 가장 많이 사용되는 다른 웹 서버는 이것을하지 않습니다.

커널 모드 웹 서버를 작성하고 싶지 않을 것입니다. 보안 취약성 (낮은 보호 링에서 덜 심각하게 실행되지 않음)을 피할 수 없기 때문에 절대 신뢰할 수 없기 때문입니다.

소프트웨어 엔지니어의 관점에서 (웹 서버 고객과 달리) 커널 모드에서 실행하는 것이 현명한 성능 결정입니까? 커널 모드 서버를 소비자의 순이익으로 만드는 시점까지 애플리케이션 개발에서 보안 문제를 완화 할 수 있습니까?

— 제임스 미 슈라
소스

"서버 결함은 시스템 및 네트워크 관리자를위한 질문 및 답변 사이트입니다." Sysadmin 및 네트워크 관리자는 웹 서버를 작성 하지 않습니다 . 그들은 설치하고 유지합니다. 커널 모드 / 사용자 모드의 문제는 개발 시간보다 설치 시간보다 훨씬 관련성이 있다고 생각합니다. 질문이 더 관련성이 높은 곳으로 이동 한 것은 마음에 들지 않지만 Server Fault가 주제에서 찾지 못하는 것 같습니다.

— James Mishra

다시 질문을 다시 읽으면 기존 웹 서버의 장단점에 대한 질문이 아니라 일반적인 소프트웨어 아키텍처 질문으로 해석 될 수 있다고 생각합니다. 그래서 가까운 투표를 철회했습니다. 그러나 일반적인 소프트웨어 아키텍처 측면을 강조하기 위해 질문을 편집하는 것이 좋습니다.

— Doc Brown

이 컨텍스트 스위치가 없기 때문에 그 커널 모드 웹 서버 성능을 향상시킬 수 있다고 생각 누구나 읽어야합니다 모든 프로그래머가 알아야 대기 번호를 . Linux의 전체 컨텍스트 전환 비용은 약 3000ns ( source )이지만, 많은 syscall에는 실제로 전체 컨텍스트 전환이 필요하지 않으며 50ns만큼 낮아질 수 있습니다 .Windows에는 숫자가 없습니다. 이것은 2/3 열의 어딘가에 있습니다. 결론 : 네트워크 요청 및 디스크를 최소화하고 컨텍스트 전환에 대해 걱정하지 마십시오.

— Lie Ryan

답변:

Http.sys는 프록시 전달자만큼 웹 서버가 아닙니다. 많은 웹 서버가 Windows 상자에 공존 할 수 있도록 설계되었으므로 IIS는 웹 사이트를 실행하고 여러 WCF 서비스는 http / REST 또는 SOAP 인터페이스를 사용하여 표준 포트 80에서 실행할 수 있습니다. 약간의 흔들림없이 Windows에서 Apache를 실행할 수 없습니다. Apache는 이 등록 시스템에서 작동 하도록 수정 되지 않았 으므로 응용 프로그램에 더 투명하지 않고 연결하기 위해 매우 복잡한 수정이 필요합니다.

작동 방식은 URL과 해당 응용 프로그램에 URL을 등록하고 http 80이 포트 80에서 요청되면 http.sys는 해당 URL 대상을 처리하기 위해 등록 된 응용 프로그램으로 요청을 전달하는 것입니다.

커널 모드 웹 서버가 의미가 있다고 생각합니다.이 방법으로 소켓 성능을 향상시킬 수 있지만 유용한 작업을 수행하기 위해 응용 프로그램 논리가 여전히 사용자 공간에서 실행되므로 항상 전환이 있습니다. 그냥 호출 스택을 따라 조금 이동했습니다.

— bj
소스

커널 모드에서 전체 서버의 주요 이점은 정적 파일을 제공하는 것입니다. 이는 사용자 모드로 전환하지 않고도 수행 할 수 있습니다. 캐시도 가능합니다.

— Jules

HTTP.sys는 CPU 사이클이 훨씬 더 부족한 시대라고 생각합니다 ... 작은 정적 파일 (HTTP.sys의 가장 유리한 경우)을 제공 할 때조차도 완전한 사용자 모드 HTTP 서버는 아마도 대부분의 네트워크를 최대한 활용할 것입니다 .

— usr

@usr Http.sys는 Windows Server 2003에 도입 된 비교적 새로운 것입니다. 포트 80에서 동시에 수신하는 많은 웹 API 서비스를 실행할 수 있습니다.

— gbjbaanb

@gbjbaanb 사용자 모드 서버도 가능합니다. Windows는 메모리 (버퍼 용)를 공유하고 소켓 핸들을 다른 프로세스로 전달할 수 있습니다.

— usr

@JamesMishra 내 마음에, 네. 당시 CPU는 아마도 10 배 이상 강력하지 않았습니다. 또한 보안 사고 방식은 실제로 없었습니다. 오늘은 나쁜 전화입니다.

— usr

Http.sys는 사용 가능한 유일한 커널 모드 웹 서버가 아닙니다 : Linux에는 tux도 있습니다. 올바르게 식별했듯이 보안은 이러한 종류의 서버에서 문제가되므로 주 리눅스 커널에 tux가 포함되지 않았습니다 (그리고 더 최신 커널 버전으로 업데이트되지 않았다고 생각합니다).

더 나은 솔루션은 프로세스 보안을 강화하기 위해 하드웨어 보호에 의존하지 않는 운영 체제를 사용하는 것입니다 (예 : Microsoft의 특이성). 이러한 시스템은 보안 위험없이 커널 모드 서버의 효율성을 높일 수 있습니다. 불행하게도, 2015 년 기준으로이 원칙을 기반으로 한 생산 준비 운영 체제를 사용할 수 없으며 AFAIK는 어느 쪽도 진지하게 작업하지 않습니다 (Singularity 프로젝트가 취소됨).

— 줄스
소스

특이점 접근 방식의 큰 문제는 JITter에서 a가 권한 상승으로 쉽게 이어질 수 있음을 의미합니다.

— 코드 InChaos

Tux Wikipedia 기사는 흥미로운 기사입니다. Tux는 정적이 아닌 컨텐츠에 대한 HTTP 요청을 Apache와 같은 "실제"웹 서버로 전달할 수 있는데, 이는 Http.sys가 사용되는 것처럼 들립니다. Tux가 Http.sys만큼 성능이 좋은지 알 수 없지만, 읽은 내용을 기반으로 Linux 커널 개발자가 Microsoft의 결정에 크게 동의하지 않는 것처럼 들립니다.

— James Mishra

Http.sys는 타사에서 제공 한 대처 방법을 실행할 수 없으므로 위험이 낮습니다.

Http.sys는 몇 가지 작업을 수행합니다.

프록시 전달자 역할을하므로 여러 프로세스가 HTTP 네임 스페이스의 다른 부분에 대한 요청에 응답 할 수 있습니다. gbjbaanb 답변이 이것을 잘 다룹니다.
Windows 파일 캐시에서 직접 정적 파일을 제공합니다. 컨텍스트 스위치가 없기 때문에 작은 파일 정적 파일의 속도를 크게 향상시킵니다.
HTTP 요청을 전달하는 모든 응용 프로그램의 출력을 캐시하고 캐시 된 결과를 반환합니다. 응용 프로그램은 캐싱 지속 시간 (있는 경우)을 완전히 제어 할 수 있습니다.

Http.sys는 간단한 작업을 매우 빠르게 수행하면서 사용자 공간의 프로세스에 다른 모든 것을 전달하도록 설계되었습니다.

의견에 대한 답변

"타사에서 제공 한 코드를 실행할 수 없으므로 위험이 적습니다."-항상 그렇게 말합니다. 거의 사실이 아닙니다.

문제는이 질문을하기 위해 복잡한 커널 코드를 작성하려면 Microsoft를 신뢰해야한다는 것입니다. 그렇지 않으면 웹 호스팅에 창을 전혀 사용하지 않기로 결정 합니다 . Http.sys는 커널의 복잡도를 고려할 때 커널 버그의 위험을 거의 추가하지 않습니다.

Http.sys가 위험을 줄인 경우“낮은 수준의”웹 제공 및 응용 프로그램 코드 아래에 분명하게 구분되어 있기 때문입니다.

잘 설계된 설정에서 웹 서버를 실행하는 시스템 (또는 가상 서버)은 위험이 높은 대상이므로 나머지 네트워크에 대한 액세스는 매우 제한적입니다. 커널이나 사용자 모드 웹 서버가 해킹되면 서버에 네트워크에 대한 "권한"이 없어야하므로 웹 서버 사용자 모드 프로세스가 작업을 수행해야합니다.

— 이안
소스

사용자 모드 응용 프로그램은 대부분의 메모리 손상 기반 버그 (일반적으로 원격 코드 실행을 유발하는 버그)를 배제하는 형식 안전 언어로 작성됩니다.

— 코드 InChaos

내가 커널 코드를 작성하도록 Microsoft를 신뢰한다면 커널 모드 웹 서버 코드를 작성하는 것을 신뢰하는 것은 약간의 도약이라는 주장을 삽니다. 정보 보안 관점에서 상당히 순진하지만, Http.sys에서 버퍼 오버플로를 무기화하는 것이 장치 드라이버 또는 인터넷에서 멀리 떨어진 커널의 다른 부분보다 훨씬 쉽다고 생각합니다.

— James Mishra