미녀비

안녕하세요

오늘은 세션과 쿠키, 토큰에 대해서 알아보겠습니다.

HTTP

오늘의 주제는 기본적으로 HTTP에서 출발하게 됩니다. HTTP는 서버에 정보를 저장하지 않는 무상태성(Stateless)를 원칙으로 만들어졌기 때문에 웹을 사용하며 사용자 인증, 상태유지를 하기위해서는 추가적인 기술이 필요한데요 이 때 사용하는것이 세션,쿠키,토큰 입니다.

세션

세션은 전통적으로 많이 사용된 인증 수단인데요 주요한 특징은 인증 데이터를 서버에서 관리한다는 것입니다.

클라이언트의 요청을 받으면 서버는 세션정보를 저장하고 세션ID를 발급해 쿠키에 담아 클라이언트에 전달하게되고 이 쿠키는 사용자 클라이언트에 저장되어 추후 요청시마다 쿠키에서 세션 ID를 함께 전달하게 되고 서버는 이를 통해서 인증상태를 관리하게 됩니다. 

세션 방식의 장점으로는 안전성에 있습니다. 민감 정보를 서버에서 관리하기때문에 위변조의 위험이 클라이언트 저장보다 적습니다. 그리고 HTTP의 주요 원칙인 무상태성을 보완하기 위해 만들어져 세션은 Stateful한 상태를 가지게 되고 또한 세션은 서버의 별도의 저장공간을 차지하기에 확장성에서 떨어지는 모습을 보이게됩니다.

토큰

토큰 방식의 가장 큰 특징은 무상태성 인증 방식을 지원한다는점 입니다. 토큰 방식은 토큰 자체에 사용자의 인증정보가 담겨있고 이를 서버와 통신하기에 서버에서는 사용자의 인증정보를 관리할 필요가 없는 장점이 있는것이죠 

클라이언트에 위치하기에 위변조 위험이 있지만 이는 비밀키를 사용한 암호화로 보호되기에 보안 문제를 극복 가능합니다. 

토큰의 특징인 무상태성은 확장성을 확보할 수 있게되고 이는 최근 자주 사용하는 RESTFUL API나 MSA 환경에서 유연한 방식으로 인증정보를 관리할 수 있게 합니다.

안녕하세요

오늘은 HTTP 프로토콜에 대해 자세히 알아보는 시간을 갖겠습니다!

탄생배경

HTTP(HyperText Transfer Protocol) 프로토콜은 1980년대 인터넷이 존재하지만 데이터에 표준이 없어 서로 정보교환이 제한되는 상황에서 이 정보들을 효율적으로 관리하기 위해 팀 버너스 리에 의해 탄생된 프로토콜 입니다.

HTTP

HyperText : 문서 내에서 다른 문서나 데이터로 연결되는 텍스트 시스템

URL : 데이터의 위치를 식별하고 나타내는 주소체계

HTML : 웹 문서를 작성하기 위한 표준 언어

위 아이디어를 바탕으로 HTTP 프로토콜이 개발됐고 이를통해 더 효율적으로 정보교환이 가능해진것이죠.

HTTP는 클라이언트-서버 구조로 클라이언트의 요청을 서버에서 받아 알맞은 데이터를 전달하도록 했고 설계 당시 최소한의 자원으로 단순하고 효율적인 통신 프로토콜을 만들고자 하여 무상태성(StateLess)를 원칙으로 만들어졌습니다.

REST의 설계원칙이기도 한데요 HTTP 프로토콜을 사용하기에 기본적으로 충족되는 원칙이라고 할 수 있습니다.

HTTP 메소드

HTTP는 클라이언트-서버 구조로 클라이언트의 요청에 서버가 응답한다고 했습니다. 이 때 클라이언트의 요청 목적을 알리는 수단으로 HTTP 메소드를 사용하는 겁니다!

GET VS POST

기본적으로 GET은 서버에 데이터를 요청하여 리소스 정보를 확인하는 목표를 가지고 있고 POST는 서버에 데이터를 전달하여 리소스를 생성하는것을 목표로 합니다.

PUT VS PETCH

PUT과 PETCH는 리소스 수정이라는 동일한 목적을 가지고 있지만 동작방식에서의 차이가 존재합니다.

PUT의 경우 리소스 전체를 교체하거나 수정하는데 사용되는데요 클라이언트가 전달한 데이터로 서버의 리소스가 덮어씌워지는 형태로 일부 필드가 누락됐을경우는 해당 필드가 null로 설정될 수 있습니다. 리소스를 완전히 대체함을 의미하죠

PETCH는 리소스를 부분적으로 수정하는 경우 사용합니다. 클라이언트가가 특정 필드만 수정하고 싶은경우 해당 필드의 데이터만 전달하고 서버는 해당 필드의 리소스만 반영하게 됩니다. 부분 업데이트에 적합한 방식입니다.

상태코드

상태코드는 클라이언트가 서버에 전달한 요청의 상태를 알려주는 것으로 세자리 코드로 구성되어 있습니다.

1xx (정보) : 요청이 처리중인 상태

2xx (성공) : 요청이 성공적으로 처리됨

 200 OK : 요청이 성공적으로 처리됨

 201 Created : 요청이 성공적으로 처리됐고 리소스가 생성됨.

3xx (리다이렉션) : 요청이 다른 URL로 이동됨

4xx (클라이언트 오류) : 클라이언트 요청에 문제가 있음

 400 Bad Request : 요청이 잘못되어 서버가 처리할 수 없음

 403 Forbidden : 클라이언트가 리소스에 접근할 권한이 없음

 404 Not Found : 요청한 리소스를 찾을 수 없음

5xx (서버 오류) : 서버에서 요청 처리중 문제가 발생

 500 : 서버 내부 오류

평문통신

HTTP는 클라이언트-서버간 데이터를 전달할 때 평문을 사용해서 전달합니다. 위에서 얘기한 GET의 경우 데이터가 URL에 바로 노출되기도 하고 POST를 사용한다고 해도 body에 데이터가 평문으로 저장되기에 데이터를 탈취당할 경우 데이터를 바로 볼 수 있어 보안이 굉장히 취약한것이죠 이를 보완하기 위해 HTTPS 라는 프로토콜이 등장하게 됩니다.

HTTPS

위에서 말했듯 HTTP는 평문으로 통신하고 데이터를 탈취하여 중간에 수정하더라도 이를 감지하지 못해 보안적으로 문제가 발생하게 되고 이를 보완하기위해 SSL 이라는 프로토콜이 등장하여 HTTP통신과 함께 사용되며 HTTPS 프로토콜이 등장하게 됩니다.

SSL

SSL 프로토콜은 HTTP의 보안 약점을 보완하기위해 개발된 프로토콜로 현재는 TLS로 대체됐습니다.

SSL은 대칭키 암호화, 공개키 암호화 방식을 사용하여 데이터를 암호화 하고 복호화 하는데요

공개키 암호화는 공개키, 개인키 두개의 키를 사용해서 암호화를 진행하는 방식으로 대칭키 암호화에 비해 비용이나 속도가 느리지만  개인키는 클라이언트만 보유하기에 보안적으로 우수합니다. 초기에 한 번 핸드셰이크 과정에서 키를 교환하게됩니다.

대칭키 암호화는 서버와 클라이언트가 동일한 키를 사용하여 암/복호화를 진행하는 방식으로 공개키 암호화에 비해 빠른 속도를 가지고 있어 초기에 키 교환 이후 데이터를 전송하는경우에 대칭키 암호화를 사용하게 됩니다.

또 SSL은 데이터의 위변조를 확인할 수 있어 데이터의 무결성 유지도 가능합니다.

인증서

SSL은 CA라는 신뢰할 수 있는 인증기관에서 발급받은 인증서가 있어야 사용이 가능한데요 서버에서는 해당 인증서를 발급받아 서버의 신뢰성을 높이는 효과가 있습니다.

안녕하세요! 

저번시간 우리는 HTTP 프로토콜을 이용한 웹 아키텍처 스타일 REST에 대해 공부했습니다.

오늘은 MSA를 알아보는 시간입니다.

MSA(MicroService Architecture)

MSA는 애플리케이션을 작고 독립적인 서비스들로 분리하여 개발하고 운여하는 아키텍처 스타일 입니다.

등장배경

기존의 애플리케이션 개발 방식은 단일구조(Monolithic Architecture) 였습니다. 애플리케이션은 하나의 코드베이스와 데이터베이스에 묶여있는 형태였죠 이 단일구조 형태는 개발과 관리가 단순하고 하나의 프로젝트만 배포하면 끝이기에 간단하다는 장점이 있었죠 하지만 특정 기능을 배포하려고 해도 전체 서버를 다시 빌드해야하는 단점이 있고 Netflix같은 대규모 플랫폼들의 등장은 특정 기능의 독립적 개발 및 확장같은 생산성의 영역이 굉장히 중요해졌고 그때 MSA가 등장하게 됩니다.

특징

MSA의 핵심은 한 애플리케이션을 기능별로 분리하여 독립적으로 운영이 가능하다 입니다.

1. 서비스의 독립성

각 서비스들은 서로 독립적으로 동작하기에 다른 서비스에 영향을 받거나 주지 않습니다. 

이는 장애처리나 최근 맞물리는 CI/CD 환경을 최대한으로 활용할 수 있게 해줍니다.

2. 도메인 중심 설계

각 서비스를 도메인 중심으로 분할합니다.

이를 통해 각각의 서비스들은 단일 기능만을 담당하여 유지보수와 확장에 용이한 구조를 갖게됩니다.

3. 다양한 기술 사용 가능

기존에는 하나의 언어, 하나의 데이터베이스로 프로젝트를 구성했는데요 서비스 별로 분할하여 역할에 맞는 특화된 언어나 데이터베이스를 사용할 수 있습니다. 

4. 통신과 분산 시스템

이전 시간에 공부한 REST가 MSA와 시너지를 내는 분야입니다. MSA는 서비스를 분할해놓고 각 엔드포인트간에는 서로 API로 통신을 합니다. 이때 사용되는 것이 REST API 인데요 REST API가 가지는 표준성, 직관성 그리고 REST의 특징인 비상태성을 통해 MSA를 위한 분산시스템에 적용하기가 아주 좋습니다.

5. 클라우드 서비스와의 연계

최근 자주 사용하는 AWS, AZURE 같은 클라우드 서비스의 유연성과 자우너 활용은 MSA의 장점을 최대화 할수 있도록 합니다. MSA의 분산된 서비스에 맞게 클라우드 서비스는 효율적으로 서버의 자원을 조절이 가능합니다.

한계

단일 구조의 설계에서 장점은 단순함 이었습니다. 하나의 애플리케이션이기에 구조가 단순하고 관리해야하는 것도 적습니다. 하지만 MSA의 경우 여러 서비스가 분산되어 있고 서비스 마다 별도의 언어, 데이터베이스를 사용하는경우 그에 따른 데이터를 관리하는 것도 어려워 질 수 있습니다.

최종정리

MSA는 기존의 설계 방식에서 벗어나 서비스를 분산하여 생산성, 확장성을 높일 수 있으나 설계를 위해 고려해야하는 부분이 존재한다.

REST(Representational State Transfer)

REST는 HTTP프로토콜 기반으로 리소스를 URI로 식별하고 표준 HTTP 메소드를 활용해서 상태를 주고받는 아키텍처 스타일로 웹 애플리케이션의 효율성과 확장성을 높이고 분산 시스템 설계에 목적이 있습니다.

등장배경

인터넷이 발전하며 웹 애플리케이션은 점점 더 복잡해지고 있었으나 마땅히 이를 관리하는 표준화된 설계 원칙은 없는 상태 였고 당시 사용하던 SOAP 프로토콜 같은 경우 복잡한 규칙으로 웹 시스템간 상호작용이 계속해서 늘어나는 상황에서 단순하고 확장가능한 아키텍처의 필요성이 대두됐고 이 때 등장한것이 REST 입니다.

REST(Representational State Transfer)?

REST는 서버의 리소스를 JSON, XML 등으로 표현(Representational) 하고 이 상태(State)를 전송(Transfer) 하는 웹의 HTTP 프로토콜을 기반으로 구현한 아키텍처 스타일 입니다.

REST 설계 원칙

1. 클라이언트-서버 구조 (Client-Server Architecture)

클라이언트와 서버는 역할 분리 구조로 설계합니다. 클라이언트는 리소스를 요청하고 서버는 이를 제공하는 것이죠
독립적으로 설계된 클라이언트와 서버는 서로에 영향을 주지 않아 시스템 확장에 용이하고 개발 단계에서도 생산성을 확보할 수 있게 됩니다.

2. 무상태성(Statelessness)

각 요청은 독립적으로 처리하고 서버는 상태를 저장하지 않습니다. 클라이언트는 필요한 모든정보를 포함시켜야 합니다.

서버는 클라이언트의 이전 요청을 참조할 필요가 없기에 다른 서버로의 분산처리가 자유롭고 이를통해 서버의 부하를 줄일 수 있으며 클라우드 환경에서 적합합니다. 

3. 캐시 가능성 (Cacheability)

서버는 응답에 캐시 데이터를 포함시켜 클라이언트가 데이터를 캐싱 가능하도록 합니다.

이를 통해 클라이언트의 반복적인 요청에도 캐시를 활용하여 서버의 자원 소모를 줄이고 클라이언트 또한 캐시데이터를 활용하면서 응답 시간을 단축시킬 수 있습니다.

4. 통합된 인터페이스 (Uniform Interface)

REST는 모든 리소스에 대해 일관된 인터페이스가 있습니다. 모든 리소스를 고유한 URI를 통해 식별하고 HTTP의 표준 메소드를 활용하는데요 이를 통해 개발자와 클라이언트 모두 표준화된 인터페이스 사용으로 쉽게 이해하고 사용할 수 있습니다.

URI(Uniform Resource Identifier) VS URL (Uniform Resource Locator)

REST에서는 리소스를 URI로 인식합니다. 모든 리소스에는 고유의 ID가 있고 그 자원이 유일하다는 것을 나타냅니다.

우리가 더 친숙한 단어는 URL 일텐데요 과거의 웹에서는 html같은 파일들의 주소를 주고 받았기에 그 파일의 위치를 가르키는 Locator를 사용했고 URI는 이런 URL을 포함하는 개념으로 서버내의 모든 리소스에 ID를 부여하고 이를 인식하는 개념으로 이해할 수 있습니다.

5. 계층화 시스템 (Layered System)

클라이언트는 서버와 통신하는지 중간계층과 통신하는지 알 필요가 없습니다.

6. 코드 온 디맨드 (Code on Demand)

서버는 필요할 때 클라이언트로 실행 가능한 코드를 전송할 수 있습니다

HATEOAS

REST의 주요 개념 중 하나로 클라이언트는 서버로부터 전달받은 Hypermedia(링크)를 통해 시스템의 상태 전환과 추가작업을 탐색할 수 있도록 합니다. 기존에는 클라이언트가 서버 URI정보를 미리 알고 있어야 했으나 서버에서 동적으로 필요한 링크를 제공해줌으로써 확장성을 보장할 수 있습니다.

Self-Descriptive Messages

무상태성 원칙을 지원하기 위해 만들어졌습니다. 서버와 클라이언트는 서로 상태를 저장하지 않기에 필요한 모든 정보를 요청/응답에 포함시켜야 하고 이를 독립적으로 처리할 수 있게 합니다. HATEOS를 포함하는 개념으로 REST의 자율성과 확장성을 보장할 수 있습니다.

REST API? RESTful API?

우리는 REST와 그 원칙들에 대해서 알아봤는데요 그럼 많이들 사용하는 REST API RESTful API는 무엇이냐

REST API는 REST 원칙을 기반으로 부분적으로 원칙을 따른경우 REST API로 불리며

RESTful API는 위와 같은 원칙을 모두 엄격히 지켰을 때 RESTful API 라고 합니다.

최종정리

REST는 발전하는 웹 환경에서 웹 통신을 위한 아키텍처로 HTTP메소드를 활용하여 웹 애플리케이션의 확장성과 효율성을 높여 분산처리 시스템을 효과적으로 설계하려는 목적을 가지고 있습니다.