http2 컨셉
http2로 무엇을 이룰 수 있을까요? HTTPbis 그룹이 시작한 일이 무엇인지에 대한 경계는 어디일까요?
경계는 사실상 상당히 엄격했으며, 팀 능력 향상, 동기부여의 가능성을 방해하는 구속의 역할을 했습니다.:
http2 패러다임을 유지한다. 이것은 아직 client가 TCP server에 requests를 보내는 프로토콜의 형태를 띄고있습니다.
http:// and https:// URLs 은 변할 수 없다. 그것을 위한 새로운 scheme 같은 것은 없다. URLs같은 것들을 이용하는 모든 콘텐츠는 바꾸기엔 너무나도 많은 예외처리를 해주어야하기 때문입니다.
HTTP1 server 와 clients는 앞으로도 수십년은 존재하고 있을 것이며, 우리는 이것들을 http2 서버로 proxy 할 수 있어야합니다.
그 후, proxy들은 http2 features 와 HTTP 1.1 clients간의 1 대 1 관계를 만들 수 있어야 합니다.
프로토콜에서 오는 선택 사항들을 없애거나 줄여야 합니다. 이것들은 요구사항이 아니지만 SPDY와 Google팀 으로부터 나온 mantra 입니다. 모든 것을 마킹하는 것은 필수적이며 당신이 구현하지 못할 상황에 빠지거나 나중에 함정에 빠지는 상황이일어나지 않게 해줄것입니다.
더 이상 이전버전은 없다. 이것은 clients와 server가 http2에 호환되거나 그러지 그렇지 않거나를 결정 짓는데에서 도출된 결과입니다. 만약 프로토콜의 확장이나 수정에 대한 필요성이 대두된다면, http3가 탄생하게 될 것입니다. 적어도 http2에서 이전 버전은 존재하지 않습니다.
5.1 현존하는 URI schemes에 대한 http2
앞서 언급했지만, 현존하는 URI schemes 는 수정될 수 없습니다, 그래서 http2를 사용해야합니다. HTTP 1.x 버전을 사용하게 된 이후로 오늘날 까지, 우리는 확실히 http2 에서 프로토콜에 대한 업그레이드가 있어야 한다고 생각습니다. 아니면 낡아빠진 프로토콜 대신 서버가 http2를 사용하도록 해야했습니다.
HTTP 1.1 은 이 작업을 수행하기 위해서 정의된 방법이 있는데, 업그레이드: 헤더라고불리는 낡은 프로토콜로 보내진 리퀘스트를 받으면 자동으로 새로운 프로토콜 응답으로 반환하는 방법입니다.
왕복 패널티는 SPDY팀이 받아들일 만한 문제가 아니었으며, 그들은 SPDY를 TLS에서만 구현하고 있었기 때문에, 그들은 협상을 단순화 하는 TLS의 확장판을 개발해내었습니다. 이 NPN(Next Protocol Negotiation이라고 부른다.) 확장판을 이용하면, server는 자신이 알고있는 프로토콜을 이용해서 client를 호출하며 client는 이 프로토콜을 받을 수 있습니다.
5.2. https://를 위한 http2
수많은 http2의 초점은 TLS에서 적절하게 동작하는 것이었습니다. SPDY는 TLS가 필요하며, http2에서 사용하도록 TLS 를 크게 밀어주는 경우도 있었습니다, 하지만 이는 합의점을 찾지 못했고 결국 TLS는 http2에서 필요없게 되었습니다. 그러나 현대의 흐름을 주도하는 두 웹브라우저인 Google Chrome 과 Mozilla Firefox 개발진들은 TLS에서 http2를 구현했다고 말했습니다.
TLS-only 방식을 선택하게 된 이유로는 사용자들의 프라이버시와 새로운 프로토콜이 TLS와 함께 이용될 때 더 높은 성공률을 보인다는 것이 일찍이 수치상으로 증명이 되었다는 두 가지 이유를 높이 샀기 때문입니다. 80번 포트를 지나가는 모든 HTTP 통신은 몇몇 중간 장치 통신을 방해하거나 해당 포트를 이용하여 다른 프로토콜을 보낼때 트레픽을 파괴하는 경우가 생깁니다.
TLS를 필수적으로 쓸 것인가에 대한 주제는 메일링과 미팅 자리에서 너무 많은 수필과 격양된 목소리(이게 좋은 것인가 나쁜것인가에 대한)가 오고 갔기 때문에 대두되었습니다. 혹시라도 이 주제에 대한 질문을 HTTPbis 참가자 앞에서 던질때는 조심해야할 필요가 있습니다.
비슷한 예로, http2 는 TLS 를 사용하는 경우 의무적으로 해야 암호 목록 을 지시해야 하는가에 대한 열띈 토론이 진행된 적이있습니다. 결국에 TLS는 1.2 버전 이후로 암호화 suite에 제한을 의무화 하기로 했습니다.
5.3. TLS를 이용한 http2 협상
Next Protocol Negotiation (NPN)은 SPDY와 TLS서버의 협상에 이용되는 프로토콜입니다. 이것은 표준화되지 않았기 때문에, IETF에서 논의한 결과, ALPN: Application Layer Protocol Negotiation이 탄생하였습니다. SPDY client와 server가 NPN을 사용하는 동안 ALPN은 http2에서 사용하기 위해 지속적으로 추진되어왔습니다.
NPN가 먼저 존재하고 ALPN이 표준화를 통해서 이용된 사실은, http2 협상 때 수많은 http2의 server와 client의 구현과 두가지의 확장성을 이끌었습니다. 또한 NPN 는 SPDY 로 사용 되어 많은 서버 가 SPDY 와 http2 을 모두 지원 하기 때문에 NPN 과 ALPN 을 이 서버 에서 지원 하는 것은 의미가 있습니다.
ALPN과 NPN간의 차이는 어떤 프로토콜을 이용할 것인지 결정하는 것에 있습니다. ALPN은 client가 server에게 우선순위로 나뉘어 정렬된 프로토콜 리스트를 보내고 서버는 그중에서 원하는 것을 선택합니다, 반면 NPN은 client가 최종 결정을 합니다.
5.4. http://를 위한 http2
앞서 언급한 바와 같이, 일반 텍스트 HTTP 1.1 은 http2를 협상하기 위해서 Upgrade된 header를 보냅니다. 만약 server가 http2를 말한다면, "101 Switching" status 코드를 반환하고 http2로 스위칭시켜 연결할 것입니다. 물론 이 업그레이드 절차는 풀 네트워크 라운드트립을 필요합니다, 하지만 http2의 장점은 훨씬 더 오랫동안 연결을 유지할 수 있다는 것이며, HTTP1 여결보다 재사용성에 있어서 더 뛰어난 성능을 보여줍니다.
몇몇 브라우저들은 이런식으로 http2를 구현하지 않는다고들 하지만, 인터넷 익스플로러 팀은 그 반대의 의견을 갖고있으며 curl은 이미 그것들을 지원하고 있습니다.
Last updated