웹킷 어디까지 왔나?
(GPU 가속 feature를 중심으로...)


웹킷 뉴스 그룹에서의 주요 안건들 요약
* HTML5 Microdata 지원 공지 (2011/9/22 : New feature announcement - Implement HTML5 Microdata in WebKit)
* HTML5 WebWorker 관련 기능 구현 논의 (2011/9/23 : starting implementation of postMessage tranferables)
* HTML5 Canvas 관련 기능 구현 논의 (2011/9/13 : Mouse Lock API)
* HTML5 time element 관련 기능 구현 논의 (2011/9/16 : Implementing HTML5 time element)
==> 요약: 현재 WebKit 진영에서는 CSS3와 HTML5에 관한 구현 논의가 주요 이슈임


GPU 가속 관련 현황 요약
* GPU는 CPU와 달리 데이터 병렬성이 풍부해 대용량 데이터 처리에 효율적임
* HTML5 Video를 이용 브라우저에서 HD 영상을 표시하기 위해서는 GPU 가속 기능 활용이 필수적임
* WebKit은 화면 처리를 위해 software rendering path와 hardware accelerated path를 제공함
* GPU 가속 feature는 WebKit 차원에서는 종료된 문제임; GPU 가속 기능 제공 여부는 브라우저 port의 문제임
* 애플의 사파리 브라우저는 오래전부터 hardware accelerated path를 심도 깊게 활용함; GPU 가속 기능 제공함
* 애플의 모바일 사파리 브라우저도 아이폰을 처음 출시할 때부터 GPU 가속 기능을 제공함
* 구글의 크롬 브라우저는 2010년 9월 (크롬7) 부터 GPU 가속 기능을 제공하기 시작함
* 구글의 폰용 안드로이드 브라우저는 아직 GPU 가속 기능을 제공하지 않음 (2011/10/19 현재)
* 구글의 패드용 안드로이드는 (안드로이드 3.0 허니콤은) GPU 가속 기능을 제공하나 아직 최적화 되지 않음; 간혹 화면이 깨지는 문제, 성능 문제 등이 보임 (2011/10/19 현재)
* 구글이 곧 발표할 아이스크림 샌드위치는 스마트 폰에서도 GPU 가속 기능을 제공하리라 전망함. 하지만 아직(2011/10/19)까지 구글의 명시적인 발표는 없음; 오늘(2011/10/21) 아이스크림 샌드위치 발표함. GPU 가속 지원 현황에 대해 좀 더 조사가 필요함 (젠장...)
==> 이제 Android 4.0을 (아이스크림 샌드위치를) 사용하는 모든 단말은 GPU 가속 기능을 제공해야 한다. 이로 인해 모든 안드로이드 App (웹 브라우저도 포함하겠지?..)은 GPU 가속 기능의 혜택을 누릴 수 있게 됐다. (2011.10.24. 내용 추가함. GPU 가속 기능이 OS 차원에서 지원된다는 얘기)
http://developer.android.com/sdk/android-4.0-highlights.html#DeveloperApis
(
Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.)
 
 

Reference
* 브라우저에서 그래픽 가속하기 (from WebKit mailing-group)
Accelerated 2D Tesselation Implementation (from WebKit mailing-group)
Chromium "GPU" LayoutTests (from WebKit mailing-group)
GPU Accelerated Compositing in Chrome (from Chrome 개발자 사이트)
Google Activates Chrome GPU Acceleration
Guess who is WebKit’s new best friend
Issue 6914: Make android use the GPU (if available) for UI and browsing (안드로이드 이슈 페이지)
 
(이상)
 
저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요

  1. 박군 2012.01.10 17:25 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 webkit에 대해서 정보를 찾아보다 오게 됬습니다.
    상당한 양과 질의 정보에 많은 도움이 되어 감사하게 생각합니다.
    제가 완전 새내기 초보 수준이라 좀 이해가 안되는 부분이 있어 질문을 댓글로 남기려 하는데요
    제가 가지고 있는 보드에 webkit을 올리려고 하는데
    단순한 url을 가지고 view만 해주면 되는거라 궂이 webkit을 빌드 해서 라이브러리를 만들 필요 없이
    webkit core에 있는 소스만 가져와서 쓰려고 하는데 이것이 가능할지 궁금합니다?
    그리고 툴킷 포팅은 제가 가지고 있는 보드에서 쓰는 플랫폼에 맞춰서 수정하려고 하는데
    이 경우 win이나 gtk가 아니라서 cairo 자체를 수정 할수 있을까요?
    부족한 질문이라 애매하게 생각되실지 모르겠지만 조금이나마 조언을 구하 고자 합니다.

    • ingee 2012.01.11 13:01 신고  댓글주소  수정/삭제

      작업하시는 보드가 Android 보드라면 Android 커널에 WebKit 모듈이 있으니까 따로 WebKit을 빌드하거나 포팅할 필요가 없습니다.
      하지만 어째 말씀하시는 뉘앙스가 그런거 없는 (OS가 안드로이드가 아닌, OS에 WebKit이 포함되어 있지 않은) 보드 같은데... WebKit 소스를 있는 그대로 가져다가 실행되도록 하는 맞춰주는 과정이 포팅입니다. 그런 포팅 작업을 하자면 win, gtk, cairo 등을 선택해서 수정하는 작업이 필요합니다.
      행운이 함께 하기를 빕니다. :)

  2. 파바밧™ 2012.03.06 15:29 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 반갑습니다~ 지금 webkit 을 공부하고 있는데 아주 많은 도움이 되고 있어 정말 고맙습니다~
    다름이 아니라 webkit 에서 플러그인을 만들려고 하는데요 TestNetscapePlugin 예제로 디버깅을 하려는데 전혀 안되고 있어요 ㅠ.ㅠ

    혹시 플러그인과 관련해서 조언 좀 구할수 있을까요?

    • ingee 2012.03.06 22:51 신고  댓글주소  수정/삭제

      웹킷 플러그인은 해본 적이 없는 일이라 조언 드리기 어렵습니다. 그래도 도움되기를 바라며, 다른 브라우저의 플러그인 작업 경험을 바탕으로 일반적인 차원에서 몇마디 보탭니다.

      1. 우선 페이지 안에서의 플러그인 동작을 위해 NPAPI (맞나?? 넷스케이프가 정의한 플러그인 API) 함수들을 구현해야 합니다.

      2. 그리고 플러그인의 설치/검색/생성을 위해 브라우저가 정의한 함수들을 구현해야 합니다. 이건 브라우저마다 다른 부분입니다. 사파리 브라우저, 크롬 브라우저, 안드로이드 내장 브라우저가 제각각 정하는 규격이 있을 겁니다.

      쫌이라도 도움되면 기쁘겠습니다. 작업 결과물 나오면 여기에 폼나게 자랑 한번 해주세요.

  3. laconicblue 2012.04.16 11:27 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    webkit 에 대한 자세한 정보들 감사드립니다.
    저는 스위치 같은 임베디드 시스템만 만들다가, 터치 스크린을 장착한 장비를 처음으로 만지면서 webkit 을 사용하게 되었습니다.
    directfb + gtk + webkit (without X11) 을 잘 컴파일하고 GtkLancher 로 각 사이트가 열리는 것까지 확인했습니다.
    그런데 Gtklancher 내에서 click 으로 다음 사이트에 넘어 갈수록
    ps aux 나 /proc/(pid)/status 상에 나타나는 memory 사용량이 계속 늘어나 100 메가 이상이 되어 버리면서
    memory 부족으로 GtkLancher 가 죽어 버리는 일이 발생하는 군요..=-=

    html 에서 그림 파일을 로딩하게 하고 click 하면 다음 그림을 보여주는 방식으로 단순한 테스트 였습니다.
    그림은 10장 정도 이지만 20번 가까이 클릭하면 계속 증가하는 군요..

    Webkit 의 tool 로 제공되는 GtkLauncher 는 간단한 browser 로 사용이 불가능한 것인가요?
    저는 기본 사이트를 open 하고 그 사이트 내에서 click 으로 기능을 보여주는 것이 목표입니다.. ^^

    GtkLauncher 의 이런 메모리 사용에 대해 조언을 구할 수 있을까요?

    • ingee 2012.04.16 11:40 신고  댓글주소  수정/삭제

      메모리를 할당만하고 해지 못하는 것 같습니다. WebKit소스가 매크로로 정의하고 있는 memory free 함수가 실제 free 함수로 정의되어 있는지 확인하면 좋을 것 같습니다.
      실제 키워드를 일러주면 좋을텐데 웹킷 소스를 보고 있지 않은지라 그러지 못합니다. 이해해주세요.

    • laconicblue 2012.04.16 14:29 신고  댓글주소  수정/삭제

      감사합니다.

      답변이 너무 빨라서 놀랬습니다.. ^^

      이래저래 웹서핑에 의존하다가 차근히 보기 시작했습니다.

      일단, 증가하는 사이즈가 8M 정도씩되면서
      주로 이미지 테스트시에 보인 것으로 봐서
      DocLoader 에서 ResourceHandle 쪽을 따라(?) 가면서 사용되는 free 함수를 보도록 하겠습니다...

    • ingee 2012.04.16 15:10 신고  댓글주소  수정/삭제

      요즘 한가해서... 긁적... ㅠㅠ
      캐시 관리하는 쪽도 같이 보시면 좋을 것 같습니다. 메모리가 모자라면 캐시를 지우는 정책이 있을텐데 그게 잘 동작하지 않는 것 같습니다.
      좋은 결과 기원합니다.
      문제가 해결되면 어떻게 해결했다라는 코멘트 부탁드립니다. 여러 사람 살리실거에요.

HTML5 일정 현황 및 계획
lynda.com Tutorial | HTML5 First Look—HTML5 timeline (
http://www.youtube.com/watch?v=tJurCyWJW9k) 에서 발췌

  • 2004: WHATWG 발족, "Web Application and Compound Documents" 워크샵
  • 2005: Web Application 1.0 초안 (Working Draft) 발표
  • 2007: W3C가 WHATWG의 작업내용을 수용, HTML5 초안 (Working Draft)을 발표함
  • 2009: HTML5 초안 (Working Draft)에 대한 Last Call 시작됨
  • 2012: HTML5 스펙을 Candidate 상태로 레벨 업 (예정)
  • 2022: HTML5 스펙을 Recommendation(최종안) 상태로 레벨 업 (예정)
  • 그리고...
  • 2009: HTML5 에 대한 대중의 관심이 급격히 커짐
  • 2010: 초안 (Working Draft)에 대한 Last Call 과정이 진행중
     * 초안의 일부 항목들은 무척 성숙한 단계에 있음
     * 점점 더 많은 기기와 브라우저들이 HTML5의 일부 항목들을 지원하고 있음
     * 따라서 HTML5의 일부 기술은 2022년 최종 스펙 발표까지 기다릴 필요 없이 지금 당장(!) 사용할 수 있음

W3C 산하 HTML5 표준화 워킹그룹과 표준화 기술 분야
2011년, W3C HTML5 표준화 동향 및 전망 (
http://www.wonsuk73.com/category/HTML5%20%ED%91%9C%EC%A4%80%20%EA%B8%B0%EC%88%A0) 에서 발췌

WG 

표준개발 범위

개발 표준 현황

HTML WG

HTML5 마크업 관련 표준 개발

-   HTML5

-   HTML+RDFa

-   HTML Microdata

-   HTML Canvas 2D Context

Web Application WG

웹 애플리케이션 개발에 필요한 웹소켓, 웹워커, IndexedDB, FileAPI 등을 포함하여 HTML5와 관련된 주요 API 표준 개발

-   Web Sockets API

-   Web Storage

-   Web Workers

-   Indexed Database API

-   Server-Sent Events

-   Cross-Origin Resource Sharing (CORS)

-   HTML5 Web Messaging

-   Clipboard Operations

-   File API

-   File API: Directories and System

-   File API: Writer

-   Programmable HTTP Caching and Serving

Device APIs and Policy WG

데스크탑, 랩탑, 모바일 인터넷 단말(MID), 핸드폰 등 다양한 기기의 웹 브라우저에서 일정, 업무, 연락처, 카메라, 메시지, 시스템 정보, 이벤트 등의 다양한 단말 기능을 사용할 수 있도록 하는 API 표준

-   Contacts API

-   The Calendar API

-   The Media Capture API

-   The Messaging API

-   The System Information API

Geolocation WG

Geolocation API를 포함하여 가속센서, 방향센서 등 센서에 관련된 표준 개발

-   Geolocation API

-   DeviceOrientation Event

Web Notification WG

사용자에게 알려주기 위해 필요한 Notification과 관련된 API 표준으로, Notification과 관련하여 사용자 인터액션(Interaction) 관리에 필요한 이벤트에 대한 표준도 포함

-   Web Notifications

Web Performance WG

웹 브라우저의 특징들과 API들에 대한 애플리케이션 성능 측정에 대한 표준 개발

-   Navigation Timing

Web Event WG

모든 디바이스의 멀티터치,-테블릿 입력 등의 사용을 가능하게 하는 방법에 대한  표준 개발

-   Web Events

Web Real-Time Communications WG

웹 브라우저에서 P2P(Peer to Peer) 오디오, 비디오 등 실시간 통신을 위한 클라이언트 API 표준 개발

-   WG Charter 검토 중



(끝)

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG HTML5

댓글을 달아 주세요

SSL/TLS는 안전한(보안이 적용된) TCP/IP socket 채널을 제공해주는 기술이다. 브라우저 빅뱅 초기에 정립된 기술이고, OpenSSL이라는 확실한 오픈소스 프로젝트가 존재하는 잘 정립된 기술이다. OpenSSL은 SSL/TLS의 종결자라 할 수 있는 소스 더미인데, 막상 가져다 쓰려면 참고할만한 문서가 막연하다. 일 때문에 이리저리 헤매다 좋은 문서를 발견하여 여기 요약한다. 다음 내용은 내게 필요했던 일부만 발췌한 것이다. 원본 페이지에는 샘플 코드를 비롯, 더 자세한 설명이 담겨있다. 아쉬운 개발자들은 주저 없이 방문 바란다.

이제 보안 연결을 설정하는데 필요한 것을 알아보자. 달라진 유일한 부분은 연결 설정 및 연결을 만드는 것이다. 다른 모든 것은 똑같다.
보안 연결은 연결이 구축된 후에 핸드쉐이크(handshake)를 필요로 한다. 헨드쉐이크 동안, 서버는 인증을 클라이언트에 보내는데, 클라이언트는 트러스트 인증에 준하여 이를 확인한다. 또한, 인증을 검사하여 만기가 되었는지를 확인한다. 인증이 신뢰를 받는 것인지를 확인하려면 트러스트 인증 스토어가 연결을 구축하기 전에 로딩되어야 한다.
클라이언트는 서버가 인증을 요청할 경우에만 서버로 인증을 보낸다. 이것은 클라이언트 인증으로 알려져 있다. 인증을 사용하여, 암호 매개변수들이 클라이언트와 서버 사이에 전달되어 보안 연결을 구축한다. 핸드쉐이크가 연결이 구축된 후에 수행되더라도, 클라이언트나 서버는 어떤 지점에서라도 새로운 핸드쉐이크를 요청할 수 있다.
핸드쉐이크와 보안 연결을 설정하는 다른 측면들은 Netscape 기술자료와 RFC 2246에 설명되어 있다.

이 글은 핸드쉐이크 하는 사이에 서버의 디지털 인증서를 처리하는 것에 초점을 맞추므로 핸드쉐이크가 어떻게 작동하는지를 상세히 살펴보고자 한다. 여러분이 SSL 프로시저에 익숙하다면, 이 섹션은 무시해도 좋다.
연결에서 개방(opening) 핸드쉐이크는 서버에 "Hello"라고 말하는 클라이언트로 시작된다. Hello 메시지에는 클라이언트의 보안 매개변수들이 포함되어 있다.
SSL 버전 넘버
무작위로 생성된 데이터
암호 설정
통신에 필요한 기타 사항
서버는 클라이언트가 제공한 것과 같은 유형의 정보인 서버의 보안 매개변수들을 포함하고 있는 고유의 Hello 메시지에 응답한다. 바로 이때 서버도 디지털 인증서를 보낸다. 클라이언트 권한이 연결에 사용되면 서버는 클라이언트의 인증서에 대한 요청을 보낸다.
서버의 Hello 메시지를 받으면, 디지털 인증서가 확인된다. 인증서의 다양한 매개변수들을 확인하여 인증서가 원래 그대로 보존되었는지를 확인하고, 유효 기간 내에 인증서가 사용되고 있는지를 확인한다.
여기에서 수행되어야 하는 한 가지 단계는 연결에 사용되는 호스트 네임과 비교하여 인증서 상의 이름을 검사하는 것이다. 이는 SSL 표준의 일부는 아니지만, man in the middle attack (MITM)을 방지하기 위해서 권장된다. 이 단계는 인증서가 여러분이 생각하고 있는 엔터티에서 온 것임을 확인한다. 이 두 개가 이 지점에서 매치되지 않으면, 인증서는 무효한 것이 아닌, 의심의 대상이 된다.
클라이언트와 서버 간 공유되었던 랜덤 데이터는 서버와 클라이언트에게만 알려진 공유 비밀 값으로서 이 세션에만 사용되는 premaster secret을 생성하는데 사용된다. 이 비밀 값은 서버의 디지털 인증서로 암호화 되고 확인을 위해 서버로 보내진다.
서버가 클라이언트 인증을 요청하면, 클라이언트는 핸드쉐이크 동안 무작위로 생성되고 서버와 클라이언트에게만 알려진 데이터의 단방향 해시(hash)를 생성한다. 클라이언트는 클라이언트의 개인 키(private key)를 사용하여 해시에 서명을 하고 서명된 데이터와 디지털 인증서를 서버로 보낸다. 서버는 그 정보를 사용하여 클라이언트를 인증한다.
인증이 성공하면, 서버와 클라이언트 모두 공유된 랜덤 데이터를 알고리즘을 통해 실행하여 master secret을 생성한다. master secret에서, 클라이언트와 서버는 세션 키(session keys)를 생성한다. 이것은 선택된 시메트릭 암호 안에 있는 대칭 키로서 세션 데이터를 암호화 하는데 사용된다.
클라이언트는 종료되었다는 메시지를 서버로 보냄으로써 핸드쉐이크를 종료한다. 이것은 서버에 의해 확인되어야 하는 암호화 된 단방향 해시 값 세트이다. 서버는 비슷한 메시지를 클라이언트로 보낸다. 클라이언트와 서버는 핸드쉐이크를 종료하고 통신을 시작하기 전에 데이터가 정확한지를 확인한다.

피어 인증서 확인하기
핸드쉐이크에서 제공된 서버의 인증서는 서버의 호스트 네임과 매치하는 것에 대한 이름을 가져야 한다. 그렇지 않다면, 인증서는 의심스러운 것으로 표시되어야 한다. 내부 확인 절차는 이미 트러스트와 종료에 대해 인증서를 검사한다. 인증서가 종료되었거나 믿을 수 없는 서명을 포함하고 있다면 무효로 표시된다. 이것은 SSL 표준의 일부가 아니므로 OpenSSL은 호스트 네임에 대해 인증서의 이름을 검사하지 않는다.
인증서의 "이름"은 실제로 인증서 상의 Common Name 필드이다. 이 필드는 인증서에서 가져온 것이어야 하며 호스트 네임에 비교하여 확인되어야 한다. 이 두 가지가 매치되지 않으면, 인증서는 무효가 아닌 의심 상태가 된다. Yahoo! 같은 일부 기업들은 다양한 호스트에 같은 인증서를 사용한다. 그 인증서에 대한 Common Name이 단 한 개의 호스트를 위한 것인데도 말이다. 인증서가 같은 회사에서 온 것인지를 확인하기 위해 보다 심도 깊은 체크가 수행되지만, 이는 프로젝트의 보안 필요에 따라 수행한다.

여기까지... 좋은 개발, 좋은 하루...

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG openssl, SSL, TLS

댓글을 달아 주세요