HTTP 란?

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.

프로토콜은 데이터를 주고받는 상호간에 미리 약속된 규칙으로 규약 송신자와 수신자 사이에 “데이터 구조는 이런 식을 하고, 이런 의미이고, 속도는 어느정도로 보내고” 등을 약속한 것이다.

결국 HTTP는 클라이언트와 서버 간에 요청/응답 으로 데이터를 주고받는 프로토콜이다.

클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(request) 라 부르고, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(response)라 부른다.

클라이언트 ←→ 프록시 ←→ 프록시 ←→ 서버

클라이언트: 사용자 에이전트 - 사용자를 대신하여 동작하는 모든 도구이며 주로 브라우저에 의해 수행된다. 브라우저는 항상 요청을 보내는 개체이다.

웹 페이지를 표시하기 위해 브라우저는 HTML문서를 가지고 오기 위한 요청 전송, 이미지나 비디오 등에 해당하는 하위 리소스들을 잘 표시하기 위한 CSS에 대응하는 추가적인 요청도 전송.

브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고, HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시한다.

웹 서버 - 통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 제공하는 서버가 존재함.

HTTP 특징

• HTTP는 간단하다: 사람이 읽을 수 있도록 간단하게 고안되었다.
• HTTP는 확장이 가능하다: 클라이언트와 서버가 새로운 헤더의 시멘틱에 대해 합의만 한다면 새로운 기능 추가가 가능하다.
• HTTP와 연결 - 연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖이다. HTTP 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존한다. (Conectionless)
• HTTP는 상태가 없지만, 세션은 있다. (Stateless)

비연결성 (Connectionless)

비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말한다.

1) 비연결성의 장점

HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 만약 서버에서 다수의 클라이언트와 연결을 계속 유지한다면, 이에 따른 많은 리소스가 발생하게 된다. 따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있으므로 비연결적인 특징을 갖는다.

2) 비연결성의 단점

서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을 거쳐야하므로 연결.해제에 대한 오버헤드가 발생한다는 단점이 있다.

3)KeepAlive

이에 대한 해결책으로 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성을 사용할 수 있다. KeepAlive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기 위해 패킷을 주기적으로 보내는 것을 말한다. 이 때 패킷에 반응이 없으면 접속을 끊게 된다.

주기적으로 클라이언트 상태를 체크한다는것 (KeepAlive)역시 완벽한 해결책은 아니다. KeepAlive 속성이 On 상태라해도, 서버가 바쁜 환경에서는 프로세스 수가 기하급수적으로 늘어나기 때문에 KeepAlive 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 한다.

무상태 (Stateless)

Connectionless로 인해 서버는 클라이언트를 식별할 수가 없는데, 이를 Stateless라고 한다. 클라이언트의 상태를 모른다는 것은 다음의 예시와 같다.

1. 쇼핑몰에 접속
2. 로그인
3. 상품 클릭 -> 상세화면으로 이동
4. 로그인
5. 주문
6. 로그인
7. ….

즉, 매번 새로운 인증을 해야하는 번거로움이 발생하게 된다.

1) 상태를 기억하는 방법 - 쿠키

서비스를 운영하려면 서버가 클라이언트를 기억해야 할 경우가 많이 있는데, 클라이언트를 기억할 수 있는 방법은 쿠키를 사용하는 것이다.

2) 상태를 기억하는 방법 - 세션

쿠키는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약하다. 이와 달리 세션은 부라우저가 아닌 서버단에서 사용자 정보를 저장하는 구조이다. 따라서 쿠키보다는 안전하다고 할 수 있다. 그런데 세션 정보도 중간에 탈취 당할 수 있어 완벽한 보안이라고 할 수 없다. 또한 세션을 사용하면 서버에 사용자 정보를 저장하므로, 서버의 메모리를 차지하게 되고 만약 동시 접속자 수가 많은 서비스일 경우에는 서버 과부화의 원인이 된다.

3) 상태를 기억하는 방법 - 토큰을 사용하는 OAuth, JWT

쿠키와 세션의 문제점들을 보완하기 위해 토큰(Token)기반의 인증 방식이 도입되었다. 토큰 기반의 인증 방식이 도입되었다. 토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술 이다. 그래서 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성이 높은 기술이라 할 수 있다.

HTTPS 란?

HTTP 에 암호화와 인증, 그리고 완전성 보호를 더한 것이 HTTPS다. HTTPS는 SSL의 껍질을 덮어쓴 HTTP 라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다.

HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신 하게 된다. SSL 을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

HTTPS 통신 흐름

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.

2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.

   CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업

3. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.

4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.

5. 클라이언트는 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.

   CA 기업의 공개키는 브라우저가 이미 알고있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)

6. 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다. 이제 A서버와 통신할 대는 얻은 A서버의 공개키로 암호화해서 요청을 날리게 된다.

HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우 등)

이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

모든 웹 페이지에서 HTTPS를 사용하지 않는 이유

평문 통신에 비해서 암호화 통신은 CPU 나 메모리 등 리소스가 많이 필요하다. 통신할 때마다 암호화를 하면 많은 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 줄어들게 된다. 그렇기 때문에 민감한 정보를 다룰 때만 HTTPS 에 의한 암호화 통신을 사용한다.