第十四章 浏览器网络入门(Primer on Browser Networking)

现代浏览器是用于快速，高效和安全地交付Web应用程序而专门设计的平台。实际上，现代的浏览器实际上是一个包含数百个组件的完整操作系统：进程管理，安全沙箱，优化缓存层，JavaScript VM，图形渲染和GPU管道，存储，传感器，音频和视频，网络，以及更多。

毫不奇怪，浏览器及其运行的任何应用程序的整体性能由许多组件决定：解析(parsing)，布局(layout)，HTML和CSS的样式计算，JavaScript执行速度，渲染管道，当然还有网络栈。每个组件都起着至关重要的作用，但是网络通常会更加重要，因为如果浏览器在网络上被阻塞，去等待资源到达，那么所有其他步骤都将被阻塞！

因此，发现现代浏览器的网络栈远不只是简单的套接字管理器(socket manager)就不足为奇了。从外部看，它可能表现为一种简单的资源获取机制(resource-fetching mechanism)，但从内部看，它是它自己的平台（图14-1），具有自己的优化标准，API和服务。

设计Web应用程序时，我们不必担心单个的TCP或UDP Sockets； 浏览器会为我们管理。此外，网络栈还负责施加正确的连接限制(connection limits)，格式化请求，将各个应用程序相互沙箱化，处理代理(proxies)，缓存(caching)等等。 进而在消除了所有这些复杂性之后，我们的应用程序可以专注于应用程序逻辑。

如我们所见，了解TCP，HTTP和移动网络(mobile networks)的性能特征可以帮助我们构建更快的应用程序。 同样，了解如何对浏览器的各种网络API、协议和服务进行优化，可以使任何应用程序的性能产生巨大差异。

连接管理和优化(Connection Management and Optimization)

在浏览器中运行的Web应用程序无需管理单个网络Sockets的生命周期，这是一件好事。 通过将这项工作交给浏览器，我们使它能够自动化许多关键的性能优化，例如Sockets重用、请求优先级设置和后期绑定(late binding)、协议协商(protocol negotiation)、强制执行连接限制(enforcing connection limits)等等。 实际上，浏览器有意将请求管理(request management)的生命周期与Sockets管理分开。这是一个微妙但关键的特点。

Sockets按池进行组织（图14-2），这些池按来源分组，每个池强制执行自己的连接限制和安全性约束。 将待处理的请求(Pending requests)排入队列，确定优先级，然后绑定到池中的各个Sockets。因此，除非服务器有意关闭连接，否则同一Socket可以在多个请求之间自动重用！

来源
应用协议，域名和端口号的三元组-例如（http，www.example.com，80）和（https，www.example.com，443）被认为是不同的来源。

Socket池
一组Socket属于同一来源。 实际上，所有主流浏览器都将池的大小限制为六个Socket。

自动化Socket池可自动执行TCP连接重用，从而带来显着的性能优势；请参见Benefits of Keepalive Connections。 但是，这还不是全部。该体系结构还带来了许多其他优化机会：

• 浏览器可以按优先级顺序处理排队的请求。
• 浏览器可以重用Socket，以最大程度地减少延迟并提高吞吐量。
• 浏览器可以在预期到请求时主动打开Socket。
• 浏览器可以在空闲Socket关闭时进行优化。
• 浏览器可以优化所有Socket上的带宽分配。

简而言之，浏览器网络栈是我们追求交付高性能应用程序的战略盟友。我们涵盖的功能都不需要代表我们做任何工作！但是，这并不是说我们不能为浏览器提供帮助。我们应用程序中的设计决策将决定网络通信模式、传输的类型和频率、协议的选择以及服务器堆栈的调整和优化，这对每个应用程序的最终性能都起着至关重要的作用。

Google Chrome中的投机网络优化
我们已经确定，现代浏览器的网络栈不仅仅是简单的Socket管理器。但是，即使那样也不能完全代表现代浏览器执行的某些优化技术。

例如，当您使用Chrome浏览器时，它会变得更快。 Chrome会了解访问过的网站的拓扑结构和典型的浏览模式，然后利用这些信息执行各种“推测性优化”，以预测用户可能的操作并消除不必要的网络延迟：DNS预先解析，TCP预先连接，页面预先渲染等等。简单的动作（例如，鼠标悬停在链接上）可以触发从浏览器到网络栈“预测器”的信号，然后可以根据过去的性能数据选择最佳优化！

更多详细信息，请参见我们先前有关Browser Optimization的讨论。如果您想了解更多有关Chrome网络优化的信息，请查看“ High Performance Networking in Google Chrome”。

网络安全和沙箱(Network Security and Sandboxing)

推迟对各个Socket的管理还有另一个重要目的：它允许浏览器对不可信的应用程序代码进行沙箱管理，并实施一组一致的安全性和策略约束。 例如，浏览器不允许直接API访问原始网络Sockets，因为这将允许恶意应用程序发起与任何主机的任意连接，例如，运行端口扫描(port scan)，连接到邮件服务器并开始发送意外消息。

• 连接限制(Connection limits)
  浏览器管理所有打开的Socket池，并强制执行连接限制以保护客户端和服务器免受资源耗尽。
• 请求格式化和响应处理(Request formatting and response processing)
  浏览器格式化所有传出的请求，以强制执行一致且格式正确的协议语义以保护服务器。 同样，响应解码会自动完成，以保护用户免受恶意服务器的攻击。
• TLS协商(TLS negotiation)
  浏览器执行TLS握手，并对证书执行必要的验证检查。 当验证失败时，例如，服务器正在使用自签名证书，都会向用户发出警告。
• 同源策略(Same-origin policy)
  浏览器对应用程序可以发起哪些请求以及请求源进行限制。

上述列表并不完整，但是强调了工作中“最低特权”的原则。 浏览器仅公开应用程序代码必需的API和资源：应用程序提供数据和URL，浏览器格式化请求并处理每个连接的整个生命周期。

值得注意的是，没有单一的“同源策略”。 相反，有一组相关的机制对DOM访问，cookie和会话状态管理，网络以及浏览器的其他组件实施限制。
有关浏览器安全性的完整讨论需要单独编写。 如果您好奇的话，Michal Zalewski的《 The Tangled Web: A Guide to Securing Modern Web Applications 》是一个很棒的资源。

资源和客户端状态缓存(Resource and Client State Caching)

最好和最快的请求是未提出请求。 在分派请求之前，浏览器会自动检查其资源缓存，执行必要的验证检查，并在满足指定约束的情况下返回资源的本地副本。 同样，如果本地资源在缓存中不可用，则会发出网络请求，并且如果允许的话，响应会自动放置在缓存中以供后续访问。

• 浏览器会自动评估每个资源上的缓存指令。
• 浏览器会在可能时自动重新验证过期的资源。
• 浏览器自动管理缓存的大小和资源逐出。

管理高效且优化的资源缓存非常困难。 幸运的是，浏览器代表我们处理了所有复杂性，我们要做的就是确保我们的服务器返回适当的缓存指令；请参阅Cache Resources on the Client。 您正在为页面上的所有资源提供Cache-Control，ETag和Last-Modified响应标头，对吗？

将会话状态管理推迟到浏览器的好处：可以在多个选项卡或浏览器窗口之间共享经过身份验证的会话，反之亦然； 单个选项卡中的注销操作将使所有其他打开的窗口中的打开会话无效。

应用程序APIS和协议(Application APIs and Protocols)

沿着所提供的网络服务的阶梯前进，我们终于到达了应用程序API和协议。如我们所见，较低的层提供了广泛的关键服务：socket和连接管理、请求和响应处理、各种安全策略的实施、缓存等等。每次我们启动HTTP或XMLHttpRequest、长期的服务器发送事件或WebSocket会话、或打开WebRTC连接时，我们都会与其中的一些或全部基础服务进行交互。

没有最好的协议或API。每个不平凡的应用程序都需要根据各种需求混合使用各种传输：与浏览器缓存的交互、协议开销、消息延迟、可靠性、数据传输的类型等等。某些协议可能提供低延迟交付（例如，服务器发送事件，WebSocket），但可能不满足其他关键条件，例如在所有情况下都可以利用浏览器缓存或支持有效的二进制传输。

	XMLHttpRequest	Server-Sent Events	WebSocket
Request streaming	no	no	yes
Response streaming	limits	yes	yes
Framing mechanism	HTTP	event stream	binary frame
Binary data transfers	yes	no(base 64)	yes
Compression	yes	yes	limited
Application transport protocol	HTTP	HTTP	WebSocket
Network transport protocol	TCP	TCP	TCP

我们有意将WebRTC排除在此比较之外，因为它的点对点交付模型与XHR，SSE和WebSocket协议大相径庭。

这些高级功能的比较是不完整的（这是以下各章的主题），但可以很好地说明每种协议之间的许多差异。 了解每个优点和缺点并进行权衡，使其与我们的应用程序需求相匹配，使得高性能应用程序改善用户持续糟糕的体验。