逆向工程：揭示Google Colab未公开的秘密

OneFlow深度学习框架

来源｜Open Source Data Science Tools

翻译｜程浩源

Google Colaboratory，简称 “Colab” ，是一个免费的Jupyter notebook云平台。Colab 不仅可以为用户提供 Python 和 R notebooks 的运行环境，而且还允许用户免费共享部分 GPU 和 TPU 资源。

对于负责在 Jupyter Notebook 编程的数据科学家来说，Colab早已成为了默认的运行环境。然而，将 Colab 的算力运用到除 Jupter Notebooks 以外的其他应用，则是一件极其困难的事。

对于那些想生产模型，并将其带出Notebook阶段的机器学习工程师而言，这样的问题尤为明显。虽然 Notebooks 非常适合用来探索，但将它与训练过程编入正式流水线的高级MLOps工具一起使用时，效果不佳。

在遇到类似问题后，我决定不让 Colab 的局限性改变我的工作流程，而是尝试围绕我的工作流程去改变 Colab！

出于这个原因，今天我们将探究 Google Colab 的内部结构，并尝试稍微改变 Colab 的内置规则。需要提前声明的是，我们只是想探究 Colab，不会对 Colab 本身或者它的用户造成任何影响。

揭开幕后的秘密

Colab 的秘密在于它的后端：谷歌服务器为 Colab 提供基础设施支持，让用户可以轻松运行代码。因此，我们第一步先分析 Colab 的 API，最简单的方法是检查 Colab 在正常运行期间进行的 API 调用。

首先打开谷歌开发者工具，找到网络（Network）选项，然后运行一段代码，开发者工具开始记录 Colab 发出的每个请求，然后我们发现了一些有趣的东西。

41fa1f8b54985f18bbb3e2af24a83484.gif

bc535d4be24ccb05a3978f59b4e6f9bc.png

看上去这个URL(/tun/m//socket.io)是远程机器上运行的 Jupyter socket 的代理。

如果我们从 Colab 界面的左窗格打开 Files 窗格（默认显示 /content 目录），就会发现另一个有趣的请求：

56ab97fb7854a67fdc813896cdd9a9b4.gif

2d032af35ffd6e86cfa7926c81d254d7.png

这次 JSON 枚举远程主机上的文件做出了响应。这个URL(/tun/m//api/contents/)似乎指向提供文件元数据的服务。

7664fb505fc3b6efb15a52b1d2560d69.png

双击 Files 窗格里的文件，Colab 就会开始下载文件并且展示文件详细信息。如果单击 /content/sample_data/README.md，则会对 /tun/m//files/ 发出请求，返回该文件的内容。

e728897624064a3ca0e99d65468f26ce.png

很明显，https://colab.research.google.com/tun/m// 是运行 Colab 实例服务器的反向代理，它提供了 /socket.io 、 /files 和 /api/contents 端点。

让我们看看是否有任何服务在 Colab 容器实例内运行。Colab 中内置有 lsof 程序，运行 lsof -iTCP -sTCP:LISTEN，列出所有在 TCP 端口上监听网络请求的进程。

2506034f54cb222b87729b530266877c.png

看！colab-fileshim、node 和 jupyter-notebook 看起来都值得一探究竟。由于我们已经使用过Files窗格，所以先看看 colab-fileshim，它有 PID 28，因此检查 /proc 文件系统，查看进程的完整命令行：

a80f4283591c2e656d03428f4a7f9cb8.png

接下来研究 /usr/local/bin/colab-fileshim.py。讽刺的是，我们其实可以直接在 Files 窗格做到这一点。这个程序更像是一个无趣的文件服务器，除了服务器本身可以响应 localhost:3453/files （带有文件内容）和 localhost:3453/api/contents （带有 JSON 元数据）。这意味着 Colab 会将这些请求从信道 URL 转发到实例本身的端口3453。

在谷歌开发者工具的网络选项中，我们可以右键单击，复制 cURL 命令来重现它。例如，这是用于查看 README.md 文件的 cURL 命令：

c457e84f779cdb2fb34cef01507f6c7d.png

如果在本地计算机终端上运行此命令，会将该 README 文件的内容打印到我们的终端，通过不断尝试和纠错，我们可以减少大部分标头，只留下如下内容:

6c201ea23ef447a5c9936b76826d013e.png

x-colab-tunnel 标头表面上是为了防止 XSS 攻击，实际上是为了防止我们或黑客从常规浏览器选项发出这些请求。

cookie 标头用于向 Google 提供身份验证，证明我们可以访问笔记本实例。由于 cookie 比较长且难以处理，在本文的其余部分我们将其存储到 shell 变量 $COLAB_COOKIE 中。

a7dfa7dc8cbcbf920bade7ec9c3fc1bd.png

胜利1：揭示我们的服务器

现在，我们已经发现了 Colab 的反向代理，看看是否可以用它为传输我们自己的请求。

我们可以简单地用自己的服务器替换进程，而不会影响现有的 colab-fileshim.py 服务器！运行 pkill -f colab-fileshim 来终止现有服务器，这样就可以在同一个端口上启动我们自己的服务器。

下面做一个简短的演示，我们将启动 Python 默认的 HTTP 服务器，然后在 localhost:3453/files 中提供我们自己的文件。

6ff4771cbaff1f9b20cbd84bbdc6c371.png

瞧！我们现在可以更改 cURL 命令来下载我们自己的文件！

b8549a8a20f8fc61142616a28825945c.png

251d2

逆向工程：揭示Google Colab未公开的秘密

相关工具