HTTP协议

HTTP常见状态码

200 请求成功
301 永久重定向 302 临时重定向 304 直接使用了缓存的资源
400 请求错误(格式，参数有误) 403 权限不够 404 找不到路径对应的资源
500 服务器执行请求时出现错误(代码逻辑错乱) 503服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

HTTP与HTTPS的区别：

所以安全上存在以下三个风险：

  • 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
  • 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
  • 冒充风险，比如冒充淘宝网站，用户钱容易没。

（1）HTTPS是密文传输，HTTP是明文传输；
（2）默认连接的端口号是不同的，HTTPS是443端口，而HTTP是80端口；
（3）HTTPS请求的过程需要CA证书要验证身份以保证客户端请求到服务器端之后，传回的响应是来自于服务器端，而HTTP则不需要CA证书；
（4）HTTPS=HTTP+加密+认证+完整性保护。
计算机网络Http总结 - 图2
上述过程就是两次HTTP请求，其详细过程如下：
1.客户端想服务器发起HTTPS的请求，连接到服务器的443端口；
2.服务器将非对称加密的公钥传递给客户端，以证书的形式回传到客户端
3.服务器接受到该公钥进行验证，就是验证2中证书，如果有问题，则HTTPS请求无法继续；如果没有问题，则上述公钥是合格的。（第一次HTTP请求）客户端这个时候随机生成一个私钥，成为client key,客户端私钥，用于对称加密数据的。使用前面的公钥对client key进行非对称加密；
4.进行二次HTTP请求，将加密之后的client key传递给服务器；
5.服务器使用私钥进行解密，得到client key,使用client key对数据进行对称加密
6.将对称加密的数据传递给客户端，客户端使用非对称解密，得到服务器发送的数据，完成第二次HTTP请求。

对称加密算法和非对称加密算法的区别

  1. 对称加密算法加密和解密使用的密钥的是相同的，也就是只有一个密钥，
  2. 而非对称加密算法有两个密钥，也就是加密和解密所使用的密钥是不同的

对称加密算法
优点:算法公开、计算量小、加密速度快、加密效率高，但不是特别安全
非对称加密算法:
优点:安全 缺点: 速度较慢

GET和POST是HTTP请求的两种基本方法，

而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。
最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。
GET请求会被浏览器主动cache，而POST不会，除非手动设置
GET请求只能进行url编码，而POST支持多种编码方式
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
GET请求在URL中传送的参数是有长度限制的，而POST么有。
Get请求是天然幂等，安全的，不会出现幻读，脏读等问题
http请求包含请求行/状态行、请求头、请求体。
request如果是post才有请求体，get则没有请求体，直接跟在？后面，用&隔开。

  1. 生成方式get方式有四种：1）直接在URL地址栏中输入URL。2）网页中的超链接。3）form中method为get。4）form中method为空时，默认是get提交。
    post只知道有一种：form中method属性为post

2、数据传送方式
get方式：表单数据存放在URL地址后面。所有get方式提交时HTTP中没有消息体。
post方式：表单数据存放在HTTP协议的消息体中以实体的方式传送到服务器。
POST方式：适合大规模的数据传送。因为是以实体的方式传送的。
3.安全性
GET方式：安全性差。因为是直接将数据显示在地址栏中，浏览器有缓冲，可记录用户信息。所以安全性低。
POST方式：安全性高。因为post方式提交数据时是采用的HTTP post机制，是将表单中的字段与值放置在HTTP HEADER内一起传送到ACTION所指的URL中，用户是看不见的。
Get请求是不幂等，不安全的，会出现幻读，脏读等问题
4、缓存性：
get请求是可以缓存的
post请求不可以缓存
5、刷新后
get请求页面后退时，不产生影响
post请求页面后退时，会重新提交请求
5、传输数据的大小
get一般传输数据大小不超过2k-4k（根据浏览器不同，限制不一样，但相差不大）
post请求传输数据的大小根据php.ini 配置文件设定，也可以无限大。

HTTP缓存

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

什么是强制缓存？

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

什么是协商缓存？

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。上图就是一个协商缓存的过程，所以协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。
协商缓存可以基于两种头部来实现。

什么是Http协议无状态协议?怎么解决？

无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
也就是说，当客户端一次HTTP请求完成以后，客户端再发送一次HTTP请求，HTTP并不知道当前客户端是一个”老用户“。
可以使用Cookie来解决无状态的问题，Cookie就相当于一个通行证，第一次访问的时候给客户端发送一个Cookie，当客户端再次来的时候，拿着Cookie(通行证)，那么服务器就知道这个是”老用户“。

Cookie 和 Session 有什么区别？

  1. cookie数据存放在客户的浏览器上，session数据放在服务器上。
  2. 当访问增多，会比较占用服务器的性能，考虑到服务器性能方面，应当使用cookie。cookie不是很安全
  3. 单个cookie保存的数据不能超过4K 当然可以通过url重写来摆脱cookie

所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中

TCP 和 UDP 的区别

  • TCP 是面向连接的，UDP 是面向无连接的
  • UDP程序结构较简单
  • TCP 是面向字节流的，UDP 是基于数据报的
  • TCP 保证数据正确性，UDP 可能丢包 是有边界的，但可能会丢包和乱序。
  • TCP 保证数据顺序，UDP 不保证

5. 首部开销

  • TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
  • UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

  • 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
  • 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；

  • 字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

    UDP应用场景：

    举几个例子：QQ聊天、在线视频、网络语音电话

    TCP应用场景：

    举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

    UDP为何无连接？

    相对于tcp每次建立连接时，客户端套接口和服务器套接口需要长期建立连接不中断，一个端口只能每次接收到来自同一个服务器的数据。而udp每个客户端端口，并不需要跟服务器端口建立长期的连接，可以每次向一个服务器端口发起申请，然后下一次再向另外一个服务器端口申请接收数据，这样，一个udp服务器接口可以一段时间内接受多个客户端发送的请求，一个客户端接口也可以短时间内接收多个服务端发来的数据。
    因为连接的长期和短期这一区别，我们称udp和tcp分别是无连接的和面向连接的服务。

    确保传输可靠性的方式

    TCP协议保证数据传输可靠性的方式主要有：

  • 校验和

  • 序列号
  • 确认应答
  • 超时重传
  • 流量控制
  • 拥塞控制

    校验和（保证数量）

计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
因为tcp是分包传送的，而校验和主要是检查包的数量的，底层是转成16位整数相加减，计算总数量，比如15个包，最后检验15个包，说明初步判断是正确的，没丢失

确认应答与序列号（保证顺序）

序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。
确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

超时重传（保证丢失的再发正确，补救措施）

在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？
首先，发送方没有介绍到响应的ACK报文原因可能有两点：
数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。

1.什么是流量控制

防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理）
滑动窗口是类似于一个窗口一样的东西，是用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小，这样就可以实现
ps：窗口指的是一次批量的发送多少数据
作用：使用滑动窗口，就可以一次发送多条数据，从而就提高了性能
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据
操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉
（5）接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端收到这个值后，就会减慢自己的发送速度
（6）如果接收端发现自己的缓冲区满了，就会将窗口的大小设置为0，此时发送端将不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

2.什么是拥塞控制

防止发送方发的太快，使得网络来不及处理，从而导致网络拥塞

慢开始

  1. 慢开始不是指cwnd的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1。
  2. 不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。这里用报文段的个数的拥塞窗口大小举例说明慢开始算法

当cnwd＞ssthresh，使用拥塞避免算法

拥塞避免（按线性规律增长）

1.拥塞避免并非完全能够避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，

快重传（检测网络状态的）

快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复（与快重传配合使用）

把ssthresh门限减半。但是接下去并不执行慢开始算法。
窗口减半然后直接按线性增加
3.考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。

整体过程流程图

计算机网络Http总结 - 图3

不同点

（1）**丢包位置不同流量控制丢包位置是在接收端上拥塞控制丢包位置是在路由器上**（2）**作用的对象不同**流量控制的对象是接收方，怕发送方发的太快，使得接收方来不及处理
拥塞控制的对象是网络，怕发送发发的太快，造成网络拥塞，使得网络来不及处理

1.一次完整的HTTP

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：
建立TCP连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断TCP连接

三次握手（SYN）和四次挥手（FIN） 序列号ISN

计算机网络Http总结 - 图4
第一次握手：客户端发送网络包，服务端收到了。
第二次握手：服务端发包，客户端收到了。
第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。 （防止恶意攻击） 第一次、第二次握手不可以携带数据
半连接队列 ：此时双方还没有完全建立其连接，放在一个队列中
和 全 SYN-ACK 重传次数（指数） 最大重传次数 该连接信息从半连接队列中删除

四次挥手

计算机网络Http总结 - 图5
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态

2.1 挥手为什么需要四次？

但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET
所以只能先回复一个ACK报文，告诉客户端

2.2tcp三次握手，为什么不能两次？

三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

网络环境是错综复杂的，往往并不是如我们期望的一样，先发送的数据包，就先到达目标主机，反而它很骚，可能会由于网络拥堵等乱七八糟的原因，会使得旧的数据包，先到达目标主机，那么这种情况下 TCP 三次握手是如何避免的呢？
客户端连续发送多次 SYN 建立连接的报文，在网络拥堵情况下：
一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
那么此时服务端就会回一个 SYN + ACK 报文给客户端；
客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：
如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；
所以，TCP 使用三次握手建立连接的最主要原因是防止历史连接初始化了连接。

原因二：同步双方初始序列号

TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：
接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中， 哪些是已经被对方收到的；
可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
计算机网络Http总结 - 图6

2.3 四次挥手释放连接时，等待2MSL的意义?

客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态

1.保证客户端发送的最后一个ACK报文段能够到达服务端。
MSL即报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
以确保报文已被自然消亡。

原因一：防止旧连接的数据包

假设 TIME-WAIT 没有等待时间或时间过短，被延迟的数据包抵达后会发生什么呢？
计算机网络Http总结 - 图7
如上图黄色框框服务端在关闭连接之前发送的 SEQ = 301 报文，被网络延迟了。
这时有相同端口的 TCP 连接被复用后，被延迟的 SEQ = 301 抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产生数据错乱等严重的问题。
服务端在接收ack关闭之前接收到了旧的数据，等下次重新连接这个端口时，服务端有旧数据，就会直接发给客户端，造成数据混乱
所以，TCP 就设计出了这么一个机制，经过 2MSL 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

原因二：保证连接正确关闭

也就是说，TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。
计算机网络Http总结 - 图8
计算机网络Http总结 - 图9
如果 TIME-WAIT 等待足够长的情况就会遇到两种情况：
服务端正常收到四次挥手的最后一个 ACK 报文，则服务端正常关闭连接。
服务端没有收到四次挥手的最后一个 ACK 报文时，则会重发 FIN 关闭连接报文并等待新的 ACK 报文。
所以客户端在 TIME-WAIT 状态等待 2MSL 时间后，就可以保证双方的连接都可以正常的关闭。

TIME_WAIT 过多有什么危害？

如果服务器有处于 TIME-WAIT 状态的 TCP，则说明是由服务器方主动发起的断开请求。

过多的 TIME-WAIT 状态主要的危害有两种：

第一是内存资源占用；
第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口；
第二个危害是会造成严重的后果的，要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过如下参数设置指定

粘包问题

发送方：但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）
接收方：放数据的速度 > 应用层拿数据速度 就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来

解决方法：

1.特殊字符控制；
2.在包头首都添加数据包的长度。

长连接和短连接

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

Http1.0与Http1.1的区别？

  • 长连接（避免三次握手频繁）

建立一长段时间的链接，并且响应头部会加上keep alive 但是高并发的情况下不适合，资源耗费不起

  • 节约带宽（断电续传）

HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。

  • HOST域（虚拟主机）
  • 举个栗子，我有一台服务器A ip地址为120.79.92.223,有三个分别为www.baidu.com、www.google.com、www.sohu.com的域名解析到了这三个网站上，当我们通过http://www.baidu.com这个网址去访问时，DNS解析出的ip为120.79.92.223，这时候服务器就是根据请求头中的host字段选择使用www.baidu.com这个域名的网站程序对请求做响应。

  • 错误通知的管理**（更多的状态码）**

    在HTTP1.1中新增了24个错误状态响应码，如：410 表示服务器上的某个资源被永久性的删除。

    Http1.1与Http2的区别？

  • 多路复用(只需一个连接便可实现并行)

做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级
计算机网络Http总结 - 图10

  • 使用头部压缩，降低了开销
  • 服务器可以主动推送给客户端缓存中
  • 采用二进制方式而非文本格式

网络五层模型

计算机网络Http总结 - 图11

1. 物理层

物理层负责把两台计算机连起来，然后在计算机之间通过高低电频来传送0,1这样的电信号。

2. 数据链路层 1. 以太网协议

解读0 1 比特流，一组电信号构成一个数据包，我们把这个数据包称之为帧

3. 网络层 ARP协议 (1). 广播 MAC 地址 1. IP协议

网络层的功能就是让我们在茫茫人海中，能够找到另一台计算机在哪里，是否属于同一个子网等。
主机到主机通信
那么问题来了，我们如何区分哪些 MAC 地址是属于同一个子网的呢？假如是同一个子网，那我们就用广播的形式把数据传送给对方，如果不是同一个子网的，我们就会把数据发给网关，让网关进行转发。为了解决这个问题，于是，有了 IP 协议。

4. 传输层 TCP 协议和 UDP 协议

计算机B里面有各种各样的应用程序，计算机该如何知道这些数据是给谁的呢
传输层的功能就是建立端口到端口的通信。相比网络层的功能是建立主机到主机的通信

5. 应用层 HTTP协议，HTTPS，电子邮件协议

有html格式的，有mp4格式的，各种各样。你确定你能看的懂？
因此我们需要指定这些数据的格式规则，收到后才好解读渲染。例如我们最常见的 Http 数据包中，就会指定该数据包是 什么格式的文件了。

输入一条URL发生了什么？

浏览器做的第一步工作是解析 URL
02 真实地址查询 —— DNS
通过浏览器解析 URL 并生成 HTTP 消息后，需要委托操作系统将消息发送给 Web 服务器。

但在发送之前，还有一项工作需要完成，那就是查询服务器域名对于的 IP 地址，因为委托操作系统发送消息时，必须提供通信对象的 IP 地址。

所以，有一种服务器就专门保存了 Web 服务器域名与 IP 的对应关系，它就是 DNS 服务器。

域名解析的工作流程

客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
本地 DNS 收到顶级域名服务器的地址后，发起请求问“老二， 你能告诉我 www.server.com 的 IP 地址吗？”
顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

首先浏览器做的第一步工作就是要对 URL 进行解析，从而生发送给 Web 服务器的请求信息。
从输入网址到获得页面的过程
(1). **浏览器查询 DNS，获取域名对应的IP地址:读取本地的Host文件映射和向本地DNS服务器进行查询**等。
　(2). 浏览器获得域名对应的**IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
　(3). TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
　(4). 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
　(5).关闭TCP连接；
　(6).浏览器解析HTML
　(7). 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。**