Chrome Dev Summit - 공개 웹 플랫폼 요약

Sam Dutton

작성자: Greg Simon & 에릭 세이델

Blink는 Chrome의 오픈소스 렌더링 엔진입니다. Blink팀은 웹을 발전시키고 개발자가 경험하는 문제를 해결하기 위해 노력하고 있습니다.

4월 출시 이후 여러 가지 보이지 않는 개선사항이 있었습니다.

가장 먼저 한 일은 소스의 절반을 삭제하는 것이었고, 이건 꼭 필요하지는 않았습니다. 아직 끝나지 않았습니다! 또한 맹목적으로 코드를 삭제하는 것은 아닙니다. 코드 삭제는 보고에 동의한 Chrome 사용자로부터 익명으로 보고되는 집계 통계를 기반으로 합니다.

Google은 6주마다 새로운 개발자 API를 게시합니다. 이는 Chrome의 배송 일정과 동일합니다.

Blink에서 포크한 큰 한 가지 큰 변화는 인텐트 시스템을 추가하는 것이었습니다. 웹 플랫폼을 변경하기 전에 매번 Blink 개발자에게 기능을 추가하거나 삭제할 의도를 알리는 공개 공지를 전송합니다. 그런 다음 코딩을 시작합니다. 그리고 이 기능이 체크인된 다음 날, 이미 Canary 빌드에 포함되어 있습니다. 이 기능은 기본적으로 사용 중지되어 있지만 about:flags를 사용하여 사용 설정할 수 있습니다.

그런 다음 공개 메일링 리스트에 발송 의도를 발표합니다.

chromestatus.com에서 그동안 작업한 기능, 출시한 기능, 지원 중단 예정인 기능을 확인할 수 있습니다. 버그 및 트래커 대시보드로 연결되는 링크가 있는 Chromium 출시 블로그를 확인할 수도 있습니다.

또 다른 큰 변화는 WebKit 접두사를 삭제한다는 것입니다. 그 목적은 블링크 접두사를 사용하는 것이 아니라 컴파일 시간 플래그만이 아니라 런타임 플래그를 보유하는 것입니다.

Android WebView는 큰 과제였지만 HTML5Test에서는 개선되고 있음을 보여줍니다. 어디서나 하나의 웹 플랫폼 API 세트를 제공한다는 점에서 데스크톱에 훨씬 더 가깝습니다. 웹 오디오가 좋은 예입니다.

하지만 소시지 기계는 어떻게 작동할까요? Blink의 모든 변경사항은 즉시 30,000번이 넘는 테스트를 거치며 이후에 추가로 실행되는 모든 Chromium 테스트를 거치게 됩니다. 또한 수천 개의 봇, 수천 개의 벤치마크 및 시스템을 통해 수백만 개의 깨진 웹페이지를 엔진에 가하여 페이지를 망가뜨리는 일이 없도록 하기 위해 24시간 보안 검사를 사용합니다. Google은 모바일 속도가 현저히 느리다는 점을 잘 알고 있으며 이를 개선하기 위해 최선을 다하고 있습니다.

새로운 기능

  • 웹 구성요소: 에릭 비델만의 강연을 확인해 보세요.
  • 웹 애니메이션: 가능하면 GPU를 사용하는 복잡하고 동기화된 고성능 애니메이션
  • 부분 레이아웃: 필요한 것만 계산하세요.
  • CSS 그리드
  • 반응형 이미지: srcset, srcN 또는 ?
  • 더 빠른 텍스트 자동 크기 조절 및 일관된 하위 픽셀 글꼴
  • Blink에서 사용하는 그래픽 시스템인 Skia가 Windows의 GDI에서 DirectWrite로 전환 중입니다.

고객님의 의견을 듣고 싶습니다.

C++를 사용하는 것 같고 Google과 함께 C++를 작성하려는 경우 모든 코드를 공개합니다. 누구에게도 말하거나 Google에 전파하지 않아도 됩니다. 패치를 게시하거나 버그를 신고하기만 하면 됩니다.

슬라이드: 깜박임

보안

Parisa Tabriz

오늘날 그 어느 때보다 많은 사람들이 더 많은 장소에서 웹에 연결되어 있습니다.

우리는 노트북, 전화 및 태블릿과 연결되어 있으며, 아마도 곧 개인용 기기 및 액세서리로도 충분할 것입니다. 신뢰할 수 없고 때로는 적대적인 네트워크에서 인터넷에 액세스합니다. 우리 삶의 많은 부분이 온라인으로 옮겨가고 있기 때문에 데이터와 사용자의 안전을 지키기 위한 조치를 취해야 합니다. 데이터를 수집하는 데 사용됩니다

무엇보다도, 개발자로서 우리는 SSL의 필요성과 실용성을 이해해야 합니다.

SSL이란 무엇인가요? Secure Sockets Layer의 약자이며 인터넷을 통한 통신 보안을 제공하도록 설계된 암호화 프로토콜입니다. 암호화 및 무결성을 통해 개인 정보를 보호하여 인터넷 연결 스누핑이나 조작을 방지합니다. SSL에는 결함이 있지만 인터넷에서 모든 종류의 데이터 통신 보안을 보장할 수 있는 선도적인 방법이자 유일한 방법입니다.

SSL Pulse에 따르면 1년 전만 해도 SSL을 도입한 비율이 15% 미만이었습니다. 현재 50% 가 넘었습니다.

두 가지 약어:

  • TLS: 대부분의 인텐트와 용도는 SSL과 동일합니다. 정확히 말하면 SSL 3.1은 TLS로 이름이 변경되었으며 TLS는 IETF 표준 이름입니다. 하지만 서로 바꿔서 사용할 수 있습니다.

  • HTTPS:SSL을 통한 HTTP로, SSL 및 표준 HTTP의 보안 기능을 레이어한 것입니다. 먼저 클라이언트-서버 핸드셰이크가 공개/비공개 키 암호화를 사용하여 공유 키를 생성합니다. 이 키는 SSL 프로토콜의 두 번째 부분에서 통신을 암호화하는 데 사용됩니다.

인터넷 네트워킹은 안전하고 즉각적이며 빠르게 느껴질 수 있습니다. 마치 웹사이트와 직접 대화하는 것 같습니다. 그러나 실제로는 직접적인 관계가 아닙니다. Google의 통신은 Wi-Fi 라우터, ISP 및 기기와 웹사이트 간의 기타 중개 프록시를 통해 이루어집니다. HTTPS를 사용하지 않으면 모든 커뮤니케이션이 일반 텍스트로 이루어집니다.

문제는 사용자가 HTTPS를 지정하는 전체 URL을 입력하거나 HTTP를 사용하여 링크를 클릭하는 경우가 거의 없다는 점입니다. 더 나쁜 것은 중간자 공격을 마운트하여 HTTPS를 HTTP로 대체할 수 있다는 것입니다. 2009년에 도입된 SSLstrip라는 도구가 바로 이 작업을 수행합니다. Firesheep은 2010년부터 개방형 Wi-Fi 네트워크에서 전송되는 쿠키를 듣다가 채팅 중에 청취하거나 다른 사람의 Facebook 계정에 로그인할 수 있었습니다.

그러나 SSL은 상대적으로 저렴하고 빠르고 쉽게 배포할 수 있습니다(ssllabs.com 및 Ilya Grigorik의 저서 High Performance Browser Networking 참조). 공개 키 고정은 웹사이트 운영자가 실제로 사이트에 인증서를 발급할 수 있는 인증 기관을 제한할 수 있도록 설계되었습니다.

"올해 (2010년 1월)에 Gmail은 기본적으로 모든 항목에 HTTPS를 사용하도록 전환했습니다. 이를 위해 추가 머신이나 특별한 하드웨어를 배포하지 않아도 되었습니다. 우리의 프로덕션 프런트엔드 머신에서 SSL은 CPU 부하의 1%, < 연결당 메모리 10KB 및 < 네트워크 오버헤드의 2%...

지금 읽지 않고 있다면 한 가지만 기억하면 됩니다. SSL의 계산 비용이 더 이상 필요하지 않다는 것입니다."

– SSL 오버클로킹, Adam Langley (Google)

마지막으로 가장 흔히 발견되는 몇 가지 버그는 다음과 같습니다.

  • 혼합 콘텐츠: HTTPS와 HTTP를 사용하는 사이트입니다. 사용자가 콘텐츠를 로드하려면 권한 버튼을 클릭해야 하기 때문에 불편을 느낄 것입니다. (Chrome 및 Firefox는 실제로 iframe에서 혼합 콘텐츠를 차단합니다.) HTTPS 페이지의 모든 리소스가 상대 URL 또는 스키마 상대 URL(예: <style src="//foo.com/style.css">)을 사용하여 HTTPS에 의해 로드되도록 합니다.
  • 안전하지 않은 쿠키: HTTP 연결을 통해 명확하게 전송됩니다. 쿠키 헤더에 보안 속성을 설정하여 이러한 상황을 피하세요. 또한 새로운 'Strict Transport Security'를 SSL을 요구하는 헤더 전송 보안 (HSTS).

요약

  • 사용자의 개인정보 보호와 무결성을 중시하는 경우 SSL을 사용해야 합니다. 더 빠르고 쉽고 저렴하게 이용할 수 있습니다.
  • 혼합 콘텐츠 버그나 올바른 HTTP 헤더 비트 설정 미설정 등 일반적인 구현 문제를 피하세요.
  • 상대 URL 또는 스키마 상대 URL을 사용합니다.
  • HSTS, 인증서 고정 등 새롭고 멋진 기능을 확인해 보세요.

Slides: SSL을 가지고 있나요?

다중 기기 웹을 위한 미디어 API

Sam Dutton 및 얀 린덴

웹에서 새로운 기기와 플랫폼이 늘어남에 따라 오디오, 동영상 및 실시간 커뮤니케이션도 엄청나게 성장하고 있습니다. 온라인 미디어는 우리가 모든 종류의 미디어를 소비하는 방식을 바꾸고 있습니다.

영국 정부의 연구에 따르면 성인의 53% 가 '미디어 멀티태스킹'을 하는 것으로 나타났습니다. TV 시청 중: 휴대기기를 사용하여 미디어를 공유하고 소비함 많은 국가에서 TV 시청은 감소하고 온라인 시청은 증가하고 있습니다. 예를 들어 중국에서는 2009년의 70% 에서 2012년 베이징 가구 중 30% 만 TV를 시청했습니다. W3C Highlights 2013에 따르면 '지난 한 해 동안 휴대기기에서 동영상을 시청하는 사용자가 2배 증가했습니다. 올해 미국에서는 하루 평균 디지털 미디어 시청 시간이 TV 시청 시간을 초과할 것으로 예상됩니다. 시청은 더 이상 수동적인 행위가 아닙니다. 미국에서는 엔터테인먼트 소비자의 87%가 텔레비전을 시청하면서 보조 화면을 1개 이상 사용하는 기기를 사용한다고 답했습니다.' Cisco에 따르면 '동영상은 2017년까지 전 세계 소비자 트래픽의 80~90% 범위 내에 있을 것입니다'라고 합니다. 이는 1초에 거의 백만 분에 가까운 동영상 분량에 해당합니다.

그렇다면 웹 개발자를 위한 솔루션에는 어떤 것이 있을까요? 개방형 웹을 위한 미디어 API 생태계: 여러 플랫폼에서 작동하는 표준화된 상호 운용 가능한 기술

요약

  • WebRTC는 브라우저에서 실시간 커뮤니케이션을 제공하며, 현재 모바일과 데스크톱에서 널리 지원됩니다. 이미 총 12억 개가 넘는 WebRTC 엔드포인트가 있습니다.
  • 웹 오디오는 정교한 오디오 합성 및 처리 도구를 제공합니다.
  • 웹 오디오와 통합된 웹 MIDI를 사용하면 MIDI 기기와 상호작용할 수 있습니다.
  • 현재 모바일 및 데스크톱 브라우저의 85% 이상에서 오디오 및 동영상 요소가 지원됩니다.
  • 미디어 소스 확장 프로그램은 적응형 스트리밍 및 타임 시프팅에 사용할 수 있습니다.
  • EME는 보호된 콘텐츠의 재생을 사용 설정합니다.
  • 스크립트, 자막, 트랙 요소는 자막, 자막, 시간 표시 메타데이터, 딥 링크, 딥 검색을 지원합니다.

Slides: 멀티스크린 웹용 Media API