文章导入：

本文呢~ 您只看标题就晓得了文章内容，没错，是关于 Web服务篇–Http 协议的内容。

咱直接开门见山，您平时上网，逛网页那是必不可少的了；

您肯定有过下面操作：在浏览器地址栏里输入 www.baidu.com ，然后页面就跳转到您所需

要的页面。

那换言之，您在地址栏里输入内容，这个简简单单的操作能够执行，以至于给您带来您想要的

网页页面呈现在眼前，这个操作的背后就是我们要讲的内容 ~！！

===>>>

这中间发生的过程，这您上网，打开浏览器，网页从无到有的过程即是文章核心~！!

概述：

* 终端客户在 Web 浏览器地址栏输入访问地址（ eg : http://www.ceshi.com:80/index.html）

* Web 浏览器请求 DNS 服务器把域名 www.ceshi.com 解析成 Web 服务器的 IP 地址

* Web 浏览器将端口号（默认是 80 ）从访问地址 URL 中解析出来

* Web 浏览器通过解析后的IP 地址及端口号与 Web 服务器之间建立一条 TCP 连接

* 建立 TCP 连接后，Web 浏览器向 Web 服务器发送一条 HTTP 请求报文

* Web 服务器响应并读取浏览器的请求信息，然后返回一条 HTTP 响应报文

* Web 服务器关闭 HTTP 连接，关闭 TCP 连接，Web浏览器显示访问的网站内容到屏幕上 ~！

详解过程：

您在浏览器地址栏输入域名（网址）

上面这个简单的操作，为了更好的理解其背后的原因，我们就得把 DNS域名解析服务再掰扯掰

扯了~！

DNS域名解析：

那你在浏览器地址栏输入了一个域名（网址），那浏览器接受到后，它怎么弄呢？

且听咱家给你分析分析

直接告诉你，浏览器（也即计算机）一看你输入的东东（网址），

浏览器直接懵逼，这是啥啊？？浏览器直接一个蒙圈，恩？？问我浏览器为啥懵逼啊？？

===>>>

来来来，我且问你，你输入的那些域名（网址），你肯定知道是啥意思，

www.baidu.com，那势必是百度的网站嘛，你光看那网址的表面意思就直接清楚了！

是啊 ~！当然清楚，这话没错~！你一看这域名你知道是百度，我也知道是百度，

张三肯定也知道，那浏览器它知不知道呢？？？？

它是不知道的~！！！！

我们最早学计算机的时候，就清楚，这些计算机，机器，它们是压根就读不懂人话的，

它们喜欢什么？？

===>>>

它们喜欢二进制 ~！！是数字 ~！！是 01 ~！！

===>>>

诶？这问题不就来了，你明明给浏览器地址栏输入的是 www.baidu.com

那也不是数字啊？？那为啥浏览器还能知道他要做啥呢？？

当你发现这个矛盾的时候， DNS域名解析服务就该登场了 ~！！

因为 DNS 就是解决这个问题的~！！！！

那根据上面所述，您在清楚了这个问题的矛盾点之后，您觉得这个矛盾应该怎么解决呢？

我的想法是：

既然，浏览器要的是数字，你地址栏输入的内容，它有没有对应的数字呢？

废话~！！当然有了，除了域名，您是不是应该还清楚一个概念叫做 IP 啊？

===>>>

当然知道了， IP地址谁不知道啊？？？？

那不就得了，你所输入的域名（网址）它对应的 IP 地址是多少啊？？

===>>>

那怎么着？？啥意思？？是让您在地址栏输入 IP 地址嘛？？？

非也~！！不是，那啥意思？？？

===>>>

您这么想，首先，您知道 www.baidu.com 对应的 IP 地址是多少嘛？？

其次，还有一个问题就是，

那全世界就只有 www.baidu.com 这一个网址嘛？？

全世界这么多网址，数不清的网址，啥意思？？？

我还得一个一个记它们网址对应的 IP ？？？

这不纯纯胡扯呢嘛 ~！！！！！

（没错，我要是在浏览器输入 IP – 数字，浏览器是轻松了，那我呢？累死我嘛？）

===>>>

所以，我们说，面对这个矛盾，这时候，DNS 服务就登场了，

DNS服务，它的全称是 DNS域名解析服务，就是解析您在浏览器地址栏输入

的内容（即你输入的那些域名-网址）

那既然是解析，那解析成什么呢？？

===>>>

即解析成浏览器（计算机）能够读懂的数字，也即 IP 地址。

DNS服务（负责把域名和IP地址做一一映射关系）

这不就正好解决了 ‘ 矛盾 ’

DNS 域名解析过程分析：

浏览器首先看一下自己的DNS缓存里有没有（缓存时间比较短，大概只有1分钟，且只能容

纳1000条缓存）

如果没有就向操作系统的DNS缓存要，还没有就检查本机域名解析文件 hosts要，

在前面三个过程都没获取到的情况下，就会向 DNS 服务器进行查询，

浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是电信运营

商提供的，也可以使用像Google提供的DNS服务器）发起域名解析请求（通过的是UDP协议

向DNS的53端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供

给我们该域名的IP地址）

下面，结合图示，来分析整个 DNS 服务的过程：

客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
本地域名服务器收到客户端的请求后，如果缓存里的表格能找到www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大，能告诉我www.server.com的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址，你去问问它吧。”
本地 DNS 收到顶级域名服务器的地址后，发起请求问“老二，你能告诉我 www.server.com 的 IP 地址吗？”
顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
本地 DNS 再将 IP 地址返回客户端。

如此，浏览器便得到了，您要访问的网页的 IP 地址。

OK ，那现在我们已经拿到了要访问网页的 IP 地址了，那我们是不是直接就可以浏览到网

页里的内容了？？

===>>>

答案是否定的，因为，现在才只是 Web服务往里长征的第一步 ~！！！！

===>>>

那现在拿到 IP 后，还要干嘛啊？？

现在，只是拿到了 IP ，我们本篇主要的核心 — HTTP协议都还没露面呢~！！！

所以，我们接下来的工作就要为 HTTP 协议做准备了 ~！！

首先，来理一下逻辑思绪

===>>>

我们为什么要进行 HTTP 协议，是因为，浏览器要和 Web服务器进行沟通

浏览器要向Web服务器进行资源索取，

而要进行资源索取就必须得两个端进行连接搭建

也就是说浏览器就得和Web服务器进行连接沟通

只有浏览器和 Web 服务器进行了连接沟通，你浏览器才可以申请到你想要访问网站

的信息，你才可以浏览你想要浏览的页面（才能呈现出来）

而 HTTP 网络请求进行的第一步就是浏览器和服务器建立TCP连接，

所以在网络请求之前，我们需要先看看 HTTP 和 TCP 两个协议的关系，

因为浏览器使用 HTTP 协议作为应用层协议，用来封装请求的文本信息；

并使用 TCP/IP 作传输层协议将它发到网络上，所以在 HTTP 协议开始工作之前，浏览器

需要通过 TCP 与服务器建立连接，也就是说 HTTP 的内容是通过 TCP 的传输数据阶段来

实现的~！！

TCP连接搭建：

那现在就是，我们要进行 TCP连接的搭建

===>>>

TCP 连接的第一步就是要准备 IP地址和端口号 ~！！

显然， IP 地址我们已经通过 DNS域名解析服务获取到了

那端口号的获取？？？

===>>>

一般情况下，我们是通过 URL 来获取端口号的 ~！

（ URL 就是在浏览器地址栏输入的内容，但大多数情况下，我们输入的都

URL 的简写，就只输入了域名，没有连着端口号一起输入）

所以，如果 URL 没有指明端口号的情况下，端口号的获取是和协议有

关的， http 协议对应的端口号默认就是 80 端口，

https 协议对应的端口号是 443 端口。

等待TCP队列

既然IP地址和端口准备好了，那么下一步是不是可以建立TCP连接了呢？

答案是“不一定可以”。Chrome有个机制，同一个域名同时最多只能建立6个TCP连接，如

果在同一个域名下同时有10个请求发生，那么其中4个请求会进入排队等待状态，直至进

行中的请求完成。

当然，如果当前请求数量少于6，会直接进入下一步，建立TCP连接。

建立TCP连接

排队等待结束之后，终于可以快乐地和服务器握手了，在HTTP工作开始之前，浏览器通

过TCP与服务器建立连接。

首先，发送方会发送连接请求，带上SYN = 1 seq= x的字段信息，此时发送方状态为同

步已发送。其次，接收方接受请求后，回复连接请求，带上SYN = 1 ACK = 1 seq = y

ack = x + 1的字段信息，此时接收方的状态为同步已接收

最后，发送方接受响应后，回复带上ACK = 1 seq = x + 1 ack = y + 1的字段信息，此

时，发送方的状态为建立连接状态，而接收方的状态得等发送方这时的回复收到后再转为

建立连接。

（上面整个表述的过程就是我们经常说的三次握手 ~！！！）

此时的状态即是 TCP 连接建立，浏览器与服务端可以进行数据传输了~！！！！

至此，从最开始到目前为止，我们所有的工作都是为 HTTP 协议做的准备 ~！！

也即是说，从现在开始，我们才真正开始进行 HTTP 协议服务~！！！！！！

发起 HTTP 请求：

# 我们现在建立了 TCP连接，即是说浏览器和服务端可以进行通信（数据传输）；

HTTP 协议中的数据正是在这个通信过程中传输的。

# 哪是如何进行 HTTP 请求的呢？？

首先浏览器会向服务器发送请求行，

它包括了请求方法、请求URI（Uniform Resource Identifier）和HTTP版本协议。

发送请求行，就是告诉服务器浏览器需要什么资源，最常用的请求方法是Get。比如，直接

在浏览器地址栏键入极客时间的域名（http://time.geekbang.org），这就是告诉服务器要

Get它的首页资源。

另外一个常用的请求方法是POST，它用于发送一些数据给服务器，比如登录一个网站，就

需要通过POST方法把用户信息发送给服务器。如果使用POST方法，那么浏览器还要准备

数据给服务器，这里准备的数据是通过请求体来发送。

在浏览器发送请求行命令之后，还要以请求头形式发送其他一些信息，把浏览器的一些基础

信息告诉服务器。比如包含了浏览器所使用的操作系统、浏览器内核等信息，以及当前请求

的域名信息、浏览器端的Cookie信息，等等。

结合上图就可以理解浏览器是如何发送请求信息给服务器的。

至此，浏览器到 Web服务器发送的 HTTP 请求，就到了 Web服务器端 ~！！

这是我们整个 Web服务的前半部分，也是 HTTP 服务的前半部分~！！

接下来就到了，Web服务器处理这 HTTP 请求后的事情了 ~！！

Web服务器处理完后，还需要再返回给浏览器~！！！！

服务器响应 HTTP 请求：

# 接下来，Web服务器则会根据浏览器发送的请求信息来准备数据 ~！

返回请求：

首先服务器会返回响应行，包括协议版本和状态码。

但并不是所有的请求都可以被服务器处理的，那么一些无法处理或者处理出错的信息，怎

么办呢？服务器会通过请求行的状态码来告诉浏览器它的处理结果。

比如：

===>>>

最常用的状态码是200，表示处理成功；

如果没有找到页面，则会返回404；

常见状态码：

随后，正如浏览器会随同请求发送请求头一样，服务器也会随同响应向浏览器发送响应

头。响应头包含了服务器自身的一些信息，比如服务器生成返回数据的时间、返回的数据

类型（JSON、HTML、流媒体等类型），以及服务器要在客户端保存的Cookie等信息。

发送完响应头后，服务器就可以继续发送响应体的数据，通常，响应体就包含了HTML的

实际内容。

浏览器解析：

浏览器拿到index.html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源

时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这个

时候就用上keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序

就是按照代码里的顺序，但是由于每个资源大小不一样，而浏览器又多线程请求请求资源。

浏览器在请求静态资源时（在未过期的情况下），向服务器端发起一个http请求（询问自

从上一次修改时间到现在有没有对资源进行修改），如果服务器端返回304状态码（告诉

浏览器服务器端没有修改），那么浏览器会直接读取本地的该资源的缓存文件。

浏览器进行页面渲染：

最后，浏览器利用自己内部的工作机制，把请求的静态资源和html代码进行渲染，渲染之后

呈现给用户，浏览器是一个边解析边渲染的过程。

首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成

后，浏览器开始布局渲染树并将其绘制到屏幕上。

这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都

是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒

模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个

过程称为repain。

页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在

移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和

repain。

JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，JS有可能修改DOM结构，意味

着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载。

服务器关闭 TCP 连接：

通常情况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 连接。不过如果浏览

器或者服务器在其头信息中加入了：

Connection:Keep-Alive

那么TCP连接在发送后将仍然保持打开状态，这样浏览器就可以继续通过同一个TCP连接发

送请求。保持TCP连接可以省去下次请求时需要建立连接的时间，提升资源加载速度。比

如，一个Web页面中内嵌的图片就都来自同一个Web站点，如果初始化了一个持久连接，

你就可以复用该连接，以请求其他资源，而不需要重新再建立新的TCP连接。

那么，关于 TCP 连接的关闭，我们需要讲一点：

===>>>

关闭TCP连接就需要进行四次挥手了。

中断连接端可以是客户端，也可以是服务器端。

上示即为四次挥手的过程 ~！！！

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动

关闭的情况，也是通过四次握手。

当 TCP 连接断开后，自此一次完整的HTTP事务宣告完成。

总结：

我们可以以一张图来大致解释整个过程：

至此，我们整个 Web服务响应的过程就介绍完毕了~！！！！

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

话说~~ HTTP协议请求的工作流程（Web服务请求过程）最细详解目录文章导入：概述：详解过程：总结：

目录

文章导入：

概述：

详解过程：