쿠키와 세션은 웹 클라이언트와 서버를 개발하는 분들 뿐만 아니라 대부분의 개발자분들은 많이 들어본 단어일 거라고 생각합니다.


한 번 정리하고 넘어가야 할 필요가 있는 것 같아서 여러자료를 참고하여 정리해봤습니다.



참고 자료는 맨 아래 기재하였습니다.



그럼 왜 쿠키와 세션이 필요한지 부터 살펴보겠습니다.

HTTP 는 connectionless , stateless 한 특징을 가지고 있습니다.

풀어서 이야기를 해보면

  • Connectionless: 연결되어 있지 않은 상
    • HTTP 통신 프로토콜은 socket 통신과는 달리 연결을 유지하고 있지 않습니다.
    • client는 server에 HTTP request하고 server는 HTTP response를 하고 연결은 끊어집니다.

  • Stateless :state(상태)를 가지고 있지 않음. Server는 client 와 통신이 끝난후 상태 정보를 가지고 있지않습니다.


위와 같은 특징으로 인해 Client는 매번 상태를 처음부터 다시 서버에게 알려야 하는 상황이 된다면 

구현하는 측면에서나 성능 측면에서 리소스를 낭비하게 된다는 문제가 발생합니다.


HTTP 에서는 이러한 문제를 해결할 방법으로 제시된 방법이 쿠기와 세션입니다.


먼저, 쿠키는 

쿠키란?(from 위키백과)

쿠키(cookie)란 하이퍼 텍스트의 기록서(HTTP)의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일을 일컫는다. HTTP 쿠키, 웹 쿠키, 브라우저 쿠키라고도 한다.

여기서 주목해야 할 부분은 '사용자의 컴퓨터에 설치되는 작은 기록 정보 파일’ 입니다.

위의 말은 데이터의 저장위치를 나타내는데 이것이 쿠키와 세션의 가장 큰 차이 중 하나입니다. (세션은 서버에 정보를 저장) 자세한 비교는 세션까지 살펴보고 비교해 보도록 하겠습니다.


쿠키의 동작 원리

1) 클라이언트가 웹 브라우저의 도메인에 접속

2) 클라이언트가 요청한 웹페이지를 response를 받으면서 쿠키(클라이언트의 상태 정보를 가진 작은 파일)가 사용자의 하드에 저장

3)클라이언트가 해당 도메인에 재방문시 웹 페이지 요청과 함께 쿠키도 함께 전달.


쿠키 구현 예제

header에 Set-Cookie 헤더를 포함시킨다.

cookie는 key-value 쌍의 데이터를 가지고 있다.

Ex ) Set-Cookie: session-id=123645&name=“Jordan”; max-age:86400; 

위와 같이 쿠키를 클라이언트에 response하고, client에서 request시 쿠키를 보내준다면(보내주지 않을 수도 있음) 쿠키 데이터를 통해서 client의 상태를 유지할 수 있다.


쿠키 사용의 예시(무조건 쿠키를 사용했다는 것은 아니고, 쿠키를 이용해서 구현이 가능)

  • 이벤트 팝업 창 (오늘 다시 보지 않음)
  • 쇼핑몰의 장바구니 기능

쿠키 단점
  • 사용자의 상태 데이터가 로컬에 저장됨으로 조작될 가능성이 있음.
  • 도메인 당 저장할 수 있는 쿠키의 양이 정해져 있음.



그 다음으로 세션을 살펴보겠습니다.


(Http) 세션이란?

서버에서 웹 클라이언트에 ID를 발급해주고 서버에 해당 ID 에 대한 상태를 저장하여서 client의 상태를 유지하는 방법

세션의 동작 원리

- 서버에서 세션 ID를 클라이언트가 해당 웹 사이트에 접속 시 발급.
- 서버에서 http response의 쿠키를 사용해서 client에 전달.
- 클라이언트에서 다시 요청을 할 때 세션 id 값을 전달하면, 서버에서 id를 통해 client의 상태 정보를 가져옴

세션의 장점

- 각 클라이언트에게 고유한 id를 발급하여 구분 할 수 있음. (쿠키의 경우 데이터를 로컬에서 가지고 있기 때문에 구분할 수 없음)
- 각 클라이언트의 요구에 맞게 서비스를 제공
- 보안 측면에서 쿠키보다 우수.

세션의 단점

- 서버에서 session-id 별 상태를 저장해야하기 때문에 해당 id 를 받아서 처리해야하는 리소스와 저장하는 저장 공간 리소스가 필요하게 되서 서버에 무리가 될 수 있음.
- 브라우저를 종료하면 session-id 가 사라질 수 있음 (세션 토큰으로 다시 재발급 받을 수도 있음.)

세션 사용의 예

- 로그인과 같은 보안과 관련된 작업은 세션을 통해 구현.




이제 마지막으로 쿠키와 세션을 비교해도록 하겠습니다.


쿠키와 세션의 비교

가장 큰 차이점은 상태 정보를 저장하는 공간의 위치다. 쿠키는 사용자의 로컬에 세션은 서버에 저장되기 때문에 이것으로 파생되는 장단점이 있다. 또, 세션 같은 경우는 브라우저가 종료되면 라이프 싸이클이 종료 될 수 있지만 요즘은 세션 토큰을 쿠키(로컬에)에 저장해서 session-id를 재발급 받는다.


출처: 제타위키 


추가적으로 내가 자주사용하는 프레임워크들이 제공하는 authentication에 대해서 살펴봐야겠다.

시간이 되는데로 정리해서 블로그에 기록해 보도록 해야겠다!


참고 자료:

블로그

위키백과

제타위키









sticky session 이란 무엇일까?





Sticky session 이란?



먼저 sticky 의 의미 중 하나는 끈적 끈적한, 여간에서 떨어지지 않는 다는 의미가 있다.


어떤 것 과 여간에서 떨어지지 않는 것 일까 ?



바로 요청에 대한 응답을 만드는 웹 서버(AWS 서비스에서 쉽게 예를 들면, EC2) 이다.


영어로는 이렇게 표현을 하는 것을 봤다. 


only single session object will be there.



한국 말로는 껌딱지? 한 서버 인스턴스에만 붙어있는 세션이라고 생각하면 될 것 같다.




머가 문제지? 문제는 다중 서버 구성 시에 발생한다.



sticky session 을 이용하면 AWS Loadbalancer의 경우 traffic 에 따라서 인스턴스에 http request를 분산하여 전달 하기 때문에


A 서버는 session 정보를 가지고 있지만, B 서버는 가지고 있지 않을 수 있는 상황이 발생한다.




이런 경우 로그인 해서 새로고침을 했더니 로그아웃이 되어 버릴 수도 있다.



어떻게 해결해야 할까 ?



먼저 , AWS ELB(elastic load balancer) 를 이용하고 있다면 간단한 설정으로 해결할 수 있다.


쉽게 말해,  sticky하게 해결한다. 만약 a라는 사용자가 x라는 서버에서 응답을 받았다고 하면 x라는 서버에서 계속 응답을 주는 것이다. 


즉, 밀착마크다....! 하지만, load balancer의 기본적인 장점이 조금 상쇄 되기 때문에 조금 아쉬울 수 있지만 괜찮은 해결 방법이다.


관련자료:


https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/elb-sticky-sessions.html



다른 경우 같은 경우는 sticky session 을 복제해서 다른 서버들에게 동기화 해주거나 따로 세션 서버를 구축하는 방법도 있다.


stack over flow에 관련 자료들이 있다.


https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions




간단하게 sticky session의 개념과 관련 문제가 발생했을 때 해결하는 방법에 대해서 기록해봤다.






오늘은 Http에 대해서 공부한 것을 정리해보겠습니다.



1. http란 ? , 2. http method , 3. http 상태 코드

로 구성되어 있습니다.

#### HTTP 란
- (Hypertext Transfer Protocol)의 약자로 web-brower(ie, chrome, safari)와 같은 브라우저를 통해
web-client(사용자와 web-server(서비스 제공자)사이 데이터를 전송하는 프로토콜.

- 특징
1) HTTP는 TCP/IP를 이용하는 응용 프로토콜이다. (컴퓨터와 컴퓨터 사이의 통신)
2) HTTP는 연결 상태를 유지하지 않는 프로토콜이다.
 -> 즉, 요청하면 응답 후 연결을 종료. 전산자원을 적게 사용한다는 장점이 있지만,
 일정 시간 후 다시 요청하면 사용자를 모른다는게 단점. 이를 보완하기위해 cookie, session 등을 이용.



#### HTTP 메서드의 종류

1. GET 요청
- URL이 가진 정보를 검색하기 위해 또는 조회하기 위해 서버 측에 요청을 보냄
ex) 회원 정보, 물품 정보 등.

2. POST 요청
- 서버에 데이터를 전달하기 위해서 요청을 보냄. (폼을 입력할 때 자주 쓰인다.)
ex) 글 포스팅, 회원가입 등.

3. PUT 요청
- 서버에 저장되어 있는 내용을 update, 즉 수정할 때 쓰이는 요청이다.
ex) 프로필 변경, 상품 정보 변경 등.

4. DELETE 요청
- 서버에 저장되어 있는 내용을 삭제할 때 쓰이는 요청이다.
ex) 포스트 삭제, 회원 탈퇴

5. HEAD 요청
- 웹 서버에 헤보 정보이외에는 어떠한 데이터도 보내지 않음. 웹 서버의 다운 여부 점검이나 웹 서버 버전 정보등을
얻기 위해 사용됨.

6. OPTIONS 요청
- 해당 메서드를 통해 시스템에 지원되는 메소드 종류를 확인할 수 있다.

7. TRACE 요청
- 원격지 서버에 Lookback 메시지를 호출하기 위해 사용된다.

8. CONNECT 요청
- 웹 서버에 프록시 기능을 요청 할 때 사용된다.
ex) 카카오톡 봇 proxcy server, 클라이언트 -> 카카오톡 프록시 서버 -> 카카오톡 개인 봇 서버







### HTTP status code 종류

1. 1xx (조건부 응답)

2. 2xx (성공)

   - 200 (성공 서버가 요청을 제대로 처리했다는 뜻)

   - 201 (성공적으로 요청이 되어 서버가 새 리소스를 생성했다.)

3. 3xx (리다이렉션 완료)

4. 4xx (요청 오류)

   - 400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.

   - 401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다.

    상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다

   - 402(결제 필요): 이 요청은 결제가 필요합니다.

   - 403(금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다.

    (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)

   - 404(찾을 수 없음): 서버가 요청한 페이지를 찾을 수 없다.

    예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.

   - 405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다.

   - 408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.


5. 5xx (서버 오류 )

   - 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.


 출처 : 위키백과

감사합니다.


프록시 서버란 무엇인지 간단하게 정의와 


이해를 돕기위해 예시를 통해 설명하도록 하겠습니다.




카카오톡 봇을 만들기 위해 API 문서를 보는데 Proxy Server 프록시 서버주소가 나와있었는데 이게 머지?


라는 생각을 하고, 찾아 본 후 이해를 했었는데...


오늘 또 '프록시 서버' 라는 단어가 나왔는데 기억이 나지 않아.. 다시 찾아보고 간단한게 정리해보려고 합니다.



먼저, 자세한 프록시 서버에 대한 설명이 필요하신분은


간단한 설명을 확인 하신 후 나무위키에서 다시 한 번 내용을 살펴보시는 것을 추천합니다!


https://namu.wiki/w/%ED%94%84%EB%A1%9D%EC%8B%9C%20%EC%84%9C%EB%B2%84



프록시 서버란?


쉽게 말해 IP를 빌려주는 서버입니다.


무슨 소리지 ?


밑의 주소는 카카오톡 봇 API 문서에 나와 있는 카카오톡 봇  프록시 서버입니다.


IP
110.76.143.234 
110.76.143.235
110.76.143.236


왜 IP를 빌려야 되는데 ? 라고 물으실 수 있습니다.



그 이유는 보통 웹 서비스들을 접속 할 수 있는 IP 또는 URL 을 미리 지정해놓습니다.


미리 허용하는 IP를 지정해 놓는 이유는 악성사용자의 의도적인 공격적 요청을 막기 위해서입니다.


예를 들어, Django에서는 ALLOWED_HOSTS config를 통해 허용하는 IP 또는 URL 을 미리 지정해놓습니다.


ALLOWED_HOSTS = ['www.doosikbae.com','110.76.143.234','110.76.143.235','110.76.143.235']



즉 , 이런 요청 구조를 가지게 됩니다. 프록시 서버의 IP를 빌려서 제 api 서버에 요청을 보내는 것이지요!


클라이언트 ( 카카오톡 봇 이용자)  -> 프록시 서버 -> 제 카카오톡 봇 api 서버



이렇게 프록시 서버가 이용되기도 하지만,



"원래 프 록시 서버가 설치된 처음 목적은 웹 서핑을 위시한 인터넷 속도의 향상이었다. 


1990년대 후반까지만 해도 이런 목적으로 사용되었다." 라고 합니다.


- 출처: 나무위키



최근에는 악성 이용자들을 프록시 서버의 아이피를 통해 불법행위를 저지르기도 한다고 합니다...!


관련자료는 나무위키를 찾아보시면 더 자세히 나와있습니다.




프록시 서버에 대해서 대략적인 이해가 되셨나요?





카카오톡 봇 만들기에 관심이 있다면 해당 포스팅에 관련자료가 있습니다.


http://myjorney.tistory.com/41




+ Recent posts