Cloud Computing On Demand

HTTP/2 시대가 시작되면서 다양한 성능 개선을 위한 사례들을 요즘 찾아보고 있습니다. QUIC 도 그중 하나이고 TCP Fast Open 이라는 표준 역시 살펴봐야 할 사례인 것 같습니다. 공부할 건 많고 시간은 없고 머리는 안돌아가고... 그래도 일단 필요한 링크들을 모아봅니다. 먼저 공부하시는 분들이 계시다면 정리해서 공유를... 굽신...

출처 : 구글 기술문서 (아래의 링크5)

링크1 - RFC 7413 - TCP Fast Open (Experimental) : https://tools.ietf.org/html/rfc7413

링크2 - Cent OS 7 + nginx 환경에서 TCP Fast Open 활성화 하기 : https://goo.gl/pRmWZO

링크3 - TCP Fast Open 위키피디가 : https://en.wikipedia.org/wiki/TCP_Fast_Open

링크4 - curl 7.49.0 의 특정 운영체제 버전에서 옵션 제공 : https://curl.haxx.se/libcurl/c/CURLOPT_TCP_FASTOPEN.html

링크5 - 구글에서 발표된 기술 문서 : http://goo.gl/rz1sqX

링크6 - Keycdn 의 아티클 (일종의 요약) : https://www.keycdn.com/support/tcp-fast-open/

- NoPD -

대세는 https 입니다. 새로운 http 표준인 http/2 (aka h2) 는 Clear Text 에 관한 규약을 가지고 있긴 하지만 시장에 있는 대부분의 브라우저들은 TLS 기반의 통신을 http/2 를 이용하기 위한 기본 조건으로 내걸고 있습니다. 프로토콜의 변화 뿐만 아니라 렛츠인크립트(Let's Encrypt)와 같은 무료 인증서 배포가 대중화되기 시작하면서 스트리밍(Streaming)과 같이 레이턴시(Latency)에 민감한 부문을 제외하면 전반적인 https 로의 전이가 그리 오래 걸릴 것 같지는 않습니다.

그런데 https 규약 자체가 보안을 의미하지는 않습니다. https 는 공개키 기반의 인증 기술을 활용하여 브라우저(클라이언트)와 서버가 통신하는데 있어서 외부에서 침투할 수 없는 채널을 만들어주는 기술이지 사전에 악의적인 사용자가 서버측에 대한 탈취를 한 경우에는 큰 소용이 없습니다. 소위 맨 인더 미들 어택(MITM, Man In The Middle Attack)과 같은 것들이 그런 사고를 지칭합니다. 때문에 공개키 기반이라는 특성을 활용하여 SSL/TLS Handshake 를 하는 과정에 일종의 검증 절차를 넣어 그런 사고를 줄이고자 하는 것이 OCSP (Online Certificate Status Protocol) 입니다.

출처 : WWDC 2016 - 애플 시큐리티 세션

OCSP 는 기본적으로 클라이언트와 서버가 통신하는데 있어서 인증서를 발행한 사업자, 소위 CA (Certificate Authority) 라고 불리우는 회사의 서버를 통해 내가 접속하고자 하는 서버가 올바른 서버인지를 확인하는 절차입니다. 이 배경에는 각 CA 가 인증서를 발급하는 과정에 취하고 있는 다양한 확인 절차가 있습니다. 이 절차를 통해 발급된 인증서는 믿을 수 있다는 전제하에 클라이언트가 서버로 부터 전달받은 인증서를 발급자에게 "유효하고 정상적인 인증서인가?"를 질의하는 절차입니다.

문제는 안그래도 SSL/TLS Handshake 로 https 통신을 시작하기 위한 비용과 시간이 큰 편인데 CA 의 서버까지 컨택하고 와야 하니 딜레이가 더 커지면서 웹 사이트나 서비스 이용에 안좋은 영향을 끼치기 시작했다는 점입니다. 여기에 더하여 CA 의 서버가 과부하 등으로 제대로 응답하지 못하거나 이슈가 생긴 경우에는 OCSP 가 제대로 진행되지 못하는 상황이 발생할 수 있다는 것이 확인되었습니다. 그래서 이런 절차를 조금더 단순화하면서도 보안을 여전히 보장해보자 하는 관점에서 등장한 것이 OCSP Stapling 입니다.

출처 : WWDC 2016 - 애플 시큐리티 세션

OCSP Stapling 은 "스테이플링" 이라는 이름에서 보이는 것처럼 인증서가 유효하다는 정보를 클라이언트가 접속하고자 하는 서버가 CA 의 인증 서버를 통해 확인받고 이 정보를 사용자에게 인증서를 전달할때 같이 주는 방식입니다. 클라이언트가 글로벌에 분포된 불특정 다수의 사용자라고 하면 서버는 상대적으로 훨씬 적은 수라는 점에서 CA - 서버간의 통신이 이슈가 될 상황이 훨씬 적을거라는 추정이 가능합니다.

웹 서버의 응답은 브라우저나 프록시, CDN 등 모든 계층에 있어서 중요한 값입니다. 특히 컨텐츠가 캐시되어야 하는 경우 혹은 캐시되지 말아야 하는 경우에 대하여 정확한 지시자(Directive)를 내려주지 않으면 잘못된 정보가 캐시되고 다른 사용자들과 공유되어 보안사고나 정보 유출이 있을수도 있고, 엉뚱한 컨텐츠가 캐시되어 제대로된 서비스가 제공되지 못할 수도 있습니다. 따라서, 정확한 헤더와 적절한 지시자를 내려주는 것이 중요합니다.

공개되어 있는 완성된 제품 (예: 워드프레스) 을 이용하는 경우에는 솔루션이 적절한 헤더 값으로 응답을 합니다만 직접 모든 것을 개발한 웹 서버, 웹 서비스라면 필요한 값을 적절히 지정해주어야 합니다. 단순한듯 복잡한 HTTP 헤더의 세계이기에 어떤 값을 어떻게 써야하는지 헷갈릴때가 많은데요 이럴때 도움이 될만한 의사결정차트(?)가 있어서 공유해 봅니다. 

출처 : 구글 개발자 문서 (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)

no-cache 와 no-store 가 항상 헷갈렸었는데요 no-cache 의 경우 Etag 등이 추가적으로 제공되어야 하며 이를 통해 컨텐츠를 "항상" revalidate 하는 작업이 필요하다는 이야기가 있습니다. 다소 복잡하다면 캐시하면 안되는 컨텐츠는 no-store 를 쓰도록 하는 것이 마음이 편할 것 같습니다 ^^ 캐시할 컨텐츠는 Cache-Contro: max-age=xxx 를 사용하되 private, public 중 어떤 추가 디렉티브를 쓸 것인지도 고민해봐야 겠습니다! Etag 는 이 모든 걸 떠나서 가능하면 넣어주는게 CDN, Proxy 를 대비하는 방법이 되겠습니다!

• # 구글 개발자 문서 : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

- NoPD -

윈도 환경에서는 그렇게 많이 사용되지 않지만 맥이나 리눅스 등의 환경에서는 컬(curl) 명령이 무척 자주 사용됩니다. curl 명령을 이용해서 간단한 HTTP 요청을 쉽게 만들고 요청(Request), 응답(Response) 헤더는 물론이고 전달되는 데이터까지 쉽게 살펴볼 수 있기 때문입니다. 하지만 curl 명령을 이용해서 큰 사이즈의 JSON 응답을 내려주는 API 를 조회하는 경우 그 내용을 살펴보기가 다소 쉽지 않다는 단점이 있습니다. 때문에 JSON Formatter 나 유사한 기능을 제공하는 편집기로 본문을 가공하여 확인해야만 했습니다. 

오늘 소개해드리는 커맨드라인 툴인 jq 는 이런 불편을 제거해주기 위한 훌륭한 도구가 될 것 같습니다. Github 에 소스코드가 공개되어 있는 jq 는 awk 나 grep 처럼 파이프(Pipe)를 이용하여 응답 컨텐츠에 포함된 JSON 형태의 데이터를 전달, 가공하여 리턴해주는 역할을 하게 됩니다. 이를 통해 번거롭게 JSON 형태의 데이터를 재가공할 필요 없이 터미널 상에서 curl 명령을 약간 바꾸는 것만으로 쉽게 JSON 을 확인할 수 있게 됩니다. 백문이 불여일견이니 한번 사용예를 보도록 하겠습니다. 

시험용 서버가 준비되지 않아 쉽게 쓸 수 있는 블로그스팟의 피드를 JSON 형태로 받아보기로 하겠습니다. 개인의 블로그에 영향을 주지 않도록 구글블로그의 공식 채널을 이용해봤습니다. 복사해서 붙여넣기 쉽도록 위의 명령을 다시 적어드리면 curl -v "https://googleblog.blogspot.kr/feeds/posts/default?alt=json" | head -n 10 이 되겠습니다. 캡쳐에서는 빠졌습니다만 less 도 연결해 주시는 것이 정신 건강에 좋습니다. jq 를 이용하지 않았기 때문에 원본 서버가 전달해주는 컨텐츠를 그대로 표현하게 되겠죠?

네, 상당히 사람 프랜들리하지 않은 결과가 나왔습니다. 180k 바이트가 넘는 컨텐츠이기 때문에 한줄로 연결된 데이터를 보는 것은 사실상 불가능하고 외부 JSON Pretty Formatter 를 이용하거나 편집기를 이용해서 보기 좋게 바꿔야 합니다. 하지만 매번 그렇게 하는 것도 참 번거로울 거라는 생각이 딱 들죠? 이럴때 유용한 커맨드라인 툴이 바로 jq 입니다. 이제 파이프를 이용하여 jq 로 응답 결과를 전달해서 간편하게 데이터를 가공해 보도록 하겠습니다. 

여기서도 친절하게 명령을 다시 적어드려 보겠습니다. curl -v "https://googleblog.blogspot.kr/feeds/posts/default?alt=json" | jq '.' | head -n 10 이 바로 명령입니다. 앞선 명령과의 차이는 파이프로 연결된 jq '.' 가 추가된 정도입니다. 하지만 결과는 정말 아릅답게 출력이 된 모습을 볼 수 있습니다. curl 명령을 이용해서 디버깅을 하거나 테스트를 수행하는 경우에 정말 간편하게 응답을 해석할 수 있게 된 것입니다. jq 는 다양한 운영체제용으로 준비되어 있어 공식 웹사이트나 github 에서 필요한 환경에 맞는 소스코드/실행파일을 다운로드 받으실 수 있습니다. 

커맨드라인 JSON Pretty Formatter - jq 공식 웹사이트 방문하기 [바로가기]

2016/01/13 - 마이크로소프트 윈도10, 학생용 버전 10% 할인 프로모션

2015/12/24 - Node v4.2.4 (LTS) 버전이 새로 업데이트 되었습니다

2015/11/19 - 비주얼 스튜디오 코드(Visual Studio Code), 깃허브를 통해 오픈소스로 공개!

2015/10/26 - 마이크로소프트, 닷넷 코어(.NET Core) 및 ASP.NET 5 취약점 포상 프로그램 실시

2015/10/02 - 마이크로소프트 애져(Azure), 아카마이(Akamai)를 통한 CDN 서비스 제공 발표

2015/09/21 - TinyPNG 를 이용하여 PNG/JPG 이미지를 동적으로 가공하기