프론트엔드Explorer

HTTP 2.0이라고도 불리는 HTTP/2는 Hypertext Transfer Protocol Version 2의 약자이다. 

2015년 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구, 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업 기구)에 의해 공식적으로 발표된 HTTP/1.1(기존 표준)의 차기 버전이다. 

HTTP/1.x이 느린 이유

HTTP/1.x이 느린 이유, 바꿔 말하면 HTTP 2.0이 등장하게 된 배경은 아래와 같다. 

위의 사진만 봐도 알 수 있듯, HTTP 1.0버전대만 하더라도, Request를 날릴 때마다 Connection을 새로 생성했다. 

Short-lived connections는 너무 비효율적이어서, HTTP 1.1에서는 Persistent Connection이라는 개념과 HTTP Pipelining이라는 개념이 만들어졌다. 

커넥션을 재사용할 수 있고, request를 미리 여러 개 서버에 날릴수도 있게 되었다. 

그러나 이러한 개선에도 불구하고, request를 보낸 순서대로 response를 받을 수 있다는 지점에서 문제가 발생했다. 

HOL(Head of line) blocking (특정 응답 지연)

만약, 처음에 요청한 request에 문제가 발생해 응답이 늦어질 경우, 

2번째, 3번째에 요청한 request의 응답도 같이 늦어진다는 문제점이 발생한다. 

RTT(Round Trip Time) 증가 (양방향 지연) 

Round Trip Time은 네트워크 시작 지점에서 대상 지점으로 이동하고 시작 지점으로 다시 이동하는 데 걸리는 시간이다. 

앞서 말한 것처럼 매 요청별로 connection을 만들게 되고, TCP 상에서 동작하는 HTTP의 특성상 3-way-Handshake가 반복적으로 일어나게 되며, 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하시키게 된다. 

무거운 헤더(특히 쿠키)

HTTP 1.x의 헤더에는 많은 메타 정보들이 저장되어 있다. 

사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데, 이 경우 매 요청마다 중복된 헤더 값을 전송하게 되며, 각 도메인에 설정된 쿠키 정보도 매 요청마다 헤더에 포함되어 전송된다. (전송값보다 헤더가 더 큰 경우도 있다) 

문제점들을 해결하기 위한 UI & 프론트엔드 개발자의 노력

• 이미지 스프라이트 
  • 여러 개의 이미지를 하나의 이미지로 합쳐서 관리하는 이미지(사용할 때는 좌표 범위로 구분해 사용)

• 도메인 샤딩
  • 리소스를 여러 개의 도메인으로 나누어 저장하여, 페이지 로드 시간을 빠르게 하는 일종의 트릭 혹은 방법
  • 여러 개의 도메인으로 나누어진 리소스를 다운받기 때문에 브라우저는 더 많은 리소스를 한 번에 받을 수 있다. 
  • 최신 브라우저들은 보통 한 도메인에 약 6개의 동시 다운로드를 제공한다. 
  • 이 개수를 초과하는 페이지의 경우, 초과하는 개수를 6으로 나눈 도메인에 리소를 뿌려두면, 병렬적으로 리소스들을 다운 받을 수 있다. 

• CSS/JavaScript 압축
• Data URI

HTTP 2.0의 등장 

SPDY

구글은 더 빠른 WEB을 실형하기 위해 Latency 관점에서 HTTP를 고속화한 SPDY라 불리는 새 프로토콜을 만들었다. 

SPDY는 HTTP를 대치하는 프로토콜이 아니라, HTTP를 통한 전송을 재정의하는 형태로 만들어졌다. 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고, 이는 HTTP/2.0 초안의 참고 규격이 되었다. 

HTTP 2.0은 완전히 새로운 프로토콜이 아니라 SPDY의 개선사항을 적용해 성능 향상에 초점을 맞춘 프로토콜이라고 생각하면 될 것 같다. 

HTTP 2.0이 빠른 이유 

1. Multiplexed Streams - 한 커넥션에 여러개의 메시지를 동시에 주고받을 수 있고, 응답은 순서에 상관없이 stream으로 주고 받는다. 
2. 요청이 커넥션 상에서 다중화되므로 HOL(Head Of Line) Blocking이 발생하지 않음 
3. Stream Prioritization(요청 리소스 간 의존관계를 설정) - 클라이언트가 요청한 HTML 문서 안에 CSS 파일 1개와 Image 파일 2개가 존재하고, 이를 클라이언트가 각각 요청한 후, Image 파일 보다 CSS 파일의 수신이 늦어지는 경우, 브라우저의 렌더링이 늦어지는 문제가 발생한다. HTTP/2의 경우 리소스 간 의존 관계(우선 순위)를 설정해 이런 문제를 해결했다. 
4. Header Compression(Header 정보를 HPACK 압축 방식을 이용하여 압축 전송) - HTTP/2에서는 Header에 중복값이 존재하는 경우, Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고, 중복된 Header는 index 값만 전송하고 중복되지 않은 Header 정보의 값은 Huffman Encoding 기법으로 인코딩 처리하여 전송한다. 
5. Server Push(HTML 문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음) - 클라이언트가 HTML 문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image,...)가 포함되어 있는 경우, HTTP/1.1에서는 클라이언트는 요청한 HTML 문서를 수신한 후, HTML 문서를 해석하면서 필요한 리소스를 재요청하는 반면, HTTP/2에서는 Server Push 기법을 통해 클라이언트가 요청하지 않은 리소스를 push해주는 방법으로 클라이언트의 요청을 최소화하여 성능 향상을 이끌어냈다. PUSH_PROMISE라고 부르며, PUSH_PROMISE를 통해 서버가 전송한 리소스에 대해서 클라이언트는 요청하지 않는다. 
6. 프로토콜 협상 메커니즘 - 프로토콜 선택. like HTTP / 1.1, HTTP / 2 또는 기타 
7. HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태코드, URI 및 헤더 필드
8. 페이지 로딩 속도 향상

하지만, HTTP/2는 여전히 TCP를 이용하기 때문에 HandShake의 RTT(Round Trip Time)로 인한 Latency(지연 시간), TCP의 HOL Blocking은 해결할 수 없다. 

그래서 HTTP/3가 등장했다. 

다음 포스팅에서는 HTTP/3에 대해 알아보자. 

클라이언트가 한 두 명일때, 서버는 여유롭게 사용자가 원하는 결과를 응답해줄 수 있다. 

하지만 대규모의 서비스는 클라이언트가 수천만명 혹은 그 이상이다. 

아무리 성능이 뛰어난 서버라고 해도 모든 트래픽을 감당할 수 없다. 

그래서 기업들은 서버를 추가로 구비하고, 여러 대의 서버에 동일한 데이터를 저장하여

수많은 트래픽을 효과적으로 분산하게 된다. 

그런데, 단순히 다수의 서버를 구축해 운영한다고 해서 모든 클라이언트의 요청에 일관성 있게 응답할 수 있을까?

쏟아지는 트래픽을 여러 대의 서버로 분산해주는 기술이 없다면, 한 곳의 서버에 모든 트래픽이 몰리는 상황이 발생할 것이다.

이 때 필요한 기술이 바로 로드밸런싱이다! 

로드밸런서

로드밸런서는 서버에 가해지는 부하(=Load)를 분산(=balancing)해주는 장치 또는 기술을 말한다.

클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며,

한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 낼 수 있게 한다. 

위에서 언급한 엄청난 트래픽에 대처할 수 있는 방법은 크게 두 가지이다. 

바로, scale-up과 scale-out!

Scale-up

Scale-up은 서버 자체의 성능을 확장하는 것을 의미한다. 

비유하자면 CPU가 i3인 컴퓨터를 i9으로 업그레이드하는 것과 같다. 

Scale-out

Scale-out은 기존 서버와 동일하거나, 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것을 의미한다. 

이는 CPU가 i3인 컴퓨터를 여러 대 추가 구입해 운영하는 것에 비유할 수 있다. 

Scale-out의 방식으로 서버를 증설하기로 결정했다면, 

여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요하다. 

로드밸런서의 종류

로드밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다. 

2계층을 기준으로 부하를 분산한다면 L2, 3계층을 기준으로 부하를 분산한다면 L3. 

상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만 가격이 비싸진다. 

반대로, 하위 계층으로 갈수록 간단한 부하 분산이 가능하고 가격이 저렴해진다. 

로드밸런서의 기본 기능 

Health Check

기본적으로 보통의 로드 밸런서는 서버들(또는 다음의 노드)에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단할 수 있다. 

이로 인해 로드 밸런서가 있을 때, 서버 몇 대에 이상이 생기더라도 다른 정상 동작 중인 서버로 트래픽을 보내주는 Fail-over가 가능하다. 

또, TCP/UDP 분석이 가능하기 때문에 Firewall의 역할도 수행할 수 있다. 

• L3 체크 - ICMP를 이용해 서버의 IP 주소가 통신 가능한 상태인지 확인한다.
• L4 체크 - TCP는 3-Way-Handshaking(전송 >> 확인/전송 >> 확인)를 기반으로 통신한다. 이러한 TCP의 특성을 바탕으로 각 포트 상태를 체크하는 방식이다. 예를 들어, HTTP 웹 서버의 경우 80 포트를 사용하므로 TCP 80 포트에 대한 체크를 통해 서버가 살아있는 상태인지 확인한다. 
• L7 체크 - 어플리케이션 계층에서 체크한다. 즉, 실제 웹페이지(like index.html)에 통신을 시도하여 이상 유무를 파악한다. 

Tunneling 

눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 

로드밸런서는 클라이언트와 서버 간 중간에서 터널링을 제공해준다. 

즉, 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제하게 한다. 

NAT(Network Address Translation)

IP 주소를 변환해주는 기능이다. (목적지와 수신지의 IP 주소와 TCP/UDP 포트를 재기록하여 변환하며 네트워크 트래픽을 주고받을 수 있다)

예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드밸런서 외부의 공인 IP 주소로 변경해준다. (반대로도 가능하다)

이렇게 하면, 부족한 공인 IP 주소를 효율적으로 사용할 수 있지만, 로드밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소(VIP)를 통해 접속하는 것이 주 목적이다. 

• SNAT(Source Network Address Translation) - 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주솔르 외부의 공인 IP 주소로 변환하는 방식이다. 집에서 사용하는 공유기가 대표적인 예이다. 
• DNAT(Destination Network Address Translation) - 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식이다. 로드밸런서가 대표적인 예이다. 

DSR(Direct Server Routing)

서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음, 

네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트를 찾아가는 방식이다. 

이 경우, 로드밸런서의 부하를 줄여줄 수 있는 장점이 있다. 

로드밸런서가 동작하는 방법

로드밸런서는 대부분 아래와 같은 절차로 동작하게 된다. 

(1) 클라이언트의 브라우저에서 dolphinsarah.com이라고 입력

(2) 클라이언트에 설정된 메인 DNS 서버로 dolphinsarah.com의 IP 주소 문의 

(3) 메인 DNS 서버는 dolphinsarah.com 주소를 관리하는 별도의 DNS 서버에 IP 주소 문의

(4) 별도 관리 DNS 서버는 로드밸런서의 IP(Virtual IP)주소를 메인 DNS 서버에게 알려줌

(5) 메인 DNS 서버는 획득한 VIP 주소를 클라이언트에 전송

(6) 클라이언트에서 로드밸런서의 VIP 주소로 http 요청

(7) 로드밸런서는 별도 로드밸런싱 방법(like 라운드 로빈)을 통해 서버에 요청을 전송

(8) 서버의 작업 결과를 받은 로드밸런서는 전달 받은 http 결과를 클라이언트에 전송

로드밸런서가 서버를 선택하는 방법 - L4 계층

라운드로빈 방식(Round Robin Method)

서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합하다. 

가중 라운드로빈 방식(Weigthed Round Robin Method)

각각의 서버마다 가중치를 매기고, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분한다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이다. 예를 들어, A라는 서버가 5라는 가중치를 갖고, B라는 서버가 2라는 가중치를 갖는다면 로드밸런서는 라운드로빈 방식으로 A서버에 5개, B서버에 2개의 요청을 전달한다. 

IP 해시 방식(IP Hash Method)

클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식이다. 사용자의 IP를 해싱(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것 또는 그러한 함수)해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다. 

최소 연결 방식(Least Connection Method)

요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 우선적으로 트래픽을 배분한다. 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식이다. 

최소 리스폰타임(Least Response Time Method)

서버의 현재 연결 상태와 응답시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분한다. 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식이다. 

로드밸런서가 서버를 선택하는 방법 - L7 계층 

L7 로드밸런서는 위와 같은 L4 로드밸런서의 기능을 포함하는 것뿐만 아니라 OSI 7계층의 프로토콜(like HTTP, SMTP, FTP etc)을 바탕으로도 분산 처리가 가능하다. 

예를 들어, 온라인 쇼핑몰의 장바구니에 물건들을 담아놓았는데 다른 서버에서의 처리는 어려울 것이다. 

L7 로드밸런싱에는 다음과 같은 방법들이 있다. 

URL 스위칭 방식(URL Switching)

특정 하위 URL 들은 특정 서버로 처리하는 방식이다. 

예를 들어, '../image' 또는 '../video'와 같은 특정 URL을 가진 주소들은 서버가 아닌 별도의 스토리지에 있는 객체 데이터로 바로 연결되도록 구성할 수 있다. 

컨텍스트 스위칭 방식(Context Switching)

클라이언트가 요청한 특정 리소스에 대해 특정 서버 등으로 연결해줄 수 있다. 

예를 들어, 이미지 파일에 대해서는 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버/스토리지로 연결해줄 수 있다. 

쿠키 지속성(Persistence with Cookie)

쿠키 정보를 바탕으로 클라이언트가 연결했던 동일한 서버에 계속 할당해주는 방식이다. 

특히 사설 네트워크에 있던 클라이언트의 IP 주소가 공인 IP주소로 치환되어 전송하는 방식을 지원한다. 

위 포스팅은 아래 링크를 참고하여 작성했습니다.

https://www.stevenjlee.net/2020/06/30/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%9D%98-%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-load-balancing-%EA%B7%B8/?openLinerExtension=true

https://post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903&openLinerExtension=true

지난 포스팅에서는 토큰 기반 인증 시스템에 대해 알아보았다. 

이번 포스팅에서는, 토큰 기반 인증 시스템의 구현체인 JWT(JSON Web Token)에 대한 소개 후,

JWT 토큰의 기본 구조를 알아보자. 

JSON Web Token이란?

JSON Web Token(JWT)은 웹표준으로서, 두 개체에서 JSON 객체를 사용하여

가볍고 자가수용적인(self-contained) 방식으로 정보를 안정성 있게 전달해준다. 

• 수많은 프로그래밍 언어에서 지원된다 - JWT는 C, Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등 대부분의 주류 프로그래밍 언어에서 지원된다.
• 자가 수용적(self-contained)이다 - JWT는 필요한 모든 정보를 자체적으로 지니고 있다. JWT 시스템에서 발급된 토큰은, 토큰에 대한 기본 정보, 전달할 정보(로그인 시스템이라면 유저 정보), 그리고 토큰이 검증됐다는 것을 증명해주는 signature를 포함하고 있다. 
• 쉽게 전달될 수 있다 - JWT는 자가수용적이므로, 두 개체 사이에서 손쉽게 전달될 수 있다. 웹서버의 경우 HTTP의 헤더에 넣어서 전달할 수도 있고, URL의 파라미터로 전달할 수도 있다. 

JWT는 어떤 상황에서 사용될까?

아래와 같은 상황에서 JWT가 유용하게 사용될 수 있다. 

회원 인증

JWT를 사용하는 가장 흔한 시나리오다. 

유저가 로그인을 하면, 서버는 유저의 정보에 기반한 토큰을 발급하여 유저에게 전달해준다. 

그 후, 유저가 서버에 요청을 할때마다 JWT를 포함하여 전달한다. 

서버가 클라이언트에게서 요청을 받을 때마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 

유저가 요청한 작업에 관한 권한이 있는지 확인하여 작업을 처리한다. 

서버에서는 유저의 세션을 유지할 필요가 없다. 

즉, 유저가 로그인되어 있는지 아닌지 신경쓸 필요가 없고, 유저가 요청을 했을 때 토큰만 확인하면 되기 때문에,

세션 관리가 필요 없어서 서버 자원을 많이 아낄 수 있다. 

정보 교류

JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법이다. 

그 이유는, 정보가 sign 되어 있기 때문에 정보를 보낸이가 바뀌진 않았는지, 

또 정보가 도중에 조작되지는 않았는지 검증할 수 있다. 

JWT의 생김새 

JWT는 .을 구분자로 3가지의 문자열로 되어 있다. 구조는 아래와 같다. 

aaaaaa.bbbbbb.cccccc
헤더(header).내용(payload).서명(signature)

(JWT 토큰을 만들때는 JWT를 담당하는 라이브러리가 자동으로 인코딩 및 해싱 작업을 해준다.)

그럼 위와 같이 3가지 부분으로 나뉘어져 있는 각각에 대해 알아보자. 

헤더(Header)

헤더는 두 가지의 정보를 지니고 있다. 

• typ: 토큰의 타입을 지정한다. 즉, JWT이다. 
• alg: 해싱 알고리즘을 지정한다. 해싱 알고리즘으로는 보통 HMAC SHA256 혹은 RSA가 사용되며, 이 알고리즘은 토큰을 검증할 때 사용되는 signature 부분에서 사용된다. 

정보(payload)

payload 부분에는 토큰에 담을 정보가 들어 있다. 

여기에 담는 '정보의 한 조각'을 클레임(claim)이라고 부른다. 

name/value의 한 쌍으로 이루어져 있다. 

그리고 토큰에는 여러 개의 클레임들을 넣을 수 있다. 

클레임은 등록된(registered) 클레임, 공개(public) 클레임, 비공개(private) 클레임으로 나뉘어져 있다. 

# 등록된(registered) 클레임

등록된 클레임들은 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기 위해

이름이 이미 정해진 클레임들이다.

등록된 클레임의 사용은 모두 선택적(optional)이며, 이에 포함된 클레임 이름들은 다음과 같다. 

• iss: 토큰 발급자(issuer)
• sub: 토큰 제목(subject)
• aud: 토큰 대상자(audience)
• exp: 토큰의 만료시간(expiration). 시간은 NumericDate 형식으로 되어 있어야 하며(ex: 1480849147370), 언제나 현재 시간보다 이후로 설정되어 있어야 한다. 
• nbf: Not Before를 의미. 토큰의 활성 날짜와 비슷한 개념. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다. 
• iat: 토큰이 발급된 시간(issued at). 이 값을 사용하여 토큰의 age가 얼마나 되었는지 판단할 수 있다.
• jti: JWT의 고유 식별자. 주로 중복 처리를 방지하기 위해 사용된다. 일회용 토큰에 사용하면 유용하다. 

# 공개(public) 클레임

공개 클레임들은 충돌이 방지된(collision-resistant) 이름을 가지고 있어야 한다. 

충돌을 방지하기 위해서, 클레임 이름을 아래와 같이 URI(Uniform Resource Identifier) 형식으로 짓는다. 

{
    "https://dolphinSarah.com/jwt_claims/is_admin": true
}

# 비공개(private) 클레임 

등록된 클레임도 아니고, 공개된 클레임도 아니다. 

양 측간에(보통 클라이언트 <-> 서버) 협의 하에 사용되는 클레임 이름이다. 

공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니, 사용할 때 유의해야 한다. 

{
    "username": "dolphinSarah"
}

아래 예제 payload는 2개의 등록된 클레임, 1개의 공개 클레임, 2개의 비공개 클레임으로 이루어져 있다. 

{
    "iss": "dolphinSarah.com",
    "exp": "1485270000000",
    "https://dolphinSarah.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "dolphinSarah"
}

서명(signature)

JSON Web Token의 마지막 부분은 바로 서명(signature)이다. 

이 서명은 헤더의 인코딩 값과, 정보의 인코딩 값을 합친 후, 

주어진 비밀키로 해쉬를 하여 생성한다. 

서명 부분을 만드는 pseudo-code의 구조는 다음과 같다. 

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

이렇게 만든 해쉬를, base64 형태로 나타내면 된다. 

위 포스팅은 아래 링크를 참고하여 작성했습니다.

https://velopert.com/2389