浏览器网络入门

本文参考 High Performance Browser Networking，获取更多详细内容请查看原文。

现代浏览器的设计旨在为Web应用程序提供快速、高效和安全的运行环境。实际上，它们就像一个功能齐全的操作系统，由多个重要组件相互协作：从进程管理到安全隔离，从缓存优化到JavaScript引擎，再到图形渲染和网络交互。

因此，浏览器的整体性能不仅依赖于页面的解析、布局和样式计算，还与JavaScript执行效率、渲染流程及网络通信息息相关。尤其是网络，因其一旦出现阻塞，整个应用的运作都会受到影响。

正因如此，现代浏览器的网络层次远不止于基本的套接字管理。从表面上看，它似乎只是一个资源获取机制，但在内部，它其实是一个复杂的生态系统，拥有独特的优化标准、API和服务功能。

设计Web应用时，开发者无需深入到TCP或UDP的细节，浏览器会全权负责此类操作。此外，网络层还会自动施加适当的连接约束、格式化请求、管理请求之间的隔离、处理代理和缓存等多个方面。这种复杂性的处理使得开发者可以更加专注于应用的核心逻辑。

然而，懂得这些机制并不意味着可以忽视它们。通过对TCP、HTTP及移动网络性能的充分理解，开发者能够构建出更为高效的应用。同时，优化与各种浏览器网络API和协议的交互也能够显著提升应用性能。

Web应用在浏览器中运行时，不需直接管理每个网络套接字，这种设计带来了显著的好处。浏览器借助内部机制自动化了一系列关键的性能优化，例如重用套接字、调整请求优先级、延迟绑定、协议协商及强制连接限制等。这种设计理念的实现使得请求管理与套接字管理成为两个独立的流程。

这些套接字被组织在按来源划分的池中，浏览器为每个池强制实施连接和安全限制。这样，待处理请求会被排队和优先排序后绑定到现有的套接字上。因此，同一个套接字可以处理多个请求，前提是服务器不会主动关闭连接。

起源

应用程序协议和域名组合构成了不同的起源。例如，(http，www.example.com，80)与(https，www.example.com，443)就被视为不同来源。

套接字池

属于同一源的套接字组。多数主流浏览器会将每个源的最大池大小限制在六个套接字。

自动化的套接字池机制使得TCP连接的重用得以无缝化，带来了显著的性能提升。同时，这样的架构还带来了更多的优化机会：

总而言之，浏览器网络层的设计是我们追求高性能Web应用的得力助手。虽然这些功能的实现并不需要我们直接干预，但是设计决策如网络通信方式、传输类型及协议的选择在最终性能上扮演着关键的角色。

将套接字管理的职责移交给浏览器还带来了另一项重要益处：能够实施一致的安全策略，将不受信任的代码隔离。例如，浏览器会限制外部代码直接访问网络套接字，防止那些潜在的恶意行为，比如执行扫描或向外部主机发送未经授权的请求等。

连接约束

浏览器负责管理套接字池并强制连接限制，以免造成资源的耗尽危机。

请求格式化与响应处理

所有外发请求都会在浏览器中进行格式化，以确保请求遵从一致的协议结构，从而保护服务器免受不当请求。类似地，响应内容的解码也是自动执行，旨在保护用户免遭恶意服务器的攻击。

TLS协商

浏览器会负责TLS握手过程，并验证SSL证书的有效性，若验证失败，用户会被及时警告，如使用了自签名证书的情况。

同源策略

同源策略限制了应用程序发起请求的来源，此机制要比单一的“主域同源策略”更加复杂，有着多种机制同时发挥作用。

如需全面了解浏览器的安全性，推荐查阅Michal Zalewski的《The Tangled Web: A Guide to Secure Modern Web Applications》，将为您提供深入的见解。

发送未发出的请求才是最迅速、最有效的方案。在请求发起之前，浏览器会自动检查本地的资源缓存，执行必要的验证，若条件满足则返回本地副本；若未找到缓存资源，则会发出网络请求，且响应会被自动缓存以备后续使用。

浏览器将会自动评估资源的缓存指令，并在必要时进行重新验证过期的资源。

管理资源缓存是复杂且不易的，因此借助浏览器处理这一过程显得尤为重要。开发者需确保响应中包含适当的缓存指令，如缓存控制、ETag和Last-Modified等信息。

此外，浏览器的一个关键功能是有效管理身份验证、会话及cookie。每个来源都有独立的cookie管理区，浏览器为我们简化了新cookie、会话及认证数据的读写，通过自动化HTTP头的处理减轻了我们的负担。

这样的设计使得经过身份验证的会话可在多个标签页之间共享，而注销动作也会使所有窗口中的会话失效。

在网络服务架构中，上层则是应用程序API及协议。较低的层提供了一系列的服务，例如套接字管理、请求与响应处理、固有的安全策略执行及缓存等。在发起HTTP请求、XMLHttpRequest或WebSocket连接时，实际上是在与这些基础服务互动。

并没有单一最佳的协议或API。对于每个应用，需要根据具体需求选取合适的传输方式，平衡协议开销、消息延迟、可靠性等因素。某些协议如服务器发送事件提供低延迟交付，但在利用浏览器缓存方面可能不足。以下是几种关键协议的比较：

不同协议各有优劣，了解这些差异、权衡优势与劣势，并将其与应用需求相匹配，是高性能应用和糟糕用户体验之间的关键所在。