HTTP协议学习笔记

1.HTTP协议的基本概念

1.1 HTTP协议的概念

        HTTP协议（Hyper Text Transfer Protocol，超文本传输协议），是用于从万维网服务器传输超文本到客户端浏览器的传输协议。规定了从服务器到浏览器之间传输超文本信息的规则。         HTTP协议属于应用层协议，主要由请求和响应构成，它承载与TCP协议之上。有时HTTP也承载与SSL和TSL之上，此时我们常称之为HTTPS。

1.2 HTTP协议的特点

        HTTP的特点主要由以下几点：

• 简单快速。客户端发送请求时，只需要传送请求方法和路径即可。
• 灵活。HTTP可以传输任意类型的数据对象，使用Content-Type可以指定请求体类型。
• 无连接。HTTP1.0限制每次请求只处理一个请求，服务器处理完请求，并收到客户端的应答就会断开连接；HTTP1.1则使用了持续连接，使得一个连接可以传输多个对象。
• 无状态。无状态就是协议对事物处理没有记忆能力，这就表示如果后面的处理需要运用前面请求的信息，则必须重传。在HTTP1.1之后，HTTP协议默认开启keep-alive，使得连接可以保持一定的时间。
• 支持B/S和C/S模式。支持基本认证和安全认证。

1.3 HTTP工作流程

        HTTP的一次请求和处理即为一个事务，其工作流程主要分为四步：

1. 首先客户端和服务端建立连接。在浏览器上，点击一个超链接，HTTP就开始工作；
2. 建立连接后，客户端发送一个请求消息给服务端；
3. 服务端接收到请求后，进行处理，并返回响应信息；
4. 客户端收到响应信息后，进行解析，并在浏览器中进行显示。

2. HTTP协议的构成

2.1 URI、URN和URL

        URI（Uniform Resource Identifier，统一资源标识符），用来唯一的标识一个资源。URI由三部分组成：a.访问资源的命名机制；b.存放资源的主机名；c.资源的路径，着重强调于资源。         URN（Uniform Resource Name，统一资源名称），通过名字来标识资源。如mailto:[e-mail].         URL（Uniform Resource Locator，统一资源定位符），可以唯一标识这个资源，还可以定位这个资源的位置。主要组成部分有：a.协议名称；b.存有该资源的主机地址，包括端口号；c.资源的具体位置。         URI是以一种抽象的、高层次概念定义的资源标识，而URL和URN是具体的资源标识方式。         URL的组成：

• 协议部分：从开始到":"部分，如“HTTP:”，后面跟上“//”。
• 域名部分：可以使用域名和IP来表示。
• 端口部分：域名之后，加上冒号，之后可以跟上端口号，HTTP默认端口为80，HTTPS默认端口为443.
• 虚拟路径部分：从第一个"/"之后到最后一个"/"之前的部分表示了资源的路径。
• 文件名部分：从最后一个"/"之后到"?"之前的部分。
• 参数部分：从"?"之后到"#"之前的部分表示了所有的参数，参数的形式为key=value，多个参数之间用"&"连接。
• 锚部分：从"#"到最后的部分。

2.2 请求方法（Method）

        HTTP协议定义了多种请求方法，具体包括如下几种：

• GET：请求指定的页面信息，并返回响应实体，常用于查询资源。
• POST：向指定资源提交数据进行处理，如提交表单等；数据包含在消息体中，POST请求一般用于创建或修改资源等请求。
• PUT：向指定资源位置上传最新的数据，常用于修改资源。
• HEAD：类似于GET，只不过不会返回响应实体，只能用于获取头部信息。
• DELETE：删除指定的资源。
• PATCH：用来将局部修改应用于某一资源。
• TRACE：回显服务器收到的请求，主要用于测试或诊断。
• OPTIONS：返回服务器针对资源所支持的请求方法；也可以利用Web服务器发送“*”的请求来测试服务器的性能。
• CONNECT：HTTP1.1协议中预留给能够将连接改为管道方式的代理服务器。

    注意：GET和POST的区别

1. GET提交的数据会以参数形式放到URL后，使用？与URL分隔；而POST提交的数据则会方法请求消息体中。
2. GET由于提交的数据会放在URL之后，所以数据的大小有限制；而POST没有。
3. GET方式使用Request.QueryString来获取变量值；而POST使用Request.Form来获取值。
4. GET提交方式会带来安全性问题，如提交用户和密码时，可以在URL上显示密码的值。

2.3 请求（Request）

        请求消息体主要包含四个部分：请求行、请求头部、空行、请求主体。具体格式如下图所示：

2.4 响应（Response）

        响应消息体也包含四部分：响应行、响应头部、空行、响应消息主体。具体格式如下图所示：

2.5 头域（HEADER）

        HTTP的头域通常包括通用头、请求头、响应头和实体头四部分。每个头域都由域名、冒号和域值组成，域名忽略大小写。常用的头域主要有以下几种： 1. 通用头域         Cache-Control：指定请求和响应遵循的缓存机制。         Date：表示消息发送的时间。         Pragam：用来包含实现特定的指令，常用的有Pragam:no-cache，这与Cache-Control:no-cache一致。         2. 请求头域         Host：指定请求资源的主机和端口号。         Referer：允许客户端指定URI的源资源地址，这样就可以允许服务器生成回退链表，可用来登录、优化Cache等。         Range：可以请求实体的一个或多个子范围。         User-Agent：包含请求的用户信息。         3.响应头域         Location：用于重定向到一个新URL地址。         Server：包含处理请求的原始服务器的软件信息等。         4.实体头域         Content-Type：请求主体的类型。         Accept：响应主体的类型。

2.6 状态码

        HTTP状态码表示了web服务器响应HTTP请求的状态的3位数字代码。主要分为以下几种：

• 1xx：服务器已收到请求，但还需要进一步处理。
• 2xx：请求处理成功。
• 3xx：完成请求还需要进一步操作。
• 4xx：请求包含一个错误语法或不能完成。
• 5xx：服务器内部错误。

        常用的HTTP响应状态码有：        200：操作成功；201：已创建；202：已收到请求，但还未处理完；401：未授权；404：找不到资源；500：服务器内部错误；502：网关错误。

3. 缓存机制

        Web缓存（cache）主要作用于Web服务器和浏览器之间。缓存会根据请求保存输出的资源内容；当下一个请求到来时，如果是相同的URL，则直接使用缓存的数据，只有当缓存中的数据失效才会重新发送请求到服务器端重新获取数据。缓存可以减少延迟和网络带宽的消耗。浏览器缓存主要有两种：强制缓存和对比缓存。

3.1 强制缓存

        强制缓存是指，在缓存中数据未失效时，可以直接使用缓存数据；而在缓存失效后，则直接请求服务器获取相应的数据和缓存规则。此时，缓存规则主要包含在响应消息头部。在Header中，有两个字段用来表示缓存失效规则（HTTP1.0中常使用Expires，HTTP1.1中常使用Cache-Control）。        Expires返回的是服务器指定的缓存数据到期时间。即如果下一次的请求时间小于Expires的值则使用缓存数据；如果到期，则重新请求。        Cache-Control是一种重要的缓存失效规则，其主要的值有如下几种：

• private：客户端可以缓存，Cache-Control默认值。
• public：客户端和服务端都可以缓存。
• max-age：缓存的内容会在指定秒后失效。
• no-cache：需要使用对比缓存来验证数据。
• no-store：所有内容都不会缓存，强制缓存和对比缓存都不会触发。

3.2 对比缓存

        对比缓存需要通过比较判断是否可以使用缓存。浏览器第一次请求数据时，服务器会将数据和缓存规则标识一起返回到浏览器中，浏览器将二者备份到缓存中；再次请求时，客户端将备份的缓存标识发送给服务器端，服务器端进行判断，判断通过后，返回304状态码，通知浏览器判断通过，可以使用缓存数据。
        HTTP定义了3种缓存机制：
        1）Freshness：允许一个回应消息可以在源服务器不被重新检查，并且可以由服务器和客户端来控制。例如，Expires回应头给了一个文档不可用的时间。Cache-Control中的max-age标识指明了缓存的最长时间；
        2）Validation：用来检查以一个缓存的回应是否仍然可用。例如，如果一个回应有一个Last-Modified回应头，缓存能够使用If-Modified-Since来判断是否已改变，以便判断根据情况发送请求；
        3）Invalidation： 在另一个请求通过缓存的时候，常常有一个副作用。例如，如果一个URL关联到一个缓存回应，但是其后跟着POST、PUT和DELETE的请求的话，缓存就会过期。

4. Cookie和Session

        Cookie和Session都是为了用来保存状态信息的，都是用来保存客户端状态的机制，它们都是为了解决HTTP无状态的问题而提出的方案。Session可以使用Cookie来实现，也可以使用URL的回写机制来实现。        Cookie和Session主要的区别有以下几点：

1. Cookie将状态保存在客户端、浏览器上；而Session将状态保存在服务器端。
2. Cookie是服务器在本地浏览器或客户端上存储的一小段文本，并随每个请求发送到同一个服务器；网络服务器用HTTP头向客户端发送Cookie，浏览器解析这些Cookie并将其保存为一个本地文件。而Session并没有在HTTP协议中定义。
3. Session是针对每一个用户的，变量的值保存在服务器上，用一个SessionID来区分是哪个用户的session变量，这个值是通过浏览器在访问的时候发送到浏览器的，当客户禁用Cookie时，这个值也可以由GET方法发送给服务器。
4. 就安全性来说，Session机制比Cookie机制更加安全，因为Session不会任意读取客户存储的信息。

5. Token认证机制原理

        Token，令牌，具有随机性，不可预测。Token认证主要有两个作用：1. 防止表单重复提交；2. anti csrf攻击（跨站点请求伪造）。下面介绍一种Token的生成原理，该Token的产生过程主要分为以下几个步骤：

1. 将载荷payload和header信息通过base64进行加密，形成payload密文和header密文；
2. 将形成的密文用句点连接起来，用服务端密钥进行HS256加密，生成签名；
3. 将前面两个密文用句点连接签名生成最终的Token返回给服务端。

        客户端在发送请求进行Token认证时，主要分为以下几步：

1. 客户端用户进行登录，如果验证通过，则生成Token并返回给客户端；
2. 客户端保存Token以进行请求认证；
3. 客户端每次发送请求时，都会携带保存的Token；
4. 服务器端在接收到请求时，首先进行Token验证；如果验证通过，则继续进行请求的处理；如果验证不通过或Token过期，则需要重新获取Token。