HTTP와 HTTPS, DNS 프로토콜

김아현·2024년 1월 19일

Computer-Science

목록 보기

4/6

이번 포스트에선 지난 시간에 다뤘던 HTTP 프로토콜을 좀 더 상세히 살펴보고 그 다음으로 HTTP에서 보안이 강화된 HTTPS를 알아보겠습니다. 마지막으로 DNS에 대해 다루겠습니다.

HTTP 프로토콜이란?

HTTP (HyperText Transfer Profocol)는 인터넷상에서 데이터를 전송하기 위한 프로토콜로, TCP/IP 4계층에서 응용 계층에 속한다. 주로 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. 주로 TCP를 사용하고, HTTP/3부터는 UDP를 사용하며 80번 포트를 사용한다.

지난 포스트에서 이야기한 것처럼 웹에서 이뤄지는 모든 데이터 교환의 기초로, 클라이언트 - 서버 프로토콜이라고도 합니다. 이 때 클라이언트-서버 프로토콜은 수신자 측에 의해 requerst가 초기화되는 프로토콜을 의미합니다.

주요 역할은 클라이언트와 서버 간에 웹 페이지(HTML 파일), 이미지, 동영상 등의 리소스를 주고 받는 것입니다. HTTP는 요청-응답 프로토콜로, 클라이언트가 HTTP 요청을 서버에 보내면, 서버는 요청을 처리하고 결과를 HTTP 응답으로 돌려줍니다. 이 프로토콜은 웹에서 데이터를 주고 받는 방식을 정의하고 있습니다.

HTTP의 역할

리소스와 독립적인 인터페이스(uri, url)를 제공함으로써 서비스의 직접적인 구현 방식을 클라이언트로부터 숨깁니다. 이를 바탕으로 상호작용의 복잡성을 줄이고 서버와 클라이언트의 독립성을 높입니다.
중간 계층 프로토콜로서 proxy나 gateway가 non-HTTP 정보 시스템을 보다 보편적인 인터페이스로 변환할 수 있게 해줍니다.

HTTP의 요청과 응답이란?

클라이언트와 서버는 데이터 스트림과는 대조적으로, 개별적인 메세지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메세지를 요청(requests)라 부르며, 그에 대해 서버에서 응답으로 전송되는 메세지를 응답(responses)이라고 부릅니다.

HTTP request와 response의 구조는 서로 닮아있습니다.
아래 이미지와 같이 총 4 파트로 나누어볼 수 있습니다.

HTTP request와 response의 구조
1. start line : 실행되어야 할 request 혹은 request 수행에 따른 성공 또는 실패가 기록된다. 항상 1줄로 끝난다.
2. HTTP headers : request 설명 혹은 message 본문에 대한 설명
3. blank line : 메타 정보가 모두 보내졌음을 알리는 빈 줄
4. body : request 관련 내용(HTML 폼 컨텐츠 등)이 옵션으로 들어가거나 response 관련 문서가 들어간다. body의 유무는 1번과 2번에 명시된다.

이 구조에서 HTTP 요청 메세지의 start line과 header를 묶어서 request head라고 부릅니다. 대조적으로 HTTP 메세지의 payload는 body라고 부릅니다.

startline : Method / URL / Protocol Version
Headers : Request headers / Response headers / General headers / Representation headers

HTTP Headers

HTTP 헤더는 앞서 구조에서 설명했던 내용처럼 HTTP message 본문에 대한 부가적인 설명을 전송할 수 있게 해줍니다.
그 종류는 Request headers / General headers / Representation headers / Entity headers 이렇게 4가지로 나뉩니다.

General Headers : HTTP header에서 request/response message 모두에 사용될 수 있습니다. 다만, 컨텐츠에 적용되지 않으며 현재 버전의 HTTP 명세에선 분류하고 있지 않습니다.

Cache-Control : request/response의 directive를 다루는 헤더 필드입니다. 캐시의 max-age나 private directive 등을 다룹니다.

Connection : keep-alive 혹은 close를 받아 현재 전송이 완료된 후 네트워크 접속을 유지할지 말지 제어합니다.

Request headers : HTTP request에서 request 컨텍스트에 관한 정보를 전달하여 서버가 response를 처리할 수 있도록 합니다.

Cookie : reponse로부터 받았던 Set-Cookie 헤더 혹은 Document.cookie로 저장한 HTTP Cookie를 담고있는 필드입니다.

Host : request가 보내질 서버의 port 넘버나 host를 특정합니다. 기본 적으로 HTTP URL에 대해선 80번, HTTPS URL에 대해선 443번이 매칭됩니다.

User-Agent : 서버와 네트워크 피어들이 request를 보낸 user agent(ex.브라우저)나 app과 os, vendor 를 식별할 수 있게 해주는 문자열입니다.

Accept-* : response의 적절한 포맷을 나타냅니다.

Authorization : 서버의 보호된 리소스에 대한 접근을 허용하며 user agent에 신뢰 권한을 부여하는 헤더입니다.

Response headers : HTTP response에서 사용되는 헤더로, 메세지 컨텐츠와 연관은 없습니다.

Age : delta-seconds 타입으로, 객체가 proxy cache 내에 머문 시간을 나타냅니다.

Location : 응답 후 redirect할 새로운 리소스의 URL을 나타냅니다. 3xx나 201 상태 코드에서만 의미가 있습니다.

Server : request를 처리한 origin server의 필드입니다. 보안 취약점으로 자주 걸리게 되므로 response header에서 숨길 수 있습니다.

Set-Cookie : 서버로부터 user agent에게 cookie를 보내기 위해 쓰이는 헤더 필드입니다. user agent는 추후 api 요청 시 cookie를 다시 서버로 보냅니다.

Representation headers : HTTP message body에서 보내진 리소스를 표현하는 헤더입니다. 예를 들어, 몇몇 데이터는 XML이나 JSON과 같은 특정한 타입으로 포맷되거나 지역별 언어로 변경됩니다. 또한 전송을 위해 압축되거나 인코딩될 수도 있습니다. 또한 Representation headers는 Entity headers를 포함합니다.

Content-Type : resource의 media type을 나타냅니다. response 내에서는 클라이언트에 반환될 컨텐츠 유형이 무엇인지 나타냅니다. request 내에서는, 서버에게 전송 데이터의 타입을 나타냅니다.

Content-Language : 응답자에 따라 표현할 언어를 나타내는 헤더입니다.

Content-Encoding : media type을 압축하기 위해 사용하는 헤더입니다. 개체의 원본 포맷의 형태를 알려주어 디코딩과 인코딩이 가능하게 합니다.

HTTP 요청의 리소스란?

HTTP의 요청의 대상을 리소스라고 부릅니다. 이 리소스는 문서나 사진 등 다양한 형식을 지원합니다. 각 리소스는 식별을 위해서 URI(Uniform Resource Identifier)라는 식별자로 식별할 수 있습니다.

URI를 더 자세히 설명하도록 하겠습니다. 가장 일반적인 URI는 웹주소로 알려진 URL(Uniform Resource Locator)입니다. 예시로는 “https://velog.io/@naro-kim/posts” 등이 있습니다.
이러한 URL을 사용자가 브라우저 주소에 입력하면 해당 URL과 연결되는 페이지 리소스를 로드할 수 있습니다.

HTTP 메서드의 종류

GET과 POST의 차이점

GET은 클라이언트가 서버에 리소스를 요청하는 메소드입니다. query string 혹은 path variable을 통해 데이터를 전송하며 주로 리소스 조회에 사용합니다. 데이터가 url에 노출되어 보안에 취약해집니다.

POST는 리소스를 생성하는 메소드입니다. 데이터를 HTTP message body에 담아 리소스 등록에 사용합니다. POST는 request Header Content-type에 resource data type을 명시해야 합니다.

이 두 메소드에선 Query string과 Path variable 그리고 HTTP message body의 개념이 등장합니다. 두 개념은 아래와 같이 설명할 수 있습니다.

Query String : url 뒤에 ? 로 전달하는 파라미터를 의미합니다. 특정 값으로 데이터를 조건부 조회하는 데 쓰입니다.
Path variable : url 뒤에 number 타입 인덱스로 리소스를 조회하는 파라미터입니다. 데이터가 url에 노출되지 않습니다. 특정 인덱스의 데이터를 조회하는 데 쓰입니다.
HTTP message body : request로 전송하는 리소스를 담고있는 부분으로 GET일 경우 Body가 존재하지 않고 POST일 경우 body가 존재합니다.

또한 GET과 POST는 요청에 Body 유무와 멱등성이라는 특성에서 차이를 보입니다.

PUT과 PATCH의 차이

HTTP 상태코드란?

HTTP의 상태코드는 request가 성공적으로 완료되었는지를 알려줍니다. console의 network탭에서 request를 클릭해 확인할 수 있으며 총 5가지의 그룹으로 나뉩니다.

정보 응답

성공 응답

리다이렉션 메세지

클라이언트 에러

서버 에러

또한 필요한 경우 서버에서 커스텀 에러메세지를 보낼수도 있습니다.

1xx : 정보 응답

101번대의 에러 코드는 정보 응답 코드에 대한 코드입니다.

100 Continue : reqeust가 이미 요청 되었거나 중첩되는 경우 무시함을 나타내는 코드
101 Switching Protocol : request 헤더에 대한 응답을 처리하며 protocol이 변경됨을 알려주는 코드
102 Processing : 서버 요청 수신 후 처리중
103 Early Hints : 서버 응답 준비 동안 preloading을 지원합니다. 단, 현재는 Firefox와 Safari에서 지원하지 않습니다.

2xx : 성공 응답

200 OK : 200번 코드는 request가 성공했다는 의미입니다. 각 메소드에 따라 성공의 의미가 달라집니다.
GET의 경우 '리소스를 불러와 메세지 바디로 전송되었습니다', HEAD의 경우 '헤더가 메세지 바디에 있습니다', PUT 또는 POST의 경우 '수행 결과에 대한 리소스가 메세지 바디로 전송되었습니다' 등을 의미합니다.
201 Created : 요청이 성공하여 리소스를 생성했다는 의미.
202 Accepted
203 Non-Authoritative Information
204 No Content : request는 성공했으나 응답할 콘텐츠가 없을 수 있습니다.

3xx : 리다이렉션 메세지

300번대의 상태 코드는 URI 변경에 대한 메세지를 나타냅니다. 클라이언트가 request를 마치기 위해서는 추가적인동작을 취해야 합니다.

웹 브라우저의 경우, response로 3xx의 상태 코드가 오고 Location header가 존재하면 그 위치로 자동 이동하게 됩니다.

3xx 상태코드 예시

4xx : 클라이언트 에러

클라이언트의 오류에 의해 발생하는 상태 코드입니다.

400 Bad Request : 잘못된 문법으로 인하여 서버가 클라이언트 요청을 이해할 수 없음
401 Unauthorized : 인증되지 않은 사용자의 요청
403 Forbidden : 클라이언트 사용자 식별은 가능하지만, 접근 권한이 없는 사용자임을 나타내는 코드
404 Not Found: requested resource를 서버에서 찾을 수 없다는 의미로 URL이 존재하지 않거나 리소스가 존재하지 않는 경우

5xx : 서버 에러

서버 오류에 의해 발생하는 상태 코드입니다.

500 Internal Server Error : 서버가 처리 방법을 알 수 없는 경우
501 Not Implemented : 서버가 request method를 이해하지 못하거나 리소스를 지원하지 않는 경우
502 Bad Gateway : 서버가 request에 필요한 response를 위해 게이트웨이에서 작업하는 동안 잘못된 경우
503 Service Unavailable : 서버가 request를 받을 준비가 되지 않은 경우로, 작동이 중단되거나 과부화된 경우.
504 Gateway Timeout : 서버가 게이트웨이 역할을 하고 있지만 response를 받을 수 없을 때 주어집니다.

HTTP의 특징

무상태성

무상태(stateless)
HTTP에서의 무상태(Stateless)란 서버에서 클라이언트의 상태를 저장하지 않는 것을 의미합니다. 따라서 클라이언트는 요청에 필요한 데이터를 모두 가지고 있어야 합니다. 또는 서버가 클라이언트로 받은 요청 사항을 모두 저장해야 합니다. 이 방법들을 쿠키(Cookie)와 세션(Session)이라고 부릅니다.

무상태의 장점은 서버 확장성이 높다는 점입니다. 클라이언트 상태를 저장하지 않기에, 요청에 응답하는 서버가 바뀌어도 됩니다. 따라서 특정 서버에 문제가 생겨 응답하지 않더라도 신규 서버 확장으로 요청에 따른 응답을 보내 문제를 해결할 수 있습니다.

비연결성

비연결성(connectionless)
HTTP의 비연결성(Connectionless)은 클라이언트에서 요청을 보낸 후 서버로부터 응답을 받으면 연결을 끊는 것을 의미합니다. 비연결성은 불특정 다수를 대상으로 하는 서비스에 유리합니다. 서버에서 응답을 받고 서도 연결을 유지하려면 그만큼 자원을 사용하게 됩니다. 따라서 연결을 필요시에만 유지하면 자원을 효율적으로 사용할 수 있습니다.

하지만, 이런 특징 때문에 서버가 클라이언트를 기억할 수 없다는 단점이 있습니다. 또한, 동일한 클라이언트에서 연속적으로 요청이 오면 연결과 해제 과정이 반복되어 자원이 낭비됩니다.

이러한 단점을 보완하기 위해 HTTP 헤더의 일종인 HTTP Keep Alive를 사용하여 마지막 응답 이후 일정 시간 동안 연결을 유지합니다. 이를 통해 동일한 클라이언트로부터 온 요청이 오면 연결을 생략할 수 있습니다.

쿠키와 세션?

쿠키 (Cookie) : 클라이언트 로컬 웹 브라우저에 저장하는 데이터파일로, 키와 값을 저장한다. 대표적인 예로는 로그인 정보와 장바구니가 있으며 약 4kb이다.

세션 (Session) : 서버에서 클라이언트와 연결 정보를 저장 및 관리하는 것을 말한다. 서버에 데이터가 저장되므로 보안 면에서는 쿠키보다 좋지만, 접속자가 많을 경우 서버에 과부하가 올 수 있다. 용량에 제한이 없다.

HTTP 커넥션

HTTP는 OSI 응용 계층에서 클라이언트와 서버 사이 커넥션을 위해 TCP 프로토콜을 전송 프로토콜로 주로 이용합니다. 초기 HTTP는 request가 보내져야 할 때마다 매번 새롭게 커넥션을 생성하고, response가 도착한 이후 커넥션을 끊는 형태였습니다.

이렇게 각각의 TCP 연결을 계속해서 반복적으로 열고 닫는 것은 성능 상의 제약을 일으킵니다. 때문에 클라이언트와 서버 사이 커넥션 관리는 HTTP의 중요한 주제입니다. 대규모로 커넥션을 열고 유지하는 것은 웹 애플리케이션 성능에 많은 영향을 주기 때문입니다. 이를 위해서, HTTP/1.x 버전에선 몇 가지 방법이 도입되었습니다. 그 중 Keep-Alive와 파이프라이닝에 대해 알아보겠습니다.

HTTP/1.1

HTTP의 첫 번째 공식 표준 버전인 HTTP/1.1은 GET, POST, PUT, DELETE method를 지원합니다. 또한, TCP keep-alive로 커넥션 재사용을 지원해 이전보다 많은 컨텐츠를 전달할 수 있습니다. 또 다른 특징으로, 파이프라이닝 기술을 지원합니다. 아래에서 더 자세히 알아보도록 하겠습니다.

HTTP Keep-Alive

Keep-Alive는 General header로, 송신자가 연결에 대한 타임아웃과 요청 최대 개수를 어떻게 정의했는지 알려줍니다. 즉 파라미터로 timeout과 max를 갖습니다.

timeout : 커넥션이 열려 있어야 하는 최소한의 시간(초 단위). keep-alive TCP 메세지가 전송 계층에 설정되지 않는 다면 TCP timeout 값 이상은 무시된다.

max : 커넥션이 닫히기 전 전송될 수 있는 최대 요청 수.

Keep-Alive 헤더를 포함하는 request 예제는 아래와 같습니다.

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)

HTTP 파이프라이닝

파이프라이닝이란 같은 영속적인 커넥션을 통해 response를 기다리지 않고 request을 연속적으로 보내는 기능입니다. 기본적으로 HTTP request는 왼쪽과 같이 순차적으로 작동합니다. 하지만 오른쪽 그림처럼 파이프라이닝을 통해 네트워크 지연을 회피할 수 있습니다.

다만, 모던 브라우저에서 HTTP 파이프라이닝이 기본 활성화되어 있진 않고 그 구현이 매우 어렵다고 합니다.
또 다른 문제점으로는 버그가 있는 Proxy가 많아 개발자들이 분석하기 힘든 오류 동작을 야기합니다.
마지막으로 HTTP/1.1의 가장 큰 문제점으로 Head of Line Blocking이 지적되어 HTTP2가 개발되었습니다.

HTTP/2

2015년에 개발된 새로운 버전의 HTTP로, HTTP/1.1보다 훨씬 바르고 효율적입니다. HTTP의 전송 시간을 개선하기 위해 등장했으며 이를 위한 방법은 멀티 플렉싱(다중화)과 로드 프로세스의 컨텐츠 우선순위 지정이 있습니다.

Multiplexing

HTTP/2는 하나의 TCP 커넥션에서 여러 요청을 병렬적으로 보낼 수 있습니다.

Stream Prioritization

resource 간 전송 우선순위를 지정합니다.

HTTP/3

HTTP/3는 UDP를 경유합니다. HOL 문제 해결을 목적으로 하여 구글이 개발한 전송 계층 프로토콜 중 하나인 QUIC을 사용합니다.

HTTPS 란?

HTTPS(HyperText Transfer Protocol Secure)는 보안 계층인 SSL/TLS를 이용해 HTTP의 보안을 강화한 웹 통신 프로토콜입니다. HTTP는 데이터 암호화를 거치지 않고 전송하기 때문에 보안에 취약합니다. 때문에 HTTPS가 등장하게 되었습니다.

SSL/TLS (Secure Socket Layer/Transport Layer Security)

SSL은 넷스케이프에서 개발한 암호화 프로토콜입니다. 이 당시 SSL이 가진 취약점을 보완해 새로 개발한 암호화 프로토콜이 바로 TLS(Transport Layer Security)입니다.

현재 HTTPS에서 통용되는 암호화 프로토콜은 TLS이지만 SSL과 함께 SSL/TLS라고 부르고 있습니다.

HTTPS 프로토콜을 사용하기 위해선 SSL/TLS 인증서를 발급받아야 합니다. 인증서가 중요한 이유는 아래와 같습니다.

브라우저 웹사이트 주소에 https 접두사가 포함됨

개인 데이터 보호 : 브라우저와 웹사이트 간 모든 통신의 암호화

고객 신뢰 강화 : 신뢰되는 웹사이트라는 표시로 사용자에게 안전을 보장

SEO 개선 : 검색 엔진 최적화 순위의 요소로 더 높은 검색 순위를 차지하게 됨

DNS (Domain Name System)

DNS이란 Domain Name System으로, 인터넷에 연결된 리소스에 대한 계층적이고 분산된 명명 시스템을 일컫습니다. DNS는 도메인 네임 리스트와 연결된 IP 주소 등의 리소스를 유지, 관리합니다.

인터넷 상에서는 Host를 식별하기 위해 IP 주소를 사용하지만 Number 형식으로 되어 있어 의미를 파악하기 힘듭니다. 이를 해결하기 위해 DNS는 IP주소에 사람이 이해할 수 있는 도메임 이름을 매핑하여 통신을 쉽게 합니다.

DNS의 작동 방식

DNS의 주요 기능은 도메인 네임을 숫자로 이루어진 IP주소(ex/ 123.0.0.123)로 변환하는 것입니다. 이를 DNS조회라 하며 사용자 요청에 따른 동작은 순서대로 아래와 같이 작동합니다.

사용자가 URL을 웹 브라우저 주소창에 입력한다.

브라우저가 URL의 유효성을 판단한다.

유효한 URL이라면 웹 브라우저는 DNS 서버에 연결할 IP 주소를 요청한다. 아니라면 Input을 검색한다.

DNS 서버로부터 매핑된 IP 주소를 받으면 3-way handshake로 TCP 통신을 위한 가상 회선을 연결한다.

HTTP connection request를 서버에 보내면 response로 리소스를 받고 브라우저가 화면을 출력한다.

이를 DNS 단위로 쪼개어 살펴보면 아래와 같이 이해할 수 있습니다.

사용자가 웹 브라우저를 열어 주소 표시줄에 www.example.com을 입력하고 Enter 키를 누릅니다.

www.example.com에 대한 요청은 일반적으로 케이블 인터넷 공급업체, DSL 광대역 공급업체 또는 기업 네트워크 같은 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅됩니다.

ISP의 DNS 해석기는 www.example.com에 대한 요청을 DNS 루트 이름 서버에 전달합니다.

ISP의 DNS 해석기는 www.example.com에 대한 요청을 이번에는 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달합니다. .com 도메인의 이름 서버는 example.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답합니다

ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.example.com에 대한 요청을 해당 이름 서버에 전달합니다.

Amazon Route 53 이름 서버는 example.com 호스팅 영역에서 www.example.com 레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환합니다.

ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 됩니다. 해석기는 이 값을 웹 브라우저로 반환합니다. 또한, DNS 해석기는 다음에 누군가가 example.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 example.com의 IP 주소를 캐싱(저장)합니다.

웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.example.com에 대한 요청을 전송합니다. 여기가 콘텐츠가 있는 곳으로, 예를 들어 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버입니다.

192.0.2.44에 있는 웹 서버 또는 그 밖의 리소스는 www.example.com의 웹 페이지를 웹 브라우저로 반환하고, 웹 브라우저는 이 페이지를 표시합니다.

출처

DNS 질의 종류

DNS 질이에는 재귀적 질의와 반복적 질의가 존재합니다.

재귀적 질의 : 도메인 네임에 해당하는 IP주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP주소를 물어보는 것을 뜻합니다.
반복적 질의 : IP주소를 찾기 위해 반복적으로 질의하는 것입니다.
루컬 DNS가 루트 DNS에게 IP주소를 물어보고 찾아내지 못했다면, TLD DNS에게 물어보고 없다면 authoriativeDNS와 같이 반복적으로 상위 DNS에게 질문하는 구조를 말합니다.

DNS에서 UDP를 사용하는 이유

HTTP는 TCP를 기반으로 만들어져 있습니다. 이와 달리 DNS는 UDP와 TCP 모두를 사용합니다. 그럼 먼저, UDP를 사용하는 이유는 무엇일까요? DNS는 신뢰성보다 속도가 중요한 서비스입니다. 때문에, 연결 설정에 드는 시간 비용이 없는 UDP를 사용합니다.
DNS는 연결 상태를 유지할 필요가 없고, TCP보다 많은 클라이언트를 수용할 수 있는 UDP를 사용합니다.

DNS 레코드란?

DNS 레코드는 DNS resource와 Domain name 사이의 매핑입니다. 각 개별 DNS 레코드에는 유형(이름 및 번호), 만료 시간(수명), 유형별 데이터가 있습니다. 예시는 DNS 레코드에서 자세히 확인할 수 있습니다.

김아현

멘티를 넘어 멘토가 되는 그날까지 파이팅

이전 포스트

컴퓨터 네트워크의 물리적 네트워크란?

다음 포스트