CHAPTER4 - HTTP/2로의 전환

조금 불친절하게 말하자면, HTTP/2를 지원하기 위해 해야 할 모든 일은 h2로 통신하는 웹 서버로 업그레이드하거나 실제 웹사이트를 대신해 h2로 통신할 콘텐츠 전송 네트워크를 사용하는 것이다. 비록 사실일지라도, 이것은 설명하기 어려운 많은 미묘한 부분을 대충 덮어 버리는 것이며, 예상치 못한 큰 대가를 치르거나 성능이 최적 상태에 못 미칠 수 있다. 다음은 웹사이트를 HTTP/2로 전환하기 전에 고려해야 할 몇 가지 항목들이다.

• 브라우저의 h2 지원
• TLS(HTTPS)로의 전환
• 웹사이트의 h2 최적화(h1용 설정 제거)
• 웹사이트의 서드파티 개체
• 기존 클라이언트를 위한 지원 유지

이번 장에서는 이 주제들에 대해 알아야 할 것들을 설명한다.

4.1 브라우저 지원

이 책의 집필 시점을 기준으로, 약 80%의 웹 브라우저가 h2를 어느 정도 지원하고 있다. 이는 h2로 전환하기만 하면 많은 사람들이 즉시 h2의 혜택을 누릴 수 있음을 의미한다. h2를 지원하지 않는 브라우저에서는 프로토콜 협상 절차가 무시되므로, h2로 통신하지 않는 브라우저는 쉽게 다시 h1으로 되돌아와 인프라에 접속할 것이다(h1 지원을 유지하는 경우).

[표 4-1]은 HTTP/2 를 지원하는 브라우저와 그 버전을 보여준다.

브라우저명	최소 버전	비고
크롬	41
파이어폭스	36
엣지	12
사파리	9	OSX 10,11 이후
인터넷 익스플로러	11	윈도우 10만 해당
오페라	28
사파리 - iOS	9.2
안드로이드 브라우저	51
크롬 - 안드로이드	51

4.2 TLS로의 전환

모든 주요 브라우저가 TLS(HTTPS 요청 등)로만 h2에 접속하기 때문에, TLS를 지원하지 않으면 할 수 있는 것이 아무것도 없다. 그리고 TLS 버전은 높게 설정해야 한다. 적어도 일시적 암호화 기능이 있는TLS 1.2는 지원해야 한다(자세한 내용은 RFC 7540의 9.2절을 참조). 보안을 중요시하는 현대의 웹사이트 대부분은 'TLS everywhere' 운동에 참여하고 있어 사용자들은 크게 신경 쓸 것이 없지만, 그렇지 않은 경우에는 시간과 자원의 투자가 이루러져야 한다.

NOTE_ 이번 절이 TLS로 웹사이트를 보호하는 방법에 관한 안내서로 의도된 것은 아니다. 이 주제를 다루는 책들은 많다. 사이트의 보안을 관리하는 일은 놓치기 쉬운 함정이 많기 때문에 쉬운 일이 아니다. 시간을 가지고 웹사이트에서 적용한 도구를 학습하라. TLS와 인증서에 관한 훌륭한 안내서로, 일리아 그리고릭의 책 "네트워킹과 웹 성능 최적화 기법"(인사이트, 2015)을 추천한다.

가능한 한 힘들이지 않고 웹사이트에서 TLS를 사용할 수 있도록 지난 5년간 많은 활공이 있었지만, TLS로 전환하는 일은 여전히 쉽지 않다. TLS로 전환하려면 다음과 같은 항목을 고려해야 한다.

웹 서버를 파악하라

모든 웹 서버는 HTTPS 설정 방식이 조금씩 다르다.

인증서를 확보하라

EV, OV, DV, CN, CSR, X509, SAN과 같이 이해하기 쉽지 않은 새로운 약어들이 많이 존재한다. 웹사이트용 인증서를 발급받기 위해서는 보통 CSR생성, 신청자의 신원 및 인증서가 대표할 도메인이름의 소유권 검증, 인증 기관에서의 인증서 구매와 같은 여러 단계가 필요하다. 선택할 수 있는 CA는 많이 있다. Let`s Encrypt와 같은 기관들은 인증서를 쉽고, 빠르고, 심지어 무료로 발급하고 있다.

개인키를 보호하라

인증서는 관리자가 신경 쓰는 만큼만 안전하다. TLS로 안전하게 사이트를 운영하려면, 개인키를 어디에 어떻게 저장할지, 누구에게 접근을 허용할지를 고려해야 한다. 매우 비싼 HSM장비를 사용하는 것부터 단순히 행운을 빌면서 좋은 관례를 사용하는 것까지 다양한 해결책이 있다. TLS를 처음 도입하는 경우라면, 개인키를 보호하는 일은 운영계획의 중요한 부분이 될 것이다.

증가하는 거버 부하에 대비하라

TLS를 가능한 한 저렴하게 보급하려는 노력이 많이 있었지만, 이것은 3보를 전진하고 2보를 후퇴하는 게임과 같다. 대칭 암호의 최적화는 부하를 줄이는 데 많은 도움이 되었지만, 임시키 교환의 사용은 반대로 부하를 증가시켰다.(비록 모든 것을 더 안전하게 해주었지만). 다음은 처음 시작할 때 고려해야 할 몇 가지 모범 사례다.

• 연결을 가능한 한 길게 유지하라. TLS의 가장 비싼 부분은 연결하는 동안의 핸드셰이크 시간이다. 연결을 가능한 한 길게 유지하면 필요한 핸드셰이크 수를 줄일 수 있다.
• 세션 티켓을 사용하라. 세션 티켓을 사용하면 클라이언트는 이전의 핸드셰이크에서 얻은 값비싼 암호 계산값을 재사용하여 서버에 다시 연결 할 수 있다.
• 암호화 지원을 내장한 칩셋을 사용하라. 최신 인텔 프로세서의 AES-NI명령어는 대칭키 암호화 작업을 매우 빨리 처리할 수 있다.

변화를 주시하라

웹 보안은 역동적인 세계다. 수개월마다 서버와 HTTPS에 새로운 취약점이 발생하고 있다. 이제의 작업이 내일 쓸모 없어지지 않게 하려면 '최신과 최고'를 계속 따라잡는 것이 중요하다.

웹사이트를 주기적으로 점검하라

퀼리스 랩의 SSL Test와 같은 도구를 사용하여 웹사이트의 TLS 구성을 점검해야 한다. 이들은 TLS에 의존하는 서빅스를 준비할 때 내재화 해야 할 모범 사례들이지만, TLS는 그 중요성을 깨닫기까지 적시에 많은 투자가 필요한 방대한 주제다. 다음 격언을 기럭하라.

적은 지식은 위험한 것이다. 깊이 마셔라, 그렇지 않으면 시적 영감의 샘물을 마시지 마라(a little learning id a dangerous thing,'Drink deep, or taste not the Pierian spring

-알렉산더 포프

TLS는 필수인가? 단순한 대답은 '아니오'다. 현실적인 대답은 '그렇다'이다. HTTP/2는 규격상 TLS가 필요 없으며 평문으로 프로토콜을 협상하는 기능을 제공하지만, 어떤 주요 브라우저도 TLS 없이는 h2를 지원하지 않는다. 그 이면에는 두 가지 이유가 있다. 첫째, 웹 소켓과 SPDY를 시험한 결과, 80 포트(평문 HTTP)를 통해 Upgrade 헤더를 사용하면 프락시 차단 등의 원인으로 인해 매우 높은 오류율을 보였다. 443 포트(HTTPS)를 통해 TLS로 요청을 보내면 훨씬 더 낮은 오류율과 더 깔끔한 프로토콜 협상 절차를 볼 수 있었다. 둘째, 안전과 개인전보 보호를 위해 모든 것을 암호화해야 한다는 믿음이 증가하고 있다. HTTL/2는 진보하는 웹 전반에 걸쳐 암호화된 통신을 촉진시키는 기회로 볼 수 있다.

4.3 HTTP/1.1 최적화 제거하기

웹 개발자들은 h1을 최대한 활용하는 데 많은 노력을 디울여 왔다. 그 몇 가지 예로, 결합, 샤딩, 축소화, 쿠키 없는 도메인, 스프라이팅과 같은 패턴이 등장했다. 독자들은 이 패턴 중 일부가 h2에서는 안티패턴이 된다는 사실에 놀랄지도 모른다. 예를 들어 , 결합(여러CSS나 자바스크립트 파일을 하나의 파일로 합치는 것)은 브라우저가 다량의 요청을 하는 일을 덜어줄 수 있다. 이 패턴은 요청의 대가가 비싼 h1에서는 중요하지만, h2에서는 요청의 구조가 훨씬 더 최적화 되었다. 결합을 하지 않아야 요청 오버헤드가 적어지고 개별 파일에 대한 더 세밀한 브라우저 캐싱을 활용할 수 있다.

[표 4-2]는 h1 요청을 최적화하는 데 사용하는 흔합 기법 몇 가지와 h2에서 고려해야 할 사항을 보여준다.

패턴	설명	제안사항
결합	HTTP 요청 수를 줄이기 위해 다수의 파일(CSS, 자바스크립트)을 하나의 파일로 결합하는 패턴	HTTP/2에서는 바이트 수와 소요 시간 측면에서 요청 오버헤드가 전혀 없지는 않지만 훨씬 적기 때문에 꼭 필요하지는 않다
축소화	HTML,자바스크립트, CSS 등의 파일에서 불필요한 바이트를 제거하는 패턴	HTTP/2에서도 유지해야 할 좋은 패턴
샤딩	브라우저가 더 많은 소켓을 사용할 수 있도록 개체들을 다수의 도메인으로 분산하는 패턴	HTTP/2는 단일 소켓을 사용하도록 설계되었으며, 샤딩을 사용하면 이 설계 목적을 훼손하게 된다. 샤딩을 제거하되, 이 표 다음에 이어지는 보충 설명을 읽어보라. 샤딩의 명암을 설명한다.
쿠키 없는 도메인	요청 크기를 최소화하기 위해 이미지 등을 위한 도메인에는 쿠키를 사용하지 않는 패턴	개체를 위한 별도의 도메인은 피해야 하며(샤딩 참조). 더 중요한 것으로 HTTP/2의 헤더 압축 덕분에 쿠키의 오버헤드가 상당히 줄었다.
스프라이팅	다수의 이미지가 포함된 이미지 지도를 만든 후 웹 페이지에서 CSS로 잘라서 사용하는 패턴	CSS 처리가 꽤 비쌀 수 있다는 점을 제외하고 축소화와 유사하다. HTTP/2에서는 사용하지 않기를 권장한다.

샤딩을 할 것인가, 하지 않을 것인가? HTTP/2는 단일 TCP/IP 소켓에서 최적으로 동작하도록 설계되었다. 이는 하나의 소켓을 열고 적절한 혼잡도에서 동작하는 것이 다수의 소켓을 조율하는 것보다 훨씬 더 신뢰성 있고 성능이 좋다는 개념을 토대로 한다. 하지만 아카마이 파운드리 팀의 연구에 따르면 이러한 전략은 성공적이지 않은 것으로 밝혀졌다. 사이트 구성에 따라, 여러 소켓이 단일 소켓보다 더 나은 경우가 여전히 있다. 이는 TCP 혼잡 제어가 동작하는 방식과 최적의 설정으로 맞춰지는 데 걸리는 시간과 밀접한 관계가 있다. 초기 혼잡 윈도우 크기가 매우 크면 이 문제를 줄이는 데 도임이 되지만, 큰 윈도우를 지원하지 못하는 네트워크에서는 문제가 될 수도 있다. 이것은 우리가 h2를 가장 잘 활용하고 최적화하는 방법을 시시각각 삭습하고 있음을 보여주는 한 예일 뿐이다. 최적의 웹사이트 설정을 찾으려면 반복해서 개발하고 시험하고 수정해야 한다.

충분한 시간을 가지고 웹사이트를 h2에 최적화했더라도, 아직 한 가지 문제가 있다. 트래픽의 25%는 여전히 h1 클라이언트에서 들어오며, 그 h1 클라이언트의 성능 또한 최적화해야 한다. 모두가 만족하기는 매우 어렵다. 사용자를 철저히 분석하면 최적화할 대상 그룹을 알 수 있을 것이다. 또는, 조건에 따라 h1과 h2 사용자에게 다른 콘텐프를 제공하거나, 마법의 힘을 발휘하는 CDN 등의 도구를 사용할 수도 있다.

4.4 서드파티

비록 애증의 존재이긴 하나 웹사이트의 서드파티 콘텐츠는 피할 수 없는 현실이다. 서드파티 콘텐츠는 직접 제어할 수 없기 때문에, 서드파티 콘텐츠의 지원 범위에 따라 성능이 좌우된다는 문제가 있다. h2가 단일 소켓 환경에서 가장 잘 동작한다면, 서드파티는 어떤 영향을 미치는가? 사실, 서드파티 콘텐츠는 h2에서도 달라질게 없이, HTTP/2에서 얻을 수 있는 잠재적인 성능상 이득을 저해하는 요인이 될 수 있다. 서드파티가 TLS를 지원하지 않으면 골치가 더 아파진다. 서드파티 콘텐츠가 웹 페이지 성능에 미치는 영향도에 관한 연구에 따르면, 많은 경우에 서드파티 콘텐츠가 웹 페이지의 성능에 큰 영향을 미치는 요인 중 하나로 지목되고 있다. 그렇다면 서드파티 콘텐츠를 어떻게 해야 하는가? 다음 질문에 대한 대답부터 찾아보라.

• 서드파티 콘텐츠가 TLS를 지원하는가?
• 서드파티 콘텐츠가 HTTP/2를 지원할 계획이 있는가?
• 서드파티 콘텐츠가 제공하는 중요한 요소인 성능 영향도를 최소화하고 있는가?

이 질문 중 하나의 대답이라도 '아니오'라면, 다음 2개의 후속 질문을 해야 한다.

• 원하는 기능을 제공하는 다른 서드파티가 있는가?
• 이 서드파티 콘텐츠가 정말 필요한가?

4.5 기존 클라이언트의 지원

변화를 좋아하지 않는 사람들이 있다. 그들의 현재 브라우저는 잘 동작하고 있으며, 업그레이드는 귀찮은 일일 수 있다. 문제는 이러한 사람들이 포기할 수 없는 고객이나 사용자일 수 있다는 점이다. 마이크로소프트는 2014년 4월 8일 윈도우 XP에 대한 지원을 종료했다. 이는 XP사용자는 최신 브라우저와 보안 측면에서 점점 더 뒤처지게 됨을 의미한다. 말할 필요도 없이, XP의 인터넷 익스플로러는 h2로 통신할 수 없다. 더 중요하게, TLS 설정과 대체 평문 사이트의 존재 여부에 따라 그 사용자들은 h1으로도 웹사이트에 접속하지 못하게 될 수도 있다! 어떤 면에서는 진보 과정에서 불가피한 일일 수 있지만, 다은 면에서는 이들이 중요한 사용자와 고객일 수도 있다. 이러한 현실은 HTTP/2로 전환하기 전에 고려해야 할 또 다른 항목이다.

4.6 요약

HTTP/2로의 전환은 보통 좋은 일로 간주하고 독자의 웹사이트에도 예외 없이 적용해야 하지만, 스위치를 켜기 전에 고려해야 할 점이 분명히 있다. 많은 주요 웹사이트가 오랫동안 h2를 구동해 오고 있지만, 이 사실이 누구에게나 승리가 보장되었음을 의미하는 것은 아니다. h2로의 전환은 다른 중요한 변경과 동일하게 다루어야 한다. 시험하고, 시험하소, 또 시험해야 한다.