HTTP/1.0, HTTP/1.1
✏️ HTTP/1.0
기본적으로 HTTP는 전송 계층 위에 있는 애플리케이션 계층으로 웹 서비스 통신에 사용됩니다. HTTP/1.0부터 시작해서 발전을 거듭하여 지금은 HTTP/3입니다.
HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었습니다. 하지만 서버로부터 파일을 가져올 때마다 TCP의 3-Way Handshake를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있습니다.
💡 RTT (왕복 지연 시간)
네트워크에서 특정 목적지까지의 신호를 보내고 그 응답이 돌아오는 데 걸리는 전체 시간을 나타냅니다.
🤔 RTT의 증가를 해결하기 위한 방법
매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답 시간이 길어졌습니다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용하곤 했습니다.
🏞 이미지 스플리팅
많은 이미지를 다운로드 받게 되면 과부하가 걸리기 때문에 많은 이지미가 합쳐 있는 하나의 스프라이트 이미지를 다운로드받고, 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법입니다.
아래는 네이버에서 사용중인 스프라이트 이미지입니다.
🗜️ 코드 압축
코드 압축은 코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법입니다.
const express = require('express');
const app = express();
const port = 3000;
app.get('/', () => {
res.send('Hello');
})
app.listen(port, () => {
console.log(`Server is listening on port ${port}`);
})
위와 같은 코드를 아래와 같은 코드로 바꾸는 방식입니다.
const express=require('express'),app=express(),port=3e3,app.get('/',(e,p)=>{e.send('Hello')}),app.listen(3e3,()=>{console.log(`Server is listening on port 3000`)})
🔢 이미지 Base64 인코딩
이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법입니다. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있습니다. 하지만 Base64 문자열로 변환할 경우 33% 정도 크기가 더 커지는 단점이 있습니다.
✏️ HTTP/1.1
HTTP/1.0에서 발전한 것이 바로 HTTP/1.1입니다. 매번 TCP 연결을 하는 것이 아니라 한번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었습니다.
아래는 HTTP/1.0과 HTTP/1.1의 비교 그림입니다.
최초 TCP 3-Way Handshake가 발생하면 그 다음부터 발생하지 않지만, 문서 안에 포함된 다수의 리소스(이미지, css 파일, script 파일)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있습니다.
⛔️ HOL Blocking
HOL Blocking(Head Of Line Blocking)은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말합니다.
위 그림과 같이 첫 번째 요청이 처리되지 않았을 때 두 번째, 세 번째 요청이 처리되지 않고 첫 번째 요청이 처리가 될 때까지 지연됩니다.