HTTP 특징
Stateless
- 클라이언트와 서버는 서로 상태를 유지하지 않는다.
HTTP는 무상태(Stateless) 프로토콜이다. 이 말은 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다는 뜻이다. 따라서 클라이언트가 재요청했을 때 서버는 이전 요청을 기억하지 못 한다.
Stateful 하면 항상 같은 서버가 유지되어야 한다. 중간에 서버에 장애가 나면? 😱
Stateless 하면 서버가 상태를 보관하지 않기 때문에 아무 서버나 호출해도 된다. 중간에 서버에 장애가 나면? 다른 서버로 요청 보내면 된다.
따라서 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
Stateless는 응답 서버를 쉽게 바꿀 수 있다. ➡️ 무한한 서버 증설 가능 (스케일 아웃)
Connectionless
- 클라이언트가 요청을 한 후 서버가 응답을 받으면 그 연결을 끊어 버린다.
서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 된다.
따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있다.
하지만 서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을 거쳐야하므로 연결/해제에 대한 오버헤드가 발생한다.
이에 대한 해결책으로 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성을 사용할 수 있다.
KeepAlive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기 위해 패킷을 주기적으로 보내는 것이다.
이때 패킷에 반응이 없으면 접속을 끊는다.
주기적으로 클라이언트의 상태를 체크한다는 것을 보면 KeepAlive 역시 완벽한 해결책은 아닌 듯하다.
KeepAlive 속성이 On 상태라고 해도, 서버가 바쁜 환경에서는 프로세스 수가 기하급수적으로 늘어나기 때문에 KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 한다.
이런 HTTP의 특징을 극복하기 위해 Cookie와 Session을 사용한다.
Cookie
-
사용자 로그인 세션 관리, 광고 정보 트래킹
-
쿠키 정보는 항상 서버에 전송되므로 네트워크 트래픽을 추가로 유발한다.
-
쿠키 정보는 웹 브라우저에 저장된다.
-
최소한의 정보만 사용해야 한다. (세션 Id, 인증 토큰)
-
서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(로컬 스토리지, 세션 스토리지)를 사용하면 된다.
-
쿠키는 클라이언트에서 확인이 가능하기 때문에 보안에 민감한 데이터는 저장하면 안 된다.
-
예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
- Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
- Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달
쿠키의 구성요소
- Name (이름): 쿠키를 구별하는 데 사용되는 키 (중복될 수 없음)
- Value (값): 쿠키의 값
- Domain (도메인): 쿠키가 저장된 도메인
- Path (경로): 쿠키가 사용되는 경로
- Expires (만료기한): 쿠키의 만료기한 (만료기한 지나면 삭제됩니다.)
Cookie 생명주기(expires, max-age)
-
Set-Cookie: expires=Sun, 14-Nov-2021 18:10:28 GMT
➡️ 만료일이 되면 쿠키 삭제 -
Set-Cookie: max-age=3600 (3600초)
➡️ 0이나 음수를 지정하면 쿠키 삭제 -
세션 쿠키: 만료 날짜를 생략하면 브라우저가 종료될 때까지만 유지한다.
-
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지한다.
Cookie 도메인(domain)
-
domain=kimkj.shop
-
도메인을 명시하면 명시한 문서 기준 도메인 + 서브 도메인 포함
➡️ kimkj.shop에도 쿠키 접근 + sub.kimkj.shop에도 쿠키 접근 -
도메인을 명시하지 않으면 현재 문서 기준 도메인만 적용된다.
➡️ kimkj.shop에서 쿠키를 생성하고 도메인을 명시하지 않았다면 kimkj.shop에서만 쿠키 접근이 가능하고 서브 도메인인 sub.kimkj.shop에는 쿠키 접근이 되지 않는다.
Cookie 경로(path)
-
path=/main
-
명시한 경로를 포함한 하위 경로 페이지만 쿠키 접근이 가능하다.
-
일반적으로는 path=/ 와 같이 루트로 지정한다.
-
예) path=/main
➡️ /main 가능
➡️ /main/exam1 가능
➡️ /hello 불가능
Cookie 보안(Secure, HttpOnly, SameSite)
-
Secure
➡️ 쿠키는 http, https를 구분하지 않고 전송된다.
➡️ secure를 적용하면 https인 경우에만 전송된다. -
HttpOnly
➡️ XSS(Cross-Site Scripting) 공격을 방지한다.
➡️ 자바스크립트에서 접근이 불가능하다.
➡️ HTTP 전송에만 사용된다. -
SameSite
➡️ XSRF(Cross-Site Request Forgery) 공격을 방지한다.
➡️ 쿠키가 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 전송된다.
Session
-
세션은 쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
-
서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
-
물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능 하다.
-
사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
-
즉, 동시접속자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
-
클라이언트가 요청을 보내면, 해당 서버가 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID이다.
Session 동작 방식
- 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
- 클라이언트는 쿠키를 사용해서 세션 ID를 저장하고 가지고 있다.
- 클라이언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청한다.
- 서버는 세션 ID를 전달 받아서 별다른 작업 없이 세션 ID로 세션에 있는 클라이언트 정보를 이용해 클라이언트한테 응답한다.
| Cookie | Session | |
|---|---|---|
| 설명 | 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일 | 서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용 |
| 저장 위치 | 클라이언트 (웹 브라우저) | 웹 서버 |
| 사용 예 | 사이트 팝업의 "오늘 다시보지 않기" 정보 저장 | 로그인 정보 저장 |
| 만료 시점 | 쿠키 저장 시 만료일시 설정 가능 (브라우저 종료 시에도 유지 가능) | 다음 조건 중 하나가 만족될 경우 만료됨 1. 브라우저 종료 시까지 2. 클라이언트 로그아웃 시까지 3. 서버에 설정한 유지기간까지 해당 클라이언트의 재요청이 없는 경우 |
| 용량 제한 | 브라우저 별로 다름 (크롬 기준) - 하나의 도메인 당 180개 - 하나의 쿠키 당 4KB(=4096byte) | 개수 제한 없음 (단, 세션 저장소 크기 이상 저장 불가능) |
| 보안 | 취약 (클라이언트에서 쿠키 정보를 쉽게 변경, 삭제 및 가로채기 당할 수 있음) | 비교적 안전 (서버에 저장되기 때문에 상대적으로 안전) |
출처
RyanGomdoriPooh. “쿠키와 세션 개념.” Ryan Server, TISTORY, 31 Oct. 2021, https://interconnection.tistory.com/74.
우르르응 Victolee. “[HTTP] HTTP 특성(비연결성, 무상태)과 구성요소 그리고 Restful API.” Victolee, TISTORY, 16 Sept. 2019, https://victorydntmd.tistory.com/286.
인프런 “모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한님”, https://inf.run/rUYK.
