없으면 없는대로

WebKit 동향 (2011년 11월 기준, GPU 가속 feature를 중심으로...)

Dev 2011. 10. 21. 10:18

웹킷 어디까지 왔나?
(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 ingeeC

HTML5 동향 (2011년 10월 기준)

Dev 2011. 10. 13. 10:17

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 ingeeC

OpenSSL API 개요

Dev 2011. 2. 7. 21:51

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

http://www.ibm.com/developerworks/kr/library/l-openssl.html

(원문: http://www.ibm.com/developerworks/linux/library/l-openssl.html)

보안 연결 설정하기

이제 보안 연결을 설정하는데 필요한 것을 알아보자. 달라진 유일한 부분은 연결 설정 및 연결을 만드는 것이다. 다른 모든 것은 똑같다.

보안 연결은 연결이 구축된 후에 핸드쉐이크(handshake)를 필요로 한다. 헨드쉐이크 동안, 서버는 인증을 클라이언트에 보내는데, 클라이언트는 트러스트 인증에 준하여 이를 확인한다. 또한, 인증을 검사하여 만기가 되었는지를 확인한다. 인증이 신뢰를 받는 것인지를 확인하려면 트러스트 인증 스토어가 연결을 구축하기 전에 로딩되어야 한다.

클라이언트는 서버가 인증을 요청할 경우에만 서버로 인증을 보낸다. 이것은 클라이언트 인증으로 알려져 있다. 인증을 사용하여, 암호 매개변수들이 클라이언트와 서버 사이에 전달되어 보안 연결을 구축한다. 핸드쉐이크가 연결이 구축된 후에 수행되더라도, 클라이언트나 서버는 어떤 지점에서라도 새로운 핸드쉐이크를 요청할 수 있다.

핸드쉐이크와 보안 연결을 설정하는 다른 측면들은 Netscape 기술자료와 RFC 2246에 설명되어 있다.

http://www.ibm.com/developerworks/kr/library/l-openssl2.html

(원문: http://www.ibm.com/developerworks/linux/library/l-openssl2.html)

비즈니스를 시작하는 핸드쉐이크

이 글은 핸드쉐이크 하는 사이에 서버의 디지털 인증서를 처리하는 것에 초점을 맞추므로 핸드쉐이크가 어떻게 작동하는지를 상세히 살펴보고자 한다. 여러분이 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이 단 한 개의 호스트를 위한 것인데도 말이다. 인증서가 같은 회사에서 온 것인지를 확인하기 위해 보다 심도 깊은 체크가 수행되지만, 이는 프로젝트의 보안 필요에 따라 수행한다.

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