대세는 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 노피디

최근 멀티 폼팩터 디바이스들이 사용자들에 의해 사용되면서 웹 사이트 개발, 서비스 하는 분들의 고민이 참 많습니다. 웹 사이트는 결국 사용자 브라우저 입장에서는 HTML 과 CSS 그리고 여러가지의 Resource File 로 구성된 집합체입니다. 웹 사이트를 제대로 최적화하기 위해서는 내 서비스가 가지고 있는 약점이 무엇이고 어떻게 개선할 수 있을지를 찾아내는 것이 중요하다 하겠습니다.


슬라이드 쉐어에서 발견한 자바까페(JavaCafe) 김흥래 님이 정리해서 올려주신 슬라이드 자료는 (13회 자바 개발자 컨퍼런스에서 사용된 자료인 것 같습니다) 그동안 본 자료들 중에서도 가장 쉽고 임팩트 있게 설명해주신 자료라 생각되어 공유해 봅니다. 슬라이드만 공유되어 있어서 실제 세션 발표하시면서 해주셨을 이야기가 없다는게 조금 아쉬운 부분이네요! 웹 관련 개발 업무를 하시는 분들은 필독하시고 사이사이에 간략히 설명된 내용들을 찾고 공부하실 필요가 있습니다! 


개인적인 친분은 없지만 자료 공유해주신 김흥래님께 감사인사를 드립니다 ^^


저작자 표시 비영리
신고
Posted by 노피디
node.js 의 다양한 라우팅 모듈들 중 가장 사랑받고 있는 모듈이 express 가 아닐까 싶습니다. 사용법이 간단하지만 상당히 훌륭한 기능을 제공하고 있기 때문에 애용하는 분들이 줄어들지 않는 것 같습니다. 새로 간단한 웹 페이지를 구성할 일이 생겨서 간만에 express 를 다시 만지다 보니 버전이 올라가면서 바뀐 부분도 있고 헷갈리는 부분도 있어서 기록삼아 남겨둡니다.

$ npm install express

 
express 를 이용하기 위해서는 우선 node.js 가 설치되어 있어야 하고 npm 을 통해서 express 를 설치해야 합니다. 레파지토리를 통해 express 의 설치가 완료되면 간단한 코드를 이용하여 정적인 메세지를 출력해 봄으로써 설치가 잘 되었는지, 기본적인 사용법이 어떻게 되는지 확인해 볼 수 있습니다

var express = require('express');
var server = express();

server.get('/', function(req, res, next) {

res.send('hello express');

}); 

server.listen(1234, function() {

console.log('Server running at http://127.0.0.1:1234/');

}); 

 
보통 express 를 쓰는 예제들을 보면 app 이라는 약어를 많이 씁니다만 결국 서버니까 습관적으로 server 라고 지정했습니다. server.get 메소드를 이용하여 루트 ('/') 접근에 대해 hello express 라는 응답을 리턴하는 코드입니다. server.get 대신 server.use 를 사용해도 결과는 동일합니다.

$ node test.js
Server running at http://127.0.0.1:1234/ 


node 를 이용하여 저장한 파일을 실행하고 브라우저로 localhsot:1234 를 접근하면 정상적으로 hello express 메세지가 노출됩니다.

 
저작자 표시
신고
Posted by 노피디
자바스크립트는 참 편리한 스크립트 언어이지만 다른 한편으로는 이해하기 힘든 녀석이기도 합니다. 이유인 즉선 너무 유연하게 사용할 수 있다보니 가끔 일반적인 언어, 컴퓨터 상식으로는 "왜 이렇게 동작하지?" 하는 경우들이 있기 때문입니다. 가장 대표적인 것이 조건 비교문을 이용하여 변수나 객체를 비교할때 입니다. 잘 동작할 것으로 생각했던 구문들이 정상적인 동작을 하지 않거나 예상치 못한 반응을 한다면 혹시 아래 표에 나온 경우중 하나가 아닌지 잘 살펴봐야 합니다. 아래 표는 http://dorey.github.io/JavaScript-Equality-Table/ 에서 업어왔습니다

 
Boolean 값인 True 와 1은 같은 값일까요? 그리고 True 와 "1"은 같은 값일까요? 조금 더 나아가 True 와 [1] 을 비교하면 어떻게 될까요? 두개의 이퀄 연산자(==)를 사용하여 자바스크립트에서 값을 비교하는 경우 위의 표에서 초록색으로 표시된 것처럼 결과가 리턴된다고 합니다. "" 와 0 이 같다는 생각을 해보셨나요? 혹은 "" 와 [[]] 가 같은 값으로 식별된다는 상상을 누가 해봤을까요? 

때문에 자바스크립트에서는 각 객체와 객체를 비교했을 때 값을 정확하게 예측하기 힘들다면 이퀄 연산자를 두개 이어쓰는 대신 세개(===)를 쓰는 것이 좋습니다. 세개의 이퀄 연산자를 사용하는 경우 엄격한 규칙에 의거하여 값을 비교하게 되고 이로 인한 조건 비교문의 오동작을 효과적으로 막을 수 있습니다. 세개의 연산자에 대한 부정형은 !== 이니 참고하시면 될 것 같습니다


훨씬 상식(?)에 가까운 결과를 보실 수 있습니다. 같은 형태의 자료형들간에 비교를 했을때 정확한 값이 나오는 것을 볼 수 있습니다. 자바스크립트를 쓰면서 뭔가 이해할 수 없는 동작이 발생하고 있다면 표를 참고하시고 연산자를 바꿔보는 것을 검토해 보세요. 우리의 시간은 소중하니까요. :-)

 

저작자 표시
신고
Posted by 노피디
웹 사이트 혹은 웹 서비스를 글로벌 사용자들을 대상으로 제공하고자 할 때 가장 걸리는 것이 바로 속도문제입니다. 내 서버가 어디에 위치하고 있느냐에 따라 엔드유저가 접근하는 시간이 달라질 수 밖에 없기 때문입니다. 아마존과 같은 클라우드 인프라 서비스는 세계 여러곳에 지역(Region) 센터를 두고 있어 이런 문제점을 어느정도 해결할 수 있게 해주고 돈을 조금 들인다면 아카마이와 같은 CDN 서비스를 통해 손쉽게 웹 트레픽의 속도를 보장할 수 있습니다.

그렇지만 개인 개발자라던가 아직 서비스에 대한 클라우드 인프라 투자, CDN 전송망의 사용이 힘든 상황이라면 얘기가 조금 다릅니다. 이런 경우라면 최대한 웹 사이트를 최적화하여 HTTP 세션이 맺어지는 불가피한 오버헤드를 제외한 나머지 웹 컨텐츠, 오브젝트에 대해서는 최대한 최적화를 하는 것이 필요합니다. 그런데 최적화를 하려면 현재 상태를 알아야 합니다. 도대체 미국, 프랑스, 영국, 호주 등 외국에서 내 웹사이트에 접근했을 때 속도는 어떻게 측정해야 할까요?

 
해외로도 발이 아주 넓어 각지에 친구가 있는 경우라면 웹 사이트 접속해보면서 시간을 재달라고 하면 되겠지만 현실적으로 그러기는 너무 힘이들죠. 이런 노고를 위해 착한 사람들이 만든 착한 웹 사이트, 웹페이지 테스트(http://www.webpagetest.org)를 이용하면 어렵지 않게 세계 각지에서의 속도 측정을 할 수 있습니다.

여러가지 심도있는 테스트는 Advanced Settings 를 통해서 할 수 있습니다만 간단하게 URL 을 입력하고 테스트 지역을 선택하는 것 만으로도 기본적인 데이터를 모두 뽑아볼 수 있습니다. 브라우저 User-Agent 값을 변경시켜 가면서 웹 사이트를 테스트 할 수 있는 기능도 제공되기 때문에 여러가지로 유용한 서비스라 하겠습니다. 어차피 HTTP Request / Response 로 분석을 해주는 서비스이기 때문에 우리가 흔히 아는 웹 사이트를 가지고 속도 테스트를 해봐도 상관 없습니다.  트위터를 가지고 한번 해보니 아래와 같은 결과가 나오네요. 지역은 브라질 상파울로를 선택하고 브라우저는 크롬을 가지고 테스트 요청을 했습니다.


상세 화면으로 들어가면 파이어버그나 크롬 웹 개발자 도구를 이용하는 것과 같은 뷰를 볼 수 있습니다. 상세한 내용은 직접 보시면서 확인하면 될 것 같구요, 처음 테스트 결과가 나오는 화면에서 두번의 테스트를 하는 이유를... 혹시 아시나요? 아신다면 그대는 웹 사이트 튜닝 세계로 들어올 준비가 된 것입니다 ^^ 정답은 댓글로 물어보시면 답변해 드리는 것으로...

웹 페이지 성능 측정 서비스, WebpageTest 방문하기 [바로가기


- NoPD - 
저작자 표시
신고
Posted by 노피디
이미 아시는 분들은 패스하셔도 되는 포스팅입니다. ^^ OAuth 라고 들어보신 분들 많으시죠? 하지만 관련한 도큐멘테이션을 하나씩 읽으려고 하다 보면 몇 장 못넘기고 포기하신 분들도 꽤 많을 것 같습니다. 트위터 서드파티 라이브러리를 검색하다가 많은 라이브러리들이 LinkedIn 의 에반젤리스트가 작성한 OAuth 에 대한 가이드를 올려둔 슬라이드 쉐어를 많이 공유하고 있더군요. 그래서 가볍게 업어 왔습니다 ^^ 한번 읽으면 잘 이해 안되는 부분도 많겠지만 두번, 세번 읽으면 감이 좀 오실지도 모르겠습니다! (사실 저도 감잡고 있다는 ㅋ)


어떠신가요? 그래도 간단하게 설명된 축에 속하는 문서라고 생각됩니다. 실제로 OAuth 인증을 받는 코드를 만들어 가시면서 보다 세세한 부분들을 보게 되시겠지만 큰 흐름을 먼저 잡는 용도로 안성 맞춤입니다. 뒷부분 슬라이드는 LinkedIn 의 API 에 대한 것들이니 앞서 얻은 Key 과 String 들을 어떻게 쓰는지를 중심으로 보시면 됩니다.


OAuth 의 흐름도는 위와 같습니다. 트위터에서 업어온 그림인데 조금 작습니다 ^^; 크게 3가지 단계로 나뉜 인증 과정을 숙지하고 어떤 Key 가 어떤 상황에서 사용하는지를 중심으로 한번 보시면 되겠습니다. 위의 슬라이드 쉐어에서 이야기한 내용들을 이 흐름도에 한 번 매핑해 보시면 좋을 것 같습니다.


- NoPD -
신고
Posted by 노피디
윈도우 폰 7 의 출시가 세달 정도 앞으로 다가왔습니다. 수많은 사람들이 새로운 세상을 꿈꾸며 윈도우 폰 7 을 기다리고 있을 것 같습니다. 이미 알려진 것처럼 윈도우 폰 7 에서는 C# 와 Silver Light 이 핵심 기술로 자리잡고 있습니다. 기존의 윈도우 모바일로 개발된 많은 UI / UX 들은 재활용되기 힘든 상황이지만 비지니스 로직이 C# 으로 되어 있다면 그나마 조금 나을 것 같습니다.

윈도우 폰 7 어플리케이션 개발을 위해 우리가 공부해야 할 것들이 참 많아 보입니다. 월간 마이크로소프트紙에도 6월부터 8월까지 세달에 걸쳐 윈도우 폰 7 개발 기초 강좌가 진행중이니 이걸 먼저 참조하면 좋을 것 같구요, 그 외 Silver Light 4 자체에 대한 학습을 위해 개론성격의 강의를 MS 의 김영욱 Evangelist 께서 만든 동영상이 있어 공유합니다. Techdays 2010 에서 공개된 영상이고 Silver Light 플러그인이 설치되어 있으면 바로 감상이 가능합니다 :-)



- NoPD -
신고
Posted by 노피디
간만에 MS 쪽 기술 Follow-Up 을 다시 시작했습니다. 그동안 회사 업무니 뭐니 바빴다가 이제 정신 좀 차리면서 따라 잡을거 따라잡고 하는 중이네요. 아직도 머릿속엔 alloc / init 이 가득차 있지만 이제는 멀티 트랙으로 움직여야 할 시기가 된 것 같네요 :-)

올해 초에 온라인으로 개최한 한국 마이크로소프트의 개발자 컨퍼런스 동영상 중 몇가지를 좀 공유할까 합니다. MSDN 에 있는 링크 영상이 너무 사이즈가 작아서... 조금만 더 키워 보고자 하는 것이 첫번째 이유지만 여튼... 좋은 것은 나눠야 배가 되니까요 :-)



- NoPD -
신고
Posted by 노피디
어쩌다보니 요즘 HTML 5 에 본의 아닌 관심을 가지고 있습니다. 시류는 앱(App)의 시대라 앱에 비중을 두는게 맞으나 결국 중기적으로 웹(Web)이 다시 중심을 가져갈 수 밖에 없는 시황(?)이라 적절히 밸런스를 유지해야 할 것 같습니다 ㅎ.

  1. HTML 5 공식 스펙문서 : http://dev.w3.org/html5/webdatabase/
  2. Safari 에서 Web SQL 사용 : http://tinyurl.com/2c2dkcb
  3. 1번의 간략/핵심 버전 : http://openbit.co.uk/?p=135

핵심은 구글 Gears 나 뭐 모종의 로컬 DB 엔진을 쓰지 않고도 HTML 5 의 기본 스펙을 이용해서 로컬 저장공간을 만들 수 있되, 얘들이 다들 잘 알고 있는 SQL 문으로 핸들링 가능하다는 것이 핵심일 것 같네요. 점점 안정적이지 못한 브라우저는 퇴출될 수 밖에 없는 구조로 가는군요!

- NoPD -

신고
Posted by 노피디

티스토리 툴바