HTTP请求全过程（很全面）
HTTP请求全过程
第一步：输入地址
当我们开始在浏览器中输入网址http://google.com/的时候，浏览器其实就已经在智能的匹配可能的url 了，他会从历史记录，书签等地方，找到已经输入的字符串可能对应的 url，然后给出智能提示，让你可以补全 url 地址。对于 google 的 chrome 的浏览器，他甚至会直接从缓存中把网页展示出来，就是说，你还没有按下 enter，页面就出来了。
第二步：浏览器查找域名的 IP 地址
1、请求一旦发起，浏览器首先要做的事情就是解析这个域名，一般来说，浏览器会首先查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。
2、如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地 DNS 服务器 。本地 DNS 服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
3、查询你输入的网址的 DNS 请求到达本地 DNS 服务器之后，本地 DNS 服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地 DNS 服务器还要向 DNS 根服务器进行查询。
4、根 DNS 服务器没有记录具体的域名和 IP 地址的对应关系，而是告诉本地 DNS 服务器，你可以到域服务器上去继续查询，并给出域服务器的地址。这种过程是迭代的过程。
5、本地 DNS 服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com 域服务器。.com 域服务器收到请求之后，也不会直接返回域名和 IP 地址的对应关系，而是告诉本地 DNS 服务器，你的域名的解析服务器的地址。
6、最后，本地 DNS 服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP 地址对应关系，本地 DNS 服务器不仅要把 IP 地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。
第三步：浏览器向 web 服务器发送一个 HTTP 请求
拿到域名对应的 IP 地址之后，浏览器会以一个随机端口（1024<端口<65535）向服务器的 WEB 程序（常用的有 httpd,nginx 等）80 端口发起 TCP 的连接请求 。 这个连接请求到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的 TCP/IP 协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过 Netfilter 防火墙（属于内核的模块）的过滤，最终到达 WEB 程序，最终建立了 TCP/IP的连接。
建立了 TCP 连接之后，发起一个 http 请求。一个典型的 http request header 一般需要包括请求的方法，例如 GET 或者 POST 等，不常用的还有 PUT 和 DELETE 、HEAD、OPTION 以及 TRACE 方法，一般的浏览器只能发起 GET 或者 POST 请求。
客户端向服务器发起 http 请求的时候，会有一些请求信息，请求信息包含三个部分：
| 请求方法 URI 协议/版本
| 请求头(Request Header)
| 请求正文：
下面是一个完整的 HTTP 请求例子：
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
注意：最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。
（1）请求的第一行是“方法 URL 议/版本”：GET/sample.jsp HTTP/1.1
（2）请求头(Request Header)
请求头包含许多有关的客户端环境和请求正文的有用信息。如，请求头可以声明浏览器所用的语言，请求正文的长度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
（3）请求正文
请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来
的是请求正文。请求正文中可以包含客户提交的查询字符串信息：username=jinqiao&password=1234
第四步：服务器的永久重定向响应
服务器给浏览器响应一个 301 永久重定向响应，这样浏览器就会访问“http://www.google.com/” 而非“http://google.com/”。为什么服务器一定要重定向而不是直接发送用户想看的网页内容呢？其中一个原因跟搜索引擎排名有关。如果一个页面有两个地址，就像 http://www.yy.com/和http://yy.com/，搜索引擎会认为它们是两个网站，结果造成每个搜索链接都减少从而降低排名。而搜索引擎知道301 永久重定向是什么意思，这样就会把访问带 www的和不带 www的地址归到同一个网站排名下。还有就是用不同的地址会造成缓存友好性变差，当一个页面有好几个名字时，它可能会在缓存里出现好几次。
**********************扩展知识***************************************************************
1）301 和 302 的区别
301 和 302 状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的 URL 地址，这个地址可以从响应的 Location 首部中获取（用户看到的效果就是他输入的地址 A 瞬间变成了另一个地址 B）——这是它们的共同点。他们的不同在于。301 表示旧地址 A 的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；
302 表示旧地址 A 的资源还在（仍然可以访问），这个重定向只是临时地从旧地址 A跳转到地址 B，搜索引擎会抓取新的内容而保存旧的网址。
2）重定向原因：
（1）网站调整（如改变网页目录结构）；
（2）网页被移到一个新地址；
（3）网页扩展名改变(如应用需要把.php 改成.Html 或.shtml)。这种情况下，如果不做重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个 404 页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也需要通过重定向让访问这些域名的用户自动跳转到主站点等。
3）什么时候进行 301 或者 302 跳转呢？
当一个网站或者网页 24—48 小时内临时移动到一个新的位置，这时候就要进行 302跳转，而使用 301 跳转的场景就是之前的网站因为某种原因需要移除掉，然后要到新的地址访问，是永久性的。
清晰明确而言：使用 301 跳转的大概场景如下：
1、域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
2、在搜索引擎的搜索结果中出现了不带 www 的域名，而带 www 的域名却没有收录，这个时候可以用 301 重定向来告诉搜索引擎我们目标的域名是哪一个。
3、空间服务器不稳定，换空间的时候。
**********************扩展知识***************************************************************
第五步：浏览器跟踪重定向地址
现在浏览器知道了 "http://www.google.com/"才是要访问的正确地址，所以它会发送另一个 http 请求。这里没有啥好说的
第六步：服务器处理请求
经过前面的重重步骤，我们终于将我们的 http 请求发送到了服务器这里，其实前面的重定向已经是到达服务器了，那么，服务器是如何处理我们的请求的呢？后端从在固定的端口接收到 TCP 报文开始，它会对 TCP 连接进行处理，对 HTTP 协议进行解析，并按照报文格式进一步封装成 HTTP Request 对象，供上层使用。一些大一点的网站会将你的请求到反向代理服务器中，因为当网站访问量非常大，网站
越来越慢，一台服务器已经不够用了。于是将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。此时，客户端不是直接通过 HTTP 协议访问某网站应用服务器，而是先请求到 Nginx，Nginx 再请求应用服务器，然后将结果返回给客户端，这里 Nginx的作用是反向代理服务器。同时也带来了一个好处，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。
如图所示：
通过 Nginx 的反向代理，我们到达了 web 服务器，服务端脚本处理我们的请求，访问我们的数据库，获取需要获取的内容等等，当然，这个过程涉及很多后端脚本的复杂操作。
**********************扩展知识***************************************************************
什么是反向代理？
客户端本来可以直接通过 HTTP 协议访问某网站应用服务器，网站管理员可以在中间加上一个 Nginx，客户端请求 Nginx，Nginx 请求应用服务器，然后将结果返回给客户端，此时Nginx 就是反向代理服务器。
**********************扩展知识***************************************************************
web服务器Tomcat请求响应全过程
https://blog.csdn.net/qq_39385706/article/details/78166529
https://blog.csdn.net/sky_100/article/details/77541968
https://blog.csdn.net/leileibest_437147623/article/details/85287568
https://blog.csdn.net/moakun/article/details/78638658
第七步：服务器返回一个 HTTP 响应
经过前面的 6 个步骤，服务器收到了我们的请求，也处理我们的请求，到这一步，它会把它的处理结果返回，也就是返回一个 HTPP 响应。
HTTP 响应与 HTTP 请求相似，HTTP 响应也由 3 个部分构成，分别是：
l 状态行
l 响应头(Response Header)
l 响应正文
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
＜html＞
＜head＞
＜title＞http＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞
1）状态行：
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK \r\n
-- 协议版本：是用 http1.0 还是其他版本
-- 状态描述：状态描述给出了关于状态代码的简短的文字描述。比如状态代码为 200 时的描述为 ok
-- 状态代码：状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。如下：
1xx：信息性状态码，表示服务器已接收了客户端请求，客户端可继续发送请求。
2xx：成功状态码，表示服务器已成功接收到请求并进行处理。
3xx：重定向状态码，表示服务器要求客户端重定向。
4xx：客户端错误状态码，表示客户端的请求有非法内容。
5xx：服务器错误状态码，表示服务器未能正常处理客户端的请求而出现意外错误。
2)响应头：
响应头部：由关键字/值对组成，每行一对，关键字和值用英文冒号":"分隔，典型的响应头有：
3)响应正文包含着我们需要的一些具体信息，比如 cookie，html,image，后端返回的请求数据等等。
这里需要注意，响应正文和响应头之间有一行空格，表示响应头的信息到空格为止，下图是fiddler 抓到的请求正文，红色框中的：响应正文：
第八步：浏览器显示 HTML
在浏览器没有完整接受全部 HTML 文档时，它就已经开始显示这个页面了，浏览器是如何把页面呈现在屏幕上的呢？不同浏览器可能解析的过程不太一样，这里我们只介绍webkit 的渲染过程，下图对应的就是WebKit 渲染的过程，这个过程包括：
解析 html 以构建 dom 树
-> 构建 render 树
-> 布局 render 树
-> 绘制 render 树
浏览器在解析 html 文件时，会”自上而下“加载，并在加载过程中进行解析渲染。
解析过程中，如果遇到请求外部资源时，如图片、外链的 CSS、iconfont 等，请求过程是异步的，并不会影响 html 文档进行加载。
解析过程中，浏览器首先会解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和 repain(重绘)。
DOM 节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为 relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为 repain。
页面在首次加载时必然会经历 reflow 和 repain。reflow 和 repain 过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少 reflow 和 repain。
当文档加载过程中遇到 js 文件，html 文档会挂起渲染（加载解析渲染同步）的线程，不仅要等待文档中 js 文件加载完毕，还要等待解析执行完毕，才可以恢复 html 文档的渲染线程。因为 JS 有可能会修改 DOM，最为经典的 document.write，这意味着，在 JS 执行完成前，后续所有资源的下载可能是没有必要的，这是 js 阻塞后续资源下载的根本原因。所以我明平时的代码中，js 是放在 html 文档末尾的。
JS 的解析是由浏览器中的 JS 解析引擎完成的，比如谷歌的是 V8。JS 是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。但是又存在某些任务比较耗时，如 IO 读写等，所以需要一种机制可以先执行排在后面的任务，这就是：同步任务(synchronous)和异步任务(asynchronous)。JS 的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务，异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行，形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件；脚本运
行时先依次运行执行栈，然后会从任务队列里提取事件，运行任务队列中的任务，这个过程是不断重复的，所以又叫做事件循环(Event loop)。
第九步：浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS 等等）
其实这个步骤可以并列在步骤 8 中，在浏览器显示 HTML 时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。这些地址都要经历一个和 HTML 读取类似的过程。所以浏览器会在 DNS 中查找这些域名，发送请求，重定向等等...不像动态页面，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取，或者可以放到 CDN 中
原文链接：https://blog.csdn.net/zhailihua/article/details/78712309
