[CS] HTTP1.1 HTTP2.0 QUIC

10분 테코톡 쿨라임님 손너잘님 발표자료 참고했습니다.

---

 

HTTP1.1&HTTP2&QUIC

• HTTP는 Application Layer의 프로토콜.
• HTTP는 신뢰성있는 연결만 해줄 수 있다면 전송프로토콜은 TCP/UDP 뭘써도 상관없다고함.

TCP(Transmission Control Protocol)

• connection을 수립하기 전에 신뢰성 있는 Connection을 위해 3 Way Handshake를 함.
• 

3 악수를 통해 연결이 수립되면 데이터를 전송함. 전송하면 잘 받았다고 응답을 보냄(유실되면 다시 데이터 요청)

제어, 핸드셰이커, 등등신뢰성 구축에 신경을 많이씀.

UDP(User Datagram Protocol)

신뢰성 x 받는걸 신경을 안쓰고 그냥 보냄.

TCP vs UDP

HTTP

0.9

요청도 GET밖에없음. only HTML

1.0

헤더생김, 상태코드, 버전, content-type생김(HTML말고 다른타입도)

커넥션 하나당 요청하나, 응답하나만 처리할 수 있음. => 요청당 연결을 수행해 성능이 저하됨(삐효율)

1.1 퍼시스턴트 커넥션

커넥션을 열어두면 여러 요청이 이 커넥션을 사용할 수 있음.(지속 커넥션)

단기 커넥션하고 비교해보면 네트워크 사용시간이 훨씬 줄어듦.

파이프라이닝

HTTP요청은 순차적으로 받아야함(1->2->3)

파이프라이닝을 통해 여러 요청을 많이 보내 순서에 맞게 응답을 받는 방식.

파이프라이닝 치명적인 문제점

첫요청이 오래걸리면 다른 요청들도 병목이 생김.

요청한 Request문제 발생, Latency증가.

=> Damain Sharding이 나옴.(도메인 명을 다르게해서 리소스를 나눠 저장함)=> 요청있으면 나눠진것에서 병렬적으로 리소스를 보내줌

but 이거도 대역폭을 너무 많이씀.

중복이 많은데 그대로 전송을 함(주고받는 데이터가 쓸데없이 커짐.)

HTTP2

대체가 아닌 기존의 확장.

컴퓨터가 좋아하는 바이너리로 전송함(텍스트가 아니라) => 파싱, 전송속도 올라가고 오류 발생 가능성 내려감.

메세지를 Header와 Data로 분할함.

스트림이라는 데이터 양방향 흐름안에, 프레임 조각 조각들이 합쳐져서 요청이나 메시지가 된다.

이걸 바탕으로 요청 응답이 다중화가 가능해짐. (프레임으로 쪼개져서 메시지간 순서가 사라짐)또 인터리븐이라고 끼어드는 방식도 있음.

=> Head of line blocking 해결

리소스간 전송 우선순위 설정 가능(우선순위 가중치를 줘서 설정.)

요청없어도 서버가 알아서 푸시해줌.(요청은 html이었으나 css, js도 알아서 푸시해줌.)

헤더 압축.(중복된 부분은 인덱스만 뽑고 중복 안된거는 허프만 인코딩을 해서 압축.)

헤더를 85퍼센트 줄임. 페이지 로드시간도 줆.

QUIC

UDP기반.

TCP는 지연을 줄이기 힘듦.

지연은 줄이고 신뢰성을 올리기위해 UDP기반으로 함.

설정을 캐싱해 핸드셰이크 없이 다음연결때 전송을 가능하게함.

ip가 바뀌어도 유지됨

소스 어드레드 토큰을 필요에 따라 발급해 IP Spoofing, Replay Attack방지

TCP도 병목이 있을 수 있음(중간 데이터 손실 시) 녹색 망가져도 빨간색도 못움직임

노란색이 문제생기면 파란색은 정상적으로 수행

HTTP3 이미나오고 구글은 쓰고있음. 아직 HTTP2가 점유율 40프로긴함.

네트워크 성능하락의 가장 큰 요인?

• Bandwidth
  • 데이터를 많이 주고받기 위해서는 큰 대역폭이 있으면 아니야?
  • 애초에 대역폭이 크면 데이터 전송 속도가 빨라지잖아?
  • => 실험 결과 한계가 있음. 대역폭은 일정 수준 이상부터 성능수준이 수렴함.
• Latency
  • 딜레이가 없어야지.

=> Latency가 성능의 핵심임.

---

HTTP의 발전은 TCP에 의해 이루어짐.(TCP성능 하락을 이겨내기 위해 HTTP가 발전을 함. TCP는 IP위에서 동작을 함.)

TCP는 느린전송을함(데이터 크기에 제한을 둠.) => 문제가 많음 => TCP 커넥션을 재활용할 방법을 찾기 시작함.(keep alive)

=> 1.1버전에서는 재화용이 가능하게 됨. but 병목은 해결 못함.

=>HTTP2 하나의 TCP커넥션을 통해 여러개를 병렬처리 할수있게 됨. but TCP HEAD OF LINE BLOCKING 발생.

=> 구글이 QUIC을 사용. => 독립 스트림(TCP체인을 병렬연결해 하나 병목생겨도 다른건 돌아감)을 통해 HEAD OF LINE 해결.