본문 바로가기

Frontend

HTTP와 HTTPS

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜입니다. 클라이언트가 서버에게 요청을 보내면 서버는 응답을 보냄으로써, 데이터를 교환합니다. HTTP는 비연결성및 무상태성이라는 특징을 가집니다. HTTP는 요청에 대한 응답을 처리하게 되면 연결을 끊어 버립니다. 따라서 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않습니다.

 

서버가 다수의 클라이언트와 연결을 계속 유지한다면, 이에따른 자원 낭비가 심해집니다. 비연결성및 무상태성의 특징을 가진다면 불필요한 자원낭비를 줄일 수 있다는 장점이 존재합니다.

 

그러나 서버는 클라이언트를 식별할 수 없다는 단점또한 존재합니다. 로그인을 하더라도 다음 요청에서는 해당 클라이언트를 기억하지 못해 또 로그인을 해야하는 문제가 발생합니다. 브라우저에서 새로고침을 누를 때 마다 로그인을 해야하는 상황. 말이안됩니다. 하지만 우리가 사용하고 있는 웹 사이트의 경우 한번 로그인하면 다시 로그인 할 필요없이 여러 페이지를 돌아다니며 다양한 기능들을 이용할 수 있습니다. 심지어는 브라우저를 껐다가 켜도 로그인이 유지되기도 합니다. 이는 HTTP 의 비연결성 및 무상태성 특징을 보완한 기술인 Cookie와 Session덕분입니다. 

 

쿠키란 클라이언트가 어떠한 웹사이트에 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 일컫습니다. 

서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때 클라이언트 측에 저장하고 싶은 정보를 응답헤더 Set-Cookie에 담습니다. 쿠키는 Key-Value형식의 문자열입니다. 

 

이후 해당 클라이언트는 요청을 보낼 때마다 매번, 저장된 쿠키를 요청 헤더의 Cookie에 담아서 보냅니다. 

서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별가능합니다. 

 

단점은 보안에 취약합니다. 요청시 쿠키의 값을 그대로 보내기때문에 유출및 조작당할 위험이 있습니다. 쿠키에는 용량제한이 있어 많은 정보를 담을 수 없습니다. 웹 브라우저마다 쿠케에 대한 지원형태가 다르기 때문에 브라우저간 공유가 불가능합니다. 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해집니다.

 

Cookie & Session 기반 인증

 

쿠키를 통해 클라이언트 로그인 상태를 유지시킬 수 있었지만, 가장 큰 단점은 쿠키가 유출및 조작 당할 위험이 존재한다는 것입니다. 개인정보를 HTTP로 주고받는 것은 위험합니다. 세션은 비밀번호등 클라이언트의 인증정보를 쿠키가아닌 서버측에 저장하고 관리합니다. 

 

서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때 , 인증정보는 서버에 저장하고 클라이언트는 식별자인 JSESSIONID를 쿠키에 담습니다. 이후 클라이언트는 요청을 보낼때마다 JSESSIONID 쿠키를 함께 보냅니다. 서버는 JSESSIONID의 유효성을 판별해 클라이언트를 식별합니다. 

쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않기 때문에 안전합니다. 그러나 해커가 이를 중간에서 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재합니다.  각 사용자마다 고유한 세션 ID 가 발급되기 때문에, 요청이 들어올 때마다 회원정보를 확인할 필요가 없습니다. 

 

서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 생깁니다.