1. HTTP 1.0 vs 1.1: "TCP 연결의 비효율과 개선" (L4 전송 계층의 고민)
왼쪽 두 개의 칸은 우리가 아까 공부한 꼼꼼한 TCP 기사님을 부르는 방식에 대한 이야기입니다.
HTTP 1.0: "한 번 먹고 집 가기"
- 그림 설명: 손님이 밥 한 숟가락(HTTP Request) 먹으려고 할 때마다, 택배 기사님과 "준비됐어? 응! 준비됐어! 아싸 가자!" (TCP SYN, SYN+ACK, ACK)라는 복잡한 인사(3-Way Handshake)를 매번 해야 합니다.
- 비효율: 순대국밥 한 그릇 먹는데 인사만 수십 번 하느라 시간이 다 갑니다. 밥 먹고 나면 바로 연결을 끊어버려서(Close), 깍두기 먹으려면 또 인사를 해야 했죠.
HTTP 1.1: "Keep-Alive - 식당에 죽치고 앉아있기" ★ 핵심
- 그림 설명: HTTP 1.0의 비효율을 깨닫고, "한 번 인사하고 연결 맺으면(Persistent Connection), 배 터질 때까지 안 끊고 계속 먹겠다!"라고 바꾼 겁니다.
- 개선: 밥(Stream 1), 깍두기(Stream 2), 새우젓(Stream 3)을 매번 인사 없이 줄줄이 요청해서 받습니다.
- 새로운 문제 (HOL Blocking): 그런데 그림의
One TCP Connection을 보세요. 통로가 하나뿐이라, 앞사람이 주문한 무거운 순대국밥(Stream 1)이 나올 때까지 뒷사람의 가벼운 깍두기(Stream 2)는 한참을 기다려야 합니다. 이걸 Head-of-Line Blocking이라고 해요.
2. HTTP 2.0: "멀티태스킹의 마법" (캡슐화의 진화)
세 번째 칸은 L1~L4는 그대로 TCP를 쓰지만, L7 알맹이(데이터)를 포장하는 방식을 아주 똑똑하게 바꾼 버전입니다.
- 그림 설명:
One TCP Connection이라는 좁은 통로 안에 가상의 '차선(Streams)'을 여러 개 만들었습니다. - 작동: 이제 순대국밥(Stream 1)이 조리되는 동안, 옆 차선으로 깍두기(Stream 2), 새우젓(Stream 3)을 동시에 보낼 수 있습니다.
- 비유: 한 줄로 서서 기다리던 식당이 푸드코트처럼 변해서, 진동벨 울리는 대로 한꺼번에 가져가는 것과 같습니다. HOL Blocking 문제가 드디어 해결된 것이죠!
3. HTTP 3.0: "TCP 버리고 UDP로 폭주하기" (L4 프로토콜의 혁명) ★ 기수님 맞춤형!
마지막 칸은 기수님이 아까 궁금해하셨던 UDP가 웹 세상의 주인공으로 등극하는 순간입니다.
- 그림 설명: 지금까지 쓰던 꼼꼼하지만 무거운 TCP를 아예 버렸습니다. 대신 빛의 속도인 UDP 위에 QUIC이라는 새로운 장갑을 씌워서 사용합니다.
- 0-RTT: 그림의 UDP 통신 부분을 보세요. TCP처럼 "준비됐어? 응!" 하는 복잡한 인사가 아예 없습니다. 그냥 첫 번째 패킷부터 데이터를 쏴버립니다.
- 진정한 멀티태스킹: HTTP 2.0은 차선이 여러 개라도 고속도로 자체가 TCP라서 한 곳만 막혀도 전체가 멈췄습니다. 하지만 HTTP 3.0(QUIC)은 각 차선(Stream)이 독립적이라 패킷이 하나 유실되어도 다른 차선은 아무 영향 없이 쌩쌩 달립니다.
💡 요약
- HTTP 1.1: 한 번 TCP 연결해서(L4) 여러 밥을 먹지만(L7), 순서대로 먹어야 해서 답답함.
- HTTP 2.0: TCP 연결(L4) 안에서 여러 밥(L7)을 동시에 먹지만, TCP 자체의 한계가 있음.(TCP 순서 보장으로 인해 다른게 먼저 도착해도 대기하고 있고 유실되면 전체 멈춤)
- HTTP 3.0: 무겁고 느린 TCP 대신 빠른 UDP(L4)를 써서, 연결 설정 시간도 줄이고(0-RTT) 패킷 손실 시 지연도 완벽히 해결함.
엄청난 클라우드 고수