73、HTTP协议请求过程
大致的流程：输入地址 –> DNS域名解析 –> 发起TCP的三次握手 –> 建立TCP连接后发起http请求 –> 服务器响应http请求，浏览器得到html代码 –> 浏览器解析html代码，并请求html代码中的资源（如javascript、css、图片等） –> 浏览器对页面进行渲染呈现给用户。
第一步：输入地址
当我们开始在浏览器中输入网址的时候，浏览器其实就已经在智能的匹配可能的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 请求。
第四步：服务器的永久重定向响应
服务器给浏览器响应一个 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的作用是反向代理服务器。同时也带来了一个好处，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。
第七步：服务器返回一个 HTTP 响应
经过前面的 6 个步骤，服务器收到了我们的请求，也处理我们的请求，到这一步，它会把它的处理结果返回，也就是返回一个 HTTP 响应。
第八步：浏览器显示 HTML
在浏览器没有完整接受全部 HTML 文档时，它就已经开始显示这个页面了，浏览器是如何把页面呈现在屏幕上的呢？不同浏览器可能解析的过程不太一样。
第九步：浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS 等等）
其实这个步骤可以并列在步骤 8 中，在浏览器显示 HTML 时，它会注意到需要获取其它地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。这些地址都要经历一个和 HTML 读取类似的过程。所以浏览器会在 DNS 中查找这些域名，发送请求，重定向等等...不像动态页面，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取，或者可以放到 CDN 中。
74、HTTP1.1与HTTP1.0的比较（HTTP1.1的四个新特性）
1、默认持久连接和流水线
HTTP/1.1 默认使用持久连接，只要客户端服务端任意一端没有明确提出断开 TCP 连接，就一直保持连接，在同一个 TCP 连接下，可以发送多次 HTTP 请求。同时，默认采用流水线的方式发送请求，即客户端每遇到一个对象引用就立即发出一个请求，而不必等到收到前一个响应之后才能发出下一个请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
HTTP/1.0 默认使用短连接，要建立长连接，可以在请求消息中包含Connection:Keep-Alive 头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个 Connection:Keep-Alive 的头域。Connection 请求头的值为 Keep-Alive 时，客户端通知服务器返回本次请求结果后保持连接；Connection 请求头的值为 close 时，客户端通知服务器返回本次请求结果后关闭连接。
2、分块传输数据
HTTP/1.0 可用来指定实体长度的唯一机制是通过 Content-Length 字段。静态资源的长度可以很容易地确定，但是对于动态生成的响应来说，为获取它的真实长度，只能等它完全生成之后，才能正确地填写 Content-Length 的值，这便要求缓存整个响应，在服务器端占用大量的缓存，从而延长了响应用户的时间。
HTTP/1.1 引入了被称为分块（chunked）的传输方法。该方法使发送方能将消息实体分割为任意大小的组块（chunk），并单独地发送他们。在每个组块前面，都加上了该组块的长度，使接收方可确保自己能够完整地接收到这个组块。更重要的是，在最末尾的地方，发送方生成了长度为零的组块，接收方可据此判断整条消息都已安全地传输完毕。这样也避免了在服务器端占用大量的缓存。Transfer-Encoding：chunked 向接收方指出：响应将被分组块，对响应分析时，应采取不同于非分组块的方式。
3、状态码 100 Continue
HTTP/1.1 加入了一个新的状态码 100 Continue，用于客户端在发送 POST 数据给服务器前，征询服务器的情况，看服务器是否处理 POST 的数据。
当要 POST 的数据大于 1024 字节的时候，客户端并不会直接就发起 POST 请求，而是会分为 2 步：
1）、发送一个请求，包含一个 Expect:100-continue，询问 Server 是否愿意接受数据。
2）、接收到 Server 返回的 100 continue 应答以后，才把数据 POST 给 Server。
这种情况通常发生在客户端准备发送一个冗长的请求给服务器，但是不确认服务器是否有能力接收。如果没有得到确认，而将一个冗长的请求包发送给服务器，然后包被服务器给抛弃了，这种情况挺浪费资源的。
4、Host 域
HTTP1.1 在 Request 消息头里多了一个 Host 域，HTTP1.0 则没有这个域。在HTTP1.0中认为每台服务器都绑定一个唯一的 IP 地址，这个 IP 地址上只有一个主机。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。