热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

不同的域但相同的IP,多个连接还是一个连接?-HTTP2:differentdomainbutsameIP,multipleconnectionoroneconnection?

WithinHTTP2:在HTTP2:Sowhenrequestonehtmlpage,withmultipledomains(www.example.com,api.exa

Within HTTP2:

在HTTP2:

So when request one html page, with multiple domains(www.example.com, api.example.com...), it is said, there will be multiple connections.

因此,当请求一个html页面时,有多个域(www.example.com, api.example.com…),会有多个连接。

but what if these domains share one same IP? Are there still multiple connections?

但是如果这些域名共享一个IP呢?还有多个连接吗?

2 个解决方案

#1


2  

That depends on the client.

这取决于客户。

http://httpwg.org/specs/rfc7540.html#HttpExtra

http://httpwg.org/specs/rfc7540.html HttpExtra

Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy.

客户端不应该打开一个以上的HTTP/2连接到给定的主机和端口对,其中主机来自URI、选择的替代服务[ALT-SVC]或配置的代理。

...

A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration.

客户端可以使用不同的服务器名称指示[TLS- ext]值打开同一个IP地址和TCP端口的多个连接,或者提供不同的TLS客户端证书,但是应该避免使用相同的配置创建多个连接。

...

Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address.

可以直接或通过使用CONNECT方法创建的通道对源服务器进行连接(第8.3节),可以使用多个不同URI权限组件的请求重用它们。只要源服务器是权威的,就可以重用连接(第10.1节)。对于没有TLS的TCP连接,这取决于主机解析到相同的IP地址。

So there's not really a hard requirement, so if a client has very good reasons for making multiple connections instead of reusing one it is allowed to do so.

所以没有硬性要求,所以如果客户端有很好的理由建立多个连接而不是重用一个,那么它就可以这么做。

Specially if both domains use a different TLS certificate (not one where both names are present as SubjectAltNames) I'd expect to see a separate connection for each.

特别是如果两个域都使用不同的TLS证书(而不是两个名称都作为subject - taltnames显示的证书),我希望看到每个域都有单独的连接。

#2


0  

As @mata says this is up to the client.

@mata说这取决于客户。

However one clear use case is in connection coalescing.

然而,一个清晰的用例是连接合并。

Under HTTP/1.1 domains were often sharded (e.g. www.example.com might also have a static.example.com domain for serving static assets). This was for two reasons:

在HTTP/1.1下,域通常是分片的(例如www.example.com也可能有一个用于服务静态资产的static.example.com域)。这有两个原因:

  1. To break the 6-8 connection limit per domain that browsers often used and allow more downloads in parallel.
  2. 为了打破浏览器经常使用的每个域的6-8连接限制,并允许更多的并行下载。
  3. To have so called "COOKIE-less" domains which saved on the overhead of sending these HTTP headers for static assets that didn't need them (e.g. images, css, Javascript).
  4. 有所谓的“无COOKIE”域,它节省了将这些HTTP头发送给不需要它们的静态资产(例如图像、css、Javascript)的开销。

Under HTTP/2 there is one connection and the limit on parallel downloads is the stream limit which is much higher (usually 100-150 though can also be unlimited). Additionally with HPACK header compression large COOKIEs cause less of a performance hit (though there can still be security issues which can be another reason for COOKIE-less domains).

在HTTP/2下有一个连接,并行下载的限制是流限制,后者要高得多(通常是100-150,但也可以是无限的)。此外,使用HPACK头压缩时,大型COOKIE会减少性能损失(尽管仍然存在安全问题,这可能是无COOKIE域的另一个原因)。

So, should we just give up on sharded domains completely now? What about those clients that cannot support HTTP/2? While support is very good it is not universal and those behind proxy connections (e.g. corporate connections or antivirus software) often cannot use this even if their browsers can.

那么,我们现在应该完全放弃共享域吗?那么那些不支持HTTP/2的客户机呢?虽然支持非常好,但它并不是通用的,而且代理连接(例如公司连接或杀毒软件)背后的人通常不能使用它,即使他们的浏览器可以。

Connection coalescing is used by browsers to collapse near identical connections (usually those with the same IP address and same TLS certificate) into one connection rather than opening a single one when using HTTP/2 and allows HTTP/1.1 connections to continue seeing these as separate domains. Daniel Haxx has the best blog post on how this is actually implemented by browsers(though it's about a year and a half old at the time of writing so this may have changed). To summarise it, Chrome uses it as you'd expect, Firefox is (overly?) aggressive about coalescing in as many circumstances as it can (and maybe some that it shouldn't!) and Edge and Safari don't do coalescing at all.

浏览器使用连接合并将几乎相同的连接(通常是具有相同IP地址和相同TLS证书的连接)合并到一个连接中,而不是在使用HTTP/2时打开一个连接,并允许HTTP/1.1连接继续将这些连接视为独立的域。Daniel Haxx有一篇关于浏览器是如何实现这一功能的最好的博客文章(尽管写这篇文章的时候已经有一年半的时间了,所以可能已经发生了变化)。总而言之,Chrome按照你所期望的那样使用它,Firefox在尽可能多的情况下(也许有些情况下它不应该这么做)积极地进行合并,而Edge和Safari根本就没有合并。

If a connection is coalesced when it shouldn't be, the server can respond with a 421 HTTP Status code which basically means "What are you doing, that's not a request for me!!" and the browser can then try again with a separate connection.

如果连接不应该被合并,服务器可以使用421 HTTP状态码进行响应,这基本上意味着“您在做什么,这不是我的请求!”,然后浏览器可以再次尝试使用一个单独的连接。

It also looks like that HTTP/2 will shortly add the ORIGIN Frame which will allow the server to respond to any request with a "hey, I can also serve you api.example.com requests if you want" style message. Even if the IP address doesn't match (which has some people concerned about the security implications of that!).

看起来HTTP/2很快就会添加源框架,允许服务器以“嘿,如果你想要的话,我也可以为你提供api.example.com请求”样式消息来响应任何请求。即使IP地址不匹配(这让一些人担心它的安全影响!)

While we're on the topic, it's not always the case that as single domain will always use one connection either. Read Jake Archibald's excellent post on HTTP/2 Push which shows that there are various circumstances when that's not the case (summarised as: for non-credentialed requests, when having the same domain open in a separate tab in Edge, or randomly even on the same tab for Safari).

虽然我们在讨论这个主题,但并不总是单个域总是使用一个连接。请阅读Jake Archibald在HTTP/2 Push上发表的优秀文章,该文章显示,当情况并非如此时,会出现各种各样的情况(总结为:对于未认证的请求,当同一域在Edge的另一个选项卡中打开时,或者在Safari的同一个选项卡上随机打开时)。


推荐阅读
  • 在寻找轻量级Ruby Web框架的过程中,您可能会遇到Sinatra和Ramaze。两者都以简洁、轻便著称,但它们之间存在一些关键区别。本文将探讨这些差异,并提供详细的分析,帮助您做出最佳选择。 ... [详细]
  • 本题要求在一组数中反复取出两个数相加,并将结果放回数组中,最终求出最小的总加法代价。这是一个经典的哈夫曼编码问题,利用贪心算法可以有效地解决。 ... [详细]
  • MySQL 数据库迁移指南:从本地到远程及磁盘间迁移
    本文详细介绍了如何在不同场景下进行 MySQL 数据库的迁移,包括从一个硬盘迁移到另一个硬盘、从一台计算机迁移到另一台计算机,以及解决迁移过程中可能遇到的问题。 ... [详细]
  • 本文详细介绍了中央电视台电影频道的节目预告,并通过专业工具分析了其加载方式,确保用户能够获取最准确的电视节目信息。 ... [详细]
  • 探讨如何真正掌握Java EE,包括所需技能、工具和实践经验。资深软件教学总监李刚分享了对毕业生简历中常见问题的看法,并提供了详尽的标准。 ... [详细]
  • 本文介绍了如何使用JavaScript的Fetch API与Express服务器进行交互,涵盖了GET、POST、PUT和DELETE请求的实现,并展示了如何处理JSON响应。 ... [详细]
  • 深入解析Java虚拟机(JVM)架构与原理
    本文旨在为读者提供对Java虚拟机(JVM)的全面理解,涵盖其主要组成部分、工作原理及其在不同平台上的实现。通过详细探讨JVM的结构和内部机制,帮助开发者更好地掌握Java编程的核心技术。 ... [详细]
  • 深入解析SpringMVC核心组件:DispatcherServlet的工作原理
    本文详细探讨了SpringMVC的核心组件——DispatcherServlet的运作机制,旨在帮助有一定Java和Spring基础的开发人员理解HTTP请求是如何被映射到Controller并执行的。文章将解答以下问题:1. HTTP请求如何映射到Controller;2. Controller是如何被执行的。 ... [详细]
  • 在高并发需求的C++项目中,我们最初选择了JsonCpp进行JSON解析和序列化。然而,在处理大数据量时,JsonCpp频繁抛出异常,尤其是在多线程环境下问题更为突出。通过分析发现,旧版本的JsonCpp存在多线程安全性和性能瓶颈。经过评估,我们最终选择了RapidJSON作为替代方案,并实现了显著的性能提升。 ... [详细]
  • PostgreSQL 最新动态 —— 2022年4月6日
    了解 PostgreSQL 社区的最新进展和技术分享 ... [详细]
  • 由二叉树到贪心算法
    二叉树很重要树是数据结构中的重中之重,尤其以各类二叉树为学习的难点。单就面试而言,在 ... [详细]
  • 探讨ChatGPT在法律和版权方面的潜在风险及影响,分析其作为内容创造工具的合法性和合规性。 ... [详细]
  • CentOS 6.8 上安装 Oracle 10.2.0.1 的常见问题及解决方案
    本文记录了在 CentOS 6.8 系统上安装 Oracle 10.2.0.1 数据库时遇到的问题及解决方法,包括依赖库缺失、操作系统版本不兼容、用户权限不足等问题。 ... [详细]
  • 本文探讨了在iOS平台上开发BLE(蓝牙低功耗)应用程序时遇到的挑战,特别是如何实现应用在后台模式下仍能持续扫描并连接蓝牙设备。文章提供了具体的配置方法和常见的问题解决方案。 ... [详细]
  • Microsoft即将发布WPF/E的CTP(Community Technology Preview)和SDK,标志着RIA(Rich Internet Application)技术的新里程碑。更多详情及下载链接请参见MSDN官方页面。 ... [详细]
author-avatar
田得婕_762
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有