네트워크, 통신, 자료구조

2진법

• 문제 해결 : 입력을 전달받아 출력을 만들어내는 과정
• 비트 : 0과 1만 가질 수 있는 측정 단위
• 바이트 : 1개의 비트로는 큰 양의 데이터를 나타내기 힘듦 -> 여덟 개의 비트를 모아 만든 바이트 탄생.

정보의 표현

• 문자, 사진, 영상 등 다양한 정보를 처리하는 방식
  - 픽셀로 이루어짐 (빨간, 초록, 파랑)
  • 세 가지 색을 서로 다른 비율로 조합하여 특정한 색을 표현
  • RGB 코드(숫자)로 영상 또는 수많은 그림, 음표를 숫자로 표현하여 빠르게 연속적으로 이어붙여놓음
• ASCII code :
  - 대문자 A는 65, 소문자 a는 97

알고리즘

• 입력에서 받은 자료를 출력 형태로 만드는 처리 과정
• 규칙들의 순서적 나열 (효율 + 정확)

TCP/IP

• 데이터를 디지털 신호로 바꾸어 전달하면서 네트워크 통신이 이루어짐
• 네트워크 통신을 위해 정해놓은 공통된 메뉴얼을 프로토콜이라고 함
• TCP/ IP는 4개의 계층으로 이루어짐 : Application Layer(특정 서비스 제공위해 애플리케이션 끼리 정보 주고받음 => DNS, HTTP), Transport Layer(송신된 데이터를 수신측 앱에 확실히 전달 TCP, UDP), Internet Layer(수신 측 까지 데이터를 전달하기 위해 사용), Network Access Layer (네트워크에 직접 연결된 기기 간 전송을 할 수 있도록 함)

가비지 컬렉터

• 애플리케이션이 할당한 메모리 공간을 주기적으로 검사하여 더 이상 사용되지 않는 메모리를 해제하는 기능.

• 자바스크립트는 매니지드 언어. 즉, 메모리의 할당 및 해제를 위한 메모리 관리 기능을 언어 차원에서 담당하고 개발자의 직접적인 메모리 제어를 허용하지 않는다. (개발자가 명시적으로 메모리 할당 및 해제 불가능)

• C언어처럼 언매니지드 언어는 malloc과 free()와 같은 기능으로 할당 및 해제를 하게됨.

• stack : 정적으로 할당한 메모리 영역. 원시 타입의 데이터가 값과 함께 할당. heap 영역에 생성된 object 타입의 데이터의 참조 값 할당

• heap : 동적으로 할당한 메모리 영역. 모든 object 타입의 데이터가 할당. heap 영역의 object를 가리키는 참조 변수가 stack에 할당. (= unreachable data)

garbage collerctor 과정
1. 가비지 컬렉터가 스택의 모든 변수를 스캔하면서 각각 어떤 객체를 참조하고 있는지 찾아서 마킹
2. reachable object가 참조하고 있는 객체도 찾아서 마킹
3. 마킹되지 않은 객체를 heap에서 제거한다.

• 가비지 : 더이상 사용되어지지 않고 release되지 않은 메모리
• 메모리 life cycle : allocate memory -> use memory -> release memory
• 메모리 : 0 과 1로 표현된 값과 그 값이 어디에 저장되어있는지 주소를 나타냄
• 변수에 값을 저장하는순간 allocate 가 일어남.

프론트엔드 보안

• XXS
• CSRF
• JWT
• OAUTH
• HTTPONLY
• sliding session, refresh token
• SSL/ TLS1.3 : 가성비 좋은 보안 (HTTPS 사용)
• 해킹 방법

local storage, cookie, session

• 쿠키: 브라우저에 저장되는 작은 크기의 문자열
  - 넷스케이스에 방문한 적이 있는지 체크하기위해 처음 사용하게됨.

  • 비연결성, 무상태성 => 현재 사용자가 방문했는지 알 수 없음
    주로 서버에서 사용. 요청시 headers에 실려서 전송하게됨
    만료 기간 지정 가능
    만료 기간이 존재한다면 영구 쿠키, 만료 기간이 없다면 세션 쿠키(브라우저 종료 시 삭제됨)
    퍼스트파티 쿠키 = 같은 도메인에서 생성된 쿠키 (서브 도메인도 포함)
    서드파티쿠키 : 다른 도메인에서 생성된 쿠키 => 원래 사이트 스크립트가 존재한다면 (사용자의 방문 사이트 파악 = 광고)

    쿠키의 문제점 :

  1. CSRF(자동으로 연결된다는 특징을 이용해 사이트에 로그인이 되어있는 경우 사용자의 비번을 바꾸거나 결제 요청을 하는 등), XSS(사용자의 민감한 정보를 탈취 = 토큰같은것)에 노출되어있음
  2. http 요청 시 자동으로 모든 쿠키를 전송한다는 문제점이 존재 => 불필요한 트래픽 증가

• 웹 스토리지 : 5MB의 저장 용량, 요청시 headers에 전송하지않아 트래픽 문제 및 쿠키의 CSRF 문제 해결, 문자열만 저장 가능해 직렬화를 통해 객체 저장 가능하게됨
  => 직렬화, 역직렬화가 필요 그래서 JSON.parse와 stringify가 필요
  - 브라우저 미지원
  - 웹 스토리지 비활성화 설정시 에러 처리 필수(에러 핸들링)
  - XSS에 취약 + 자바스크립트로 접근 가능해짐
  - 브라우저/탭간 공유 불가 => 독립된 스토리지
  - 만료기간 설정 불가
  - 동기적으로 실행되어 메인 스레드 블로킹하게됨 (큰 데이터 다룰때 조심)

• 로컬 스토리지 => 저장범위(도메인/브라우저) + 직접 삭제시만 삭제됨

• 세션 스토리지 => 저장범위(도메인, 브라우저, 탭) + 탭 종료시 삭제됨

• 둘 다 보완 문제가 잇어 민감한 정보 저장하지 않기

• 쿠키: 기간 설정, 서버 전송등 작은 용량 => 비로그인 장바구니, n일 동안 보지않기

• 세션 스토리지 : 탭 종료시 삭제되어도 ok인 경우 사용, 이전 페이지 저장 및 이전 스크롤 위치 저장

• 로컬 스토리지 : 브라우저 종료 시 유지 : 사용자 설정 저장, 글 임시 저장

보안문제 해결 방안
XSS = httpOnly => 자바스크립트로 접근 불가 / innerHTML 사용하지 않기 (사용자의 입력이 자바스크립트 코드로 실행될 수 있는 코드 작성하지 않기)
=> 사용해야한다면 sanitize-html, DOMPurify 사용하기

CSRF = SameSite, Referer 검증 => 같은 도메인의 요청에만 쿠키를 전송, 요청 온 사이트의 도메인을 확인할 수 있음 (크롬은 어느정도 대체되어있음)

• 인증 : 서비스에 등록된 유저의 신원을 입증하는 과정
• 인가 : 인증된 사용자에 대한 자원 접근 권한 확인
  자원을 적절한, 유효한 사용자에게 전달 및 공개하기 위한 방법

문제의 시초: HTTP로 클라이언트와 서버가 통신을 하는데 HTTP는 무상태성, 비연결성을 지향. 즉, 상태를 가지고 있지 않음. 하지만 인증과 인가는 상태를 저장한다는 것에서 시작 -> 두 패러다임의 충돌.
이 패러다임을 해소해야하겠다...

1. 인증하기 => Request Header
   • 문제점 : 매번 인증을 해줘야 한다.
2. 인증 유지하기 => Browser
   • 브라우저의 스토리지를 통해 위의 문제 해결
   • 해커 입장에서도 편리. 편하게 정버를 가져갈 수 있기 때문
3. 안전하게 인증하기 => Server session
   • 보안 향상위해 서버 사용. session 활용
   • 원하는 자원을 session이라는 인증된 사용자 식별자에 session id를 할당해 값을 서버에 저장
   • 해커가 정보를 가지고 가더라도 클라이언트보다는 덜 위험
   • 만료기간 지나도 시간 지나면 유효하지 않다
   • 서버에서 관리 (삭제해버리면 문제없음)
   • 단점 : 만약 여러개의 서버가 존재시 같은 사이트라도 다른 서버에 가면 해당 session id가 valid하지 않음 (왜냐면 세션 아이디가 없으니까)
   • 해결: 위의 문제는 서버 하나하나가 세션 아이디를 관리해서 생긴 문제. 해당 문제를 해결하기 위해 세션 스토리지를 둬서 그 스토리지에서 세션 아이디를 관리하게됨
4. 효율적으로 인증하기 => Token
   • 위의 문제: 클라이언트가 미친듯이 많아지면 서버가 터짐
   • 정보의 흐름에 문제를 맡겨보자. 정보의 콘텐츠 안에 사용자 정보를 담아보자 = 토큰 활용
   • JSON Web Token (JWT) => secret key를 사용해서 JWT를 만들어냄. 시크릿 키를 사용해서 JWT에 인증과정을 거침. (해독하기는 매우 쉬워서 민감한 정보를 주면 안됨) =< 서버 내부에서 잘 관리해야한다.
   • 로그인을 하고 요청을 보낸다 => DB와 연결됨 -> 토큰을 주면 클라이언트의 키와 값에 쿠키값 저장하게됨
   • 이 토큰의 유효성 검사를 자신이 가진 시크릿 키로 검사를 함 =< 유효하지않음 버리고 아니면 사용자 정보 파악 (이름 = 유저이름, 만료시기, 권한 등...)
   • 장점: 여러개의 서버가 존재한다면 자기가 가진 시크릿 키로 해독하고 요청을 반환하면된다 => 서버 시스템의 확장성에 긍정적 영향 (각자 해독해서 인증할 수 있음)
   • 단점 : 해킹당하기 쉬움 (access token 탈취당하면 사용자와 동등하게 자원에 접근가능하게됨)
   • 만료기간을 사용하는데 만료기간 설정하면 해커도 접근못하지만 사용자도 접근못함
   • refresh token으로 해결. refresh token과 access token을 둘 다 생성하게됨.
   • access token은 저장하지않고 refresh token만 저장하게됨. 이 둘을 헤더로 보내서 클라이언트에 저장하게됨. 클라이언트는 access token을 보내 정보 받음. 하지만 access token이 만료된경우 서버는 만료되었다고 말하면 브라우저단에서는 access, refresh를 둘 다 보내고 서버에서는 refresh token을 가지고 새로운 access token을 반환하게됨. 이 업데이트 토큰을 사용할 수 있게 됨
   • 토큰으로 상태관리 하기에 따로 세션을 둘 필요없다. 토큰 관리해야하고 보완도 신경써야한다.

Restful API

• Interface : 사용자와 기계의 소통 창구

• API : 소프트웨어가 다른 소프트웨어에게 지정된 형식으로 요쳥, 명령을 받을 수 있는 수단

• 예를 들어서 Windows API가 있는데 윈도우 개발자들이 이런 명령어를 치면 이런 동작을 할꺼야 라고 정해져있음. 그러면 개발자들은 그 명령어를 사용해 활용하면 됨.

• 브라우저에는 Web API를 활용하여 자바스크립트로부터 명령을받아 동작을 수행함.

• Rest API : 과거의 SOAP이란 복잡한 방식을 대체한 것.
  특징

  • 각 요이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다.
  • 만약 혼자서 평생 만들고 유지보수를 한다면 이름따위 상관없음. 하지만 다른 개발자와 협업하거나 인수인계할 때, 이름이 명확하지 않으면 협업하기 힘듦.
  • Restful한 것은 이름만으로도 어떤 역할을 하는지 알 수 있음.
  • 예시) https://(도메인)/classes/2/students?page=2&count=10

• Rest API에서는 5가지 방식이 있음
  1) GET, PUT, POST, PATCH, DELETE

• GET: data read (조회에 사용)

• PUT: payload 존재 = 정보를 통채로 갈아끼울 때 사용

• POST: payload 존재 (data create (새 학생 정보 추가 )

• PATCH: payload 존재 ( 변경된 부분만 업데이트, 일부만 특정하게 바꿀때)

• DELETE: 삭제
  -> URI는 동사가 아닌 명사로 이루어져야한다.

• 장점 : 메소드와 API를 조합해서 예측 가능하고 일정한 정보와 작업을 요청하는 것

• 단점 : 원하지 않는 정보까지 다 보내옴
  - 예시) 도메인/classes/반 idx/ students 정보만 요청했는데 성별, 보호자, 연락처, 주소까지 다 넘어옴

  • 즉, 데이터 양 측면에서 소모가 큼
  • 요청을 여러번 보내야함

• 즉, Rest API는 어떤 URI에 어떤 메서드를 사용할지 만든 약속

graph ql

• 원하는 정보만 요청하고 받을 수 있음.

• 여러 depth들의 정보를 한번에 받아올 수 있음.

• 요청은 graphql 의 post => mutation은 영향을 미침.

• 정보가 정해져있고 많은 경우 Rest API 가 더 효율적일 수 있음.

Blocking, non-blocking

• 다른 주체가 작업할 때 자신의 제어권이 있는지 없는지

Synchronous vs Asynchronous

• 동기 : 끝남과 동시에 시작한다.+ 블로킹
• 비동기 : 끝남과 시작이 동시에 이루어지지 않는다. + 논 블로킹