[컴퓨터공학] 네트워크

• 네트워크 개념을 정리한 것으로 내용은 추가될 예정입니다.
   

1. TCP와 UDP
2. TCP의 3-way-handshake와 4-way-handshake
3. HTTP Method
4. HTTP 멱등성
5. HTTP Keep-Alive
6. HTTP와 HTTPS
7. 웹사이트 동작 과정
8. REST API
9. URI vs URL vs URN
10. 쿠키와 세션
11. JWT 토큰 기반 인증
12. OAuth

 

---

TCP와 UDP

1. TCP

TCP(Transmission Control Protocol)는 인터넷 상에서 데이터 전송의 신뢰성을 보장하기 위한 프로토콜로, OSI 모델의 전송 계층(Transport Layer)에 속한다. TCP는 양 끝단이 연결되어 있어야 데이터 전송이 가능한 연결형 프로토콜이다. TCP에서는 소켓(Socket)을 사용하여 논리적인 연결을 성립하고, 데이터를 세그먼트(Segment) 단위로 분할하여 전송한다. 이때 연결 설정은 3-way-handshake 과정을 통해 이루어지며, 각 소켓은 고유한 IP 주소와 포트 번호를 가지고 있다.

TCP는 안정적인 데이터 전송을 위해 오류 제어와 흐름 제어 기능을 제공한다. 오류 제어는 전송 중에 발생할 수 있는 오류를 검출하고 복구하는 기능으로, 에러 검출코드를 사용하여 오류를 검출하고 재전송을 통해 데이터 손실을 최소화한다. 흐름 제어는 수신측이 처리할 수 있는 만큼만 데이터를 전송함으로써, 수신측에서 발생할 수 있는 과부하를 방지하는 기능이다. 또한 TCP는 유니캐스트(Unicast) 방식으로 전송되며, 양 끝단이 동시에 데이터를 전송할 수 있는 전이중(Full-Duplex) 모드로 동작한다.
 
TCP 폭주 제어, 흐름 제어
- 도서 <그림으로 공부하는 IT 인프라 구조> 6장
 

2. UDP

UDP(User Datagram Protocol)는 TCP와 달리 사전에 연결을 성립하는 절차가 없는 비연결형 프로토콜로, 데이터 전송의 신뢰성을 보장하지 않는다. UDP는 실시간 스트리밍처럼 응답 시간에 민감한 서비스나 사내 방송에서 사용되는 멀티캐스트처럼 단방향으로 다수의 단말과 통신하여 응답을 받기 어려운 환경에서 주로 사용된다.

이처럼 UDP는 데이터 전송의 신뢰성보다 신속성을 중요시하기 때문에 전송 중간에 일부 데이터가 유실되더라도 재전송하지 않는다. 그래서 UDP를 사용하는 애플리케이션 대부분은 이런 상황을 인지하고 동작하거나, 연결 성립은 TCP를 이용하고 실제 데이터 전송만 UDP를 이용하는 방식으로 통신을 한다.

UDP를 사용하는 대표적인 애플리케이션 계층 프로토콜에는 DNS가 있다. 일반적으로 DNS 요청(Request) 메세지는 UDP 세그먼트에 들어갈 정도로 크기가 작고, UDP는 사전 연결 성립 절차가 없어 신속하게 작업을 처리할 수 있기 때문에 DNS는 UDP를 이용한다. 하지만 DNS 요청 메세지의 크기가 512 Bytes를 넘으면 TCP를 사용해야 한다.
 
같은 동영상 스트리밍이더라도 넷플릭스나 유튜브와 같이 시간에 민감하지 않은 단일 시청자를 위한 서비스는 TCP를 사용한다. UDP가 아닌 TCP를 사용하는 경우, 원활한 시청을 위해 수 초~수 분의 동영상 데이터를 미리 받아 놓고 네트워크에 잠시 문제가 발생하더라도 동영상이 끊기지 않도록 캐시에 저장해둔다.

(참고)
- 도서 <IT 엔지니어를 위한 네트워크 입문> 3.4
 

---

TCP의 3-way-handshake와 4-way-handshake

1. 3-way-handshake (3방향 핸드셰이크) : 연결 성립

TCP에서는 데이터 유실 없는 안전한 통신을 위해 통신 시작 전, 상대와 3번의 패킷을 주고 받는 사전 연결 작업을 진행한다. 이를 3-way-handshake라고 부른다. TCP는 어떤 패킷이 새로운 연결 성립을 위한 패킷이고 어떤 패킷이 기존 통신에 대한 응답인지를 구분하기 위해, TCP 헤더에 6 비트의 플래그 비트를 사용한다.

 

동작 과정

1. 클라이언트에서 서버로 SYN 패킷(SYN 플래그 비트를 1로 표기한 패킷)을 보낸다. 이때 SYN 패킷에는 랜덤한 sequence number가 포함되어 있다.
2. SYN 패킷을 받은 서버는 SYN과 ACK이 설정된 패킷을 클라이언트에게 보낸다. 이 패킷에는 클라이언트가 보낸 SYN 패킷의 sequence number + 1 값을 갖는 ack number와, 랜덤한 sequence number가 포함되어 있다. ack number가 101이라는 것은 현재 sequence number가 100인 패킷을 받았다는 것을 의미한다.
3. SYN/ACK 패킷을 받은 클라이언트는 서버와의 연결을 확립하기 위해 ACK 패킷을 서버에게 다시 보낸다. 이때 ACK 패킷에는 서버가 보낸 SYN 패킷의 sequence number + 1 값을 갖는 ack number가 포함되어 있다.

 
이와 같은 과정을 거쳐 클라이언트와 서버 간의 연결이 성립된다. 이때 sequence number와 ack number는 각각 데이터의 순서와 도착 여부를 보장하기 위해 사용된다.
 

2. 4-way-handshake (4방향 핸드셰이크) : 연결 해제

모든 통신이 끝나면 TCP에서는 4번의 패킷을 주고 받으며 연결을 해제한다.
 

 

동작 과정

1. 클라이언트에서 서버로 연결 종료를 요청하는 FIN 패킷을 보낸다.
2. FIN 패킷을 받은 서버는 연결 종료 요청를 확인했다는 의미로 ACK 패킷을 클라이언트에게 보낸다. 이후 서버는 전송중인 데이터를 마저 보내기 위해 CLOSE_WAIT 상태가 된다.
3. 데이터 전송이 끝나면, 클라이언트에게 FIN 패킷을 보내 연결이 종료되었음을 알린다.
4. FIN 패킷을 받은 클라이언트는 이에 대한 응답으로 ACK 패킷을 서버에게 보낸다. 이때 클라이언트는 아직 서버로부터 받지 못한 패킷이 있을 경우를 대비해, 상태를 TIME_WAIT으로 변경하고 남은 패킷을 기다린다.
5. 클라이언트로부터 ACK 패킷을 받은 서버는 소켓 연결을 닫고 CLOSED 상태가 된다.
6. TIME_WAIT에 설정된 시간이 끝나면 클라이언트도 소켓 연결을 닫고 CLOSED 상태가 된다.

 
(참고)
도서 <IT 엔지니어를 위한 네트워크 입문> 3.4
 

---

HTTP Method

HTTP(HyperText Transfer Protocol)는 웹 상에서 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜이다. 클라이언트가 HTTP를 통해 서버에게 요청을 보내면 서버는 요청받은 데이터를 클라이언트에게 응답한다. HTTP 요청에 포함되는 HTTP Method는 서버가 수행해야 할 행동을 표시하는 용도로 사용되며, 대표적으로 GET, POST, PUT, PATCH, DELETE가 있다.

1. GET

GET은 서버로부터 데이터를 조회하기 위해 설계된 메서드이다. GET 요청 시 HTTP 요청(Request) 메세지의 Body는 비어있으며, 전송할 데이터가 있는 경우에는 URL 끝에 쿼리스트링(Query String) 형식으로 붙여서 전송한다. 따라서 전송할 수 있는 데이터의 크기에 제한이 있으며, URL에 데이터가 그대로 노출되기 때문에 보안이 필요한 데이터는 GET 방식으로 전송하면 안된다.
 

 
GET 요청 후 응답받은 데이터는 브라우저에서 캐싱(Caching)할 수 있다. 브라우저는 HTML, CSS, JS, 이미지와 같이 크기가 크고 변경될 일이 적은 정적 컨텐츠는 캐시에 저장해두고, 이후 동일한 요청이 들어오면 서버로 요청을 보내는 대신 캐시에 저장된 데이터를 응답해준다. 따라서 브라우저의 캐싱 기능을 이용하면 웹사이트의 응답 시간을 줄이고 서버 트래픽을 감소시킬 수 있다. 프론트엔드 개발을 하다보면 브라우저에 캐싱된 데이터로 인해 정적 컨텐츠의 내용을 변경해도 변경된 내용이 반영되지 않는 문제가 발생할 수 있는데, 이때는 브라우저의 캐시를 지워주면 문제를 해결할 수 있다.

2. POST

POST는 서버에 데이터를 제출하기 위해 설계된 메서드이다. POST 요청 시에는 HTTP 요청 메세지의 Body에 데이터를 담아 보낸다. Body는 길이의 제한 없이 데이터를 담을 수 있기 때문에, POST는 GET과 달리 대용량의 데이터 전송이 가능하다. 하지만 POST 방식도 크롬 개발자 도구와 같은 툴을 이용하면 Body에 담긴 데이터를 확인할 수 있기 때문에, 보안이 요구되는 데이터는 반드시 암호화하여 전송해야 한다.
 

3. PUT

PUT은 서버에 있는 기존 자원을 수정하거나 새로운 자원을 생성하기 위해 설계된 메서드이다. PUT 요청을 한 경로에 자원이 있다면 서버는 해당 자원 전체를 갱신하고, 자원이 없다면 새로운 자원을 생성한다.
 

4. PATCH

PATCH는 PUT과 달리 자원의 일부분만 수정하고 싶을 때 사용한다. 클라이언트가 수정하고자 하는 자원의 일부분만 HTTP 요청 메세지의 Body에 담아 PATCH 요청을 보내면, 서버는 클라이언트가 보낸 데이터를 기존 자원과 병합하여 변경한다. 일반적으로 PATCH는 PUT보다 HTTP 요청 메세지의 Body에 담기는 데이터의 양이 적기 때문에 대역폭을 절약할 수 있다.
 

5. DELETE

DELETE 메서드는 서버에서 특정 데이터를 삭제하기 위해 설계된 메서드이다. 클라이언트에서 삭제하고자 하는 자원의 경로를 지정해 DELETE 요청을 보내면, 서버는 해당 경로에 존재하는 자원을 삭제한다.
 
(참고)
https://brilliantdevelop.tistory.com/33
 

---

HTTP 멱등성

HTTP 멱등성(idempotence)이란 같은 요청을 여러 번 전송해도 서버의 상태가 변하지 않는 특성을 말한다. 즉, 클라이언트가 동일한 요청을 여러 번 전송해도 항상 동일한 결과가 나타난다.

GET 요청은 서버에서 자원(Resource)을 가져오기만 하기 때문에, 같은 GET 요청을 여러 번 전송하더라도 서버의 상태는 변하지 않는다. 따라서 GET 요청은 멱등성을 가지고 있다. 이와 비슷하게 DELETE 요청도 멱등성을 가지고 있다. 같은 DELETE 요청을 여러 번 전송하더라도 서버에서 삭제되는 자원은 항상 같으므로 결과도 항상 동일하다.

반면, POST 요청은 멱등성을 가지고 있지 않다. POST 요청은 서버의 상태를 변경하기 때문에, 같은 POST 요청을 여러 번 전송하면 서버의 상태가 계속해서 변한다. PUT과 PATCH 요청은 멱등성을 가지지만 자원의 상태를 변경하므로, 멱등성을 보장하기 위해서는 클라이언트가 서버의 현재 상태를 정확하게 파악하고 전송해야 한다.
 

---

HTTP Keep-Alive

HTTP는 기본적으로 stateless한 프로토콜이다. 따라서 클라이언트와 서버가 서로 요청과 응답을 주고받기 위해선 연결을 설정하고 끊는 과정이 매번 필요하다. 하지만 이러한 연결 설정 및 끊기 과정은 부담이 되거나 불필요한 경우가 있다. 이에 따라 HTTP/1.0부터는 Keep-Alive라는 기능이 도입되었다.

Keep-Alive는 클라이언트와 서버 간의 연결을 유지하고 재사용하는 기능이다. Keep-Alive 기능을 이용하면 클라이언트와 서버가 요청과 응답을 주고받을 때마다 매번 새로운 연결을 설정할 필요가 없으므로, 연결 설정과 끊기 과정에서 발생하는 부담과 지연을 줄일 수 있다.
 

Keep-Alive는 HTTP/1.0에서는 기본적으로 활성화되어 있지 않기 때문에, 해당 기능을 사용하고자 한다면 Connection 헤더 필드의 값을 "keep-alive"로 설정해야 한다. 하지만 HTTP/1.1부터는 Keep-Alive가 기본으로 활성화되어 있으므로 별도의 설정이 필요하지 않다. 만약 Keep-Alive 기능을 비활성화하고자 한다면 Connection 헤더 필드의 값을 "close"로 설정하면 된다.
 

---

HTTP와 HTTPS

1. HTTP의 문제

HTTP 통신에서는 보안과 관련된 다양한 문제가 발생할 수 있다.
 

1.1 평문이기 때문에 도청 가능

HTTP에는 통신 내용을 암호화하는 기능이 없기 때문에 평문(암호화하지 않은 메세지)으로 HTTP 메세지를 전송하게 된다. 따라서 도청 가능한 TCP/IP 네트워크를 흐르는 HTTP 메세지는 경로 도중에 도청될 가능성이 존재한다.
 

[해결책]

이와 같은 도청 문제는 암호화를 통해 해결이 가능하다. 암호화에는 그 대상에 따라 몇 가지 방법이 존재한다.
 
1) 통신 암호화
HTTP 프로토콜에 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)와 같은 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화할 수 있다. 이와 같이 SSL을 조합한 HTTP를 HTTPS(HTTP Secure) 또는 HTTP over SSL이라 부른다. 통신 전, 먼저 SSL 등을 이용해 안전한 통신로를 확립하고 나서 HTTP 통신을 하면 도청 문제를 방지할 수 있다.
 
2) 콘텐츠 암호화
통신하고 있는 콘텐츠 내용 자체를 암호화하는 방법이다. 메세지 헤더(Header)는 암호화되어 있지 않으며, 메세지 바디(Body)에 들어가는 내용을 암호화한다. 콘텐츠 암호화 방식을 이용하면 클라이언트와 서버에서는 암호화된 HTTP 메세지를 복호화하는 작업이 필요하게 된다.
 

1.2 통신 상대를 확인하지 않기 때문에 위장 가능

HTTP 통신에서는 상대가 누구인지 확인하지 않기 때문에 누구든지 요청을 보낼 수 있으며, 서버는 요청한 클라이언트가 누구이던 간에 응답을 보내게 된다. 따라서 이와 관련된 여러 문제가 발생할 수 있다.
 

• 응답을 보낸 웹 서버가 원래 의도한 웹 서버인지 아닌지 확인할 수 없다.
• 응답을 받은 클라이언트가 원래 의도한 클라이언트인지 아닌지 확인할 수 없다.
• 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지 확인할 수 없다.
• 어디에서 누가 요청을 보냈는지 확인할 수 없다.
• 의미없는 요청이더라도 수신하기 때문에, 대량의 요청에 의한 DoS 공격을 방지할 수 없다.

 

[해결책]

이 문제 또한 SSL을 이용해 해결할 수 있다. SSL은 암호화뿐만 아니라, 증명서를 통해 통신 상대를 확인하는 기능을 제공한다. 증명서는 신뢰할 수 있는 제 3자에 의해 발행되며, 증명서를 위조하는 것은 기술적으로 상당히 어렵다. 통신에 참여하는 클라이언트나 서버는 상대가 가진 증명서를 통해 자신이 통신하고자 하는 상대가 맞는지 확인할 수 있다.
 

1.3 완전성을 증명할 수 없기 때문에 변조 가능

HTTP는 완전성(정보의 정확성)을 증명할 수 없기 때문에, 정보의 변조 여부를 알 수 없다. 즉, 원래 발신한 정보와 수신한 정보가 같은지 아닌지 확인할 수 없다.
 

[해결책]

이와 같은 문제의 해결책으로 MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재한다. 하지만 해시 값이나 서명 자체도 적절히 수정되어 있다면 유저로서는 알 수가 없기 때문에, 이 방법 또한 변조를 확실히 방지할 수 있는 것은 아니다. HTTPS를 이용하면 변조 문제를 확실히 방지할 수 있다.
 
 

2. HTTPS

HTTP에 암호화와 인증, 완전성 보장 등의 기능을 더한 것을 HTTPS라고 부른다. HTTPS는 애플리케이션 계층의 새로운 프로토콜이 아니라, HTTP 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체한 것이다. 80번 포트를 사용하는 HTTP와 달리 HTTPS에서는 443번 포트를 사용한다.
 

 
HTTP는 TCP와 직접 통신하지만, SSL을 사용하면 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL은 HTTP와 독립된 프로토콜이기 때문에 HTTP뿐만 아니라 SMTP, Telnet 등 보안이 필요한 다른 애플리케이션 계층 프로토콜에서도 이용될 수 있다.

HTTPS는 메세지 암호화를 위해 대칭키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호화 방식을 사용한다. 공개키 암호화 방식은 대칭키 암호화 방식보다 처리 속도가 느리기 때문에, 대칭키를 교환하는 곳에서만 공개키 암호화 방식을 사용하고 메세지는 대칭키를 이용해 암호화한다.
 

 
 

3. 모든 웹 페이지에 HTTPS를 사용해도 괜찮은가?

평문 통신에 비해 암호화 통신은 암호화와 복호화 계산 작업으로 인해 CPU나 메모리 등의 하드웨어 자원이 많이 필요하다. 또한 HTTPS는 HTTP와 TCP 사이에 SSL이 추가된 것이기 때문에, SSL 통신만큼 네트워크 자원을 더 소비하게 되어 HTTP에 비해 2~100배 정도 느려질 수 있다.

하지만 최근에는 하드웨어가 발달하여 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용하면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하던 방식에서 현재 모든 웹 페이지에 HTTPS를 적용하는 방향으로 바뀌어가고 있다.
 
(참고)
- 도서 <그림으로 배우는 Http & Network Basic>
 

---

웹사이트 동작 과정

1. 사용자가 브라우저에서 웹 사이트의 URL을 입력하거나, 링크를 클릭한다.
2. TCP/IP 통신을 위해서는 반드시 IP 주소를 알아야 하기 때문에, URL에 포함된 웹 서버의 호스트명을 DNS 서버에 질의하여 웹 서버의 IP 주소를 구한다.
3. DNS 서버로부터 받은 IP 주소를 이용해 웹 서버에 접근하여 TCP 연결을 맺는다. 이때 브라우저와 웹 서버는 3-way-handshaking 과정을 거쳐 연결을 맺는다.
4. TCP 연결이 성립되면, 브라우저는 웹 서버에게 HTTP 요청(Request) 메세지를 전송한다. HTTP 요청 메시지에는 GET, POST 등의 HTTP 메서드와 URL, HTTP 버전, 요청 Header 등이 포함된다.
5. 클라이언트로부터 요청을 받은 웹 서버는 해당 요청을 처리하고, 그 결과를 HTTP 응답(Response) 메세지에 담아 브라우저에게 전송한다. 응답 메세지에는 요청받은 HTML, CSS, 자바스크립트 코드 또는 JSON 데이터 등이 포함된다.
6. 브라우저는 응답받은 데이터를 사용하여 웹 페이지를 렌더링한다. HTML 코드를 파싱하고, CSS 스타일을 적용하고, 자바스크립트를 실행해 동적인 기능을 구현한다.
7. 웹 페이지 렌더링이 완료되면, 브라우저와 웹 서버는 TCP 연결을 해제한다.

 
(참고)
- 도서 <그림으로 배우는 네트워크 원리> 4.12
 

---

REST API

REST API는 REST 아키텍처를 따르는 API를 의미한다.
 
REST(Representational State Transfer)는 서버의 자원(Resource)에 대해 어떤 동작(Verb)을 수행할 것인지 구체적으로 명시하는 아키텍처로, HTTP 프로토콜을 기반으로 한다. REST 아키텍처를 사용하면 클라이언트와 서버 간 통신이 효율적이고 일관성 있게 이루어진다.
 
API(Application Programming Interface)는 프로그램이 서로 상호작용하기 위한 인터페이스를 의미한다. 클라이언트와 서버가 상호작용(통신)하기 위해서는 이를 연결하는 인터페이스가 필요한데, API가 이를 담당한다.
 

따라서 REST API는 서버의 자원에 대해 수행할 동작을 나타내는 방식으로 설계된 API이다. 이때 서버의 자원은 URI를 통해 식별하고, 수행할 동작은 HTTP 메서드(GET, POST, PUT, PATCH, DELETE 등)를 이용해 나타낸다.

REST API에서 중요한 것은 각 요청이 어떤 자원이나 동작을 위한 것인지 요청의 모습 자체로 추론이 가능해야 한다는 것이다. REST API를 설계할 때는 다른 개발자들도 이해하기 쉬운 인터페이스를 제공하도록 노력해야 하며, 이를 위해 자원의 명확한 식별과 적절한 HTTP 메서드 사용이 필요하다.
 
* GraphQL : REST API와는 다른 정보 전달 방식이다.
 
(참고)
- 도서 <이것이 취업을 위한 코딩 테스트다> 부록 C
- https://www.youtube.com/watch?v=iOueE9AXDQQ
 

---

URI vs URL vs URN

 

1. URI 

URI(Uniform Resource Identifier)는 인터넷 상의 특정 자원(Resource)을 나타내는 식별자로, URL과 URN을 포함하는 개념이다.
 

2. URL

URL(Uniform Resource Locator)은 URI의 하위 개념으로, 인터넷 상에서 특정 자원이 어디에 위치하는지를 나타내는 문자열이다. URL은 프로토콜, 호스트, 자원 경로, 쿼리스트링 등으로 구성된다. 프로토콜은 해당 자원에 접근하기 위해 사용되는 통신 규약을 의미하고, 호스트는 자원이 위치한 서버의 도메인 이름이나 IP 주소를 의미한다. 자원 경로는 서버 내부에서 자원이 위치한 경로를 나타내고, 쿼리스트링은 서버로 추가적인 데이터를 전달하기 위해 사용된다.
예를 들어 "https://www.example.com/index.html?name=jin"은 URL이다. 해당 URL은 HTTPS 프로토콜을 사용하여 "www.example.com" 호스트에 있는 "index.html" 자원을 요청한다는 것을 의미하며, "name"이라는 파라미터에 "jin"이라는 값을 서버로 전달한다.
 

3. URN

URN(Uniform Resource Name)은 URI의 또 다른 하위 개념으로, 자원의 이름을 나타낸다. URN은 프로토콜, 호스트, 경로 등의 정보가 없으며, 자원의 이름을 식별하는 데 사용된다. 예를 들어, "urn:isbn:0451450523"은 ISBN(국제표준도서번호)을 식별하기 위한 URN이다. 이처럼 URN은 자원의 이름만을 나타내므로, 해당 자원의 위치가 바뀌더라도 여전히 유효하게 사용될 수 있다.
 

---

쿠키와 세션 

[네트워크] 쿠키와 세션

 

---

JWT 토큰 기반 인증

1. 세션 기반 인증의 문제점

Horizontal Scaling은 애플리케이션의 성능을 높이기 위해 여러 대의 서버를 구축하고 각각의 서버에서 애플리케이션을 실행하는 것을 의미한다. 그러나 세션 기반 인증에서는 세션 데이터가 서버의 메모리나 디스크에 저장되기 때문에, 각 서버는 다른 서버에 저장된 세션 데이터에 접근할 수 없게 된다. 따라서 인증 진행 후 세션 데이터가 저장된 서버가 아닌 다른 서버에 다음 요청이 전달되면, 서버는 사용자의 세션 정보를 모르기 때문에 다시 인증을 진행해야 하는 문제가 발생한다.

이와 같은 문제를 해결하기 위해 데이터베이스나 분산 캐시 등 외부 저장소에 세션 데이터를 저장하면, 여러 서버에서 세션 데이터를 공유할 수 있다. 하지만 이를 구현하려면 세션 관리 및 데이터베이스 또는 캐시 시스템을 구성하는 추가적인 작업이 필요하기 때문에 유지보수가 어려워진다.
 

2. JWT 토큰 기반 인증

토큰 기반 인증은 사용자 인증 정보를 바탕으로 토큰을 생성하여 클라이언트에게 발급하고, 이후 해당 토큰을 이용해 인증을 진행하는 방식이다. 토큰 기반 인증에서 대표적으로 사용되는 토큰은 JWT(JSON Web Token)이다. JWT는 사용자 관련 정보를 JSON 형식으로 표현하고 이를 Base64로 인코딩한 문자열로, Header, Payload, Signature 세 부분으로 구성되어 있다. Header에는 토큰의 타입과 암호화 알고리즘 정보가 담기고, Payload에는 사용자 정보가 담긴다. Signature는 토큰의 유효성을 검증하기 위한 정보로, Header와 Payload를 합친 후 서버만 아는 비밀키로 암호화한 값이다.
 

토큰 기반 인증 과정

1. 사용자가 로그인 요청을 보내면 서버는 유효한 사용자인지 검증하고, 검증 성공 시 해당 사용자 정보를 바탕으로 토큰을 생성한다.
2. 서버는 생성한 토큰을 클라이언트(브라우저)에게 전달한다.
3. 클라이언트는 전달받은 토큰을 저장해두고, 다음 요청을 보낼 때 서버에 토큰을 함께 전달한다. (그림 1번 과정)
4. 서버는 전달받은 토큰의 Signature를 검증하여 유효한 인증 정보인지 확인한다. (그림 2번 과정)
5. 사용자 인증이 완료되면, 요청받은 작업을 처리하고 그 결과를 응답한다. (그림 3~5번 과정)

 

 
 
이처럼 토큰 기반 인증은 세션 기반 인증과 달리 서버측에서 세션 데이터를 관리하지 않기 때문에 수평적 확장(Scale Out)에 용이합니다. 하지만 사용자 정보가 토큰에 담겨있고 클라이언트에서 토큰을 저장하기 때문에 정보 유출의 위험이 있다. 따라서 보안이 요구되는 데이터는 토큰에 담지 않아야 한다.

 

• 수평적 확장(Scale Out) : 애플리케이션의 성능을 높이기 위해서, 여러 대의 서버를 구축하고 각각의 서버에서 애플리케이션을 실행하는 것을 의미합니다.
• 수직적 확장(Scale Up) : 애플리케이션의 성능을 높이기 위해서, 서버에 고사양의 하드웨어를 추가하는 것을 의미합니다. 한 대의 서버에 추가할 수 있는 하드웨어의 수에는 제한이 있기 때문에, 수직적 확장에는 한계가 있습니다.

 

---

OAuth

OAuth(Open Authorization)는 인터넷 사용자의 자원(Resource)에 대한 제한된 접근(Access) 권한을 제3자 애플리케이션에게 부여하기 위한 프로토콜이다. 예를 들어 사용자가 Facebook 앱을 사용하는 경우, Facebook은 사용자의 동의 하에 OAuth를 사용하여 제3자 애플리케이션에게 사용자의 Facebook 데이터에 대한 접근 권한을 부여할 수 있다.

OAuth 프로세스는 사용자가 제3자 애플리케이션을 사용할 때 시작된다. 사용자가 애플리케이션에 로그인하면, 애플리케이션은 OAuth를 사용하여 사용자의 특정 데이터에 접근할 수 있다. 이를 위해 OAuth는 인증 서버(Authorization Server)와 리소스 서버(Resource Server)를 사용한다. 인증 서버는 사용자 인증을 처리하고, 리소스 서버는 애플리케이션에서 접근하려는 사용자 데이터를 저장한다. 사용자가 애플리케이션에 로그인하면 인증 서버는 제3자 애플리케이션에게 토큰을 부여하며, 애플리케이션은 해당 토큰을 사용해 리소스 서버에 있는 사용자 데이터에 접근할 수 있다.
 

 
이처럼 OAuth는 사용자가 자신의 아이디와 비밀번호와 같은 계정 정보를 제공하지 않아도 제3자 애플리케이션이 사용자의 특정 데이터에 접근할 수 있도록 하기 때문에 보안성을 유지하는 데 도움이 된다. 또한 OAuth는 여러 애플리케이션에서 동시에 사용자 자원에 접근할 수 있도록 지원한다.