하루 30분 TIL

230220 30분 TIL

devSoo 2023. 2. 19. 20:16

1. AJAX

  • 전통적인 웹모델에서는 변경할 필요가 없는 부분까지 완전한 HTML을 매번 서버로 부터 받기 때문에 불필요한 통신 및 비효율 발생 또한 서버와의 통신이 동기적이기 때문에 응답이 있을 때까지 블로킹 처리됨
  • 이러한 단점을 보완하기 위해 나온 Asynchronous Javascript And XML 서버와 비동기적으로 데이터를 주고 받는 자바스크립트 기술 
    (여기서 XML은 JSON이 나오기 전 사용했던 데이터를 주고 받을때 쓰는 데이터 형식)
  • 브라우저가 가지고 있는 XMLHttpRequest 객체를 이용해서 전체 페이지를  새로 고치치 않고 페이지 일부 만을 위한 데이터 로드기법

참고자료: Ajax, JSON, XMLHttpRequest


2. OOP(객체지향 프로그래밍) 

  • 프로그래밍하려는 대상을 하나의 객체(사물)로 정의하는 설계 방법으로 객체의 관점에서 구조를 만들고 사용하는 방법
  • 객체지향을 지원하는 대표적인 언어로는 Java, C# 가 있다.
function Car() {
  this.power = false;
  this.position = 0;
}

Car.prototype.start = function() {
  this.power = true;
  console.log('자동차 시동');
}

Car.prototype.moveTo = function(position) {
  console.log(`자동차 이동 = 현재 위치: {${this.position}}`);

  if (!this.power) {
    console.log('자동차의 시동이 꺼져있습니다.');
    return;
  }

  this.position = position;
  console.log(`자동차 이동 = 이동 위치: {${this.position}}`);
}

const car = new Car();
car.start();
car.moveTo(10);
  • 결과적으로 객체를 정의(변수와 메서드)하고 객체를 생성해서 만들어진 객체를 사용하는 것을 의미

3. FP(함수형 프로그래밍) 

  • 프로그래밍하려는 문제를 함수들의 정의와 조합을 통해서 해결하는 프로그래밍 방법
  • 함수의 개념을 최우선적으로 사용해서 모든 문제를 해결하는 프로그래밍 기법
  • 순수함수의 장점과 같이 언제든 결과가 동일한 함수를 사용할 수 있고 그 함수를 이용해 조합 성을 높일 수 있다는 장점이 있음 
function start(car) {
  car.power = true;
  console.log('자동차 시동');
}

function moveTo(car, position) {
  console.log(`자동차 이동 = 현재 위치: {${car.position}}`);

  if (!car.power) {
    console.log('자동차의 시동이 꺼져있습니다.');
    return;
  }

  car.position += position;
  console.log(`자동차 이동 = 이동 위치: {${car.position}}`);
}

const car = { power: false, position: 0 };
start(car);
moveTo(car, 10);

위 예제와 달리 객체가 가진 기능을 사용하지 않고 오롯이 함수를 정의하고 함수를 조합해서 결과를 만들어냄

 

차이점

  • 객체지향과 함수지향을 설계의 관점이 다름-> 객체지향은 "객체" 중심의 설계, 함수형은 "함수" 중심의 설계를 함
// 객체지향 프로그래밍
car.start();
car.moveTo(10);

// 함수형 프로그래밍
start(car);
moveTo(car, 10);
  • 객체지향은 Car와 같이 객체를 설계하고 생성해서 객체를 사용하는 반면, 함수지향은 객체와 무관하게 함수로 문제를 접근하고 해결

참고자료: https://7942yongdae.tistory.com/156


3. 인증방식 

1) 쿠키인증

  • Key-Value 형식의 문자열 덩어리
  • 클라이언트가 사이트 방문 시 서버를 통해 브라우저에 설치되는 작은 기록 파일
  • 단점
    • 보안에 취약(요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 위험)
    • 용량제한
    • 브라우저마다 쿠키 지원 형태 달라 브라우저간 공유  불가
    • 쿠키 사이즈 커질 수 록 네트워크 부하 심해짐

 

2) 세션인증

  • 쿠키의 보안적인 이슈때문에, 민감한 정보를 브라우저가 아닌 서버에 저장/ 관리 (서버 메모리 or 서버로컬파일, DB)
  • 인증방식은 세션을 서버에서 저장후 Sessiond Id를 클라이언트에 줘서 브라우저 쿠키에 저장, api 요청시 해당 Sessiond Id를 담아서 보냄
  • 단점
    • 세션ID 자체만으로는 유의미한 개인정보가 없지만 해커가 세션ID 탈취시 클라이언트인척 위장해서 서버로부터 민감한 정보를 받을 수 있는 한계가 있음 (서버에서 IP 특정을 통해 해결 가능)
    • 서버에서 세션 저장소 사용하므로 요청이 많아지면 서버 부하가 심해짐 

 

3) 토큰인증

  • 클라이언트가 서버에 접속하면 해당 클라이언트에 인증되었다는 '토큰'을 부여 
  • 이 토큰은 유일하며, 매 요청시 요청 헤더에 토근을 담아서 보내고 서버에서는 그 토큰의 일치여부만 확인 후 인증 
  • 장점: 기존의 세션 기반은 모든 정보를 서버에서 가지고 조회했어야 한다면 토큰은 클라이언트에 정보가 되기 때문에 서버의 부담을 덜 수 있다(위조 판별만 하면 됨)
  • 토큰은 앱과 서버가 통신 및 인증할 때 가장 많이 사용(웹에서는 쿠키와 세션이 있지만 앱은 없기 때문) 
  • 인증방식:  서버에서 유일한 토큰을 클라이언트에 전달 후 클라이언트는 쿠키나 스토리지에 저장하고 요청 시마다 헤더에 포함하여 전달, 토큰에 요청한 사람의 정보가 있기 떄문에 서버는 DB를 다시 조회하지 않고 누가 요청했는지 알 수 있다. 
  • 단점
    • 쿠키/세션과 다르게 토큰 자체의 길이가 길어 인증 요청 많을 수록 네트워크 부하가 심해짐 
    • Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없음
    • 토큰을 탈취 시 대처하기 어려움(따라서 사용기간 제한을 설정해서 극복) 

4) JWT(JSON Web Token)

  • 인증에 필요한 정보를 암호화시킨 JSON 토큰
  • JSON 데이터를 인코딩하여 직렬화한 것으로 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있음 
  • JWT 구조
    •  JWT는 . 을 구분자로 나누어지는 세 가지 문자열의 조합이다. . 을 기준으로 좌측부터 HeaderPayloadSignature를 의미한다.
  • 인증방식: 클라이언트로부터 받은 JWT의 헤더, 페이로드를 서버의 key값을 이용해 시그니처를 다시 만들고 이를 비교하며 일치했을 경우 인증을 통과시킨다.
  • 장점: 
    • Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조 막을 수 있음
    • 인증 정보에 대한 별도 저장소 필요 없음
    • JWT는 토큰에 대한 기본 정보 및 검증됬음을 서명하는 모든 정보를 자체적으로 지니고 있음
    • 세션과 다르게 서버는 상태를 가지지 않으므로 서버 확장성이 좋아짐
    • 쿠키와 달리 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유 가능
    • OAuth의 경우 소셜계정 이용 다른 웹서비스 로그인 할 수 있고
    • 세션과 달리 모바일 어플리케이션 환경에서도 잘 동작함 
  • 단점: 
    • 토큰 자체에 모든 정보가 있으므로 양날의 검
    • 토큰길이가 길기 때문에 네트워크 부하 줄 수 있음
    • Payload 자체는 암호화된 것이 아니라 인코딩된 것이기 때문에 중간에 탈취당해 디코딩 시 데이터 볼 수 있어 중요한 데이터를 넣지 않아야 됨
    • 서버는 무상태로 토큰 자체를 탈취 시 대처하기 어려움 

 

5) Access Token / Refresh Token 방식

  • 토큰 탈취의 위험성 때문에 현업에서는 Access Token, Refresh Token 으로 이중으로 나누어 인증을 하는 방식을 택함 
  • Access Token : 클라이언트가 갖고있는 실제로 유저의 정보가 담긴 토큰으로, 클라이언트에서 요청이 오면 서버에서 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행
  • Refresh Token: 새로운 Access Token을 발급해주기 위해 사용하는 토큰으로 짧은 수명을 가지는 Access Token에게 새로운 토큰을 발급해주기 위해 사용. 해당 토큰은 보통 데이터베이스에 유저 정보와 같이 기록.
  • 정리하자면, Access Token은 접근에 관여하는 토큰, Refresh Token은 재발급에 관여하는 토큰의 역할로 사용되는 JWT 이라고 말할 수 있다.

 

참고자료: https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC