网络安全基础：HTTP和HTTPS详解

本文最后更新于 2024-04-19，文章内容可能已经过时。

HTTP简介

HTTP（超文本传输协议，Hypertext Transfer Protocol）是一种用于从网络传输超文本到本地浏览器的传输协议。它定义了客户端与服务器之间请求和响应的格式。HTTP 工作在 TCP/IP 模型之上，通常使用端口 80

超文本传输协议，是一种应用层协议，是基于为浏览器/服务器间提供统一的信息交换格式而出现的，其发展历程为HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3。

是一种基于客户端-服务端架构的应用层协议，主要用于 Web 应用之间的数据交互。

HTTP定义了客户端向服务器发起请求和服务器返回响应的标准格式和步骤。HTTP 协议工作在 TCP/IP 协议的应用层上，使用80端口进行通信。客户端通过发送HTTP请求给服务器，服务器处理请求并返回相应的HTTP响应，通常包含请求所需的内容。HTTP 请求和响应消息总是由多行文本构成，其中第一行包含请求或响应的类型、请求的URI、协议版本和状态码等信息，随后为一些头部标识数据，最后是实体（Body）数据（例如请求表单或者响应的HTML页面等）。这些HTTP消息可以通过各种方式进行交互，例如在客户端浏览器中访问Web页面或API时。

HTTPS简介

HTTPS（超文本传输安全协议，Hypertext Transfer Protocol Secure）是 HTTP 的安全版本，它在 HTTP 下增加了 SSL/TLS 协议，提供了数据加密、完整性校验和身份验证。HTTPS 通常使用端口 443。

加密：HTTPS 使用 SSL/TLS 协议对传输的数据进行加密，而 HTTP 没有加密。这意味着在使用 HTTPS 时，数据在传输过程中不能被第三方截获和窃取。
身份验证：HTTPS 需要通过证书来验证服务器的身份，确保用户访问的是可信任的网站。这有助于防止“中间人攻击”，在这种攻击中，攻击者扮演着用户和服务器之间的中介，窃取或篡改数据。
数据完整性：HTTPS 通过加密和身份验证确保了数据的完整性，防止了数据在传输过程中的篡改。
端口：HTTP 默认使用 80 端口，而 HTTPS 默认使用 443 端口。
性能：由于 HTTPS 需要进行加密和解密操作，因此在某些情况下，它的性能可能略低于 HTTP。但随着技术的发展，这种性能差距已经变得很小。
SEO：对于搜索引擎优化（SEO），使用 HTTPS 的网站可能会获得更好的排名，因为搜索引擎认为 HTTPS 网站更安全、更可信。

HTTP的工作流程

HTTP的工作流程通常可以分为以下步骤：

1.客户端向服务器发送HTTP请求。

2.服务器接收到请求后进行处理，并返回响应给客户端。

3.客户端接收到响应并进行相应的处理（解析视图HTML、加载JS和CSS，或在API中使用响应数据等）。

具体地，HTTP请求一般由以下三个部分组成：请求首行、请求头以及实体主体。

请求首行中包含了由请求方法、请求URL、协议版本组成。常见的请求方法有GET、POST等。

而请求头则提供了更多的请求信息，例如User-Agent、Accept-Encoding、Content-Type等。

实体主体用于提供附加的请求数据，例如表单提交或者上传文件的数据。服务器处理完请求后，会生成一个 HTTP 响应消息，同样由三个部分组成：状态行、消息头和消息正文。其中，状态行由协议版本、状态码和状态描述构成；消息头包含了响应的元数据信息；消息正文包含了请求所需要的内容或者处理结果。

总之，HTTP协议的工作流程是通过客户端与服务端之间的交互来实现数据的发送和接受，请求和响应之间的数据传输都是基于HTTP协议定义的标准格式和步骤完成的。

HTTP响应报文：在接收和解释请求消息后 . 服务器返回一个HTTP响应消息

HTTP响应也由四个部分组成·分别是：

状态行
消息报头
空行
响应正文

状态行：

HTTP-Version Status-Code Reason-Phrase CRLF

Http-Version：表示服务器HTTP协议的版本；

Status-Code：表示服务器发回的响应状态代码

Reason-Phrase：表示状态代码的文本描述

状态码：

状态码有三位数字组成 · 第一个数字定义了响应的类别 · 且有五种可能取值：

1xx：指示信息--请求已被服务器接收 · 继续处理

2xx：成功-请求已成功被服务器接收 · 理解、并技受

3xx：重定向-需要后续操作才能完成这一请求

4xx：客户端错误-请求有语法错误或请求无法实现

5xx：服务端错误--服务器在处理某个正确请求时发生错误

常见状态码：

200 OK # 客户端请求成功

400 Bad Request # 客户端请求有语法错误 · 不能被服务器所理解

401 Unauthorized # 请求未经授权 · 这个状态代码必须和WWW- Authenticate 报头域一起使用

403 Forbidden # 服务器收到请求·但是拒绝提供服务

404 Not Found # 请求资源不存在 ·eg：输入了错误的URL

500 Internal Server Error # 服务器发生不可预期的错误

503 Server Unavailable # 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP的请求方法：

GET

GET：获取/查询资源

不包含请求主体

请求参数一般是用“?”拼接在请求的URL后面

POST

POST：在 Request-URI所标识的资源后附加新的数据

用于向指定资源发送数据 · 指定的资源会对数据进行处理 · 然后将处理结果返回给客户端 · 一般用于表单提交文件上传

三次握手和四次挥手

三次握手（TCP连接的建立）

第1次握手：客户端发送一个带有SYN标志的数据包给服务端；

第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了；

第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。

其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立

TCP协议中，客户端和服务器建立连接时需要进行三次握手的过程。具体步骤如下：

第一步：客户端向服务器发送一个连接请求报文段（SYN标志位为1，表示请求建立连接）。

第二步：服务器接收到请求报文段后，如果同意建立连接，则会回复一个报文段（ACK标志位和SYN标志位都为1，表示确认并同意建立连接请求），同时也会将自己的初始化序列号发送给客户端。

第三步：客户端收到服务器发来的报文后，再次向服务器发送一个报文段（ACK标志位为1，表示确认收到服务器的请求），并在该报文段中带上服务器的初始化序列号。

此时连接就建立成功了，可以开始传输数据了。这个过程是为了确保客户端和服务器双方都能够正常通信，而且经过三次握手后，双方都知道对方的初始化序列号，以便后续通过序列号来保证数据的可靠性和完整性。

客户机首先向服务器的TCP发送SYN=1，表示一个连接请求报文段，随机选择一个起始序号seq=x
服务器的TCP收到连接请求报文段，如果同意建立连接，就像客户机发回确认ACK=1,并为该TCP连接分配TCP缓存和变量，并随机产生起始序号seq=y
当客户机收到确认报文后，还要想服务器给出确认，并且也要给连接分配缓存和变量

TCP为什么要进行三次握手而不是两次握手？

TCP协议需要经过三次握手，才能建立链接。

TCP是一种可靠的传输控制协议,他必须做到两点,一是保证数据的稳定性,二是保证数据的传输效率。三次握手正是为了做到这两点而实现的。

实现数据可靠传输，为什么刚好需要三次握手呢?如果两次握手，行不行?

两次握手：

A发送同步信号SYN+A的初始化序列号

B发送同步信号SYN+B的初始化序列号+B的ACK序列号

两次握手会出现一个问题。B没办法指导A是否已经收到了自己的同步信号，一但这个同步信号出现问题了，像丢失了，A和B的初始序列号将无法达成一致，就无法建立稳定可靠的链接。

显然，两次握手是不可取的。

四次挥手（TCP连接的释放）

第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态；

第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态；

第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态；

第4次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

其中：FIN标志位数置1，表示断开TCP连接。

客户机打算关闭连接，向TCP发送FIN=1标志位的连接释放报文段，并停止再发送数据,seq=u等于前面已传送过的数据的最后一个字节的序号加1
服务器疏导释放报文段，发出确认号ack=u+1。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭
若服务器已经没有向客户机发送的数据，就通知TCP释放连接，此时发送FIN=1的连接释放报文段
客户机收到连接释放报文段后，必须发出确认，ACK=1, 确认好ack=w+1,序号seq=u+1。此时TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入到连接关闭状态

什么情况TCP的四次挥手会进入closed状态？

如果在四次挥手的过程中，客户端发送的最后一个ACK报文在网络中丢失，并且客户端的TIME-WAIT状态过短或没有设置，则客户端会直接进入CLOSE状态，而服务端则会一直处于LAST-ACK状态。这种情况下，连接无法正常关闭

TSL的加密

数据（加密）传输过程

Alice：

信息摘要=hash(原始信息)
数字签名=A_Private(摘要)
--------要传给Bob---------
加密信息=S_key(数字签名，原始信息，Alice的证书)
密钥信封=B_public(S_key)

Bob：

B_privete(密钥信封)=B_privete(B_public(S_key)) = S_keyS_key
(加密信息) = S_key(S_key(数字签名，原始信息，Alice的证书)) = 数字签名，原始信息，Alice的证书（包含Alice的公钥，A_public）
收到的信息摘要 = hash(原始信息)
信息摘要 = A_public(数字签名)
收到的信息摘要 == 信息摘要？    如果相等，就代表没有被篡改。

TLS协议的加密过程

1、握手协议：

TLS连接的建立始于握手协议，在客户端和服务器建立三次握手之后，客户端向服务器发送一个“clientHello”消息，其中包含支持的TLS版本，密码套件和一个随机数，服务器收到“clientHello”消息后，返回一个“ServerHello”消息，其中包含了选择的TLS版本和密码套件和另一个随机数。

服务器还会发送包含其公钥的数字证书，验证身份信息。客户端会验证证书的有效性。

客户端生成一个用于对称加密的随机数，并使用服务器的公钥进行加密，然后将加密后的随机数发送给服务器，形成预主密钥。

服务器使用私钥解密客户端发送的随机数，并生成会话密钥（session key）这个会话密钥和客户端的会话密钥是一致的。