[네트워크]HTTP 1.0, HTTP 2.0, QUIC

그레고리력 2021. 7. 2. 19:35

HTTP 1.0

TCP 기반
연결 한 번에 요청 1, 응답 1 처리 ->서버 부하, 성능 저하
요청 헤더에 Connection: keep alive를 포함해 연결된 TCP 커넥션을 활용하려는 시도를 함(응답 헤더에 Connection: keep alive을 통해 유지)
하지만 Connection: keep alive는 dumb proxy 등의 문제가 있었음

HTTP 1.1

TCP 기반
peristent connection : 지정한 timeout 동안 connection을 닫지 않음(지속 커넥션이 기본 옵션, Connection: close를 보내야 종료)
pipelining : 하나의 커넥션에서 순차적으로 여러 요청을 보내고 그 순서에 맞춰 한 번에 응답을 받는 것(지연 시간을 줄임)
head of line blocking : 1번 요청에 대한 응답이 너무 오래걸리는 경우 전체적인 지연 발생
header의 중복 : 주고 받는 데이터가 쓸데없이 큼

HTTP 2.0

TCP기반
http 메시지 전송 방식의 변화: 텍스트 -> 바이너리 프레이밍 계층 사용(헤더, 데이터 프레임으로 분할, 바이너리로 변환) -> 오류 발생이 줄고 파싱 전송 속도 빨라짐, 메시지(여러 프레임이 모아진것, 요청 응답 단위), 스트림(메시지 여러개가 모여 양방향 통신을 통해 전달되는 하나 이상의 메시지)
한 개의 스트림이 한 쌍의 요청과 응답을 처리, 하나의 커넥션 위에 여러 개의 스트림이 동시에 만들어져 동시 처리 가능, 스트림 우선순위, 흐름 제어 등 가능
모든 메시지는 프레임에 담겨 전송
멀티플렉싱 : 프레임으로 요청을 쪼개서 먼저 도착하는 것이 응답이 가능하도록 해 head of line blocking 해결, stream이 뒤섞여서 전송 될 경우, stream number를 이용해 수신측에서 재조합
리소스 사이 전송 우선순위를 설정할 수 있음
서버 푸쉬 : 클라이언트가 요청하지 않은 데이터를 서버가 능동적으로 응답(관련된 리소스를 서버에서 능동적으로 보내줌, HTML 요청 받으면 CSS 보내는 등 )
header compression : 헤더 압축(중복은 인덱스만, 중복되지 않은 데이터만 인코딩 과정을 통해 압축)
TCP 자체의 haed of blocking: 별개의 스트림으로 데이터를 분류한 것은 TCP는 알지 못하기 때문에 전송된 데이터들이 순서에 맞게 조합되어야 하기 때문에 이에 의한 오버헤드 발생

QUIC

어플리케이션 계층에 신뢰성 구현
전송 계층 프로토콜(like tcp, udp)
udp 기반, 첫 연결에서 필요한 정보와 함께 데이터를 전송, 연결 성공 시 설정을 캐싱
Connection UUID라는 고유한 식별자로 서버와 연결(매번 연결할 필요가 없음)
TLS 기본 적용(SSL: 보안 소켓 계층(Secure Sockets Layer, SSL), TLS: 전송 계층 보안(Transport Layer Security, TLS))
독립 스트림 -> 향상된 멀티플렉싱 기능으로 haed of blocking 해결

HTTP 트랜잭션의 지연 원인

HTTP의 지연은 TCP 네트워크 지연 때문에 발생함

클라이언트가 URL을 통해 IP주소와 포트 번호를 알아내야 하는데 최근 방문한 적이 없는데 DNS를 통해 IP주소를 얻어내는데 시간이 걸림
TCP커넥션 요청을 보내고 연결을 수립하는데 시간이 걸림(TCP 커넥션 핸드쉐이크 지연)
연결 수립후 요청 메시지가 절달되고 서버에 의해 처리되는데 시간이 걸림(확인응답 지연)
웹 서버가 HTTP 응답을 보내는 것 역시 시간이 소요됨
TCP 느린 시작 : 혼잡 제어 목적으로 한 번에 전송할 수 있는 패킷의 수가 제어된다. 성공적으로 전송할수록 가능한 패킷 수가 늘어남, 이미 존재하는 커넷션을 재사용하는 기능(지속 커넥션) 존재
네이글 알고리즘 : 네트워크 효율을 위해 패킷을 전송하기 전에 많은 양의 데이터를 하나로 합침, 작은 크기의 데이터를 매번 전송하면 과부하가 오기 때문에 버퍼에 담아뒀다 한 번에 전송하는 것, 하지만 이로인해 HTTP 성능에 문제가 생김, 하나로 합쳐지기 까지 기다리거나 확인응답 지연과 합해지면 응답이 너무 오래걸림, TCP_NODEONLY 파라미터 값을 설정하면 네이글 알고리즘 비활성화됨

순차적인 트랜잭션 처리에 의한 지연 해결

병렬 커넥션 : 여러개의 커넥션으로 동시에 데이터를 내려받음, 네트워크 대역폭이 좁을 때 효과 없음, 서버에 과부하가 걸릴 수도 있음
지속 커넥션 : 커넥션을 맺는 시간 절약, 병렬커넥션의 경우 느린 시작떄문에 효과가 떨어지고 연결 가능한 커넥션 제한이 있음, 튜닝된 커넥션 장점, 보통 병렬과 지속을 같이 사용함
파이프라인 커넥션 : POST와 같은 비멱등 요청을 계속 보내면 문제가 생길 수 있음
다중커넥션

대역폭과 지연시간

대역폭(Bandwidth) : 단위시간당 얼마나 많은 데이터를 전송할 수 있는지
지연시간(latency) 두 노드 사이에 전송하는데 걸리는 시간
대역폭은 처리할 수 있는 용량(사이즈)를, 지연시간(대기시간)은 전송 속도를 측정
대역폭보다는 레이턴시를 줄이는 방향이 로딩시간을 줄이는데 효과적임