HTTP的请求过程
一、简单描述一次Http的请求过程
域名解析 –> 发起TCP的3次握手 –> 建立TCP连接后发起http请求 –> 服务器响应http请求，浏览器得到html代码 –> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） –> 浏览器对页面进行渲染呈现给用户
二、从域名的解析开始
这一步的目标是为了获取到服务器的IP地址，如同打电话，要让通信信号定位到对方联系人，让消息传达至对方。
①浏览器会先解析我们输入的url地址，浏览器会先搜索自身的DNS缓存，看自身的缓存中是否有对应的条目，而且没有过期，如果有且没有过期则解析到此结束。
②如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束。
③如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件（位于C:\Windows\System32\drivers\etc），看看这里面有没有该域名对应的IP地址，如果有则解析成功。
④如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器发起域名解析请求直到获取至服务器的IP地址。
注：一般情况下是不会进行以下步骤的
如果经过以上的4个步骤，还没有解析成功，那么会进行如下步骤（以下是针对Windows操作系统）：
⑤操作系统就会查找NetBIOS name Cache（NetBIOS名称缓存，就存在客户端电脑中的），那这个缓存有什么东西呢？凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址，就都会存在这个缓存里面。什么情况下该步能解析成功呢？就是该名称正好是几分钟前和我成功通信过，那么这一步就可以成功解析。
⑥如果第5步也没有成功，那会查询WINS 服务器（是NETBIOS名称和IP地址对应的服务器）。
⑦如果第6步也没有查询成功，那么客户端就要进行广播查找。
⑧如果第7步也没有成功，那么客户端就读取LMHOSTS文件（和HOSTS文件同一个目录下，写法也一样）
如果第8步还没有解析成功，那么就宣告这次解析失败，那就无法跟目标计算机进行通信。只要这8步中有一步可以解析成功，那就可以成功和目标计算机进行通信。
三、TCP的三次握手
拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序，最终建立了TCP/IP的连接。
如下图：
- Client首先发送一个连接试探，ACK=0 表示确认号无效，SYN = 1 表示这是一个连接请求或连接接受报文，同时表示这个数据报不能携带数据，seq = x 表示Client自己的初始序号（seq = 0 就代表这是第0号包），这时候Client进入syn_sent状态，表示客户端等待服务器的回复。
- Server监听到连接请求报文后，如同意建立连接，则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1，同时表明x为止的所有数据都已正确收到（ack=1其实是ack=0+1,也就是期望客户端的第1个包），seq = y 表示Server 自己的初始序号（seq=0就代表这是服务器这边发出的第0号包）。这时服务器进入syn_rcvd，表示服务器已经收到Client的连接请求，等待client的确认。
- Client收到确认后还需再次发送确认，同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效（代表期望收到服务器的第1个包），Client自己的序号seq= x + 1（表示这就是我的第1个包，相对于第0个包来说的），一旦收到Client的确认之后，这个TCP连接就进入Established状态，就可以发起http请求了。
举个例子：
假设一个老外在故宫里面迷路了，看到了小明，于是就有下面的对话：
老外： Excuse me，Can you Speak English?
小明： yes 。
老外： OK,I want …
在问路之前，老外先问小明是否会说英语，小明回答是的，这时老外才开始问路
2个计算机通信是靠协议（目前流行的TCP/IP协议）来实现,如果2个计算机使用的协议不一样，那是不能进行通信的，所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议，协商完成后就可以进行通信了，当然这样理解不是那么准确。
四、发起Http请求
Http会发起一次请求request报文，它包括：请求行（request line）、请求头部（header）、空行和请求数据这四个部分。
1.请求行
请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。
HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
而常见的有如下几种：
- GET: 完整请求一个资源 （常用）
- HEAD: 仅请求响应首部
- POST：提交表单 （常用）
- PUT: (webdav) 上传文件（但是浏览器不支持该方法）
- DELETE：(webdav) 删除
- OPTIONS：返回请求的资源所支持的方法的方法
- TRACE: 追求一个资源请求中间所经过的代理（该方法不能由浏览器发出）
2.请求头
请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：
- Accept：客户端可识别的内容类型列表。
- Accept-Encoding：声明浏览器支持的编码类型。
- Cache-Control：指定了请求和响应遵循的缓存机制。
- Connection：决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成。
- Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
- Referer：告诉服务器从哪个页面链接过来的，服务器藉此可以获得一些信息用于处理。
- Upgrade-Insecure-Requests：让浏览器自动升级请求从http到https，用于大量包含http资源的http网页直接升级到https而不会报错。
- User-Agent：产生请求的浏览器类型。
3.空行
最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。
4.请求数据
请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
五、Http响应报文
HTTP响应也由三个部分组成，分别是：状态行、相应头部、响应正文。
1.状态行
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。
- 1xx：指示信息–表示请求已接收，继续处理。
- 2xx：成功–表示请求已被成功接收、理解、接受。
- 3xx：重定向–要完成请求必须进行更进一步的操作。
- 4xx：客户端错误–请求有语法错误或请求无法实现。
- 5xx：服务器端错误–服务器未能实现合法的请求。
常见状态代码、状态描述的说明如下。
- 200 OK：客户端请求成功。
- 301: 永久重定向, Location响应首部的值仍为当前URL，因此为隐藏重定向。
- 302: 临时重定向，显式重定向, Location响应首部的值为新的URL。
- 304：Not Modified 未修改，比如本地缓存的资源文件和服务器上比较时，发现并没有修改，服务器返回一个304状态码，告诉浏览器，你不用请求该资源，直接使用本地的资源即可。
- 400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
- 401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。
- 403 Forbidden：服务器收到请求，但是拒绝提供服务。
- 404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
- 500 Internal Server Error：服务器发生不可预期的错误。
- 502: Bad Gateway 前面代理服务器联系不到后端的服务器时出现
- 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）。
- 504：Gateway Timeout 这个是代理能联系到后端的服务器，但是后端的服务器在规定的时间内没有给代理服务器响应
2.响应头部
如下是Chrome浏览器的响应头部：
Connection 使用keep-alive特性
Content-Encoding 使用gzip方式对资源压缩
Content-type MIME类型为html类型，字符集是 UTF-8
Date 响应的日期
Server 使用的WEB服务器
Transfer-Encoding:chunked 分块传输编码 是http中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分，分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供
六、最后阶段
最后浏览器会解析渲染服务器发来的HTML，结果呈现在浏览器窗口。
参考:
1.一次完整的HTTP请求过程
2.HTTP请求、响应报文格式