응용 계층 - HTTP의 기초
DNS과 URL & URI
IP 주소 : 네트워크 상의 호스트를 식별하기 위해 기본적으로 사용되는 정보
근데 IP 주소만을 사용한다면?
특정 호스트의 특징을 나타내기도 어렵다 -> 숫자만으로만 되어있으니..
호스트의 IP 주소는 언제든 바뀔 수 있다
도메인 네임 Domain Name 을 사용
'http://www.example.com, naver.com'와 같은 문자열 형태의 호스트 특정 정보, 호스트의 IP 주소와 대응
IP 주소에 비해 기억하기 쉬움
IP 주소가 바뀌더라도 바뀐 IP 주소에 도메인 네임을 다시 대응 , IP 주소만으로 특정하는 것보다 더 간편
도메인 네임 <- 매핑 -> IP 주소 는 네임 서버 Name Server라고 불리는 특별한 서버에서 관리
네임 서버 Name Server = DNS 서버 DNS server
전 세계 여러 군데, 여러 개의 네임 서버가 존재
호스트는 네임 서버에 이 도메인 네임을 가진 호스트의 IP가 뭐임? 물어보면서
패킷을 주고받고자 하는 호스트의 IP 주소를 알아낸다.
IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정
= 풀이(resolve)한다, 리졸빙(resolve+ing)한다 라고 표현
도메인 네임에 대해 알아야할 것은 2가지
1.도메인 네임의 계층적 구조
2.도메인 네임을 관리하는 네임 서버의 계층적 구조
1.도메인 네임의 계층적 구조
하나의 도메인 네임은 점(.) 을 기준으로 계층적으로 분류
3단계도메인.2단계도메인.최상위도메인.루트도메인
최상위 도메인 = Top-Level Domain (TLD)
최상위 도메인의 예 : 'com, net, org, kr(대 한민국), jp(일본), cn (중국), us(미국)' 등
'http://www.example.com'의 최상위 도메인은 'com'
헷갈리면 안되는게 최상위 도메인이라는 이름과 달리 실제로 도메인 네임의 마지막 부분이 아님!!
도메인 네임의 마지막 부분에 점(.)으로 표현되는 루트 도메인도 도메인 네임의 일부
일반적으로 루트 도메인 (마지막 점)을 생략
그래서 일반적으로 대개 최상위 도메인을 도메인 네임의 마지막 부분으로 간주
도메인의 단계는 이보다 더 늘어날 수 도 있지만, 일반적으로는 3~5단계 정도로 구성
'http://www.example.com.'처럼 도메인 네임을 모두 포함하는 도메인 네임은
전체 주소 도메인 네임(FQDN) Fully-Qualified Domain Name 이라고 하며, 이 FQDN을 알면 호스트를 식별 가능
+@
다른 도메인이 포함된 도메인은 서브 도메인(subdomain)이라고 부른다
예를 들어 'mail.example.com, http://www.example.com, developer.example.com'은
모두 'example.com'의 서브 도메인
2.도메인 네임을 관리하는 네임 서버의 계층적 구조
도메인 네임을 네임 서버들이 어떻게 관리?
도메인 네임도 계층적 형태, 이런 도메인 네임을 관리하는 네임 서버 또한 계층적 형태
전 세계 여러 곳에, 네임 서버는 여러 개 위치 = 네임 서버는 분산되어 관리
이렇게 계층적,분산되어 있는 도메인 네임에 대한 관리 체계 = 도메인 네임 시스템(DNS) Domain Name System
DNS는 호스트가 이러한 DNS를 이용할 수 있도록 하는 애플리케이션 계층 프로토콜을 의미하기도 함
계층 분산되어있는 네임서버를 바탕으로 어떻게 도메인 네임이 리졸빙될까?
호스트가 'minchul.net'이라는 도메인 네임을 통해 IP 주소가 뭘까하는 시나리오
호스트는 먼저 " 클라이언트와 맞닿아 있는 네임 서버 = 로컬 네임 서버 local name server" 에게 도메인 네임을 질의
일단 질의를 하려면 로컬 네임서버의 주소를 알긴해야함
많은 경우 ISP가 로컬 네임 서버의 주소를 자동으로 할당
+@
ISP는 Internet Service Provider(인터넷 서비스 제공자)의 줄임말
집이나 회사에서 인터넷을 쓰려면 통신사(예: KT, SK브로드밴드, LG U+) 같은 업체랑 계약
ISP = 업체
- 역할: 인터넷 접속을 가능하게 해주는 회사
- 제공 서비스: 인터넷 회선, IP 주소, 로컬 네임 서버 주소 같은 네트워크 자원 자동 할당(DHCP 등)
즉, 네가 인터넷을 켜면 ISP가 네 컴퓨터나 공유기한테 로컬 네임 서버 주소도 같이 알려주는 것
다만, ISP에서 할당해 주는 로컬 네임 서버 주소가 아닌, 공개 DNS 서버 public DNS Server를 이용 가능
공개 DNS 서버 ex) 구글의 '8.8.8.8,8.8.4.4'와 클라우드플레어의 '1.1.1.1'
로컬 네임 서버가 FQDN에 대응하는 IP 주소 알고있다? 클라이언트에게 IP 주소를 반환
근데 로컬 네임 서버가 IP 주소를 모른다?
IP 주소를 알아낼 때까지
도메인 네임의 루트 도메인을 관장하는 서버(루트 네임 서버root name server) 에게 물어보고
최상위 도메인을 관장하는 서버(TLD 네임 서버TLD name server)에게 물어보고
그 하위 레벨의 도메인 네임을 관장하는 네임 서버 등에 걸쳐 물어봄
그렇게 최종적으로 해당 주소를 클라이언트에게 전달하게 되죠.
근데 이런 질의 과정이 반복 = 트래픽이 많아짐 = 리졸빙이 오래걸림
그래서 네임 서버들이 기존에 응답받은 결과를 임시로 저장, 똑같은 질의면 다시 씀 = DNS 캐시 DNS cache
DNS 캐시를 저 장하는 용도로만 활용되는 서버도 존재
자주 접속하는 웹사이트와 같이 자주 질의되는 도메인 네임인 경우의
대부분이 로컬 네임 서버 선에서 캐시되어 있음
+@
DNS 서버에 캐시된 값은 TTL(Time To Live) 값이 존재
여기서 TTL은 캐시될 수 있는 시간
++@
DNS 레코드 타입
내가 만든 서버를 배포하고싶다
서버 컴퓨터의 IP를 통해 클라이언트는 서버 프로그램과 상호작용
이떄 IP주소가 아니라 도메인 네임을 통해 상호작용하게 하려면?
1. 도메인 네임을 구입
도메인 네임은 각종 DNS 서비스 업체에서 구매 가능, 해당 업체들은 많은 경우 네임 서버를 운영
그다음으로는 서버 IP 주소 <- 매핑 -> 구매한 도메인 네임을 매핑해야한다
2. 네임 서버에 도메인 네임 관련 설정 정보를 추가, 추가하는 정보 = DNS 자원 레코드(DNS resource record)
DNS 레코드에 포함된 정보는 어떤 DNS 서비스 업체인지와 무관하게 거의 비슷
기본적으로 이름(Record name)과 그에 대응하는 값(Value),
그 <이름, 값 쌍 의 유형을 나타내는 레코드 타입(Record type)도 포함
자원과 URL & URI
URI = 웹 상에서의 자원과 이를 식별하기 위한 정보
앞에서 자원 = 프로그램 실행에 필요한 요소라고 설명
네트워크 맥락에서의 자원의 의미도 비슷
자원 resource = 네트워크 상의 메시지를 통해 주고받는 최종 대상
ex) HTML파일, 이미지, 동영상, 텍스트 등등이 될수가있다
즉, 두 호스트가 네트워크를 통 해 서로 정보를 주고받을 때 송수신하는 대상
URI Uniform Resource Identifier = 웹 상에서의 자원을 식별하기 위한 정보
자원(Resource)을 식별 (Indentifier)하는 통일된 방식(Uniform)
URI로 자원을 식별할 때는 '이름'을 기반 or '위치'를 기반으로 식별
이름 기반 - > URN Uniform Resource Name
위치 기반 - > URL Uniform Resource Locator , 요즘은 URL을 쓴다.
URL의 구조
예시
foo: // http://www.example.com:8042 /over/there ?name=ferret# nose
1. scheme - foo:
2. authority - http://www.example.com:8042
3. path - /over/there
4. query - ?name=ferret#
5. fragment - nose
1. scheme = 자원에 접근하는 방법
scheme 값은 매우 다양, 일반적으로는 사용할 프로토콜이 명시
scheme가 'http://'일 경우 HTTP를 사용 하여 자원에 접근, 'https://'일 경우 HTTPS를 사용하여 자원에 접근
2. authority = 호스트를 특정할 수 있는 IP 주소나 도메인 네임 , 콜론(:) 뒤에 포트 번호를 명시 가능
3. path = 자원이 위치하고 있는 경로가 명시
슬래시(/)를 기준으로 계층적으로 표현, 최상위 경로 또한 슬래시로 표현
example. com의 자원 중 /home/images/a.png에 위치한 자원'은 'http://example.com/home/images/a.png'로 표현
4. query = URL에 대한 매개변수 역할을 하는 문자열
쿼리 문자열 query string, 쿼리 파라미터 query parameter 라고도 한다
'scheme, authority, path만으로는 표현하기 어려운 추가 정보'
자원을 식별하기 위해 추가적인 정보가 필요한 case 존재
ex) 수많은 단어 목록 중에서 '특정 단어를 검색한 결과'에 해당하는 자원
수많은 상품 목록 중에서 '특정 상품을 검색 한 뒤 그 결과를 내림차순으로 정렬한 결과'
이런 거는 scheme, authority, path만으로 표현하기는 어려움
이떄 쿼리 문자열 사용
쿼리 문자열 : ?와 <키=값>과 & 를 사용하여 표현
지역: location
침실 수: rooms
면적: size
최소 가격: min_price
http://example.com/search?location=seoul&rooms=2&size=100&min_price=200000
5. fragment = 자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
(a) https://datatracker.ietf.org/doc/html/rfc3986
(b) https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.2
URL (a)는 자원의 조각이 아닌 자원 그 자체(HTML 파일 자원 자체)
URL (b)는 HTML 자원의 특정 부분을 가리키므로 HTML 파일의 특정 부분으로 이동
+@
URL = 위치 기반, 근데 자원의 위치는 가변 -> 자원의 위치가 변하면 URL은 유효 X
URN = 이름 기반의 식별자 -> 자원의 위치와 무관하게 자원을 식별
ex) ISBN이 '0451450523'인 도서를 나타내는 URN -> urn:isbn:0451450523
위치나 프로토콜과 무관하게 자원을 식별, 단점은 널리 채택된 방식은 아니라는 점
HTTP의 특징
HTTP의 목적
애플리케이션의 다양한 자원을 네트워크를 통해 송수신
데이터의 형식에 구애 받지 않고 다양한 애플리케이션 데이터의 송수신
HTTP의 특징 4가지
1. HTTP는 요청과 응답을 기반으로 동작 (요청 응답 기반 프로토 콜)
2. HTTP는 미디어 독립적 (미디어 독립적 프로토콜)
3. HTTP는 상태 유지 X (스테이트리스 프로토콜)
4. HTTP는 지속 연결을 지원 (지속 연결 프로토콜)
1. (요청 응답 기반 프로토 콜)
기본적으로 요청을 보내는 클라이언트 <-> 응답 메시지를 보내는 서버
서로 HTTP REQUEST RESPONSE를 주고받는 구조
같은 메시지라도 요청메시지와 응답메시지의 구조는 다름
2. (미디어 독립적 프로토콜)
다양한 데이터를 네트워크를 통해 송수신한다는 목적
HTTP는 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원을 송수신 가능
주고받을 자원의 특성과 무관하게 자원을 주고받는 수단(인터페이스)의 역할만 수행
미디어 타입 media type = 메시지로 주고받는 자원의 종류
주고받을 미디어 타입에 특별한 제한 X, 독립적으로 작동이 가능한 미디어 독립적인 프로토콜
+@
미디어 타입은 MIME 타입(Multipurpose Internet Mail Extensions Type)이라고도 부릅니다.
미디어 타입은 네트워크 단의 확장자라고 할 수 있다.
ex) 파일의 종류를 .html, .png, .json, .mp4와 같은 확장자로 표현
HTTP를 통해 송수신하는 자원의 종류는 미디어 타입으로 표현
기본적으로 슬래시를 기준으로 하는 '타입/서브타입'의 형식으로 구성
타입type = 데이터의 유형, 서브타입subtype = 주어진 타입에 대한 세부 유형
3. (스테이트리스 프로토콜)
HTTP는 상태를 유지하지 않는 스테이트리스stateless 프로토콜
= 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억 X
-> 클라이언트의 모든 HTTP 요청은 독립적인 요청으로 간주
왜 이렇게 만들어 놓았을까?
일반적으로 HTTP 서버는 많은 클라이언트와 동시에 상호작용
만약 클라이언트 상태 정보를 기억한다면?
요청 메시지가 수백만 개가 될 수도 있는데,모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담
서버는 여러대면 여러 대로 구성된 서버 모두가 모든 클라이언트의 상태 정보를 공유해야될지도
공유 못하면 특정 서버하고만 계속 상호작용해야됨 = 특정 클라이언트가 특정 서버에 종속(그 서버가 다운된다면?)
HTTP 서버 설계 목표 -> 확장성scalability, 견고성robustness
서버가 상태를 유지 X, 모든 요청을 독립적인 요청으로 처리 한다면?
특정 클라이언트가 특정 서버에 종속 X -> 서버의 추가나 대체가 쉽다
결론 스테이트리스 특성은
필요할 경우 언제든 쉽게 서버를 추가 = 확장성
서버 중 하나에 문제가 생기더라도 쉽게 다른 서버로 대체 = 견고성 이 좋다
4. (지속 연결 프로토콜)
HTTP에는 버전 존재
요즘 많이 쓰는 버전 HTTP 1.1과 2.0은 TCP를 기반으로 동작
앞에서 TCP는 연결형 프로토콜이라 배웠는데? HTTP는 비연결형 프로토콜인데?
초기 HTTP 버전(HTTP 1.0 이하)에서는 쓰리 웨이 핸드셰이크를 통해 TCP 연결을 수립한 후,
요청에 대한 응답을 받으면 연결을 종료하는 방식
추가적인 요청 응답 메시지를 주고받 으려면 매번 새롭게 연결을 수립하고 종료
--> 이런 방식을 '비지속 연결'
최근 HTTP 버전(HTTP 1.1 이상)에서는 지속 연결 persistent connection 기술 사용 ( 킵 얼라이브keep-alive )
하나의 TCP 연결 상에서 여러 개의 요청 응답을 주고받을 수 있는 기술
지속 연결을 통해 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답을 처리
+@
HTTP 버전별 특징
ㄱ. HTTP 1.1
1.1 부터 지속 연결 기능 지원
1.1 버전 이전은 공식적으로 비지속 연결을 기반으로 동작
1.1은 메시지를 평문으로 송수신, 콘텐츠 협상 기능 등 다양한 편의 기능들이 추가
ㄴ. HTTP 2.0
바이너리 데이터 기반 송수산
평문으로 메시지를 주고받는 HTTP 1.1과는 달리, 바이너리 데이터를 기반으로 송수신
헤더 압축
헤더를 압축하여 송수신, 네트워크 이용 효율 좋다
서버 푸시(server push)
클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송하는 기능
ex) 클라이언트가 "index.html'이라는 자원만을 요청,
근데 'styles. css, scripts.js' 파일이 'index.html'과 함께 사용될 것으로 예상되는 경우, 이를 미리 함께 응답
HTTP 멀티플렉싱(multiplexing) 기법
여러 개의 독립적인 스트림(stream)을 바탕으로 요청 응답 메시지를 병렬적으로 주고받는 기술
요청과 응답을 주고받는 단위는 하나의 스트림에서 이루어 지고, 이러한 스트림 여러 개를 독립적으로 활용
HTTP 멀티플렉싱을 통해 HTTP 1.1의 고질적인 문제 = HOL 블로킹(Head-Of-Line blocking) 을 완화
HOL 블로킹 = 같은 큐에 대기 하며 순차적으로 처리되는 여러 패킷이 있을 때
첫 번째 패킷의 처리 지연으로 인해 나머지 패킷들의 처리도 모두 지연되는 문제 상황
ㄷ. HTTP 3.0
가장 최근 등장, 사용 비중이 점차 높아짐
UDP를 기반으로 동작 (이전까지의 모두 TCP를 기반으로 동작)
3.0부터는 UDP를 기반으로 구현된 QUIC(Quick UDP Internet Connections)이라는 프로토콜을 기반으로 동작
UDP는 TCP에 비해 상대적으로 송수신 속도가 빠 르기 때문에 HTTP/3.0을 통해 속도 측면에서 큰 개선
HTTP 메시지 구조
HTTP 메시지 (1.1 기준)
시작 라인, 필드 라인, 메시지 본문로 구성
< 시작 라인 >
<필드 라인들>
<빈 줄>
<메시지 본문>
필드 라인은 여러개 가능, 메세지 본문은 없을 수도
메시지 본문 = HTTP를 통해 주고받는 자원이 명시
HTTP는 다양한 미디어 타입 가능 -> 시작라인과 필드 라인에 대해 잘 알자
시작 라인
HTTP는 요청-응답 기반 프로토콜, 요청인지 응답인지에 따라 시작라인이 달라짐
요청 메시지 -> 요청 라인 request line
응답 메시지 -> 상태 라인 status line
1. 요청 라인
- 메서드: GET, POST, PUT, DELETE 같은 동작 방식
- 요청 대상: URL 경로 (예: /api/user/1 , /hello?q=network)
- HTTP 버전: 보통 HTTP/1.1
2. 상태 라인
이유문구는 생략 가능
- HTTP 버전: 요청과 동일하게 HTTP/1.1 같은 형태
- 상태 코드: 200, 404, 500 등 서버가 돌려주는 결과 코드
- 이유 문구: 상태 코드의 짧은 설명 (예: OK, Not Found)
필드 라인
필드 라인에는 HTTP 헤더가 명시
헤더는 메시지 전송과 관련된 부가 정보,제어 정보
일반적으로 하나의 메시지에는 여러개의 헤더 존재
헤더는 콜론 : 을 기준으로 헤더 이름 : 헤더 값 형태로 구성
자주 쓰는 요청 헤더:
Host: 요청 대상 서버 호스트명
User-Agent: 클라이언트 정보 (브라우저, 앱 등)
Accept: 클라이언트가 받을 수 있는 콘텐츠 타입
자주 쓰는 응답 헤더:
Content-Type: 본문이 어떤 타입인지 (text/html, application/json)
Content-Length: 본문 길이
Set-Cookie: 쿠키 설정
HTTP 메서드
시작 라인, 헤더가 명시되는 필드 라인이 제일 중요
요청 라인에서는 메서드, 상태 라인에서는 상태 코드(와 그를 설명하는 이유 구문)이 핵심
HTTP 메서드
1. GET
- 서버에서 리소스를 가져올 때 사용.
2. HEAD
- GET이랑 거의 똑같이 동작하지만, 본문은 빼고 헤더만 응답받음.
3. POST
- 서버에 데이터 전송, 작업 처리 요청
- 서버 상태 변경 (글 작성, 데이터 생성)할 때 자주 사용.
4. PUT
- 지정한 리소스를 통째로 대체.
- 없으면 새로 만들고, 있으면 전부 덮어씀.
5. DELETE
- 지정한 리소스를 삭제.
- 역시 멱등성 있음 (여러 번 삭제 요청해도 결과는 같음: 삭제된 상태).
6. PATCH
- 리소스를 부분적으로 수정할 때 사용.
- PUT은 전체 교체, PATCH는 필요한 부분만 업데이트.
6. CONNECT
- 클라이언트와 목적지 서버 사이에 터널을 열 때 사용.
- 주로 HTTPS (TLS/SSL) 통신할 때 프록시 서버를 통해 연결하기 위해 쓰임.
7. OPTIONS
- 서버가 어떤 메서드를 지원하는지 확인할 때 사용.
- 예: Allow: GET, POST, HEAD 같은 헤더가 응답으로 옴.
8. TRACE
- 요청이 서버까지 가는 경로를 그대로 돌려줌.
- 디버깅 용도. 보안상 문제될 수 있어 실제 서비스에서는 거의 막아둠.
GET과 HEAD
GET은 가장 흔히 사용, 자원을 조회하는 용도
웹브라우저로 웹사이트에 대해 자원 보고싶다 -> 해당 웹사이트에 GET 요청을 보내는 것
웹 브라우저를 통한 웹 페이지 조회 = 웹 브라우저의 GET 요청 메시지에 대한 응답
| GET /example-page HTTP/1.1 Host: http://www.example.com Accept: * |
해석해보자면
요청 라인 : <GET으로> </example-page를 요청한다><HTTP버전은 1.1로>
헤더
<대상 호스트는 http://www.example.com>
<내가 받는 파일형태는 다 받을게>
호스트 정보 그리고 요청 대상을 조합해서 http://www.example.com/example-page 라는 URL 유추 가능
HEAD는 응답에서 응답 본문을 날린 헤더만 받겠다는 메서드
POST
POST는 서버로 하여금 특정 작업을 처리하도록 요청하는 용도로 사용
많은 경우에 '클라이언트가 서버에 새로운 자원 을 생성하고자 할 때' 사용
| POST /api/users HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 52 { "username": "영지", "email": "영지@example.com", "password": "8848" } |
| HTTP/1.1 201 Created Content-Type: application/json Content-Length: 85 Location: /api/users/123 { "id": 123, "username": "영지", "email": "영지@example.com", "message": "회원 가입 완료" } |
Location 헤더로 생성 위치, 본문을 통해 생성된 자원을 응답
PUT과 PATCH
PUT은 통째로 덮어쓰기 ( 데이터 구조가 바뀌는 수준으로)
PATCH은 부분적 수정 ( 데이터값만 덮어씌운다)
ex) 서버에 id=8848, title="KING" , contents="kkkk" 가 존재한다고 가정
put으로 id=8848, contents='aaaa' 보내면
서버는 id=8848, contents='aaaa' 로 수정
patch로 id=8848, contents='aaaa' 보내면
서버는 id=8848, title="KING" , contents='aaaa' 로 수정
HTTP 상태 코드
상태 코드는 서버가 클라이언트 요청을 처리한 결과를 나타내는 숫자 코드
| 1xx (정보) | 정보성 상태 코드, 요청을 잘 받았고, 계속 진행 중이라는 뜻. |
| 2xx (성공) | 성공 상태 코드, 요청이 정상적으로 처리됨. |
| 3xx (리다이렉션) | 리다이렉션 상태 코드 , 다른 경로로 이동해야 함. |
| 4xx (클라이언트 오류) | 클라 에러 상태 코드, 요청이 잘못됨 (클라이언트 책임). |
| 5xx (서버 오류) | 서버 에러 상태 코드, 서버가 요청 처리 실패 (서버 책임). |
1. 200번대
- 200 OK: 성공
- 201 Created: 새 리소스 생성됨
- 202 Accepted : 요청은 받아들였는데, 아직 요청한 작업 안끝남
- 204 No Content: 성공했지만 본문 없음
2. 300번대
- 301 Moved Permanently: 영구 이동, 영구적 리다이렉션 - 재요청 메서드가 변경될 수 있음
- 302 Found: 임시 이동, 일시적 리다이렉션 - 재요청 메서드가 변경되지 될수있음
- 303 See Other : 일시적 리다이렉션 - 재요청 메서드가 GET으로 변경됨
- 304 Not Modified: 캐시 사용 가능, 캐시 - 자원이 변경되지 않음
- 307 Temporary Redirect : 일시적 리다이렉션 - 재요청 메서드가 변경되지 않음
- 308 Permanent Redirect : 영구 이동, 영구적 리다이렉션 - 재요청 메서드가 변경될 수 업음
영구적 리다이렉션 = 자원이 새로운 곳으로 이동,경로가 영구적으로 재지정
기존 URL에 요청메시지를 보내면 항상 새로운 URL로 리다이렉트
결과로 영구적인 리다이렉션 관련 상태 코드 -> 요청을 보낸 기존의 URL은 기억할 필요 없다
일시적 리다이렉션 = 자원의 위치가 임시로 변경, 임시로 사용할 URL이 필요한 경우
일시적인 리다이렉션 관련 상태 코드 응답? 요청을 보낸 기존의 URL을 기억해놓아야댐
301 (Moved Permanently)는 GET으로 변경될 가능성
308 (Permanent Redirect)의 첫 번째 요청 메서드에서 변경 X
302, 307도 마찬가지
3. 400번대
- 요청이 잘못됨 (클라이언트 책임).
- 400 Bad Request: 잘못된 요청
- 401 Unauthorized: 인증 필요
- 403 Forbidden: 권한 없음
- 404 Not Found: 리소스 없음
- 405 Method Not Allowed : 요청한 메서드 지원안함
401 (Unauthorized)은 인증authentication을 요구하는 상태 코드
403 (Forbidden)은 인가 authorization 을 요구하는 상태 코드
인증 - '자신이 누구인지를 증명하 는 작업'
인가 - '인증된 주체에게 허용된 작업'을 의미
일단 우리 유저가 맞는지 아닌지? -> 인증
유저는 맞는데 관리자인지 일반유저인지?-> 인가
4. 500번대
- 서버가 요청 처리 실패 (서버 책임).
- 500 Internal Server Error: 서버 내부 에러
- 502 Bad Gateway: 게이트웨이/프록시 문제
- 503 Service Unavailable: 서버 과부하/점검 중
500번대 상태 코드의 대부분은 '요청을 처리할 수 없음'을 나타내는 500 (Internal Server Error)
상세한 에러 내용을 사용자에게 알려주는거는 보안 문제랑 연결댐
보통 서버 문제를 가리키는 상태 코드 는 500 (Internal Server Error)으로 통칭
HTTP 주요 헤더
1. 요청 메시지(Request)에서 주로 활용되는 헤더
- Host : 요청 대상 서버의 호스트 이름 (Host: example.com) 도메인네임 or IP 주소 + 포트번호
- User-Agent : 클라이언트 정보 (브라우저, 앱, 라이브러리 등)
웹브라우저와 Mozilla호환정보,운영체제아키텍쳐정보,렌더링엔진,브라우저정보... - Referer
개발 초기 당시 오타로 표기됐던 'Referer'라는 단어가 오늘날까지 헤더의 이름으로 사용
Referer 헤더에는 클라이언트가 요청을 보낼 때 머무르던 URL이 명시
유입 경로 파악 가능 - Accept : 클라이언트가 원하는 응답 콘텐츠 타입 (application/json, text/html)
- Accept-Language : 선호하는 언어 (ko-KR, en-US)
- Accept-Encoding : 지원하는 압축 방식 (gzip, deflate)
- Authorization : 인증 토큰, 자격 증명 (Bearer 토큰, Basic ...)
- Cookie : 서버가 이전에 내려준 쿠키 전송
2. 응답 메시지(Response)에서 주로 활용되는 헤더
- Servce : 응답을 보내는 서버 호스트와 관련된 정보
- Allow : 처리가능한 http헤더타입을 알린다 (405번 코드와 같이사용)
- Location : 리다이렉션 대상 URL (HTTP 302, 201 Created 시 자주 사용)
- Set-Cookie : 쿠키 생성/수정 (Set-Cookie: sessionId=abc123; HttpOnly)
- WWW-Authenticate : 인증 방식 요구 (401 Unauthorized 응답 시)
3. 요청/응답 둘 다에서 활용되는 공통 헤더
- Cache-Control : 캐싱 정책 (no-cache, max-age=3600)
- Connection : 연결 방식 (keep-alive, close)
- Content-Length : 본문 길이(바이트 단위)
- Date : 메시지 생성 날짜와 시간
- Content-Encoding : 본문 압축 방식 (gzip, br)
- Content-Type : 본문 데이터 타입 (application/json, text/html)
- Transfer-Encoding : 전송 인코딩 (chunked)
'CS > CS' 카테고리의 다른 글
| 데이터베이스 DB 설계 (0) | 2025.09.05 |
|---|---|
| HTTP - ㄴ (1) | 2025.09.03 |
| Graph 그래프 (3) | 2025.08.29 |
| 트리 Tree (3) | 2025.08.29 |
| 동기화 , 교착 상태(DeadLock) (3) | 2025.08.24 |