HTTP와 HTTPS : 우리 이렇게 얘기하기로 약속~
사람이 대화하는 언어에는 그만의 규칙이 있다.
한국어를 예로 들어보면 '나는 밥을 먹는다'와 같이 주어 + 목적어 + 동사의 구조로 이루어진 문장을 사용하거나
자음과 모음의 조합을 통해 단어를 만든다던가 하는 여러 규칙이 있다.
클라이언트와 서버 간에도 이러한 규칙이 존재하는데 그중 하나인 HTTP와 HTTPS에 대해서 알아보자.
HTTP는?
우선 HTTP에 대한 이야기를 해보자.
간단하게 단어부터 풀이하면 Hypertext Transfer Protocol
문자 그대로 해석하면 문서에서 다른 문서로 접근할 때 발생하는 통신간의 약속이라는 의미가 될 것 같다.
다시 정리해 보면, HTTP는 클라이언트와 서버 간에 데이터를 주고받을 때 사용하는 통신 규약인데
이 친구가 가지고 있는 몇 가지 특징이 있다.
1. 요청과 응답
우리가 어떤 웹 페이지에 접속하면 다양한 정보가 담긴 페이지를 바로 볼 수 있다.
이 과정 속에서 클라이언트는 화면을 그리는데 필요한 데이터를 서버에 요청하고,
서버에서는 클라이언트의 요청에 대한 응답으로 데이터를 전달한다.
받아온 데이터를 클라이언트에서 사용자가 볼 수 있도록 화면에 그려주는 작업을 하게 된다.
이러한 과정에서 클라이언트와 서버는 HTTP를 이용해 요청을 하고 응답을 하며 데이터를 주고받게 된다.
2. Stateless
문자 그대로 해석하면 상태 없음을 의미한다. 이 말의 의미는 통신의 기억이 없다는 것으로 해석될 수 있다.
무슨 말이냐면, 각각의 HTTP 통신(요청/응답)은 독립적이기 때문에 과거의 통신 내용을 전혀 기억하지 못한다.
일반적인 카페에서 손님 (클라이언트)과 직원 (서버)의 대화를 살펴보자.
손님 : 아이스 아메리카노 1개 주세요.
직원 : 매장에서 드시나요? 아니면 포장해 드릴까요?
손님 : 포장해 주세요.
직원 : 포인트 적립 하시나요?
손님 : 아니요
직원 : 4500원 결제해 주세요.
사람 간의 일반적인 대화의 방식은 이전 대화에 대한 내용을 기억하고 다음 대화로 이어간다.
하지만 이 사람들이 stateless 즉, 기억이 없는 상태라면..?
손님 : 아이스 아메리카노 1개 주세요.
직원 : 매장에서 드시나요? 아니면 포장해 드릴까요?
손님 : 아이스 아메리카노 1개 주세요.
직원 : 매장에서 드시나요? 아니면 포장해 드릴까요?
손님 : 아이스 아메리카노 1개 주세요. (도르마무)
이러한 문제를 해결하기 위해서는 한번 주문할 때 필요한 모든 정보를 한 번에 말하는 방식으로 주문해야 한다.
인간의 방법에서는 굉장히 비효율적인 방법이라고 생각이 되는데 HTTP는 왜 이런 방법을 사용할까?
HTTP가 이러한 통신 방식을 사용하는 이유는 효율성과 단순성 때문이다.
HTTP가 통신할 때 이전 요청 내용을 기억해야 한다면 통신마다 클라이언트의 상태를 서버에 저장해야 하는데,
웹이 점차 복잡해짐에 따라 서버에서 받아와야 하는 데이터도 점차 늘어나고 있다.
그래서 통신도 굉장히 많아지고 있는데, 이때마다 이전 요청을 기억해야 한다면
서버의 메모리에 부담을 가중시킬 수밖에 없다.
또한 요청과 응답이 복잡하게 엮인 구조로 통신하게 된다면,
클라이언트가 서버 간의 통신에서 불필요한 데이터나 필요한 데이터의 누락이 발생할 수도 있다.
그렇기에 HTTP 통신은 상태를 저장하지 않는 형태로 통신을 진행한다.
그러나 stateless의 통신 방법에도 문제점이 있고 명확한 한계가 있는데,
그러한 부분을 관리하기 위해 세션, 쿠키, 토큰을 사용해 상태를 관리하기도 한다.
HTTP 메시지 구조
HTTP는 통신 규약이라고 했는데 어떤 규칙으로 통신을 하는지 그 구조를 알아보자.
먼저 데이터 요청 시 클라이언트가 서버로 전달해야 하는 구조를 살펴보면
크게 3 부분으로 나눠져 있는 것을 볼 수 있다.
우선 Start Line에는 HTTP method와 Request target, HTTP version의 정보가 담겨있는데,
HTTP method는 클라이언트에서 데이터를 어떻게 할 것 인지 서버에 간단하게 알려주는 부분이다.
해당 부분에 대한 더 자세한 내용은 맨 아래 링크를 통해서 참고하자..!
Request target은 서버가 클라이언트의 요청을 받는 주소다.
90년대 친구랑 놀고 싶어서 친구집에 전화 걸었을 때,
번호를 잘못 누르면 "잘못 걸었다~"라는 내용과 함께 전화가 끊기는 것처럼
잘못된 주소로 요청을 하면 잘못 요청했다는 오류 메시지를 전달받게 된다.
마지막 HTTP version은 통신 규약의 버전인데 주로 1.1 버전을 사용한다.
Headers에는 요청의 메타 데이터 (추가적인 정보)가 담겨 있다.
{ key : value }의 형태를 가지고 있는데 요청을 보내는 클라이언트의 정보가 담겨 있는 영역이다.
마지막 Body에는 요청 시 서버에 전달하는 데이터인데,
Body는 Start Line의 HTTP method에 따라 있기도 하고 없기도 하다.
먼저 데이터 요청 시 서버가 클라이언트로 전달해야 하는 구조를 살펴보면
역시 크게 3 부분으로 나눠져 있는 것을 볼 수 있다.
우선 Status Line에는 HTTP version, Status Code, Status Text의 정보가 담겨있다.
HTTP version은 요청 시에 클라이언트가 전달한 값과 동일하고,
Status Code는 응답에 대한 상태를 코드로 알려준다.
예를 들어 통신에 성공하면 200번대의 코드가, 실패하면 400번대의 코드를 보여준다.
Statis Text는 Status Code에 따른 통신 상태를 간략히 설명한다.
Headers에는 요청과 마찬가지로 응답에 대한 추가적인 정보가 담겨있고,
Body에는 요청 시 서버에서 전달하는 데이터가 담겨 있다.
근데 HTTPS는 왜 나온 거야?
사실 여기까지만 보면 HTTP가 뭐고 어떤 데이터들이 주고받아지는지 알 수 있겠는데
왜 HTTP만 있으면 되지 HTTPS가 등장한 지 이해가 안 될 수 있다. (내 얘기다)
우선 HTTP를 쓰던 시절에는 딱히 보안과 개인정보에 대해서 보호할 필요를 느끼질 못했을 수 있다.
민감한 개인정보를 입력할 정도로 웹이 복잡하고 발달하지도 않기 때문인데,
그러나 최근에는 점차 웹이 발전하고, 다뤄야 하는 민감한 정보들도 많아지고
게다가 이러한 정보들을 해킹당할 경우도 많아지기에 보안적으로 개선이 필요했다.
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=mx_star&password=12345678위의 예시를 보면 HTTP로 통신하게 될 경우 암호화되지 않은 평문 데이터를 전송해
사용자의 민감한 정보가 노출된다는 문제가 있었다.
이러한 이유로 HTTP에서 HTTPS를 권장하게 된다.
HTTPS 개념과 특징
HTTPS는 Hypertext Transfer Protocol Secure로 HTTP의 보안 버전이다.
HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 통신을 암호화한다.
HTTPS의 장점으로는 아무래도 가장 먼저 보안성을 들 수 있겠다.
HTTPS를 통해 통신을 하게 되면 데이터가 암호화가 되어서 설사 데이터 해킹을 당하더라도
암호화된 데이터기 때문에 내용을 확인하기 매우 어려워진다.
그리고 SEO에 유리하다는 장점도 있다.
이 부분은 '그냥 개발할 때 잘 만들면 되는 거 아닌가?'라고 생각할 수 있는데,
최근 검색 엔진은 HTTPS를 사용하는 웹사이트를 선호하기 때문에
HTTPS를 사용하면 SEO에서도 유리하다는 장점이 있다.
물론 HTTPS는 암호화와 복호화 과정을 거쳐야 해서 일반적으로는 HTTP 보다는 약간 느릴 수 있다는 점과
SSL 인증서를 구입하고, 설정, 관리에 추가적인 비용이 발생할 수 있다는 단점은 있지만,
최근 환경에서는 반드시 적용해야 하는 부분이라고 생각된다.
아 물론 그냥 정적인 페이지고 민감한 정보가 아예 없다면 HTTP로 적용해도 상관없겠지만!
함께 읽으면 좋은 글 리스트