jk25dddddddd

[jk25d]

retry. exponential backoff. circuit breaker

1. 심플한 리트라이 방법. 일정 시간마다 retry. 문제점. 트래픽이 몰려 리퀘스트가 실패한 경우 서버에 더 부담을 주게됨. 2. exponential backoff. 실패할때 마다 대기시간을 늘림. 최대 n초까지 늘리고 더이상 늘리지 않음. 일정 횟수 이상 실패시 시도하지 않음. 문제점. 네트워크 문제등으로 연결 실패가 길어질시 횟수제한에 도달할 수 있음 3. circuit breaker. exponential backoff로 일정이상 실패시 차단기(circuit breaker) 가동. 가동중일때 오는 리퀘스트는 무조건 fail. 일정이상 대기후 반가동 상태로. 반가동 상태일땐 리퀘스트를 흘려보내고 성공여부에 따라 차단기를 가동할지 말지 결정 https://dzone.com/articles/understanding-retry-pattern-with-exponential-back

[jk25d]

etag, last-modified

서버에서 컨텐츠 보낼때 hash값(etag) or 최종수정시간(last-modified) 헤더를 브라우저로 전송함.

브라우저는 담에 리소스 요청시 if-none-match or if-modified-since 를 보내고, 서버에서는 이걸보고 304(not modified)를 보낼지 변경된 컨텐츠를 보낼지 판단함.

[jk25d]

C10k. Socket limits. Elb. Websocket. Proxy Elb를 이용해 websocket을 쓸 경우 서버의 메모리 사용량은? 클라에서 http로 핸드쉐이킹. 일시적 퍼머넌트 연결 to elb. Elb와 서버는 커넥션 맺음. 웹소켓 연결 맺어짐. 아까 맺은 커넥션으로 elb와 웹소켓 통신. Elb와 서버도 아까 맺은걸로. 사용자가 늘어나면 elb로 커넥션 늘어남. 최대 포트당 64k개 커넥션. Elb에서는 아까 맺은 커넥션으로 128개 리퀘스트 가능. 파이프라인 지원안함 백엔드랑. 리퀘스트가 많을 경우 서버와의 커넥션(소켓) 늘림. Elb안쓸경우. 접속자수(idle포함) * 커넥션당 메모리 총메모리. 동접자 / 128 * 커넥션당 메모리

[jk25d]

Security tips for digital nomads

1. 가방은 발 밑에.. 테이블 아래.. (의자위에 놓는건 안전하지 않음)

2. 도둑이 훔쳐서 금방 못 빠져 나가도록 안쪽자리.. 다른 의자와 테이블로 장애물이 많은 자리 앉기

3. 노트북은 항상 몸에 지닌다. 화장실 갈떄도.. 그동안 자리는 책같은 걸로 잠시 맡아둠..

4. 구려 보이는 노트북 쓰기.. 맥북 말고.. 맥북 쓸꺼면 커버 씌우기(자기는 bookbook꺼 선호..) (bookbook이 이쁘긴 한데.. 무게가 상당해서 전 이걸로 구매https://www.incipio.com/fathers-day/macbook-air-11in-feather-ultralight-hard-shell-case.html)

5. 옆사람이 말걸거나 그러면 가방 조심하기..

http://www.pcworld.com/article/2054467/security-tips-for-digital-nomads.html

[jk25d]

mixin, traits and swift

First off we have the interface. This is a protocol that just has method signatures but no actual code. This is what Objective-C and Swift 1.2 have.

A trait also has the actual method bodies. In other words, a trait adds code to an interface. This is the new thing that Swift 2.0 lets us do today with protocol extensions.

A mixin is like a trait but it also has state. We can’t really do this yet with Swift 2.0 as you’re not allowed to add stored properties to protocols.

[jk25d]

Single Page Application 인증

- OAuth2, JWT대한 설명은 생략

- SPA는 토큰 방식으로 stateful하게 만듬. cookie(http_only)를 쓰면 js단에서 사용자의 정보를 알 수 없기 때문. 토큰은 JWT라는 standard가 있고..

- JWT토큰같은 경우는 자체에 정보(사용자, 권한, expires등)를 갖고 있기 때문에 백엔드에서 따로 정보를 갖고 있지 않아도 됨.. sns나 mobile에서는 expire를 길게 가져가길 바라는데.. 그렇게 되면 revoke(토큰 폐지)이슈가 발생함. 고로 long lived refresh token이나 long lived access token을 사용.

- long lived refresh token은 access token이 (일반적으로 20-30분 이내) 만료가 되면 refresh token으로 access token을 재 발급 받는 방식. 하지만 이미 발행된 access token은 자체 만료되기 전까지 폐지할 방법이 없음(window time). 그리고 refresh token정보는 역시 db(or cache) 에 저장해야 함

- long lived access token은 로직이 간단하고 window time이 없느나 모든 token을 db에 저장해야 함. 그래야 폐지가 되니.. github나 foursqure등에서 쓰임.

- 어쨌든 백엔드 어딘가에(db든 cache든) 토큰 정보를 갖고 있어야 함

- 다음으론 localStorage에 저장할 건지 cookie에 저장할건지의 문제

- 토큰을 localStorage같은데 저장을하면 xss에 취약함. 

- cookie에 저장을하면 csrf문제와 front에서 사용자 정보를 알 수가 없는 문제(http_only인 cookie를 js가 볼 수 없기 때문)가 발생함

- front에서 사용자 정보를 알기 위해 별도의 url을 통해 정보를 가져와야 함

- csrf를 쓰려면 session을 써야 함. 그럼 또 session을 저장하기 위한 백엔드의 db(cache)가 필요함.  csrf토큰은 cookie(no http_only)를 통해 전송하고 js에서 읽어서 헤더(ajax)나 request parameter(form submit)로 server로 보내는 방식 추천.

- 어쨌든 저장소는 cookie 추천. localStorage xss는 취약점은 어찌할 수가 없어서..

이건 미 검증.. csrf를 위한 session 공간을 따로 두지말고.. token저장시 value로 저장하는 건?.. token을 db에 저장하게 되면 구지 JWT를 쓸 필요가 있나.. 그냥 session id처럼 crypto safe한 값을 써도 되지 않나..

계속 업뎃 될 수 있음..

https://stormpath.com/blog/token-auth-spa/

https://stormpath.com/blog/jwt-the-right-way/

http://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens/12885823#12885823

https://github.com/expressjs/session/blob/master/index.js

https://github.com/crypto-utils/uid-safe/blob/master/index.js

https://github.com/jshttp/cookie/blob/master/index.js

https://github.com/tj/node-cookie-signature/blob/master/index.js

[jk25d]

무릇 보통 사람은 자기보다 열 배 부자에 대해서는 욕을 하고, 백 배가 되면 무서워하고, 천 배가 되면 그 사람 일을 해주고 만 배가 되면 그 사람 노예가 된다. 이것이 사물의 이치다.

- 사기. 권129. 화식열전

[jk25d]

node.js minimal UUID

maximum9 characters long UUID

# support untill Fri, 11 Mar 2270 09:08:00 GMT # support by 1024 workers # support 2048 ops / sec # generate 9 characters long UUID

https://gist.github.com/joonilkim/d8acd4c621c1f3f17cea

[jk25d]

facebook token expiry policy

https://developers.facebook.com/docs/facebook-login/access-tokens

[jk25d]

node.js hash function benchmark

tested on my macbook air early 2015, 1.6ghz i5

{ name: 'md5', 'ops/sec': '168,639' } { name: 'sha1', 'ops/sec': '169,629' } { name: 'sha256', 'ops/sec': '168,328' } { name: 'sha512', 'ops/sec': '171,289' } { name: 'murmurhash', 'ops/sec': '1,920,171' } { name: 'murmurhash-js', 'ops/sec': '2,150,003' } { name: 'murmurhash-native', 'ops/sec': '1,055,845' } { name: 'crc', 'ops/sec': '266,177' } { name: 'buffer-crc32', 'ops/sec': '203,341' }

https://gist.github.com/anonymous/1a6ce61076f419bad093

[jk25d]

rate limits

## twitter (api) rate limit charts

https://dev.twitter.com/rest/public/rate-limits

# fb rate limits

http://stackoverflow.com/questions/8713241/whats-the-facebooks-graph-api-call-limit

# g+ rate limits

https://developers.google.com/adwords/api/docs/guides/rate-limits

## express.js rate limiter

https://github.com/ovx/strict-rate-limiter

https://github.com/AdamPflug/express-brute

[jk25d]

https와 인증의 이해

성능때메 대칭키로 암호화해야 하는데 대칭키를 그냥 주고받을 수 없으니까(보안땜시) 서버가 발행해준 공개키로 대칭키 주고 받는거고.. (여기선 클라가 먼저 대칭키를 유추할 수있는 premaster secret을 서버로 보내줌(공개키로 encrypt해서).. 서버는 private key로 premaster secret알아내고.. 이것저것 조합해서 대칭키 알아냄)

근데 비대칭키 보내주기 전에 나한테 공개키를 보내 준 서버가 제대로 된 서버인지 알아야 함. (중요) (중간에 다른 누가 실서버 공개키는 가로채고 가짜 공개키를 보내줄 수도 있기 때문). 고로 서버가 공개키와 함꼐 보내준 인증서(root certificate)가 root CA에서 발행한건지 체크함.. 보통은 root CA에서 직접 발행해주지 않고 중간 발행자를 통함으로 그 중간 발행자가 root CA 위임인지 확인하기 위해 intermediate certificate를 또 사용함.. 두 cerificate다 서버에서 browser로 보냄..

만약 ssl을 사용하지 않고.. 직접 클라와 서버가 저 짓(공개키보내고 대칭키 encrypt해서 다시 보내는..)을 하면 문제가 없나.. 문제가 됨. 위에 언급했듯이 누군가 중간에서 실제 서버인척하는게 가능함.. 실 서버의 공개키는 가로채고 새로 공개키를 발급해서 클라한테 줌.. 클라가 공개키로 encrypt 한 대칭키를 건네주면 중간녀석은 비밀키(아까 공개키와 함께 생성한..)로 대칭키를 알아 낼 수 있음.. 그리고 실 서버한테 다시 가로챈 공개키로 대칭키를 encrypt해서 보내줌..

결국 브라우저가 신뢰할 수 있는 서버인지 체크하는게 중요.. ssl 안쓰면 보안 의미없음..

https://support.microsoft.com/en-us/kb/257591

http://security.stackexchange.com/questions/7421/how-do-the-processes-for-digital-certificates-signatures-and-ssl-work

http://security.stackexchange.com/questions/63971/how-is-the-premaster-secret-used-in-tls-generated

https://www.wormly.com/help/ssl-tests/intermediate-cert-chain

[jk25d]

css 아키텍쳐 고민

디자인이 자주 변경되다 보니 그에 맞는 css 스타일링에 대해 고민하게 됨. 여러 스레드를 보고 나에게 맞는 방식만 추려봄

- 기본은 utility class(하나의 class가 하나의 속성만 가짐) 조합으로 스타일링

- specific한 element는 inline styling 쓸것임. (pollute the markup rather than the style sheet.)

- naming은 BEM이나 SMACSS보단 (--나 __가 싫음) trello와 유사하게 (.component-descendant.mod-modifier)

- 최대한 vanilla css 유지. preprocessor는 변수, mixin(only for vendor prefixed stuff), import, data-uri정도만 쓸것임

- css 구분은 SMACSS 따르지 않고.. trello와 유사하게(component, modifiers(m-), state(is-), javascript(js-), mixin(mx-), utilities(noprefix))

- file structure (reset, variables(color, font, media-queries), utilities, components)

- camelcase나 underscore쓰지않고 왠만하면 짧게.. (padding: 5px 0;, color: #eee;)

- utilities class naming은 변경 잘 안되게.. (.border2px 대신  .border-sm)

- css inheritance대신 modifier사용(.m-).. modifier는 단독으로 정의하지 않음

- css selecting performance(rules are read from right to left) 고려한 가이드임. 그렇다고 너무 descendent selector 피할 필욘 없음.. 최악의 경우에도 50ms 차이

http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects

http://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/

https://gist.github.com/bobbygrace/9e961e8982f42eb91b80

https://github.com/davidtheclark/scalable-css-reading-list/blob/master/README.md

[jk25d]

[jk25d]

hash ring 구현 분석

hash ring 구현 분석..

하게된 이유: modular 연산으로 분산할 경우 node추가나 삭제시 문제가 되기 때문에 어떻게 구현되어 있나 볼라고

1. md5를 이용해서 16바이트를 만들고 4바이트씩 끊어서 그게 vnode가 담당할 key의 범위로 정함(vnode point라고 칭함)  (node당 vnode가 160개라고 치면, 40개의 md5를 만들고, md5의 4바이트씩 이용해서 40*4개의 vnode를 만듬)

2. 위에서 얻은 vnode point를 바탕으로 sort해서 ring을 완성 (node마다 vnode point값이 뒤죽박죽이기 때문에, ring에서 node들의 실제위치도 뒤죽박죽이됨)

3. node들의 ring에서 위치가 뒤죽박죽이기 때문에, 특정 노드가 추가되거나 삭제되어도 하나의 노드에 부하가 몰릴 가능성이 줄어듦

4. 실제 data를 넣을 경우, data의 md5해시를 만들고 하위4바이트를 이용해 어느 node에 들어갈지 결정(빠른 탐색을 위해 bisection 알고리즘 사용)

* node가 추가되거나 삭제되어도 기존 data가 들어갈 node는 거의 고정.. 해당 node의 범위의 data만 rehashing 필요.. 

* node들의 위치를 뒤죽박죽으로 만듬으로써 node 추가나 삭제시에도 소수 node에 data가 몰리지 않도록 함..

http://amix.dk/blog/post/19369

http://amix.dk/blog/viewEntry/19367

https://pypi.python.org/pypi/hash_ring/

https://github.com/3rd-Eden/node-hashring/blob/master/index.js

https://github.com/bnoguchi/node-hash-ring/blob/master/src/hash_ring.cc

[jk25d]

redis가 해시 알고리즘을 djb2에서 murmurhash2로 바꾼 이유

bucket명을 prefix:id로 보통 사용하는데.. id만 바뀔 경우 djb2에서는 인접한 숫자가 나오기 때문에.. locality가 생김..

성능은 djb2가 더 나음..

https://github.com/antirez/redis/commit/da920e75d4836897b9a7109b6d4743e201cd8a4f

http://stackoverflow.com/questions/9625246/what-are-the-underlying-data-structures-used-for-redis

[jk25d]

non-crypto hashing 알고리즘 선택

string을 골고루 잘 퍼지게 숫자로 바꿔주는 해싱 알고리즘이 필요해서 좀 살펴 봄..

중요한 건 성능이랑 collision

djb2, murmur2, superHash, crc32 정도가 대상..

아래 벤치마크를 보면 crc32가 collision이 가장 적으나 속도가 3배정도 느리고.. 대체적으로 이것저것 봤을 떄 murmur2(특히 32bit 머신에선 승자)가 성능이나 collision 면에선 괜찮아 보임.

murmur2랑 murmur3 비교한거 보면 murmur3가 속도나 collision면에서 조금더 나음..

i7 이상이면 sse4 instruction이용한 crc32 고려해볼 수 있음

http://programmers.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

http://blog.reverberate.org/2012/01/state-of-hash-functions-2012.html

https://github.com/JohnLangford/vowpal_wabbit/wiki/murmur2-vs-murmur3

https://github.com/Voxer/sse4_crc32

http://www.drdobbs.com/parallel/fast-parallelized-crc-computation-using/229401411