DNS와 자원
- 서버와 클라이언트는 ‘메시지를 주고받고자 하는 대상’과 ‘송수신하고자 하는 정보’를 식별
- 메시지를 주고받고자 하는 대상을 파악
- 송수신하고자 하는 정보를 식별
- URL - 위치 기반 식별자
- URN - 이름 기반의 식별자
도메인 네임과 네임 서버
- 도메인 네임(domain name)
- DNS 서버
- 도메인 네임을 관리하는 네임 서버
- 도메인 네임 서버, 전화번호부
- 정방향: 도메인 이름 → IP 주소 반환
- 역방향: IP주소 → 도메인 이름
- 포트: 53번
- UDP 기본, TCP 가능
- IP와 도메인 주소를 매핑한다.
- 개인 전화번호부와 같은 hosts 파일
- hosts 파일 - 호스트마다 유지하는 ‘개인’ 전화번호부 같은 파일
- 도메인 네임과 IP 주소의 대응 관계를 담은 파일로, 이를 토대로 도메인 네임에 대응하는 IP 주소를 식별
- hosts 파일 위치
- 맥OS나 리눅스 - /etc/hosts
- 윈도우 - %SystemRoot%\System32\drivers\etc\hosts
- 127.0.0.1 naver.com 저장
- etc/host → 도메인 관리 파일
- 윈도우: c드라이브/windows/system32/drivers/etc/hosts
- 해당 도메인을 해당 IP로 지정한다.
- ping naver.com을 입력하면 127.0.0.1으로 향하도록 바뀐다.
- 네임 서버는 공용 전화번호부
도메인 네임과 DNS
- 도메인 네임은 점(.)을 기준으로 계층적으로 분류
- 최상단에 루트 도메인(Root Domain)
- 최상위 도메인 TLD(Top-Level Domain)
- 2단계 도메인(Second-Level Domain)
- 3단계 도메인
- 전체 주소 도메인 네임 FQDN(Fully-Qualified Domain Name)
- 호스트 네임(Host Name) - FQDN의 첫 번째 부분(www)
- 도메인 네임 시스템( DNS, Domain Name System)
- 분산된 도메인 네임(Domain Name)에 대한 관리 체계(System)
- 계층적 구조, 타고 내려간다.
- 도메인 구매
- 도메인 구매 후 도메인에 대한 정보를 저장해야 함.
- 서브 도메인이란?
- 서브 도메인(subdomain)은 다른 도메인이 포함된 도메인을 의미
- google.com의 서브 도메인 - 모두 google.com을 포함
- 마찬가지로 google.com은 com을 포함하고 있기에 com의 서브 도메인
- example.com을 주소창에 입력
- → 클라이언트의 호스트 파일( /etc/host) 확인 (자체 DNS를 찾는 것) → 없음 → 밖으로 나간다.
- ISP 업체가 도메인을 매핑해놓는다.(DNS 서버) → 있다면 바로 주고, 없다면?
- Root nameserver “.” : 얘한테 가서 묻는다. “.com”으로 된 도메인 네임서버 알아? → 알려준다.
- TLD nameserver: “.com”한테 가서 “example.com”이 어디있는지 묻는다.
- Authoritative nameserver: “www.example.com”을 묻는다.
- Recursive resolver에서 조합해서 클라이언트에게 알려준다.
- 클라이언트가 DNS 서버에서 보내는 질의가 재귀적 질의다. 너가 알아서 찾아와.
- DNS 서버는 반복적 질의를 한다. 물어본 것만 알려준다.
- 모든 사람이 루트에게 물어보면 루트가 힘들다 → ISP가 캐싱하고 있다. → 모든 요청이 루트까지 잘 가지 않는다. 또 컴퓨터, 브라우저에서도 캐싱을 해서 빠르게 인터넷에 접속이 가능하다.
- example.com을 한번 갔다오면 캐싱한다. 그러나 캐싱은 무한하지 않다.
- IP가 변경될 수 있다.
- 메모리 자원을 위해서이다.
- TTL 보통 300초이다. 설정가능하고 기본값이 300초이다.
- google.com 입력 시 다양한 IP 주소가 있고 그 중에 가까운 곳으로 간다. (애니캐스트)
- nslookup dns.google.com → 8.8.8.8 → 구글의 dns 서버였다.
계층적 네임 서버
- IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정
- ‘도메인 네임을 풀이 resolve한다’라고 표현하며,
영어로는 ‘리졸빙(resolve+ing)한다’고 표현
- 네임 서버의 유형
- 로컬 네임 서버
- 루트 네임 서버
- TLD(최상위 도메인) 네임 서버
- 책임 네임 서버
- 로컬 네임 서버(local name server)
- 클라이언트와 맞닿아 있는 네임 서버
- 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
- 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당
- 공개 DNS 서버 public DNS Server를 이용할 수도 있음
- 루트 네임 서버(root name server)
- 루트 도메인을 관장하는 네임 서버
- 로컬 네임 서버가 대응되는 IP 주소를 몰라 루트 네임 서버에게 해당 도메인 네임을 질의할 때 TLD 네임 서버의 IP 주소를 반환
- TLD 네임 서버
- TLD를 관리하는 네임 서버
- TLD 네임 서버는 다음 그림과 같이 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환
- 하위 도메인 네임을 관리하는 네임 서버는 그보다 하위 도메인 네임을 관리하는 네임 서버 주소를 반환
- 책임 네임 서버(authoritative name server)
- 특정 도메인 영역(zone)을 관리하는 네임 서버
- 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버
- 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버
- 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어냄
도메인 네임 리졸빙 과정의 문제점과 DNS 캐시
- 앞의 그림처럼 도메인 네임을 리졸빙하기 위해 8개의 단계를 거치게 됨
- 시간이 오래 걸리고 네트워크상의 메시지 수가 지나치게 늘어날 수 있음
- 만약 전 세계 모든 호스트가 도메인 네임 리졸빙을 위해 루트 네임 서버에 도메인 네임을 한꺼번에 질의한다면 루트 네임 서버에 과부하가 생길 것임
- DNS 캐시(DNS cache)
- 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 활용
- DNS 캐시를 저장하는 용도로만 사용되는 서버도 있음
- DNS 캐싱은 이전에 조회한 DNS 쿼리 결과를 저장해두고 재사용하여 네트워크 트래픽을 줄이고 응답 속도를 빠르게 하는 기술
- DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있음
- DNS 캐시는 영원히 남아있는 것은 아님
→ 무한히 DNS 캐싱을 하지 않는 이유: IP 주소가 변경될 수도 있고, 메모리 문제가 있을 수 있기 때문
- 임시 저장된 값은 TTL(Time To Live 캐시될 수 있는 시간) 값과 함께 저장
- traceroute 1.1.1.1, tracert 1.1.1.1
- 동작하는 방식
- 최종적인 서버까지 가는데 거쳐가는 라우터들의 IP주소가 나온다.
- 라우터에 대한 정보가 없다.
- ICMP ping은 라우터들에 대한 대답을 꺼둔다. 보안적인 이유로. + 방화벽
- 3계층의 TTL - 홉
- 4계층의 TTL - 캐싱이 날아가는 시간
- src = 2.2.2.2
- dst = 8.8.8.8
- ttl = 1
- ttl → 0, 답이 와서 첫번째 라우터 주소를 알게 된다.
- ttl → 2
- ttl → 2, 두번째 라우터 주소를 알게 된다.
- 8.8.8.8에 도착할 때까지 숫자를 늘려가며 시도한다.
자원을 식별하는 URI
- 자원(resource) - 네트워크상의 메시지를 통해 주고받는 대상을 의미
- 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상
- HTML 파일
- 이미지나 동영상 파일
- 텍스트 파일 등
- 자원은 ‘HTTP 요청 메시지의 대상’
- 자원을 식별할 수 있는 정보 URI(Uniform Resource Identifier)
- 자원을 식별하는 통일된 방식
- URL(Uniform Resource Locator)
- URN(Uniform Resource Name)
- URL
- URL은 오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 식별자
- 대부분 이것을 쓴다.
- URL의 구조
- scheme
- authority
- path
- query
- fragment
- scheme
- URL의 첫 부분은 scheme은 ‘자원에 접근하는 방법’을 의미
- 일반적으로 사용할 프로토콜이 명시
- authority
- authority에는 ‘호스트를 특정할 수 있는 정보’, 이를테면 IP 주소 혹은 도메인 네임이 명시
- 콜론(:) 뒤에 포트 번호를 덧붙일 수도 있음
- path
- path에는 ‘자원이 위치한 경로’가 명시
- 자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현
- 트리구조
- query, 쿼리 스트링
- 쿼리 문자열(query string) 또는 쿼리 파라미터(query parameter)
- ? 뒤에서 시작되는 값
- 쿼리 문자열은 물음표(?)로 시작되는 <키=값> 형태의 데이터로, 앰퍼샌드(&)를 사용하여 여러 쿼리 문자열을 연결
- url 주소에 데이터를 넣어서 보내는 것 (key=value 형식)
- HTTP는 요청-응답 기반의 프로토콜
- 클라이언트는 서버에게 URI(URL)가 포함된 HTTP 요청 메시지를 보내고,
- HTTP 서버는 이에 대해 HTTP 응답 메시지를 보냄
- [참고] 쿼리 문자열을 활용한 URL 설계
- 부동산 검색 웹 사이트 / 도서 판매 웹 사이트
- url로 생각보다 많은 정보를 알 수 있다.
- site:co.kr inurl:"index of /" 는 국내(.co.kr) 도메인 중 웹 서버의 디렉토리 목록(Directory Listing)이 노출된 취약한 페이지를 찾는 구글 해킹(Google Dorking) 검색식입니다.
- fragment
- fragment는 ‘자원의 한 조각을 가리키기 위한 정보’
- HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용
- 아래의 URL은 위의 HTML 파일 자원 내의 특정 부분을 나타냄
- 위키 페이지 같은 도큐멘테이션 형식 페이지에서 사용된다. 좌/우측 메뉴 클릭 시 #뒤가 생기거나 변경되며 이동한다.
- URN
- 보기가 어렵고 크게 중요하지 않다.
- URL의 문제를 해결한다. URL은 자원의 위치가 변경되면 404 Not Found가 된다.
- 자원의 고유의 이름을 붙여서 위치와 무관하게 식별한다.
- 그냥 텍스트 정보이다. 인터넷에 검색하는 정보가 아니다. 그 자체로 식별자인다.
- ISBN → 텍스트 자체가 정보이다.
- URL의 단점
- 위치를 기반으로 자원을 식별하는데 자원의 위치는 언제든 변할 수 있음
- 즉, 자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없음
- URN의 장점
- 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별
- URN은 아직 URL만큼 널리 채택된 방식은 아님
- [예시]
- ISBN이 0451450523인 도서를 나타내는 URN
DNS 레코드
- CNAME
- A 레코드
- 특정 호스트에 대한 도메인 네임과 IP주소를 대응하는 것
- 도메인 네임이 해당 IP주소에 대응된다는 사실을 네임 서버에 알리기 위해 도메인 레코드를 추가해야 한다.
- example.com 질의 → 1.2.3.4를 응답받는다.
- 구매한 도메인 주소를 1.2.3.4로 대응해줘.
HTTP
- HTTP의 중요한 네 가지 특성
- 요청과 응답을 기반으로 동작
- 미디어 독립적
- 상태를 유지하지 않음
- 지속 연결을 지원
HTTP의 특성
- 요청-응답 기반 프로토콜
- HTTP는 ‘클라이언트-서버 구조 기반의 요청-응답 프로토콜’
- 같은 HTTP 메시지일지라도 HTTP 요청 메시지와 HTTP 응답 메시지는 메시지 형태가 다름
- 웹 브라우저의 개발자 도구를 열어 [Network] 탭을 클릭한 후, 특정 웹 사이트에 접속하여 확인
- 클라이언트 → 서버 (Http Request)
- 클라이언트 ← 서버 (Http Response)
- 앞의 접속 화면에서 임의의 자원을 클릭 - 예)example.com
- HTTP 요청 메시지 헤더(Request Headers)와 HTTP 응답 메시지 헤더(Response Headers) 확인
- 미디어 독립적 프로토콜
- HTTP를 정의한 공식 문서(RFC 9110)
- 자원 - HTTP가 요청하는 대상 → 어떤 자원?
- HTTP는 자원의 특성을 제한하지 않으며, 단지 자원과 상호 작용하는 데 사용할 수 있는 인터페이스를 정의
- 대부분의 자원은 URI로 식별
- HTTP를 통해 다양한 자원을 주고 받는다.
- 미디어 타입(media type)
- HTTP에서 메시지로 주고받는 자원의 종류
- MIME 타입(Multipurpose Internet Mail Extensions Type)이라고도 함
- HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한 미디어 독립적인 프로토콜
- 미디어가 독립적이다.
- 종류를 제한 X, 무엇이든 보낼 수 있지만 지금 보내는 것의 타입이 뭔지 알려줘야 처리한다.
- 미디어 타입의 구성과 종류
- 슬래시를 기준으로 하는 ‘타입/서브타입(type/subtype)’ 형식으로 구성
- 타입(type) - 데이터의 유형
- 서브타입(subtype) - 주어진 타입에 대한 세부 유형
- 미디어 타입의 종류는 매우 다양하며, 필요에 따라 새로운 미디어 타입을 등록할 수도 있음
- 따라서 모든 미디어 타입을 암기할 필요는 없고, 필요할 때마다 찾아보는 것이 일반적
- 미디어 타입에는 부가적인 설명을 위해 선택적으로 매개변수가 포함매개변수
- ‘타입/서브타입;매개변수=값’의 형식으로 표현
스테이트리스 프로토콜
- HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜
- 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미
- 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
- 상태를 유지하지 않는 특성의 장점
- HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용
- 동시에 처리해야 할 요청 메시지의 수는 수천 개가 될 수도 있고, 많게는 수백만 개
- 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담
- 상태를 기억하지 않으므로 기본적으로 독립적으로 작동
- 서버는 하나가 아니라 여러 대로 구성될 경우
- 모든 서버가 모든 클라이언트의 상태를 유지할 경우 클라이언트는 여러 서버를 동시에 이용하기가 어려워짐 → 상태를 공유한다면 하나의 서버에 물려있게 된다.
- 서버가 모든 클라이언트의 상태 정보를 공유하는 작업은 매우 번거롭고 복잡
- 특정 클라이언트가 특정 서버에 종속되는 상황 방지
- HTTP가 상태를 유지하는 프로토콜이었다면 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호 작용할 수 있게 되어, 특정 클라이언트가 특정 서버에 종속될 수 있음
- 이러한 상황에서 어느 한 서버에 문제가 발생하면 해당 서버에 종속된 클라이언트는 직전까지의 HTTP 통신 내역을 잃어버리는 상황이 발생
- 확장성(scalability)과 견고성(robustness)
- HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표
- 상태를 기억하지 않으니까 서버를 언제든지 추가해서 확장성이 높다.
- 서버 하나에 문제가 생겨도 다른 서버로 언제들지 대체될 수 있어 견고성이 높다.
- 그렇다고 해서 아예 클라이언트를 모르는 것은 아니다. 서버가 매번 처음보는 것처럼 대하지는 않는다는 것이다.
지속 연결 프로토콜
- 비지속 연결
- 기본적으로 TCP 위에서 동작한다.
- 초기의 HTTP 버전(HTTP 1.0 이하)은 쓰리 웨이 핸드셰이크를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작
- 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결을 수립이라고 합니다
- 과거에 쓰던 것
- 지속 연결(persistent connection) 또는 킵 얼라이브(keep-alive)
- 최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)
- 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술
- 매번 쓰리웨이 핸드셰이크를 하면 자원 낭비가 발생한다.
HTTP 메서드
- 각각의 메서드는 서버에게 어떤 식으로 말을 걸지 형식적으로 정해놓은 것이다.
- GET - 가져다주세요
- 특정 자원을 조회할 때 사용되는 메서드
- 클라이언트가 서버에게 ‘이것(자원)을 가져다주세요’라고 요청을 보내는 것과 같음
- 자원은 HTML,, JSON, 이미지 파일이나 일반 텍스트 파일 등
① 요청 메시지
② 응답 메시지
- GET 요청 메시지가 성공적으로 처리되었다면 이에 대한 응답으로서 요청한 자원을 전달받음
③ 요청 메시지
- GET 요청 메시지에서는 메시지 본문보다 쿼리 문자열이 사용되는 경우가 많음
- HEAD - GET이랑 동일한데 헤더만 가져다주세요.
- POST – 처리해 주세요
- 서버로 하여금 특정 작업을 처리하도록 요청하는 메서드
- 예) http://example.com/posting에 접속했을 때의 화면이 다음과 같고, 어떤 클라이언트가 입력 폼에
- 글을 입력한 뒤, [게시하기] 버튼을 눌렀다고 가정
- 로그인 등 범용성이 높다.
- 서버에 새로운 자원을 생성할 때
- POST 메서드가 사용
- POST 메서드는 많은 경우 ‘클라이언트가 서버에 새로운 자원을 생성하고자 할 때’ 사용
- 성공적으로 POST 요청이 처리되어 새로운 자원이 생성되면 서버는 응답 메시지의 Location 헤더를 통해
- 새로 생성된 자원의 위치를 클라이언트에게 알려 줌
- 다음 응답 메시지의 붉은색 글자 부분 - 새로 생성된 자원은 /posting/1에서 확인할 수 있다는 의미
- PUT – 덮어써 주세요
- 요청 자원이 없다면 메시지 본문으로 자원을 새롭게 생성하거나, 이미 자원이 존재한다면
- 메시지 본문으로 자원을 완전히 대체하는 메서드
- PATCH - 일부 수정해 주세요
- PUT 메서드가 덮어쓰기, 완전한 대체에 가깝다면 PATCH 메서드는 부분적 수정
- (아래 화면) 앞 예제에서의 요청 메서드를 PATCH 메서드로 바꿔 보낸 결과
- PUT 메서드로 요청을 보냈을 경우 메시지 본문으로 덮어써졌지만, PATCH 메서드로 요청을 보낼 경우 메시지 본문에 맞게자원이 일부 수정
- DELETE – 삭제해 주세요
- 특정 자원을 삭제하고 싶을 때 사용하는 메서드
- 서버 개발자 입장의 메서드 설계
- 어떤 URI(URL)에 어떤 메서드로 요청을 받았을 때 서버가 어떻게 행동해야 하는지 설계하는 것은
- 어떤 메서드는 구현할 수도 있고, 어떤 메서드는 구현하지 않을 수도 있음
- 같은 URL에 대한 요청일지라도 사용된 메서드가 다르면 각기 다른 요청으로 간주하기 때문에,
- 때로는 같은 URL에 대해 메서드별 동작을 여러 개 구현할 수도 있음
- 오로지 개발자의 몫
- API 문서(1)
- 데이터를 가져갈 수 있는 경로와 메서드 등에 대해 정리해놓은 문서
- 공공데이터 포털 - https://www.data.go.kr/index.do
- 예) 유튜브와 관련된 API
- 어떤 URL에 어떤 메서드를 보낼 수 있는지,
- 어떤 쿼리 문자열(매개변수)이 사용될 수 있는지,
- 올바르게 요청을 보냈을 경우 어떤 응답 메시지를 받을 수 있는 지,
- 그리고 올바르지 않은 요청을 보냈을 경우 어떤 오류 메시지를 받을 수 있는지가 명시
- API 문서(2)
- 예) 네이버의 뉴스 검색 결과를 확인할 수 있는 API
- 어떤 URL에 어떤 메서드를 보낼 수 있는지,
- 어떤 쿼리 문자열(매개변수)이 사용될 수 있는지,
- 어떤 응답 메시지를 받을 수 있는지가 명시
HTTP 상태 코드
- 상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수
- 웹서버에 대한 헬스 체크 시에 확인한다. 요청에 대한 응답에 있는 코드를 기반으로 한다.
- 상태 코드의 종류는 200, 201, 304, 404, 505 등 다양한데, 백의 자리 수를 기준으로 유형을 구분
- 200번대: 성공 상태 코드
- 200번대 상태 코드는 ‘요청이 성공했음’을 의미
- 주로 사용되는 상태 코드는 200(OK), 201(Created), 202(Accepted), 204(No Content)
- 예) 클라이언트가 “http://example.com/images/a.png”로 GET 요청을 보냈다고 가정
- 서버가 이 요청을 성공적으로 받아들이고 처리한 경우, 서버는 요청한 자원과 함께 상태 코드
- 200(OK)을 포함하여 응답
- 300번대: 리다이렉션 상태 코드
- 리다이렉션(redirection)
- ‘요청을 완수하기 위해 추가적인 조치가 필요한 상태(인터넷 공식 문서 RFC 9110)’
- 문제가 생기거나 뭔가 이동했나보다.
- 클라이언트가 요청한 URL의 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것을 의미
- 영구적인 리다이렉션(permanent redirection)
- 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정
- 이 경우 기존의 URL에 요청 메시지를 보내면 항상 새로운 URL로 리다이렉트
- curl -I http://google.com → “301 Moved Permanently” 이 나온다.
- 400번대: 클라이언트 에러 상태 코드
- ‘클라이언트에 의한 에러가 있음’을 알려 주는 상태 코드
- 404
- 401, 403 → 인증/인가와 관련된 상태 코드
- 401 → 자신이 누구인지를 증명하는 것. 인증
- 403 → 권한 부여. 인증된 주체에게 권한을 주는 것. 인가.
- 상태 코드 401(Unauthorized)
- 웹상에서 정보를 검색할 때 모든 자원에 접근이 가능한 것은 아니며 때로는
- 특정 자원에 접근하기 위해 인증이 필요
- 요청에 대한 인증이 필요할 경우 서버는 401(Unauthorized) 상태 코드를 응답
- 상태 코드 403(Forbidden)
- 클라이언트의 권한이 충분하지 않다면 상태 코드 403(Forbidden)을 응답
- 인증(Authentication) 여부와 권한 부여(Authorization) 여부는 다른 개념
- 인증 - ‘자신이 누구인지 증명하는 것’
- 권한 부여 또는 인가 - ‘인증된 주체에게 작업을 허용하는 것’
- 상태 코드 404(Not Found)
- 접근하고자 하는 자원이 존재하지 않음을 알리는 상태 코드
- 존재하더라도 공개하지 않는 자원에 대해 404(Not Found)를 응답하는 경우도 있음
- 500번대: 서버 에러 상태 코드
- 500번대는 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드
- 개발 시 500번대 에러는 최대한 발생하면 안된다.
- 상태 코드 500(Internal Server Error)
- ‘서버의 예기치 못한 상황으로 인해 요청을 처리할 수 없음’
- 상태 코드 500(Internal Server Error)은 서버 내 에러를 통칭
- 상태 코드 502(Bad Gateway)
- 클라이언트와 서버 사이에 위치한 중간 서버의 통신 오류를 나타내는 상태 코드
- 프록시 등의 문제
- 상태 코드 503(Service Unavailable)
- ‘현재 서비스를 일시적으로 이용할 수 없음’
- 서버가 과부하 상태에 있거나 일시적인 점검 상태일 때 볼 수 있는 상태
