반응형

 

API(Application Programming Interface)는 소프트웨어 애플리케이션 간의 상호 작용을 가능하게 하는 인터페이스입니다.

API는 다양한 기능을 다른 프로그램에서 사용할 수 있도록 정의된 규칙 및 도구의 집합을 제공합니다.

 

 

주요 개념

 

1. 인터페이스: API는 소프트웨어 구성 요소가 서로 상호작용할 수 있도록 하는 인터페이스입니다. 이 인터페이스는 명령, 함수, 프로토콜 등으로 구성될 수 있습니다.

2. 표준화: API는 특정 작업을 수행하기 위한 표준화된 방법을 제공합니다. 이를 통해 다양한 소프트웨어가 일관된 방식으로 상호작용할 수 있습니다.

3. 재사용성: 개발자는 API를 사용하여 기존 기능을 재사용할 수 있습니다. 새로운 애플리케이션을 개발할 때 처음부터 모든 기능을 구현할 필요 없이, API를 통해 필요한 기능을 빠르게 통합할 수 있습니다.

 

종류

 

1. 웹 API: 웹 서비스 상호작용을 위한 API로, HTTP 프로토콜을 사용하여 데이터를 주고받습니다.

RESTful API와 SOAP API가 대표적입니다.

RESTful API: REST(Representational State Transfer) 아키텍처 스타일을 따르는 API로, 자원을 URL로 표현하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 조작합니다.

SOAP API: SOAP(Simple Object Access Protocol)를 사용하는 API로, XML 형식을 통해 메시지를 교환합니다.

2. 라이브러리 API: 소프트웨어 라이브러리에서 제공하는 API로, 특정 프로그래밍 언어로 작성된 함수와 절차를 사용하여 기능을 구현합니다.

3. 운영 체제 API: 운영 체제가 제공하는 API로, 애플리케이션이 운영 체제의 기능을 사용할 수 있도록 합니다. 예를 들어, 파일 시스템 접근, 프로세스 관리 등이 있습니다.

 

예시

 

1. Google Maps API: 개발자가 Google Maps 서비스를 자신의 애플리케이션에 통합할 수 있도록 하는 API입니다. 경로 찾기, 장소 정보 제공, 지도 표시 등의 기능을 제공합니다.

GET https://maps.googleapis.com/maps/api/geocode/json?address=Seattle&key=YOUR_API_KEY

2. Twitter API: Twitter 플랫폼의 데이터를 접근하고 조작할 수 있게 해주는 API입니다. 트윗 작성, 사용자 정보 가져오기, 트윗 검색 등의 기능을 제공합니다.

GET https://api.twitter.com/2/tweets?ids=1453489038376136711&tweet.fields=created_at&expansions=author_id&user.fields=username

API 사용의 장점

 

1. 빠른 개발: 기존의 기능을 재사용함으로써 개발 속도를 높일 수 있습니다.

2. 유지보수 용이: 중앙화된 API를 통해 기능 업데이트와 유지보수가 용이합니다.

3. 호환성: 다양한 시스템 간의 호환성을 보장합니다.

 

참고 자료

 

RESTful API란 무엇인가?

반응형
반응형

클라이언트-서버 모델 개요

클라이언트

  • 정의: 서비스를 요청하는 프로그램이나 장치.
  • 역할: 사용자 입력을 받아 서버에 요청을 보내고, 서버로부터 받은 응답을 사용자에게 제공.
  • : 웹 브라우저, 모바일 앱 등.
  • 웹 브라우저: 인터넷 웹사이트를 탐색하고 서버에서 웹 페이지를 요청하여 표시합니다.
  • 모바일 앱: 다양한 서비스를 제공하기 위해 서버에 요청을 보내고 응답을 받아 사용자에게 표시합니다.

 

서버

  • 정의: 클라이언트의 요청을 처리하고 응답을 제공하는 프로그램이나 장치.
  • 역할: 데이터베이스 조회, 비즈니스 로직 처리, 클라이언트에게 응답 제공.
  • : 웹 서버, 데이터베이스 서버, API 서버 등.
  • 웹 서버: 웹 페이지를 제공하고, HTTP 요청을 처리합니다.
  • 데이터베이스 서버: 데이터를 저장하고, 데이터베이스 쿼리를 처리합니다.
  • API 서버: 클라이언트 애플리케이션에 기능과 데이터를 제공하는 API를 제공합니다.

클라이언트가 서버에 요청하는 방식

서버에 요청하는 프로토콜에는 여러 가지가 있지만, 가장 일반적으로 사용되는 프로토콜은 HTTP/HTTPS입니다. 이 외에도 WebSocket, FTP, SMTP 등이 있습니다. 각 프로토콜은 특정한 용도와 방식으로 서버와 클라이언트 간의 통신을 지원합니다. 아래는 주요 프로토콜들에 대한 정리입니다.

 

1. HTTP/HTTPS

HTTP (HyperText Transfer Protocol)

  • 정의: 웹에서 클라이언트와 서버 간의 데이터 통신을 위해 사용되는 프로토콜.
  • 역할: 웹 페이지, 이미지, 동영상 등 다양한 데이터를 전송.
  • 특징:
    • 비연결성: 각 요청은 독립적이며, 요청 후 연결이 종료됨.
    • 무상태성: 각 요청 간에 상태 정보를 유지하지 않음.
  • 요청 메서드:
    • GET: 데이터를 요청.
    • POST: 데이터를 서버에 제출.
    • PUT: 데이터를 갱신.
    • DELETE: 데이터를 삭제.
    • PATCH: 데이터의 부분적 갱신.
    • OPTIONS: 지원하는 요청 메서드 확인.
GET /index.html HTTP/1.1
Host: www.example.com

 

2. WebSocket

WebSocket 프로토콜

  • 정의: 클라이언트와 서버 간의 양방향 통신을 위한 프로토콜.
  • 역할: 실시간 데이터 전송이 필요한 애플리케이션에서 사용.
  • 특징:
    • 양방향 통신: 클라이언트와 서버가 모두 메시지를 주고받을 수 있음.
    • 지속적인 연결: 연결이 유지되며, 지속적인 데이터 스트림이 가능.
// 클라이언트 측 JavaScript 예제
const socket = new WebSocket('ws://www.example.com/socketserver');

socket.onopen = function(event) {
  socket.send('Hello Server!');
};

socket.onmessage = function(event) {
  console.log('Message from server: ', event.data);
};

 

3. FTP

FTP (File Transfer Protocol)

  • 정의: 파일을 전송하기 위한 프로토콜.
  • 역할: 클라이언트와 서버 간의 파일 업로드 및 다운로드.
  • 특징:
    • 데이터 전송: 큰 파일의 전송에 최적화.
    • 인증: 사용자 이름과 비밀번호로 접근.
ftp ftp.example.com
Username: user
Password: pass

 

4. SMTP

SMTP (Simple Mail Transfer Protocol)

  • 정의: 이메일을 전송하기 위한 프로토콜.
  • 역할: 클라이언트에서 서버로, 서버에서 서버로 이메일 전송.
  • 특징:
    • 이메일 전송: 주로 이메일 클라이언트와 서버 간의 통신.
    • 텍스트 기반: 간단한 텍스트 명령어로 구성.
  • SMTP 예제:
HELO example.com
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.com>
DATA
Subject: Test mail
This is a test email.
.
QUIT

 

 

  • HTTP/HTTPS: 웹에서 가장 널리 사용되는 프로토콜로, 웹 페이지와 데이터를 전송.
  • WebSocket: 실시간 양방향 통신을 지원하는 프로토콜로, 채팅 애플리케이션 등에 사용.
  • FTP: 파일 전송에 특화된 프로토콜로, 대용량 파일 전송에 적합.
  • SMTP: 이메일 전송을 위한 프로토콜로, 이메일 클라이언트와 서버 간의 통신을 지원.
  • RESTful API: 리소스 기반의 API 설계 아키텍처로, HTTP 메서드를 통해 자원에 접근.

 

반응형
반응형

1. 프론트엔드 개발자 로드맵

 

기초 단계

 

HTML/CSS

   HTML5

   CSS3

   Flexbox

   Grid 레이아웃

JavaScript

    ES6 기본 문법

    DOM 조작

    이벤트 처리

 

중급 단계

 

프레임워크 및 라이브러리

React

Vue.js

Angular

상태 관리 라이브러리 (Redux, Vuex 등)

패키지 관리자

npm

yarn

 

고급 단계

 

빌드 도구

Webpack

Babel

테스팅

Jest

Mocha

최적화

Lighthouse

DevTools

 

2. 백엔드 개발자 로드맵

 

기초 단계

 

프로그래밍 언어

Java

Python

Node.js

Ruby

웹 프레임워크

Spring Boot (Java)

Django (Python)

Express (Node.js)

Ruby on Rails (Ruby)

 

중급 단계

 

데이터베이스

SQL: MySQL, PostgreSQL

NoSQL: MongoDB, Redis

API 설계

RESTful API

GraphQL

 

고급 단계

 

보안

인증 및 권한 부여 (OAuth, JWT)

OWASP Top 10

테스팅 및 배포

JUnit, Mockito (Java)

CI/CD 도구 (Jenkins, GitHub Actions)

 

3. 인프라 엔지니어 로드맵

 

기초 단계

 

운영체제

Linux 기초 명령어

시스템 관리

 

중급 단계

 

네트워킹

TCP/IP

DNS

HTTP/HTTPS

클라우드 플랫폼

AWS

Azure

GCP

컨테이너화

Docker

Kubernetes

 

고급 단계

 

모니터링 및 로깅

Prometheus

Grafana

ELK 스택 (Elasticsearch, Logstash, Kibana)

 

4. DBA 로드맵

 

기초 단계

 

데이터베이스 기초

ERD 작성

SQL 문법 (SELECT, INSERT, UPDATE, DELETE)

 

중급 단계

 

데이터베이스 관리

인덱스

조인

트랜잭션 관리

백업 및 복구

 

고급 단계

 

데이터베이스 아키텍처

샤딩

파티셔닝

고가용성 (Replication, Clustering)

데이터 보안

암호화

접근 제어

반응형
반응형

공개 IP 주소(Public IP)와 사설 IP 주소(Private IP)는 인터넷 및 내부 네트워크에서 장치들이 통신하기 위해 사용하는 두 가지 주요 유형의 IP 주소입니다. 이들 주소는 각각 다른 용도로 사용되며, 네트워크의 구조와 보안에 중요한 역할을 합니다.

 

공개 IP 주소 (Public IP)

 

정의

 

공개 IP 주소는 인터넷에 직접 연결된 장치에 할당되는 IP 주소입니다. 전 세계에서 유일하며, 인터넷 상의 다른 모든 장치와 직접 통신할 수 있습니다.

예: 192.0.2.1, 203.0.113.1

 

특징

 

고유성: 전 세계적으로 유일한 주소입니다. 인터넷 상의 다른 장치와 중복되지 않습니다.

공인된 할당: IANA(Internet Assigned Numbers Authority) 및 지역 인터넷 등록 기관(RIR)이 할당합니다.

인터넷 접근: 인터넷에 직접 연결되므로, 전 세계 어디서나 접근할 수 있습니다.

보안: 공개 IP 주소는 인터넷에 노출되어 있으므로, 보안 취약점이 있을 수 있습니다. 방화벽 및 기타 보안 조치가 필요합니다.

 

예시

 

가정 네트워크: ISP(인터넷 서비스 제공자)가 가정의 라우터에 공개 IP 주소를 할당합니다.

웹 서버: 웹 서버가 인터넷에 접근할 수 있도록 공개 IP 주소를 사용합니다.

 

사설 IP 주소 (Private IP)

 

정의

사설 IP 주소는 내부 네트워크에서만 사용되는 IP 주소입니다. 인터넷에서는 직접 사용할 수 없으며, 주로 로컬 네트워크 내의 장치들 간의 통신에 사용됩니다.

예: 192.168.1.1, 10.0.0.1

 

특징

중복 가능성: 다른 네트워크에서도 같은 사설 IP 주소를 사용할 수 있습니다. 고유하지 않습니다.

로컬 네트워크 사용: 사설 네트워크 내에서만 유효하며, 인터넷에 직접 노출되지 않습니다.

NAT 필요: 인터넷과의 통신을 위해 NAT(Network Address Translation)를 통해 공개 IP 주소로 변환되어야 합니다.

보안: 사설 네트워크 내부에서만 사용되므로, 외부로부터의 직접적인 접근이 차단되어 보안성이 높습니다.

 

사설 IP 주소 범위 (RFC 1918 정의)

 

10.0.0.0 ~ 10.255.255.255

172.16.0.0 ~ 172.31.255.255

192.168.0.0 ~ 192.168.255.255

 

예시

가정 네트워크: 가정의 라우터가 내부 네트워크 장치(컴퓨터, 스마트폰, 프린터 등)에 사설 IP 주소를 할당합니다.

기업 네트워크: 회사 내부의 컴퓨터, 서버, 네트워크 장치들이 사설 IP 주소를 사용하여 통신합니다.

 

요약

결론

공개 IP 주소는 인터넷에 직접 연결된 장치들 간의 통신에 사용되며, 전 세계적으로 유일한 주소를 가집니다. 반면, 사설 IP 주소는 내부 네트워크 내에서만 사용되며, 인터넷에 직접 노출되지 않아 보안성이 높습니다. 각 주소의 용도와 특징을 이해하면 네트워크를 설계하고 관리하는 데 도움이 됩니다.

반응형
반응형

 

1. 도메인 이름 입력 및 요청

 

사용자가 웹 브라우저의 주소창에 URL을 입력하고 엔터를 누르면, 브라우저는 입력받은 URL을 해석하여 해당 도메인의 IP 주소를 찾아야 합니다. URL이 도메인 이름으로 구성되어 있기 때문에, 먼저 이 도메인의 IP 주소를 알아내야 실제 서버와 통신이 가능합니다.

 

2. DNS 조회

 

브라우저는 도메인 이름을 IP 주소로 변환하기 위해 DNS(Domain Name System) 조회를 수행합니다. DNS는 전 세계의 도메인 이름과 그에 해당하는 IP 주소를 관리하는 시스템으로, 인터넷 전화번호부와 유사합니다.

 

브라우저는 먼저 로컬 DNS 캐시를 확인하여 최근에 조회된 도메인의 IP 주소가 저장되어 있는지 확인합니다.

캐시에 없는 경우, 브라우저는 설정된 DNS 서버에 요청을 보내 도메인 이름에 대한 IP 주소를 조회합니다.

이 과정에서 여러 DNS 서버를 거쳐 최종적으로 도메인을 관리하는 권한 있는(Authoritative) DNS 서버에서 응답을 받을 수 있습니다.

 

3. TCP 연결

 

IP 주소를 획득하면, 브라우저는 해당 서버에 접속하기 위해 TCP(Transmission Control Protocol) 연결을 시도합니다. TCP는 인터넷 프로토콜 스위트의 핵심 프로토콜로, 데이터가 정확하고 신뢰성 있게 전송되도록 합니다.

 

브라우저는 TCP 3-way handshake 과정을 통해 서버와의 연결을 확립합니다. 이는 SYN, SYN-ACK, ACK 패킷을 교환하는 과정으로 구성됩니다.

 

4. HTTP 요청 및 응답

 

TCP 연결이 확립되면, 브라우저는 HTTP(Hypertext Transfer Protocol) 요청을 서버로 보냅니다. 이 요청에는 사용자가 요구하는 리소스(예: 웹 페이지)의 정보가 포함되어 있습니다.

 

서버는 HTTP 요청을 받고 필요한 작업을 수행한 후 HTTP 응답을 브라우저로 전송합니다. 응답에는 요청된 웹 페이지의 데이터, 상태 코드, 헤더 등이 포함됩니다.

 

5. 콘텐츠 렌더링

 

브라우저는 서버로부터 받은 HTTP 응답을 해석하여 사용자에게 보여줄 웹 페이지를 구성합니다. 이 과정에는 HTML, CSS, JavaScript 등을 파싱하고 실행하여 최종적으로 사용자에게 웹 페이지를 렌더링하는 작업이 포함됩니다.

 

6. 완료

 

웹 페이지가 완전히 로드되면 사용자는 페이지의 모든 콘텐츠를 보고 상호작용할 수 있습니다. 이 단계에서 추가적인 사용자 요청이 있을 경우, 동일한 프로세스가 반복하여 수행됩니다.

반응형

'웹 기본지식' 카테고리의 다른 글

개발자 기술 로드맵  (0) 2024.06.01
public ip 와 private ip 는 어떤것인지  (0) 2024.05.31
http status 값 정의  (2) 2020.05.14
FTP 보안 프로토콜  (1) 2020.05.13
쿠키 세션 기본 개념  (0) 2020.05.13
반응형

응답값 정리

200 번대 응답(Response) : 성공(Success)

200

OK

* 요청 정상 처리.

204

No Content

* 요청 정상 처리하였지만, 돌려줄 리소스 없음.

* 응답에 어떠한 엔티티 바디(Entity Body)도 포함하지 않음.

* 서버에서 처리 후, 클라이언트에 정보를 보낼 필요가 없는 경우 사용. 

206

Partial Content

* Range가 지정된 요청인 경우, 지정된 범위만큼의 요청을 받았다는 것을 알려줌. 

300 번대 응답(Response) : 리디렉션(Redirection)

301

Moved Permanently

* 요청된 리소스에는 새로운 URI가 지정되어 있기 때문에, 이후로는 새 URI를 사용해야 한다는 것을 나타냄. (영구적인 URI 변경)

302

Found

* 요청된 리소스에는 새로운 URI가 지정되어 있기 때문에, 이후로는 새 URI를 사용해야 한 다는 것을 나타냄. 301과 유사하지만, 302는 일시적인 URI 이동) 

303

See Other

* 이 응답은 요청에 대한 리소스는 다른 URI에 있기 때문에 GET 메서드를 사용해서 얻어야 한다는 것을 나타냄. 302 코드와 같지만, 303은 리디렉션 위치를 GET 메서드를 통해 얻어야 한다고 명확하게 되어 있음. 

304

Not Modified

* 요청한 리소스가 마지막 요청 이후 변경된 적이 없기 때문에 기존 클라이언트의 로컬 캐시 리소스를 사용하도록 알려줌.

300번대로 분류되어 있지만, 리디렉션과는 관계없는 처리를 함.

307

Temporary Redirect

* 임시로 페이지를 리다이렉트 함.

304응답

브라우저가 서버에 GET 요청을 보낼 때,
요청하는 정보를 이미 디스크에 가지고 있을 경우(캐시되어 있는 경우)
브라우저는 이 데이터가 변경되었는지 여부를 확인하는 요청을 보내게 된다.
이와 같은 요청을 Conditional Get Request 라고 하며,
서버는 요청 데이터가 변경되지 않았을 경우 응답 코드로 304 (Not Modified) 를 리턴한다.
물론, 데이터가 변경되었다면 변경된 데이터를 응답으로 보내게 된다.

400 번대 응답(Response) : 클라이언트 에러 (Client Error)

400

Bad Request

* 클라이언트의 요청 구문이 잘못됨.

* 브라우저는 이 응답을 200 OK 응답과 동일한 형태로 취급함.

401

Unauthorized

* 요청 처리를 위해 HTTP 인증(BASIC 인증, DIGEST 인증) 정보가 필요함을 알려줌.

접근 허용을 차단함. 최초 요청에는 인증 다이얼로그 표시하고, 두번째는 인증 실패 응답을 보냄. 

403

Forbidden

* 접근 금지 응답. Directory Listing 요청(서버 파일 디렉토리 목록 표시) 및 관리자 페이지 접근 등을 차단하는 경우의 응답. (파일 시스템 퍼미션 거부, 허가 되지 않은 IP 주소를 통한 액세스의 거부 등)

* 서버는 엔티티 바디에 접근 거부에 대한 이유를 명시하여 보낼 수 있음.

404

Not Found

* 클라이언트가 요청한 리소스가 서버에 없음

405

Mothod Not Allowed

* 허용되지 않는 HTTP 메서드를 사용함. 

500 번대 응답(Response) : 서버 에러 (Server Error)

500

Internal Server Error

* 서버에서 클라이언트 요청을 처리 중에 에러가 발생함.

503

Service Unavailable

* 서버가 일시적으로 요청을 처리할 수 없음.

* 서버가 과부하 상태이거나 점검중이므로 요청을 처리할 수 없음을 알려줌.

504

Gateway Timeout

* 서버를 통하는 게이트웨이에 문제가 발생하여 시간이 초과됨.

505

HTTP Version Not Supported

* 해당 HTTP 버전에서는 지원되지 않는 요청임을 알려줌.

참고문헌

https://ooz.co.kr/260 status정리

반응형
반응형

FTP 보안 프로토콜(SFTP, Secure FTP, FTPS)

1. SFTP(SSH File Transfer Protocol)

정확히 말하면 SFTP 프로토콜은 FTP를 사용하지 않는다. SFTP는 SSH 기반의 새로운 파일 전송 프로토콜이다. SSH 서버가 구축되어 있어야 한다. Telnet을 대체하는 원격관리 프로토콜인 SSH를 이용하기 때문에 구축 및 유지 비용이 적고 다른 보안 FTP 메커니즘에 비해 일반 사용자들이 사용하기에 편리하여 많이 사용된다.

일반 사용자들은 FileZilla, SSH Secure Shell v3.29 또는 pscp, WinSCP 프로그램을 이용한다. 상용S/W로는 VanDyke Software 社에서 나온 SecureFX가 있다.

특히 FileZilla는 Open S/W이고 아래에서 소개한 FTPS(FTP over SSL)까지 지원하기 때문에 추천한다.

2. FTP over SSH(Secure FTP)

SSH 연결 위에 일반 FTP로 터널링 연결을 함으로써 접속 시에 계정 정보가 암호화 되어 악의적인 공격자에게 노출되지 않지만 데이터는 암호화 되지 않는다.

이 방법은 ssh를 이용하여 터널링을 구성한 다음, 일반 ftp로 접속하는 방법이기 때문에 일반 사용자들이 사용하기에는 쉽지 않다.

  • SSH(Secure Shell)

원격 컴퓨터에 안전하게 액세스하기 위한 유닉스 기반의 명령 인터페이스 및 프로토콜
강력한 암호화 기능을 구현해 모든 데이터가 암호화 되기에 높은 보안을 지원

3. FTPS(FTP over SSL)

FTP가 TLS/SSL 보안 연결에서 동작한다. TLS(Transport Layer Security)/SSL(Secure Sockets Layer)

FTP Secure 또는 FTP-SSL로 알려진 FTPS는 TLS(Transport Layer Security)와 Secure Sockets Layer (SSL) 암호화 프로토콜이 더해진 FTP의 확장판이다. SSL 레이어 위에서 FTP를 수행하는 것으로서 command 와 data 모두 암호화 된다.

4. FTP

FTP는 21포트(TCP 21)를 사용하고, SFTP는 22포트를 사용하죠. 21 포트를 이용한 FTP접속은 로그인 정보를 평문으로 전송하기 때문에 보안에 취약하다. SFTP는 이름 그대로 이러한 점을 보완한 Secure FTP로, 보다 안전한 호스팅 서비스를 이용하기 위해서는 SFTP를 사용한다.

반응형
반응형

1. HTTP의 특징과 쿠키와 세션을 사용하는 이유

HTTP 프로토콜이 connectionless, stateless한 특성이 있기 때문입니다.
connectionless
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징
stateless
통신이 끝나면 상태를 유지하지 않는 특징

1. 개요

  • 공통점 : 사용자의 정보(데이터)를 저장할 때 이용된다.

  • 차이점 :

  • 쿠키 :
    1) 사용자의 로컬에 저장되었다가 브라우저가 요청시 왔다갔다하게 됨(보안에 취약)
    2) 세션과 달리 여러 서버로 전송이 가능함
    3) 세션이 브라우저 단위로 생성되어 브라우저 종료시 사라지는데 반해, 쿠키는 유효시간 설정을 할 수 있음. ex) 7일
    4) 클라이언트가 재요청시 웹페이지 요청과 함께 쿠키값도 전송 - 자동으로 서버에 전송

    • 쿠키의 제한
      클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음. 하나의 쿠키값은 4KB까지 저장
      5) Response Header 에 Set-Cookie 속성을 사용하여 클라이언트에 쿠키 생성
      6) 만료시간이 있지만 파일로 저장되어서 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다.
      7) 서버에 요청시 속도가 빠름
  • 세션 :
    1) 서버에 데이터를 저장하여 쿠키에 비해 보안에 안전함
    2) 브라우저 단위로 생성됨 => 익스플로러를 켜고 크롬을 켜고 하면 각각 2개의 세션이 생성되는 것
    3) 브라우저를 종료할때까지 유지되는 상태 - 일정시간동안 같은 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 유지하는 기술
    4) 클라이언트가 Request 를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는데 이것이 세션ID.
    5) 서버의 자원을 사용하기 때문에 무분별하게 만들면 서버의 메모리가 감당할 수 없어질 수 있어 속도가 느려질 수 있다. - 비교적 느림

    세션 프로세스
    1) 클라이언트가 서버에 접속시 세션 ID를 발급
    2) 서버에서는 클라이언트로 발급해준 세션ID를 쿠키를 사용해 저장(JSESSIONID)
    3) 클라이언트가 다시 접속할때, JSESSIONID 를 이용해서 세션ID값을 서버에 전달

    즉, 세션을 구별하기 위해 ID가 필요하고 그 ID만 쿠키를 이용해서 저장. 쿠키는 자동으로 서버에 전송되므로 서버에서 세션아이디에 따른 처리를 한다.

2. 세션과 쿠키를 이용한 자동 로그인 구현

로그인에 성공했을 때 사용자 DB 테이블에 sessionId와 유효시간 속성에 값을 지정하는 겁니다. 그리고 쿠키에는 세션Id를 넣는다.
"인터셉터"에서 해당 쿠키값이 존재하면 사용자 DB 테이블 내에서 유효시간이 아직
남아 있으면서 해당 세션 Id를 가지고 있는 사용자 정보를 검색해 해당 사용자 객체를 반환하는 겁니다.

요즘 추세

세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에 요즘은 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세입니다.

그 중 JWT( JSON Web Token )라는 것 사용

참고문헌

https://interconnection.tistory.com/74 [쿠키 세션]

반응형

+ Recent posts