【Linux开发】关于X11

X-Window（维基百科：https://en.wikipedia.org/wiki/X_Window_System）是一个窗口系统，采用的是server-client架构，分为两个部分x-server和x-client，其中x-server其能够直接操作硬件显示器，而x-client不能直接操作显存，而是使用X11协议向x-server发送图像绘制请求，例如“请在点(10,10)处绘制一个半径为100像素的圆”。常见的比如GNOME(基于GTK)、KDE(基于QT)等软件都是使用X11协议的client端软件，向系统中的x-server程序发送显示请求进行图形绘制操作，这种架构对我来说有种特别的熟悉感。

仔细想来，和我使用过的 组态屏/串口屏 的原理很相似，单片机系统通过串口按照指定的通讯协议向组态屏中发送显示命令，组态屏也可以将用户的触摸操作等事件回传给单片机系统，实现了一个人机交互系统。如果我们将串口协议改成了TCP/IP协议，那么组态屏可以实现为多个单片机系统提供人机交互的服务，相当于同时打开了多个图形化软件一样，这就和x-window的原理是一样的了。这种设计结构的优点很突出，就是简单方便，主机不需要在意显示的细节，所有的显示和处理输入的任务都交给了组态屏，并且可以处理多个有显示需求的客户端。但是这种设计的缺点也很明显，通过串口或者TCP/IP协议的效率显然不如直接操作显存高，应该说是远没有直接操作显存高，比如我想要在组态屏上显示一个实时的视频流，那串口显然是带宽不够，使用TCP/IP协议可能也很勉强，假如显示的像素信息是没有压缩过的，传输未压缩的视频所需要的带宽是非常高的，就算x-client和x-server在同一台机器上，使用回环网络，不占用外网带宽，还是会影响协议栈的性能（还上不上网了）。

为此我特定搜索了一下关于X11的效率问题，看到一个有参考价值的讨论：https://superuser.com/questions/1217280/why-is-x11-forwarding-so-inefficient，引用其中的几段内容：

The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today.

Basically X11 doesn't send the screen to your computer, but it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change/refresh of the display.
So your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (xx,yy), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc."
The local client isn't really aware what needs to be updated and the remote system has very little information on what the client actually needs, so basically the server must send a lot of redundant information that the client may or may not need.
This is very efficient if the display to be rendered consists of a limited number of simple graphical shapes and only a low refresh frequency (no animations and such) is needed. Which was the case back in the days when X11 was first developed.

But modern GUI's have a lot of eye-candy and much of that needs to be send from the remote system to your client in the form of bitmaps/textures/fonts which take quite a lot of bandwidth. And all sorts of eye-candy includes animated effects requiring frequent updates. And the displays keep getting bigger too, twice as wide/high is 4x the number of pixels.

Of course, over time, enhancements to the X11 protocol were made to optimize this as much as possible, but the basic underlying design is, in essence, simply not well suited to the demands of the kind of GUI's people nowadays expect.

Other protocols (like RDP and VNC) are more designed to let the remote system do all the hard work and let that system decide which updates to send to the client (as compressed bitmaps) as efficiently as possible. Often that turns out to be more efficient for modern GUI's.

Neither method is perfect and can deal with every situation equally well. There is no such thing as a single display-protocol that can do well under every conceivable use-case.
So in most cases you just try all protocols that are supported between your local client and the remote server and use the one that gives the best results. And in some cases there is no choice and you just have to make do with whatever is available.

Most protocols do allow some performance tuning, but many of these settings are server-side only and not available to the average user. (And configuring them properly is a bit of an arcane art. A lot of sys-admins won't be willing to mess with that.)

In most cases the easiest way to improve performance (sometimes quite dramatically) is by switching to a more simple desktop environment with less eye-candy and forego the use of background images.

在X11的诞生时期(1984年左右，WIN95都没出现的年代)，并没有那么多花里胡哨的可视化界面系统，所以X11的出现从一开始就不是针对图像、视频、动画等图形类信息的(这些信息不仅需要庞大的带宽，还需要很低的时延)，它的目的仅仅是绘制文本，绘制圆圈方框这样的简单的图像而已，因此，基于X11传输的数据也不是屏幕的显存数据，而是显示指令集。然而，现在的计算机系统都拥有华丽的外观，加上多媒体的高速发展，X11的设计在现在显得不是很高效......

There are primarily two reasons for X11 connections to be slow, both of which you touched on in your question: bandwidth and latency. To understand why X11 apps are slow over a network, let's discuss both of these.

Bandwidth

X11, by default, doesn't do any compression on the network data that gets passed between the application and the display server. As you mentioned, you can use the -C option on SSH to enable compression, and while this does help, it's not optimized for compressing graphical data. Compared to formats like H.264 which can obtain compression rates of 100 to 1, the -C compression will be lucky to achieve 2 to 1 compression. A better solution is to use a graphics or video optimized codec for the X11 video, but we have to be careful not to make it too lossy as desktops generally need to have sharper images than a movie so the user can still clearly read the text and make out fine details.

Latency

X11 tends to have high latency because most operations require multiple round trips between the application and the display server. When run across a LAN where ping times measure less than a millisecond these multiple round trips aren't noticeable, but across an internet connection they add up quickly.

Solutions

A number of years ago there were a couple projects build to address the bandwidth and latency issues inherent in the X11 protocol. lbx (Low Bandwidth X) and dxpc (Differential X Protocol Compressor). I don't think lbx ever got much traction, but dxpc became the underlying technology used for a product called NX. NX uses both lossy compression to reduce the bandwidth requirements and a differential algorithm and caching to reduce the number of back-and-forth information passing that creates the high latency. I've used NX quite often and find the performance to be almost as good as local applications. If you're feeling up to it you might try NX and see if it works for you. The downside is that it requires installing software on both ends of the connection, whereas X11 is generally already installed.

这位朋友提到了约束X11效率的两个关键因素，带宽和时延，这点对client和server不处于同一主机的场景来说十分关键。但是X11其实是拥有压缩功能的，可以将显示数据进行压缩后再传输，这样可以一定程度上提高效率。

后面也有一条评论说道：

Latency wise, on *ix machines, X11 sessions to local displays usually use Unix 
domain sockets instead of TCP; Unix domain sockets are many times faster than TCP 
at round trips even to localhost stackoverflow.com/questions/14973942/…. For X11 
apps with really pathologically large numbers of round trips, that could be the 
difference between okay and noticeably slow performance. – rakslice Feb 2 at 4:15 

x-server对于本地的x-client会使用 Unix domain sockets 来代替 TCP协议，Unix domain socket的速度相比于内部回环网络来说快好几倍，这对于本地运行的x-client来说是一个好消息。

Unix domain socket 参考：https://www.cnblogs.com/sparkdev/p/8359028.html。

Unix domain socket 又叫 IPC(inter-process communication 进程间通信) socket，用于实现同一主机上的进程间通信。socket 原本是为网络通讯设计的，但后来在 socket 的框架上发展出一种 IPC 机制，就是 UNIX domain socket。虽然网络 socket 也可用于同一台主机的进程间通讯(通过 loopback 地址 127.0.0.1)，但是 UNIX domain socket 用于 IPC 更有效率：不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用层数据从一个进程拷贝到另一个进程。这是因为，IPC 机制本质上是可靠的通讯，而网络协议是为不可靠的通讯设计的。

UNIX domain socket 是全双工的，API 接口语义丰富，相比其它 IPC 机制有明显的优越性，目前已成为使用最广泛的 IPC 机制，比如 X Window 服务器和 GUI 程序之间就是通过 UNIX domain socket 通讯的。