http connection lifecycle下载 - http connection lifecycle源码下载

http connection lifecycle

其他类别

1.0.0

下载

HTTP 连接生命周期

动机
开放系统互连模型
连接
- 第 1 步：解析 URL
- 步骤 2：DNS（地址解析）
- 第 3 步：构建 TCP/IP 数据包
- 步骤 4：连接到网关 (ARP)
- 第 5 步：路由器和 NAT
- 第 6 步：通过互联网路由
- 第7步：3次握手
- 第 8 步：TLS 握手
- 第 9 步：处理请求
- 第10步：关闭连接
参考

动机

在技术面试或其他方面，一个常见的问题是当您在浏览器中输入 URL 时会发生什么？当您浏览网站时，幕后会发生什么？典型的 HTTP 连接生命周期需要什么？我将尽我所知回答这些问题。

开放系统互连模型

在深入研究连接过程之前，我们先回顾一下基本的 OSI 模型（开放系统互连模型）。 OSI 模型是一种概念模型，它标准化了两个系统之间的通信 - 一个是发出请求的系统（客户端），另一个是服务请求并发送回响应的系统（服务器）。下表显示了每层的一些重要特征。

不	层	硬件	功能	协议/应用程序	补充内容
7	应用	服务器/电脑	应用程序、用户界面	HTTP、SMTP、DNS	L7 接头
6	推介会	服务器/电脑	处理加密和语法更改	JPEG、MP3	L6 接头
5	会议	服务器/电脑	身份验证、权限、会话	SCP、操作系统调度	L5 接头
4	运输	防火墙	端到端交付、错误控制	TCP、UDP	L4 接头
3	网络	路由器	网络寻址、路由、交换	知识产权	L3 标头
2	数据链	开关	物理地址、错误检测、流程	以太网、帧中继	L2 头/尾
1	身体的	电缆	通过物理网络传输的比特	环境影响评估/TIA	L1 标头

连接

第1步：解析URL

一旦您在浏览器中输入 URL 并按 Enter/Return 键，浏览器（或任何与此相关的客户端）就会解析 URL [1] 以从中提取重要的组件。下面给出了一个示例 URL：

https://www.google.com/search?q=cats

这里我们只是在谷歌上搜索猫。从上面的 URL 来看， https://是协议， google.com是www （互联网）上的主机， /search是路径参数， ?q=cats是查询字符串参数，表示我们正在 Google 中查询猫 [ 2]。

步骤 2：DNS（地址解析）

现在，由于浏览器知道它试图访问的主机（在本例中google.com ，它将尝试获取其相应的 IP 地址。创建“ .com”或“ .org”等域名是为了让我们可以轻松记住它们。但浏览器要向 google.com 发送实际请求，它需要主机的 IP 地址。 DNS 解析帮助我们获取给定域名的 IP 地址信息。从上表来看，DNS 驻留在应用程序层 (L7)。

DNS解析步骤：

浏览器首先检查其本地浏览器缓存，查看域名到 IP 地址的映射是否已存在。 DNS 中的每条记录都有一个 TTL 值，该记录仅保留在缓存中，直到 TTL 到期时间，之后必须再次获取该记录。
如果浏览器缓存中不存在该记录，DNS 解析器将检查操作系统级缓存。操作系统为最近由该计算机上的不同客户端（如浏览器）浏览的网站保留自己的 DNS 解析缓存。在本地计算机上，可以通过在 Windows 上使用命令$ ipconfig /displaydns或在 mac/linux 上使用$ log stream --predicate 'process == "mDNSResponder"' --info命令来检查 DNS 缓存。
如果该记录不在操作系统缓存中，则会检查 DNS 记录是否存在于 Internet 服务提供商 (ISP) 维护的缓存中。
如果即使在 ISP 级缓存中也不存在该记录，则会通过 Internet 向 DNS 服务器进行查询。在这种情况下，由于查询路由到本地网络之外，因此必须经历 ARP（和 NATting）过程和实际网络路由，如下所述。 DNS 查询可以是递归类型（递归查询服务器直到找到答案）、迭代类型（获取查询的最佳主机，但可能不是最终答案）或非递归类型（其中 DNS 知道它立即返回的答案）。该查询是通过端口 53 上的 UDP 协议进行的。
- 如果查询是递归类型，DNS 解析器将首先访问根 DNS 服务器。根服务器将返回 TLD 名称服务器的 IP 地址。
- 现在针对 TLD 服务器（顶级域服务器）进行查询。这里的.com 、 .org等都是顶级域名。然后，TLD 名称将返回权威名称服务器的 IP 地址。
- 然后，权威名称服务器具有与该域名相对应的IP地址。

$ dig google.com

; << >> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             180     IN      A       172.217.164.174

;; AUTHORITY SECTION:
google.com.             60552   IN      NS      ns1.google.com.
google.com.             60552   IN      NS      ns2.google.com.
google.com.             60552   IN      NS      ns3.google.com.
google.com.             60552   IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         60438   IN      A       216.239.32.10
ns1.google.com.         58273   IN      AAAA    2001:4860:4802:32::a
ns2.google.com.         60438   IN      A       216.239.34.10
ns2.google.com.         131763  IN      AAAA    2001:4860:4802:34::a
ns3.google.com.         163770  IN      A       216.239.36.10
ns3.google.com.         60541   IN      AAAA    2001:4860:4802:36::a
ns4.google.com.         75597   IN      A       216.239.38.10
ns4.google.com.         60541   IN      AAAA    2001:4860:4802:38::a

;; Query time: 13 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Mon Jun 24 12:20:50 PDT 2019
;; MSG SIZE  rcvd: 303

第 3 步：构建 TCP/IP 数据包

在 OSI 模型的每一层，信息被称为 PDU（分组数据单元）。因此，应用层的信息称为 L7 PDU，而网络层的信息称为 L3 PDU。在每一层，都会添加相应的层头。标头位于其主体之前，包含寻址和到达预期目的地所需的其他数据。另一方面，数据从最顶层向下传递。 L4、L3 和 L2 标头如下所示：

图片/ip_packet.png

图片/tcp_packet.png

图片/data_link_header_pdu.png

步骤 4：连接到网关 (ARP)

在数据包发送到互联网并最终到达谷歌域服务器之前，它首先需要通过路由器进行路由。每当一个设备需要物理连接到另一个设备（在本例中为本地路由器）时，它就需要该设备的 MAC 地址（硬件地址）。但是本地机器如何知道路由器是默认路由呢？此信息是通过本地计算机内每个接口设置的默认路由获取的。您可以使用$ ifconfig命令检查默认路由。

IP地址用于定位网络上的设备，而MAC地址用于识别实际设备。 ARP 协议用于在已知 IP 地址的情况下获取设备的 MAC 地址。这里我们假设请求的机器已经收到一个 IP 地址（静态的或通过 DHCP 协议）。

ARP 驻留在 OSI 模型的数据链路层。在这种情况下，本地计算机上运行的 Web 浏览器将连接到作为互联网网关的路由器。

首先，计算机检查其称为 ARP 缓存的内部链接，看看它是否具有要连接的设备的 MAC 地址。可以在本地机器的终端上使用arp -a命令检查 ARP 表。
如果本地缓存中没有 ARP 解析，源计算机将生成地址解析协议 (ARP) 请求消息并发送自己的 IP 和 MAC 地址。然后源将 ARP 请求消息广播到本地网络。
由于该消息是广播，因此 LAN 上的每个设备都会收到该消息。每个设备都会比较它们的 IP 地址，不匹配的设备将丢弃数据包而不采取任何操作。 IP 地址与请求中的 IP 地址匹配的设备将生成带有自己的 MAC 地址的 ARP 应答消息。然后它将发送一条回复消息，并且它不会是广播，而是单播。
源计算机将处理来自目标的 ARP 回复，它将发送者硬件地址存储为目标的第 2 层地址，然后更新其 ARP 缓存。

第 5 步：路由器和 NAT

然后数据包被路由到默认路由。如果没有设置默认路由，它们将被路由到路由器。可以使用命令查看默认路由

route get default | grep gateway或netstat -rn (mac/linux) 或ipconfig (windows)。

例如，如果您位于 192.168.10.0/24 网络上并尝试通过 172.217.164.174/24 到达 Google 网络，例如当数据包到达路由器时，路由器将检查路由表并决定如何将流量路由到到达目的网络。因此，它将把数据包发送到指定的网关，以到达目的地 172.217.164.174/24

第 6 步：通过互联网路由

客户端与服务器端的连接；在这种情况下，您的本地计算机到 Google 服务器需要经过很多跳。每一跳本质上是通往目的地的路径上的一个路由器。这里的路由器帮助请求从一个网络传输到另一个网络。途中的每个设备都有一个全球唯一的 MAC 地址（硬件地址）。

现在，本地计算机创建带有 L7 标头 (HTTP)、L4 标头 (TCP)、L3 标头 (IP)、L2 标头（ARP、MAC 地址）、L2 尾部（帧检查序列）和实际数据的请求。当路由器收到数据包时，它会解封装、修改 L2 头/尾并再次封装该数据包。

路由器现在接收它并开始解封装。它查看 L2 标头并发现目标 mac 是给它自己的。现在它删除了 L2 标头，现在查看 L3 标头并了解该请求不是针对其自身，而是针对 Google 服务器。然后路由器递减 L3 标头内的 TTL 值。路由器现在会在其路由表中查找其他路由器可能已向该路由器（通过 RIP 或 IGP）通告的所有可能路由，以了解如何到达目的地。如果路由器的缓存中没有 MAC 地址，则路由器会执行 ARP 来获取下一跳路由器的 MAC 地址。

然后，路由器还会添加 CRC，该 CRC 会继续到 L2 尾部。这有助于下一个路由器知道路由上没有发生导致数据包在网络上损坏的问题。如果它已损坏，则会丢弃该帧。

在这种情况下，路由器修改了 L2 标头和 L2 尾部，但它没有触及 L3 标头，因此其上方没有标头。

源端口号将是一个临时端口号，目标端口号将为 80。

第7步：3次握手

TCP - 可靠且相同的订单服务。本地计算机现在要做的第一件事是与 Google 服务器建立三向握手，因为它知道到服务器的路由。连接建立有助于最终确定一些状态变量，如 MSS 大小、初始序列号、ACK 类型、缓冲区大小等。

在这种情况下，TCP 标头中的源端口和目标端口都是 16 位，因此 2^16 是 65535。源端口用于标识客户端应用程序，而目标端口用于标识在 Web 服务器上运行的服务或守护进程。

客户端（Web 浏览器）选择 49152 - 65535 之间的任何端口。这可以确保没有 2 个应用程序使用相同的端口。端口地址与 IP 地址一起称为 TCP 套接字。目的端口是IP报文中的80端口。

开始沟通：

在开始任何操作之前，客户端（Web 浏览器）需要查看与 Web 服务器的连接是否可用。为此，我们需要用序列号 = 0 填充源端口、目标端口、源 IP 和目标 IP。序列号由客户端分配，但服务器需要。确认号由服务器分配但由客户端使用。在步骤 1 中，由于没有需要确认的内容 (SYN)，因此未设置 ACK 字段
在步骤 2 中，当服务器响应时，它会翻转源端口和目标端口。在服务器的响应中，它放置一个随机序列号，例如 = 1000 和 ACK = 1。在这种情况下，设置了同步，并且设置了 ACK 标志 (SYN,ACK)
在步骤 3 中，当客户端响应时，它将具有相同的端口，因为它是同一个会话，现在将确认步骤 2 的 SYN、ACK。序列号将为 1，确认号为 1001

通过上述三个步骤，客户端和服务器之间的 TCP 握手成功，并且双方现在都同意数据传输的通用规则。

第 8 步：TLS 握手

如果您连接到安全网站，则在 TCP 握手后，将进行 TLS 握手。通过 TLS 握手，客户端和服务器同意安全通信的通用条款。

客户端计算机向服务器发送一条 ClientHello 消息，其中包含其传输层安全 (TLS) 版本、可用的密码算法和压缩方法的列表。
服务器向客户端回复一条 ServerHello 消息，其中包含 TLS 版本、选定的密码、选定的压缩方法以及由 CA（证书颁发机构）签名的服务器公共证书。该证书包含一个公钥，客户端将使用该公钥来加密握手的其余部分，直到就对称密钥达成一致。
客户端根据其可信 CA 列表验证服务器数字证书。如果可以基于 CA 建立信任，则客户端会生成一串伪随机字节并使用服务器的公钥对其进行加密。这些随机字节可用于确定对称密钥。
服务器使用其私钥解密随机字节，并使用这些字节生成自己的对称主密钥副本。
客户端向服务器发送一条 Finished 消息，并使用对称密钥对迄今为止传输的哈希值进行加密。
服务器生成自己的哈希值，然后解密客户端发送的哈希值以验证其是否匹配。如果是，它会将自己的 Finished 消息发送给客户端，并使用对称密钥进行加密。

从现在开始，TLS 会话传输使用商定的对称密钥加密的应用程序 (HTTP) 数据。