一个HTTP请求全过程
-
HTTP请求的完整过程：
域名解析---->与服务器建立连接---->发起HTTP请求------>服务器响应HTTP请求，浏览器得到HTML代码-->浏览器解析HTML代码，并请求HTML代码中的资源（如js、css、图片）---->浏览器对页面进行渲染呈现给用户
- 域名解析
- 浏览器会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，智能容纳1000条缓存-Chrome浏览器），看缓存中是否有对应条目，有且没有过期解析到此结束，否则执行②
- 如果浏览器自身的缓存里没有找到对应的条目，那么浏览器会搜索操作系统自身的DNS缓存，如果找到且没过期则解析到此结束，否则执行③
- 如果操作系统DNS缓存也没有找到，那么尝试读取hosts文件，看这个文件里是否有该域名对应的IP地址，如果有则解析成功，否则执行④
- 如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是电信运营商提供的）发起域名解析请求，（通过的UDP协议向DNS53端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供给我们该域名的IP地址），运营商的DNS服务器首先找自身缓存，找到对应条目且没有过期则解析成功。如果没有找到对应的条目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（这个DNS服务器内置13台根域名的DNS的IP地址），找到根域名的DNS地址发起请求，根域发现这是一个顶级域com域的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但知道com（顶级）域的IP地址，你去找它，于是运营商的DNS就得到了com域的IP地址，又向com域的IP地址发起请求，com域这台服务器告诉运营商的DNS我不知道这个域的IP地址，但是我知道权威域名服务器的IP地址，你去找它，于是运营商又向权威域名的DNS地址发起请求，这个时候权威域名服务器一查，果真在我这里，于是就把找到的结果发送给运营商的DNS服务器，这个时候运营商的DNS服务器你就拿到了这个域名对应的IP地址，并返回给系统内核，内核又把结果返回给浏览器。
如果经过以上的4个步骤，还没有解析成功，那么会进行如下步骤（以下是针对Windows操作系统）：
⑤操作系统就会查找NetBIOS name Cache（NetBIOS名称缓存，就存在客户端电脑中的），那这个缓存有什么东西呢？凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址，就都会存在这个缓存里面。什么情况下该步能解析成功呢？就是该名称正好是几分钟前和我成功通信过，那么这一步就可以成功解析。
⑥如果第⑤步也没有成功，那会查询WINS 服务器（是NETBIOS名称和IP地址对应的服务器）
⑦如果第⑥步也没有查询成功，那么客户端就要进行广播查找
⑧如果第⑦步也没有成功，那么客户端就读取LMHOSTS文件（和HOSTS文件同一个目录下，写法也一样）
如果第八步还没有解析成功，那么就宣告这次解析失败，那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功，那就可以成功和目标计算机进行通信。
原文链接：https://blog.csdn.net/u013777975/article/details/80496121
2、与服务器建立连接
客户端请求到达服务器，首先就是建立TCP连接
三次握手过程：
1）client首先发送一个连接试探，ACK=0表示确认号无效，SYN=1表示这还少一个连接请求或连接接收报文，同时表示这个数据报不能携带数据，seq=x表示client自己的初始序号（seq=0就代表这是第0号包），这时候client进入syn_sent状态，表示客户端等待服务器的回复
2）server监听到连接请求报文后，如果同意建立里阿尼额，则向client发送确认。Tcp报文首部中的SYN和ACk都置1，ack=x+1表示期望收到对方下一个报文的第一个数据字节号是x+1，同时表明x为止的所有数据都已正确收到（ack=1其实就是ack=0+1，也就是期望客户端的第一个包），syn=y表示server自己的初始序号（seq=0就是代表这是服务器这边发出的第0号包）。这时服务器进入syn_rcvd，表示服务器已经收到client的连接请求，等待client的确认。
3）client收到确认后还需要再次发送确认，同时携带要发送给server的数据。ACk置1表示确认号ack=y+1有效（代表期望接收到的服务器的第一个包），client自己的序号seq=x+1（表示这就是我的第一个包，相对于第0个包来说的），一旦收到client的确认之后，这个TCP连接就进入established，就可以发起http请求了。
TCP四次挥手：
-
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
-
第二次挥手： Server 收到 FIN 后，发送一个 ACK 给 Client ，确认序号为收到序号 +1 （与 SYN 相同，一个 FIN 占用一个序号）， Server进入 CLOSE_WAIT 状态。
-
第三次挥手： Server 发送一个 FIN ，用来关闭 Server 到 Client 的数据传送， Server 进入 LAST_ACK 状态。
-
第四次挥手： Client 收到 FIN 后， Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server ，确认序号为收到序号 +1 ， Server 进入CLOSED 状态，完成四次挥手
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
【问题3】为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
原文链接：https://blog.csdn.net/qq_38950316/article/details/81087809
3、发起HTTP请求
HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP协议进行，否则无法连接。
通俗来讲，他就是计算机通过网络进行通信的规则，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据。目前任何终端之间进行任何一种通信都必须按照HTTP协议进行，否则无法连接。
HTTP请求报文：
一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成。
1）请求行
请求行分为三个部分：请求方法、请求地址和协议版本
请求方法
HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常用的两种GET和POST，如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。
| 序号 |
方法 |
描述 |
| 1 |
GET |
请求指定的页面信息，并返回实体主体。 |
| 2 |
HEAD |
类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 |
POST |
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 |
PUT |
从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 |
DELETE |
请求服务器删除指定的页面。 |
| 6 |
CONNECT |
HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 |
OPTIONS |
允许客户端查看服务器的性能。 |
| 8 |
TRACE |
回显服务器收到的请求，主要用于测试或诊断。 |
| 9 |
PATCH |
是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
请求地址
URL:统一资源定位符，是一种自愿位置的抽象唯一识别方法。
组成：<协议>：//<主机>：<端口>/<路径>
端口和路径有时可以省略（HTTP默认端口号是80）
2）请求头部
请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。
请求头部的最后会有一个空行，表示请求头部结束，接下来为请求数据，这一行非常重要，必不可少。
3）请求数据
可选部分，比如GET请求就没有请求数据。
4、服务器响应HTTP请求，浏览器得到HTML代码
接收到HTTP请求之后，就轮到负载均衡了，它位于网站的最前端，把短时间内较高的访问量分摊到不同机器上处理。
HTTP响应报文：
HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。
1）状态行
由3部分组成，分别为：协议版本，状态码，状态码描述。
其中协议版本与请求报文一致，状态码描述是对状态码的简单描述，所以这里就只介绍状态码。
状态码
状态代码为3位数字。
1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求。
下面列举几个常见的：
HTTP状态码列表
| 状态码 |
状态码英文名称 |
中文描述 |
| 100 |
Continue |
继续。客户端应继续其请求 |
| 101 |
Switching Protocols |
切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 |
OK |
请求成功。一般用于GET与POST请求 |
| 201 |
Created |
已创建。成功请求并创建了新的资源 |
| 202 |
Accepted |
已接受。已经接受请求，但未处理完成 |
| 203 |
Non-Authoritative Information |
非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 |
No Content |
无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 |
Reset Content |
重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 |
Partial Content |
部分内容。服务器成功处理了部分GET请求 |
| 300 |
Multiple Choices |
多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 |
Moved Permanently |
永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 |
Found |
临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 |
See Other |
查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 |
Not Modified |
未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 |
Use Proxy |
使用代理。所请求的资源必须通过代理访问 |
| 306 |
Unused |
已经被废弃的HTTP状态码 |
| 307 |
Temporary Redirect |
临时重定向。与302类似。使用GET请求重定向 |
| 400 |
Bad Request |
客户端请求的语法错误，服务器无法理解 |
| 401 |
Unauthorized |
请求要求用户的身份认证 |
| 402 |
Payment Required |
保留，将来使用 |
| 403 |
Forbidden |
服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 |
Not Found |
服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 |
Method Not Allowed |
客户端请求中的方法被禁止 |
| 406 |
Not Acceptable |
服务器无法根据客户端请求的内容特性完成请求 |
| 407 |
Proxy Authentication Required |
请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 |
Request Time-out |
服务器等待客户端发送的请求时间过长，超时 |
| 409 |
Conflict |
服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 |
Gone |
客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 |
Length Required |
服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 |
Precondition Failed |
客户端请求信息的先决条件错误 |
| 413 |
Request Entity Too Large |
由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 |
Request-URI Too Large |
请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 |
Unsupported Media Type |
服务器无法处理请求附带的媒体格式 |
| 416 |
Requested range not satisfiable |
客户端请求的范围无效 |
| 417 |
Expectation Failed |
服务器无法满足Expect的请求头信息 |
| 500 |
Internal Server Error |
服务器内部错误，无法完成请求 |
| 501 |
Not Implemented |
服务器不支持请求的功能，无法完成请求 |
| 502 |
Bad Gateway |
作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 |
Service Unavailable |
由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 |
Gateway Time-out |
充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 |
HTTP Version not supported |
服务器不支持请求的HTTP协议的版本，无法完成处理 |
2）响应头部
与请求头部类似，为响应报文添加了一些附加信息
3）响应数据
用于存放需要返回给客户端的数据信息。
5、浏览器解析html代码，并请求html代码中的资源
浏览器拿到index.html文件后，就开始解析其中的HTML代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这个时候就用上keep-alive特性，建立一个HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里的顺序，但由于每个资源大小不一样，而浏览器又多线程请求资，所以显示的顺序不一定是代码里面的顺序。
浏览器在请求静态资源时（在未过期的情况下），向服务器端发起一个HTTP请求（询问自从上一次修改时间到现在有没有对资源进行修改），如果服务器端返回304状态码（告诉浏览器端没有修改），那么浏览器会直接读取本地的该资源的缓存文件。
6、浏览器对页面进行渲染呈现给用户
最后，浏览器利用自己内部的工作机制，把请求到的静态资源和html代码进行渲染，渲染之后呈现给用户。