英文:
HTTP/3 Server using Jetty 11 not responding
问题
我正在尝试使用Jetty 11和Java 11(作为实验)实现一个HTTP/3测试服务器。我正在按照文档中的代码进行操作:文档链接。
以下是您提供的Java代码片段:
public class HTTP3Server {
public static void main(String[] args) {
// ...(代码部分,不提供翻译)
}
}
有关HTTP/3的问题,您列出了以下信息:
- 密钥库在HTTP/1.1或HTTP/2中正常工作(在HTTP/3中是否需要不同的操作?)。
/var/www/index.html
存在。- 服务器在启动时没有警告或错误信息。
- UDP端口3443似乎是打开的(而TCP端口3443是关闭的)。
最后,尝试在Chrome中打开 https://localhost:3443/ 失败,没有服务器日志中的任何活动。
请问您有关于这些问题的具体问题或需要哪些方面的帮助?
英文:
I'm trying to implement a HTTP/3 test server using Jetty 11 with Java 11 (as experiment). I'm following the code in the documentation:
public class HTTP3Server {
public static void main(String[] args) {
Server server = new Server();
// The SSL Context
SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
sslContextFactory.setKeyStorePath("/etc/java/keystore.jks");
sslContextFactory.setKeyStorePassword("password");
// The HTTP configuration object
HttpConfiguration httpConfig = new HttpConfiguration();
SecureRequestCustomizer src = new SecureRequestCustomizer();
src.setSniHostCheck(false);
httpConfig.addCustomizer(src);
// Create and configure the HTTP/3 connector.
HTTP3ServerConnectionFactory h3Factory = new HTTP3ServerConnectionFactory(httpConfig);
HTTP3ServerConnector connector = new HTTP3ServerConnector(server, sslContextFactory, h3Factory);
connector.setPort(3443);
server.addConnector(connector);
// Create and configure a ResourceHandler.
ResourceHandler handler = new ResourceHandler();
// Configure the directory where static resources are located.
handler.setBaseResource(Resource.newResource("/var/www/"));
// Configure directory listing.
handler.setDirectoriesListed(false);
// Configure welcome files.
handler.setWelcomeFiles(new String[]{"index.html"});
// Configure whether to accept range requests.
handler.setAcceptRanges(true);
server.setHandler(handler);
// Start server
server.start();
}
}
- The keystore works fine when used in HTTP/1.1 or HTTP/2 (do I need to do anything different for HTTP/3 here?).
/var/www/index.html
exists.- The server is launched without warnings or errors:
2023-05-25 10:31:06.305:INFO :oejs.Server:main: jetty-11.0.15; built: 2023-04-11T18:37:53.775Z; git: 5bc5e562c8d05c5862505aebe5cf83a61bdbcb96; jvm 11.0.19+7-post-Ubuntu-0ubuntu122.04.1
2023-05-25 10:31:06.338:INFO :oejhs.HTTP3ServerConnector:main: HTTP/3+QUIC support is experimental and not suited for production use.
2023-05-25 10:31:06.623:INFO :oejus.SslContextFactory:main: x509=X509@4af0df05(localhost,h=[icl test],a=[],w=[]) for Server@674bd420[provider=null,keyStore=file:///etc/java/keystore.jks,trustStore=null]
2023-05-25 10:31:06.661:INFO :oejs.AbstractConnector:main: Started HTTP3ServerConnector@4bd31064{h3, (h3)}{0.0.0.0:3443}
2023-05-25 10:31:06.733:INFO :oejs.Server:main: Started Server@30c93896{STARTING}[11.0.15,sto=0] @1189ms
- The UDP port 3443 seems open (while TCP port 3443 is closed):
PORT STATE SERVICE
3443/udp open|filtered ov-nnm-websrv
I'm not sure if that is expected or not.
- Finally, opening https://localhost:3443/ in Chrome fails as if it doesn't exists (no activity is registered in the server logs).
What do I need to do to make it work?
答案1
得分: 2
抱歉,以下是您要求的翻译内容:
"Jetty's HTTP3Client
可以与诸如Google等的HTTP/3服务器通信。同样,Jetty的HTTP3Client
可以与Jetty的HTTP/3服务器通信。因为Jetty对HTTP/3的实现在客户端和服务器之间共享,所以人们可能认为让浏览器与Jetty的HTTP/3服务器通信应该很容易。
然而,每个浏览器都有一个我所知道需要反向工程的秘密配方,而且每个配方都不同。
例如,浏览器经常拒绝自签名的证书,因此您的服务器必须具有CA签名的证书,以便与浏览器一起使用合法的域名。
此外,浏览器通常不允许HTTP/3通信在443端口之外的其他端口上,因此您必须以管理员/根权限启动服务器。我们还相信所协商的密码的强度起了一定作用。
还有更多:浏览器不会通过QUIC建立第一次直接通信。它们首先尝试使用HTTP/2,如果服务器宣布支持HTTP/3,那么浏览器可能会切换到使用HTTP/3。但是不清楚切换的具体策略,例如是否需要HTTP/2 ALTSVC帧,或者Alt-Svc
头是否足够,或者是否两者都需要。
总之,这将是一项艰巨的任务,即使揭示了一个浏览器的秘密,也不一定适用于其他浏览器。
Jetty团队致力于发现并记录至少一个秘密配方,但到目前为止我们一直没有成功。
我个人会非常高兴,如果知道某个浏览器的秘密配方的人愿意分享,但目前可用的信息似乎很有限,而且经常过时。
英文:
I'm afraid it is much more complicated than that, unfortunately.
Jetty's HTTP3Client
can communicate with HTTP/3 servers such as Google and others.
In the same way, Jetty's HTTP3Client
can communicate with Jetty's HTTP/3 server.
Because Jetty's implementation of HTTP/3 is shared between client and server, one would think it is a breeze to make a browser talk to a Jetty HTTP/3 server.
However, each browser has a secret sauce that (to my knowledge) needs to be reverse engineered, and each sauce is different.
For example, it is quite common that browsers refuse self-signed certificates, so your server must have a CA-signed certificate for a legit domain in order to work with a browser.
Furthermore, it is also common that browsers do not allow HTTP/3 communication other than on port 443, so you must start your server with admin/root privileges.
We also believe that the strength of the ciphers negotiated plays a role.
There's more: browser do not establish a first direct communication via QUIC.
They first try HTTP/2, and if the server announces support for HTTP/3, then the browser may switch to use HTTP/3.
However, it is unclear what is exactly the policy to switch, for example whether a HTTP/2 ALTSVC frame is necessary, or the Alt-Svc
header is enough, or if both are required.
Bottom line, it is going to be a daunting task, and even if the secret is unveiled for one browser, it may not work for other browsers.
The Jetty team is committed to discover and document at least 1 secret sauce, but so far we have been unsuccessful.
I for one would be very happy if someone knowing a browser's secret sauce would share it, but the information out there seems sparse and often outdated.
We will insist and find it, eventually.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论