HTTPS
네이버가 네이버라는 것을 증명해줄 CA를 받아와야한다. 브라우저 탭에서 해당 인증서를 확인도 가능, 이것을 암호화해놓으면
브라우저는 그 CA에서 준 공개키를 복호화해서 이것이 CA 키인지 확인을 한다.
데이터 암호화용 조각을 조합해서 HTTP를 암호화해서 주고, 그걸 서버에서 복호화한다. 그리고 일정시간마다 이 암호가 계속 업데이트되기 때문에 해커가 이 키를 복호화할 수 없다.
이런 일련의 과정들을 HTTPS에서 해주는 것. CA 인증을 공짜로 받는 것은 lets encrypt에서!
HTTP1.1
3way handshake 방법이 비효율적이어서 connection: keep-alive 옵션을 통해 연결을 지속.
브라우저 별로 커넥션 수가 제한 되어있다.
HTTP2
Binary Framing Layer
바이너리 기반으로 되어있다. (byte) 텍스트 기반이 아니라 하이퍼미디어 같은 파일들을 전송하기 좋게 업그레이드되었다.
바이너리 기반으로 되어있기 때문에 와이어샤크 등의 분석도구를 써도 못알아보는 경우가 많아짐. 즉 분석이 어려움.
성능이 전보다 최적화된 인코딩 메커니즘이다. 그래서 이전 버전과는 호환이 되지 않아서 서버에서 HTTP2를 사용하는데 클라이언트에서 HTTP1을 사용하면 이용할 수가 없다.
커넥션 동시성 향상
하나의 커넥션을 맺고 여러개의 스트림이 존재. 즉, 한개의 연결을 해도 여러개의 요청을 받아올 수 있다.
-> 용량, 헤더 압축, 커넥션 비효율성 개선을 위해 동시성 향상
서버푸시 기능
서버푸시 기능이 생김. 서버푸시란? 브라우저에서 HTML 먼저 받고 링크 스크립트를 그 후에 받는 형식으로 로딩되었다면,(요청이 추가로 일어남) 지금은 그런 별도의 요청 없이도 HTML 안에서 추가로 요구하는 link 스크립트도 서버에서 같이 파악하여 보내준다. 서버의 기술도 향상이 되었음. 대신 추가작업은 필요하다.
HTTPS 필수
HTTPS를 필수로 설정하도록 되었다.
TCP 기반
TCP 기반으로 되어있다. (TCP의 비효율성은 아직 가지고 있는 상태)
인터넷 상황이 좋지 않을 때 패킷 손실 현상이 일어날 수 있다. 이런 현상이 일어나면 TCP 기반으로 되어있기 때문에 HTTP2의 성능이 매우 떨어지게된다.
HTTP3
UDP 기반
HTTP2에서 TCP의 한계를 극복하기 위해 HTTP3에서는 UDP 기반으로 데이터 통신을 하도록 한다. 즉, 패킷손실 현상이 일어다고 성능이 크게 떨어지지 않는다.
QUIC 프로토콜
구글이 구현한 QUIC이라는 프로토콜을 사용한다.(HTTPS 필수, TLS1.3 버전을 따른다. 기존은 1.2 사용)
UDP의 단점인 패킷이 손실되어도 책임지지 않는 부분, 그리고 암호화 기능이 없어 보안에 취약한 부분을 보완하였다.
UDP를 사용하여 일어나는 패킷 손실을 보완하기 위해 각 패킷에 식별 정보를 부여하고, 전송 순서나 패킷손실에 대한 문제가 생기면 재전송하는 알고리즘을 도입함으로써 이 부분을 해결하였다.
QUIC에서는 전송계층 자체에서 암호화기능을 통합하여 기본적으로 내장된 기능으로 활용하도록 하였다.
동영상 서비스에서 속도가 매우 빠르다. (넷플릭스, 유투브에서 HTTP3를 사용하기 때문에 속도가 매우 빠르다)
응용계층으로 HTTP 뿐만 아니라 다른 프로토콜도 올릴 수도 있다.
zero round trip time
0RTT(zero round trip time)이 가능하다. 3way handshake를 극복했다는 뜻.
HTTP2까지는 TCP 기반이라서 3way handshake를 통해 데이터를 주고받게 되는데, HTTPS까지 주고 받으면 3RTT(three round trip time)를 무조건 하게된다.(데이터를 주고받는데 3번 왔다갔다한다는 뜻. 매우 비효율적)
이걸 극복하고 1RTT로 데이터를 주고받을 수 있도록 개선함. 최대로 0RTT도 가능.
TCP의 비효율성을 UDP로 극복하여 동영상 서비스에서 속도가 빠르다.