🔥5 - 네트워크

📌 1. OSI 7 layer

Application   7

Presentation 6

Session       5

🌎 APS

 

Transport

Network

🌎 TN

 

Data Link

Physical

🌎 DP

🔥 7계층 Application 응용 계층

사용자를 위한 인터페이스를 제공. 사용제에게 보이는 유일한 계층

🔥 6계층 Presentation 표현 계층

7계층으로부터 받은 데이터를 디코딩하고, 전송하는 데이터를 인코딩하는 계층

코드간의 번역을 담당해서, 응용 계층으로부터 데이터의 형식 차이때문에 생기는 부담을 덜어주는 역할을 한다.

 

ex) 🌎 메일

한글로 쓴 내용을 네트워크가 이해할 수 있게 변환

 

데이터 암복호화를 하는 계층

🔥5계층 Session 세션계층

양쪽 연결을 관리하고 지속시켜주는 계층

TCP/IP 세션을 생성하고 삭제하는 계층

🔥4계층 Trasnport 전송 계층

TCP란 네트워크 계층 중 전송 계층에서 사용하는 프로토콜

데이터를 전송하고, 전송 속도를 조절한다. 전송 중 발생한 오류 역시 처리한다.

전송 계층은 포트 번호를 통해 도착지에까지 도달할 수 있게 한다.

 

🌎 TCP 계층

IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리한다.
https://gmlwjd9405.github.io/2018/09/19/tcp-connection.html

 

- IP 프로토콜의 한계

 

비연결성

- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 전송

비신뢰성

- 중간에 패킷이 유실될 수 있음

- 패킷이 순서대로 안 갈수 있음

프로그램 구분 불가

- 같은 IP를 사용하는 서버에서 통신하는 App이 2개 이상이면?

 

해결책 : 🌎 TCP

1. 연결지향 : TCP 3 way handshake

2. 신뢰성 ( 데이터 전달 보증 )

3. 순서보장

 

🌎 UDP

IP와 거의 같다. PORT + Checksum 정도만 추가. TCP에 비하면 하얀 도화지임.

데이터 전달 및 순서는 보장되지 않지만 단순하고 속도는 빠르다.

🔥 3계층 Network Layer 네트워크 계층

데이터를 목적지까지 경로를 찾아 전송하는 계층

목적지의 주소(IP)를 통해 데이터가 전송될 경로(Route)를 선택한다. ( = Routing )

이러한 동작을 하는 장비를 Router라고 한다.

데이터를 해당 네트워크와 연결된 다른 네트워크를 통해 전달함으로써 인터넷이 가능하도록 만드는 계층.

🔥 2계층 Datalink Layer 데이터링크 계층

두 개의 직접 연결된 노드 사이의 노드 간 데이터 전송을 제공한다.

Point to Point간 신뢰성 있는 전송을 보장하기 위한 계층

물리적으로 할당받은 주소를 사용하는데, 이 주소를 MAC주소라고 하며, Datalink Layer에서는 MAC주소를 갖고 통신한다.

🌎 MAC 주소

네트워크 카드 하드웨어에 부여되는 고유한 물리주소

 

데이터 링크층에서는 스위치라는 장비를 통해 목적지 MAC 주소의 장비로 data를 전송한다.

노란색 박스 = 스위치

🔥 라우터 & 스위치

🌎 라우터

IP 주소를 통해 경로를 찾는 장비

네트워크 주소가 다른 서로 다른 장비들을 연결할 때 사용한다.

 

🌎 스위치

MAC 주소를 통해 data를 해당 장비에 전송하는 장비

MAC주소와 Port번호가 기록된 Mac Address Table을 가지고 data를 전송할 기기를 찾는다.

 

🌎 IP주소 뿐 아니라 MAC주소도 필요한 이유

( IP주소와 MAC주소는 모두 고유한 주소이다. )

먼저 공인IP, 사설 IP에 대해서 알아보자. IP주소는 공인 IP와 사설 IP로 나눌 수 있다.

기존에 사용하던 IPv4는 32비트 길이의 식별자로 최대 12자리 번호로 이루어져 있다. 그러나 인터넷 사용자가 급증함에 따라 IPv4주소가 고갈되기 직전에 이르러 버렸다. 이 문제를 해결하기 위해 IPv6, 128비트 길이의 식별자가 등장했다.

사설 IP도 위와 같은 맥락에서 등장한 IP다.

https://velog.io/@hidaehyunlee/%EA%B3%B5%EC%9D%B8Public-%EC%82%AC%EC%84%A4Private-IP%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

사설 IP주소만으로는 인터넷에 직접 연결할 수 없다. 라우터를 통해 1개의 공인 IP만 할당하고, 라우터에 연결된 개인 PC는 사설 IP를 각각 할당받아 인터넷에 접속할 수 있다.

 

사설 IP를 할당받은 핸드폰이나 노트북 등이 라우터에 Data packet을 보내면, 라우터가 해당 사설 IP를 공인 IP로 바꾸어서 해당 ISP(인터넷 서비스 공급자)에게 전송한다. 

https://velog.io/@wonhee010/OSI-7%EA%B3%84%EC%B8%B5-TCPIP-4%EA%B3%84%EC%B8%B5%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C

🔥 1계층 : Physical 물리계층

비트 단위의 data를 물리적으로 전송하기 위해 전기적 신호로 변환하는 계층

🔥 TCP/IP 4계층

OSI 7계층이 시스템의 연결을 위한 모델이라면

TCP/IP 4계층은 웹 서비스에 맞게 단순화 시킨 모델이다.

 

위에 3개 묶고, TCP - IP - 밑에 2개

Application

Transport

Internet

Network Interface

📌2. MTU 란

Packet 또는 Frame기반의 Network에서 전송될 수 있는 최대 크기의 Packet 또는 Frame

 

TCP는 어떠한 전송에서라도 각 패킷의 크기를 결정하는데 있어 MTU를 사용한다.

MTU가 너무 크면 커다란 크기의 패킷을 처리할 수 없는 라우터를 만났을 때 재전송해야 하는 문제를 맞이할 수 있다.

이와 반대로 너무 작으면, 상대적으로 헤더 송수신 확인이 많은 자원이 들어가기 때문에 오버헤드가 커진다.

📌3. 3way hand shake - 4way hand shake

🔥 3 way hand shake

TCP를 이용하여 통신하기 위해 네트워크 설정을 하는 과정이다.

TCP연결을 초기화 할 때 사용한다.

1. Client는 Server에게 연결하고 싶다는 의미로 SYN 패킷을 보낸다. 이 때, Client는 SYN/ACK 패킷을 기다리는 SYN_SENT 상태가 된다.

 

2. SYN 신호를 받은 Server는 Client에게 요청을 수락한다는 ACK와 SYN flag가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이 때, 서버는 SYN_RECEIVED 상태가 된다.

 

3. Client가 Server에게 ACK를 다시 보내면 연결은 이루어진다. 이 때 서버의 상태는 Established가 된다.

 

이와 같이 신뢰성 있는 연결을 맺어주는 것이 TCP 3 way hand shake이다.

🔥 4 way hand shake

세선을 종료할 때 사용한다.

1. Client가 연결을 종료하겠다는 FIN flag를 전송한다.

 

2. Server는 일단 알았다는 ACK 신호를 보내고, 자신의 통신이 끝날 때까지 기다린다. 이 상태는 TIME_WAIT 상태이다.

 

3. Server의 App이 종료될 준비가 됐으면, 종료됐다고 Client에게 FIN flag를 보낸다.

 

4. Client는 알았다고 ACK 메세지를 보낸다.

https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake

📌 4. www.google.com  을 쳤을 때 일어나는 일

내 블로그
https://velog.io/@camel-man-ims/CS-%EA%B8%B0%EB%B3%B8%EC%A0%95%EB%A6%AC1-URL%EC%9D%84-%EC%B9%98%EB%A9%B4-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC

📌 5. HTTP Protocol

인터넷(웹) 환경에서 서버와 클라이언트가 data를 주고받을 수 있는 프로토콜

HTTP protocol은 일반적으로 TCP/IP 위에서 동작하며, 기본 포트는 80번이다. HTTPS는 443번.

 

HTTP는 🌎 비연결성(Connectionless)과 🌎 무상태성(Stateless)를 갖는다.

요청이 일어나서 응답이 일어나면, 후에 연결을 끊어버린다.

기본적으로는 자원 하나에 대해서 하나의 연결을 만든다.

 

장점으로는 연결을 지속적으로 유지하지 않아도 되기 때문에 자원의 효율성이 극대화되지만, Client의 이전 상태를 알 수 없게 된다면 해당 정보를 초기화해야 하는 문제가 생긴다. HTTP는 Cookie를 사용해서 이 문제를 해결하고 있다.

🔥 Cookie

클라이언트와 서버의 상태정보를 담고 있는 정보조각

 

로그인을 예로 들자면, Client가 Login에 성공하면 Server는 로그인 정보를 자신의 Database에 저장하고 동일한 값을 Cookie형태로 Client에게 전송한다.

Client는 다음번 요청시 Cache된 정보인 Cookie를 보냄으로써 같은 요청을 두번 보내지 않아도 되게 된다.

🔥 URI

서버에 자원을 요청하기 위한 영문주소

URN은 거의 쓰이지 않고, URI와 URL은 거의 같은 의미로 사용되고, 일반적으로 URL이라고 불린다.

📌6. HTTP vs HTTPS

HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다.

 

HTTPS는 공개키/개인키 암호화 방식을 통해 암호화하고 있다.

 

공개키와 개인키로 암호화하면 개인키로만 복호화 할 수 있다.

개인키로 암호화하면 공개키로만 복호화 할 수 있다.

 

서버는 클라이언트가 요청을 보낼 때 암호화를 하기 위한 공개키를 생성해야 하는데, 일반적으로 인증된 기간(CA. Certifcate Authority)에 공개키를 전송해서 인증서를 발급받고 있다.

 

Client에게 공개키를 주고, 서버가 개인키를 갖고 있으면서 데이터를 주고 받는 방식

 

HTTPS는 암복호화 과정이 필요하기 때문에 HTTP보다 느릴 수 있으나, 오늘날에는 거의 차이가 없을 정도이다.

단순 정보 조회만 하는 사이트의 경우에는 HTTP만 적용돼도 문제없지만, 민감한 데이터가 주고 받을 경우의 수가 있을 시 HTTPS가 적용돼야 한다.

🔥 얄팍한 코딩사전 영상

HTTP의 한계 ->

1. 서버가 진짜 해당 서버인지 모른다.

2. 중간에 사용자의 정보가 탈취될 수 있다.

 

HTTP-> 비공개키 대칭키 방식

 

HTTPS ->

1. 처음에 handshake를 한다.

2. 서버가 클라이언트에게 인증서의 공개키를 보낸다.

3. 클라이언트의 내장 브라우저가 해당 인증서의 공개키를 내장돼있는 CA의 개인키로 푼다.

4. 풀리면 등록된 서버이므로 안전한 것.

5. 처음에 handshake 할 때 주고 받은 데이터로 비공개키, 대칭키를 만든다.

6. 해당 대칭키로 데이터를 교환한다.

https://mangkyu.tistory.com/98
https://www.youtube.com/watch?v=H6lpFRpyl14

📌 7. HTTP 1.0 과 HTTP 1.1 차이

HTTP 1.1의 🔥 특징 3가지

1. 커넥션 유지

2. 호스트 헤더

3. 강력한 인증 절차

🔥1. 커넥션 유지 ( Persisten Connection )

HTTP 1.0은 요청 컨텐츠마다 TCP 세션을 맺어야 한다.

 

이와 다르게 HTTP 1.1은 Persistent의 기능을 이용하여 한 개의 TCP 세션을 통해 여러개의 콘텐츠 요청이 가능하다.

🔥 파이프라이닝 ( Pipelining )

커넥션을 유지할 수 있는 기능때문에 파이프라이닝이 가능하다.

 

1.0버전에서는 각각의 Request마다 Response를 받아야 다음 통신이 가능하기 때문에, Request가 끊어져서 요청이 되지만 1.1버전에서는 Request들이 연속적으로 들어올 수 있다.

🔥 2. 호스트 헤더 ( Host Header )

HTTP 1.0에서는 하나의 IP에는 하나의 Domain만 할당할 수 있다.

도메인의 수 만큼 서버의 개수도 늘어날 수 밖에 없는 구조이다.

 

HTTP 1.1에서는 Host Header의 추가를 통해 Virtual Hosting이 가능해졌다.

가상호스트란 싱글 서버(또는 서버 풀)에서 여러 개의 도메인 이름으로 호스팅하기 위한 방법
https://seokbeomkim.github.io/posts/vhost-host-header/

🔥 3. 강력한 인증 절차

header에 proxy 관련 헤더가 추가됨으로써 인증절차가 강화됐다.

글 출처  
https://withbundo.blogspot.com/2021/02/http-http-10-http-11.html

📌 8. HTTP 2 특징

2015년에 발표된 HTTP 1.1 차기버전

 

기존에 Plain Text(평문)을 사용하고, 개행으로 구분되던 HTTP/1.x 프로토콜과는 달리 2.0에서는 바이너리 포멧으로 인코딩 된 Message, Frame으로 구성된다.

Frame : HTTP/2 에서 통신의 최소단위

각 프레임에는 하나의 Frame Header가 포함된다.

 

Stream > Message > Frame 순으로 구성된다고 생각하면 될 것 같다.

🔥 주요 특징

🌎 1. 파일전송

HTTP/1.1 까지는 한 번에 하나의 파일만 전송이 가능했다. 이로 인해 여러 파일을 전송할 경우, 선행 파일의 전송이 늦어지면 파일 전체의 전송이 늦어지는 현상이 발생했다.

 

HTTP/2는 여러 파일을 한 번에 병렬 전송을 할 수 있도록 변화하여 이런 현상을 개선했다.

 

🌎 2. Stream 우선순위

HTTP 메세지가 많은 프레임으로 분할될 수 있고, 여러 스트림을 다중화 할 수 있게 되면서 스트림들의 우선순위를 지정할 필요가 생겼다.

 

Client는 우선순위 지정을 위해 우선순위 지정 트리를 사용하여 서버의 스트림처리 우선순위를 지정할 수 있다.

Server는 우선순위가 높은 Client에게 우선적으로 전달될 수 있도록 대역폭을 설정한다.

https://velog.io/@taesunny/HTTP2HTTP-2.0-%EC%A0%95%EB%A6%AC

📌 9. HTTP Header 구조

🔥 1. 일반 헤더

 

요청/응답이 생성된 날짜 같은 일반적인 정보가 포함된다.

 

🔥 2. 요청/응답 헤더

 

서버에 요청하면 요청헤더, 서버가 해당 요청에 응답하면 응답헤더가 있다.

 

요청 헤더에는 요청한 URL, 메서드(POST,GET,PUT,DELETE) 같은 정보들이 포함된다.

브라우저라는 용어는 User-Agent 라고도 하는데, 이런 정보들이 헤더에 들어가는 것이다.

 

응답 헤더는 서버의 기타 정보를 포함한다.

 

🔥 3. 엔티티 헤더

 

HTTP 본문에 대한 정보가 포함된다. 컨텐츠 길이, 언어, 인코딩, 만료날짜 등 본문에 대한 기타 정보들이 포함된다.

https://blueyikim.tistory.com/1999

📌 10. Keep-Alive란

HTTP 특성상 커넥션을 유지하지 않지만, keepAlive를 설정하면 커넥션을 유지하게 된다. 단, 서버는 연결할 수 있는 소켓이 정해져 있기 때문에 연결을 오래 유지하면 다른 사람이 연결을 하지 못할 수 있다. 하지만 소수의 사람들이 이용할 경우 해당 소수의 사람들은 빠르게 인터넷을 이용할 수 있게 된다.

https://hamait.tistory.com/341

📌 11. Cookie - Session

HTTP는 비연결성과 무상태성을 갖고 있는데, 이로 인해 약점이 생긴다. 이 두가지 특성을 보완하기 위해 Cookie와 Session을 사용한다.

🔥 Cookie

1. 쿠키는 클라이언트(browser) Local에 저장되는 Key와 value가 들어있는 작은 data file이다.

2. 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송한다.

3. Cookie 덕분에 매번 인증을 하지 않아도 된다.

🔥 Session

1. 세션 역시 쿠키기반 이지만, 사용자 정보 파일을 Client가 관리하는 Cookie와 달리, Session에서는 Server가 관리한다.

2. Client를 구분하기 위해 Client마다 Session ID를 부여하며, Client Broswer가 해당 사이트를 종료할 때까지 인증상태를 유지한다.

3. Cookie보다 보안에 뛰어나지만 사용자가 많아질수록 서버의 메모리를 많이 차지하게 된다.

 

🌎 Session 동작방식

1. Client가 Server에 접속해서 Session ID를 발급받는다.

2. Client는 Cookie에 Session ID를 저장한다.

3. Client는 Server에 접속할 때 해당 쿠키의 Session ID를 Server에 전달한다.

4. Server는 전달받은 Session ID를 보고 Client를 식별한다.

https://interconnection.tistory.com/74

📌 12. 웹 브라우저가 서버를 통해 사용자에게 보여주기까지

www.google.com  을 예로 들어보자.

 

google.com 에 접속하면 index.html을 받아온다. index.html 안에는 여러 파일이 있는데, 예를 들어 로고 파일인google.png 파일이 있다. 웹 브라우저는 html을 읽을 때 image나 video등 같은 파일이 있으면 해당 url에 파일을 요청한다. 

 

이런 요청을 하는 과정을 '트랜젝션' 이라고 하는데, 요청을 받고, 보내는 하나의 일련 단위를 http 트랜젝션이라고 부른다. 위 google.com 을 방문했을 때, 여러 개의 트랜젝션이 일어나게 된다.

 

좀 더 자세히 설명해보자.

1. google.com 에 들어왔고, index.html을 통해 google.png가 필요하다는 것을 인지했다.

2. url을 이용해 서버의 ip를 추출하고, HTTP 메세지를 만들어서 해당 ip에 필요한 이미지인 google.png에 대한 GET요청을 보내기 위한 준비를 한다.

3. 클라이언트와 서버는 TCP connection을 맺고, Client는 Server에게 HTTP 요청을 보낸다.

4. 서버는 파일을 찾아서 StatusCode와 함께 Client와 TCP connection을 한다음 HTTP 응답을 한다.

https://krksap.tistory.com/1148

🔥 GET - POST 차이

GET은 자료를 요청할 때 사용하고, POST는 내용을 담아서 요청을 보낼 때 사용한다.

GET은 body가 없고, post는 body가 있다.

📌 13. CORS란?

Cross Origin Resouse Sharing : 교차 출처 자원 공유

 

웹 상에서 서로 다른 Origin에서 자원(Resource)를 공유할 수 있도록 하기 위해 놓은 정책

🌎 Origin = Domain 혹은 port를 의미

🔥 CORS 등장배경

Same-Origin-Policy (SOP) 때문.

 

🌎 SOP : 웹 브라우저 보안을 위해 프로토콜, 호스트, 포트가 동일한 서버로만 ajax요청을 주고받을 수 있도록 하는 정책

 

하지만 SPA(Single Page Application)이 등장하면서 Client와 Server의 Domain을 따로 유지하는 경우가 생겼다. 또한 외부 API를 앱 내에 연동하는 경우, 앱과 외부의 API가 다르기 때문에 SOP에 영향을 받아 자원공유를 할 수 없는 상황이 생긴다.

 

기본적으로 HTML은 CORS정책을 따르도록 돼있다. 따라서 추가적인 설정 없이도 HTML <link> tag를 통해 다른 HTML문서로 이동하거나, css 파일 정보를 가져오는 것이 가능한 것이다.

 

하지만 <script> tag 내에 있는 HTTP 요청 ( XMLHttpRequest, FetchApi ) 등은 기본적으로 SOP를 따르도록 돼있다. 따라서 따로 CORS정책을 허가하는 정책들을 추가해주어야 다른 Origin과의 자원 공유가 가능하다.

https://yeoulcoding.tistory.com/96

📌 14. 멱등 - 안전

HTTP 메서드 속성

1. 안전

2. 멱등

3. 캐시가능

🔥 안전

GET만 안전 ( CRUD 중에서는 )

🔥 멱등

한번 호출하든 , 100번 호출하든 결과가 똑같다.

 

GET : 조회이기 때문에 똑같다.

PUT : 결과를 대체하기 때문에 결과가 똑같다.

DELETE : 삭제하기 때문에 똑같다.

 

POST : 멱등이 아니다. 두 번 호출하면 결과가 달라질 수 있다. ( ex) 결제 )

🔥 캐시가능

응답결과를 캐시해서 사용해도 되는가?

 

GET, POST, HEAD, PATCH가 가능하지만, 실제로는 GET과 HEAD 정도만 사용. 

 

POST와 PATCH는 구현이 쉽지 않다.

📌 15. Web Server - Web Application Server 차이

🔥 Static pages - Dynamic pages

Web Server는 Static Pages로써 항상 동일한 page를 반환한다.

Dynamic pages는 인자의 내용에 맞게 동적인 contents를 반환한다.

🔥 Web Server

1. 정적인 콘텐츠를 제공하고, WAS거치지 않고 바로 자원을 제공한다.

2. Client의 요청을 WAS에게 보내고, WAS가 처리한 결과를 Client에게 return한다.

( Client는 일반적으로 Web Browser을 의미한다 )

3. Web Server의 예 ) nginx, Apache Server

🔥 Web Application Server (WAS)

1. DB 조회나 다양한 로직을 처리를 요구하는 동적인 콘텐츠를 제공하기 위해서 만들어진 Application Server

2. Application을 수행해주는 Middleware(software engine). Web Container, Servlet Container라고도 불린다.

( Container란 JSP, Servlet을 실행시킬 수 있는 Software를 의미한다 )

3. WAS = Web Server + Web Container

4. WAS 의 예 ) Tomcat

🔥 Web Server의 존재이유

web server가 있다면 정적인 파일들을 앞단에서 빠르게 보내줄 수 있다.

 https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

📌 16. Rest API

Representational State Transfer

 

🌎 사전적 정의

자원을 이름(Representational. 자원의 표현)으로 구분하여 해당 자원의 상태(state. 정보)를 주고받는 것

 

- 자원의 표현 : ex) DB의 학생 정보가 자원일 때, 'students'를 자원의 표현이라고 정의

 

🌎 구체적 정의

HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 정보를 주고받는 것

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

📌 17. API Gateway

MSA ( Micro Service Architecture ) 는 큰 서비스를 잘게 쪼개어 개발, 운영하는 아키텍쳐이다. 

 

여러 개로 나뉘어진 Server를 Client에서 각각의 API를 호출한다면 각각의 Server마다 인증 및 인가를 받아야하는 불편함이 있다.

 

또한 퍼져 있는 서버의 수 많은 API를 호출을 기록하고 관리하는 것은 귀찮고 어려운 일인데, 이런 문제점을 해결해 줄 수 있는 것이 API Gateway다.

 

API Gateway는 API 서버 앞단에서 모든 API 서버들의 endpoint를 단일화시켜주는 또 다른 서버이다. API에 대한 인증과 인가를 갖고 있으며 Request의 내용에 따라 Server 내부에 있는 Microservice로 routing 하는 역할을 한다.

https://ideatec.co.kr/APIGateway_view/?idx=6320594&bmode=view

참고자료
https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3API-Gateway-nvk2kf0zbj

📌18. 토큰 인증 방식

토큰 방식은 Access Token 토큰이 탈취되면 역시 취약하다. 그래서 Refresh Token을 발급하고, Access Token을 짧게 가져가는 식으로 설계하는 것이 좋다.

https://cornswrold.tistory.com/503