Merge pull request #5 from goohooh/master

web-pattern

Author: goohooh

08_웹_패턴/goohooh.md

@@ -0,0 +1,145 @@
+# 웹 패턴
+
+## 자바스크립트 전송
+
+### 파일 결합
+브라우저의 컨텐츠 전송
+
+#### DNS 쿼리
+1. URL 입력 -> 이벤트 발생
+2. 운영체제에 웹사이트 이름을 IP 주소로 알려줄 것을 요청
+3. 윈도우 / 리눅스 / 맥에선 표준 C 라이브러리 함수인 `gethostbynam` 호출
+4. 로컬 DNS 캐시를 확인 하여 매핑된 주소가 있는지 탐색
+5. 있다면 캐시 정보를 사용하고 없다면 DNS 서버에 이를 요청
+6. 일반적으로 DNS 서버는 ISP(Internet Service Provider)업체에 의해 제공
+7. 해당 서버에 기록이 존재할 때 까지 DNS 서버 체인을 따라 전파
+8. 루트 서버까지 도달하여 찾지 못한다면 조회는 실패
+
+#### 연결 및 요청
+1. 브라우저가 사이트 주소를 알면 연결을 만들고 컨텐츠 요청
+2. 문서 혹은 문자 전송. 보안 연결일 경우 이 시점에 SSL/TLS 협상 수행
+3. 서버가 HTML을 전송하고, 여기서 외부 자원을 발견하면 다시 서버와 연결하여 자원 요청
+
+여기서 `파일 결합`의 이유가 필요해진다. 전송이 오버헤드를 줄여야 한다.
+
+네임 스페이스를 통해 결합에 문제를 피할 수 있다.
+
+다만 이때 트레이드 오프가 필요하다
+
+- 사용자가 페이지를 돌아다닐 경우
+    - 파일 결합으로 캐시를 사용하여 재사용성 증대
+- 사용자가 페이지 일부분만 방문할 경우
+    - 파일을 결합할 경우 필요없는 스크립트까지 받게 됨
+
+> 이를 해결하기 위해 두 방법 사이의 스윗 스팟을 찾아야하는데 이를 위해 이동 통계가 필요하다.
+
+### 축소
+1. 태스크 러너/번들러 사용
+2. 서버에서 컨텐츠 스트림을 압축할 때 `gzip`(무손실 압축) [관련 링크](http://www.playnexacro.com/index.html#show:article)
+
+### 콘텐츠 전송 네트워크(CDN)
+오직 정적 콘텐츠 제공을 목적으로 하는 호스트 분산 네트워크
+
+## 플러그인 & 제이쿼리 & d3
+[추천 도서](http://www.yes24.com/24/goods/11371306)
+
+## 멀티 스레드
+UI 환경에서 싱글 스레드는 흔히 사용된다. 레이스 컨디션을 피하기도 좋다.
+
+하지만 웹 앱의 규모가 커지면서 복잡도는 증가했고 이에때라 복잡한 연산을 백그라운드에서 
+
+실행해야할 필요성이 높아졌다. 이에 대응한 것이 `Web Workers` 출현이다.
+
+모던 브라우져에서 사용 가능하며 메시지를 통해 메인 스레드와 통신한다.
+
+```js
+// 워커 파일 내부(worker.js)
+self.addEventListener('message', e => {
+    var data = e.data;
+    // startCalcualtion 메시지를 받으면
+    if (data.cmd === 'startCalculation') {
+        self.postMessage({event: 'caculationStarted'});
+        // fib의 새로운 인스턴스를 시작
+        var result = fib(data.parameters.nummber);
+        self.postMessage({
+            event: 'calculationComplete',
+            result: result
+        });
+    }    
+}, false);
+
+// 메인 스레드
+// 외부 파일에서 웹워커를 로드하고
+worker = new Worker('worker.js');
+// 리스너를 추가한다.
+worker.addEventListener('message', message => {
+    logEvent(message.data.event);
+    if (message.data.event === 'calculationComplete') {
+        writeResult(message.data.result);
+    }
+    if (message.data.event === 'calculationStarted') {
+        document.getElementById('result').innerHTML = 'working';
+    }
+});
+
+// 계산을 위한 명령
+worker.postMessage({
+    cmd: 'startCaculation',
+    parameters: {number: 40}
+});
+```
+백그라운드 실행 동안 메인 스레드는 다른 작업을 할 수 있고,
+
+웹 워커로 부터 메시지가 수신되면 기존 이벤트 루프로 처리한다.
+
+Node.js에서 자식 프로세스를 포크 하는 형식으로 비슷한 인터페이스를 제공한다.
+
+하지만 프로세스를 포크하는 만큼 비용이 많이 든다.
+
+## 서킷 브레이커 패턴
+
+대형 시스템은 많은 중복으로 이루어져 있다. 이러한 중복은 컴포넌트의 실패 시
+
+백업을 제공하는 수단이 될 수 있다.
+
+> 앱이 외부 데이터 소스에 5초마다 쿼리를 보낸다고 가정하자.
+
+이러한 폴링이 실패하면, 대부분 실패를 무시하고 계속 폴링한다.
+
+일부의 경우 실패시 즉시 재요청을 하기도 하는데, 이는 바쁜 스케쥴링에서
+
+문제가 될 수 있다.
+
+서버측에서는 수많은 클라이언트에게 5초마다 응답해야 한다. 
+
+서킷 브레이커 패턴은 실패가 일정 횟수에 도달하면 통신 시도를 차단 한다.
+
+물론 어느 시점에서는 서킷 브레이커를 리셋하여 서비스가 복구되도록 해야한다.
+
+## 백 오프
+
+서킷 브레이커의 변형으로 통신을 차단하는 대신 요청에 딜레이를 준다.
+
+폴링 간격이 5초 였다면, 고장 검출 시 간격을 10초로 변경한다.
+
+이 과정을 반복하여 간격을 늘리고, 다시 정상 작동 한다면 다시 간격을 줄여간다.
+
+## 성능 저하 애플리케이션 동작
+
+실시간 주식 시세를 서비스하는 경우
+
+시스템에 문제가 생기면, 비실시간으로 서비스를 제공할 수 있다.
+
+모던 브라우저가 제공하는 저장 공간을 사용하는 것이다.
+
+앱이 서버로 데이터를 전송할 때도 유용하다.
+
+데이터 업데이트를 로컬에 저장하고 서비스가 가능해질 때 한꺼번에 보낼 수도 있다.
+
+(사용자가 페이지를 떠나면 백그라운드 작업은 종료된다.)
+
+> 이런 방식을 사용할 경우 사용자에게 데이터가 최신이 아님을 경고해 줘야 한다.
+
+## 프로미스
+
+냉무