고민의 흔적

로그인, 쿠키와 세션, JWT 토큰

HTTP란?

stateless 하다. 연결을 끊는 순간 사용자와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

브라우저에서 상태를 유지하는 방법

• 쿠키와 세션
• 토큰 기반 방식

세션

서버와 클라이언트의 연결이 활성화된 상태

세션 ID

웹 서버 메모리에 저장되는 클라이언트에 대한 유니크한 ID(서버 또는 데이터베이스에 저장)

쿠키

• 키 - 값으로 구성된 작은 데이터 조각
• 쿠키에 담긴 데이터는 브라우저에서 관리된다. 하지만 보통 만료 날짜를 서버에서 설정한다.
• 이름, 값, 만료 날짜 등으로 구성

쿠키와 세션

1. 처음 로그인 -> 쿠키, 세션 ID 생성 그 이후 다시 요청했을 때 HTTP 헤더에 쿠키를 포함시켜 요청한다.
2. 해당 쿠키에 맞는 세션 ID로 전에 로그인했던 아이디인지 확인
3. 로그인을 유지

XSS(Cross Site Scripting)

쿠키는 클라이언트에서 자바스크립트로 조회가 가능하다. 공격자들이 자바스크립트로 쿠키를 가로채고자 시도를 하는데 이를 XSS라고 한다.

해결 방법 : HTTP Only Cookie 또는 secure cookie를 사용한다.

• Set-Cookie : 쿠키명 = 쿠키값; path=/ ; secure
• Set-Cookie : 쿠키명 = 쿠키값; path=/ ; HttpOnly

보통은 HTTP 관련 라이브러리에 적혀있는 대로 사용한다.

ex) axios.defaults.withCredentials = true;

쿠키 - 세션 방식의 단점

로그인할 때마다 세션 ID를 저장해야 돼서 로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부하 등 악영향을 미친다. 

토큰 기반 인증 방식

JWT토큰 인증은 토큰 기반 인증서버를 통해서 하게 하고 서버는 stateless 하게 내버려 두자. 요청 -> 토큰 생성 -> 이후 사용자가 토큰을 헤더(authoriztion 키에 넣어서 요청, 이 토큰을 기반으로)

JWT(JSON Web Token, RFC 7519)

헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩 된다. 메세지 인증, 암호화에 사용

Header

어떠한 방법의 서명 알고리즘을 사용할 것인가에 대한 정보

Payload

데이터, 토큰 발급자, 토큰 유효기간(인증이 필요한 최소한의 정보만)

Signature

헤더에 정의된 알고리즘으로 인코딩된 헤더와 페이로드를 합친 값, 그리고 비밀키를 기반으로 생성된 서명 값

JWT 장점

사용자가 인증되면 사용자는 모든 시스템에서 사용할 수 있는 보안 토큰을 받습니다. 즉, 단일 엔드포인트를 생성해서 다른 모든 서버 간의 API 상호작용을 인증할 수 있다는 점에서 좋다.

JWT의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없다.

확장성, 디버깅, 사이즈가 작음, JWT토큰 자체가 독립적이다.

JWT 단점

더 많은 필드가 추가되면 토큰이 비대해져 트래픽에 영향

탈취하여 디코딩하면 데이터를 볼 수 있다.

브라우저 렌더링 과정

1. DOM 트리 구축

하나의 html 페이지는 div, span 등 각각의 요소를 가진다. 각 요소는 하나하나 노드로 설정이 되어 트리 형태로 저장된다. 이를 DOM 트리라고 한다. 예를 들어 div > span, span이 있다면 div라는 부모 노드 밑에 span이라는 자식 노드가 2개 생기는 것이다.

2. 렌더 트리와 렌더 레이어 생성

각각의 노드는 CSS파서에 의해 정해진 스타일 규칙이 적용되어 있다. span.color="red"는 노드 색깔이 빨간색이다 등을 말한다. 이런 규칙에 따라 CSSOM이라는 트리가 만들어지고 미리 만들어놓은 DOM트리 내에 있는 노드와 함께 렌더 객체가 생성되며 이들이 모여 병렬적인 렌더 트리가 생성된다. 상속적인 스타일은 부모 노드에만 위치하도록 설계하는 등의 최적화를 거쳐 렌더 레이어가 완성된다.

3. 렌더 레이어를 대상으로 Layout설정

이때 좌표는 보통 부모를 기준으로 설정된다. Global Layout은 브라우저 사이즈가 증가하거나 폰트 사이즈가 커지면 변경된다.

4. 렌더레이어를 대상으로 칠하기

픽셀마다 점을 찍듯 칠한다. 이를 레스터화라고도 한다.

5. 레이어 합치기 및 표기

각각의 레이어로부터 비트맵이 생성되고 GPU에 텍스처로 업로드된다. 그다음 택스처들은 서로 합쳐져 하나의 이미지로 렌더링 되며 화면으로 출력된다.

웹 브라우저의 캐시

대표적인 캐시로는 웹 브라우저의 작은 저장소 쿠키, 로컬 스토리지, 세션 스토리지가 있다. 이러한 것들은 보통 사용자의 커스텀한 정보나 인증 모듈 관련 사항들을 웹 브라우저에 저장해서 추후 서버에 요청할 때 자신을 나타내는 아이덴티티나 중복 요청 방지를 위해 쓰인다.

쿠키

쿠키는 만료기한이 있는 키 - 값 저장소이다. same site 옵션을 strict로 설정하지 않았을 경우 다른 도메인에서 요청했을 때 자동 전송되며, 4KB까지 데이터를 저장할 수 있고 만료기한을 정할 수 있다. 쿠키를 설정할 때는 document.cookie로 쿠키를 볼 수 없게 httponly 옵션을 거는 것이 중요하며, 클라이언트 또는 서버에서 만료기한 등을 정할 수 있는데 보통 서버에서 만료기한을 정한다.

로컬 스토리지

로컬 스토리지는 만료기한이 없는 키 - 값 저장소이다. 10MB까지 저장할 수 있으며 웹브라우저를 닫아도 유지되고 도메인 단위로 저장, 생성된다. 클라이언트에서만 수정 가능하다.

세션 스토리지

세션 스토리지는 만료기한이 없는 키 - 값 저장소이다. 탭 단위로 세션 스토리지를 생성하며, 탭을 닫을 때 해당 데이터가 삭제된다. 5MB까지 저장이 가능하다. 클라이언트에서만 수정 가능하다.

HTTP의 상태 코드

1xx(정보)

요청을 받았으며 프로세스를 계속한다.

2xx(성공)

요청을 성공적으로 받았으며 인식했고 수용한다.

• 200 OK : 요청을 성공적으로 되었습니다.
• 201 Created : 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었다.

3xx(리다이렉션)

요청 완료를 위해 추가 작업 조치가 필요하다

• 301 Moved perma nently : 이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미한다. 변경된 새로운 URI를 응답에서 주는 것이 좋다.

4xx(클라이언트 오류)

요청의 문법이 잘못되었거나 요청을 처리할 수 없다.

• 400 Bad Request : 이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미한다.
• 401 Unauthorized : 클라이언트의 인증이 되지 않음을 의미한다.

5xx(서버 오류)

서버가 명백히 유효한 요청에 대해 충족을 실패했다.

• 500 Internal Server Error : 서버에 오류가 있음을 의미한다.

HTTP의 메서드

POST : 자원을 생성

보통 하위 자원을 생성한다. 성공적으로 생성되면 HTTP 상태 201을 반환

GET : 읽기

성공 시 200, 오류의 경우 가장 자주 404(Not Found) 또는 400(Bad Request)을 반환한다. 데이터를 수정, 삭제하는데 반드시 사용하면 안 된다.

PUT : 업데이트(전체 자원)

요청을 보낼 때 전체를 보내야 한다.

PATCH : 업데이트(일부 자원)

요청을 보낼 때 수정하는 일부분을 보내야 한다.

DELETE : 삭제

REST API

API란?

API는 소프트웨어와 소프트웨어 사이 데이터 전송을 가능하게 하는 프로그램이다.

Uniform-Interface

자원들이 각각의 독립적인 인터페이스를 가져야 한다.

• 웹페이지를 변경했다고 웹 브라우저를 업데이트하는 일은 없어야 된다.
• HTTP 명세나 HTML 명세가 변경되어도 웹페이지는 잘 작동해야 한다.

REST API 아키텍처 규칙

1. Self - descriptive messages

HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 한다.

예를 들어. json을 반환한다면 application/json으로 명시해주어야 한다. MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준이다. 'font/ttf', 'text/plain', 'text/csv' 등

2. HATEOAS 구조

하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 한다.

3. Stateless

이 규칙은 HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 만족된다. 즉 REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미이다.

4. Cacheable

HTTP는 원래 캐싱이 된다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css이미지 등을 불러오는 것을 볼 수 있다. 이러한 캐싱은 네트워크 요청을 줄여주며 이는 UX 향상에도 도움이 된다. 네트워크 요청 시 해당되는 자원들을 복사해서 메모리에 저장해두었다가 또 같은 요청 시 네트워크 요청을 하지 않고 브라우저 메모리에 있던 자원을 다시 반환한다. HTTP 메서드 중 GET에 한정되며 Cache-Control:max-age=100(100초) 이런 식으로 한정된 시간을 정할 수가 있다. 캐싱된 데이터가 유효한지 판단하기 위해 Last-modifed와 Etag를 쓴다. Etag는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것이다.

5. Client-Server 구조

클라이언트와 서버가 서로 독립적인 구조를 가져야 한다. 물론 이는 HTTP를 통해 가능한 구조이다. 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 된다. 서버는 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 된다. 클라이언트에서는 HTTP로 받는 로직만 잘 처리하면 된다.

6. Layered System

계층구조로 아키텍처를 만들 수 있다는 것을 뜻한다.

URI 규칙

1. 동작은 HTTP 메서드로 해야 한다. 수정 = put, 삭제 = delete, 추가 = post, 조회 = get을 이용해야 한다. 예를 들어 /books/delete/1 이렇게 표기하면 안 된다.
2. 확장자는 표기하지 말아야 한다.
3. 동사가 아닌 명사로만 표기해야 한다. 유저가 책을 소유한다라고 하려면 유저/유저아이디/inclusion/책/책 아이디
4. URI는 계층적인 내용을 담고 있다. /집/아파트/전세 이런 식으로 내려가야 한다.
5. 소문자로 쓰며 너무 길 경우에는 *****-**** 를 쓴다.
6. HTTP 응답 상태 코드를 활용한다.

도서관 시스템의 REST API 예시

get('/books/') : 모든 책을 조회한다.

post('/books/booksid') : 책을 생성한다.

put('/books/'booksid) : 책을 수정한다.

get('/books/booksid') : 특정 책을 조회한다.

put('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.

patch('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다. 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있다.

RTT

패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복 시간

RTT 증가를 해결하기 위한 방법

매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답 시간이 길어졌다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용했다.

이미지 스플리팅

많은 이미지를 다운로드하게 되면 과부하가 걸리기 때문에 많은 이미지가 협쳐 있는 하나 이미지를 다운로드하고, 이를 기반으로 background-image의 position을 이용해 이미지를 표기하는 방법이다.

코드 압축

코드압축은 코드를 압축해 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법이다.

개행 문자, 띄어쓰기 등이 사라져 코드가 압축되면 코드 용량이 줄어든다.

이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법이다. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있다. 하지만 Base64 문자열로 변환할 경우 37% 정도 크기가 더 커지는 단점이 있다.

HTTP/1.1

매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다. 한번 TCP 3-way-shake 가 발생하면 그다음부터 발생하지 않는 것을 볼 수 있다. 하지만 문서 안에 포함된 다수의 리소스(이미지, css, script)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.

HOL Blocking

HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다. 예를 들어 image.jpg와 style.css, data.xml을 다운로드받을 때 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 된다.

무거운 헤더 구조

HTTP/1.1의 헤더에는 쿠키등 많은 메타데이터가 들어 있고 압축이 되지 않아 무거웠다.

HTTP/2.0

HTTP/2.0은 HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위를 처리를 지원하는 프로토콜이다.

멀티플렉싱

멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것이다. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다. 멀티플렉싱을 통해 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고 응답을 줄 수 있다. 이렇게 되면 HTTP/1.x에서 발생하는 HOL Blocking을 해결할 수 있다.

스트림

시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

헤더 압축

HTTP/1.x에서 크기가 큰 헤더의 문제를 HTTP/2.0에서는 헤더 압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.

허프만 코딩

문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트 양을 줄이는 원리이다.

서버 푸시

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있었다면, HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

HTTPS

HTTP/2는 HTTPS 위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청이다.

SSL/TLS

SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜이다. 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제삼자가 메시지를 도청하거나 변조하지 못하도록 한다. SSL/TLS를 통해 공격자가 서비인 척하며 사용자 정보를 가로채는 네트워크 상의 인터셉터를 방지할 수 있다.

SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다. 참고로 TLS 1.3은 사용자가 이전에 방문한 사이트로 다시 방문한다면 SSL/TLS에서 보안 세션을 만들 때 걸리는 통신을 하지 않아도 된다. 이를 0-RTT라 한다.

보안 세션

보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다. 클라이언트와 서버와 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 한 번의 1-RTT가 생긴 후 데이터를 송수신하는 것을 볼 수 있다. 클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인한다. 제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화된 데이터의 송수신이 시작된다.

사이퍼 슈트

사이퍼 슈트는 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 말하며 다섯 개가 있다.

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

TLS_AES_128_GCM_SHA256에는 세가지 규약이 들어 있는데 TLS는 프로토콜, AES_128_GCM은 AEAD 사이퍼 모드, SHA256은 해싱 알고리즘을 뜻한다.

AEAD 사이퍼 모드

AEAD는 데이터 암호화 알고리즘이며 AES_128_GCM 등이 있다. 예를 들어 AES_128_GCM이라는 것은 128비트의 키를 사용하는 표준 블록 함호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻한다.

암호화 알고리즘

키 교환 암호화 알고리즘으로는 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용한다. 둘 다 디피-헬만 방식을 근간으로 만들어졌다.

디피-헬만 키 교환 암호화 알고리즘

디피-헬만 키 교환 암호화 알고리즘은 암호키를 교환하는 하나의 방법이다.

처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유한다. 각자 비밀 값과 또 혼합한다. 그 이후에 공통의 암호키가 생성되는 것이다.

SHA-256 알고리즘

SHA-256 알고리즘은 해시 함수의 결괏값이 256비트인 알고리즘이며 해싱을 해야 할 메세지에 1을 추가하는 등 전처리를 하고 전 처리된 메시지를 기반으로 해시를 반환한다.

HTTPS 구축 방법

직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축하거나, 서버 앞단의 HTTPS를 제공하는 로드밸런서를 두거나, 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다.

HTTP/3

TCP 위에서 돌아가는 HTTP/2와는 달리 HTTP/3은 QUIC이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.

QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way-handshake과정을 거치지 않아도 된다. QUIC는 첫 연결 설정에 1-RTT만 소요된다. QUIC는 순방향 오류 수정 메커니즘이 적용되었다. 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.