小编Hel*_*rld的帖子

背景:ETag跟踪在这里得到了很好的解释,也在维基百科上提到过.

我在回答"如何阻止ETag跟踪？" 的回答中写道.让我写这个问题.

我有一个浏览器端解决方案,可以防止ETag跟踪.它无需修改当前的HTTP协议即可运行.这是ETag跟踪的可行解决方案吗？

我们没有告诉服务器我们的ETag,而是向服务器询问其ETag,我们将它与我们已经拥有的ETag进行比较.

伪代码:

If (file_not_in_cache)
{
    page=http_get_request();     
    page.display();
    page.put_in_cache();
}
else
{
    page=load_from_cache();
    client_etag=page.extract_etag();
    server_etag=http_HEAD_request().extract_etag();

    //Instead of saying "my etag is xyz",
    //the client says: "what is YOUR etag, server?"

    if (server_etag==client_etag)
    {
        page.display();
    }
    else
    {
        page.remove_from_cache();
        page=http_get_request();     
        page.display();
        page.put_in_cache();
    }
}

我的解决方案的HTTP会话示例:

客户:

HEAD /posts/46328
host: security.stackexchange.com

服务器:

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, …

“为什么 Javascript 比本机代码慢？”的传统答案 是：“因为它被解释了”。这种说法的问题在于解释并不是语言本身的品质。事实上，现在大多数 Javascript 代码都经过 JIT 处理，但这还远未接近本机速度。

如果我们从方程中删除解释因素并编译 Javascript AOT 会怎么样？它会与本机代码的性能相匹配吗？如果是，为什么这没有通过网络广泛完成*？如果不是，那么现在的性能瓶颈在哪里？

如果新的瓶颈是 DOM，如果我们也消除它会怎么样？一个无 DOM 的、已编译的 Javascript 会和本机代码一样高效吗？如果是，为什么这没有通过网络广泛完成**？如果不是，那么现在的性能瓶颈在哪里？

在剥离 DOM 部分和解释部分之后，我能看到 Javascript 和 C/C++ 之间唯一的大区别是前者具有动态类型。假设我们也消除了这一点，最终得到一个无 DOM、静态类型、提前编译的 Javascipt。与本机代码相比如何？如果它同样有效，为什么没有广泛使用呢？如果没有的话，现在的瓶颈在哪里？在这种情况下，JavaScript 几乎与 C 相同。

*有人可能会说 JIT 加载速度更快，但这并不能解释为什么 AOT 没有用于资源密集型 Web 应用程序（例如 3D 视频游戏），在这些应用程序中，AOT 性能优势非常值得最初的 AOT 编译延迟。（无论如何，都会出现明显的“游戏加载”延迟）

**无 DOM 的 javascript 将使用 WebGL/Canvas 与用户交互。目前这需要最少的 DOM，它定义了最初的 HTML5 Canvas，但理论上如果值得性能优势的话，可以通过修改技术来消除这种情况。假设回答时可以使用 DOM-less WebGL/Canvas。

编辑：我说的是客户端编译。