기본 배경.

크롬의 목표

  • 속도 : 빠른 브라우저
  • 보안
  • 안정성 : 웹 앱 플랫폼
  • 단순함 : 복잡한 기술을 단순한 사용자 경험속에 녹이기.

크롬이 사용한 기술

  • 멀티 프로세스 모델 : 프로세스 및 메모리 격리. 각 탭당 보안 샌드박스 모델 제공.
  • 웹 프로그램 싱행의 주요 단계 : 리소스 가져오기, 페이지 레이아웃 및 렌더링, 자바스크립트 실행.
  • V8 : 오픈소스, 빠른 자바스크립트 엔진. node.js의 기본 엔진이기도 함.
  • Blink : 오픈소스, 빠른 표준 호환 레이아웃 엔진.
  • 학습 : 사용자 이용 패턴 수집, 분석을 통한 빠른 사용자 경험 제공.

모던 웹 앱

  • HTTP archive 프로젝트에 수집된 30만개의 문서를 분석
  • 한 페이지를 표시하는데 1280KB, 88개의 리소스, 15개 이상의 개별 호스트 연결이 필요.

사용자 입장에서 '충분히 빠름'이란?

  • 0 100ms : 바로 반응
  • 100 300 ms : 약간 인식되는 느림.
  • 300 1000ms : 기계가 동작하는 구나 인식.
  • 1s+ : 정신세계의 컨텍스트 전환
  • 10s+ : 나중에 해야지

네트워크 입장에서 리소스 요청의 수명

  1. Redirect, App Cache : 이미 가져온 리소스중에서 적절한 캐시관련 헤더(Expireds, Cache-Control 등)가 설정되어 있었다면 로컬 사본을 이용.
  2. DNS 질의
    • 크롬은 {스킴, 호스트, 포트}에 따라 재 사용되는 소켓 풀을 관리.
    • 프록시가 설정되어 있거나, 프록시 자동설정 스크립트(PAC)가 설정되어 있는지 확인. 설정되어 있다면 프록시에 대한 소켓 풀 관리. PAC는 URL에 따라 다른 프록시 설정이 가능.
    • DNS 질의는 인기있는 호스트거나 가까이있는 호스트 도메인일 경우 응답이 빠름.
  3. TCP 연결
    • 3-웨이 핸드쉐이킹 : 순차적으로 SYN/SYN_ACK/ACK가 이루어지다 보니 시간이 많이 소요.(full round-trip time).
    • HTTPS 요청일 경우 SSL핸드쉐이킹이 발생. 이는 추가로 2번의 라운드트립 지연이 발생할 수 있음. 다만 SSL세션이 캐시되어 있을 경우 한번의 라운드트립 시간에 연결 가능.
  4. HTTP 요청
    • HTTP 요청을 보내는데 필요한 시간 + 서버가 응답을 처리하는데 소요되는 시간 + 서버가 보낸 응답을 받는 시간.

미국 광대역통신망에서의 간 단계별 소요시간

  • DNS : 50 ms
  • TCP 핸드쉐이킹 : 80ms (1RTT)
  • SSL 핸드쉐이킹 : 160ms (2 RTT)
  • HTTP 요청 전송 : 40ms
  • 서버 처리 시간 : 100ms
  • 서버 응답 전송 : 40ms
  • 하나의 리소스 요청에 대해 470ms 소요. 그중 80%이상의 시간이 네트워크 연결에 소요된 시간.
  • 악조건 : 초기 TCP 윈도우 크기(4~15KB)가 서버 응답을 보내는데 적절치 않을 경우 한두번 더 RTT지연이 발생. SSL 연결의 경우 인증서를 못가져오거나 온라인 인증서 상태 확인(OCSP; Online Certificate Status Check)를 진행할 경우 수백에서 수천 밀리초의 지연이 추가 발생




원문 : http://aosabook.org/en/posa/high-performance-networking-in-chrome.html

Posted by NeoZest


Neozest입니다.

개발자에게 많은 지적 자극을 주는 부분은 바로 다른 사람의 코드를 읽는 순간이 아닐까 생각됩니다. 그 사람이 자신보다 실력이 뛰어나다면 가슴에서 우러러 나오는 존경심 + 더 공부해야겠다는 열정이 나올 것이고, 그 사람이 못하다면 자신이 배운 지식을 동원해서 다시 한번 정리할 수 있는 기회가 됩니다.

어제는 구글이 만든 오픈소스 브라우저인 크롬이 베타를 떼고 정식버전으로 출시되었습니다. (먼저 구글 크롬팀에 축하를...)
브라우저는 아주 많은 모듈들로 이루어져 있기 때문에 쉽게 전체적인 코드를 한눈에 보기는
불편하죠. 사실 웹킷코드를 리뷰한 적이 있는 저로써는 웹킷이외에 뭐가 사용되었을까가 더 궁금하기도 했죠. 그래서 구글 크롬에 사용된 third-party library들과 그들의 역할이 뭔지를 살펴보도록 하지요.(이미 구글과 같은 큰 조직에서 충분히 안정성이나 견고성을 검증했기 때문에 이런 모듈은 국내에서도 목적에 맞다면 사용해 보는 것도 좋겠죠.)


1. Google BreakPad (http://code.google.com/p/google-breakpad/)
프로그램을 개발하다보면 어쩔 수 없이 crash가 발생하게 됩니다. 그런데 이 crash에 대한 정보를 최대한 수집하여 분석할 수 있다면 해당 crash가 발생한 정황을 알 수 있겠죠. 마치 윈도우의 Dr.watson처럼 말이죠. 구글에서 만든 BreakPad는 멀티플랫폼에서 동작하는 crash report 시스템입니다. 이 글을 적고 있는 현재 Revision이 304이군요.

2. Google URL (http://code.google.com/p/google-url/)
크롬이 브라우저인 관계로 URL을 다룰 일이 많죠. 그 부분을 처리하는 작은 모듈입니다. 그런데 개인적으로는 이런 모듈이 이미 많은 언어에 foundation library에 포함되는 추세이기 때문에 코드 읽기 차원에서 볼 수는 있겠지만, 유용성은 떨어지지 않나 생각되네요.

3. ICU38(http://www.icu-project.org/)
유니코드는 이제는 익숙한 용어가 되었습니다. VC 최신 버전에서는 프로젝트를 생성할 때 기본으로 유니코드 기반으로 만들어지지요. 그렇지만 아직까지도 유닉스나 기존 레거시코드들에서 유니코드를 사용하기 위해서는 코드 페이지 변환등의 작업을 담당할 라이브러리가 필요하지요. 이 역할을 맡고 있는 것이 IBM에서 만든 ICU38입니다. (코드 변환 이외에도 정규표현식이나 형식화(formatting) 등의 작업을 제공하는군요.)


흠. 겨우 3개를 봤을 뿐인데...시간이 많이 걸리는군요.
나머지는 계속해서 다음 포스트에 정리해 보겠습니다.
Posted by NeoZest