1. HTTP
1) HTTP란?
A) 웹상에서 클라이언트와 서버 간 통신을 위한 프로토콜
B) Application 계층
C) HTTP가 신뢰성을 보장해주기 때문에 이론적으로는 TCP(Transmission Control Protocol), UDP(User Datagram Protocol) 중 아무거나 사용 가능
2) 설명
2. HTTP/0.9
1) GET method만 있음
2) HTML 리소스만 처리 가능
3. HTTP/1.0
1) 0.9의 확장
2) Header 사용 -> version, status code, Content-Type -> HTML 이외의 다른 파일도 가능
3) 1 Connection : 1 request + 1 reply -> 매번 새로운 연결로 성능 저하 + 서버 부하 비용 증가
4. HTTP/1.1
1) 1.0의 확장
2) Persistent Connection : 지정한 timeout 동안 커넥션을 닫지 않는 방식
3) 파이프라이닝 기법 도입 : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방 -> Head Of Line Blocking 문제 발생!
4) 연속된 request, reply일 경우에는 Header가 중복됨에도 계속 Header를 표기함으로써 리소스가 낭비됨
5. HTTP/2.0
1) 1.1의 확장(2015~6 에 등장)
2) 메시지 전송 방식의 변화
A) 바이너리 프레이밍 계층 사용 : 파싱, 전송 속도 향상, 오류 발생 가능성 저하
B) Connection 안의 스트림(데이터 양방향 전송)에 프레임 단위로 들어가 합쳐짐
C) request, reply의 Multiplexing이 가능(인터리빙 방식) -> HOL 문제를 해결
D) Stream Prioritization :리소스 간 우선 순위 설정 가능
E) Server Push : 클라이언트가 요청하지 않아도 서버가 알아서 보내줌
ex) client가 HTML 리소스를 요청하면 CSS, JS도 요청하겠구나 하고 같이 보내버림
F) Header Compression :Static Dynamic Table 개념 도입 + 중복되지 않은 데이터를 허프만 인코딩 해서 압축 -> 헤더의 크기(약 85% 정도 줄어듦)를 줄여 페이지 로드 시간 감소
6. QUIC
1) 구글에서 만든 전송 계층 프로토콜(현재 구글 관련 제품 대부분의 기본 프로토콜)
2) 2013년에 공개
3) UDP 기반 -> 왜? TCP의 헤더 길이나 복잡한 알고리즘으로 인한 latency를 방지하기 위해서 + UDP는 데이터 전송에 집중한 설계이고 별도 기능 없이 원하는 기능만 구현할 수 있기 때문에
4) 전송 속도 향 : 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송 -> 연결 성공 시 설정을 캐싱하여 다음 연결 때 3 way handshake 없이 바로 성립 가능(Connection UUID 를 사용)
5) TLS 기본 적용, IP Spoofing / Replay Attack 방지 -> 보안성 향상
6) 독립 스트림 사용으로 향상된 Multiplexing 가능(HTTP/2.0에서도 Multiplexing을 지원해주지만 TCP 자체에서 일어나는 HOL을 개선)
7) 구글의 경우 로딩 시간 평균 3% 개선, 유투브 시청 중 버퍼링 평균 30% 개선
7. HTTP/3.0
1) 2018년 11월에 이미 QUIC을 기반으로 등장 -> 구글은 이미 사용 중
8. 느낀점
급하게 정리한 내용이라 추후 다시 정리 예정