Hash List 모듈 사용 방법
hlist.JS(Hash List) 적용 소스
1. 동작 원리
가장 먼저, 작성된 모듈의 기본이 되는 기능에 대해 설명하자면, 기존 URI의 #(해시) 기능인 앵커(anchor)를 응용한 기능이며, 보편적으로 아래와 같은 경우에 사용된다.
1.1 앵커 태그의 href 속성에 "#here" 문자열을 할당 시킨다.
1.2. 특정 태그(div)의 id 속성에 위 앵커 태그에 할당한 문자열을 동일하게 할당 시킨다.
1.3. 이와 같은 문서 환경이 구성되어 있는 경우, 해당 앵커의 기본 이벤트 발생 시 동일한 문자열로 할당된 특정 태그를 찾아 그 위치로 이동 시키는 기능을 사용할 수 있으며, 보통 사이트 가이드 문서의 목차 내용을 이동 시키는데 사용된다.
해당 기능은 아래 코드와 같이 구현된다.
<div id="here">there 영역!!</div>
<a href="#here">there 영역으로 가기!!!</a>
작성된 모듈(Hlist.js) 또한 데모 페이지에서 확인할 수 있듯이 위에서 설명한 #(해시) 기능을 응용한 방법이다.
- 제공되는 URI 형식이 아래와 같이 작성되는 이유는 기존 시멘틱한 URI 작성 방식을 최대한 손실시키지 않기 위함이다.
제공되는 URI 작성법:
http://mohwa.org/aspx/hlist/hlist.aspx?#list/page/5
: #(해시)list(proc)/page/5(parameters)
2. 적용에 따른 장 / 단점
장점:
1. 페이지에 포함된 전체 리소스(정적 / 동적) 갱신없이(no reflash) 특정 영역의 데이터를 받아와 업데이트 하는 방식(+ajax)으로, 그에 따라 성능(네트웍 트래픽 감소, no reflash에 따른 페이지 로드 시간 감소 등..) 및 사용자 접근성이 향상 된다.
2. 방식 변경 후에도 사이트 기본 기능(북마크, 링크 공유, 검색엔진 인덱싱, 페이지 히스토리)은 그대로 사용 가능하다.
즉 #(해시) 기능을 사용하는 가장 큰 이유는 전통적인 웹 사이트의 레가시(유산)를 깨뜨리지 않으려는 최소한의 절충한이라고 볼 수 있다.(HTML5 API의 pushState(Ajax History 관리) 기능은 아직까지 모든 브라우저에서 지원하지 않으므로(최신 표준 브라우저에서만 사용 가능) 기술 도입에 적당하지 않다.)
3. Cache 기능으로 정의된 CacheTimeout 안에는 DB Call을 하지않고 미리 적재된 캐쉬 데이터를 불러와 사용게 된다.
단점:
1. 전체적으로 JS 기반인 기술이므로 JS 미 지원 브라우저에서는 동작하지 않는다.
즉 그와 관련한 사용자 접근성에 치명적인 단점이 존재한다.
하지만 이를 대응하기 위한 방법이 존재하지 않는것은 아니다. 단, 개발 초입 시 이를 충분히 고려한 설계를 통해 미 지원 브라우저를 처리해야하며, 그에 따라 늘어나는 개발 비용은 충분히 고려해야할 부분이다.(기존 Form 태그의 Submit을 JS(form.submit())만을 이용한 설계(JS 미지원 브라우저에서는 동작하지 않는 설계)가 아닌 Submit(type="submit", type="image") 타입의 버튼 형식 및 Form 태그의 Onsubmit 이벤트를 통해 사용하는 방법을 떠올리면 이해가 빠를 듯 하다.)
또 다른 분기 처리 방법으로는 사이트 이원화를 생각해 볼 수 있다.
즉 JS 지원 여부에 따라 순수 HTML만으로도 동작하는 사이트로 리디렉션 해주는 방법이다.
2. JS 기반인 기술이므로 코드 상 작은 실수(JSON에서 콤마(,)를 찍지않는 작은 실수)로 인해 전체 웹 사이트가 망가질 리스크가 적지 않다.
3. 각종 "검색엔진"이 해당 사이트의 내용을 알기 위해 컨텐츠를 긁어가는 봇인 "크롤러"는 JS를 실행시키지 않으므로 #(해시) 기능으로 생성되는 사이트의 컨텐츠를 가져갈 수 없다.(비동기(ajax)를 사용한 컨텐츠 업데이트를 사용할 수 없기 때문)
즉 크롤러가 수집하는 페이지는 내용 없는 빈 페이지라는 얘기이다.
3. 적용 예제
4. 관련 사이트:
메뉴얼:
http://mohwa.org/doc/hlist/index.html
소스 페이지:
http://mohwa.org/aspx/hlist/hlist.js
데모 페이지(루리웹 페이지를 이용한 예제이며, 현재 페이징 기능 까지 구현되어 있다.)
http://mohwa.org/aspx/hlist/hlist.aspx?#list
URI(텀즈):
http://www.terms.co.kr/URI.htm
URL과 URI의 의미와 차이점:
OctoberSkyJs 1차 스터디 후기
OctoberSkyJs 1차 스터디 후기
올해 들어 나름 야심 차게 시작하고 전부터 큰 관심만 가졌던 Node.JS 스터디 모임인 "OctoberSkyJs 1차 스터디 후기"를 간단히 제 블로그를 통해 남겨봅니다.
오늘은 개인적인 사정으로 인해 당일 발표 중 첫 번째, 두 번째 발표인 "Buffer"와 "C/C++ Addons"는 아쉽게도 들을 수 없었지만(특히 C/C++ Addons는 꼭 듣고 싶었던 발표이기에 더 큰 아쉬움이 남습니다.;;),
차후 "Groups Mail"을 통해 공개될 "발표 자료"를 기대해 봅니다. plz
그럼 후기의 본론인 스터디 얘기를 하자면, 오늘 제가 들은 발표는 총 2개의 발표였으며, 그 중 세 번째 주제였던 @백정상님의 "Cluster"와 당일 발표자분의 부재로 인해 그 자리를 대신 메꿔 주셨던(소위 땜빵 발표?) @채수원님의 "libuv"에 대한 얘기였습니다.
특히 세 번째 발표인 "Cluster"란 주제는 스터디 예습을 전혀 하지 못한 제겐 시작부터 큰 "멘붕"을 느끼게 했고, 기반 지식(OS, 하드웨어, 엔진(V8)) 또한 그리 깊지 않아 발표 내내 최대한 이해하기 위해 노력했던 시간이었던 거 같습니다.(다행히도 다른 분들의 여러 질문이 이해하는 데 도움이 많이 되었답니다.ㅋㅋ)
스터디 내용 중 생각나는 내용에 대한 주제를 간단히 적어보자면 Cluster란?, 적용 시 성능 향상은?(약 20 ~ 40%?), Child-Process 와의 관계? 등의 이야기였고 물론 100% 이해하기 힘들고 제겐 어려운 내용이었지만 성능 향상에 대한 새로운 부분을 알게 되어 아주 유익한 시간이었습니다.
또한 "땜방 발표"를 해주셨던 @채수원님의 "Libuv" 또한 Clouster의 내용과 같이 기반 지식이 부족한 현재로선 100% 이해하기 힘든 내용이었지만 역시 의미 있는 시간이었습니다.
그리고 발표하셨던 내용 중 어느 "한 부분"이 제겐 인상 깊게 남아 아랫글로 옮겨 봅니다.
"Node.JS는 JVM과는 달리 OS와 Machine 간에 최적화 레이어가 존재하지 않는다.(뒤에 따라오는 말은 그에 대한 성능과 관련된 말씀이셨는데 정확히 생각나지 않고 이해 또한 잘 되지 않아 이 글에 옮겨 적지 않겠습니다.(괜찮으시다면 댓글로 직접 남겨 주셔도 좋을 듯합니다.^^;;))
그럼 후기의 끝으로 앞으로 남은 "스터디" 현재 모든 맴버들과 같이 잘 마무리 할 수 있기를 빌며...
1차 후기를 마칩니다.!!
Wire Shake를 통해 본 Keep-Alive 처리 과정
Wire Shake를 통해 본 Keep-Alive 처리 과정
1. HTTP 기본 구조(HTTP 1.0 이하)
- 파란 테두리: 첫 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
- 빨간 테두리: 두 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며, 다시 생성 되는 구조이다.
웹 서버 상세 처리 과정:
2. Keep-Alive(HTTP 1.1 이상) 기능 이란?
위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.
즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout 시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)
- IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)
3. IIS(6 / 7) Keep-Alive 설정 방법
- IIS 6:
1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의
- 연결 시간 제한은 기본 120초를 갖는다.
- IIS 7:
1. Keep-Alive 활성화 설정
2. Keep-Alive Timeout 정의
- 연결 시간 제한은 기본 120초를 갖는다.
4. 웹 서버 HTTP Connection 변화
- Keep-Alive 비활성화 시:
1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)
2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.
- Keep-Alive 활성화 시:
1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)
- 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초) 시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)
2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)
5. Wire Shake를 통해 본 Keep-Alive 처리 과정
- 파란 테두리: 첫 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
- 빨간 테두리: 두 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)
- Keep-Alive 처리 과정
1. HTTP Session(논리적 연결) 생성
2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결에 Request하게 된다.
즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.
3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.
4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.
5. HTTP Session Close
- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.
- Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정
- 파란 테두리: 첫 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
- 빨간 테두리: 두 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)
- 주황 테두리: Socket(TCP) 연결 및 HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시 첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)
TCP 세션 수립 과정
http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD
HTTP 1.1 Keep-Alive 기능에 대해
