我将该过程分为了以下六步：
1. DNS域名解析
- 在浏览器DNS缓存中搜索
- 在操作系统DNS缓存中搜索
- 读取系统hosts文件，查找其中是否有对应的ip
- 向本地配置的首选DNS服务器发起域名解析请求
2. 建立TCP连接
为了准确地传输数据，TCP协议采用了三次握手策略。发送端首先发送一个带SYN（synchronize）标志的数据包给接收方，接收方收到后，回传一个带有SYN/ACK(acknowledegment)标志的数据包以示传达确认信息。最后发送方再回传一个带ACK标志的数据包，代表握手结束。在这过程中若出现问题中断，TCP会再次发送相同的数据包。
TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。
3. 发起HTTP请求
浏览器发起HTTP请求报文，报文分为报文头和报文体。
报文头包括：
- 请求的方法（get、post等等）
- URI
- Http版本
- Host请求资源所处的互联网主机名和端口
- User-Agent浏览器和用户代理名称等信息
- Cache-Contol 操作缓存机制
- Cookie信息
具体参考下图：
4. 接受响应结果
服务器接受到请求后会返回响应报文，浏览器接受处理，响应报文也分报文头和报文体，具体如下：
报文头中包含响应状态码，表示网页服务器的http响应状态：
消息（1字头）
1*类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。
略
成功（2字头）
这一类型的状态码，代表请求已成功被服务器接收、理解、并接受
- 200 OK
- 请求已成功，请求所希望的响应头或数据体将随此响应返回。
- 204 No Content
- 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。
- 如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。
- 由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。
- 206 Partial Content
- 服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
- 301 Moved Permanently
- 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
- 新的永久性的URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
- 如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。