URL 如何转换为 TCP/IP 请求？

Question

最近，一位同事告诉我，第三方可以看到 HTTPS GET 请求的查询字符串，我开始证明他是错的。但是找到任何明确的 URL 解析描述是很困难的。

我的理解是 URL 只是零碎发送，域传递到 IP 标头，端口传递到 TCP 标头等。在 HTTPS GET 的特殊情况下，这意味着查询字符串将只驻留在 HTTP 标头中，它又位于 TLS 正文中，它是端到端加密的，因此是安全的。

那么，我的问题是双重的：

• 首先，我对 HTTPS GET 查询字符串的特殊情况是否正确？
• 其次，任何人都可以向我提供一个 URL 的总体剖析，并着眼于它的部分如何转换为 TCP/IP 请求？

Answer 1

首先，在使用 HTTPS 时，您对在传输过程中受到保护的查询字符串是正确的。已经有很多关于此的问题，例如this one。本质上，HTTPS 是基于 SSL/TLS 的 HTTP，因此在发送任何 HTTPS 流量之前设置 SSL/TLS 连接。（可能可见的是主机名，在 TLS 的服务器名称指示扩展中，或者这可能会被 DNS 请求泄露。）

其次，当您向 发出 GET 请求时https://host.example:port/something?blabla=1，以下是所发生情况的概述：

• 您的浏览器会host.example在该端口上建立 TCP 连接。
• 由于它是一个https://URL，因此建立了 SSL/TLS 连接。SSL/TLS 堆栈应该验证证书，并且它与您要查找的主机名匹配。

• 在此 SSL/TLS 连接之上（使用普通 HTTP 时，它将直接位于 TCP 连接之上），您的浏览器会发送如下内容：

  GET /something?blabla=1 HTTP/1.1
  Host: host.example:port
  .... (other headers)
  

  所有这些都是通过 SSL/TLS 发送的。请注意，严格来说，查询参数是 URL 的组成部分，在 中发送，而Request-Line不是在头中发送。

您可以在RFC 2616（最近被取代）中找到有关 HTTP 的详细信息，并在RFC 2818 中找到有关 HTTPS 的详细信息。