随着Web2.0时代的到来，互联网架构从C/S架构转变为更加方便，快捷的B/S架构，B/S网络架构是基于统一的应用层协议HTTP来交互数据。所以，对于程序员们来说，掌握HTTP是非常重要的。
曾经，有哥移动端的开发的同学问过我对http了解多少，正当我想和他高谈阔论时，发现自己理解的很杂乱，没有体系，所以，这篇文章将是我对HTTP的个人理解总结。
访问网页的流程
当我们想访问一些网站时，我们一般会输入一个URL，例如当我们打开浏览器，输入百度的网址，这个时候，我们的浏览器会先分析这个URL上面的域名，通过DNS服务器查询出域名映射的IP地址，然后根据这个IP地址与Web服务器进行通信，服务器再将文件传给客户端。
浏览器分析这个URL域名时，使用的就是DNS域名解析。那么得到IP地址后又是怎样去和Web服务器进行通信的呢，这里就是使用的HTTP协议，而HTTP就是构建在TCP/IP协议之上的。
DNS域名解析
首先，让我们先来看看DNS时如何解析的。
DNS域名解析过程
- 当用户在浏览器中输入域名并按下回车键后，浏览器会检查缓存中有没有每个域名对应的IP地址，若缓存有，解析结束；没有，进入下一步。
注：通过chrome://net-internals/#dns来查看chrome浏览器的缓存
- 如果浏览器缓存中没有，浏览器会找操作系统缓存中是否有这个映射，有解析结束(操作系统也有个域名解析过程)；没有，进入下一步。
注：windows系统下，可通过命令行下ipconfig /displaydns查看
- 操作系统将这个域名发送到本地区的域名服务器。
- 若还没有，就直接到根域名服务器。
- 并如图所示的进行迭代查询，当然也有递归查询。
- 正常情况下(不正常的情况就是没找到呗)，查找到域名，返回该域名对应的ip和TTL值，本地域名服务器将缓存这个域名和ip的关系，缓存时间由TTL控制
- 本地域名服务器再把解析的结果返回给用户，用户根据TTL值缓存再本地系统。至此，DNS解析结束。
以上过程是理论上的，实际上，还有有可能一些大公司的网站因为会有很多人访问，所以他们的IP不止一个，++也就是说一个域名对应多个IP地址++。
简单了解DNS缓存
如上所说DNS域名解析后会缓存解析结果，主要再两个地方缓存，一个是本地域名服务器，还有就是本地机器，这两个都是用TTL来控制时间的
TCP/IP协议
接着上面的例子，现在，我们通过DNS解析得到了目标网站的IP地址了，接着就该真正地与Web服务器建立连接了，让我们看看它是怎么做到的。
开始之前，我们要知道什么是TCP/IP协议
协议族分层
| 应用层 | HTTP |
| 传输层 | TCP |
| 网络层 | IP |
| 链路层 | 网络 |
为什么分层:
分层的好处是把各个相对独立的功能解耦，层与层之间通过规定好的接口来通信。如果以后需要修改或者重写某一个层的实现，只要接口保持不变也不会影响到其他层的功能。
在这里就不细谈TCP/IP的层次结构了。。直接来张图看看用户数据如何经过这些层次结构来封装为物理层可以传输的比特流吧。
==现在，我们拿到了IP地址，这时，浏览器会以一个随机端口(1024--65535)向服务器WEB程序80端口发起TCP连接请求，如上图所示，这个连接请求经过层层包装达到进入网卡，然后进入内核的TCP/IP协议栈(识别连接请求，解封包，剥开)，进行连接，TCP连接建立有三次握手：==
TCP三次握手：
让我们专注于传输层，TCP协议是面向连接的，那么，我们先来看看他们是如何进行连接的
第一次握手：客户端发送带有SYN标志的连接请求报文段，然后进入SYN_SEND状态，等待服务端的确认。
第二次握手：服务端接收到客户端的SYN报文段后，需要发送ACK信息对这个SYN报文段进行确认。同时，还要发送自己的SYN请求信息。服务端会将上述的信息放到一个报文段（SYN+ACK报文段）中，一并发送给客户端，此时服务端将会进入SYN_RECV状态。
第三次握手：客户端接收到服务端的SYN+ACK报文段后，会想服务端发送ACK确认报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED状态，完成TCP三次握手。
三次握手之后，就建立了连接，举个例子；三次握手相当于两个人想要说话：
- 第一次(客户端)：在么，我要说话咯，能听到吗？
- 第二次(服务器)：在的，能听到，说吧。
- 第三次(客户端)：好的，我想说。。。。。
HTTP解析
HTTP请求报文
通过上述操作，我们浏览器终于和服务器建立了连接，也就是说浏览器现在能够发送http请求了，但是，一个http请求到底有那些东西呢？
HTTP请求报文解剖
HTTP请求报文有三部分组成(请求行+请求头+请求体)
举个例子：小李的快递到了，快递员来电话说今天八点之前到勤奋鸟公司取快递，取号是6666。
这里，快递小哥就是客户端，小李就是服务器，取快递相当于就是HTTP请求体，“八点之前来勤奋鸟公司取”，“取号是6666”就是请求头
下面，让我们重点来关注请求头
请求头：
这就是大名鼎鼎的Request Header了，他控制着互联网成千上万的用户的传输，更重要的是他控制着浏览器的渲染行为和服务器的执行逻辑。
常见的请求头属性：
这些头信息都可以在chrome浏览器网络中调试，查看
| 请求头 | 说明 |
| Accept | 这个属性用来告诉服务器客户端接收什么类型的响应 |
| Accept-Encoding | 用于指定可接受的内容编码 |
| Accept-Language | 指定一种语言，例如:Accept-Language:zh-cn |
| Cache-Control | 对缓存进行控制 |
| Connection | 当前连接是否保持 |
| Cookie | 通过这个属性客户端的Cookie传给服务器 |
| Host | 指定被请求资源的Internet主机和端口号 |
| Upgrade-Insecure-Requests | (仅了解)Upgrade-Insecure-Requests: 1，告诉服务器浏览器可以处理https协议 |
| User-Agent | 客户端将它的操作系统、浏览器和其他属性告诉服务器 |
HTTP响应报文
好的，现在，客户端的请求也发送了，服务器也收到了，正常情况下，服务器肯定要回应，现在，我们再来看看服务器是如何响应http请求的
响应报文结构
HTTP响应报文也由三部分组成(响应行+响应头+响应体)
响应状态码
和请求报文相比，响应报文多了状态码，写程序的小伙伴对他应该是很熟悉了。
常见的HTTP响应状态码
| 200 | 请求成功 |
| 302 | 临时跳转，跳转的地址通过Location指定 |
| 303 | 重定向到其他页面，URL通过响应头的Location告诉客户端 |
| 304 | 采用本地缓存访问 |
| 400 | 客户端请求有语法问题，不能被服务器识别 |
| 403 | 服务器收到请求，拒绝提供服务 |
| 404 | 找不到访问路径 |
| 500 | 服务器发生错误 |
常见HTTP响应头
| Server | 使用的服务器名称 |
| Content-Type | 指明发送给接收者的实体正文的媒体类型，如：Content-Type:text/html |
| Content-Encoding | 与请求头的这个字段对应 |
| Content-Language | 与请求头的这个字段对应 |
| Content-Length | 指明实体正文长度 |
| Keep-Alive | 保持连接时间 |
| Cache-Control | 告诉客户端控制响应内容缓存 |
| ETag | 响应服务器端资源版本的属性 |
| Location | 重定向的地址 |
| Set-Cookie | 设置客户端cookie |
好的，那么，一次http请求服务器返回也就结束了，我们了解了它是如何从域名一步步解析成IP地址然后又是如何得到服务器的数据的。
最后，本人萌新，如有错误，欢迎指出，我会及时改正。谢谢。。。
