TCP
HTTP : 서버와 클라이언트 사이에 이루어지는 요청(request)/응답(response)이다
CRUD원칙에 의해 RESTful로 통신하는 프로토콜이다
HTTP Method : GET, PUT, DELETE, POST, HEAD
HTTP status code : 200(ok), 302(redirect), 404(Not found)
Data Format : XML->JSON

HTTP1.0(1996)

HTTP1.0 : 하나의 연결당 하나의 요청
-> 하지만, TCP는 3-way handshake를 해야한다
-> RTT의 증가
-> 그러면 매번 TCP연결 하지 말고 한 번 TCP 초기화하면 keep-alive로 여러 개의 파일을 송수신하자
->HTTP1.1

HTTP1.1(1997)

HTTP1.1 : 매번 TCP연결 안하고 keep-alive로 여러 파일을 송수신
하지만, HTTP1.1도 문제가 있다

1. HOL Blocking

같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 성능 저하된다 그림

2. Fat message headers

HTTP1.1의 헤더에는 많은 메타정보들을 저장한다
매 요청마다 중복된 Header값을 전송하게 된다
(서버에서 Header작성해서 보내는 것도 다 돈이다)

3. Limited Priorities

우선 순위가 낮은 아이템을 띄우지고 못한다(우선 순위가 높은 아이템의 지연때문에)
-> 사용자는 오래 걸리는 페이지 로딩을 기다리지 않고 그냥 페이지 꺼버린다(광고 못띄움 ㅠㅠ)

4. 정리

• HOL Blocking + Limited Priorites -> 광고도 못띄우고 사람들이 사이트 나간다, 광고는 돈인데...
• 위에거 해결하고 속도 올리려면 WebServer가 이름을 여러 개 가지고 HTTP session을 여러 개 열어서 connection 여러개 뚫어야함
  -> 서버 운영하는 입장(구글) : 음? 열받네? 광고 못띄우고 느리다고 욕먹고 속도 올리려고 connection 여러 개 뚫은 돈은 내가 다 내고... 내가 호구임?
  -> 안되겠다 내가 새로운 프로토콜 만든다(구글) -> HTTP2

HTTP2(2015)

HTTP2 용어 정리

• Stream : 구성된 연결 내에서 전달되는 바이트의 양방향 흐름, 하나 이상의 메세지 전달가능
• Message : 논리적 요청 또는 응답 메세지에 매핑되는 프레임의 전체 시퀀스
• Frame : HTTP2에서 통신의 최소단위, 각 최소단위에는 하나의 프레임 헤더가 포함됨

모든 통신은 단일 TCP연결
각 스트림에는 고유식별자와 우선순위 정보있음
각 메세지는 하나의 논리적 메세지이고 하나 이상의 프레임으로 구성
프레임은 HTTP2에서 통신의 최소단위

돈을 벌기 위해서!

• HOL Blocking -> 지연시간 줄이기
• 커넥션 여러 개 -> 응답 다중화 : 프레임을 인터리빙(메세지를 프레임으로 쪼갠다)한 다음, 다시 조립 -> 병렬스트림이 가능해서 여러 메세지를 전송 가능
• Fat message header -> HTTP 헤더 필드 압축해서 프로토콜 오버헤드 최소화(보내는 데이터 형식이 String이 아닌 bit로! 옛날로 회귀) -> Binary Framing Layer -> 헤더압축 : Huffman Coding + IndexedList

HTTP3(2021)

QUIC기반의 프로토콜
QUIC : UDP기반, UDP(신뢰성 보장x)???
TCP는 현대사회에 어울리지 않는다!(Slow start, Multiplicative decrease based congestion control & 패킷이 하나 없어지면 목적지 찾는 동안에 연결이 중단된다(HOL Blocking), 여담으로 패킷 손실률이 2%이상이면 HTTP1이 오히려 나을 정도, 하지만 요즘 TCP는 패킷손실률이 거의 없긴 하다) -> 애초에 전쟁에 쓰려고 만든 프로토콜이다...

QUIC 프로토콜은 새로운 연결을 설정하는데 필요한 시간을 줄인다(1-RTT 또는 0-RTT) 0-RTT의그림