-
- HTTP/1.1과 HTTP/2.0의 가장 큰 차이점
- HTTP1.1은 커넥션 하나에 한 요청과 한 응답밖에 못받았다. 그래서 지연되는 문제때문에 여러 커넥션을 열고 이전에 보낸 요청에대한 응답이 안와도 다음요청을 했는데, 이것도 열수있는 커넥션 수가 제한 되어 있기때문에 지연성 문제를 완전히 해결하지는 못했다.
- 2.0에서는 하나의 커넥션에 여러개의 스트림이 동시에 열릴수있다. 즉 하나의 HTTP/2.0 커넥션을 통해 여러개의 요청이 동시에 보내질 수 있어서 HTTP1.1에서 겪던 문제를 쉽게 해결 할 수 있다.
- 모든 스트림은 31비트의 무부호 정수로 된 고유한 식별자를 가진다
- 스트림이 클라이언트에 의해 초기화 되었다면 이 식별자는 홀수, 서버라면 짝수이다. ㄷ새로 만들어지는 스트림의 식별자는 이전에 만들어졌거나 예약된 식별자보다 반드시 커야한다. (어기면 PROTOCL_ERROR 라는 커넥션 에러가 발생한다.)
- 한번사용한 스트림 식별자는 다시 사용할 수 없는데 그렇다면 커넥션을 다시 맺으면 그만이다.
- 서버와 클라이언트는 커넥션을 맺고나서 스트림을 상대방과 협상 없이 일방적으로 만든다. 즉, TCP 패킷을 주고받는데 시간을 안써도 된다.
- 헤더 압축
- HTTP1.1 에서는 헤더를 그냥 보냈는데 이제는 페이지 하나볼려고 수백번 요청을 해야할 수도 있기때문에 헤더가 크면 느려진다.
- 그래서 압축한다
- 서버 푸시
- HTTP2.0에서는 서버가 하나의 요청에 대해 응답으로 여러 리소스를 보낼 수도 있다. 이를 통해 클라이언트가 어떤 리소스를 요구할지 미리 알수있을때 유용하다.
- HTML문서를 요청받으면 클라이언트가 앵간하면 이미지, css, js 파일등을 다시 요청을 할텐데 이를 클라이언트가 html을 파싱하고 요청할때까지 기다리지말고 그냥 바로 쏴줘 버린다.
- 리소스를 푸시하려는 서버는 먼저 클라이언트에 자원을 푸시한다고 PUSH_PROMISE 프레임을보내줘야한다. 클라이언트가 이 프레임을 받고나면 해당 스트림은 클라이언트입장에서는 예약됨(원격) 상태가 된다
- 이때 RST_STREAM을 클라이언트가 서버로 보내면 스트림이 즉각 닫힌다
- 닫히기전까진 클라이언트는 서버가 푸시해주려는 리소스를 요청해선 안된다
- 이런 방법을 쓰는건 서버가 보내주려는 자원을 클라이언트가 별도로 또 요청하는 상황을 피하기 위해서 이다
- 그래도 중간에 낀 프락시 서버때문에 완전 잘못될수도 있어서 주의를 해야한다.
- 서버는 추가 리소스를 줬는데 프락시가 전달안해줄수도있다.
- 서버는 추가 리소르르 안 줬는데도 프락시가 지멋대로 클라이언트에 추가 리소스를 줄 수도있다(대환장...)
- 보안 위협
- 커넥션이 길다보니까 이전에 브라우저를 사용했던 사람이 떠난 후에 다음에 해당 브라우저를 사용하는 사람이 이전에 한 사람이 무슨 정보로 이용했는지등을 볼 수 있어 개인정보 유출 위험이 있다.(커넥션 유지 기간이 짧을때보다 위험이 커졌단 말!)