[HTTP] HTTP 쿠키와 세션

 

 

 

서로 간의 통신을 위한 약속을 프로토콜이라고 한다.

웹에서 프로토콜은 주고 받을 데이터에 대한 형식을 정의한 것으로 생각하면 된다.

 

데이터를 주고받을 때, 어떤 형식으로 주고받을지 미리 협의 해 놔야 통신이 가능하다.

 

HTTP (Hyper Text Transfer Protocol) 도 프로토콜의 종류 중 하나다.

 

 

1. Stateless 

 

HTTP는 상태를 유지하지 않는다.

따라서 같은 클라이언트가 같은 요청을 서버에게 2번 보내도 서버는 같은 클라이언트로부터 도착한 요청임을 알 수 없다.

 

따라서 쿠키와 세션을 사용해 사용자를 구분한다.

 

쿠키는 클라이언트의 브라우저에서 관리되는 작은 데이터 파일이다.

 

서버는 HTTP 응답 메세지를 보낼 때 헤더에 Set-Cookie 필드를 생성해 쿠키를 설정한다.

클라이언트가 쿠키를 받은 이후부터는 같은 서버에 요청을 보낼 때 마다 HTTP 요청 메세지를 보낼 때 헤더에 쿠키를 포함시킨다.

 

Cookie ck = new Cookie("id", "asdf"); // 쿠키생성
ck.setMaxAge(60*60*24); // 초 단위로 유효기간 설정
response.addCookie(ck); // 응답에 쿠키 추가
 
Cookie ck2 = new Cookie("id", ""); // 변경할 쿠키와 같은 id를 가지는 쿠키 생성
cookie.setMaxAge(0); // 유효기간을 0으로 설정. 삭제한다는의미
response.addCookie(ck2); // 응답에 쿠키 갱신. id가 같은 쿠키는 브라우저가 새롭게 갱신함.

 

쿠키가 가지는 속성은 다음과 같다.

 

Name : 쿠키의 이름으로, 중복되지 않는다.

Value : 이름에 대응되는 값으로 사용자를 식별할 때 사용한다.

Expire : 쿠키의 유효기간이다. 설정하지 않으면 브라우저를 닫을 때 함께 사라진다.

Path : 쿠키를 사용할 수 있는 URL 경로이다. (도메인의 경로에 따라 쿠키를 제한할 수 있다)

Domain : 쿠키를 사용할 수 있는 도메인을 지정한다. 기본적으로는 쿠키가 생성된 도메인에서만 적용되는게 기본이지만..

구글을 생각해보자. google.com 에 로그인하면 mail.google.com 도메인에도 로그인을 유지할 수 있다.

이렇듯 서브 도메인을 설정할 때 사용한다. 

 

 

세션은 서버 측에서 보관하는 사용자의 상태이고, 서버는 브라우저마다 세션을 독립적으로 생성하고 관리한다.

 

클라이언트가 서버에 처음 접속할 때 서버는 사용자를 식별하기 위해 고유한 세션 ID를 생성하고 클라이언트에게 전달한다. (세션 ID는 쿠키 형태로 클라이언트의 브라우저에 저장된다)

 

클라이언트에 저장되는 쿠키는 보안에 취약하기에 민감한 정보는 서버에서 세션 형태로 저장하고, 세션을 인식할 수 있는인식자를 쿠키 형태로 저장하는 방식이다.

 

세션은 기본적으로 메모리에 저장하고, 클라이언트가 서버에 연결하는 동안에만 유지하는 방식을 사용한다.

 

하지만 상황에 따라 데이터베이스에 세션을 저장해 분산 시스템에서 세션 정보를 공유하거나 Redis같은 외부 저장소에 세션을 저장해 데이터의 지속성과 성능을 끌어올리기도 한다.

 

JSESSION 이라는 키를 가진 쿠키는 특정 웹사이트에서 하나만 존재할 수 있고, 해당 쿠키의 값을 통해 세션을 식별한다. 

 

 

 

 

 

HTTP 헤더를 통해 쿠키를 전달하는 경우도 있지만, 브라우저에서 쿠키 생성을 차단하는 경우 브라우저가 서버에 응답할 때 URL에 세션 ID를 붙여서 함께 전송하기도 한다. 

 

세션은 서버에 부담을 줄 수 있으니 웹 사이트에서 세션이 필요하지 않는 부분은 세션을 제거하자. 

 

 

 

 

2. 확장 가능성

 

 

 

위와 같이 HTTP 응답 메세지가 주어질 때 헤더 부분에서 서버와 클라이언트간의 약속을 통해 원하는 내용을 추가해서 통신 할 수 있다. 

 

브라우저에서 URL을 입력할 때, 실제로는 위와 비슷한 형식의 HTTP 요청 메세지를 만들어 서버에게 전송한다.

서버는 요청 메세지를 기반으로 헤더와 바디로 구분된 HTTP 응답 메세지를 만들어 클라이언트에게 전송한다.

 

 

 

 

최상단에서 HTTP/1.1 200 OK 는 HTTP 1.1로 통신했음을 의미하고, 요청에 대한 결과가 200임을 의미한다.

 

200번대가 나오면 성공, 300번대가 나오면 다른 URL을 요청, 400번대와 500번대는 오류이다

100번대는 새로 추가된 부분인데, 정보 교환을 목적으로 하는 번호이다.

 

 

요청 메세지에는 GET과 POST가 대표적이다.

 

 

 

 

 

GET 방식은 서버에게 리소스를 가져오는 역할을 해 바디가 없어도 되고, URL의 쿼리스트링으로 데이터를 보낼 수 있다.

POST 방식은 서버에 전송할 데이터를 바디에 저장한다. 

 

두 방식 모두 데이터를 추가로 전송할 수 있는데, GET방식은 소량의 데이터만 전달할 수 있고 URL에 데이터가 노출되니 보안에 취약하다. (쇼핑몰에서 상품에 대한 데이터가 URL에 노출되는 걸 생각하자.)

 

반면에 POST는 데이터를 바디에 저장해 전송할 수 있어 대용량 정보를 전송할 수 있고, 보안에 강하지만 데이터 공유에는 불리한 부분이 있다.

 

(그냥 POST 방식이 보안에 강하지는 않다. HTTP 프로토콜에 암호화를 담당하는 TLS프로토콜을 결합해 HTTP 트래픽을 암호화한 HTTPS 프로토콜을 사용해야 한다)

 

HTTP 프로토콜으로 통신할 때 데이터는 어떻게 전송할까?

 

바이너리 파일은 문자와 숫자로 구성되고, 텍스트 파일은 문자로만 구성된다.

 

간단한 예시로 바이너리 파일로 이루어진 이미지를 메모장으로 연다고 생각해보자. 바이너리 파일에서 숫자에 해당하는 부분은 텍스트가 깨져서 나타날것이다.

 

텍스트는 사람이 이해하기 쉽지만, 바이너리 값은 값이 의미를 이해하기 어렵다.

 

 

 

 

텍스트 기반의 프로토콜에서 바이너리 데이터를 전송하기 위해 MIME (Multipurpose Internet Mail Extensions)이 고안됐다.

 

원래는 이메일에서 텍스트가 아닌 메세지를 전송하기 위해 사용됐는데, 이제는 웹에서도 사용된다.

 

HTTP의 헤더에 사용되며, 데이터를 전송할 때 response.setContentType(" ")에서 MIME타입을 작성해줌으로 전송할 파일의 타입을 알려줄 수 있다.

 

응답 메세지에서는 어떤 파일을 전송하는지 알려주고, 요청 메세지에서는 클라이언트가 어떤 미디어 유형을 받아들일 수 있는지 알려주는 역할을 수행한다.

 

바이너리 데이터를 텍스트 데이터로 변환 할 때는 64진법을 사용한다.

(공통으로 사용하는 문자 체계 64개만을 사용해 안전하지만, 텍스트의 크기가 늘어난다.)

 

즉, 바이너리 데이터를 텍스트 기반인 HTTP프로토콜을 통해 통신하려면 MIME을 사용하거나 64진법을 사용해야 한다.