HTTP, HTTPS / HTTP 메서드

HTTP 프로토콜

HTTP(Hypertext Transfer Protocol)는 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신 규약

 

웹 문서간에 링크를 통해 연결할 수 있은 프로토콜이며, 문서뿐만 아니라 여러 종류의 데이터들을 폭 넓게 전송할 수 있다.

1. HTML, TEXT
2. IMAGE, 음성, 영상, 파일
3. JSON, XML(API)
4. 거의 모든 형태의 데이터 전송 가능

서버 간에 데이터를 주고 받을 때는 대부분 HTTP 프로토콜을 사용해서 통신하며, 인터넷 주소를 지정할 때 http://www.naver.com 와 같이 시작하는 것은 www.naver.com 이라는 인터넷 주소가 가진 데이터 정보 등의 교환을 HTTP 통신 규약대로 처리한다는 것을 의마한다.

 

인터넷 기반 서비스에는 HTTP 외에도 email, FTP, DNS, NEWS 등이 있다.

 

HTTP의 통신 구조

 

HTTP 통신은 클라이언트(Front-End)와 서버(Back-End)로 나뉘어진 구조로 되어있다.

클라이언트가 요청(Request)하면 서버가 응답(Response) 하는 것이다.

 

클라이언트가 HTTP 메시지를 만들어 보내고, 서버에서 요청에 대한 응답이 올 때까지 기다리고 서버는 요청에 대한 결과를 만들어서 응답한다.

 

HTTP 통신에 있어 클라이언트와 서버를 분리해야 되는 이유로는 각자의 역할에 집중할 수 있기 때문이다.

클라이언트에서는 복잡한 비즈니스로직이나 데이터를 다룰 필요없고, UI를 그리는데 집중할 수 있다.

서버에서는 복잡한 비즈니스 로직이나, 데이터를 다루는데만 집중하면 된다(트래픽이 폭주해 고도화가 필요한 경우 클라이언트는 신경 쓰지 않고 서버만 개선하면 된다).

 

클라이언트와 서버를 독립적으로 구분한다는 것은 각자의 책임을 나눠 해당 책임에만 집중하여, 클라이언트와 서버 양쪽이 각각 독립적으로 고도화할 수 있다.

 

HTTP의 무상태성(Stateless)

• 무상태(Stateless): 클라이언트와 서버 사이에 상태를 유지하지 않는다
• 장점: 서버 확장성 높음(스케일 아웃)
• 단점: 클라이언트가 추가 데이터 전송(메모리 ↑)

상태유지(Stateful)

• 서버가 클라이언트의 상태를 보존한다.
• 가장 대표적인 예로 홈페이지에서 회원 로그인을 하면, 페이지를 옮겨가도 서버는 클라이언트의 상태를 보존하기 대문에 그 클라이언트가 회원인지 알 수 있다.
• 중간에 서버에서 장애가 발생하면 클라이언트는 처음부터 다시 작업을 요청해야 한다.
• 서버가 바뀔 때마다 클라이언트의 내용을 기록해서 상태를 유지해야 하는데 어려움이 있다.

무상태(Stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 홈페이지에서 회원 로그인을 하고 페이지를 옮기면 또 로그인을 요청한다, 서버는 클라이언트의 상태를 보존하지 않기 때문에 그 클라이언트가 회원인지 알 수 없다.
• 무상태 환경에서는 회원 정보를 서버가 아닌 클라이언트가 토큰 형태로 가지고, 서버와 통신이 필요할 때 실어 보내 인증하는 방식이다.
• 무상태 환경은 클라이언트가 상태 정보를 갖고 있는 것이므로 아무 서버나 호출해도 되기 때문에 서버의 스케일아웃(수평확장)에 유리하다.
• 상태유지(Stateful)보다 데이터를 많이 사용한다는 단점이 있다.

 

HTTP의 비연결성(Connectionless)

• HTTP는 기본이 연결을 유지하지 않느 모델이다.
• 서버와 클라이언트의 Connection을 지속하지 않는다.
• 1시간동안 수천명 이상이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 적다.
  • 예를 들면 웹 브라우저 검색 페이지에서 검색 버튼만 연타하면서 이용하지는 않는 것
• 비연결성 특성 때문에 서버 자원을 매우 효율적으로 사용할 수 있다.

[ Stateless와 Connectionless 차이]

Stateless(무상태성): 필요한 상태에 대한 정보를 클라이언트가 가지고 오기 때문에 클라이언트의 요청에
어느 서버가 응답해도 상관 없음. 따라서 클라이언트의 요청이 대폭 증가하면 서버를 증설해 해결할 수 있음

Connectionless(비연결성): 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을
유지하지 않음으로써 자원을 효율적으로 관리하고 수 많은 클라이언트의 요청에 대응할 수 있게 함

무상태성은 클라이언트와 서버 간에 상태 정보를 들고 있지 않아 클라이언트가 상태 정보를 일일히 http에
실어 요청해야 되는 것을 말하고, 비연결성은 클라이언트와 서버 간에 네트워크 연결이 끊어져 단절되는 것

 

 

연결을 유지하는 모델

• 연결을 유지한다면, 서버와 클라이언트의 연결은 서로의 네트워킹 요청이 없더라도 계속해서 유지된다.
• 자원이 계속해서 사용된다(이러한 점 때문에, HTTP는 기본적으로 연결을 유지하지 않는 모델이다).

 

연결을 유지하지 않는 모델

• 연결을 유지하지 않는다면, 서버의 자원을 효율적으로 사용할 수 있다.
• 클라이언트가 연결을 계속 끊는다는 것은 TCP/IP 연결을 매번 새롭게 맺어야 한다는 것을 뜻한다.
• TCP 3 way handshake를 매번 해야하고, 이는 시간이 걸린다.
• 이러한 문제는 HTTP 지속 연결(Persistent Connections)로 해결하고 있다.
• HTTP/2, HTTP/3에서 더 많은 최적화가 이루어 졌다.

 

비연결성 한계 - 단기 커넥션

• HTTP 초기 - 연결, 종료 낭비
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수많은 자원이 함께 다운로드 되는데, 새로 연결을 맺을 때마다 TCP Handshake가 발생한다는 문제점이 있음
• HTTP 초기에는 모든 자료에 대해서 비연결성으로 각각의 자원에 대해 연결/응답/종료를 반복하다보니 대략적으로 1초 가량 소모되었다.

 

비연결성 극복 - HTTP 지속 연결

• 클라이언트는 서버와 소켓 연결을 한 다음 필요한 자원을 요청/응답으로 다운로드받는다
• 소켓 연결을 일정 시간동안 유지함으로써, 필요한 자원들을 모두 다운받을때까지 연결이 종료되지 않고 요청/응답이 반복된 뒤 종료

 

HTTP 상태 코드

상태 코드는 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능으로, 3자리 숫자로 만들어져 있으며, 100 ~ 500 번대 숫자로 이루어져 있다.

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

 

HTTP 메시지

 

개발자 도구의 네트워크 창에서 Headers 부분을 보면 클라이언트와 서버 간에 HTTP 메시지를 통해 통신한 이력을 확인할 수 있다.

 

Request Headers는 클라이언트가 서버에게 보내는 HTTP 메시지 이력이며, Response Headers는 서버가 클라이언트에게 응답하는 HTTP 메시지 이력이다.

 

구조

 

HTTP 메시지는 기본적으로 시작라인(Start Line), 헤더(Header), 공백 라인(Empty Line), 바디(Message Body)로 구성된다.

 

공백 라인은 HTTP 메시지 값을 구분하기 위한 라인이므로, 단순히 보기 편하게 넣는 것을 넘어서 반드시 있어야 한다.

보낼 메시지 바디가 없다면 공백만 넣고 끝내면 된다. 그리고 HTTP 요청 종류에 따라 Message Body가 포함될 수도 있고 아닐 수도 있다.

 

HTTP 요청 메시지

• 시작 라인(Start Line)
  • Method : GET / POST / PUT / DELET 등(HTTP 메서드)
  • URL : 요청 대상 경로 표시
  • Version : 사용된 http 버전
• 헤더(Header)
  • Headers : HTTP 전송에 필요한 모든 부가 정보를 담고 있다(메시지 크기, 압축 여부, 인증, 브라우저 정보, 서버 정보, 캐시... 등)
• 공백 라인(Empty Line) : 헤더와 바디를 구분하기 위한 라인
• 바디(Message Body)
  • Message Body : 전송 받은 데이터

 

HTTP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 데이터 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 일부만 변경
• DELETE : 리소스 삭제

기타 메서드

• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

HTTP 메서드 특성

안정성(Safe)

• 호출해도 리소스 변경이 일어나지 않는 속성
• 여기서 안전의 기준은 오직 리소스 변경 가능성이며, 외적인 요소는 포함하지 않는다
• GET, HEAD를 안전한 메서드라고 할 수 있다(POST, PUT, PATCH, DELETE는 리소스를 변경하는 메서드)

멱등성(Idempotent)

• 동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것
• 같은 행위를 여러 번 반복하더라도 같은 효과를 받으며, 서버의 상태로 동일하게 남음
• 멱등성은 요청의 결과를 보고 판단
• TimeOut 등으로 클라이언트가 서버로부터 정상 응답을 받지 못했을 대 같은요청을 다시 해도 되는지 판단하는 근거
• GET : 몇 번을 조회하더라도 같은 결과가 조회된다
• PUT : 결과를 대체한다. 따라서 같은 요청을 여러 번해도 최종 결과는 같다
• DELETE : 결과를 삭제한다. 같은 요청을 여러 번 해도 삭제된 결과는 같다
• POST : 멱등이 아니다, 두 번 호출하면 에러가 발생할 수 있다, POST로 주문을 두 번 호출하면 결제가 중복될 수 있다

캐시 가능(Cacheable)

• 응답 결과를 캐시해 사용할 수 있는 속성
• GET, HEAD, POST, PATCH가 캐시 가능하나, Message Body의 캐시 키의 복잡성 문제로 실제로는 GET, HEAD만 사용

 

HTTPS 란?

HyperText Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다.

 

HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

 

대칭키 암호화와 비대칭키 암호화

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하고 있다. 각각의 암호화 방식은 다음과 같다.

• 대칭키 암호화
  • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
  • 키가 노출되면 매우 위험하지만 연산 속도가 빠름
• 비대칭키 암호화
  • 1개의 쌍으로 구성된 공개키와 암호화/복호화 하는 데 사용함
  • 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

비대칭키 암호화는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.

• 공개키: 모두에게 공개 가능한 키
• 개인키: 나만 가지고 알고 있어야 하는 키

암호화를 공개키로 하느냐 개인키로 하느냐에 따라 얻는 효과가 다른데, 공개키와 개인키로 암호화하면 각각 다음과 같은 효과를 얻을 수 있다.

• 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. → 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
• 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. → 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS의 동작 과정

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있다.

 

HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다(세션키는 주고 받는 데이터를 암호화하기 위해 사용 되는 대칭키).

 

데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어지는데, 여기서 문제는 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐 인데, 이 과정에서 비대칭키가 사용된다.

 

처음 연결을 성립하여 안전하게  세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.

 

실제 HTTPS 연결 과정이 성립되는 흐름을 살펴보면 다음과 같다.

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 한다
2. 서버는 공개키(인증서)를 브라우저에 넘겨준다
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급한다
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송한다
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻는다
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행한다

 

HTTPS의 발급 과정

서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로는 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급 받는다.

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급한다
2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청한다
3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고 , CA 기업의 개인키로 암호화하여 A 기업에게 이를 제공한다
4. A 기업은 클라이언트에게 암호화된 인증서를 제공한다
5. 브라우저는 CA 기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화한다
6. 암호화된 인증서를 복호화하여 얻은 A기업의 공개키로 세션키를 공유한다

 

인증서는 CA의 개인키로 암호화되었기 때문에 신뢰성을 확보할 수 있고, 클라이언트는 A 기업의 공개키로 데이터를 암호화하였기 때문에 A기업만 복호화하여 원본의 데이터를 얻을 수 있다.

 

인증서에는 A 기업의 공개키가 포함되어 있으므로, A 기업의 공개키라도 봐도 무방하며, 브라우저에는 인증된 CA 기관의 정보들이 사전에 등록되어 있어 인증된 CA 기관의 인증서가 아닐 경우 다음과 같은 형태로 브라우저에서 보여지게 된다.

 

HTTP와 HTTPS

HTTP는 암호화가 추가되지 않아 보안에 취약하지만 HTTPS는 안전하게 데이터를 주고받을 수 있다.

 

HTTPS를 이용하면 암호화/복호화 과정이 필요해 HTTP보다 속도가 느리며, 인증서를발급하고 유지하기 위한 추가 비용이 발생한다.

 

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출 되어도 괜찮은 단순한 정보 조회 등만을 처리하고 있으면 HTTP를 이용해도 괜찮다.

 

차이점 요약