참고
HTTP 발전과정
NOTE
HTTP는 어플리케이션 계층에서 웹 서비스 통신에 사용된다!
HTTP 버전별로 통신차이가 있다.
HTTP/1.0
NOTE
기본적으로 한 연결당 하나의 요청을 처리한다!
RTT → 패킷이 목적지에 도달하고, 다시 돌아오는 시간
문제점
•
매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이가고 응답 시간이 길어졌다.
•
RTT의 증가를 해결하기 위한 방법
◦
이미지 스플리팅
◦
코드 압축
◦
이미지 Base64 인코딩
이미지 스플리팅
NOTE
많은 이미지를 다운로드받게 되면 과부하가 걸리기 때문에 이미지가 합쳐있는 하나의 이미지를 다운로드 받는다.
#icons>li>a {
background-image: url("icons.png");
width: 25px;
display: inline-block;
height: 25px;
repeat: no-repeat;
}
#icons>li:nth-child(1)>a {
background-position: 2px -8px;
}
#icons>li:nth-child(2)>a {
background-position: -29px
}
CSS
복사
ex) 하나의 이미지 icons.png를 기반으로 background-position을 통해 2개의 이미지를 설정
이런 이미지 전체를 다운로드 받음
홈페이지에서 필요한곳에 사용!
코드 압축
NOTE
코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법!
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}`)
})
JavaScript
복사
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")});
JavaScript
복사
한줄로 최대한 압축
이미지 Base64 인코딩
NOTE
이미지 파일을 64진법으로 이루어진 문자열로 인코딩한다!
이미지의 인물은 책 저자가 가장 존경하는 인물이라고 한다..
•
이방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할필요가 없다.
•
Base64로 변경하면 크키가 37% 더 커진다
HTTP/1.1
NOTE
매번 TCP 연결을 하지 않고, 한번 TCP 초기화를 한 후 keep-alive라는 옵션으로 여러개의 파일을 송수신할 수 있게됨!
kepp-alive 동안은 연결이 유지된다!
TCP handshake가 한번 발생하면 그다음에 다시 발생하지 않음
•
1.0에서도 keep-alive는 있었지만 표준화가 되어있지 않았다.
문제점
•
HOT Blocking
◦
문서 안에 포함된 다수의 리소스(이미지, 동영상, css)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어진다.
•
무거운 헤더 구조
◦
쿠키, 메타데이터가 많이 들어가는데 압축이 되지않고 무겁다.
HOT Blocking(Head of Line Blocking)
NOTE
네트워크에서 같은 큐에 있는 패킷이 1번째 패킷에 의해 지연되는 현상!
순차적으로 발생해야하니 처음 이미지 다운이 느려지면 전부 느려짐..
파이프라이닝 기술로 한번에 요청을 보내는건 가능하지만, 결국 응답은 순서대로 받아야함..
HTTP/2.0
NOTE
SDPY 프로토콜에서 파생된 HTTP/1.x보다 지연 시간을 줄이고, 응답시간을 더 빠르게할 수 있다!
1.1 → 하나의 커넥션 하나의 스트림
2 → 하나의 커넥션 여러 스트림
•
SDPY 프로토콜
◦
구글에서 개발된 네트워크 프로토콜
◦
웹페이지의 로딩 속도를 향상시키는 것이 목표
멀티 플렉싱
NOTE
여러개의 스트림을 사용하여 송수신 하는 개념이다!
여러 스트림을 사용함
기존의 데이터를 조각내어 보내던걸, 단일 연결을 사용해 병렬로 여러 요청을 받을 수 있게되었다. (HOT Blocking 해결!)
•
특정 스트림의 패킷이 손실되어도, 해당 스트림에만 영향을 미치고 나머지는 멀쩡하다.
•
스트림(Stream)
◦
시간이 지남에 따라 사용할 수 있게되는 일련의 데이터 흐름
◦
source → destination간의 데이터 흐름!
헤더 압축
NOTE
HTTP 1.1에는 큰 헤더크기에 문제점이 존재했다!
HTTP/2에서 헤더압축을 써서 해결 (허프만 코딩 압축 알고리즘 사용)
•
허프만 코딩
◦
문자열을 문자 단위로 쪼개 빈도수를 센다.
▪
빈도가 높은 정보 → 적은 비트 수
▪
빈도가 낮은 수 → 많은 비트 수
◦
전체 데이터의 표현에 필요한 비트량을 줄인다.
서버 푸시
NOTE
HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을수 있다면, HTTP/2에서는 클라이언트 요청 없이 서버가 바로 리소스를 푸시한다!
html에서 css나 js는 거의 포함되므로, html을 읽으면 안에 있는 css를 서버에서 미리 던져준다.
HTTP/3
NOTE
SDPY 프로토콜에서 파생된 HTTP/1.x보다 지연 시간을 줄이고, 응답시간을 더 빠르게할 수 있다!
1.1 → 하나의 커넥션 하나의 스트림
2 → 하나의 커넥션 여러 스트림
•
SDPY 프로토콜
◦
구글에서 개발된 네트워크 프로토콜
◦
웹페이지의 로딩 속도를 향상시키는 것이 목표