IT & Tech

Session, TCP, RSA, RFC, JWT

완두완두콩 2022. 8. 2. 15:42

 

 

세션

처음 서버에 Get 으로 요청을 하면, 서버는 header 에 세션ID 를 담아서 웹 브라우저에

다시 리턴해준다.

다시 한번 Get 으로 요청하는 경우, 갖고 있는 세션 ID 를 함께 서버에 전송해준다.

 

세션 ID 란 무엇인가?

1. 세션 ID 를 이용해서 최초 방문이 아니라는 것을 확인해주기 위함.

2. 서버가 ID를 발급해준 사용자가 맞는지 확인해주기 위함.

 

세션 ID 가 사라지는 경우 :

1. 서버에서 세션을 삭제하는 경우.

2. 사용자가 브라우저를 종료한 경우.

3. 서버에서 특정 시간이 지나면 사라짐.

 

세션은 로그인 요청(인증) 하는 경우에 많이 사용 된다.

 

세션의 동작 방식

1. 서버에 응답요청을 보냄

2. 서버에서 세션ID를 생성함

3. 세션ID 를 담아서 클라이언트에게 보내줌

4. 클라이언트는 웹브라우저에 세션ID 를 저장.

5. 세션ID 를 가지고 다시 서버에 요청

6. 세션 ID 를 확인 후, DB 를 조회해서 일치하는 정보가 있는지 확인

7. 서버의 세션에 user 정보를 저장

8. 클라이언트에서 유저정보를 요청함(세션ID를 가지고)

9. 세션에서 일치하는 세션 ID 를 찾고, 유저 정보를 확인함

10. DB 에서 유저 정보를 찾는다.

11. 유저 정보를 응답해준다.

 

세션의 단점 

 

클라이언트의 수가 많아서 동접자 수가 서버에서 처리 가능한 수보다

많은 경우, 클라이언트가 대기를 해야한다.

그렇기에 서버를 여러개 둬서 하나의 서버가 바쁘면 다른 서버로 보내는 작업

-> 로드밸런싱

 

1. 내가 2번 서버에 접속해서 세션ID 를 생성했는데, 로드밸런싱으로 인해

다른 서버에 접속하게 되면, 해당 서버에는 내 세션 정보가 없으므로 문제가 발생!

그렇기 때문에 로드밸런싱을 무시하고 다시 기존의 서버에 요청하도록 해야함.

 

2. 세션 저장소를 계속 전체 복제를 해서 어떤 서버를 가더라도 문제가 없도록 한다.-> 복잡

 

3. DB 에 세션값을 저장해서 서버에 전송 -> 앞선 문제점들은 해결되지만

DB 는 하드디스크에 저장돼 있기 때문에 

속도 저하가 크다.

-> 메모리(램) 공유 서버를 만들어서 세션값을 저장한다. -> 속도 저하가 없음.

 

TCP

OSI 7 계층 

물리, 데이터, 네트워크, 트랜스포트, 세션, 프레젠테이션, 응용 계층.

TCP 는 신뢰성을 보장해준다. & 속도가 느림 -> Ack 가 올때까지 재전송. -> ex) 비밀번호

반면 UDP 는 속도는 빠르지만, 신뢰성 보장 x -> ex) 전화, 동영상(일부 프레임 소실 돼도 OK)

 

RSA

 

RSA 인증 방식에는 공개키와 개인키가 존재한다.

A -> B 로  정보를 전송하고자 하는 경우, A는 B 의 공개키로 문서를 보낸다.

그럼 B 는 B 의 개인키로 잠금을 풀고 문서를 확인한다.

 

반면, 해커는 B 개인키가 없기 때문에 확인이 불가하다.

공개키는 모두 공개하고 암호화 하고 싶으면 그 공개키로 잠그고,

각자 개인키로 열어본다.

그렇다면 A -> B 로 보내는 경우에 A 의 개인키로 잠그는 것 어떨까?

단, 정보가 유출되어도 된다는 내용이라고 가정을 해보자.

 

A 는 개인키로 B 에게 문서를 전달한다. 

중간에 해커가 탈취해서 공개 되어있는 A 의 공개키로 확인을 해도 문제가 없다.

왜냐하면 유출이 되어도 상관 없으니까.

B는 정상적으로 받은 뒤, A 의 공개키로 열어봄으로써 확인을 할 수 있다.

 

A 가 개인키로 보냄으로써 우리는 A 가 보낸 문서라는 것을 확인할 수 있다.

왜냐하면 개인키는 각자만 가지고 있는 키인데, A 개인키로 문서가 전달됐고,

A 의 공개키로 문서가 열린다면 해당 문서는 A 가 보낸것임에

틀림 없기 때문이다. 

 

공개키 -> 개인키 (암호화)

개인키 -> 공개키 (전자서명)

에서 사용된다.

 

B 의 공개키로 한번 감싸고, A의 개인키로 또 다시 감싸서 정보를 보냈을 경우,

A 의 공개키로 열려고 했는데 열리지 않는다 -> 인증에 문제가 생김 -> A 가 보낸 것이 아님

반면 인증에 성공하면, B 의 개인키로 열어보고, 문서의 내용을 확인할 수 있다.

 

인증과 암호화 문제를 해결할 수 있다. -> RSA 방식.

JWT 는 RSA 를 사용한다.

 

 

RFC

인터넷은 RFC 문서로 만들어져 있다.

RFC 는 일종의 약속.

K 대학에서 어떤 네트워크와 연결하기 위해 특정한 규칙을 만든다.

-> RFC 문서로 만든다.

-> 하나 늘어날때마다 숫자를 1씩 증가

-> 해당 RFC 에 들어가려면 모든 약관에 동의를 해야함

-> 현재에 와서는 동등한 규칙을 통해 문서가 작성되지는 않을 것 이다.

 

JWT 는 RFC 7519 에 만들어진 어떠한 약속이다.

 

JWT

BASE64 로 암호화 해놓음 -> 복호화도 가능 -> 암호의 목적보다는 서명의 목적이 강함

무결성 검증.

header / payload / signature 로 구성

1.서버에서 웹 브라우저로 JWT 전송(header+payload+서버코드)

2. 서버에서 JWT 를 복호화해서 자신이 발급한 JWT 정보가 맞는지 확인

 

저작자표시 비영리 변경금지