오늘은 HTTP와 HTTPS에 대하여 알아보려고 한다.

HTTP(Hyper Text Transfer Protocol)는 웹 상에서 정보를 주고받기 위해 사용되는 프로토콜로, HTML 문서를 주고 받기 위해서 주로 사용된다. 우리가 어떠한 웹 페이지에 접근할 때, 해당 웹 페이지를 렌더링하기 위한 자원들을 서버에 요청하고 그 응답을 받아서 얻은 source들을 얻게 된고, 이러한 source를 바탕으로 렌더링된 웹 페이지를 눈으로 볼 수 있다. 이와 같이 HTTP는 일종의 통신 규약으로, 어떠한 형식을 통해서만 서로 통신을 하겠다고 정해놓은 규칙을 의미한다.

HTTP & HTTPS

HTTPS는 HTTP뒤에 S가 붙은 것처럼 기존 HTTP에 무언가 기능이 추가된 프로토콜이다. 그 무언가란 SSL(Secure Socket Layer) 을 말한다. SSL은 인증서의 일종으로, HTTP를 이용한 요청 및 응답을 암호화해준다. 따라서, HTTPS를 통한 통신이 HTTP보다 더 안전한 보안용 프로토콜이라 할 수 있다.

HTTP

HTTP는 기본적으로 요청(request)과 응답(response)의 구조로 되어있으며, 클라이언트가 서버로 HTTP request를 보내면, 서버는 HTTP response를 응답하면서 통신이 이루어진다.

HTTP에는 여러가지 요청 메서드가 존재하며, 이중 중요한 것만 나열하자면, 아래와 같다.

GET : 서버로 데이터를 요청하는 메소드

POST : 서버에 데이터를 추가하기 위해 사용하는 메소드

PUT : 서버의 데이터를 업데이트 하는 메소드(전부)

PATCH : 서버의 데이터를 업데이트 하는 메소드(일부)

DELETE : 서버의 데이터를 삭제하는 메소드

!! PUT vs PATCH

이 둘의 차이는 아래의 그림을 보고 이해하자!

그림과 같이 회원정보를 바꿔야 하는 상황에서 PUT메서드를 사용하게 되면, 전부 바뀌므로, 위의 경우에서는 이름 이외의 변경사항이 없었을지라도, 이를 전송하지 않아 그림과 같이 나이와 성별의 값이 null로 업데이트된다. PATCH는 이와 다르게, 일부만 업데이트가 가능하기 때문에, 이름만 업데이트되고, 나이와 성별은 기존값이 유지된다. 이 둘의 차이점은 이정도로만 이해하고 넘어가자.

HTTP의 request & response 구조

HTTP의 구조를 알고 싶다면, CLI를 열어서 아래의 커맨드를 실행하면 된다.(작은 따옴표는 제거)

curl -v '확인하고 싶은 페이지 링크'

여기서는 예시로 MDN 공식문서에서 HTTPS를 검색한 페이지 링크를 사용하였다.

먼저 HTTP로 요청을 보냈기 때문에, 이에 해당하는 포트인 80이 출력되는 것을 볼 수 있다.(HTTPS는 443)

다음으로는 크게 두개의 단락이 있는데, 첫번째 단락이 HTTP request message이고, 두번째 단락이 response message에 해당된다.

request message

그림과 같이 다시 세 단락으로 구분할 수 있다.

• 첫번째 단락 (빨간색 박스)

  HTTP method | request target | HTTP version

  MDN 공식문서에서 HTTPS에 대해 검색 즉, 데이터를 요청하였기 때문에, 이에 해당하는 GET 메소드가 표시되고 있고, 어떠한 것을 검색하였는지에 해당하는 타겟 정보가 나오며, 마지막에는 HTTP의 버전이 표시됨을 알 수 있다.

• 두번째 단락 (파란색 박스)

  header에 해당하는 부분이다.

  HOST | User-Agent | Accept | Authorization | etc...

  header에는 Host, User-Agent(클라이언트), Accept(해당 타입에 맞는 데이터를 요청), Authorization(JWT와 같은 인증 토큰을 서버로 보낼 때 사용)등이 들어간다.

• 세번째 단락 (초록색 박스)

  세번째 단락은 body부분에 해당되는데, POST 메소드 같은 경우 서버에 데이터를 추가하기 위해 사용되기 때문에 이 부분에 서버로 전송할 데이터를 담게 되지만, 이 경우에는 GET요청이므로 비어있음을 볼 수 있다.

response message

이 경우에도 세 단락으로 구분할 수 있다.

• 첫번째 단락 (빨간색 박스)

  HTTP version | status code | status text

  그림과 같이 HTTP의 버전이 표시되고, 그 뒤에 요청에 대한 응답의 종류를 나타내는 상태코드와 이 코드의 상태를 나타내는 메시지가 표시된다. 이 경우에는 GET요청이므로 일반적으로 200 (알겠어! 로 생각하자) OK가 나와야 하지만, 어떤 이유에선지 301과 Moved Permanently가 표시되었다. 이 상태 및 상태코드는 redirect 시에 나타나며, 쉽게 말하자면, 나는 A라는 페이지로 이동하려고 했는데, 해당 페이지의 내용이 B라는 페이지로 이동되었기 때문에, B라는 페이지로 redirect되었다는 의미라고 한다.

❗ 원인을 찾은듯 하다. curl로 확인할 때, 경로에 http를 사용하는 경우에는 redirect가 표시되었으나, https로 바꿔준 뒤에는 정상적으로 200 상태코드가 표시된다.

• 두번째 단락 (파란색 박스)

  Date | Content-type | Content-Length | Cache-Control | Location | etc...

request message와 동일하게 header 부분에 해당한다. header에는 주로, Date(응답받은 시각), Content-type, Content-Length, Cache-Control, Location 등이 들어온다.

• 세번째 단락 (초록색 박스)

  세번째 단락은 body에 해당되는데, 원래라면, 200 상태코드와 함께 요청한 데이터에 해당하는 즉, HTML문서임을 나타내는 이 나타나야 하는데, 이 경우에도 redirect 때문인지 기대하던 것과 다르게 아무것도 응답받지 못하였다.

  위와 동일하게 주소부분에 https로 바꿔준 뒤, 정상적으로 body 부분에 html 문서를 받아옴을 확인하였다. (그 길이가 매우 긴 관계로 사진은 생략함)

❗ 좀더 찾아보니, HTTP 상태코드에서 300번대는 redirection시에 응답받고, 응답 헤더에 Location이 존재한다면, 그 위치로 자동으로 이동한다고 한다. 따라서 위의 그림에도 응답 헤더에 Location이 있어 redirection이 일어났고, 301 상태코드의 경우 리다이렉트 요청 시, 요청 메서드가 GET으로 바뀌며, 본문이 제거될 수 있다고 한다. 때문에, 위와 같이 응답받은 body부분이 비워져서 응답온 것으로 생각된다.

너무 길어져서, HTTPS 설정 및 적용 방법은 다음 블로그에서 다뤄야겠다.