Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTTP和HTTPS #3

Open
FIGHTING-TOP opened this issue Oct 23, 2020 · 0 comments
Open

HTTP和HTTPS #3

FIGHTING-TOP opened this issue Oct 23, 2020 · 0 comments
Assignees
@FIGHTING-TOP
Labels
HTTP HTTPS

Comments

@FIGHTING-TOP
Copy link
Owner

FIGHTING-TOP commented Oct 23, 2020 •
edited

HTTP协议是计算机网络七层协议中的应用层协议，它是一个建立在TCP/IP通信协议上的一种应用。

网络七层协议

984915-20201020180901120-1691764606

HTTP

**超文本传输协议（HTTP）**是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。

HTTP有多个版本，目前广泛使用的是HTTP1.1版本，另外我们比较熟悉的还有HTTP1.0和HTTP2.0，详情请参考文章HTTP1.0，HTTP1.1，HTTP2.0。

HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。

HTTP协议一般用于B/S架构，浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

HTTP协议特点

HTTP 是简单的

虽然下一代HTTP/2协议将HTTP消息封装到了帧（frames）中，HTTP大体上还是被设计得简单易读。HTTP报文能够被人读懂，还允许简单测试，降低了门槛，对新人很友好。

HTTP 是可扩展的

在 HTTP/1.0 中出现的 HTTP headers 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来。

HTTP 是无状态，有会话的

HTTP是无状态的：在同一个连接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，比如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。而使用HTTP的头部扩展，HTTP Cookies就可以解决这个问题。把Cookies添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。

注意，HTTP本质是无状态的，使用Cookies可以创建有状态的会话。

HTTP 和连接

一个连接是由传输层来控制的，这从根本上不属于HTTP的范围。HTTP并不需要其底层的传输层协议是面向连接的，只需要它是可靠的，或不丢失消息的（至少返回错误）。在互联网中，有两个最常用的传输层协议：TCP是可靠的，而UDP不是。因此，HTTP依赖于面向连接的TCP进行消息传递，但连接并不是必须的。

在客户端（通常指浏览器）与服务器能够交互（客户端发起请求，服务器返回响应）之前，必须在这两者间建立一个 TCP 链接，打开一个 TCP 连接需要多次往返交换消息（因此耗时）。HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接。当需要连续发起多个请求时，这种模式比多个请求共享同一个 TCP 链接更低效。

为了减轻这些缺陷，HTTP/1.1引入了流水线（被证明难以实现）和持久连接的概念：底层的TCP连接可以通过Connection头部来被部分控制。HTTP/2则发展得更远，通过在一个连接复用消息的方式来让这个连接始终保持为暖连接。

为了更好的适合HTTP，设计一种更好传输协议的进程一直在进行。Google就研发了一种以UDP为基础，能提供更可靠更高效的传输协议QUIC。

HTTP流

当客户端想要和服务端进行信息交互时（服务端是指最终服务器，或者是一个中间代理），过程表现为下面几步：

第一步，打开一个TCP连接：TCP连接被用来发送一条或多条请求，以及接受响应消息。客户端可能打开一条新的连接，或重用一个已经存在的连接，或者也可能开几个新的TCP连接连向服务端。

第二步，发送一个HTTP报文：HTTP报文（在HTTP/2之前）是语义可读的。在HTTP/2中，这些简单的消息被封装在了帧中，这使得报文不能被直接读取，但是原理仍是相同的。

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

第三步，读取服务端返回的报文信息：

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
 
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

第四步，关闭连接或者为后续请求重用连接。

当HTTP流水线启动时，后续请求都可以不用等待第一个请求的成功响应就被发送。然而HTTP流水线已被证明很难在现有的网络中实现，因为现有网络中有很多老旧的软件与现代版本的软件共存。因此，HTTP流水线已被在有多请求下表现得更稳健的HTTP/2的帧所取代。

HTTP报文

HTTP/1.1以及更早的HTTP协议报文都是语义可读的。在HTTP/2中，这些报文被嵌入到了一个新的二进制结构，帧。帧允许实现很多优化，比如报文头部的压缩和复用。即使只有原始HTTP报文的一部分以HTTP/2发送出来，每条报文的语义依旧不变，客户端会重组原始HTTP/1.1请求。因此用HTTP/1.1格式来理解HTTP/2报文仍旧有效。

有两种HTTP报文的类型，请求与响应，每种都有其特定的格式。

请求

984915-20201021115324131-439663924

请求由以下元素组成：

  • 一个HTTP的method，经常是由一个动词像GET, POST 或者一个名词像OPTIONS，HEAD来定义客户端的动作行为。通常客户端的操作都是获取资源（GET方法）或者发送HTML form表单值（POST方法），虽然在一些情况下也会有其他操作。

  • 要获取的资源的路径，通常是上下文中就很明显的元素资源的URL，它没有protocol （http://），domain（www.xxx.com），或是TCP的port（HTTP一般在80端口）。

  • HTTP协议版本号。

  • 为服务端表达其他信息的可选头部headers。

  • 对于一些像POST这样的方法，报文的body就包含了发送的资源，这与响应报文的body类似。

响应

984915-20201021123935037-395436598

响应报文包含了下面的元素：

  • HTTP协议版本号。

  • 一个状态码（status code），来告知对应请求执行成功或失败，以及失败的原因。

  • 一个状态信息，这个信息是非权威的状态码描述信息，可以由服务端自行设定。

  • HTTP headers，与请求头部类似。

  • 可选项，比起请求报文，响应报文中更常见地包含获取的资源body。

HTTP默认端口号

HTTP的默认端口号为80， HTTPS的默认端口号为443

HTTP的一些不足

  • 请求信息明文传输，容易被窃听截取

  • 没有验证对方身份，存在冒充危险

  • 数据的完整性未校验，容易被篡改

所以呢，才有了HTTPS的出现来弥补这些不足。

HTTPS

HTTPS协议（Hypertext Transfer Protocol over Secure Socket Layer）简单讲是HTTP的安全版，在HTTP协议的基础上加入SSL层(HTTP+SSL) 。 SSL（Secure Sockets Layer 安全套接层）主要用于Web的安全传输协议，在传输层对网络连接进行加密，保障在Internet上数据传输的安全。

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间的会话层，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道，其本身是不提供可靠性保障的，我们还是需要下层可靠的传输层协议。在通信双方建立可靠的 TCP 连接之后，我们就需要通过 TLS 握手交换双方的密钥了，在这里我们将介绍 TLS 1.2 的连接建立过程：

  1. 客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数；

  2. 服务端收到客户端支持的协议版本、加密算法等信息后；

  3. 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数；

  4. 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；

  5. 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；

  6. 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；

  7. 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；

  8. 客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；

  9. 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；

  10. 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；

  11. 向服务端发送 Finished 消息，其中包含加密后的握手信息；

  12. 服务端收到 Change Cipher Spec 和 Finished 消息后；

  13. 向客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；

  14. 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；

如何验证证书合法性

（1）首先浏览器校验证书的网站域名是否与证书颁发的域名一致，再检查SSL证书中的证书吊销列表，校验证书是否在有效期内
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布
版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

HTTPS中间人攻击

中间人攻击简单说就是在客户端和服务端之间有一个第三者，可以监听信息或者修改信息
中间人攻击，HTTPS也可以被碾压

HTTPS优势

  • 内容加密建立一个信息安全通道，来保证数据传输的安全

  • 身份认证确认网站的真实性

  • 数据完整性防止内容被第三方冒充或者篡改

HTTPS劣势

  • HTTPS协议多次握手，导致页面的加载时间延长

  • HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗

  • 需要专业机构颁发CA证书，一般都是收费的，功能越强大的证书费用越高

  • SSL涉及到的加密算法会消耗一部分 CPU 资源
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@FIGHTING-TOP FIGHTING-TOP

Labels
HTTP HTTPS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@FIGHTING-TOP