////
Search
✅

5. 응용 계층 - HTTP의 기초

•
응용 계층의 핵심 : HTTP

DNS와 URI/URL

HTTP를 이해하려면 도메인 네임, DNS(도메인 네임을 다루는 프로토콜), 웹 상에서의 자원 개념, URI에 대해 먼저 알 필요가 있음

도메인 네임과 DNS

계층 구조
•
IP 주소 : 네트워크 상의 호스트를 식별하기 위해 사용하는 정보
◦
IP 주소만 사용하긴 기억하기 너무 어려움 → 도메인 네임 사용
도메인 네임
•
문자열 형태의 호스트 특정 정보
•
호스트의 IP 주소와 대응

네임 서버(DNS 서버)

도메인 네임과 대응되는 IP 주소를 관리하는 서버
•
리졸빙(resolving)
◦
호스트가 네임 서버에 특정 도메인 네임을 가진 호스트의 IP 주소가 무엇인지 질의 → 패킷을 주고받고자 하는 호스트의 IP 주소를 알아내는 과정
•
2가지 핵심(기억할) 내용
1.
도메인 네임의 계층적 구조
2.
네임 서버의 계층적 구조

도메인 네임의 계층적 구조

도메인 네임은 점(.)을 기준으로 계층적으로 분류됨(일반적으로 3 ~ 5단계 정도로 구성)
•
루트 도메인
•
최상위 도메인(TLD)
•
2단계 도메인(세컨드 레벨 도메인)
전체 주소 도메인 네임(FQDN) : www.example.com처럼 도메인 네임을 모두 포함하는 도메인 네임
•
FQDN을 알면 호스트 식별 가능
예시) www.example.com.
◦
. : 루트 도메인
◦
com : 최상위 도메인
◦
example : 2단계 도메인
◦
www : 3단계 도메인

네임 서버의 계층적 구조

호스트가 도메인 네임(예 : minchul.net)을 이용해 IP 주소를 알아내고자 하는 경우
•
가장 먼저 로컬 네임 서버에 도메인 네임을 질의
로컬 네임 서버 : 클라이언트와 맞닿아 있는 네임 서버
◦
많은 경우 ISP가 로컬 네임 서버의 주소를 자동으로 할당(클라이언트가 먼저 질의하려면 주소를 알아야하므로)
◦
ISP에서 할당해주는 로컬 네임 서버 주소가 아닌, 공개 DNS 서버를 이용할 수도 있음
•
로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알고 있다면 클라이언트에게 즉시 IP 주소를 반환. 만약 IP 주소를 모른다면 로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알아낼 때까지 도메인 네임의 루트 도메인을 관정하는 서버(루트 네임 서버)에게 질의하고 최상위 도메인을 관장하는 서버(TLD 네임 서버)에게 질의하고 다음 네임 서버에 질의하는 식으로 이어나감

자원과 URI/URL

•
자원 : 네트워크 상의 메시지를 통해 주고받는 최종 대상
예시) HTML 파일, 이미지나 동영상 파일, 텍스트 파일 등
◦
자원 식별시, 이름을 기반으로 식별(URN)하거나 위치를 기반으로 식별(URL)하는 방식 존재

URL의 구조

1) scheme

•
자원 접근 방법 표기
•
일반적으로는 사용할 프로토콜 표기

2) authority

•
호스트를 특정할 수 있는 IP 주소나 도메인 네임을 명시
•
뒤에 포트 번호 명시 가능

3) path

•
자원이 위치하고 있는 경로 명시
•
슬래시(/)를 기준으로 계층적으로 표현(최상위 경로 또한 슬래시로 표현)

4) query

쿼리 문자열 쿼리 파라미터
•
URL에 대한 매개변수 역할을 하는 문자열
•
scheme, authority, path만으로는 표현하기 어려운 추가 정보 명시
•
물음표(?)로 시작하는 <키=값> 형태의 데이터
•
앰퍼샌드(&)를 사용해 여러 쿼리 문자열을 연결 가능

5) fragment

•
자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
일반적으로 HTML 파일 같은 자원에서 특정 부분을 가리키는 데 사용

HTTP의 특징과 메시지 구조

•
HTTP의 목적 : 애플리케이션의 다양한 자원을 네트워크를 통해 송수신하기
즉, 데이터 형식에 구애받지 않고 다양한 애플리케이션 데이터의 송수신을 가능하게 하는 것이 주된 목적

HTTP의 특징

4가지

1) HTTP는 요청과 응답을 기반으로 동작(= 요청 응답 기반 프로토콜)

•
요청 메시지를 보내는 클라이언트와 응답 메시지를 보내는 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작
•
같은 HTTP 메시지라 하더라도, HTTP 응답 메시지와 HTTP 요청 메시지의 형태는 다름

2) HTTP는 미디어 독립적(= 미디어 독립적 프로토콜)

HTTP의 주요 목적 : 애플리케이션의 다양한 데이터를 네트워크를 통해 송수신한다!
•
HTTP : 주고받을 자원의 특성과 무관하게 자원을 주고받는 수단(인터페이스)의 역할만 수행
◦
HTTP에서 메시지로 주고받는 자원의 종류 : 미디어 타입
◦
주고받을 미디어 타입에 특별한 제한을 두지 않고, 독립적으로 작동이 가능한 미디어 독립적 프로토콜
•
미디어 타입(MIME 타입)
네트워크 세상의 확장자
◦
타입/서브타입 형식으로 구성
▪
타입 : 데이터 유형
▪
서브타입 : 주어진 타입에 대한 세부 유형
타입
타입 설명
서브타입
서브타입 설명
text
일반 텍스트 형식의 데이터
text/plain
평문 텍스트 문서
이하 동일
이하 동일
text/html
HTML 문서
text/css
CSS 문서
text/javascript
자바스크립트 문서
타입
타입 설명
서브타입
서브타입 설명
image
이미지 형식의 데이터
image/png
PNG 이미지
이하 동일
이하 동일
image/jpeg
JPEG 이미지
image/webp
WebP 이미지
image/gif
GIF 이미지
타입
타입 설명
서브타입
서브타입 설명
video
비디오 형식의 데이터
video/mp4
MP4 비디오
이하 동일
이하 동일
video/ogg
OGG 비디오
video/webm
WebM 비디오
타입
타입 설명
서브타입
서브타입 설명
audio
오디오 형식의 데이터
audio/midi
MIDI 오디오
이하 동일
이하 동일
audio/wav
WAV 오디오
타입
타입 설명
서브타입
서브타입 설명
application
바이너리 형식의 데이터
application/octet-stream
알 수 없는 바이너리 데이터를 포함한 일반적인 바이너리 데이터
이하 동일
이하 동일
application/pdf
PDF 문서 형식 데이터
application/xml
XML 형식 데이터
application/json
JSON 형식 데이터
application/x-www-form-urlencoded
HTML 입력 폼 데이터(key-value 형태의 입력값을 URL 인코딩한 데이터)
타입
타입 설명
서브타입
서브타입 설명
multipart
각기 다른 미디어 타입을 가질 수 있는 여러 요소로 구성된 데이터
multipart/form-data
HTML 입력 폼 데이터
이하 동일
이하 동일
multipart/encrypted
암호화된 데이터

3) HTTP는 상태 유지 X(= 스테이트리스 프로토콜)

•
상태 유지 X = 서버가 HTTP 요청을 보낸 클라이언트 관련 상태를 기억 X
◦
즉, 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
•
HTTP가 상태를 유지하지 않는 이유
1.
일반적으로 HTTP 서버는 많은 클라이언트와 동시에 상호작용 → 서버 입장에서는 요청 메시지 수가 수천 ~ 수백만 개가 될 수도 → 모든 클라이언트의 상태 정보를 유지하려면 서버 부담 증가
◦
서버는 여러 대로 구성될 수 있음 →
◦
모든 서버가 모든 클라이언트 상태 정보를 공유해야함 → 복잡성 증가
•
HTTP 서버가 지켜야 할 중요 설계 목표
1.
확장성
•
서버가 모든 요청을 독립적인 요청으로 처리 → 특정 클라이언트가 특정 서버에 종속되지 않으므로, 서버 추가 및 대체가 쉬움
2.
견고성
•
서버 중 하나가 문제가 생기더라도 쉽게 다른 서버로 대체 가능 → 견고성 증가

4) HTTP는 지속 연결 지원(지속 연결 프로토콜)

요즘 많이 사용되는 HTTP 버전 : HTTP 1.1 & 2.0
•
비지속 연결
◦
초기 버전(HTTP 1.0 이하)에서는 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작 → 요청-응답 메시지를 주고받으려면 매번 새롭게 연결을 수립하고 종료해야함
•
지속 연결(keep-alive)
◦
HTTP 1.1 이상
◦
하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술
HTTP 버전별 특징
1.
HTTP 1.1
•
메시지를 평문으로 주고받음
•
파이프라이닝 : 연결을 한 번 해놓으면 일정 정도 유지
◦
그래도 HTML 요청에 따라 추가적으로 필요한 미디어들(이미지 등)은 1번의 요청에 1번의 응답을 받음
2.
HTTP 2.0
HTTP 1.1의 단점을 보완 및 개선하기 위한 버전
•
바이너리 데이터 기반 송수신 : 바이너리 데이터를 기반으로 메시지를 주고받음
•
헤더 압축 : 헤더를 압축한 송수신 → 네트워크 이용 효율 증가
•
서버 푸시(server push) : 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송(index.html만 요청했더라도, style.css, script.js을 함께 사용할 것으로 예상된다면 미리 함께 응답하는 형태)
•
HTTP 멀티플렉싱 기법 : 여러 개의 독립적인 stream을 바탕으로 요청-응답 메시지를 병렬적으로 주고받는 기법
◦
HTML 파일 응답을 파싱하면서 추가적으로 필요한 이미지 파일들을 서버에 요청할 때 병렬적으로 한 꺼번에 보내는 기능

HTTP 메시지 구조

1.
시작 라인
•
시작 라인으로 HTTP 요청 메시지인지 HTTP 응답 메시지인지 구분
◦
요청 라인 : 요청 메시지의 경우
메서드 요청 대상 HTTP 버전
◦
상태 라인 : 응답 메시지의 경우
HTTP 버전 상태 코드 이유 구문
2.
필드 라인(여러 개 존재 가능)
•
HTTP 헤더가 명시됨 : HTTP 메시지 전송과 관련한 부가 정보이자 제어 정보
◦
구성 : 헤더 이름(header-name) : 헤더 값(header-value)
3.
메시지 본문(없을 수도)

HTTP 메서드와 상태 코드

HTTP 메시지에서 가장 중요한 부분 :
1.
시작 라인
•
요청 라인(HTTP 요청 메시지) : 메서드
•
상태 라인(HTTP 응답 메시지) : 상태 코드(& 이유 구문)
2.
필드 라인(HTTP 헤더 명시) : 대표적인 HTTP 헤더

HTTP 메서드

GET HEAD POST PUT PATCH DELETE
HTTP 메서드
설명
GET
자원을 습득하기 위한 메서드
HEAD
GET과 동일하나, 헤더만을 응답받는 메서드
POST
서버로 하여금 특정 작업을 처리하도록 하는 메서드
PUT
자원을 대체하기 위한 메서드
PATCH
자원에 대한 부분적 수정을 위한 메서드
DELETE
자원을 삭제하기 위한 메서드
CONNECT
자원에 대한 양방향 연결을 시작하는 메서드
OPTIONS
사용 가능한 메서드 등 통신 옵션을 확인하는 메서드
TRACE
자원에 대한 루프백 테스트를 수행하는 메서드

1. GET과 HEAD

•
자원을 조회하는 용도의 메서드
•
HOST 헤더 : 요청을 보낼 호스트 명시
•
HEAD 메서드는 응답 메시지에 메시지 본문이 포함되지 않는다는 점을 제외하면 GET과 동일

2. POST

•
서버로 하여금 특정 작업을 처리하도록 요청하는 용도의 메서드
‘특정 작업’이 ‘새로운 자원 생성’인 경우가 대다수
•
Location 헤더 : 생성된 자원의 위치를 응답
•
메시지 본문 : 생성된 자원을 응답

3. PUT과 PATCH

•
PUT 메서드는 덮어쓰기를 요청하는 메서드인 반면, PATCH 메서드는 부분적 수정을 요청하는 메서드

4. DELETE

•
특정 자원의 삭제를 요청할 때 사용하는 메서드

HTTP 상태 코드

•
요청의 결과를 나타내는 3자리 정수
◦
백의 자릿수를 기준으로 요청 결과의 유형을 구분
상태 코드
설명
100번대
정보성 상태 코드
200번대
성공 상태 코드
300번대
리다이렉션 상태 코드
400번대
클라이언트 에러 상태 코드
500번대
서버 에러 상태 코드

1. 200번대 : 성공 상태 코드

•
요청이 성공했음을 의미
상태 코드
이유 구문
설명
200
OK
요청 성공
201
Created
요청 성공 & 새로운 자원 생성
202
Accepted
요청을 잘 받았지만, 아직 요청한 작업을 끝내지 않음
204
No Content
요청이 성공했지만, 메시지 본문으로 표시할 데이터 없음

2. 300번대 : 리다이렉션 상태 코드

•
Location 헤더를 통해 요청한 자원이 위치한 URL 안내 가능
◦
클라이언트를 이를 수신해 Location 헤더에 명시된 URL로 재요청 → 새로운 URL에 대한 응답 수신
상태 코드
이유 구문
설명
301
Moved Permanently
영구적 리다이렉션 : 재요청 메서드 변경될 수 있음
308
Permanent Redirect
영구적 리다이렉션 : 재요청 메서드 변경될 수 없음
302
Found
일시적 리다이렉션 : 재요청 메서드가 변경될 수 있음
303
See Other
일시적 리다이렉션 : 재요청 메서드가 GET으로 변경됨
307
Temporary Redirect
일시적 리다이렉션 : 재요청 메서드가 변경되지 않음
304
Not Modified
캐시 - 자원이 변경되지 않음
•
영구적 리다이렉션
◦
자원이 완전히 새로운 곳으로 이동 → 경로가 영구적으로 재지정되는 것
◦
요청을 보낸 기존 URL은 기억할 필요 X
•
일시적 리다이렉션
◦
자원 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우
◦
여전히 요청을 보낸 기존 URL을 기억해야함

3. 400번대 : 클라이언트 에러 상태 코드

•
클라이언트에게 잘못이 있음을 나타내는 상태 코드
상태 코드
이유 구문
설명
400
Bad Request
요청 메시지 내용 or 형식 자체에 문제 있음
401
Unauthorized
요청 자원에 대한 유효한 인증 없음
403
Forbidden
요청이 서버에 의해 거부됨 (EX : 자원에 대한 접근 권한이 충분하지 않음)
404
Not Found
요청받은 자원을 찾을 수 없음
405
Method Not Allowed
요청한 메서드를 지원하지 않음
•
401(Unauthorized) : 인증을 요구하는 상태 코드
◦
인증 : 자신이 누구인지 증명하는 작업
•
403(Forbidden) : 권한을 요구하는 상태 코드
◦
권한 : 인증된 주체에게 허용된 작업
즉, 인증이 되었더라도 권한은 충분하지 않을 수 있음에 주의

4. 500번대 상태 코드

•
서버에게 잘못이 있음을 나타내는 상태 코드
상태 코드
이유 구문
설명
500
Internal Server Error
요청 처리 불가
502
Bad Gateway
중간 서버의 통신 오류
•
500번대 상태 코드의 대부분은 500(Internal Server Error) : 서버의 문제에 대해 로그를 비롯한 문제의 발생 원인을 상세히 공개하는 것은 보안상 좋지 않아서 서버 문제를 500으로 통칭하는 경우가 대다수

HTTP 주요 헤더

•
HTTP 헤더의 종류를 매우 다양하기에, 빈번히 사용되는 HTTP 헤더의 의미를 기억해두고 새로운 헤더를 만날 때마다 그때 그때 정리해도 무방
•
현재 소개하는 헤더들은 모두 기본적인 헤더에 해당

요청 메시지에서 주로 활용되는 HTTP 헤더

1. HOST

•
요청을 보낼 호스트 명시
•
도메인 네임 or IP 주소로 표현(포트 번호가 포함될 수도)

2. User-Agent

•
대표적인 HTTP 요청 헤더
•
유저 에이전트 : 본래 HTTP 요청을 시작하는 클라이언트 측의 프로그램 의미
•
브라우저 종류, 운영체제 및 아키텍처 정보, 브라우저 렌더링 엔진 종류 등이 명시됨
•
기억해야할 점 : User-Agent 헤더를 통해 HTTP 요청 메시지를 보낸 클라이언트의 접속 수단(EX : 웹 브라우저) 유추 가능

3. Referer

•
클라이언트가 요청을 보낼 때 머무르던 URL이 명시됨 → 이를 통해 클라이언트의 유입 경로 파악 가능

응답 메시지에서 주로 활용되는 HTTP 헤더

1. Server

•
HTTP 응답 메시지를 보내는 서버 호스트와 간련된 정보 명시

2. Allow

•
처리 가능한 HTTP 헤더 목록을 알리기 위해 사용
•
상태 코드 405(Method Not Allowed)를 응답할 때 함께 사용 가능
◦
405 : 수신한 요청 메시지의 메서드를 지원하지 않는다는 것을 의미하는 상태 코드

3. Location

•
클라이언트에게 자원 위치를 알려주기 위해 사용
•
리다이렉션이 발생했을 때 or 새로운 자원이 생성되었을 때 사용

요청과 응답 메시지 모두에서 활용되는 HTTP 헤더

1. Date

•
메시지가 생성된 날짜 & 시각에 관련된 정보를 담은 헤더

2. Content-Length

•
메시지 본문의 바이트 단위 크기(길이)를 표현하기 위해 사용

3. Content-Type, Content-Language, Content-Encoding

표현 헤더(representation header)
•
Content-Type : 메시지 본문에서 사용된 미디어 타입 명시
•
Content-Language : 메시지 본문에 어떤 자연어가 사용되었는지 명시
•
Content-Encoding : 메시지 본문을 압축하거나 변환한 방식 명시

4. Connection

•
HTTP 메시지를 송신하는 호스트가 어떤 방식의 연결을 원하는지 명시하는 헤더
◦
keep-alive : 지속 연결 희망
◦
close : 연결 종료 희망