HTTP & HTTPS

bearMin·2024년 7월 8일

들어가면서

HTTPS는 인터넷으로 네이버만 들어가도 자주 볼 수 있는 단어(?)이다. 이게 어떤 의미를 가지고 있길래 모든 사이트는 저 단어로 시작을 하는걸까?

HTTP는?

http? 어라? https가 아니라 http는 뭘까? https를 설명하기 위해서는 http에 대해서 먼저 알아야한다. 왜인지는 아래서 차근차근 설명해보도록 하겠다.

정의는?

하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol)의 약자로, 서버와 클라이언트가 인터넷 상에서 데이터를 주고 받기 위한 프로토콜을 뜻한다.

💡 프로토콜이란?
컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계

사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고 웹 서버는 HTTP 응답을 받는다. 네트워크 통신을 작동하게 하는 기본 기술이며 가장 성공적인 인터넷 프로토콜이다!

특징은?

자 그렇다면 어떤 특징을 가지고 있을까?

애플리케이션 레벨의 프로토콜로 TCP/IP를 이용한다.

💡 TCP/IP란?
IP 주소를 사용하여 목적지에 데이터를 보내는데(IP) 
이때, 데이터를 안정적으로 전송하는 것을 담당하는 프토토콜(TCP)

어떤 종류의 데이터든 전송할 수 있도록 설계되어 있다. : 흔히 볼 수 있는 HTML부터 이미지나 동영상 등 종류를 가리지 않고 데이터를 전송할 수 있다.

HTTP를 통해 전달되는 자료는 (http://)로 시작하는 URL(인터넷 주소)로 조회할 수 있다.

💡 URL이란?
인터넷에서 웹 페이지, 이미지 등의 리소스의 위치를 가리키는 문자열

연결 상태를 유지하지 않는 비연결성(Connectionless) 프로토콜이며, 상태정보를 유지하지 않는 Stateless 프로토콜이다. : 서버가 응답 후 클라이언트와의 연결을 끊기 때문에 요청이 들어오는 클라이언트의 이전 상황을 알 수 없다. 따라서 상태정보를 유지하기 위해 쿠키, 세션, 토큰이라는 기술들이 등장했다!
연결을 유지하지 않기 때문에 요청과 응답의 방식으로 동작한다.

동작방식은?

특징에서도 말했지만 HTTP는 비연결성 프로토콜이며 요청과 응답의 방식으로 동작한다.

HTTP는 서버/클라이언트 모델을 따르는데 서버/클라이언트 모델이란 클라이언트가 서버에 요청을 하면 서버가 클라이언트의 요청을 처리해서 응답하게 된다.

여기서 클라이언트는 웹/앱을 사용하는 사용자를 뜻한다. 클라이언트는 웹 브라우저를 사용해서 서버에 원하는 데이터를 요청하게 되고, 서버는 자료에 접근하는 시스템으로 요청에 대한 응답을 보내준다.

HTTP 요청(Request)은?

그렇다면 요청 메시지는 어떻게 보내는지 그 구조에 대해서 조금 더 자세하게 살펴보자!

위의 사진을 살펴보면 알 수 있듯이 총 3가지의 부분으로 나뉘어진다.

하나하나 살펴보면

start line에는 HTTP Method, Request target, HTTP version이 존재한다.

	  GET          /test.html       HTTP/1.1
[HTTP Method] [Request target] [HTTP version]

HTTP Method : GET, POST, PUT, PATCH, DELETE 등이 있다. GET은 존재하는 자원에 대한 요청, POST는 새로운 자원을 생성, PUT과 PATCH는 존재하는 자원에 대한 변경, DELETE는 존재하는 자원에 대한 삭제와 같은 기능을 가지고 있다.
Request target : HTTP Request가 전송되는 목표 주소이다.
HTTP version : version에 따라 Request 메시지의 구조나 데이터가 다를 수 있기에 version을 명시한다.

headers에는 주로 해당 request에 대한 추가적인 정보를 담고 있다.

Host: google.com
Accept: text/html
Accept-Encoding: gzip, deflate
Connection: keep-alive
...

Host : 요청하려는 서버 호스트의 이름과 포트번호를 명시한다.
Accept : 클라이언트가 처리 가능한 미디어 타입의 종류를 나열한다.
Accept-Encoding : 클라이언트가 이해할 수 있는 압축 방식을 표시하며 이를 표기하여 전송하면 서버는 해당 압축 방식으로 리소스를 압축하여 반환해준다.

등이 있다.

body에는 HTTP Request가 전송하는 데이터를 담고 있는 부분으로 만일 전송하는 데이터가 없다면 body 부분은 비어있다.

{
		"이름": "개발하는 오리"
}

다양한 방식으로 데이터의 전송이 가능하다. ~~난 주로 json으로 사용하는 편ㅎㅎ~~

HTTP 응답(Response)은?

요청 메시지를 어떻게 보내는지 알아봤다. 그렇다면 응답 메시지는 어떻게 보낼까? 그 구조를 살펴보자!

Request와 동일하게 3가지 부분으로 나뉘어진다.

status line은 Response의 상태를 간략하게 나타내주는 부분이다.

   HTTP/1.1          200              OK
[HTTP version]  [Status Code]   [Status Text]

HTTP version : version에 따라 Request 메시지의 구조나 데이터가 다를 수 있기에 version을 명시한다.
Status Code & Text : Response의 code와 text는 우리가 가장 잘 알고 있는 404 Not Found 등이 있다. 이 외에도 400 Bad Request, 200 OK 와 같이 어떤 요청에 대한 응답이 성공적인지 문제가 있었는지 등과 같은 것을 알려주는 정보이다.

headers는 Request의 headers와 동일하다. 다만 Response에서만 사용되는 header의 값들이 있는데 가장 대표적인 예로 User-Agent 대신에 Server 헤더가 사용된다는 것이다.

body 역시 Request의 body와 동일하다. 데이터를 전송할 필요가 없을 경우에는 body가 비어있게 되며 데이터를 전송해야할 경우 body에 데이터를 넣어준다. ~~역시나 나는 json을 주로 사용한다ㅎㅎ~~

HTTP의 역사는?

다른 것들은 어느정도 이해가 됐을텐데 갑자기 중간에 나오는 version이라는 것이 눈에 띄었을 것이다. 1.1 이라는 예시가 있었는데 과연 얼마나 많은 버전이 있고 주로 뭐가 사용이 되는지 한번 알아보자!

HTTP/0.9 (1991년)

HTTP 초기 버전을 구분하기 위해 부르는 버전
요청은 단일 라인으로 구성이 되며, 리소스에 대한 Method는 GET만 존재
파일 내용 자체로만 구성하여 응답도 극도로 단순
HTTP 헤더도 없고, HTML 파일만 전송이 가능

가장 초기에 등장하였으며 정말 통신에 필요한 최소한의 기능만 제공하였다.

HTTP/1.0 (1996년)

header의 개념이 도입이 되어 요청과 응답에 추가가 됨
버전 정보와 요청 Method가 함께 전송
상태 코드 라인도 응답의 시작부분에 추가되어 브라우저 요청의 성공과 실패 파악 가능
Content-Type 도입으로 HTML 이외의 문서 전송이 가능

이때부터 우리가 흔히 알고 있는 HTTP의 모습이 보이기 시작했으며 현재 HTTP 프로토콜의 가장 기초가 되는 부분이다. 다만 이는 분산되어있던 기능을 하나로 정리한 것이지 공식적으로 표준이었던 것은 아니다!

HTTP/1.1 (1997년)

Persist Connection 추가
- 지정한 timeout 동안 Connection을 닫지 않음
Pipelining 추가
- 앞의 요청에 대한 응답을 기다리지 않고 순차적으로 여러 요청을 연속적으로 보낸 뒤 그 순서에 맞춰 응답을 받는 방식
- 하나의 Connection에 여러 개의 요청이 들어왔을 뿐, 동시에 여러 개의 요청을 처리해서 응답으로 보내주는 것이 아님

가장 많이 사용되는 표준이며, 이전까지 TCP에서 3-way handshake로 연결을 하기 때문에 느려지던 속도를 높일 수 있었다.

💡 3-way handshake란?
데이터를 전송하기 전에 정확한 전송을 보장하기 위해 상대방의 컴퓨터와 사전에 
연결을 하는 과정으로 [연결 가능한가요? → 네~ 지금 연결해주세요~ → 넵!] 과 
같은 과정을 통해 연결을 진행한다.

HTTP/1.0이 느렸던 이유는 한번의 데이터를 보낼 때에도 무조건 위와 같은 연결과정이 필요했기 때문이다. 때문에 한번 연결을 했을 때 끊지 않고 유지하는 persist connections 와 한번에 여러 개의 요청을 보낼 수 있는 pipelining을 통해 통신속도를 높일 수 있다.

SPDY (2009년)

Google에서 개발한 시험용 프로토콜
웹 페이지의 로드 지연시간을 단축시키기 위해 만들어짐
HTTP Working Group은 이를 바탕으로 HTTP/2.0을 제작하게 됨

성능 향상에 힘입어 SPDY를 사용하는 사이트가 늘어나게 되었으며 사실상의 표준이라고 불린다. 좋은 성능의 향상을 보였으며 HTTP/2.0의 토대가 되었기 때문에 HTTP가 아님에도 불구하고 같이 적어보았다.

HTTP/2.0 (2015년)

SPDY를 기반으로 HTTP/1.1에서 성능과 속도를 개선
이전 요청에 대한 응답을 대기하지 않아도 뒤의 응답을 먼저 받을 수 있음
한 번의 요청으로 여러 개의 응답을 받을 수 있음

HTTP/2.0의 가장 핵심이 되는 부분은 바로 binary framing이다. 기존 text 방식으로 HTTP 메세지를 보낼 경우 본문은 압축이 되지만 헤더는 압축이 되지 않으며 헤더 중복값이 있다는 문제가 있었다. 하지만 이를 binary frame으로 인코딩하여 전송을 한다면 데이터 파싱 및 전송 속도도 증가할 뿐만 아니라 오류 발생 가능성 역시 줄어들게 된다.

HTTP/3.0 (2019)

QUIC를 사용한 차세대 프로토콜

HTTP/3.0에서 가장 알아야 할 부분이 바로 저것이다. HTTP/2.0의 문제점으로는 TCP를 사용하기 때문에 Handshake로 인한 지연시간이 발생하며, 데이터의 유실이나 오류가 있을 시 재전송을 하는데(데이터 전송의 정확성을 위한 프로토콜이기 때문에) 이 과정에서 뒤에 있던 요청들이 대기하게 되는 HOL Blacking 문제가 발생이 된다.

따라서 HTTP/3.0에서는 기존에 사용하던 TCP를 사용하지 않고 UDP를 더 정확하게 말하자면 UDP를 개조한 QUIC 프로토콜을 사용하여 이를 해결하였다.

💡 UDP란?
비연결형 서비스로 연결하고 해제하는 과정이 없다. 즉 수신측에서 제대로 받았는지는
신경쓰지 않고 데이터를 보내기만 하며 데이터에 대한 보증도 없고 순서의 보장도 없다. 
TCP에 비해 단순하고 빠르기 때문에 신뢰성보다는 연속성이 중요할 때 주로 사용이 된다.

HTTPS란?

이렇게 HTTP에 대해서 열심히 알아봤다. 근데 지금은 웹사이트를 찾아봤을 때 http:// 로 시작하는 웹사이트는 거의 없을 것이다. https://로 거의 시작을 하는데 이게 뭐길래 http를 사용하지 않는 것일까?

정의는?

HyperText Transfer Protocol에 Secure을 더한 것으로 HTTP는 정보를 text로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다. 이를 방지하기 위해 보안을 추가한 것을 HTTPS라고 한다.

이때 보안은 SSL/TLS를 사용하여 데이터를 암호화를 진행한다!

💡 SSL/TLS란?
SSL과 TLS는 데이터를 암호화하는 통신 프로토콜이다. 
TLS는 SSL이 발전하며 이름이 변경이 된 것인데, 아직도 SSL이란 명칭이 많이
사용되고 있다. 다만 SSL은 2015년 공식적으로 사용이 종료되었으며 모든 버전의 
SSL이 더이상 사용이 되지 않는다.

HTTP와의 차이는?

기본적인 골격이나 사용 목적은 거의 동일하지만 데이터를 주고 받는 과정에서 보안이 추가됐는지 여부가 가장 큰 차이점이다. HTTPS는 서버와 클라이언트 사이의 모든 통신 내용이 암호화가 된다.

또한 URL과 포트번호에서도 차이가 조금씩 존재하는데

HTTPS는 (https://)로 URL이 시작하며 기본 포트번호는 443이다.

그러나 HTTP는 (http://)로 URL이 시작하며 기본 포트번호는 80이다.

속도 면에서도 차이가 존재하는데

HTTPS는 암호화가 되고 암호화된 것을 해제하는 복호화의 과정이 필요하기 때문에 속도가 느리다.

반면 HTTP는 위와 같은 과정이 없기 때문에 속도가 빠르다.

~~이는 실제 많은 양의 데이터를 처리할 경우 체감이 난다고 하는데 아직 나는 그정도의 데이터를 처리해본 적이 없어서 잘 모르겠다..~~

위와 같은 차이점들 때문에 민감한 정보들을 다루는 페이지는 HTTPS로, 그 외의 페이지들은 HTTP로 전송하는 방식을 주로 사용한다!

암호화 방식은?

HTTPS의 보안 방식에는 대칭키 암호화 방식과 비대칭키 암호화 방식이 혼합이 되어서 사용이 된다!

대칭키 암호화 방식이란?

쓰여진 그대로의 의미를 먼저 해석해보자면 대칭이 되는 키로 암호화와 복호화를 진행하는 방식이다.

클라이언트와 서버가 동일한 키를 가지고 암호화와 복호화를 진행한다는 뜻으로 동일한 키를 사용하기 때문에 연산의 속도가 빠르다는 장점이 있다. 다만 키를 전송할 때 누군가 가로챈다면 문제가 생길 수 있다는 단점 역시 존재한다.

가장 대표적인 예로는 AES, DES 등이 있다.

비대칭키 암호화 방식이란?

1개의 쌍으로 구성된 공개키와 개인키를 가지고 암호화와 복호화를 진행한다. 공개키는 타인에게 제공을 하는 키이고 개인키는 자신만 가지고 있으며 공개가 되지 않는 키이다.

공개키로 암호화된 데이터는 개인키만을 사용하여 복호화를 할 수 있고, 개인키로 암호화를 한 데이터는 공개키만 복호화를 할 수 있다.

클라이언트는 공개키로 데이터를 암호화해서 전송을 하는데 이때 대칭키 암호화 방식처럼 누군가 키를 가로채도 개인키로만 복호화를 진행할 수 있기 때문에 문제가 되지 않는다.

가장 대표적인 예로는 RSA, DSA 등이 있다.

동작방식은?

보기만 해도 복잡한 위의 사진은 클라이언트와 서버간의 암호화된 데이터 전달의 동작 방식이다.

하나씩 차근차근 설명을 해보겠다..!

클라이언트에서 서버로 랜덤한 데이터를 생성하여 요청을 보낸다.
데이터를 받은 서버는 응답으로 랜덤 데이터 + 해당 서버의 인증서를 보낸다.

⇒ 이때 이 1번과 2번의 과정을 handshake 과정이라고 한다.
클라이언트는 CA 목록을 통해 신뢰할 수 있는 인증서인지 확인을 한다. 이때 비대칭키 암호화 방식을 사용하며 CA 공개키로 인증서가 복호화가 가능하다면 신뢰할 수 있는 사이트라는 것을 의미한다. 이때 복호화된 인증서에는 서버의 공개키가 포함이 되어있다.

💡 CA란?
SSL 보안 인증서를 발급하는 기관을 의미하며 브라우저에는 CA의 목록이 내장되어있다.

클라이언트는 1, 2번의 과정(handshake) 과정에서 사용한 랜덤 데이터들을 혼합하여 대칭키를 만들고 위의 3번 과정에서 얻은 공개키를 이용하여 클라이언트가 만든 대칭키를 암호화하여 서버로 전송한다.
서버는 본인의 개인키를 가지고 클라이언트로부터 받은 암호화된 대칭키를 복호화한다.

이러한 과정을 통해 서버와 클라이언트는 동일한 대칭키를 만들어 안전한 데이터 전송을 할 수 있다.

조금 더 간단하게 설명을 해보자면 대칭키를 만들기 위해서 비대칭키 암호화 방식을 사용하여 인증을 하고 대칭키를 공유한다. 이렇게 공유된 대칭키 암호화 방식을 사용하여 데이터를 주고 받는다.

이렇게 말로 설명하기도 복잡한 과정을 진행하는 이유는 무엇일까?

이것은 위에서도 얘기했던 속도의 문제이기 때문이다. 비대칭키 암호화 방식은 속도가 느리며 컴퓨터에게 많은 부담이 간다. 때문에 보안을 유지해야하는 부분에서는 비대칭키 암호화 방식을 사용하고, 안전하게 연결이 되었으며 클라이언트와 서버만 알고 있는 대칭키가 만들어졌을 경우 대칭키 암호화 방식을 사용하여 조금 더 빠르게 데이터를 주고 받을 수 있도록 하는 것이다!

사용해야하나?

지금까지 계속 얘기했지만 HTTP는 보안에 취약하다. 이때문에 보안의 취약점을 해결하기 위해서 사용이 되어야한다.

또한 현재 HTTPS를 사용한다면 검색 엔진에 가산점을 받게 된다. (2014년 구글에서 발표했다..) HTTP를 HTTPS로만 구성을 해도 검색 엔진에 가산점을 주기 때문에 검색엔진 최적화(SEO)를 위해서 사용이 되어야한다.

그리고 SSL이 의무화가 되면서 SSL/TLS 인증서가 설치되지 않은 웹사이트에는 패널티가 부여됐다. 가끔 웹사이트 중에서 안전하지 않은 웹사이트라며 경고를 띄우는 것을 본 적 있을 것이다. (주로 주의 요함 혹은 안전하지 않음 과 같은 문구가 뜬다) 이처럼 경고를 띄우기 때문에 사용자들은 겁을 먹고 사이트에 접속을 피하게 된다.

이 외에도 여러가지 이유들이 있지만 결국 HTTPS를 사용하는 것은 HTTP보다 훨씬 더 많은 이점이 있기 때문에 굳이 사용하지 않을 필요는 없을 것 같다!

정리하자면?

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 프로토콜이다!

HTTP는 보안에 대한 문제가 있었고 이를 해결하기 위해 Secure(보안)을 추가한 HTTPS가 등장했다!

HTTP는 속도는 빠르지만 보안에 취약하고, HTTPS는 속도는 느리지만 보안에 강점이 있다!

bearMin

소소한 공부기록

이전 포스트

API & REST API

다음 포스트

HTTP & HTTPS

들어가면서

HTTP는?

정의는?

특징은?

동작방식은?

HTTP 요청(Request)은?

HTTP 응답(Response)은?

HTTP의 역사는?

HTTP/0.9 (1991년)

HTTP/1.0 (1996년)

HTTP/1.1 (1997년)

SPDY (2009년)

HTTP/2.0 (2015년)

HTTP/3.0 (2019)

HTTPS란?

정의는?

HTTP와의 차이는?

암호화 방식은?

대칭키 암호화 방식이란?

비대칭키 암호화 방식이란?

동작방식은?

사용해야하나?

정리하자면?

API & REST API

HTTP Method

0개의 댓글