输入网址按回车，到底发生了什么
详解输入网址点击回车，后台到底发生了什么。透析 HTTP 协议与 TCP 连接之间的千丝万缕的关系。掌握为何是三次握手四次挥手？time_wait 存在的意义是什么？全面图解重点问题，再也不用担心面试被问到。
大致流程
URL 解析。
DNS 查询。
TCP 连接。
服务器处理请求。
客户端接收 HTTP 报文响应。
渲染页面
重点来了：
如何理解 TCP 的三次握手与四次挥手？每次握手客户端与服务端是怎样的状态？
为何挥手会出现 2MSL，遇到大量 Socket 处在 TIME_WAIT 或者 CLOSE_WAIT 状态是什么问题？
三次握手与四次挥手的过程是怎样的？
HTTP 的报文格式又是怎样的？
继续阅读本文，且听码哥字节答疑解惑，微信搜索 “码哥字节”，关注公众号更多硬核。
URL 解析
地址解析：首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词，并且根据你输入的内容进行自动完成、字符编码等操作。
HSTS 由于安全隐患，会使用 HSTS 强制客户端使用 HTTPS 访问页面。详见：你所不知道的 HSTS[1]。
其他操作 浏览器还会进行一些额外的操作，比如安全检查、访问限制（之前国产浏览器限制 996.icu）。
检查缓存
URL解析
DNS 查询
DNS 查询
浏览器缓存：先检查是否在缓存中，没有则调用系统库函数进行查询。
操作系统缓存：操作系统也有自己的 DNS 缓存，但在这之前，会向检查域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查询请求。
路由器缓存。
ISP DNS 缓存：ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数情况下都会有缓存。
根域名服务器查询
在前面所有步骤没有缓存的情况下，本地 DNS 服务器会将请求转发到互联网上的根域，下面这个图很好的诠释了整个流程：
DNS递归查询
需要注意的的是：
递归方式：一路查下去中间不返回，得到最终结果才返回信息（浏览器到本地 DNS 服务器的过程）
迭代方式，就是本地 DNS 服务器到根域名服务器查询的方式。
什么是 DNS 劫持
前端 dns-prefetch 优化
TCP 连接建立与断开
TCP/IP 分为四层，在发送数据时，每层都要对数据进行封装：
TCP/IP 连接
应用层：发送 HTTP 请求
浏览器从地址栏得到服务器 IP，接着构造一个 HTTP 报文，其中包括：
请求报头(Request Header)：请求方法、目标地址、遵循的协议等
请求主体，请求参数，比如 body 里面的参数
传输层：TCP 传输报文
传输层会发起一条到达服务器的 TCP 连接，为了方便传输，会对数据进行分割（以报文段为单位），并标记编号，方便服务器接受时能够准确地还原报文信息。在建立连接前，会先进行 TCP 三次握手。
网络层：IP 协议查询 MAC 地址
将数据段打包，并加入源及目标的 IP 地址，并且负责寻找传输路线。判断目标地址是否与当前地址处于同一网络中，是的话直接根据 Mac 地址发送，否则使用路由表查找下一个地址，以及使用 ARP 协议查询它的 Mac 地址。
链路层：以太网协议
根据以太网协议将数据分为以“帧”为单位的数据包，每一帧分为两个部分：
标头：数据包的发送者、接受者、数据类型
数据：数据包具体内容
Mac 地址
以太网规定了连入网络的所有设备都必须具备“网卡”接口，数据包都是从一块网卡传递到另一块网卡，网卡的地址就是 Mac 地址。每一个 Mac 地址都是独一无二的，具备了一对一的能力。
主要的请求过程：
浏览器从地址栏中获取服务器的 IP 和端口号；
浏览器与服务器之间通过 TCP 三次握手建立连接；
浏览器向服务器发送报文；
服务器接收报文处理，同时将响应报文发给浏览器；
浏览器解析报文，渲染输出到页面；
三次握手
在传输层传输数据之前需要建立连接，也就是三次握手创建可靠连接。
三次握手
首先建立链接前需要 Server 端先监听端口，因此 Server 端建立链接前的初始状态就是 LISTEN 状态，这时 Client 端准备建立链接，先发送一个 SYN 同步包，发送完同步包后，Client 端的链接状态变成了 SYN_SENT 状态。Server 端收到 SYN 后，同意建立链接，会向 Client 端回复一个 ACK。
由于 TCP 是双工传输，Server 端也会同时向 Client 端发送一个 SYN，申请 Server 向 Client 方向建立链接。发送完 ACK 和 SYN 后，Server 端的链接状态就变成了 SYN_RCVD。
Client 收到 Server 的 ACK 后，Client 端的链接状态就变成了 ESTABLISHED 状态，同时，Client 向 Server 端发送 ACK，回复 Server 端的 SYN 请求。
Server 端收到 Client 端的 ACK 后，Server 端的链接状态也就变成了的 ESTABLISHED 状态，此时建连完成，双方随时可以进行数据传输。
在面试时需要明白三次握手是为了建立双向的链接，需要记住 Client 端和 Server 端的链接状态变化。另外回答建连的问题时，可以提到 SYN 洪水攻击发生的原因，就是 Server 端收到 Client 端的 SYN 请求后，发送了 ACK 和 SYN，但是 Client 端不进行回复，导致 Server 端大量的链接处在 SYN_RCVD 状态，进而影响其他正常请求的建连。可以设置 tcp_synack_retries = 0 加快半链接的回收速度，或者调大 tcp_max_syn_backlog 来应对少量的 SYN 洪水攻击
四次挥手
我们只要关注 80 端口与 13743 端口建立的连接断开过程，浏览器通过 13747 端口发送 [FIN, ACK] 这里是不是跟很多网上看到的不一样？
其实是客户端在发送 [FIN] 报文的时候顺带发了一个 [ACK] 确认上次传输确认。
接着服务端通过 80 端口响应了 [ACK] ，然后立马响应 [FIN, ACK] 表示数据传输完了，可以关闭连接。
最后浏览器通过 13743 端口 发送 [ACK] 包给服务端，客服端与服务端连接就关闭了。
具体流程如下图抓包所示：
四次挥手
三次握手与四次挥手
TCP 连接与断开
客户端：
SYN_SENT - 客户端发起第 1 次握手后，连接状态为 SYN_SENT ，等待服务端内核进行应答，如果服务端来不及处理（例如服务端的 backlog 队列已满）就可以看到这种状态的连接。
ESTABLISHED - 表示连接处于正常状态，可以进行数据传送。客户端收到服务器回复的 SYN+ACK 后，对服务端的 SYN 单独回复（第 3 次握手），连接建立完成，进入 ESTABLISHED 状态。服务端程序收到第 3 次握手包后，也进入 ESTABLISHED 状态。
FIN_WAIT_1 - 客户端发送了关闭连接的 FIN 报文后，等待服务端回复 ACK 确认。
FIN_WAIT_2 - 表示我方已关闭连接，正在等待服务端关闭。客户端发了关闭连接的 FIN 报文后，服务器发回 ACK 应答，但是没进行关闭，就会处于这种状态。
TIME_WAIT - 双方都正常关闭连接后，客户端会维持 TIME_WAIT 一段时间，以确保最后一个 ACK 能成功发送到服务器端。停留时长为 2 倍的 MSL (报文最大生存时间)，Linux 下大约是 60 秒。所以在一个频繁建立短连接的服务器上通常可以看到成千上万的 TIME_WAIT 连接。
服务端：
LISTEN - 表示当前程序正在监听某个端口时。
SYN_RCVD - 服务端收到第 1 次握手后，进入 SYN_RCVD 状态，并回复一个 SYN+ACK（第 2 次握手），再等待对方确认。
ESTABLISHED - 表示连接处于正常状态，可以进行数据传送。完成 TCP3 次握手后，连接建立完成，进入 ESTABLISHED 状态。
CLOSE_WAIT - 表示客户端已经关闭连接，但是本地还没关闭，正在等待本地关闭。有时客户端程序已经退出了，但服务端程序由于异常或 BUG 没有调用 close()函数对连接进行关闭，那在服务器这个连接就会一直处于 CLOSE_WAIT 状态，而在客户机已经不存在这个连接了。
LAST_ACK - 表示正在等待客户端对服务端的关闭请求进行最终确认。
TIME_WAIT 状态存在的理由：
划重点了
可靠地实现 TCP 全双工连接的终止 在进行关闭连接四路握手协议时，最后的 ACK 是由主动关闭端发出的，如果这个最终的 ACK 丢失，服务器将重发最终的 FIN，因此客户端必须维护状态信息允 许它重发最终的 ACK。如 果不维持这个状态信息，那么客户端将响应 RST 分节，服务器将此分节解释成一个错误（ 在 java 中会抛出 connection reset 的 SocketException)。因而，要实现 TCP 全双工连接的正常终 止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭 的客户端必须维持状 态信息进入 TIME_WAIT 状态。
允许老的重复分节在网络中消逝 TCP 分节可能由于路由器异常而“迷途”，在迷途期间，TCP 发送端可能因确认超时而重发这个 分节，迷途的分节在路由器修复后也会被送到最终目的地，这个 原来的迷途分节就称为 lost duplicate。在关闭一个 TCP 连接后，马上又重新建立起一个相同的 IP 地址和端口之间的 TCP 连接，后一个连接被称为前一个连接的化身 （ incarnation)，那么有可能出现这种情况，前一 个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。为了避免 这个情 况，TCP 不允许处于 TIME_WAIT 状态的连接启动一个新的化身，因为 TIME_WAIT 状 态持续 2MSL，就可以保证当成功建立一个 TCP 连接的时 候，来自连接先前化身的重复分组已 经在网络中消逝。
另外回答断链的问题时，可以提到实际应用中有可能遇到大量 Socket 处在 TIME_WAIT 或者 CLOSE_WAIT 状态的问题。一般开启 tcp_tw_reuse 和 tcp_tw_recycle 能够加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE_WAIT 可能是被动关闭的一方存在代码 bug，没有正确关闭链接导致的。
简单地说就是
保证 TCP 协议的全双工连接能够可靠关闭；
保证这次连接的重复数据段从网络中消失，防止端口被重用时可能产生数据混淆；
服务器处理请求并响应 HTTP 报文
深入分析下 HTTP 报文到底是什么玩意。数据传输都是通过 TCP/IP 协议负责底层的传输工作， HTTP 协议基本不用操心，所谓的 “超文本传输协议” 似乎不怎么理会 “传输” 这个事情，那 HTTP 的核心又是什么呢？
比图 TCP 报文，它在实际要传输的数据之前附加了一个 20 字节的头部数据，存储 TCP 协议必须的额外信息，例如发送方的端口号、接收方的端口号、包序号、标志位等等。
有了这个附加的 TCP 头，数据包才能够正确传输，到了目的地后把头部去掉，就可以拿到真正的数据。这个很容易理解，设置起点与终点，不同协议贴上不同的头部，到了对应目的地就拆下这个头部，提取真正的数据。
HTTP报文
与 TCP/UDP 类似需要在传输数据前设置一些请求头，不同的是 HTTP 是一个 “纯文本” 的协议，所有的头都是 ASCII 码的文本，很容易看出来是什么。
再者就是他的请求报文与响应报文的结构基本一样，主要三大部分组成：
起始行(Start Line)：描述请求或者响应的基本信息。
Header：使用 key-value 的形式详细说明报文信息。
空行。
消息正文（Entity）：传输的数据，图片、视频、文本等都可以。
这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。
敲黑板了
HTTP 协议规定报文必须包含 Header，而且之后必须有一个 “空行”，也就是“CRLF”，十六进制的“0D0A”，可以没有 “body”。
报文结构如下图所示：
HTTP报文
截取一段报文：
HTTP报文抓取
请求头-起始行
请求行由请求方法字段、URL 字段和 HTTP 协议版本字段 3 个字段组成，它们用空格分隔。例如，GET / HTTP/1.1。
HTTP 协议的请求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
GET 是请求方法， “/” 是请求的目标资源，“HTTP/1.1” 请求协议版本号。
GET / HTTP/1.1 翻译成文字大概就是：“hello，服务器，我要请求根目录下的默认文件使用的是 HTTP 1.1 协议版本”。
头部 Header
第二部分就是 Header，组成形式是 key：value，使用自定义头需要注意事项：
header 字段不区分大小写，通常是首字母大写；
字段名不允许有空格，可以使用 “-”，不能使用 “_”；
字段名必须紧接着 “:”，不能有空格，但是 “:” 后面可以有空格。
字段名顺序没有意义；
浏览器接收响应并渲染数据
浏览器接收到来自服务器的响应资源后，会对资源进行分析。首先查看 Response header，根据不同状态码做不同的事（比如上面提到的重定向）。如果响应资源进行了压缩（比如 gzip），还需要进行解压。然后，对响应资源做缓存。接下来，根据响应资源里的 MIME[3] 类型去解析响应内容（比如 HTML、Image 各有不同的解析方式）。
接下来将接收到的数据渲染出来，不同的浏览器也不是完全相同，但是大致流程是一样的：
浏览器渲染页面流程
推荐阅读
阿里精选:Java 代码精简之道
Java8 中用法优雅的 Stream，性能也""优雅""吗？
