국내 보안솔루션 시장이 안정적인 성장기에 접어듦에 따라 각종 포인트 솔루션에 대한 관리의 중요성이 부각되고 있다. 이에 따라 금융권, 통신사업자, 공공기관을 중심으로 이기종 보안솔루션을 중앙에서 하나의 콘솔로 관리하는 ESM(Enterprise Security Management) 솔루션의 수요가 크게 증가하고 있으며, 새롭게 제품을 선보이는 업체도 급증하는 추세다. 올해 국내 보안솔루션 시장에서 가장 높은 성장률을 기록할 것으로 지목된 ESM 시장은 본격적인 개화기를 넘어, 선두진영과 후발업체간의 격차가 가시화되는 2단계에 접어들 전망이다.

과거 아날로그 시기에는 보안이 그저 자물쇠와 같은 물리적인 시설을 이용한 ‘방범’ 정도의 개념으로 간주됐지만, 디지털 시대에서는 보안이 보다 근본적인 삶과 연관된다. 개개인의 프라이버시와 기업보안은 디지털 경제의 필수사항이며, 보다 체계적이고 강력한 보안을 확보하는 자가 성공을 보장받을 수 있다. 즉 디지털 경제에서 보안은 선택이 아니라 가장 기초적인 인프라인 셈이다.

올해 최고 성장종목으로 ‘ESM’ 지목

이러한 우려 탓인지 해마다 보안 솔루션 시장은 급성장을 거듭하고 있다. 여러 시장기관의 자료를 종합해 본 결과, 지난해 전 세계 보안솔루션 시장은 64억달러(약 8조3,200억원)를 기록, 2000년 대비 24% 가량 성장한 것으로 나타났다. 국내 보안 시장은 세계 시장보다 성장 속도가 더 가파르다. 지난해 국내 보안 솔루션 시장은 대략 1,470억원 규모로 집계돼 2000년 대비 54%의 성장률을 기록했으며, 보안 서비스 시장도 186억원에 달해 점차 비중이 높아지고 있는 추세다.

특히 지난해 국내 보안솔루션 시장은 예년과는 사뭇 다른 양상을 보였다. 안티바이러스와 방화벽이 여전히 높은 비중을 차지하고는 있지만 그 성장률이 점차 둔화되는 반면, 침입탐지시스템(IDS), 가상사설망(VPN), 공개키기반(PKI), 통합인증 및 권한관리(EAM), 생체보안솔루션 등 새롭게 주목받는 솔루션이 대거 등장한 것.

IDS 솔루션은 ‘K4인증’이라는 훈풍을 받아 지난해 하반기 부터 가장 잘 나가는 보안솔루션으로 맹위를 떨쳤으며, PKI 기반의 인증 솔루션과 VPN 등 2세대 보안솔루션으로 불리는 네트워크 보안솔루션도 금융권과 공공시장을 강타하며 국내 보안솔루션 시장의 다원화를 더욱 부추겼다.

이와 같은 시장 상황과 비례해 국내 보안업체의 수도 이미 200여개를 넘어설 정도로 급증했다. 가장 많은 신생업체가 등장한 분야는 역시 시장의 관심을 반영하듯 IDS와 VPN이다. 이미 2000년 말부터 대거 등장하기 시작한 이들은 전체 보안시장의 선도업체들이 간과한 틈새시장을 공략하던 전략에서 벗어나 대범하게 선도업체와의 정면승부에 나서는 등 나름대로 시장활성화에 상당부분 기여하는 중이다.

보안솔루션 시장이 이처럼 안정적인 성장 궤도에 진입함에 따라 각각의 포인트 솔루션을 통제할 수 있는 관리 솔루션에 대한 요구도 급증하고 있다. 현재 국내 전산환경은 구축된 보안솔루션 종류만 해도 한 두 가지가 아닌데다가 싱글벤더 제품보다는 멀티벤더 제품으로 구성된 사례가 더 많아 보안전담 오퍼레이터가 있는 기업마저도 보안관리가 어려울 정도다.

대부분의 컨설턴트들은 아무리 다양한 보안솔루션을 도입해 그물망 같은 보안정책을 추진한다 할 지라도 정작 그에 대한 관리가 이뤄지지 않는다면 무용지물이나 다름없다는 지적과 함께 관리포인트의 최소화를 통한 효과적인 관리의 필요성을 역설하고 있다. 즉 관리만 제대로 한다면 라우터 하나만으로도 충분히 보안정책을 수행할 수 있지만, 이미 다양한 솔루션을 도입한 상태라면 보다 체계적인 관리 정책이 필요하다는 것.

이에 따라 이기종 보안솔루션을 중앙에서 하나의 콘솔로 관리하는 전사적보안관리(ESM; Enterprise Security Management) 솔루션이 급부상하고 있다. 이미 다양한 보안솔루션이 도입된 금융권, 통신사업자, 공공기관을 중심으로 그 수요가 크게 증가하고 있으며, 새롭게 제품을 선보이는 업체도 더욱 확산되는 중이다.

비록 지난해 국내 ESM 시장규모는 60억원 정도에 불과했지만, 올해에는 2배 이상 급증할 것이라는 전망이 나오는 것도 이러한 이유에서다. 이미 업계에서는 ESM을 올해 가장 높은 성장을 기록할 보안솔루션으로 지목하고 있어, 올해부터는 본격적인 선두경쟁이 시작될 전망이다.

이글루시큐리티, 초기 ESM 시장 ‘리드’

현재 국내 ESM 시장에서 가장 적극적인 활동을 보이고 있는 업체는 이글루시큐리티(대표 이득춘)다. 이글루시큐리티는 자사의 관제서비스 제공을 목적으로 개발한 관제툴을 ESM으로 발전시켜, 별도의 보안관제시스템을 구축하려는 금융권과 대기업을 우선 공략하는 방식으로 초기 시장의 주도권을 잡는 데 성공했다.

지난해 캐나다의 스토리지ASP와 필리핀의 넷엑스테크놀로지스에 ESM 솔루션인 ‘스파이더-1’을 수출하면서 세계 시장으로의 진출을 먼저 시도했던 이글루시큐리티는 삼성카드, 신한은행, 대검찰청, 데이콤, 한국자동차공업협회 등에 제품을 잇따라 공급하는 등 국내 시장에서 가장 돋보이는 행보를 거듭하고 있다.

특히 체크포인트의 ‘파이어월-1’을 비롯해 국내외 9개사의 방화벽, 2개사의 안티바이러스, 6개사의 IDS, 3개사의 VPN, 3개사의 서버보안솔루션, 3개사의 컨텐츠 시큐리티, 1개사의 메일 시큐리티 등 총 29개사의 보안솔루션과 연동이 가능한 ‘스파이더-1’은 지난해 체크포인트의 OPSEC 인증까지 획득, 해외 시장 개척에서도 유리한 입지를 구축해 놓은 상태다. 특히 최근 미국과 중국 기업들을 대상으로 제품소개를 마친 결과 긍정적인 반응이 쏟아지고 있어 OEM 등을 통한 수출도 가능할 전망이다.

진정기 이글루시큐리티 마케팅전략팀 부장은 “포인트 솔루션이 어느 정도 도입되고 나면 그 다음부터는 관리 제품들이 등장하기 마련이다. 그리고 다시 관리 제품이 성숙되면, 포인트 솔루션을 관리하기 위한 통합관리 측면에서 고객지향적으로 변화하게 된다. 즉 고객을 분석하고 고객을 세분하는 형식의 CRM 개념으로 접근하는 셈이다. 이는 곧 단순 관리에서 분석으로 넘어간다는 것을 의미한다. 현재 스파이더-1은 이러한 분석 단계에 들어서고 있다”고 말했다.

이글루시큐리티는 지난해 ESM분야에서만 전체 매출의 25%를 기록하는 등 ‘스파이더-1’의 기여도가 점차 확대됨에 따라 지난해 하반기경 대대적인 조직개편을 시행했으며, 최근에는 기존의 직판 영업 체제를 채널 중심의 영업 체제로 전환, 본격적인 영업 다변화 정책을 추진 중이다. 이글루시큐리티의 이러한 정책 전환은 올해 매출목표 120억원 가운데 60억원을 순수 ESM 매출로 책정해 놓은 상태여서, 양적인 매출액보다는 수익성 위주의 실질적인 영업 구조로 개편하기 위한 전략으로 풀이된다.

보안솔루션 업체, 이기종 지원 능력 ‘아직은 역부족’

관제 서비스 업체들이 효율적인 관제 서비스 제공을 의해 불가피하게 ESM 혹은 IMS(Integrated Management System) 솔루션을 개발했다면, 윈스테크넷을 비롯해 어울림정보기술, 시큐어소프트, 인젠, 시큐아이닷컴 등 현재 ESM 솔루션을 확보하고 있는 업체들은 IDS, 방화벽 등 자사의 보안솔루션 관리 기능 강화가 1차적인 목표였다고 할 수 있다. 이러한 점에서 보안솔루션 벤더들의 ESM 솔루션은 이기종 지원이나 성능 면에서는 아직 관제 서비스 업체 제품에 비해 개발 과정이 더디게 진행되고 있는 편이다.

윈스테크넷(대표 김대연)이 지난해 초 시장에 선보인바 있는 ‘스나이퍼 ESM’은 행정자치부, 정보통신부, 대신증권 등에 공급돼 운영되고 있지만, 모두 윈스테크넷의 IDS인 ‘스나이퍼’의 관제서비스를 위한 것일 뿐, 이기종 보안솔루션과의 연동 작업을 위한 도입은 아닌 것으로 알려졌다. 비록 지난달 ‘스나이퍼 ESM’의 차기버전을 발표했지만, 이 제품 역시 해당 개발자가 퇴사하는 과정에서 문제점이 많이 지적돼 다시 처음부터 개발한 솔루션에 불과해 본격적인 ESM 경쟁제품이라고 보기에는 무리가 있다.

현재 윈스테크넷의 ‘스나이퍼 ESM’은 리눅스시큐리티의 바이몬을 비롯해 시큐어웍스, 시큐아이월, 시큐웨이게이트 등 4개의 방화벽과 해커스랩의 ‘N-패트롤’, 이글루시큐리티의 ‘스파이더-1’, HP의 ‘오픈뷰’, IBM의 ‘티볼리’ 등 4개의 관제지원 프로토콜을 지원한다.

별도로 ESM팀을 운영할 정도로 ESM에 상당한 관심을 기울이고 있는 어울림정보기술(대표 장문수)의 ‘시큐어웍스ESM’도 현재로서는 일부 회사의 방화벽과 VPN을 지원하는 수준이어서 진정한 의미의 ESM이라고 하기에는 부족하다. 하지만 지난해 10월 행자부 테스트를 거쳐 행자부에 공급되는 등 꾸준히 시장에서 반응을 보이고 있어, 안정화 작업 및 연동 제품 확대를 위한 개발에 역량을 집중시킨다는 방침이다.

지난해 대한생명, 조달청 등에 공급되면서, 약 10억원의 매출을 기록한 시큐어소프트(대표 김홍선)의 ‘수호신ESM’ 역시 자사 제품 번들로 공급된 사례가 대부분이다. 파이어월-1이나 리얼시큐어와 같은 제품과의 연동이 가능하기는 하지만, 역시 주요 성능은 자사 제품의 관리인 셈이다.

하지만, 시큐어소프트는 올해 커스터마이징 지원 강화, 이기종 보안시스템과의 연동, 개별 보안시스템의 보안정책 설정 기능 제공 등을 통해 한 단계 업데이트된 제품을 선보인다는 방침이다. 이와 동시에 웹 플랫폼을 채택, 언제 어디서든 ESM 콘솔에 접속 가능토록 할 계획이다. 시큐어소프트는 올해 공공, 금융 시장을 주 타깃으로 20억원 이상의 매출 달성을 목표로 하고 있다.

EMS 솔루션, ESM 통합 움직임 활발

이처럼 국내 보안솔루션 업체들이 이기종 멀티벤더 솔루션 통합에 관심을 기울이는 동안, 전사적관리솔루션(EMS) 벤더들의 보안솔루션 관리 통합 작업도 상당한 진전을 보이고 있다. 이 가운데 특히 주목받는 솔루션이 바로 한국IBM(대표 신재철)의 ‘티볼리 리스크 매니저’다.

이 제품은 지난해 10월 안철수연구소의 안티바이러스, 펜타시큐리티시스템의 IDS, 어울림정보기술의 방화벽, 인포섹의 침해사고대응서비스, 데이타게이트인터내셔널의 취약성분석 및 평가 솔루션 등과 연계된 패키지를 국내 시장에 선보이며, 강력한 보안관리 기능을 과시한 바 있다.

특히 티볼리 리스크 매니저는 중앙관리 보안환경은 물론 이벤트의 유사성, 연관성을 내부 지능형 로직에 따라 필터링을 제공, 보안침해 사고 시 폭주하는 이벤트로부터 모든 보안 대상 자원을 하나의 관리 콘솔만으로 관리할 수 있어 사실상 ESM 솔루션의 대부분의 기능이 탑재돼 있는 상태다. 한국IBM은 6개 국내 보안솔루션 업체와의 통합보안관리솔루션 패키지 발표를 계기로 적극적인 시장 진입을 시도하고 있는 중이며, 향후에도 지속적으로 국내 업체들과의 제휴를 통해 인티그레이션을 더욱 강화한다는 전략이다.

김욱 한국IBM 티볼리사업부 차장은 “여러 프로젝트를 들어가다 보면 이기종 보안툴에 대한 연동을 요구하는 사례가 종종 있다. 티볼리 리스크 매니저는 이와 같은 포인트 솔루션을 통합관리하는 툴로서, 키(key)가 되는 제품을 육성하는 본사 차원의 노력이 진행되고 있다. 현재 티볼리 리스크 매니저는 인증관련 툴인 티볼리 폴리시 디렉터와 서버보안 제품인 티볼리 시큐리티 매니지먼트 제품과의 통합작업도 추진 중이다”라고 말했다.

이 밖에 아직은 SMS 통합 성향이 짙은 컴퓨터어쏘시에이트, BMC소프트웨어 등도 전사적관리솔루션 통합 차원에서 통합보안관리 기능을 일부 제공하고 있으며, 국내 6개 보안업체와의 제휴를 통해 보안관리까지 영역 확장을 시도하고 있는 HP의 오픈뷰는 직접적인 보안관리툴 개발을 추진할 계획은 없는 것으로 알려졌다.

컨트롤 기능 강화된 2세대 ESM 등장 ‘초읽기’

ESM에 대한 관심이 이처럼 급격히 증가하고 있는 것은 사실이지만, 현재 시장에 출시된 ESM 솔루션은 보완할 사항이 더 많다. 보안솔루션 벤더들이 내놓은 ESM은 자사 제품에 대한 통합 운영 및 관리 기능은 탁월하지만 타사 제품에 대해서는 하나의 콘솔로 원격관리나 단순 로그분석 기능 정도를 제공하는 수준이고, 보안 관제서비스 업체들의 ESM은 관제를 목적으로 개발된 툴에 필요한 기능을 추가하는 방식으로 발전해 온만큼 관제 중심의 ESM의 틀을 벗어나지 못하는 상황이다.

SMS/NMS 업체들이 제공하는 ESM 역시 크게 다르지 않다. 이들의 ESM 기능 역시 자사의 SMS/NMS 시스템에 보안기능 또는 위험 관리기능을 추가해 통합보안관리를 추구하고 있기 때문에 SMS 및 NMS 기능에 비해 보안관리 기능은 상대적으로 떨어지는 단점이 있다.

이에 따라 최근 일부 솔루션벤더를 중심으로 2세대 ESM에 대한 논의가 활발하게 전개되고 있다. 즉 처음부터 대용량에 대한 통합보안관리를 위해 안정성과 확장성을 고려하고, 관제와 운영/관리를 기준으로 개발된 ‘2세대 ESM’ 개발이 초읽기에 들어간 것이다. 현재 출시된 ESM이 이벤트나 로그분석을 통한 모니터링 정도의 1.5세대 ESM이라면, 인젠과 시큐아이닷컴, 시만텍이 올해 선보이고자 하는 제품은 바로 세부적인 컨트롤 기능이 탑재된 ‘2세대 ESM(뉴 ESM)’ 솔루션이다.

물론 인젠(대표 임병동)의 ESM 솔루션인 ‘네오어드민@ESM’은 현재 연동 가능한 솔루션이 자사 제품을 제외하면 파이어월-1, 리얼시큐어, 수호신, 넷스크린 정도에 불과하고, 일부 컨피그레이션 컨트롤이 가능한 시큐어웍스2.0이나 폴리시 일부 수정이 가능한 리얼시큐어를 제외한 나머지 솔루션에 대해서는 여타 업체와 마찬가지로 이벤트 관리 수준에 머물고 있다.

하지만 인젠이 5월경 1차 버전을 출시할 예정인 2세대 ESM은 이러한 한계를 뛰어넘어 운영관리 기능이 한층 강화될 전망이다. 인젠은 현재의 ESM으로는 확장성과 안정성에서 향후 시장을 책임지기에는 부족하다는 판단 하에, 관제와 운영관리, 확장성, 표준 인터페이스까지 구현 가능한 제품을 준비중이다.

김형률 인젠 ESM 사업본부 ESM 컨설팅팀 수석은 “제품 개발을 위해 지난해 나왔던 ESM 프로젝트를 모두 조사해 봤다. 이 프로젝트를 기반으로 표준집합을 만들고, 다시 ESM이 나아가야 할 전략적인 방향을 살펴봤다. 그리고 나서 인젠만의 방향을 추가시키고, 이들을 연결시키는 작업을 마친 뒤 현재 제품의 스펙을 맞춰놓은 상태다. 이번에 나오는 제품은 각사 제품의 장점을 모두 흡수하고, 확장성과 안정성을 바닥에 깔아놓은 점이 특징이다”고 말했다.

인젠·시큐아이닷컴·시만텍, 2세대 ESM 개발 앞장

특히 그는 아예 병렬시스템으로 구성 가능한, 즉 가장 적은 서버로 가장 많은 적용이 가능하도록 플랫폼 자체를 다시 만들었다고 설명했다. 전구간 암호화 통신은 기본적인 옵션이 될 것이며, 그룹 관리 등 다양한 고객의 요구사항이 모두 적용되는 형태가 될 것이라는 점도 덧붙였다. 모든 연동 제품에 균등한 관리가 가능한 제품, 그것이 바로 인젠이 새롭게 출시할 예정인 뉴 ESM의 모습이다.

인젠은 이 제품 출시를 계기로 국내 ESM 시장에서의 돌풍을 기대하고 있다. 세부적인 컨트롤을 요구하는 중소기업의 경우 기존 ‘네오어드민@ESM’을 여전히 전진배치할 계획이지만, 대기업이나 금융권처럼 포괄적인 연동 및 균등한 컨피그레이션 컨트롤을 요구하는 시장은 뉴 ESM으로 접근할 방침이다.

인젠과 마찬가지로 시큐아이닷컴(대표 오경수) 역시 감시와 감사 수준의 ESM의 틀을 벗어나 이기종 솔루션 제어로까지 범위를 확장하고 있다. 시큐아이닷컴의 ESM 솔루션인 ‘시큐아이ESM’의 경우 현재 체크포인트, 넷스크린, 시스코 등 총 20개 이상의 보안솔루션과 연동이 가능하지만, 단순 모니터링과 오디팅 정도의 컨트롤만으로는 부족하다는 입장이다.

따라서 시큐아이닷컴이 선택한 해결책은 바로 표준 프로토콜. 비록 여타 업체의 협력 여부가 가장 큰 변수가 되겠지만, 현재로서는 일부 업체에서도 호의적인 반응을 보이고 있어 일정 수준의 2세대 ESM으로의 전이는 가능할 전망이다.

다만 시큐아이닷컴의 의도대로 상당수의 솔루션 제어까지 가능한 ESM 개발은 좀 더 지켜봐야 할 것으로 판단된다. 산업 표준 아키텍처 및 표준 API 개발을 위해 구성된 정보보안 그랜드컨소시엄인 ‘세인트(Security Alliance for Information Network & Technology)’나 ‘비스타(Vanguard of Information Security Technology Alliance)’마저도 유명무실한 상태인데다가, 시큐아이닷컴 주도의 표준화에 경쟁업체들이 적극적인 동조를 보여줄 지 여부도 불확실하기 때문이다.

특히 표준 API 개발을 적극 추진해 오던 어울림정보기술이 여전히 정체상태에 머물고 있고, 표준 API 개발을 검토하던 인젠 역시 방향을 선회했다는 점은 분명 주목할만한 점이다. 이를 보완하기 위해 시큐아이닷컴은 현재 협력 관계인 HP의 오픈뷰를 적극 활용한다는 복안을 내놓은 상태다.

올해 들어 연이은 신제품 발표와 함께 사업 영역을 급속히 확장 중인 시만텍코리아(대표 최원식)도 연말경에는 2세대 ESM 제품으로 국내 영업을 시작할 계획이다. 오는 6월경 본사 차원에서 시작할 예정인 ‘SESA’ 제품이 바로 그것. 시만텍은 ‘SESA’가 현재로서는 시만텍 제품 관리나 일부 제품에 한해 컨피그레이션 컨트롤이 가능한 정도지만, 연말경에는 보다 다양한 솔루션과 하드웨어 지원까지 가능할 전망이라고 밝혔다.

ESM 시장 신규 진입 업체 줄이어

2세대 ESM 제품 개발과 함께 국내 ESM 시장에 가장 주목할 만한 변화는 신규 시장 진입 업체가 속속 등장하고 있다는 점이다. 올해 초 의미없는 이벤트와 실제 의미있는 침입 패턴을 구분해 관리할 수 있는 MAE(Meta Analysis Engine) 기술 기반의 ESM인 ‘SEMS(가칭)’를 발표한 한시큐어(코코넛에 인수)에 이어, 지난달 보안컨설팅 전문업체인 마크로테크놀러지(대표 이성만)가 ‘비캠프(BeCAMP)’를 출시했으며, 연말경 안철수연구소도 ESM 솔루션 발표를 계획 중이다.

특히 이번에 마크로테크놀러지가 발표한 ‘비캠프’는 최근 ESM의 트렌드를 입증하기라도 하듯 시스템 통합 분석에 따른 일원화된 보안 정책 수립 기능을 강화했다. 게다가 공격자의 위치를 역추적할 수 있는 기능 탑재는 물론 NMS 및 SMS(System Management Solution)로까지 활동 영역을 확장함에 따라 후발주자로서의 단점을 제품 성능으로 타파한다는 전략이다.

보안 관제서비스 제공업체들의 신규진입도 점차 가시화되고 있다. 넷시큐어테크놀로지는 자사의 관제툴을 기반으로 6월경 모듈타입의 ESM 솔루션을 출시할 예정이며, 해커스랩과 코코넛도 자사의 통합 관제툴의 상용화를 적극 검토하고 있는 것으로 알려졌다.

최근 보안 관제서비스 시장에서 급부상 중인 넷시큐어테크놀로지(대표 배영훈)가 막바지 작업에 한창인 ESM은 관제서비스에 특화된 솔루션으로, NMS와 SMS(System Management Solution) 모니터링까지 주요 기능에 포함돼 있으며 리포팅 기능이 특히 강화될 예정이다.

정보보호전문업체 지정 이후 크게 주목받고 있는 해커스랩(대표 김창범)도 ESM 기능이 탑재된 통합관리모듈인 ‘N-패트롤’의 상용화를 적극 검토중이다. SOC(Security Operation Center)용으로 개발된 이 제품은 이미 LG-EDS 관제센터, 한국증권전산, 한국통신 등에 도입돼 사용되고 있지만, 그 동안 단독 솔루션으로 공급되지는 않았던 게 사실이다. 하지만 최근 ESM에 대한 관심이 급증하고 있어 조만간 독립된 솔루션 패키지로 시장에 선보일 계획이다.

하지만 상반기 내에 자사 관제툴의 차세대 버전을 출시할 계획이었던 코코넛(대표 조석일) 한시큐어 인수로 인해 ESM 시장 진입 시기가 불확실해졌다. 이번에 인수한 한시큐어가 올해 초 ESM 솔루션인 ‘SEMS(가칭)’을 발표함에 따라 이 제품의 처리 문제가 남았기 때문이다. 비록 코코넛이 그 동안의 관제 노하우를 기반으로 자체 관제툴을 보유하고 있기는 하지만, 그렇다고 애써 개발해 놓은 한시큐어의 ESM을 그대로 사장시킬 수도 없는 노릇. 이에 따라 코코넛은 현재 양사 솔루션의 통합을 조심스럽게 검토하고 있는 것으로 알려졌으며, 법인 통합이 완료되는 4월 중순 경 가시적인 방안을 내놓을 방침이다.

반면 사이버패트롤과 인포섹은 비록 ESM 기능의 관제툴을 확보하고는 있지만, 시장 진출은 불투명한 상태다. 인포섹은 보안 관제툴을 티볼리 제품군으로 전환해 현재 서비스를 진행 중이어서 사실상 ESM 시장 진입은 어려울 전망이며, 사이버패트롤 역시 최근 인젠과의 매각협상이 추진중인 것으로 밝혀져 단독 ESM 제품 출시의 가능성은 희박한 편이다.

상호 협력, 시장 활성화의 ‘관건’

ESM에 대한 관심이 이처럼 급격히 증가하고 있는 것은 사실이지만, 아직 시장이 본격화됐다고 평가하기에는 이르다. 금융권이나 일부 공공기관 및 대기업, 통신사업자 정도를 제외하면 여전히 상당수의 기업들은 안티바이러스나 방화벽과 같은 1차적인 보안솔루션만을 구비해 놓은 상태이고, 여전히 IDS, PKI, VPN 등 포인트 솔루션 도입에 보다 적극적이기 때문이다. 여기에 보안솔루션이 평균적으로 6개월에 한 번 정도 업그레이드된다는 사실은 ESM 솔루션의 확산에 상당한 장애물이 되고 있다.

하지만 무엇보다도 가장 큰 문제점으로 지적되는 것은 국내 보안솔루션 업체간의 상호 협력 부분이다. ISS, 시스코 등 세계적인 보안솔루션 업체들이 서로 앞다퉈 API를 개방하고 있고, 체크포인트도 현재의 OPSEC보다 확장된 개념의 API 개방을 검토하고 있다는 점은 그만큼 서로간의 협력이 ESM 시장 성패의 열쇠일 뿐 아니라 자사 솔루션 확장의 지름길이기 때문이다.

현재 국내 보안솔루션 업체들의 협력은 단순 채널영업을 위한 제휴나 이벤트 관리 수준의 연동에 불과하다. 산업 표준 아키텍처 및 표준 API 개발을 위해 구성된 정보보안 그랜드컨소시엄인 ‘세인트’나 ‘비스타’가 유명무실한 상태로 1년 넘게 지속되고 있는 것도 이와 같은 맥락으로 풀이할 수 있다.

일부 솔루션을 제외하면 국내 보안 기술은 분명 세계 시장에 일정정도 뒤져있는 게 사실이다. 그리고 국내 보안 시장 역시 세계 시장에 비해 협소하고, 늦은 감이 없지 않다. 다만 국내 보안시장의 성장률이 세계 시장의 평균 성장률을 앞서고 있고, 기술 격차도 빠르게 좁혀지고 있다는 점은 주목할 만 하다.

특히 ESM 솔루션의 경우 아직 미국 시장에서조차 시작 단계이기 때문에 제품 성능이나 진출 시기 등에 따라 충분히 경쟁력을 발휘할 수도 있을 것으로 기대된다. 이를 위해 적어도 국내 업체들간의 적극적인 협조는 가장 기초적인 전제 조건인 셈이다.

[미니 인터뷰] 진정기 이글루시큐리티 마케팅전략팀 부장

분석력 강화된 ESM으로 국내외 시장 ‘동시 공략’
보고서기능 보강 등 고객지향적 발전방향 제시 … 올해 미국·일본·중국 진출 가시화

ESM의 기술 동향은.
포인트 솔루션이 어느 정도 도입되고 나면 그 다음부터는 관리 제품들이 등장하기 마련이다. 그리고 다시 관리 제품이 성숙되면, 포인트 솔루션을 관리하기 위한 통합관리 측면에서 고객지향적으로 변화하게 된다. 즉 고객을 분석하고 고객을 세분하는 형식의 CRM 개념으로 접근하는 셈이다. 이는 곧 단순 관리에서 분석으로 넘어간다는 것을 의미한다. 현재 스파이더-1은 이러한 분석 단계에 들어서고 있다.

스파이더-1의 발전 방향은.
현재의 ESM은 이기종 솔루션을 연동하는 데에 중점을 두고 있지만, 고객지향적으로 진행될 경우 보고가 중요해진다. 서로의 로그를 분석해서 상호연관관계를 보고해야 하고, 이러한 보고서는 각종 이벤트나 로그에 대한 분석 및 판단 근거 자료가 된다. 스파이더-1 역시 보고서에 대한 부분을 강화하는 중이다.

실제로 프로젝트를 진행하다보면 부하가 가장 많이 걸리는 부분이 보고서다. 해당 업체들이 자신들의 보고서 양식에 따라 커스터마이징을 요구하기 때문이다. 올해 새롭게 출시될 차기 버전에는 이와 같은 보고서에 대한 부분이 보다 다양화되고, 표준화될 예정이다.

올해 주요 계획은.
최근 이글루는 미국을 순회하고 왔다. 돌면서 반응을 지켜본 결과 상당히 호의적인 반응을 보였다. 이에 따라 현재 OEM 수출도 고려 중이며, 싸이버텍홀딩스와의 관계를 최대한 활용해 올해 미국시장에 본격적으로 진출할 계획이다.

이와 동시에 중국과 일본 시장 진출도 올해에는 가능할 것으로 기대된다. 일본의 경우 이들이 요구하는 사항에 대해 현재 연구가 진행 중이며, 만약 그러한 기능이 지원만 된다면 곧바로 물량이 쏟아질 전망이다.

이글루는 이와 같은 해외시장 개척과 더불어 내실을 다지는 차원에서 올해부터는 채널 마케팅을 적극 전개할 방침이다. 이글루의 채널들이 각 사가 확보하고 있는 고객들을 대상으로 통합 마케팅을 진행할 경우 스파이더-1 매출 향상에 커다란 도움이 될 것이기 때문이다. 이를 토대로 올해 이글루는 스파이더-1의 매출을 60억원까지 끌어올릴 것이다.


[미니 인터뷰] 김형률 인젠 ESM 사업본부 ESM 컨설팅팀 수석

“2세대 ESM 시장의 강자가 진정한 승자”
5월경 신개념 ESM 발표 예정 … 중소기업·대기업 분할 공략

2세대 ESM의 개발 동기는.
네오어드민@ESM으로 프로젝트를 진행하다보니, 한 제품으로 관리할 수 있는 솔루션의 한계를 느꼈다. 서버가 많거나 네트워크 부하가 유난히 많은 지역과 같은 경우 말이다. 현재의 ESM으로는 다시 이러한 ESM 제품을 관리하는 솔루션까지 등장할 수도 있다는 생각을 했다. 즉 현재로서는 방화벽이나 IDS 몇대가 도입된 사이트가 많기는 하지만 이 제품군들이 더욱 확장될 경우 현재의 ESM으로는 확장성과 안정성에서 향후 시장을 책임지기에는 부족하다는 판단을 한 것이다.

인젠은 관제와 운영관리, 확장성, 표준 인터페이스까지 가능한 제품으로 접근하자는 차원에서 뉴 ESM을 개발하고 있다. 이 제품은 오는 5월경 1차 버전이 나올 예정이며, 9월경에는 실질적인 상용시스템이 출시될 계획이다. 비록 처음에는 관제서비스 업체와 유사한 형태가 되겠지만, 향후에는 운영관리가 탁월한 제품이 될 것이다.

인젠이 개발 중인 뉴 ESM을 소개하면.
제품 개발을 위해 지난해 나왔던 ESM 프로젝트를 모두 조사한 적이 있다. 이 프로젝트를 기반으로 표준집합을 만들고, 다시 ESM이 나아가야 할 전략적인 방향을 살펴봤다. 그리고 나서 인젠만의 방향을 추가시키고, 이들을 연결시키는 작업을 마친 뒤 현재 제품의 스펙을 맞춰놓은 상태다. 이번에 나오는 제품은 각사 제품의 장점을 모두 흡수하고, 확장성과 안정성을 바닥에 깔아놓은 점이 특징이다.

특히 아예 병렬시스템으로 구성 가능한, 즉 가장 적은 서버로 가장 많은 적용이 가능하도록 플랫폼 자체를 다시 만들었다. 전구간 암호화 통신은 기본적인 옵션이 될 것이며, 그룹 관리 등 다양한 고객의 요구사항이 모두 적용되는 형태가 될 것이다. 모든 연동 제품에 균등한 관리가 가능한 제품, 이것이 바로 인젠이 새롭게 출시할 예정인 뉴 ESM의 모습이다.

인젠의 올해 ESM 시장 전략은.
현재 보유하고 있는 ESM 솔루션인 ‘네오어드민@ESM’의 가장 큰 장점이자 단점인 세밀한 컨트롤은 네오어드민@ESM에 집중시켜, 특정 제품에 대한 세부적인 조작을 요구하는 중소기업 시장을 집중 공략할 계획이다.

반면 새로이 출시하는 뉴 ESM은 균등하게 모든 제품을 관리할 수 있다는 장점을 앞세워 주로 대기업 시장의 문을 두드릴 것이다. 비록 출시 초기에는 커버하는 솔루션의 범위가 그리 넓지만은 않겠지만, 연동되는 범위도 현재보다는 훨씬 더 넓어질 전망이다. (www.dataNet.co.kr)

 

발췌 [NETWORK TIMES 2002년 04월호]

Posted by linuxism
,

List of HTTP status codes

From Wikipedia, the free encyclopedia
HTTP
Persistence · Compression ·HTTPS
Request methods
OPTIONS · GET · HEAD · POST· PUT · DELETE · TRACE ·CONNECT
Header fields
Cookie · ETag · Location ·Referer
DNT · X-Forwarded-For
Status codes
301 Moved permanently
302 Found
303 See Other
403 Forbidden
404 Not Found

The following is a list of HyperText Transfer Protocol (HTTP) response status codes. This includes codes from IETF internet standards as well as unstandardised RFCs, other specifications and some additional commonly used codes. The first digit of the status code specifies one of five classes of response; the bare minimum for an HTTP client is that it recognises these five classes. Microsoft IIS may use additional decimal sub-codes to provide more specific information,[1] but these are not listed here. The phrases used are the standard examples, but any human-readable alternative can be provided. Unless otherwise stated, the status code is part of the HTTP/1.1 standard.

Contents

  [hide

[edit]1xx Informational

Request received, continuing process.[2]

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions.

100 Continue
This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request[2] and check if a 100 Continue status code is received in response before continuing (or receive 417 Expectation Failed and not continue).[2]
101 Switching Protocols
This means the requester has asked the server to switch protocols and the server is acknowledging that it will do so.[2]
102 Processing (WebDAV) (RFC 2518)
As a WebDAV request may contain many sub-requests involving file operations, it may take a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.[3] This prevents the client from timing out and assuming the request was lost.
103 Checkpoint
This code is used in the Resumable HTTP Requests Proposal to resume aborted PUT or POST requests.[4]
122 Request-URI too long
This is a non-standard IE7-only code which means the URI is longer than a maximum of 2083 characters.[5][6] (See code 414.)

[edit]2xx Success

This class of status codes indicates the action requested by the client was received, understood, accepted and processed successfully.

200 OK
Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.[2]
201 Created
The request has been fulfilled and resulted in a new resource being created.[2]
202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.[2]
203 Non-Authoritative Information (since HTTP/1.1)
The server successfully processed the request, but is returning information that may be from another source.[2]
204 No Content
The server successfully processed the request, but is not returning any content.[2]
205 Reset Content
The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view.[2]
206 Partial Content
The server is delivering only part of the resource due to a range header sent by the client. The range header is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.[2]
207 Multi-Status (WebDAV) (RFC 4918)
The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.[7]
208 Already Reported (WebDAV) (RFC 5842)
The members of a DAV binding have already been enumerated in a previous reply to this request, and are not being included again.
226 IM Used (RFC 3229)
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. [8]

[edit]3xx Redirection

The client must take additional action to complete the request.[2]

This class of status code indicates that further action needs to be taken by the user agent in order to fulfil the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A user agent should not automatically redirect a request more than five times, since such redirections usually indicate an infinite loop.

300 Multiple Choices
Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with differentextensions, or word sense disambiguation.[2]
301 Moved Permanently
This and all future requests should be directed to the given URI.[2]
302 Found
This is an example of industrial practice contradicting the standard.[2] HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[9] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[10] However, some Web applications and frameworks use the 302 status code as if it were the 303.[citation needed]
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.[2]
304 Not Modified
Indicates the resource has not been modified since last requested.[2] Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
305 Use Proxy (since HTTP/1.1)
Many HTTP clients (such as Mozilla[11] and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons.[2]
306 Switch Proxy
No longer used.[2] Originally meant "Subsequent requests should use the specified proxy."[12]
307 Temporary Redirect (since HTTP/1.1)
In this occasion, the request should be repeated with another URI, but future requests can still use the original URI.[2] In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.
308 Resume Incomplete
This code is used in the Resumable HTTP Requests Proposal to resume aborted PUT or POST requests.[4]

[edit]4xx Client Error

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agentsshould display any included entity to the user.

400 Bad Request
The request cannot be fulfilled due to bad syntax.[2]
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided.[2] The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.
402 Payment Required
Reserved for future use.[2] The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code is not usually used. As an example of its use, however, Apple's MobileMe service generates a 402 error ("httpStatusCode:402" in the Mac OS X Console log) if the MobileMe account is delinquent.
403 Forbidden
The request was a legal request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2]
404 Not Found
The requested resource could not be found but may be available again in the future.[2] Subsequent requests by the client are permissible.
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource;[2] for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.
406 Not Acceptable
The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.[2]
407 Proxy Authentication Required
The client must first authenticate itself with the proxy.[2]
408 Request Timeout
The server timed out waiting for the request.[2] According to W3 HTTP specifications: "The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time."
409 Conflict
Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.[2]
410 Gone
Indicates that the resource requested is no longer available and will not be available again.[2] This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a "404 Not Found" may be used instead.
411 Length Required
The request did not specify the length of its content, which is required by the requested resource.[2]
412 Precondition Failed
The server does not meet one of the preconditions that the requester put on the request.[2]
413 Request Entity Too Large
The request is larger than the server is willing or able to process.[2]
414 Request-URI Too Long
The URI provided was too long for the server to process.[2]
415 Unsupported Media Type
The request entity has a media type which the server or resource does not support.[2] For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Requested Range Not Satisfiable
The client has asked for a portion of the file, but the server cannot supply that portion.[2] For example, if the client asked for a part of the file that lies beyond the end of the file.
417 Expectation Failed
The server cannot meet the requirements of the Expect request-header field.[2]
418 I'm a teapot (RFC 2324)
This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. However, known implementations do exist.[13]
422 Unprocessable Entity (WebDAV) (RFC 4918)
The request was well-formed but was unable to be followed due to semantic errors.[7]
423 Locked (WebDAV) (RFC 4918)
The resource that is being accessed is locked.[7]
424 Failed Dependency (WebDAV) (RFC 4918)
The request failed due to failure of a previous request (e.g. a PROPPATCH).[7]
425 Unordered Collection (RFC 3648)
Defined in drafts of "WebDAV Advanced Collections Protocol",[14] but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".[15]
426 Upgrade Required (RFC 2817)
The client should switch to a different protocol such as TLS/1.0.[16]
428 Precondition Required
The origin server requires the request to be conditional. Intended to prevent "the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict."[17] Proposed in an Internet-Draft.
429 Too Many Requests
The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes. Proposed in an Internet-Draft.[17]
431 Request Header Fields Too Large
The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large. Proposed in an Internet-Draft.[17]
444 No Response
An nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).
449 Retry With
A Microsoft extension. The request should be retried after performing the appropriate action.[18]
450 Blocked by Windows Parental Controls
A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.[19]
499 Client Closed Request
An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.[20]

[edit]5xx Server Error

The server failed to fulfill an apparently valid request.[2]

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error
A generic error message, given when no more specific message is suitable.[2]
501 Not Implemented
The server either does not recognise the request method, or it lacks the ability to fulfill the request.[2]
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.[2]
503 Service Unavailable
The server is currently unavailable (because it is overloaded or down for maintenance).[2] Generally, this is a temporary state.
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.[2]
505 HTTP Version Not Supported
The server does not support the HTTP protocol version used in the request.[2]
506 Variant Also Negotiates (RFC 2295)
Transparent content negotiation for the request results in a circular reference.[21]
507 Insufficient Storage (WebDAV) (RFC 4918)
The server is unable to store the representation needed to complete the request.[7]
508 Loop Detected (WebDAV) (RFC 5842)
The server detected an infinite loop while processing the request (sent in lieu of 208).
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
This status code, while used by many servers, is not specified in any RFCs.
510 Not Extended (RFC 2774)
Further extensions to the request are required for the server to fulfill it.[22]
511 Network Authentication Required
The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g. "captive portals" used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot). Proposed in an Internet-Draft.[17]

[edit]See also

[edit]References

  1. ^ "The HTTP status codes in IIS 7.0"Microsoft. July 14, 2009. Retrieved April 1, 2009.
  2. a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al aman ao ap aq ar as at Fielding, Roy T.Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol -- HTTP/1.1IETF. RFC 2616. Retrieved October 24, 2009.
  3. ^ Goland, Yaron; Whitehead, Jim; Faizi, Asad; Carter, Steve R.; Jensen, Del (February 1999). HTTP Extensions for Distributed Authoring -- WEBDAVIETF. RFC 2518. Retrieved October 24, 2009.
  4. a b "A proposal for supporting resumable POST/PUT HTTP requests in HTTP/1.0.".Google. 2010. Retrieved August 8, 2011. This is not a standard code in HTTP 1.1.
  5. ^ Support.microsoft.com
  6. ^ Lorem.biz
  7. a b c d e Dusseault, Lisa, ed (June 2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)IETF. RFC 4918. Retrieved October 24, 2009.
  8. ^ Delta encoding in HTTPIETF. January 2002. RFC 3229. Retrieved February 25, 2011.
  9. ^ Berners-Lee, TimFielding, Roy T.Nielsen, Henrik Frystyk (May 1996). Hypertext Transfer Protocol -- HTTP/1.0IETF. RFC 1945. Retrieved October 24, 2009.
  10. ^ "HTTP/1.1 Section 10 Status Code Definitions"W3C. Retrieved March 16, 2010.
  11. ^ "Mozilla Bugzilla Bug 187996: Strange behavior on 305 redirect". March 3, 2003. Retrieved May 21, 2009.
  12. ^ Cohen, Josh. "HTTP/1.1 305 and 306 Response Codes". HTTP Working Group.
  13. ^ HTTP 418 implemented at BBC CBeebies
  14. ^ Slein, Judy; Whitehead, Jim; Davis, Jim; Clemm, Geoffrey; Fay, Chuck; Crawford, Jason; Chihaya, Tyson (June 18, 1999). WebDAV Advanced Collections Protocol.IETF. I-D draft-ietf-webdav-collection-protocol-04. Retrieved October 24, 2009.
  15. ^ Whitehead, Jim (December 2003). Reschke, Julian F.. ed. Web Distributed Authoring and Versioning (WebDAV) Ordered Collections ProtocolIETF. RFC 3648. Retrieved October 24, 2009.
  16. ^ Khare, Rohit; Lawrence, Scott (May 2000). Upgrading to TLS Within HTTP/1.1IETF. RFC 2817. Retrieved October 24, 2009.
  17. a b c d Nottingham, M.; Fielding, R. (18 October 2011). "draft-nottingham-http-new-status-02 - Additional HTTP Status Codes"Internet-DraftsInternet Engineering Task Force. Retrieved 2011-10-22.
  18. ^ "2.2.6 449 Retry With Status Code"Microsoft. 2009. Retrieved October 26, 2009.
  19. ^ "Screenshot of error page" (bmp). Retrieved October 11, 2009.
  20. ^ Sysoev, Igor (August 2007). "Re: 499 error in nginx". Retrieved December 09, 2010.
  21. ^ Holtman, Koen; Mutz, Andrew H. (March 1998). Transparent Content Negotiation in HTTPIETF. RFC 2295. Retrieved October 24, 2009.
  22. ^ Nielsen, Henrik Frystyk; Leach, Paul J.; Lawrence, Scott (February 2000). An HTTP Extension FrameworkIETF. RFC 2774. Retrieved October 24, 2009.

[edit]External links






아래는 HTTP(하이퍼텍스트 전송 프로토콜) 응답 상태 코드의 목록이다.

IANA가 현재 공식 HTTP 상태 코드 레지스트리를 관리하고 있다.

목차

  [숨기기

1xx (조건부 응답)[편집]

요청을 받았으며 작업을 계속한다.[1]

  • 100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
  • 101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
  • 102(처리, RFC 2518)

2xx (성공)[편집]

이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

  • 200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
  • 201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
  • 202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
  • 203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
  • 204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
  • 205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
  • 206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
  • 207(다중 상태, RFC 4918)
  • 208(이미 보고됨, RFC 5842)
  • 226 IM Used (RFC 3229)

3xx (리다이렉션 완료)[편집]

클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.[1]

  • 300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
  • 301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
  • 302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
  • 303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
  • 304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
  • 305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
  • 307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
  • 308(영구 리다이렉션, RFC에서 실험적으로 승인됨)

4xx (요청 오류)[편집]

4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.

  • 400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
  • 401(권한 없음): 이 요청은 인증이 필요한다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다.
  • 403(금지됨): 서버가 요청을 거부하고 있다.
  • 404(찾을 수 없음): 서버가 요청한 페이지를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
  • 405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다.
  • 406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
  • 407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
  • 408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
  • 409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
  • 410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
  • 411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
  • 412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
  • 413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
  • 414(요청 URI가 너무 김): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
  • 415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
  • 416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
  • 417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
  • 418(I'm a teapot, RFC 2324)
  • 420(Enhance Your Calm, 트위터)
  • 422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
  • 423(잠김,WebDAV; RFC 4918)
  • 424(실패된 의존성, WebDAV; RFC 4918)
  • 424(메쏘드 실패, WebDAV)
  • 425(정렬되지 않은 컬렉션, 인터넷 초안)
  • 426(업그레이드 필요, RFC 2817)
  • 428(전제조건 필요, RFC 6585)
  • 429(너무 많은 요청, RFC 6585)
  • 431(요청 헤더 필드가 너무 큼, RFC 6585)
  • 444(응답 없음, Nginx)
  • 449(다시 시도, 마이크로소프트)
  • 450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
  • 451(법적인 이유로 이용 불가, 인터넷 초안)
  • 451(리다이렉션, 마이크로소프트)
  • 494(요청 헤더가 너무 큼, Nginx)
  • 495(Cert 오류, Nginx)
  • 496(Cert 없음, Nginx)
  • 497(HTTP to HTTPS, Nginx)
  • 499(클라이언트가 요청을 닫음, Nginx)

5xx (서버 오류)[편집]

서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.[1]

  • 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
  • 501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
  • 502(불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
  • 503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
  • 504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
  • 505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
  • 506(Variant Also Negotiates, RFC 2295)
  • 507(용량 부족, WebDAV; RFC 4918)
  • 508(루프 감지됨, WebDAV; RFC 5842)
  • 509(대역폭 제한 초과, Apache bw/limited extension)
  • 510(확장되지 않음, RFC 2774)
  • 511(네트워크 인증 필요, RFC 6585)
  • 598(네트워크 읽기 시간초과 오류, 알 수 없음)
  • 599(네트워크 연결 시간초과 오류, 알 수 없음)

참조[편집]

  1. ↑    Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol – HTTP/1.1.IETFRFC 2616. Retrieved October 24, 2009.

바깥 고리[편집]




출처 - http://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C










'Web > HTTP' 카테고리의 다른 글

apache - 파일 크기 제한을 초과함 $HTTPD  (0) 2013.09.09
http - compression  (0) 2013.06.27
http - cache(web cache)  (0) 2013.06.24
http - request, response header  (0) 2013.06.20
http - accept header field  (0) 2013.06.19
Posted by linuxism
,

디바이스 파일

System/Common 2011. 12. 15. 11:20
출처 - 뇌를 자극하는 Solaris Bible 





 

'System > Common' 카테고리의 다른 글

IBM System X  (0) 2012.01.11
SetUID, SetGID, Sticky-bit, chmod  (0) 2011.12.21
i-node & Directory  (0) 2011.12.15
linux - File Descriptor  (0) 2011.12.12
Character Device File vs Block Device File  (0) 2011.12.08
Posted by linuxism
,