一、URL解析
1、地址解析
浏览器会根据你的输入来判断该输入是一条合法的URL，还是需要被搜索的关键词。并且根据你输入的内容进行自动完成、字符编码等操作。
2、其他操作
目前大部分浏览器都会强制客户端使用HTTPS协议以保证信息传输的安全性。同时还会进行一些额外的操作，比如安全检查、访问限制等。
3、缓存检查
浏览器会先检测是否缓存了目标URL的页面，如果有且缓存未过期，则直接展示缓存页面，无需再向服务器进行请求。
二、DNS解析
DNS解析是寻找所需要的资源的IP地址的过程。因为互联网中每一台连网的机器都有唯一IP作为标识，但是它是一串数字，记忆太过困难。所以就需要将网址和IP地址进行转换，也就是DNS解析。其具体步骤如下。
1、查询缓存
我们的浏览器、操作系统、路由器都会缓存一些URL对应的IP地址，统称为DNS高速缓存。这是为了加快DNS解析速度，使得不必每次都到根域名服务器中去查询。
2、递归解析
输入www.baidu.com网址后，首先在高速缓存中查找，没找到去根域名服务器查找，没有再去com顶级域名服务器查找，依次类推，直到找到IP地址，然后把它记录在本地告诉缓存中，供下次使用。
大致过程就是.-> .com ->baidu.com. -> www.baidu.com.
其中.代表根域名服务器。
3、DNS负载均衡
访问baidu.com的时候，每次响应的可能并非是同一个服务器（IP地址不同），一般大公司都有成百上千台服务器来支撑访问，DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡。
三、建立TCP连接
TCP/IP 分为四层，在发送数据时，每层都要对数据进行封装
TCP提供一种面向连接的，可靠的字节流服务，是一种可靠传输。接下来将会讲解TCP的首部、三次握手与四次挥手。
1、TCP的首部
TCP首部的格式如下
● 源端口：源端口和IP地址的作用是标识报文的发送地址和返回地址
● 目的端口：端口指明接收方计算机上的应用程序接口
○ TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接
● 序号：是TCP可靠传输的关键部分
○ 序号是该报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节都有一个序号
■ 比如一个报文段的序号为300，报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性
● 确认号：ack，用于指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到
○ 确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0
● 首部长度/数据偏移：占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远
● 保留：占6位，保留今后使用，但目前应都位0
● 控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能
○ URG：紧急。当URG=1时，表明紧急指针字段有效。告诉系统此报文段中有紧急数据
○ ACK：确认。当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1
○ PSH：推送。当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1
○ RST：复位。当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接
○ SYN：同步，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1
○ FIN：终止，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放
● 窗口：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bits字段，因而窗口大小最大为65535
● 校验和：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。由发送端计算和存储，并由接收端进行验证
● 紧急指针：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式
● 选项和填充：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍
● 数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。
2、三次握手
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
为什么是三次握手？两次不行吗？四次不行吗？
为什么不是两次握手
这是为了避免服务器建立无用连接（客户端服务器建立连接后，却不传输数据）
如果只进行两次握手，如果客户端向服务器第一次发送的建立连接的请求因为某原因，兜兜转转绕了一大圈才到达服务器。这期间客户端因为未收到服务器的响应，就会再次发送连接请求，这时服务器收到了，向客户端发送连接请求后，连接便建立了。然后数据传输完毕后，释放连接。这时刚刚兜兜转转一大圈的建立连接的请求到了服务器，服务器收到后再次向客户端发送请求，发送后又建立了连接，但是建立连接后客户端没有再理会服务器，客户端与服务器之间没有传输数据，此时服务器的资源就会被浪费
为什么不是四次握手
因为通信不可能100%可靠（红军蓝军约定）， 而上面的三次握手已经做好了通信的准备工作， 再增加握手， 并不能显著提高可靠性，所以只需要三次握手就足够了
这里简单介绍一下红军蓝军约定
红军和蓝军都想消灭一波敌人，但是单凭他们一个军队的力量都不足以消灭这波敌人，因此他们想到了一起合作，于是红军向蓝军发了一封电报，内容是约定好早上8点一起向敌军进攻，由于他们不确定蓝军是否一定能收到电报, 所以只有收到蓝军的回复之后才会进行进攻，而蓝军也是同样的想法，因为他们不确定红军一定能收到自己的回复而在约定好的时间发动进攻，所以他们只有收到红军的回复后才发动进攻….
问怎样才能保证这次战役一定胜利呢？答案是不可能的，因为双方都对于自己发出的消息对方是否一定接收得到存在质疑，所以，这样的通信将一直进行下去，结果将是使胜利的几率一直接近100%，但是却永远达不到100%。
3、四次挥手
● 第一次挥手
○ 客户端发送一个FIN=1，用来关闭客户端到服务器的数据传送，此后客户端不会再向服务器发送数据(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。 FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号
● 第二次挥手
○ 服务器收到FIN包后，发送一个ACK给对方并且带上自己的序列号seq，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间
○ 此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）
● 第三次挥手
○ 服务器发送一个FIN=1，用来关闭服务器到客户端的数据传送，也就是通知客户端，可以真正地释放连接了。由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
● 第四次挥手
○ 客户端收到FIN后，发送一个ACK=1给服务器，确认序号为收到序号+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态
○ 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些
为什么客户端最后还要等待2MSL
确保第四次挥手服务器能够收到，同时使失效的连接请求从网络中消失
MSL是Maximum Segment Lifetime英文的缩写，中文可以译为报文最大生存时间，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
● 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失。站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器
● 防止类似与三次握手中提到了的已经失效的连接请求报文段出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失（最长生存MSL）。这样新的连接中不会出现旧连接的请求报文
为什么建立连接是三次握手，关闭连接确是四次挥手
● 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端
● 关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次
四、发送HTTPS请求
1、HTTP简介
参考你每天都在使用的HTTP协议，到底是什么鬼？
2、HTTPS简介
在HTTP的基础上再加一层TLS（传输层安全性协议）或者SSL（安全套接层），就构成了HTTPS协议。
HTTPS详细介绍可以参考一文带你了解HTTPS
HTTPS如何保证可靠性
● 对称加密以及非对称加密
○ 通过非对称加密生成密钥，后面通过这个密钥进行对称加密进行传输
● 数字签名
○ 保证非对称加密时发送的公钥是被认证过的，是安全可靠的
● 单向Hash算法
大致过程如下
3、HTTPS传输过程
● 建立TCP连接（HTTP）
● 将HTTP请求转换为HTTPS请求，转到HTTPS网站
○ 因为一般人输入网址时，都是输入如www.baidu.com，而不会输入https://www.baidu.com。这时默认使用的是HTTP协议，浏览器会帮我们自动转换为HTTPS协议
● 建立新的TCP连接(HTTPS)
○ 因为HTTP与HTTPS的端口不同。HTTP使用80端口，HTTPS使用443端口
● 完成一系列的协商工作
○ 完成加密套件的协商和证书的身份确认，这次交互客户端和服务端会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法等等。浏览器获取到证书之后，也要验证证书的有效性，是否过期是否撤销
● 浏览器获取CA域名
○ 如果没有CA域名的缓存，还需要进行DNS解析
● 再次建立新的TCP连接（CA域名）
● 发送OCSP请求
○ OCSP全称是Online Certificate Status Protocol，在线证书状态协议，顾名思义用来获取证书状态的请求，这里的状态包括有效、过期、未知。并且可以宽限一段客户端访问证书的时间
● 进行密钥协商
经过以上过程后，便可以进行数据的对称加密传输了。
五、查询MAC地址
这一步主要负责为打包好的数据+TCP首部+IP首部寻找传输路线，找到IP对应的物理机，这里会用到ARP协议。
1、ARP协议
ARP（Address Resolution Protocol）即地址解析协议， 用于实现从 IP 地址到 MAC 地址的映射，即询问目标IP对应的MAC地址。
2、ARP如何交互
ARP协议通过一问一答实现交互，但是问和答都有讲究，问是通过广播形式实现，答是通过单播形式。
以上都是计算机网络的部分，接下来将介绍服务器如何接收与处理请求
六、请求在Tomcat中的处理流程
Web 容器以进程的方式在计算机上运行，它主要负责接收请求，并将其投送至特定的应用，但Web容器并不属于计算机网络的组成部分。接下来将以Tomcat为例介绍Web容器的核心组件。
1、Tomcat的核心组件
Tomcat的核心组件主要有：Server、Service、Connector、Engine、Host和Context。
一个Server可以包含多个Service，一个Service可以包含多个Connector，但只能包含一个Engine，一个Engine可以包含多个Host，一个Host可以包含多个Context。
它们之间的关系如下图所示
配置文件的结构如下
<Server>
<Service>
<Engine>
<Host>
<Context />
</Host>
<Host>
<Context />
</Host>
</Engine>
<Connector />
<Connector />
</Service>
</Server>
Server
Server 是整个配置文件的唯一根元素，代表整个 Tomcat 容器。Server 内部可以包含多个 Service，其主要职责就是管理多个 Service，对外提供给客户端访问，同时维护所有 Service 的生命周期，包括初始化服务、结束服务、定位客户端要访问的 Service 等等。
Service
Service 的主要职责就是将 Engine 与 Connector 装配在一起对外提供服务。一个 Service 可以包含多个 Connector，但只能包含一个 Engine，其中 Connector 负责从客户端接收请求，Engine 负责处理 Connector 接收进来的请求。
Connector
Connector是主要负责接收请求的组件。
Tomcat有以下两种工作模式
● 作为Web服务器，直接接收客户端的请求
● 作为Java Web服务器，接收前置Web服务器的请求
Connector作为通信接口，它为其所属特定的 Service 接收外部客户端请求，以及回送应答至外部客户端。具体职责包括创建 Request、Response 对象用于跟外部客户端交换数据，并将 Request 交给配套的 Engine 来处理。
Engine
Engine 是 Service 组件中负责请求处理的组件，其内部可以包含多个 Host。Engine 从一个或多个 Connector 中接收请求并处理，并将处理结果封装成应答交给 Connector，最终回传给外部客户端。
Host
Host 代表一个虚拟主机，它对应计算机网络上的一个实体。即某个在 DNS 服务器上注册过的域名或者 IP 地址，例如：www.baidu.com或 201.187.10.21。Host 内部可以包含多个 Context，每个 Context 表示一个 Web 应用。Host 负责安装、展开、启动和结束每个 Web 应用。
客户端在填写目标地址时会通过主机名来标识它希望访问的服务器，Tomcat 将从 HTTP 请求头的 Host 字段提取主机名，然后再匹配对应的虚拟主机。如果没有找到匹配的，HTTP 请求将被发送至默认主机 defaultHost。
Context
Context 代表在特定虚拟主机上运行的一个 Web 应用，负责处理某个特定 Web 应用的所有请求。
2、Tomcat处理HTTP请求
当以 HTTP 请求到达Tomcat服务器（Server）以后，Tomcat会进行以下几个步骤，将请求交给对应的Web应用进行处理
● 根据协议类型和端口号选定 Service 和 Engine
○ Connector 主要负责接收请求。当 Connector 接收到特定协议和特定端口的请求后，其所属的 Service 和 Service 下的 Engine 也就确定了
● 根据域名或 IP 地址选定 Host
○ Engine一旦确定了，就会根据 IP 来选择对应的虚拟主机Host来处理请求。如果匹配失败了，则会使用默认虚拟主机来处理请求
● 根据 URI 选定 Context
○ URI 中的 context-path 指定了 HTTPS 请求将要访问的 Web 应用
○ 当请求抵达时，Tomcat 将根据 Context 的属性 path 取值与 URI 中的 context-path 的匹配程度来选择 Web 应用处理相应请求
七、请求在Web应用中的处理流程
请求被 Web 容器中的 Connector 捕获，选取对应的 Server 中的 Engine ，Engine 再根据IP选择对应的虚拟主机，虚拟主机根据URI将请求交给对应的Web应用进行处理。接下来将介绍请求在Web请求中的处理过程。
介绍处理过程前，先对Web应用的基本组件进行简单介绍。
1、Web应用核心组件
Listener
监听器 Listener 主要用于监听 Application、Session、Request 等对象的变化，每当这些对象发生变化就会回调用对应的监听方法。
Filter
过滤器 Filter 负责对请求做预处理，接着将请求交给 Servlet 进行处理并生成响应，最后 Filter 再对响应进行后处理。
从请求的处理过程来看，Filter 主要参与以下几个环节
● 在 HttpServletRequest 到达 Servlet 之前，拦截客户的 HttpServletRequest
● 根据需要检查 HttpServletRequest，也可以修改 HttpServletRequest 报文头和数据
● 在 Servlet 生成的 HttpServletResponse 抵达客户端之前，拦截 HttpServletResponse
● 根据需要检查 HttpServletResponse，也可以修改 HttpServletResponse 报文头和数据
简单来说就是在真正处理请求以及返回响应之前，通过过滤器对内容再进行一些修改
Servlet
Servlet 负责处理客户端访问动态资源的 HTTP 请求，接口
javax.servlet.Servlet 定义了所有 Servlet 必须要实现的方法
public interface Servlet {
// 由 Servlet 容器调用，完成 Servlet 初始化，启动对外服务
void init(ServletConfig var1) throws ServletException;
// 获取 Servlet 初始化和启动时参数的配置信息对象 ServletConfig
ServletConfig getServletConfig();
// 由 Servlet 容器调用，让 Servlet 处理某个 HTTP 请求
void service(ServletRequest var1, ServletResponse var2) throws ServletException, IOException;
// 获取 Servlet 的说明信息，包括：作者、版本和版权等等
String getServletInfo();
// 由 Servlet 容器调用，用于关闭停止 Servlet 提供的服务
void destroy();
}
从 HTTP 请求的处理过程来看，Servlet 主要参与以下几个环节
● 接收请求
○ 客户端请求会被封装成 HttpServletRequest 对象，包含报文头参数和报文体等信息
● 处理请求
○ 通常调用 Servlet 的方法 service、doPost 或 doGet 等方法处理请求，并进一步调用业务层相应逻辑对其进行处理等
● 反回响应
○ 处理完请求后，可以转发（forward）、重定向（redirect）到某个视图页面或者直接返回结果数据
2、Web应用处理HTTP请求流程
Web 应用处理 HTTP 请求的流程主要是穿越 Listener 和多个 Filters，最终抵达 Servlet 的过程，Servlet再进行下一步的处理。
具体流程如下图
八、请求在Spring Web应用中的处理流程
因为使用 SSM 框架，所以 Spring MVC 中的 DispatcherServlet 充当了 Web 应用中的 Serlvet，负责将任务分配给对应的Controller，并将最终视图返回给 Web 容器。
1、Spring MVC的核心组件
DispatcherServlet
DispatcherServlet 是整个流程控制的中心，由它来接收请求并调用其它组件处理用户的请求，同时还负责响应结果。DispatcherServlet的存在降低了组件之间的耦合性。
HandlerMapping
HandlerMapping 负责根据用户请求映射获得对应的 Handler和 HandlerInterceptor。处理方法为从 URL 获得 URI，在通过 URI 从 HandlerMapping 中找到对应的 Handler 和 HandlerInterceptor，即处理器和拦截器。
HandlerAdapter
HandlerAdapter 负责按照特定规则去执行 Handler。
如果 Handler 有对应的 HandlerAdapater，HandlerAdapater 则会在调用 Handler 之前执行 HandlerInterceptor 的 preHandler() 方法对 Handler 进行拦截。
HandlerInterceptor
HandlerInterceptor 主要负责在执行 Handler 前对其进行拦截。HandlerInterceptor 中的 preHandler() 方法将会提取 HTTP 请求中的数据填充到处理器 Handler 的中。
Handler
Handler 即Controller ，是处理业务代码的核心器件。这部分由程序员自行编写，一般的SSM框架中，其下层还有Service和Dao。
2、Spring MVC处理请求流程
当 Web 容器中的 Host 会选择对应的 Web应用来处理请求，这里将请求交给了 Spring MVC 中的 DispatcherServlet 来进一步处理请求。
● DispatcherServlet 通过解析 HTTP 请求的 URL 获得 URI，再根据该 URI 从 HandlerMapping 当中获得该请求对应的 Handler 和 HandlerInterceptor
● DispatcherServlet 根据获得的 Handler 选择合适的 HandlerAdapter。如果成功获得 HandlerAdapter，HandlerAdapater 则会在调用 Handler 之前执行 HandlerInterceptor 的 preHandler() 方法对 Handler 进行拦截
● Handler 即 Controller 会进行请求的处理，并向下调用 Service 和 Dao 来处理请求
● Hander 处理完成请求后会返回模型数据，模型数据由 DispatcherServlet 封装后返回给Web 容器
处理的流程图如下
九、返回过程
Web 应用处理完请求并将结果返回给 Web 容器后，容器会将响应结果返回给客户端，这是上面流程的逆过程。浏览器收到响应结果后，会对结果进行解析和渲染。这样我们就能看到浏览器给我们显示的网页了。
十、整体流程图
下面给出了输入URL到浏览器显示界面的流程图
以上便是从输入URL到浏览器显示页面的整个流程
