HTTP의 기초
DNS와 URI / URL
도메인 네임과 DNS
- IP 주소의 한계점 : 특정 호스트의 특징을 나타내기 어려움 & IP 주소는 바뀔 수 있음 → 도메인 네임이 등장
- 도메인 네임 예시 : naver.com, kernel.org등 문자열 호스트 특정 정보로, 호스트의 IP 주소와 대응
- 네임 서버 : 도메인 네임과 그에 대응하는 IP 주소를 관리하는 서버
- DNS 서버 : 도메인 네임을 관리하는 네임 서버
- 호스트 : 네임 서버에 "도메인 네임 가진 호스트 IP 주소를 주세요!" → 호스트 IP 주소 얻을 수 있음 == 리졸빙 한다
- 도메인 네임의 계층적 구조
- 점(.) 을 기준으로 분류 되어있음.
- [최상단에 루트 도메인(.) → 최상위 도메인(TLD) - kr, jp, cn ... → 2단계 도메인 → 3단계 도메인 ] == 전체 주소 도메인 네임 (FQDN)
- 도메인 네임 시스템 (DNS)
- 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계
- DNS를 이용할 수 있도록 하는 어플리케이션 계층 프로토콜을 의미하기도 함
- 도메인 네임이 네임서버를 바탕으로 리졸빙 되는 방법
- 1. 로컬 네임 서버(클라이언트와 맞닿아 있는 네임 서버)에게 도메인 네임 질의 → 루트 도메인 관장하는 서버 → 최상위 도메인을 관장하는 서버 .... 등에 걸쳐 꾸준히 질의
- 즉, 도메인 네임이 계층적인 구조를 띄는 것처럼, 도메인 네임의 각 구조를 관리하는 서버 또한, 계측적 구조로 관리
- 질의 과정이 많이 반복 → 네트워크 내 트래픽 증가 → 리졸빙에 오랜 시간 걸림 → → 기존에 응답받은 결과를 임시로 저장하여, 추후 같은 질의에 활용하는 경우가 많음 → DNS 캐시라고 함.
- DNS 캐시 사용시, 빠른 시간안에 원하는 IP 주소를 얻어낼 수 있음 → 자주 질의되는 도메인 네임의 경우, 로컬 네임 서버 선에서 캐시 되어 있음!!!!!
자원과 URI / URL
- 자원 : 네트워크 상의 메시지를 통해 주고받는 최종 대상 (ex. HTML, image, avi, txt ...)
- URI(Uniform Resource identifier)
- 웹 상에서의 자원(Resource)을 식별(identifier) 하기 위한 통일된 방식(Uniform)이자 정보
- URN(Uniform Resource Name) : 이름으로 자원을 식별하는 방식 → 고유성을 가지고 있음
- URL(Uniform Resource Locator) : 위치로 자원을 식별하는 방식, 오늘날 많이 쓰임
- 1. scheme
- 자원에 접근하는 방법
- 일반적으로 사용할 프로토콜 명시 (http, https)
- 2. authority
- 호스트를 특정할 수 있는 IP 주소나 도메인 네임 명시
- : 뒤에 포트 번호를 명시 할 수 있음
- 3. path
- 자원이 위치하고 있는 경로 명시
- 슬래시 기준으로 계층적 표현
- 4. query
- URL에 대한 매개변수 역할을 하는 문자열
- 쿼리 문자열, 쿼리 파라미터로 불림
- DB 짤때, ~~~~/reportId=1& 이부분
- 5. fragment
- 자원의 한 조각을 가리키기 위한 정보
- 일반적으로 HTML 파일과 같은 자원에서 특정 부분을 가리키는데 사용
HTTP의 특징과 메시지 구조
- HTTP의 목적
- 애플리 케이션의 다양한 자원을 네트워크를 통해 송수신 하기
- 데이터의 형식에 구애받지 않고, 다양한 앱 데이터의 송수신을 가능하게 하는 것!!!
HTTP의 특징
- 1. 요청 응답 기반 프로토콜
- 클라이언트의 요청 메시지 → 응답 메시지를 보내는 서버
- 같은 HTTP 메시지이지만, 요청, 응답 HTTP 메시지의 형태는 다름
- 2. 미디어 독립적 프로토콜
- 미디어 타입 : HTTP에서 메시지로 주고받는 자원의 종류 (MIME 타입이라고도 함)
- 3. 스테이트리스 프로토콜
- 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않음 → 클라이언트의 모든 HTTP 요청은 독립적인 요청으로 간주
- 인터넷 표준 공식 문서인 RFC 9110에서 가장 먼저 강조된 특성!
- 상태를 유지하지 않는 이유?
- HTTP 서버는 많은 클라이언트와 동시 상호 작용 → 모든 상태 정보 유지는 서버에 부담
- 서버가 여러대일 경우, 모든 상태정보를 공유해야하는데, 만약 못할경우, 특정 서버와 상호작용 → 종속되버림 → 통신 내역을 잃어버리는 상황 발생 가능
- HTTP 설계 목표는 확장성과 견고성이 있음
- 모든 요청을 독립 처리 → 종속 X → 서버의 추가나 대체가 쉬워짐 → 확장성 증가
- 서버 중 하나에 문제가 생기더라도 다른 서버로 대체 → 견고성 증가
- 4. 지속 연결 프로토콜
- 지속 연결
- 하나의 TCP 연결 상에서 여러개의 요청-응답을 주고받을 수 있는 기술
- 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답 처리 가능
- 지속 연결
- HTTP 버전별 특징
HTTP 메시지 구조
- 시작 라인
![]() |
시작라인, 필드라인, 메시지 본문으로 이루어짐 필드라인 : 여러개 존재 가능 메시지 본문 : 없을 수 있으며, HTTP를 통해 주고받는 자원 명시 |
![]() |
![]() |
구분 | 필드 이름 | 설명 |
요청 라인 | 메서드(method) | 클라이언트가 서버의 자원에 대해 수행할 작업의 종류를 나타냄 |
요청 대상(request-target) | 요청을 보낼 서버의 자원을 명시 일반적으로 쿼리 문자열이 포함된 URL의 path가 명시 |
|
HTTP 버전(HTTP-version) | 사용된 HTTP 버전으로, 'HTTP/<버전>'형식 | |
상태라인 | HTTP 버전(HTTP-version) | 사용된 HTTP 버전으로, 'HTTP/<버전>'형식 |
상태 코드(status code) | 요청에 대한 결과를 나타내는 3자리 정수 | |
이유 구문(reason phrase) | 상태 코드에 대한 문자열 형태의 설명 (200 등) |
- 필드 라인
- HTTP 헤더 명시
- 메시지 전송과 관련된 부가 정보이자 제어 정보임
- 여러개의 헤더가 포함되어 있음
- 요약
HTTP 메서드와 상태 코드
HTTP 메서드
- 1. GET 과 HEAD
- GET : 자원을 조회하는 용도
- 즉, 웹 브라우저를 통한 웹 페이지 조회 == GET 요청 메시지에 대한 응답
- HEAD : 응답 메시지에 메시지 본문이 포함되지 않는다는 점 제외, GET 메서드와 동일
![]() |
![]() |
- 2. POST
- 서버로 하여금 특정 작업을 처리하도록 요청하는 용도로 사용되는 메서드
- 일반적으로 '클라이언트가 서버에 새로운 자원을 생성하고자 할때' 사용
![]() |
![]() |
- 3. PUT 과 PATCH
- PUT : 덮어쓰기를 요청하는 메서드
- PATCH : 부분 수정을 요청하는 메서드
- 4. DELETE
- 특정 자원의 삭제를 요청할 때 사용되는 메서드
HTTP 상태 코드
- 1. 200번대 : 성공 상태 코드
상태코드 | 이유 구문 | 설명 |
200 | OK | 요청이 성공 |
201 | Created | 요청이 성공했고, 새로운 자원 생성 |
202 | Accepted | 요청은 잘받음, 아직 요청한 작업을 끝내지 않음 |
204 | No Content | 요청은 성공, 메시지 본문으로 표시할 데이터X |
- 2. 300번대 : 리다이렉션 상태 코드
- 리다이렉션 : 클라이언트가 요청한 자원이 다른곳에 있을때, 다른 곳으로 요청을 이동시키는 것
- 영구적 리다이렉션 : 자원이 완전히 새로운 것으로 이동 → 경로가 영구적으로 재지정되는 것
- 일시적 리다이렉션 : 자원의 위치가 임시로 변경 or 임시로 사용할 URL이 필요한 경우 사
- 리다이렉션 : 클라이언트가 요청한 자원이 다른곳에 있을때, 다른 곳으로 요청을 이동시키는 것
상태코드 | 이유 구문 | 설명 |
301 | Moved Permanently | 영구적 리다이렉션 - 재요청 메서드가 변경될 수 있음 |
308 | Permanent Redirect | 영구적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
302 | Found | 일시적 리다이렉션- 재요청 메서드가 변경될 수 있음 |
303 | See Other | 일시적 리다이렉션 - 재요청 메서드가 GET으로 변경됨 |
307 | Temporary Redirect | 일시적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
304 | Not Modified | 캐시 - 자원이 변경되지 않음 |
- 3. 400번대 : 클라이언트 에러 상태 코드
- 클라이언트에게 잘못이 있음을 나타내는 상태 코드
- 401 : 인증(authentication)을 요구하는 상태 코드
- 인증 : 자신이 누구인지를 증명하는 작업
- 403 : 권한(authorization)을 요구하는 상태 코드
- 권한 : 인증된 주체에게 허용된 작업
- 401 : 인증(authentication)을 요구하는 상태 코드
- 클라이언트에게 잘못이 있음을 나타내는 상태 코드
상태코드 | 이유 구문 | 설명 |
400 | Bad Request | 요청 메시지의 내용이나 형식 자체에 문제 |
401 | Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 |
403 | Forbidden | 요청이 서버에 의해 거부됨 (자원에 대한 접근 권한 충분X) |
404 | Not Found | 요청받은 자원을 찾을 수 없음 |
405 | Method Not Allowed | 요청한 메서드를 지원하지 않음 |
- 4. 500번대 상태 코드
- 서버에게 잘못이 있음을 나타내는 상태 코드
상태코드 | 이유 구문 | 설명 |
500 | Internal Server Error | 요청을 처리할 수 없음 (대부분 이것) |
502 | Bad Gateway | 중간 서버의 통신 오류 |
HTTP 주요 헤더
요청 메시지에서 주로 활용되는 HTTP 헤더 : Host, User-Agent, Referer
- 1. Host
- 요청을 보낼 호스트가 명시되는 헤더
- 도메인 네임이나 IP 주소로 표현, port number가 포함될수도 있음
- 2. User-Agent
- HTTP 요청을 시작하는 클라이언트 측의 프로그램 (웹 브라우저가 대표적)
- 운영 체제, 아키텍처의 정보, 렌더링 엔진의 종류 등 명시
- 3. Referer
- 클라이언트가 요청을 보낼때 머무르던 URL이 명시 → 클라이언트의 유입 경로 파악 가능
응답 메시지에서 주로 활용되는 HTTP 헤더 : Server, Allow, Location
- 1. Server
- HTTP 응답 메시지를 보내는 서버 호스트와 관련된 정보 명시
- 2. Allow
- 처리 가능한 HTTP 헤더 목록을 알리기 위해 사용
- 3. Location
- 클라이언트에게 자원의 위치를 알려주기 위해 사용
- 주로, 리다이렉션이 발생했을때, 새로운 자원이 생성되었을 때 사용
요청, 응답 메시지 모두에서 활용되는 HTTP 헤더 : Date, Content-Length, Content-Type, Content-Language, Content-Encoding, Connection
- 1. Date
- 메시지가 생성된 날짜와 시각 정보 담은 헤더
- 2. Content-Length
- 메시지 본문의 바이트 단위 크기를 표현에 사용
- 3. Content-Type, Content-Language, Content-Encoding
- 메시지 본문이 어떻게 표현되었는지 관련된 헤더
- 표현 헤더라고도 함
- 4. Connection
- HTTP 메시지를 송신하는 호스트가 원하는 방식의 연결을 명시하는 헤더
- keep-alive : 지속 연결 희망 , close : 연결 종료 희
HTTP의 응용
쿠키
- HTTP의 스테이트리스한 특성을 보완하기 위한 수단
- 서버에서 생성되며, 클라이언트 측에 저장되는 <이름, value> 쌍 형태의 데이터
- 쿠키의 만료 기간등과 같은 속성값도 소유 가능
- 클라이언트의 브라우저에 주로 저장
캐시
- 응답받은 자원의 사본을 임시 저장하여, 대역폭 낭비및 응답 지연을 방지하는 기술
- 원본 데이터와 캐시된 사본 데이터간의 일관성이 깨질 가능성 → 캐시에 유효기간을 부여하는 이유
- 캐시 신선도 : 캐시도니 사본 데이터와 서버의 원본데이터의 유사한 정도
- 만약, 서버의 원본 데이터가 변하지 않았을 경우, 캐시 유효기간이 만료되도, 새로 받을 필요는 없음!! → 이를 확인하기 위해, 유효기간이 만료될 경우, 원본 자원이 변경된 적이 있는지를 질의 함!! (날짜 기반일수도, 엔티티 태그 기반일수도 있음!)
- 1. 서버의 요청받은 자원이 변경 된 경우
- 상태 코드 200과 함께 새로운 자원 반환
- 2. 서버가 요청받은 자원이 변경되지 않은 경우
- 상태코드 304(Not Modified)를 통해, 자원이 변경되지 않았음을 알림
- 304 코드는 '캐시된 자원을 참조하자' 라는 뜻
- 3. 서버가 요청받은 자원이 삭제된 경우
- 상태코드 404 (Not Found)를 통해 자원이 존재하지 않음을 알림
- 1. 서버의 요청받은 자원이 변경 된 경우
보안 : SSL/TLS와 HTTPS
- HTTPS : HTTP에 SSL or TLS라는 프로토콜의 동작이 추가된 프로토콜
- SSL(Secure Sockets Layer) , TLS(Transport Layer Security) : 인증과 암호화를 수행하는 프로토콜이며, TLS는 SSL을 계승한 프로토콜
- HTTP에서 TLS 핸드쉐이크가 추가된것 == HTTPS
- TLS 핸드쉐이크의 핵심
- 1. 암호화 통신을 위한 키를 생성/교환 할수 있다.
- 2. 인증서 송수신과 검증이 이루어질수 있다.
'CS > 기타' 카테고리의 다른 글
(CS) 네트워크 - 프록시와 안정적인 트래픽 (0) | 2025.03.30 |
---|---|
(CS) 네트워크 - 전송 계층, TCP & UDP (0) | 2025.03.25 |
(CS) 네트워크 - 네트워크 계층 IP (0) | 2025.03.22 |
(CS) 네트워크 - 물리 계층과 데이터 링크 계층 (0) | 2025.03.19 |
(CS) 네트워크 - 기본구조 (1) | 2025.03.18 |