Cloud & Dev. Story2016.08.03 16:43

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


# TCP Fast Open - TCP 의 3 way handshake 로 발생하는 RTT 및 Latency 의 한계를 극복하려는 노력 / Handshake 할때부터 컨텐츠를 담아 전달해 보자는 것이 요지.



출처 : 구글 기술문서 (아래의 링크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 -

저작자 표시 비영리
신고
Posted by 노피디

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


WWDC 2016 에서 애플은 ATS 에 대한 정책 강화를 통해, 앱의 인터넷 구간 통신 프로토콜로 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 - 서버간의 통신이 이슈가 될 상황이 훨씬 적을거라는 추정이 가능합니다.



저작자 표시 비영리
신고
Posted by 노피디

웹 서버의 응답은 브라우저나 프록시, 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 -

저작자 표시 비영리
신고
Posted by 노피디
Development2016.02.22 15:59

윈도 환경에서는 그렇게 많이 사용되지 않지만 맥이나 리눅스 등의 환경에서는 컬(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 공식 웹사이트 방문하기 [바로가기]



저작자 표시 비영리
신고
Posted by 노피디
Development2013.12.26 15:23
웹의 세상이 되면서 웹 개발자들이 각광받는 시대입니다. 서버사이드 개발을 하던 프론트엔드 개발을 하던 웹 개발은 이제 어느 회사에서도 없어서는 안되는 중요한 역할을 해내고 있습니다. 그런데 웹을 그냥 하는 것과 웹을 잘 하는 것은 분명 차이가 있을 것 같습니다. 고작 10년여의 경력인지라 모르는 것들이 정말 많고 계속 변하는 웹 관련 기술에 혀를 내두를 지경이지만 결국 기본이 탄탄하다면 두려울(?)것이 없다는 생각을 늘 하고 있습니다.

웹을 이해하기 위해서는 웹을 소화하는 주요 주체인 브라우저에 대해서 잘 이해할 필요가 있습니다. 내가 만든 자바스크립트가 브라우저에게 어떤 영향을 줄 것인지? 내가 만든 서버사이드 스크립트 메서드 한개가 사용자에게 어떤 경험을 주게 될지를 고민하는 것이 필요하다는 이야기입니다. 브라우저가 행하는 기본적인 동작을 이해하는 것에서 웹 튜닝이나 웹 가속에 대한 논의가 시작될 수 있을 것 같습니다.

사진 출처 : www.internetretailer.com


웹은 서버가 내려주는 HTML 을 읽고 사용자에게 표현하는 역할을 합니다. 브라우저는 HTML 의 여러가지 구성요소를 어떻게 해석하고 받아들이고 이해한 내용을 표현하는 것일까요? 렌더링 단계(화면에 컨텐츠를 보여주는 단계) 이전에 일어나는 일들과 하지 않아야 하는 것들을 간략하게 설명한 동영상이 있어서 소개해 봅니다. 브라우저의 동작을 이해하기 위해서 TCP 도 잘 알아야 하지만 일단은 그렇구나~ 하고 넘어가면 좋을 것 같습니다!


- NoPD -


 
저작자 표시
신고
Posted by 노피디
HTTP 2.02013.12.10 15:54
팀 버너스리경이 인터넷에 엑세스 하는 방법의 하나로 월드 와이드 웹(World Wide Web)을 주창한 이래 웹은 이제 인터넷의 핵심이 되었습니다. 일상에서 일어나는 정말 많은 네트워크 연결은 인터넷을 통해서 일어나고 있습니다. 트위터에서 새로운 소식을 듣고 페이스북에 친구들과 사진을 공유하는 것 뿐만 아니라 부모님과 영상통화를 하고 동영상으로 인기있는 TV 프로그램을 보는 것도 모두 인터넷을 통해 이루어지고 있습니다.

그런데, 이런 인터넷의 폭발적인 사용을 뒷받침 해주고 있는 HTTP 프로토콜(Hyper Text Transfer Protocol)은 그다지 효과적인 프로토콜이 아닙니다. HTTP 의 첫 버전이었던 HTTP/1.0 은 단순히 서버와 사용자간에 하나의 연결만을 맺어주는 수준이었고 단일 서버에서 복수의 가상 웹 사이트를 운영할 수 있는 기능도 없었습니다. 이러한 단점을 개선한 HTTP/1.1 은 동시에 여러개의 연결을 맺을 수 있고 가상 호스트에 대한 지원이 가능해졌지만 너무 단순하게 만들어진 나머지 효율적인 웹 트랜잭션의 처리를 위해서는 추가적인 많은 작업들을 해주어야 했습니다

출처 : The Telegraph (http://goo.gl/gVQw3)



시간이 흘러 바야흐로 21세기로 접어들면서 인터넷은 이제 단순히 컴퓨터를 위한 기술이 아니라 수많은 스마트 기기들과 사물들까지 연결하는 하이퍼커넥티드(Hyper Connected) 세상을 만들어 가고 있습니다. 사물인터넷(IoT, Internet of Things)이라는 용어는 그런 네트웍의 복잡성과 연결된 기기의 수를 이야기 해주고 있고 빅 데이터(Big Data)는 이런 네트웍을 통해서 발생되고 있는 데이터의 규모를 발해주는 대표적인 단어들입니다

우리가 웹을 통해 요청을 하나 만들때 마다(HTTP Request) 전력이 소모되고 있다는 사실을 인지해 본 적이 있나요? 불필요한 트랜잭션 처리를 위해서 서버와 클라이언트의 브라우저 혹은 스마트 기기에서 동작하는 앱이 전기 혹은 베터리를 소모하고 있다는 생각을 해본적 있나요? 더 많은 기기들(스마트폰, 패드, 컴퓨터, 센서 등)이 더 많은 방법으로(브라우저, 스크립트, 앱 등) 인터넷에 연결되고 있는 작금의 트래픽 폭발을 효율적으로 조정하고 더 빠른 사용자 속도를 제공하는 것에 대한 고민에서 HTTP/2.0 은 출발했습니다.

구글이 추진하고 있는 SPDY 와 이를 근간으로 마이크로소프트가 SPDY 혹은 Web Socket 기반으로 준비중인 Microsoft S+M 은 HTTP/2.0 의 기본 골격이 되어 결국 최종적으로 만들어질 표준에 전체 혹은 일부가 녹아들어갈 것입니다. 이들의 노력으로 만들어지고 있는 HTTP/2.0 은 앞으로 우리의 인터넷, 웹웹을 어떻게 바꿔 나갈까요? IETF 에서 공개한 프로토콜 Draft (http://tools.ietf.org/html/draft-ietf-httpbis-http2-04) 를 바탕으로 어떤것들이 바뀌고 어떤 변화가 생길 것인지를 하나씩 알아보도록 하겠습니다.

- NoPD -
저작자 표시
신고
Posted by 노피디

티스토리 툴바