[HTTP] HTTP 이해하기 (2) / Session, Cookies, Keep-Alive

서버 개발자에서 웹 기술 개발자가 되기 위한 스텝. HTTP 이해하기 (2)

 

HTTP의 특징은 Connectless & Stateless

- 불특정의 많은 수의 요청을 처리할 수 있는 장점

- 동일한 클라이언트로부터 연속적으로 요청을 받아 처리한다면 연결비용(TCP)이 큰 단점

- 클라이언트의 이전 정보를 알 수 없는 단점

 

Keep-Alive

- 동일한 클라이언트로부터 연속적으로 요청이 있는 경우

ex) keep-alive 하지 않는 경우 : 연속적인 작업에 연결을 맺고 끊는 과정이 각각 들어간다.

요청 A. Client와 Server가 연결을 맺는다. Server가 요청A를 처리한다. Client와 Server의 연결이 끊어진다.

요청 B. A의 결과를 가지고 Client가 Server에 요청을 보낸다. Client와 Server가 연결을 맺는다. Server가 요청B를 처리한다. Client와 Server의 연결이 끊어진다.

- TCP연결에 소모되는 비용을 최소화 하자

- Connection을 한번 맺고 이를 재사용

ex) keep-alive한 경우 

요청 A와 B를 한 연결로 Client와 Server가 연결을 맺는다. Server가 요청A를 처리한다. Client가 요청A의 결과를 가지고 요청 B를 요청한다. Server가 요청B를 처리한다. Client와 Server의 연결이 끊어진다.

- 서버입장에서 연결을 유지하고 있고 있기때문에 어느 순간 가능한 연결을 다 써버릴 수 있고 더이상 연결 요청을 받을 수 없다는 것을 주의

- Keep-Alive 옵션을 사용할 때 몇 초간 유지 될지 or 최대 몇개의 요청을 수용할 것인지 정한다.

ex) Response Header에서 Keep-Alive:timeout=10, max=200와 같이 확인 가능하며 요청마다 max가 하나씩 감소한다. 

 

Cookies

- 클라이언트 로컬에 저장되는 Key/Value로 이루어진 데이터 파일 (크기는 최대 4KB)

- 브라우저가 종료되어도 인증이 유지 가능(쿠키는 파일이므로, 쿠키에 만료기간이 지정된 경우)

- 쿠키는 응답헤더에 담겨 옴

클라이언트 요청 (to 서버) -> 서버에서 쿠키를 생성 -> 응답헤더에 쿠키를 포함 -> 쿠키를 클라이언트 로컬에 보관 -> 클라이언트에서 요청 시 헤더에 쿠키를 포함 -> 서버에서 쿠키를 읽어 정보 획득 (변경 발생 시 응답에 다시 쿠키 포함)

Session

- 사용자 정보를 서버에 저장하는 것이며 접속된 사용자마다 고유 ID를 부여함

- 만료시간을 지정할 수 있으며, 브라우저가 종료되면 세션은 만료 (브라우저 종료가 만료시간보다 우선 시)

클라이언트가 접속 시 서버가 ID발급 -> 클라이언트는 세션 ID 저장 -> 요청 시 쿠키에 세션 ID가 있다면 서버는 이를 기반으로 정보를 조회 -> 작업 처리 및 응답

 - 주로 로그인을 유지 시키는 등에 사용을 함

 

Cookies vs Session

- 어디에 저장이 되는가? Cookies (클라이언트), Session (서버)

- 보안? Session이 보안적인 측면에서 우위에 있음. Cookies의 경우 탈취 혹은 변조의 위험이 있음

- 속도? Cookies가 우위에 있음. Cookies는 즉각적으로 클라이언트에서 제공된 정보를 사용할 수 있지만 Session은 서버에서 조회를 해야함

- 라이프사이클? 

> 브라우저 종료 시 유지 가능? Session은 불가능 Cookies는 가능(파일형태)

> 만료시간과 브라우저 종료에 어떤게 우선 시 되나? Session은 만료시간이 남았어도 브라우저가 종료되면 끝. Cookies는 브라우저 종료 되더라도 Cookies의 만료시간이 충분하다면 유지됨