-
Notifications
You must be signed in to change notification settings - Fork 11
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
22 changed files
with
588 additions
and
312 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| Wed Jan 31 11:47:07 UTC 2024 | ||
| Wed Jan 31 12:56:11 UTC 2024 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,9 +4,30 @@ | |
| <description>News related to WPE WebKit.</description> | ||
| <link href="https://wpewebkit.org/blog.xml" rel="self"/> | ||
| <link href="https://wpewebkit.org/blog/"/> | ||
| <updated>2024-01-29T06:00:00Z</updated> | ||
| <updated>2024-02-01T00:00:00Z</updated> | ||
| <id>https://wpewebkit.org/blog/</id> | ||
|
|
||
| <entry> | ||
| <title>Use Case: Server-side headless rendering</title> | ||
| <link href="https://wpewebkit.org/wpewebkit.org/use-case-ssrendering/blog/2024-use-case-server-side-rendering.html"/> | ||
| <updated>2024-02-01T00:00:00Z</updated> | ||
| <id>https://wpewebkit.org/wpewebkit.org/use-case-ssrendering/blog/2024-use-case-server-side-rendering.html</id> | ||
| <content type="html"><div class="success-top"> | ||
| <img alt="WPE and server-side headless rendering" align="center" src="https://wpewebkit.org/assets/img/logo-server-side-rendering.png" srcset="https://wpewebkit.org/assets/img/[email protected] 2x" /> | ||
| <img alt="WPE" align="center" src="https://wpewebkit.org/assets/img/logo-blue.svg" /> | ||
| </div> | ||
| <p>In many distributed applications, it can be useful to run a light web browser on the server side to render some HTML content or process images, video and/or audio using javascript.</p> | ||
| <p>Some concrete use-cases can be:</p> | ||
| <ul> | ||
| <li>Video post-production using HTML overlays.</li> | ||
| <li>Easy 3D rendering with WebGL that can be broadcasted as a video stream.</li> | ||
| <li>Reusing the same javascript code between a frontend web application and the backend processing.</li> | ||
| </ul> | ||
| <p>WPE WebKit is the perfect solution for all those use cases as it offers a lightweight solution which can run on low-end hardware or even within a container. It provides a lot of flexibility at the moment of choosing the backend infrastructure as WPE WebKit can, for instance, run from within a container with a very minimal Linux configuration (no need for any windowing system) and with full hardware acceleration and zero-copy of the video buffers between the GPU and the CPU.</p> | ||
| <p>Additionally, the fact that WPE WebKit is optimized for lower-powered devices, makes it also the perfect option for server-side rendering when scaling commercial deployments while keeping cost under control, which is yet another important factor to take into account when considering cloud rendering.</p> | ||
| </content> | ||
| </entry> | ||
|
|
||
| <entry> | ||
| <title>A New WPE Backend Using EGLStream</title> | ||
| <link href="https://wpewebkit.org/wpewebkit.org/use-case-ssrendering/blog/07-creating-wpe-backends.html"/> | ||
|
|
@@ -849,57 +870,6 @@ Note that these implementations are already complete in LBSE downstream and do n | |
| <p>WPE WebKit brought <strong>RDK (Reference Design Kit)</strong>, a modern, performant web browser, to millions of screens. It enables operators to manage devices and easily customize their UIs and apps and provides analytics to improve the customer experience and drive business results.</p> | ||
| <p>Delivering a fast and memory-efficient browser for embedded systems is a challenging task, so Igalia helped Metrological build a new full-screen browser engine which stripped away all unnecessary toolkit elements.</p> | ||
| <p>With years of experience around WebKit platform integration, Igalia worked to produce a new WebKit port, WPE, which interfaced directly with Wayland and the graphics driver. Additionally, Igalia pushed forward the implementation of a multi-platform multi-threaded compositor, enabling better performance on low-end multicore processors. WPE is an official port of WebKit.</p> | ||
| </content> | ||
| </entry> | ||
|
|
||
| <entry> | ||
| <title>WPE Networking Overview</title> | ||
| <link href="https://wpewebkit.org/wpewebkit.org/use-case-ssrendering/blog/04-wpe-networking-overview.html"/> | ||
| <updated>2022-09-29T00:00:00Z</updated> | ||
| <id>https://wpewebkit.org/wpewebkit.org/use-case-ssrendering/blog/04-wpe-networking-overview.html</id> | ||
| <content type="html"><p>At the heart of any browser engine is networking: Connecting with services and other users. Unlike other engines, WebKit approaches this more abstractly by leaving a large portion of the networking up to individual ports. This includes network protocols such as HTTP, WebSockets, and WebRTC. The upside to this approach is a higher level of integration with the system-provided libraries and features so WebKit will behave similarly to other software on the platform often with more centralized configuration.</p> | ||
| <p>Due to this abstraction there are a few independent layers that make up the networking stack of WPE. In this post, I’ll break down what each layer accomplishes as well as give some insight into the codebase’s structure.</p> | ||
| <h2 id="networking-layers" tabindex="-1">Networking Layers</h2> | ||
| <div align="center"> | ||
| <img alt="WebKit Network Layers" src="https://wpewebkit.org/assets/networking-layers.svg" /> | ||
| </div> | ||
| <h3 id="webkit" tabindex="-1">WebKit</h3> | ||
| <p>Before we get into the libraries used for WPE, let’s discuss WebKit itself. Despite abstracting out a lot of the protocol handling, WebKit itself still needs to understand a lot of fundamentals of HTTP.</p> | ||
| <p>WebCore (discussed in <a href="https://wpewebkit.org/blog/02-overview-of-wpe.html">WPE Overview</a>) understands HTTP requests, headers, and cookies, as they are required to implement many higher-level features. What it does not do is the network operations, most parsing, or on-disk storage. In the codebase, these are represented by <code>ResourceRequest</code> and <code>ResourceResponse</code> objects, which map to general HTTP functionality.</p> | ||
| <h4 id="networkprocess" tabindex="-1">NetworkProcess</h4> | ||
| <p>A core part of modern web engine security is the multi-process model. In order to defend against exploits, each website runs in its own isolated process that does not have network access. In order to allow for network access, they must talk over IPC to a dedicated NetworkProcess, typically one per browser instance. The NetworkProcess receives a <code>ResourceRequest</code>, creates a <code>NetworkDataTask</code> with it to download the data, and responds with a <code>ResourceResponse</code> to the WebProcess which looks like this:</p> | ||
| <div align="center"> | ||
| <img alt="WebKit Network Flowchart" src="https://wpewebkit.org/assets/networking-flow.svg" /> | ||
| </div> | ||
| <h3 id="wpe" tabindex="-1">WPE</h3> | ||
| <p>WPE implements the platform-specific versions of the classes above as <code>ResourceRequestSoup</code> and <code>NetworkDataTaskSoup</code>, primarily using a library called libsoup.</p> | ||
| <p>The <a href="https://libsoup.org/">libsoup</a> library was originally created for the GNOME project’s email client and has since grown to be a very featureful HTTP implementation, now maintained by Igalia.</p> | ||
| <p>At a high level, the main task that libsoup does is manage connections and queued requests to websites and then efficiently streams the responses back to WPE. Properly implementing HTTP is a fairly large task, and this is a non-exhaustive list of features it implements: HTTP/1.1, HTTP/2, WebSockets, cookies, decompression, multiple authentication standards, HSTS, and HTTP proxies.</p> | ||
| <p>On its own, libsoup is really focused on the HTTP layer and uses the <a href="https://gitlab.gnome.org/GNOME/glib">GLib</a> library to implement many of its networking features in a portable way. This is where TCP, DNS, and TLS are handled. It is also directly used by WebKit for URI parsing and DNS pre-caching.</p> | ||
| <p>Using GLib also helps standardize behavior across modern Linux systems. It allows configuration of a global proxy resolver that WebKit, along with other applications, can use.</p> | ||
| <h4 id="tls" tabindex="-1">TLS</h4> | ||
| <p>Another unique detail of our stack is that TLS is fully abstracted inside of GLib by a project called <a href="https://gitlab.gnome.org/GNOME/glib-networking">GLib-Networking</a>. This project provides multiple implementations of TLS that can be chosen at runtime, including OpenSSL and gnutls on Linux. The benefit here is that clients can choose the implementation they prefer—whether for licensing, certification, or technical reasons.</p> | ||
| <h3 id="usage" tabindex="-1">Usage</h3> | ||
| <p>Let’s go step by step to see some real world usage. If we call <code>webkit_web_view_load_uri()</code> for a new domain it will:</p> | ||
| <ol> | ||
| <li>Create a <code>ResourceRequest</code> in WebCore that represents an HTTP request with a few basic headers set. | ||
| <ul> | ||
| <li><code>ResourceRequestSoup</code> will create its own internal representation for the request using <code>soup_message_new_for_uri()</code>.</li> | ||
| </ul> | ||
| </li> | ||
| <li>This is passed to the <code>NetworkProcess</code> to load this request as a <code>NetworkDataTask</code>.</li> | ||
| <li><code>NetworkDataTaskSoup</code> will send/receive the request/response with <code>soup_session_send()</code> which queues the message to be sent.</li> | ||
| <li>libsoup will connect to the host using <code>GSocketClient</code> which does a DNS lookup and TCP connection. | ||
| <ul> | ||
| <li>If this is a TLS connection <code>GTlsClientConnection</code> will use a library such as gnutls to do a TLS handshake.</li> | ||
| </ul> | ||
| </li> | ||
| <li>libsoup will write the HTTP request and read from the socket parsing the HTTP responses eventually returning the data to WebKit.</li> | ||
| <li>WebKit receives this data, along with periodic updates about the state of the request, and sends it out of the <code>NetworkProcess</code> back to the main process as a <code>ResourceResponse</code> eventually loading the data in the <code>WebProcess</code>.</li> | ||
| </ol> | ||
| <h2 id="summary" tabindex="-1">Summary</h2> | ||
| <p>In conclusion, WebKit provides a very flexible abstraction for platforms, and WPE leverages mature system libraries to provide a portable implementation. It has many layers, but they are all well organized and suited to their tasks.</p> | ||
| <p>If you are working with WPE and are interested in collaborating, feel free to <a href="https://www.igalia.com/contact/">contact us</a>. If you are interested in working with Igalia, you can <a href="https://www.igalia.com/jobs/browsers_webkit_position">apply here</a>.</p> | ||
| </content> | ||
| </entry> | ||
| </feed> | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.