Webkit 歷史圖示

Webkit-Browser-1-768x487

最早的技術擁有者應該是 Netscape, 但 KDE 用了一套自訂的 Javascript engine – KJS 和 webcore engine – KHTML. 其中 KHTML 做得比 Netscape Navigator 的 Gecko 還小, 所以被 Apple 相中拿來開發 Webkit. KDE 原本沒有做 webview 的部分, 所以 Webkit 的名稱是 Apple 取的.

Apple 除了開發 Webkit, 又以兩手策略開發封閉性的 Safari. 到了 2010 年, Apple 做出 multi-process 的技術, 把 main process 和 render process 分開, 因此把 Webkit 改為不相容的 Webkit 2.0.

Google 的策略是借用 Webkit 的 Webcore, 其他自己搞. 後來開發出  V8 Javacript engine, 算是有了重大突破. 接著 Google 又做出 Blink engine, 把 webcore 換掉, 這些好料都放進了 Chrome. 當然 Google 也是兩手策略, 不會平台讓 Apple 佔便宜.

QT 和 GTK 都基於 Webkit 2.0 做出新版. 同理, WPE (Wayland for Webkit) 當然也是 ‘for’ Webkit 2.0 才聰明. 

那 Chrome 有 multi-process 嗎? Chrome (Chromium) 的做法是起好幾個 Webkit [1]. 以空間換取時間. 至於沒有 mutli-process 的弱點, 據說是用 timer 來多工執行, 沒有用到多核的優點 [3].

Chrome-768x713

那 Blink 比起原來的 Webcore 差多少? 根據 [2], Blink 從 Webkit 裡面刪掉 8.8 百萬行的 source code…身輕如燕, 難怪叫做 blink. 不意外地, Qt 等等上層 API 也 port 到了 Blink.

對了, Chromium 是鉻, Cobalt 是鈷, 看起來是兄弟關係. 那麼 Google 的 Cobalt 又是做甚麼的? 這個資訊很難找, keyword 下錯絕對搜尋不到, 客官要看這裡 [4]. Cobalt 的作者本來是負責維護 Chromium 裡面的一段代碼, 叫做  H5VCC (HTML5 Video Container for Consoles). 他在各種平台 porting 這段 9 百萬行的 code  好幾年後, 終於受不了了. 決定要推出符合下面特色的功能:

  • Limited Memory. 記憶體少.
  • Slow CPUs. CPU 慢.
  • Fewer cores. 更少核.
  • Sometimes No GPU. 可能沒 GPU.
  • Sometimes No JIT. 考量安全性, 也不需要支援 just in time 代碼.
  • Heterogenous Development Environments. 跨平台環境.
  • No navigation. 不用瀏覽, 只要呈現.
  • No scrolling. 不需要捲動畫面.

因為 Cobalt 弱弱地不用處理很多事情, 連 Javascript engine 都可以偷掉. We have, perhaps surprisingly, not written our own JavaScript Engine from scratch. Because of the JITing constraint, we have to be flexible with which engine(s) we work with. We have a bindings layer that interfaces with the JS Engine so that application script can interface with natively-backed objects (like DOM elements). 因此近來成為 porting Youtube 的主流.

[REF]

  1. https://www.chromium.org/developers/design-documents/multi-process-architecture
  2. http://browserg.nom.es/
  3. https://www.zhihu.com/question/20930880
  4. https://cobalt.googlesource.com/cobalt/+/refs/heads/master/src/README.md

HTTPS 小註解

看臉書上說, 現在大部分的網站都用 HTTPS 了. 雖然說臉書假新聞多, 那我這個站呢? 我把我改 HTTPS 的心得跟大家也分享一下.

首先, XAMPP 就可以自行產生 key, 變成 HTTPS 的網站 [1]. Keyword 就是 makecert.bat 打下去就對了! 在交互式的輸入中, 除了 Common Name 要打 IP 或是 domain name 之外, 沒有什麼難的. 做完之後, 它自動會把三把 key 放到 apache/conf/ 下面的三個目錄:

ssl.csr 裡面放 server.csr
ssl.crt 裡面放 server.crt
ssl.key 裡面放 server.key

這樣第一階段就完成了. 第二步要確定 apache/conf/ 下的 httpd.conf 裡面, 

LoadModule rewrite_module modules/mod_rewrite.so

這行的註解 (‘#’) 被拿掉後, 用 https://www.cash.idv.tw 就可以連上我的網站了. 當然, 後面還有一些細節是要保護那些目錄? 這個我先略過不提. 我要講的重點是, 如果用 chrome browser  去連 https://www.cash.idv.tw, 它竟然把我的 https 用斜線劃掉了, 這樣看起來好丟臉啊! 

not-https

查了前人的文章 [2], 才知道 Chrome 會檢查憑證是否為第三方所認證的. 我們自己產生出來的 key, 當然不能說很有說服力, 有人證認確實比較好. 怎麼辦呢? 找到一個 SSL for free 可以解決這個問題 [3], 只要按照網站上說的, 產生 SSL key 應該不困難.

在這個過程中, 我發現我在 PCHOME 代管的 DNS, 只有註冊 http://www.cash.div.tw, 沒註冊 cash.idv.tw.  把這個問題修正了之後, 才能夠通過 SSL fro free 的測試. 如果一切順利, SSL for free 網站會生出三個檔案, 打包成一個 sslforfree.zip 下載.

這個 zip 檔解開之後, 會看到 ca_bundle.crt, certificate.crt, private.key 三個檔案. 看起來只要能用這三個檔案代替 XAMPP 的三個檔案, 那麼 Chrome browser 也不能再挑剔我的 key 沒有公信力了吧!

話雖如此. 那個對到哪個呢? 這訊息我 Google 不到, 畢竟用 SSL for free 的人和用 XAMPP 的人交集很少吧!? 那就只好自己來了. 雖然我好想靠別人哪~~~

根據 /apache/conf/extra/httpd-ssl.conf 裡面寫的, private.key 顯然就是 server.key

# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you’ve both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
# ECC keys, when in use, can also be configured in parallel
SSLCertificateKeyFile “conf/ssl.key/server.key"

CA 是第三方認證的. 顯然是 ca_bundle.crt 那包, 要放到 ssl.crt, 我把 ca_bundle.crt 直接 rename 成 ssl.crt 下的 server.crt. 不 rename 改 config 檔也可以通.

# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath “c:/Apache24/conf/ssl.crt/"
#SSLCACertificateFile “c:/Apache24/conf/ssl.crt/ca-bundle.crt"

最後是 certificate.crt, 難不成它就是  ssl.csr 下的 server.csr? 看起來也的確有對上.

# Server Certificate:
# Point SSLCertificateFile “conf/ssl.crt/server.crt"
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
# Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
# require an ECC certificate which can also be configured in
# parallel.
SSLCertificateFile “conf/ssl.crt/server.crt"

把這三個檔案各自 rename 之後, Chrome 也就不抱怨我的 https 了. 測試了一下 http 和 https 都可以連上我的網站. 按照網路上的說法, 應該要把 http 的網址關掉, 然後只用 https 的網址. 或者把 http 的 request 都 redirect 到 https. 不過, 只要我打開 SSLRequireSSL, XAMPP 就開不起來了. 這個我還在研究中. 總之, 我把 Chrome 的紅字先劃掉了!

SSL for Free apache 目錄 重新命名
ca_bundle.crt ssl.crt server.crt
certificate.crt ssl.csr server.csr
private.key ssl.key server.key

2017/2/26 補充

如果要在後台強制使用 https, 參考 [4] 這篇, 在 wp-config.php 當中, 在 下面這段出現之前 (它通常在最後一行).

/** 設定 WordPress 變數和包含的檔案。 */
require_once(ABSPATH . ‘wp-settings.php’);

加入下面的 define. 因為有版本新舊的關係. 可以兩個都加.

define(‘FORCE_SSL_ADMIN’, true); /* 新版適用 */
define(‘FORCE_SSL_LOGIN’, true); /* WordPress version 4 以後就不用了 */

[REF]

  1. http://robsnotebook.com/xampp-ssl-encrypt-passwords
  2. HTTPS網站被Chrome打臉?
  3. SSL For Free 免費 SSL 憑證申請,使用 Let’s Encrypt 最簡單方法教學!
  4. Administration Over SSL

Webkit 相關小檔案

原本我以為免費 browser 盛行之後, Opera 就沒搞頭了. 想不到他們和 Google 聯手在今天四月推出了新的 web browser engine – blink, 放到了 Chrome 28 版和 Opera 15 版.

大家都知道 Google 有 Chrome browser 而 Android 用 Webkit 當預設的瀏覽器, 但他們原先其實都是 Webkit [1]. 而 Webkit 是 Apple 從 open source 的 KDE project 中分支出來的, 它借用了 KDE 的 KHTML engine 和KJS  Javascript engine. 由於 KDE 是 open source, 當然 Webkit 也必須是 open source, 只是 KHTML 發展成 WebCore, 而 KJS 變成 JavaScriptCore.

等到 Apple 熟悉了瀏覽器的技術, 就做出了 Safari, 並且聲其中牽涉到 OS 的技術, 所以不用 open source. Google 同樣是先加入 Webkit 計畫練兵, 並且在 2006 年另外開了一個 Chromium 的 open source project 另外發展一套瀏覽器 [2].

Google 在 Chromium 計畫的主要成果包括 V8 Javasceipt 引擎, sandbox, 黑名單, 與無痕瀏覽等等. 其中, V8 就曾經被放進 Android 4.0 的 Webkit 當中. 當然最好的東西都進了 Chrome browser. 最後 Google 的人開始嫌棄 Webkit [3], 並且打算在 Android 5.0 把它拔掉, 換成自家的 browser.

話說, Google 和 Apple 是 Webkit 這個 open source project 的最主要的 reviewer, 自己在管的計畫為什麼還嫌東嫌西呢? 其實 Chome  之於 Google 就像 Safari 之於 Apple, 自己有了獨到的心得之後, 難免就不想再和別人分享. 上次 Chromium 最傑出的成果是 V8 JavaScript engine, 而這次 Google 的突破點在於 HTML engine – blink. 看來內外功都已經練成了.

Chrome 的 blink 比 Webkit 的 WebCore 強在那裡呢? [ref 3] 首先說到 multi-process, Google 認為 Webkit 在這個情境下會拖慢速度, 而 blink 當然只要一眨眼. [Ref 4] 則大致介紹了 blink 在 multi-process 的設計概念. 這個可以單獨寫一篇, 初步的理解就是改了 data structure, 用空間換取時間.

那麼 Opera 又扮演什麼角色呢? 它最近宣布放棄開發瀏覽器 [3], 準備擁抱 Chrome. 這件事引起許多人在網路上討論. 原來這也不是因為 Opera 有什麼高瞻遠矚, 而是 Opera 的 Mobile OEM 業務已經被 Android 打掛, 萎縮到不值得經營了. 它在 2012Q4 的業績就比前一個年度下滑 89% [5].

相對地 Opera 在 device OEM 的部份還有成長, 只要把內核換成和 Android 一樣, STB 上的 Opera browser 將會和大家用的 Chrome 或 Safari 更加神似. Opera 廢掉自己的武功, 雖然可以省下研發的費用, 但也有人說 Opera 的企業精神已經喪失. Google 殺人於無形, Opera 投敵求生, IT 業真是可怕.

[REF]

1. Webkit

2. Chromium

3. Google Forks WebKit And Launches Blink, A New Rendering Engine That Will Soon Power Chrome And Chrome OS

4. Design Plans for Out-of-Process iframes

5. Opera放弃自家内核转投WebKit的背后