HTTP协议简述

综述

超文本传输协议（HyperText Transfer Protocol，HTTP），是互联网应用最广泛的网络协议。最初的HTTP协议设计用于发送和接收HTML。经过发展演变成为客户端和服务器进行请求(Request)和响应(Response)的标准协议。要了解HTTP的运行过程，需要了解大体OSI模型

由下到上，OSI模型描述了整个网络架构中从基础设置到上层应用的框架。

HTTP是建立在TCP/IP协议之上的应用层协议，HTTP规定了请求和响应的报文格式，由TCP/IP协议簇进行转发，送达目标(服务器)之后，按照HTTP协议可以解析得到报文的意义，并进行响应处理。

上图描述的是一个简单的HTTP请求过程，其中HTTP主要起到的作用，就是告知客户端和服务器，如何构建报文，如何解析报文，而传输则交给下层TCP/IP协议进行。此外还有一些与通信有关系的程序，也做一下介绍：

• 代理：接收客户端发送的请求后直接转发给其他服务器(可能会被发送到下一个代理)，不会改变URI。（如果有级联的多台代理服务器，当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面添加via头部，并填上自己的相关信息，当下一个代理服务器 收到第一个代理服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via头部，并把自己的相关信息加到后面。）缓存代理：请求的内容直接从代理服务器中获取，而不必从源服务器获取。

• 网关：作用与代理类似，但是可以改变请求的协议，比如讲HTTP协议转换成为私有协议或者其他协议，在两个网关之间传输，达到加密的作用。

• 隧道：通过和HTTP CONNECT方法，构建服务器和客户端之间的通信线路，可以增加安全线

HTTP报文的构建：
发出的请求信息包括以下几个

• 请求行 方法(GET,POST等) URI(统一资源标识符) HTTP/1.1，表示请求URI代表的资源

• 请求首部字段 Host: www.qiongsong.com Accept-Language: cn Connection: keep-alive ……

• 空行

• 其他消息体

请求行和标题必须以作为结尾。空行内必须只有而无其他空格。在HTTP/1.1协议中，所有的请求头，除Host外，都是可选的。
返回的响应消息包括下面的几个部分

• 协议版本号(HTTP/1.1) 状态码(200、404) 状态码原因短语(OK)

• 响应主体

HTTP1.1 中的请求方法有以下几种

• GET: 获取资源

• POST: 传输实体主体

• PUT: 传输文件，一般不使用，因为不带验证机制，任何人都可以使用PUT来进行文件上传，可以考虑结合表征状态转移(REST Representational State Transfer)或者增加额外的验证机制来配合使用

• HEAD: 获取报文首部

• DELETE: 删除资源，与PUT一样不带有验证机制

• OPTIONS：询问支持的方法

• TRACE：追踪路径，让服务器端将之前的请求通信环回路给客户端，主要用于跟踪问题

• CONNECT：要求用隧道协议链接代理，一般配合(SSL、TLS) 使用。

状态码则主要有以下几种类别，每一种类别又有细分的状态码

• 1xx消息——请求已被服务器接收，继续处理

• 2xx成功——请求已成功被服务器接收、理解、并接受

• 3xx重定向——需要后续操作才能完成这一请求(304为资源未修改，与3XX有一点差异)

• 4xx请求错误——请求含有词法错误或者无法被执行

• 5xx服务器错误——服务器在处理某个正确请求时发生错误

无状态和Cookie

HTTP 的一种重要的特性就是协议本身是无状态的，也就是服务器在接受同一个用户发起的请求报文的时候，并无法知道这些请求是由同一个用户发送过来，也无法得知这些请求的上下文关系。而我们平时浏览网页特别是需要进行用户验证类的网页，每一次要求用户进行身份验证并不合理。为解决这个问题，就发展出Cookie技术。

Cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态。从服务器返回的报文中，通过set-cookie首部字段，添加cookie(由服务器生成，并通常做加密处理)，客户端收到返回报文之后会保存cookie，当下一次客户端向服务器发送请求的时候，会在请求中加入cookie值后发送。服务器获取到cookie之后，会对比之前服务器上的记录(session)，从而对请求进行状态识别。
cookie具有长度限制，不同的浏览器之间有细微的差异，一般不能超过4097个字节，超过这个数量的cookie在请求的时候，浏览器会直接忽略。

对于 Cookie 的安全保护是 Web 安全的一个重要因素，常见的将 Cookie 设置为 Httponly，避免js 脚本直接获取 Cookie，同时采用加密传输方式来传输内容，避免中间人攻击。

性能

性能对于传输协议而言至关重要，剥离底层 TCP 协议对传输性能的影响，在 HTTP 层面对性能影响的点有

• 浏览器：浏览器对于请求的发起可能会限制对同一域名的连接数量，导致并发请求被堵塞。

• DNS：域名到 IP 的转换速度，通常通过 DNS 缓存来解决

• 建立连接：HTTP 需要通过 TCP 三次握手建立连接，连接的高效复用，是影响 HTTP 性能的关键因素。

现在最流行的 HTTP1.1 对于程序员而言，相比于 HTTP1.0 的最大改进在于对长连接的支持，HTTP1.1 默认支持长连接和请求流水线，可以在一个 TCP 连接上传输多个 HTTP 请求，减少建立连接的延迟，体现在报文中是 Connection:keep-alive 的默认开启。

而对于内存，通过引入过期时间等，可以避免重复请求，提高相应速度。

HTTPs

HTTP 在网络上传输采用的是明文信息，可能会被恶意截获从而产生安全问题。为了解决 HTTP 的传输安全性，增加了一个 SSL （Secure Socket Layer）层，HTTPs = HTTP + SSL。

下面简单描述一下 HTTPs 是如何保证数据传输安全的。为了保证数据传输不被截获，那么需要对数据进行加密，传输过程中采用密文进行传输。加密的方法有两类：一类是对称加密，密钥只有一个，内容通过密钥加密后，只能通过这个密钥解密；另一类是非对称加密，密文通过公钥加密后，通过另一个私钥解密，密钥是成对出现的。对称加密算法效率较高，非对称加密算法较为复杂同时效率也比较低。因此 HTTPs 将两者结合起来，实现了在网络中的安全传输，大致原理是，首先通过非对称加密算法协商对称加密的密钥，后续通过协商出来的密钥进行数据的加解密和传输。

其中有几点要补充说明

• 为什么客户端和服务端都需要生成随机数

SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-master secret就有可能猜测出来，那么仅适用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端随机数和服务器随机数加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机数可能完全不随机，可是三个伪随机数就十分接近随机了。

• Change Cipher Spec 的意思

意思是告知对方，采用协商后的通信密钥进行加密通信，之后 Encrypted Handshake Message 是发送的第一个加密数据。内容就是把当前（准备发送Encrypted Handshake Message）前，自己收到的数据和发送的数据进行一次简单运算 (hash+加密)，在解密握手信息的时候，需要双方密钥一致，并且接收方也需要模拟计算握手信息，校验整个通信数据没有被篡改，

• HTTPs 是否绝对安全

绝对安全是一个相对说法，上面的 HTTPs 的机制是单项认证，也就是保证客户端只能访问正确的服务器（通过证书保证）但是无法保证服务器只能被正确的客户端访问，要做到这一点需要增加双项认证，也就是客户端也需要提供自己的证书。客户端校验服务端证书，服务端也校验客户端证书，这在金融行业等会引入，例如网银的USB密钥。相对安全性会高很多。

• HTTPs 可以防御中间人攻击和篡改吗

是的，HTTPs 的主要功能就是这个，但是需要严格管理 CA 证书，安全问题是一步错、步步错。

• HTTPS 可以防御重放攻击吗

可以，每一个通信的 Socket 都会协商产生随机数，除非可以完全复制客户端的 Socket 否则无法进行重放攻击。如果是重复提交，需要在系统端进行幂等保证。

soursce:https://fzsens.github.io/web/2015/03/07/brief-http/

喜欢，在看