위 처럼 하나의 이미지 background-image:url("cons.png");. background-position 등을 기반으로 이미지를 설정한다.
2) 코드 압축
코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법
// 코드 압축 전
const express = require('express')
const app = express()
const port = 3000
app.get('/', (req, res) => {
res.send('Hello World!')
})
app.listen(port, () => {
console.log(`Example app listening on port ${port}`)
})
// 코드 압축 후
const express=require("express"),app=express(),port=3e3;app.get("/",(e,p)=>{p.send("Hello World!")}),app.listen(3e3,()=>{console.log("Example app listening on port 3000")});
3) 이미지 Base64 인코딩
이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법
0부터 63까지 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ 으로 나타낸다.
인코딩이란?정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 방식
장점
단점
서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다.
원본데이터에서 33% 정도 크기가 증가된다. (256가지를 표현할 수 있는 바이트를 printable한 64가지를 사용해서 표현하기 때문이다. => 8비트를 6비트로 표현 3개의 8비트는 4개의 6비트로 표현 가능)
매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다.
HTTP/1.0의 keep-alive를 표준화해 기본 옵션으로 설정했다.
keep-alive란? http와 tcp에서 persistent connection을 맺는 기법 중 하나.(하나의 TCP connection을 활용해서 여러 개의 HTTP reqeust/response를 주고 받을 수 있도록 해준다.
persistent connection이란? 요청이 처리된 후에도 연결(connection)을 유지하는 경우
keep-alive의 유지 시간은 연결된 socket에 I/O Access가 마지막으로 종료된 시점부터 정의된 시간까지 Access가 없더라도 세션을 유지하는 구조. 즉, 정의된 시간내에 Access가 이루어진다면 계속 연결된 상태를 유지할 수 있다.
keep-alive timeout 설정이 필요한 이유: 서버 자원은 무한정이 아니기 때문에 접속을 계속 유지하는 것은 Server에 손실을 발생시킨다. 즉, 서버와 연결을 맺을 수 있는 Socket은 한정되어 있고 연결이 오래 지속되면 다른 사람들이 연결을 못하게 된다.
keep alive의 단점 바쁜 서버 환경에서 Keep Alive 기능을 사용할 경우 모든 요청 마다 연결을 유지해야 하기 때문에 프로세스 수가 기하급수적으로 늘어나 MaxClient 값을 초과하게 되면서 메모리를 많이 사용하게 된다. 이는 곧 성는 저하에 원인이 된다. 즉, 대량 접속 시 효율이 떨어지게 된다.
keep alive
1) HTTP 1.0과 HTTP 1.1의 차이
1)-1 Non-Persistent vs Persistent
HTTP 1.0과 HTTP 1.1의 가장 큰 차이점: 연결 지속성(Persistent Connection)
persistent connection의 장점
네트워크 혼잡 감소: TCP, SSL/TCP connection request수가 줄어들면서
네트워크 비용 감소: 여러 개의 connection으로 하나의 client요청을 serving하는 것보다 한 개의 connection으로 client 요청을 serving하는 게 더 효율적
latency(지연시간) 감소: 3 - way handshake를 맺으면서 필요한 round-trip이 줄어들어서 그만큼 지연시간도 감소한다.
HTTP 1.0
HTTP 1.1
TCP 세션을 유지하지 않는다.
1.1은 TCP 세션을 유지한다.
매번 데이터를 요청하고 수신할 때마다 새로운 TCP 세션을 맺어야 한다.
한 번의 TCP 세션에 여러 개의 요청을 보내고 응답을 수신할 수 있다. (TCP 세션 처리 부하를 줄이고 응답속도를 개선할 수 있다.)
Non-Persistent HTTP
Persistent HTTP
persistent connection
위의 그림처럼 HTTP 1.1은 한 번 TCP 3-웨이 핸드셰이크가 발생하면 그 다음부터 발생하지 않지만 문서 안에 포함된 다수의 이미지(이미지, CSS 파일, script 파일)를 처리하려면 요청할 리소스 개수에 비례해 대기 시간이 길어지는 단점이 있다.
1)-2 파이프라이닝(Pipelining)
파이프라이닝: 송신자가 다수의 패킷을 한 번에 보내는 것(여러 개의 요청을 동시에 전송)
위에서 언급한 persistent 기능을 통한 커넥션 유지와 함께 HTTP 1.1에서 지원되는 기능
응답 속도를 높혀 페이지 뷰의 속도를 빠르게 할 수 있다.
HTTP 1.0
HTTP 1.1
파이프라이닝 제공 하지 않음
파이프라이닝 제공
ACK 신호를 기다리다 ACK 신호를 받고 나서 다음 데이터를 보내는 stop and wait 방식
송신자가 ACKs 신호를 받지 않아도 패킷 여러 개를 보내는 방식(여러 개의 요청을 동시에 전송)
파이프라이닝
1)-3 호스트 헤더(Host Header)
HTTP 1.1 에서 Host 헤더의 추가를 통해 가상 호스팅(Virtual Hosting)이 가능해졌다.
HTTP 1.0
HTTP 1.1
하나의 IP 주소에 여러 개의 도메인을 운영할 수 없기에 도메인 마다 IP를 구분해서 준비해야 한다. => 서버도 그만큼 늘어날 수 밖에 없는 구조
가상 호스팅 덕분에 하나의 IP 주소에 여러 개의 도메인을 적용시킬 수 있다.
호스트 헤더
1)-4 향상된 인증 절차(Improved Authentication Procedure)
HTTP 1.1은 proxy-authenication과 proxy-authorization 이 두 개의 header가 추가되었다.
실제 서버에서 클라이언트 인증을 요구하는 www-authentication 헤더는 HTTP 1.0부터 지원됐지만, 서버와 클라이언트 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었다.
하지만 두 header의 추가로 프록시가 사용자의 인증을 요구하는 게 가능해지면서 인증 절차가 향상되었다.
프록시 서버(proxy server)란? 클라이언트와 서버 사이에서 데이터를 전달해주는 서버
2) HOL Blocking(Head Of Line Blocking)
HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
HOL Blocking 때문에 패킷의 처리 속도는 지연되고, 최악의 경우는 드랍까지 발생할 수 있다.
HOL Blocking
ex 2) 보통의 스위치는 패킷이 Input에 들어오면 Switching fabric을 거쳐 Output에 도달하게 된다.
첫 번째 input과 세 번째 input은 동일한 인터페이스(output 4)로 패킷을 보내려고 한다.
이 경우 switching fabric에서 세 번째 input의 패킷을 먼저 처리하면, 첫 번째 input의 패킷을 인터페이스(output 4)로 보내지 못한다 => 이것을 HOL Blocking 이라고 함
3) 무거운 헤더 구조
HTTP 요청을 할 때마다 중복된 헤더 값을 전송하게 되고, 서버 도메인에 관련된 쿠키 정보도 헤더에 함께 포함되어 전송된다.
이런 반복적인 헤더 전송, 쿠키 정보로 인한 헤더 크기의 증가라는 단점이 있다.
HTTP1.x의 단점 : RTT 증가 / HOL Blocking / 무거운 헤더 구조
4-3. HTTP/2
HTTP/2는 SPDY 프로토콜에서 파생되었으며 HTTP/1.x보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있다.
멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜
HTTP 1.1에 비해 유저가 느끼는 latency나 네트워크 서버 리소스 사용량 등과 같은 성능 위주로 개선
SPDY('speedy')란? 구글이 자신들의 'Make the Web Faster' 노력의 하나로 제안한 새로운 프로토콜
초창기 인터넷 환경에서 고안된 HTTP의 단점들을 보완하고, 지금과 앞으로의 인터넷 환경을 보다 효율적으로 이용할 수 있는 프로토콜로 제안되었다. (설계 목적: 웹 페이지의 로딩 시간을 줄이기)
SPDY는 HTTP를 대체하는 프로토콜이 아니라, HTTP가 전송 계층을 통해 전송되는 방식을 재정의하는 프로토콜
SPDY의 특징 1. 항상 TLS 위에서 동작(HTTS로 작성된 웹 사이트만 적용 가능) 2.HTTP 헤더 압축(요청이 많아질 수록 압축률을 커지고, 대역폭이 작은 모바일 환경에서 효과가 크게 보임) 3. 텍스트가 아닌 바이너리 프로토콜(파싱이 더 빠르고, 오류 발생 가능성이 낮음) 4. 멀티플렉싱(하나의 커넥션 안에서 다수의 독립적인 스트림을 동시에 처리) 5. Full-duplex Interleaving & Prioritization(다른 스트림이 끼어드는 것을 허용) 6. 서버 푸시
1) 멀티플렉싱(Multiplexed Streams)
하나의 통신 채널을 통해서 둘 이상의 데이터를 전송하는 데 사용되는 기술(여러 개의 스트림을 사용해 송수신)
멀티플렉싱을 통해 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 스트림은 동작 가능
즉, Multiplexed Streams를 이용해 하나의 TCP Connection만으로 모든 요청과 응답 데이터를 전송하고 바이너리 프레임의 스트림 전송 방식을 통해 응답 순서에 무관하게 데이터를 처리 => HTTP 1.1의 Connection Kepp-Alive와 Pipelining로 인해 생기는 HOL Blocking을 개선함
스트림(stream)? 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름
2) 헤더 압축(Header Compression)
HTTP/1.x의 또다른 문제인 중복되는 헤더의 반복 전송을 효율적으로 낮추기 위해 HTTP/2에서는 헤더 압축을 써서 해결하는데, Header Table과 Huffman Encoding 기법을 사용한다. 이를 HPACK 압축 방식이라 하고 허프만 코딩 압축 알고리즘을 사용한다.
클라이언트가 요청을 두 번 보낼 때, HTTP/1.x의 경우 헤더 중복이 발생해도 중복 전송한다.
BUT! HTTP/2에서는 헤더의 중복이 있는 경우 Static/Dynamic Header Table 개념을 이용해 중복을 검출해내고 / 해당 테이블에서의 index 값, 중복되지 않은 Header 정보를 Huffman Encoding 방식으로 인코딩한 데이터를 전송한다.
허프만 코딩(huffman coding)?문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용해 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용해 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리
3) 서버 푸시(Server Push)
서버는 클라이언트가 요청하지 않은 리소스를 사전에 푸시를 통해 전송할 수 있다
리소스 푸시가 가능해지면 클라이언트가 HTML 문서를 요청할 때 해당 문서 내의 리소스를 미리 클라이언트에서 다운로드 할 수 있도록 해 클라이언트의 요청을 최소화할 수 있다.
HTTP/1.1
HTTP/2
클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있다.
클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.
html에는 css나 js 파일이 포함되는데 html을 읽으면서 안에 들어있던 css 파일을 서버에서 푸시해 클라이언트에 먼저 줄 수 있다.
4) 우선순위(Stream Prioritization)
클라이언트가 선호하는 응답 수신 방식을 지정해서 응답을 받을 수 있다.
ex) 문서 내에 CSS 파일 1개와 이미지 파일 2개 존재하고, 클라이언트가 요청
이미지 파일보다 CSS 파일의 수신이 늦어진다면 브라우저 렌더링에 문제가 생기게 될 수 있다.
HTTP/2에서는 리소스 간의 의존관계에 따른 우선순위를 설정해 리소스 로드 문제를 해결한다.!
4-4. HTTPS
HTTPS(하이퍼 텍스트 전송 프로토콜 보안) 사용하는 HTTP 프로토콜의 보안 버전
애플리케이션과 전송 계층 사이에 신뢰 계층인 SSL/TLS(보안) 계층을 넣어 신뢰할 수 있는 HTTP 요청으로 이를 통해 '통신을 암호화'한다.
HTTPS 프로토콜을 사용하면 웹 사이트 사용자가 인터넷을 통해 신용 카드 번호, 은행 정보 및 로그인 자격 증명과 같은 중요한 데이터를 안전하게 전송할 수 있다.
HTTP/2는 HTTPS 위에서만 동작한다. (SPDY때문)
1) SSL/TLS
전송 계층에서 보안을 제공하는 프로토콜로 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 한다.
SSL(Secure Sockets Layer:보안 소켓 계층)? 웹 사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 암호화 기반 인터넷 보안 프로토콜 - 전달되는 모든 데이터들을 암호화하고 특정한 유형의 사이버 공격을 차단한다. - SSL 인증서는 "SSL 핸드셰이크"라는 과정을 통해 웹사이트/서버와 브라우저 간에 암호화된 연결을 수립한다.
TLS(Transport Layer Security:전송 계층 보안)? TLS은 SSL의 향상된, 더욱 안전한 버전으로 최신 암호화 프로토콜 SSL의 여러 취약성이 알려지면서 TLS이 그 대안으로 떠올랐으며 현재 SSL을 인증한 업체 및 제공하는 업체는 실제로 TLS 암호화를 제공하는 것
SSL은 SSL 1.0부터 시작해서 SSL 2.0 -> SSL 3.0 -> TLS 1.0 -> TLS 1.3까지 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었지만 보통 이를 합쳐 SSL/TLS로 부른다.
SSL/TLS의 작동 방식
SSL은 개인정보 보호를 제공하기 위해 웹에서 전송되는 데이터를 암호화한다. 따라서 데이터를 가로채려해도 거의 복호화가 불가능하다.
SSL은 클라이언트와 서버간에 핸드셰이크를 통해 인증이 이루어지고, 또한 데이터 무결성을 위해 데이터에 디지털 서명을 해 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인한다.
SSL/TLS를 통해 공격자가 서버인 척하며 사용자 정보를 가로채는 네트워크의 상태의 '인터셉터'를 방지할 수 있다.
HTTPS
SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.
1)-1 보안 세션
보안이 시작되고 끝나는 동안 유지되는 세션
SSL/TLS은 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다.
세션(Session)?운영체제가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간. 즉, 사용자가 인증에 성공한 상태
TLS의 핸드셰이크
클라이언트와 서버가 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 한 번의 1-RTT가 생긴 후 데이터를 송수신을 한다.
클라이언트에서 사이퍼슈트(cipher suite)를 서버에 전달(1)하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인(2)한다.
제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작(3)되고 이후 해싱 알고리즘 등(4)으로 암호화된 데이터의 송수신(5)이 시작된다.
(1) 사이퍼 슈트(Cipher Suites)
TLS 핸드셰이크를 통해서 클라이언트/서버간 최종 협의하게 되는데, 어떤 프로토콜을 사용할지, 어떻게 암호화해서 통신할 지 에 대한 여러 정보가 포함되어 있는 것. 즉,프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약
Cipher Suites(암호화 스위트)의 구조
WITH 앞쪽 부분
WITH 뒤 쪽
프로토콜(TLS/SSL) 및 키 교환방식(키 교환 암호 알고리즘)과 인증(전자서명을 통한 인증서 검증:인증 알고리즘)을 담당
실제 데이터를 암호화하는 부분으로 대칭 암호 알고리즘 + 블록 암호 운용 방식 + 메시지 인증(해시 알고리즘)
키 교환 알고리즘: 서버와 클라이언트 간 key를 교환할 방식을 선정하는 것 (RSA, DH, DHE, ECDH, ECDHE)
대칭 암호 알고리즘: 실제 데이터를 암호화(Encryption)하는 알고리즘 (3DES, AES, AES128 등)
인증 알고리즘: 서버와 클라이언트 간 교환한 인증서를 확인하는 알고리즘 (RSA, DSS, ECDSA, ANON)
블록 암호 운용 방식: 데이터를 암호할 때 블록 단위로 암호화 하는데, 블록된 암호화 해킷을 조합해 데이터를 추측하는 것을 방지하기 위한 방식(CBC, GCM)
만약 키교환과 인증을 모두 RSA를 사용하게 될 때는 키교환과 인증을 RSA 하나로 생략해서 표현!!
해시 알고리즘: 서로 상대방이 암호화 한 것이 맞는지 확인하기 위한 알고리즘 (데이터 무결성을 검증하기 위해 메시지 인증을 한다. 이를 보통 MAC(Message Authentication)이라고 하는데 여기에 해쉬 알고리즘 SHA, SHA256, SHA384, MD5등을 이용해서 HMAC이라고 부른다.)
위 사진을 해석하면 TLS 프로토콜을 사용하며, 키 교환방식은 ECDHE, 인증 알고리즘은 RSA, 대칭 알고리즘으로 AES를 사용하고, 암호키 길이는 128비트, 블록 암호 운용 모드는 CBC이고, 해시 알고리즘은 SHA를 사용한다는 것
사이퍼 슈트 5개
TLS_AED_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
ex) TLS_AES_128_GCM_SHA256는 세 가지 규약이 들어있다. TLS는 프로토콜 / AES_128_GCM은 AEAD 사이퍼 모드 / SHA256은 해싱 알고리즘을 뜻한다.
(2) AEAD 사이퍼 모드(Authenticated Encryption with Associated Data)
데이터 암호화 알고리즘
1)-2 인증 메커니즘
인증 메커니즘은 인증기관(CA:Certificate Authorities)에서 발급한 인증서를 기반으로 이루어진다.
CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 '공개키'를 클라이언트에게 제공하고, 사용자가 접속한 '서버가 신뢰'할 수 있는 서버임을 보장한다.
인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어져 있다.
CA는 신뢰성이 공인된 기업들만 참여할 수 있다. ex) Comodo, GoDaddy, GlobalSign, 아마존
CA 발급 과정 1. 서비스가 CA 인증서를 발급받으려면 사이트 정보 + 공개키를 CA에 제출해야한다. 2. 이후 CA는 공개키를 '해시'한 값인 지문을 사용하는 CA의 비밀키 등을 기반으로 CA 인증서를 발급한다. 개인키(비밀키)? 개인이 소유하고 있는 키, 암호화키와 복호화키가 동일해서 송신자, 수신자 외에는 노출되지 않도록 관리해야 한다. 공개키(비대칭키)? 암호화키와 복호화 키가 다르다.
1)-3 암호화 알고리즘
키 교환 암호화 알고리즘으로는 대수곡선 기반의 ECDHE(Elliptic Curve Diffie-Hellman Ephermeral) 또는 모듈식 기반의 DHE(Diffie-Hellman Ephermeral)를 사용한다. 둘 다 디피-헬만(Diffie-Hellman) 방식을 근간으로 만들어졌다.
디피-헬만 키 교환(Diffie-Hellman key exchange) 암호화 알고리즘
암호키를 교환하는 하나의 방법
상대방의 공개키와 나의 개인키를 이용해 계산을 하면 비밀키가 나온다는 것. 그 후 나와 상대방은 비밀키를 사용해 데이터를 암호화한 후 전달하면 된다.
이 DH 알고리즘은 위에서 나온 싸이퍼 슈트의 "키 교환(key change)알고리즘"으로 대칭키를 공유하는 데 사용한다.
암호화에는 누구에게나 공개되어 있는 공개 키를, 복호화에는 수신자만 아는 비밀 키를 사용하는 방법
같은 키를 사용하기 때문에, 자물쇠를 잠그는 사람인 메시지 전송자와 메시지 수신자 모두 키 관리에 주의해야 한다.
대칭 키 알고리즘과 달리 공개 키를 누구에게나 공개해도 상관없고 비밀 키만 잘 관리하면 되어서 조금 더 키 관리가 수월해진다.
대표적인 대칭 키 암호화 방식: DES, AES 알고리즘
대표적인 공개키 암호화 방식: RSA 알고리즘
하나의 대칭 키를 사용하기 때문에 계산 속도가 더 빠르다.
암호화, 복호화에 2개의 키를 사용하기 때문에 상대적으로 대칭 키 암호화 방식보다는 계산 속도가 느리다.
https://로 시작하는 URL의 웹 사이트에 접속할 때, 데이터 송수신에서의 암호화는 속도가 더 빠른 대칭 키 암호화 알고리즘이 사용된다.
https://로 시작하는 URL의 웹 사이트에 접속할 때,웹 사이트 인증에는 공개 키 암호화 알고리즘이 사용된다.
디피-헬만 키 교환 암호화 알고리즘
처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유한다.
그 다음 각자의 비밀 값과 또 혼합한다.
그 이후 공동의 암호키가 생성!
이렇게 클라이언트와 서버 모두 개인키와 공개키를 생성하고 서로에게 공개키를 보내고 공개키와 개인키를 결합해 PSK(사전 합의된 비밀키)가 생성된다면, 악의적인 공격자가 개인키 또는 공개키를 가지고도 PSK가 없기 때문에 아무것도 할 수 없다. => 이러한 일련의 과정을 통해 키를 암호화할 수 있는 것!
1)-4 해싱 알고리즘
데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘
SSL/TLS는 해싱 알고리즘으로 SHA-256 알고리즘과 SHA-384 알고리즘을 쓰고, 그 중 SHA-256을 많이 사용한다.
(1) SHA-256 알고리즘
해시 함수의 결괏값이 256 비트인 알고리즘이고 비트 코인을 비롯한 많은 블록체인 시스템에서도 쓴다.
SHA-256 알고리즘은 해싱을 해야 할 메시지에 1을 추가하는 등 전처리를 하고 전처리된 메시지를 기반으로 해시를 반환한다.
SHA - 256
위의 그림처럼 "나는 반드시 이번 면접에 합격하고 강원도 고성에 수영하러 간다!"라는 글자가 08cc3029b838d4be3ed53ffe3bab5be2c2d44526218d365bfdfd15673e27838f라는 문자열로 변환되는 것을 볼 수 있다.
HTTP/1.1 및 HTTP/2와 함께 World Wide Web에서 정보를 교환하는 데 사용되는 HTTP의 세번째 버전, QUIC이라는 프로토콜 위에서 돌아가는 HTTP
HTTP/2처럼 멀티플렉싱을 가지고 있고, 초기 연결 설정 시 지연 시간이 감소된다.
QUIC(Quick UDP Internet Connection:퀵)? UDP를 사용하여 인터넷 연결을 하는 프로토콜
- TCP가 가지고 있는 3-way handshake로 인한 지연시간과 HOL Blocking 등의 문제를 해결하고자 구글이 개발한 UDP 기반의 프로토콜
- QUIC은 처음부터 TCP의 핸드쉐이크 과정을 최적화하는 것에 초점을 맞춰 설계되었고, UDP를 사용함으로써 이를 실현해낼 수 있다.
HTTP/2
HTTP/3
TCP 위에서 돌아간다.
QUIC이라는 계층 위에서 돌아간다.
TCP 기반 통신
UDP 기반 통신
HTTP/3가 TCP 대신에 UDP를 사용하는 이유
(1) 속도가 빠르다. UDP(User Datagram Protocol), 데이터그램 방식을 사용하는 프로토콜이기에 애초에 각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용하고 목적지만 정해져있다면 중간 경로는 신경 쓰지 않아도 된다. => 핸드셰이크 과정이 필요없다!!!!! 즉 => UDP는 TCP가 신뢰성을 확보하기 위해 거치던 과정을 거치지 않기에 속도가 더 빠르다.
(2) 커스터마이징이 가능해 신뢰성을 보장할 수 있다. UDP는 커스터마이징이 용이하기 때문에 UDP를 사용하더라도 기존의 TCP가 가지고 있던 기능(신뢰성과 정확성)을 전부 구현할 수 있다. => UDP는 데이터 전송을 제외한 그 어떤 기능도 정의되어 있지 않은 프로토콜, 백지 상태의 프로토콜이기에 어플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준의 기능을 가질 수도 있다.
UDP 기반으로 돌아가는 HTTP/3
1) 초기 연결 설정 시 지연 감소
QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way handshake 과정을 거치지 않아도 된다.
QUIC은 첫 연결 설정에 1-RTT만 소요된다. (TCP는 연결을 생성하기 위해 기본적으로 1 RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 하려고 한다면 TLS의 자체 핸드셰이크까지 더해져 총 3RTT가 필요하다.)
클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다.
QUIC은 순방향 오류 수정 메커니즘(FEC, Forword Error Correction)이 적용되었다.
이는 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열약한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.
