인터넷을 하다보면 어쩌다 한번씩 만나는 HTTP 상태코드는 Internet Assigned Numbers Authority (IANA) 가 현재 공식적으로 HTTP 응답 상태 코드 레지스트리로 관리하고있고 이 관리코드는 HTTP/1.0에 클라이언트와 서버간의 통신을 보다 정교하게 만들기 위해 다양한 상태코드와 헤더가 추가되었다 HTTP 상태코드를 확인해보자.
1xx (정보): 요청을 받았으며 프로세스를 계속한다.
임시 응답으로 현재 클라이언트의 요청은 처리되었고 계속 진행하라는 의미 HTTP 1.1버전부터 추가
- 100(Continue): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
- 101(Switching Protocol): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다
- 102(Processing, RFC 2518): 서버가 처리하는 데 오랜 시간이 예상되어 클라이언트에서 타임 아웃이 발생하지 않도록 이 응답 코드 전송
**RFC 2518이란 WebDAV 프로토콜을 정의하는 문서로 WebDAV는 HTTP 프로토콜을 확장하여 웹 서버에서의 파일 관리를 가능하게 하는 표준 RFC 2518은 이후 RFC 4918로 대체됨
2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다.
클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미
- 200(OK): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
- 201(Created): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
- 202(Accepted): 서버가 요청을 접수했지만 아직 처리하지 않았다.
- 203(Non-Authoritative Information): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공
**신뢰할 수 없는 정보의 예로 콘텐츠 필터링: 어떤 민감한 단어들을 필터링, 이미지 압축 프록시 서버: 고해상도 이미지를 요청하였을 때 데이터 절약을 위해 이미지 파일을 저해상도로 변환
*** 콘텐츠타입 예시: json, xml, text, csv - 204(No Content): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
- 205(Reset Content): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
- 206(Partial Content): 서버가 GET 요청의 일부만 성공적으로 처리했다
프록시서버
프록시 서버는 클라이언트의 실제 목적시 서버 사이에서 중계역할을 하는 서버로 여러가지 중요한 기능을 수행
1. IP 주소의 보호: 클라이언트가 웹사이트나 서비스를 요청할 때 클라이언트의 실제 IP 주소를 숨기고 프록시 서버의 IP주소를 대신하여 사용자의 익명성이 보호된다.
2. 트래픽 제어 및 성능 향상: 프록시 서버는 캐싱 기능을 활용해 자주 요청되는 데이터를 저장하고, 클라이언트가 동일한 요청을 할 경우 원 서버에 접속하지 않고 캐시에서 빠르게 데이터를 제공할수 있다.
3. 접근제어 및 보안강화: 프록시 서버는 특정 웹사이트, 특정 콘텐츠, 악성 웹사이트나 불법적인 접근을 차단하는필터 역할을 수행할 수 있다.
4. 로깅 및 모니터링: 프록시 서버는 클라이언트의 요청 기록을 저장할 수 있어, 사용자의 웹 활동을 추적하거나
분석이가능하다.
게이트웨이서버
1. 추상서버: 클라이언트가 실제 서버의 위치나 복잡한 구조를 인식하지 않고, 단순한 인터페이스를 통해 서비스를
제공받도록 돕는 개념
1) 서버의 복잡성 숨김: 추상 서버는 다양한 백엔드 시스템(예: 데이터베이스, 마이크로서비스, 외부 API 등)을 통합하고, 클라이언트에게는 하나의 통합된 서비스처럼 보이게한다.
2) 서비스 통합: 클라이언트가 한 번의 요청을 보내면, 게이트웨이 서버는 여러 백엔드 서비스에 요청을 전달한 후, 그 결과를 합쳐 클라이언트에게 응답하여 하나의 단일 서비스로 제공할 수 있다.
3) 로드 밸런싱 및 장애 처리: 추상 서버로서의 게이트웨이 서버는 서버 부하를 분산시키고, 서버 장애 발생 시에도 요청을 다른 서버로 전환하는 역할이 가능하다.
4) 보안 및 접근제어: 추상 서버는 보안 측면에서도 중요한 역할을 한다. 게이트웨이 서버는 클라이언트가 모든 백엔드 서버에 직접 접근하지 못하도록 하여 보안을 강화할 수 있다. 클라이언트는 게이트웨이를 통해서만 백엔드 서버에 접근할 수 있으며, 게이트웨이가 클라이언트의 요청을 필터링하거나 권한을 검증하는 역할을 수행한다.
2. 보안로직 통일: 게이트웨이 서버는 다양한 백엔드 시스템에 대한 보안 정책을 통일할 수 있는 중심점으로
작동한다.
1) 중앙화된 인증 및 인가: 게이트웨이 서버는 단일 진입점으로 작용하여, 모든 클라이언트 요청에 대해 중앙에서 인증 및 권한 검증을 수행, 클라이언트는 백엔드 서버에 접근하지 않고 게이트웨이서버를 통과하여야하므로
일관된 보안로직이 적용
2) 보안 정책의 통일: 게이트웨이 서버는 방화벽 규칙, 데이터 암호화, 접근 제어와 같은 보안 규칙을 중앙화하여
관리한다,백엔드 서버들마다 서로 다른 보안 설정을 관리할 필요 없이, 게이트웨이 서버에서 한 번에 관리
3) 암호화 관리: 게이트웨이 서버는 모든 외부 통신을 SSL/TLS와 같은 암호화 프로토콜로 보호하고, 이를 일관되게 적용가능하다. 각 백엔드 서버가 개별적으로 암호화 통신을 설정하는 대신, 게이트웨이에서 중앙 집중적으로 암호화 처리
3. 권한 문제 해결 및 통일된 권한 관리: 권한 관리를 단순화하고, 중앙 집중화된 방식으로 통합할 수 있다. 이로
인해 개별 서비스나 시스템에서 따로 권한 설정을 관리할 필요가 없으며, 모든 권한 관련 로직을 게이트웨이 서버에서 처리할 수 있게된다.
1) 권한 검증의 중앙화: 각 백엔드 시스템에서 권한 검증을 따로 처리하는 대신, 게이트웨이 서버에서 중앙화된
권한 관리가 가능하다. 사용자가 특정 자원이나 서비스에 접근할 때, 게이트웨이 서버가 사용자의 권한을 검증하고, 허가된 요청만 백엔드 서버로 전달
2) 세분화된 접근 제어: 게이트웨이 서버는 다양한 권한 레벨에 따라 세분화된 접근 제어를 적용할 수 있다. 예를
들어, 사용자의 역할(Role)에 따라 특정 API는 읽기 권한만 부여하고, 다른 API는 쓰기 권한을 부여하는 식으로
권한을 구분할 수 있다.
3) 역할 기반 접근 제어(Role-Based Access Control, RBAC): 게이트웨이 서버에서 사용자 역할(Role)에 따라
접근 권한을 중앙에서 관리할 수 있다. 이로 인해 사용자가 가지고 있는 권한에 따라 각기 다른 자원이나 서비스에 접근할 수 있도록 보장할 수 있다.
4. 네트워크 허용 규칙 간편화
1) 단일 진입점 제공: 게이트웨이 서버는 네트워크의 단일 진입점 역할을 한다. 즉, 모든 외부 트래픽은 게이트웨이를 통해 들어오고 나가므로, 네트워크 규칙을 관리하는 위치가 단일화가되어 이를 통해 복잡한 네트워크 규칙 설정을 단순화할 수 있다.
2) IP 필터링 및 방화벽 규칙 관리: 게이트웨이 서버는 네트워크에 대한 IP 필터링이나 방화벽 규칙을 중앙에서 관리할 수 있다. 이를 통해 외부 네트워크에서 특정 IP 주소나 포트에 대한 접근을 쉽게 차단하거나 허용할 수 있다.
3) VPC 게이트웨이 통합: 클라우드 환경에서는 가상 사설 클라우드(VPC)를 사용하여 네트워크를 분리하고, 게이트웨이를 통해 내부 및 외부 네트워크 연결을 간소화할 수 있다. 게이트웨이는 VPC 내 네트워크 허용 규칙을 일관되게 적용하고, 외부와의 트래픽을 제어하는 중요한 역할을 한다.
3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다.
완전한 처리를 위해서 추가 동작이 필요한 경우 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미
- 300(Multiple Choice): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할
작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다. - 301(Moved Permanently): 요청한 페이지가 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한
응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다. - 302(Found): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속
사용해야 한다. - 303(See Other): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
- 304(Not Modified): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의
콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다. - 305(Use Proxy): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면
요청자가 사용할 프록시를 가리키는 것이기도 하다.
*프록시 사용의 예로는 어떤 회사에서는 직원들이 사내 네트워크에서 외부 웹사이트에 접근할 때 특정 프록시 서버를 거치도록 설정하였고 이 프록시서버는 트래픽을 모니터링하고, 보안검사를 수행한 훙 외부서버에 전송 - 307(Temporary Redirect): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시
원래 위치를 계속 사용해야 한다.
*임시 리디렉션의 예로는 서버의 유지보수를 하기위여 서비스나 기능에 접근하면 임시페이지로 이동시키거나, 파일 다운로드 서버가 트래픽 부하로 인해 일시적으로 변경
4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미
- 400(Bad Request): 서버가 요청의 구문을 인식하지 못했다.
- 401(Unauthorized): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
**권한없음의 예로는 로그인이 필요한 웹사이트에 접근하려고 하였을 때, API 호출시 유효하지 않은 인증토큰
(만료되거나 올바르지 않을 경우)을 사용할때,인증을 하지 않았을 때 권한없음의 페이지로 이동 - 402(Payment Required): 이 요청은 결제가 필요합니다.
- 403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고
있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
**금지됨의 예로는 관리자만 접근이 가능한 페이지에 일반사용자나 관리자로그인을 하지 않은 사용자가 접속을 시도할 때, 특정 디렉토리나 파일에대한 직접접근을 차단하는경우, 특정 IP주소를 차단,서버의 읽기 권한이 없는 파일에 엑세스 하였을때 해당 코드가 발생한다. - 404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는
페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다. - 405(Method Not Allowed): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는
서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다. - 406(Not Acceptable): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
- 407(Proxy Authentication Required): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여
인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다. - 408(Request Timeout): 서버의 요청 대기가 시간을 초과하였다.
- 409(Conflict): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야
한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다. - 410(Gone): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
- 411(Length Required): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
- 412(Precondition Failed): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
- 413(Payload Too Large): 요청의 본문이 너무 길어 서버가 처리할 수 없다.
- 414(URI Too Long): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
- 415(Unsupported Media Type): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
- 416(Requested Range Not Satisfiable): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태
코드를 표시한다. - 417(Expectation Failed): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다.
- 서버 사정으로 메시지 처리에 문제가 발생한 경우입니다. 서버의 부하, DB 처리 과정 오류, 서버에서
예외(Exceptio)가 발생하는 경우를 의미
- 500(Internal Server Error): 서버에 오류가 발생하여 요청을 수행할 수 없다.
- 501(Not Implemented): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
- 502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서
잘못된 응답을 받았다.
**bad gateway의 예로는 게이트웨이 또는 프록시 서버로 부터 잘못된 응답을 받았을 때, 목적시 서버가 응답을
하지 않거나 잘못된 응답을 반환할때 서버간의 통신오류를 나타낸다 - 503(Service Unavailable): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수
없다. 이는 대개 일시적인 상태이다. - 504(Gateway Timeout): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을
받지 못했다. - 505(HTTP Version Not Supported): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
[결과]
1xx는 현재 클라이언트의 요청까지는 처리되었고 작업을 계속 진행함 코드, 2xx는 요청을 성공적으로 받고 인식및 수용한 상태, 3xx는 요청완료를 하였고 추가작업 조치가 필요다는 상태, 4xx는 없는페이지를 요청하는 등 요청이 잘못되었다는 상태, 5xx는 서버의 사정으로 요청 처리에 문제가 발생한 경우로 크게 분류하며 많은 상태코드가 존재한다.
[느낀점]
HTTP 상태코드를 공부하기 전에는 404, 502정도만 보았고 생각없이 웹사이를 이용하였지만 상태코드에 대하여 알아보자 많은 코드들이 있었고, 그에 따른 코드가 어떻게 하면 실제로 나오게 되는가에 대하여 알아내는 것이 쉽지않았다. 해당 코드와 설명은 있지만 예시를 들기위하여 확인하는 과정이 아직 준비되지 않아 아직 많은 내용을 추가하지 못하여 추후 내용 업데이트 하려고 한다.
[웹 프로그래밍] HTTP 상태 코드 표(100 ~ 500) 전체 요약 정리
서버에서의 처리 결과는 응답 메시지의 상태 라인에 있는 상태 코드(status code)를 보고 파악할 수 있습니다. 상태 코드는 세 자리 숫자로 되어 있는데 첫 번째 숫자는 HTTP 응답의 종류를 구분하는
hongong.hanbit.co.kr
hongong.hanbit.co.kr
https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
HTTP 상태 코드 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. 아래는 HTTP(하이퍼텍스트 전송 프로토콜) 응답 상태 코드의 목록이다. IANA가 현재 공식 HTTP 상태 코드 레지스트리를 관리하고 있다. 모든 HTTP 응답 코드는 5개의
ko.wikipedia.org