HTTP란? (feat. HTTPS의 차이)

이번 포스팅에서는 웹개발자라면 상식으로 알고 있어야할 HTTP와 HTTPS에 대해 알아보도록 하겠다. HTTP에 관해서도 전부 알기에는 방대한 양이 있어 오늘은 개요와 차이점 정도 그리고 이해를 돕기위한 부가적인 정보 몇가지만 공유해본다. 

 

 

 

 

🌐 HTTP ? 그냥 인터넷 주소창 양식 아니냐고?

  HTTP란 HyperText Transfer Protocol 의 약자로, HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜로, 웹에서 이루어지는 모든 데이터 교환의 기초이며 클라이언트와 서버간의 통신규약이다. 초기에는 HTML과 같은 하이퍼미디어 문서를 주로 전송했지만, 최근에는 Plain text, JSON, XML 등 다양한 형태의 정보도 전송한다. 이렇듯 웹 브라우저와 웹 서버 간의 커뮤니케이션을 위해 디자인되었지만 현재는 모바일 애플리케이션 및 IoT 등과의 커뮤니케이션과 같이 시대에 발전에 맞추어 다른 목적으로도 사용되고 있다. 

 

 HTTP는 무상태 프로토콜로 이는 서버가 두 요청 간에 어떠한 상태나 데이터를 유지하지 않음을 의미한다. (상태를 유지하기 위한 수단으로는 *쿠키와 *세션을 사용한다.) 일반적으로 안정적인 TCP/IP 레이어를 기반으로 사용하는 응용 프로토콜이다. 또한 여러 다른 기술과 함께 사용되는데 그 중 하나가 데이터를 안전하게 주고받기 위해 HTTP에 전송 계층 보안(Transport Layer Security, TLS)을 더해 만든 HTTPS 프로토콜을 사용한다.

*우선은 사용된다는 정도로만 알고, 쿠키와 세션에 대해서는 따로 포스팅하겠다.

 

 

 

  HTTP에서는 텍스트 기반으로 통신하였기 때문에 제3자가 클라이언트-서버 간의 통신 데이터를 바로 볼 수 있었던 문제가 발생하였고, 이를 보완하고자 HTTPS가 탄생하였다. *기존의 텍스트 형식을 바이너리 형태로 변환하여 주고 받기 때문에 제3자가 직관적으로 무슨 통신을 하는 지 알 수 없다. 따라서 현재 대부분의 브라우저는 HTTPS로 서비스를 제공하고 이가 적용되지 않은 사이트에 접속하게 되면 사용자에게 보안 경고를 알린다.

 

*HTML, CSS, 자바스크립트, JSON, XML 등의 텍스트 기반 데이터와 이미지, 동영상, 파일과 같은 바이너리 데이터도 주고받을 수 있다.

바이너리 데이터는 HTTP멀티파트나 Base64로 인코딩하여 사용한다.

 

 

---

 

🔁 그렇다면 어떻게 통신할까?

 앞서 HTTP는 연결을 유지하지 않는 무상태 프로토콜이라고 하였다. 따라서 데이터의 교환은 요청(Request)과 응답(Response)의 방식으로 이루어진다. 클라이언트에서 서버로 HTTP 요청 Method를 보내면 서버에서는 해당 요청에 따른 데이터를 찾아 클라이언트로 응답을 보낸다. 또한 요청/응답 시에 부가적인 정보를 포함할 수 있는 헤더라는 항목이 있다.

 

헤더에 관한 자세한 내용은 본문에서 다루기엔 양이 너무 방대하여 작성자도 아직 알아가는 단계에 있어 이해를 돕기위해 mdn web docs : HTTP 헤더 / [HTTP 기초_1] 헤더 (요청(Request) 헤더, 응답(Response)헤더)를 참고하길 바란다. 그 중 기본적이라 할 수 있는 한 가지만 살펴보자면, *Content-Type 을 예로 들 수 있는데,

 

*Content-Type 헤더는 메시지 바디(본문)에 있는 데이터의 형식을 알려주는 헤더이다. 이는 요청 헤더 뿐만 아니라 응답 헤더에서도 사용된다. 웹 서비스 개발 시 사용자 요청에 대한 응답을 보낼 때는 반드시 Content-Type 헤더 값을 정확하게 명시해야 한다. 이 헤더의 값에 따라 브라우저의 동작이 바뀔 수 있기 때문이다.

 

 

 

 HTTP 요청Method에는 여러가지가 있지만 오늘은 그 중에 가장 많이 사용되고 주요시 여기는 4가지만 간략히 살펴보자. 통상적으로 CRUD라 알려진 메소드로는 다음과 같다.

• POST : 생성 (Create)
• GET : 조회 (Read)
• PUT : 수정 (Update)
• DELETE : 삭제 (Delete)

*수정에 관한 Method에는 PUT뿐만 아니라 PATCH도 있다. 두 메소드에는 차이가 있어 바로 아래에서 비교를 참고바란다.

<PUT>
리소스(자원)의 모든 것을 수정한다. 만약 해당하는 자원이 없으면 생성한다.
	* 전체가 아닌 일부만 전달할 경우, 전달값 외 모두 null 혹은 default 처리되니 주의한다.

<PATCH>
리소스(자원)의 요청된 일부만을 수정한다.
	* 요청된 일부만 반영되어 나머지는 기존의 데이터가 유지된다.

 

 

 HTTP 요청이 서버로 날아가면 응답이 성공적으로 수행되었는지 아닌지 알 수 있어야하는데, 이때 직관적으로 확인이 가능한 것이 Status Code(상태 코드)이다. 이는 각 상태에 따른 정해진 숫자를 코드로 나타내며, 크게 5개의 그룹으로 나누어진다. HTTP 상태 코드 자세히

 

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다
• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

 

 

---

✔️ HTTP 버전

HTTP 버전은 HTTP표준을 정의함으로, 버전에 따라 사용할 수 있는 기능과 통신 방법이 약간 다르다. 가장 많이 사용되고 있는 버전은 1.1 이며 다음으로는 2.0 이다. 현재까지는 0.9 / 1.0 / 1.1 / 2.0 / 3.0(QUIC) 로 구분된다. 오늘은 그 중에 1.1 정도로만 훑어보자.

 

*초기 http는 버전 번호가 없었으며 매우 간단했다. 이후 웹이 인기를 끌며 사용자의 다양한 요구를 충족시키기 위해 사양을 정리하여 탄생한 것을 1.0 버전이라 부르게 되었고 구별하기 위해 최초에 탄생한 HTTP는 0.9 버전으로 불리게 되었다.

 

 

1.1의 주요 특징으로는 앞 요청에 대한 응답을 기다리지 않고 여러 요청을 순차적이고 연속적으로 일단 보내놓고 그 순서에 맞게 응답을 받는 방식으로 이를 파이프라이닝(Pipelining)이라 한다. 하나씩 요청-응답이 처리되는 기존 방식을 개선 (단, 하나의 Connection에 여러 요청이 들어있을 뿐, 동시 여러 요청을 처리하여 응답으로 보내주는 것은 아님: Multiplexing 되지 않음)

 

 

이러한 특징을 가지고 있다보니 그에 따른 한계점도 존재하는데, 대표적으로는 다음과 같다.

 

• Head Of Line Blocking (HOL) : 앞 요청에 대한 응답이 오래걸리면 뒤 요청은 Blocking 되어버림 > 전체 속도의 저하 유발
• Header 구조의 중복 : 연속된 요청의 헤더의 많은 중복이 발생

 

* 위 문제를 개선하기 위해 여러 응답을 병렬로 보낼 수 있도록 하고, 불필요한 오버 헤드(헤더의 중복)를 제거한 것이 2.0버전이다. 

 

 

여기서 그럼 의문이 들 수 있다. 버전이 업그레이드 되면 좋은 거 아니야? 라고. 하지만 우리가 새 출시된 기기 혹은 신차를 산다고 가정해보자. 새로 출시되었다고 해서 100% 결함이 없다고 보장되어지느냐? 라고 했을 때 이미 그렇지 않은 사례들이 존재하듯이 모두가 맞다고 할 수 없을 것이다. 소비자에게 많이 팔려 사용되는 것이 인기가 있듯이,

 

1.1 버전을 많이 사용하는 이유는 우리가 필요로 하는 기본 기능들이 충분히 존재하기 때문이다. 2.0과 3.0은 아직 성능 개선에 초점이 맞춰져 있어서 1.1을 사용해도 충분한 서비스가 가능하다.

 

 

 

---

🔒 HTTPS, S만 붙었는데 대체 무슨 차이야?

HTTPS는 HTTP에 Secure을 붙인 용어이다. 단어로만 봐도 알 수 있듯 가장 큰 차이로 보안이 더해진 것이다. 이 두가지를 요약 비교하면

 

*응용계층과 전송계층에 관해서는 각 링크를 참조하길 권장한다.

구분	HTTP	HTTPS
동작 계층	응용 계층	전송 계층
기본 통신 포트	80	443
보안	암호화 체계가 없음	암호화 및 복호화 체계가 있음

물론 다른 차이도 있겠지만 암/복호화 체계의 유무가 가장 눈에 띌 것이다. 제3자로부터의 정보 탈취는 위험하고 중요한 문제일테니 말이다.

 

 

그럼 보안은 어떻게 이루어질까? HTTPS에서는 SSL과 앞단락에서 잠깐 언급한 TLS에 대해 빼놓을 수 없다.

• SSL : Secure Sockets Layer(보안 소켓 계층), 클라이언트-서버 간(또는 두 서버 간)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술 및 프로토콜.
• TLS : Transport Layer Security(전송 계층 보안), TLS은 SSL보다 향상된 보안 방식. 현재 1.3버전까지 승인되었으며 1.2까지는 권장하는 버전으로, 사용되어지고 있다.

90년대 중반에 넷스케이프로부터 SSL이 출시되어 업그레이드 되었으나 IETF(Internet Engineering Task Force)에 SSL 프로토콜 제어권이 넘어갔고 이를 비롯하여 IETF에서는 1999년에 TLS1.0을 출시하여 업그레이드 해왔고, 개선된 방식의 사용과 혼란을 방지하고자 SSL은 3.0을 마지막으로 2015년에 공식적인 사용 종료되었다. (그렇지만 여전히 많은 사람들이 SSL을 용어로 사용하고 있어 본문에서도 SSL로 언급하도록 한다.)

 

 

 

SSL의 핵심은 암호화와 인증서다. SSL은 보안과 성능상의 이유로 두가지 암호화 기법을 혼용해서 사용하고 있는데 SSL동작방법을 이해하기 위해서는 이에 대한 이해가 필요하다.

 

 

 

                    암호화                    

 

 

먼저 암호화 기법이라 하면 대칭키와 공개키를 말한다.

 

*암호를 만드는 행위인 암호화를 할 때 사용하는 일종의 비밀번호를 키(key)라고 한다. 이 키에 따라서 암호화된 결과가 달라지기 때문에 키를 모르면 암호를 푸는 행위인 복호화를 할 수 없다.

 

 

대칭키

대칭키는 동일한 키를 이용해 암호화와 복호화를 할 수 있는 방식의 기법이다. 암호화를 할 때 abc라는 키 값을 사용했다면 복호화를 할 때도 abc라는 값을 입력해야 한다. 이해를 돕기 위해 도어락에 비유하여 현관 비밀번호를 1234로 등록했다고 가정해보자. 현관을 넘어 집으로 들어가기 위해서는 도어락에 1234라는 비밀번호를 입력해야 할 것이다. 등록한 비밀번호와 출입을 위해 입력받은 비밀번호를 비교 즉, 대칭하여 암/복호화하는 것이 대칭키 방식이다.   

 

대칭키 방식은 치명적인 단점이 있다. 암호를 주고 받는 사람들 사이에 대칭키를 전달하는 것이 어렵다는 것도 단점이지만 무엇보다 대칭키가 유출되면 키를 획득한 공격자는 암호의 내용을 복호화 할 수 있기 때문에 암호화가 쓸모가 없어지기 때문이다. 이런 배경을 통해 공개키방식이 등장했다.

 

 

공개키

공개키 방식은 두개의 키를 갖게 되는데 A키로 암호화를 하면 B키로 복호화 할 수 있고, B키로 암호화하면 A키로 복호화 할 수 있는 방식이다. 두개의 키 중 하나를 비공개키(private key 혹은 개인키,비밀키라고도 부른다)로하고, 나머지를 공개키(public key)로 지정한다. 비공개키는 자신만 가지고 있고, 공개키를 타인에게 제공한다. 공개키를 제공 받은 타인은 공개키를 이용해서 정보를 암호화한다. 암호화한 정보를 비공개키를 가지고 있는 사람에게 전송한다. 비공개키의 소유자는 이 키를 이용해서 암호화된 정보를 복호화 한다. 이 과정에서 공개키가 유출된다고해도 비공개키를 모르면 정보를 복호화 할 수 없기 때문에 안전하다. 공개키로는 암호화는 할 수 있지만 복호화는 할 수 없기 때문이다.

 

그렇다면 사용자에 따른 신원은 어떻게 구별할 수 있을까? 비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송한다. 정보와 공개키를 획득한 사람은 공개키를 이용해서 암호화된 정보를 복호화 한다. 이 과정에서 공개키가 유출된다면 의도하지 않은 공격자에 의해서 데이터가 복호화 될 위험이 있다. 이런 위험에도 불구하고 비공개키를 이용해서 암호화를 하는 이유는 무엇일까? 그것은 이것이 데이터를 보호하는 것이 목적이 아니기 때문이다. 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미한다. 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자 서명이라고 부른다.

  

 

 

 

                 SSL인증서                 

 

 

클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장하는 SSL인증서는 클라이언트와 서버간 통신을 제3자가 보증해주는 전자화된 문서다. 클라이언트가 웹사이트를 통해 서버로부터 인증서 정보를 전달받으면 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증한 후에 암호화된 연결을 수립한다. 이를 'SSL handshake'라 하며 웹사이트 방문자에게는 이 과정이 보이지 않고 순간적으로 이루어진다. 또한, 이 인증서가 작동하는 과정에는 앞서 설명한 암/복호화가 포함되어있다.

 

 

 

 

---

 

SSL과 관련하여는 CA 등 추가적인 내용이 있지만 기본적인 원리를 이해하기에는 위 내용만으로도 우선은 충분할 것이다. 추가적인 내용이 필요하게 되면 다시 포스팅해볼 생각이다.

 

 

 

 

본 내용이 HTTP와 HTTPS의 기초 내용에 대해 비교적 쉽게 이해가 되었길 바라며,,

혹시 글에 문제가 있다면 댓글로 남겨주시길 :) 그럼 이만 !

 

 

 

 

 

 

 

 

*참고 문헌

HTTP 개요 - HTTP | MDN

HTTP란 무엇인가?

HTTP

HTTP (1) - version 별 특징 (0.9 / 1.0 / 2.0 / 3.0)

HTTPS와 SSL 인증서 - 생활코딩