目录
- 一.http
- 1.url和域名
- 2.URL编码（Encode）和解码（Decode）
- 4.http协议格式
- 5.http的方法和状态码
- 6.cookie和session
- 二.https
- 1.加密
- 2.https的方案与MITM
- 3.证书
一.http
1.url和域名
url即统一资源定位符，通常会包括协议、域名、路径等部分。URL可以具体到某个网页、图片、文件或其他资源的精确位置。eg：https://www.example.com/blog/article?id=123
域名是一个用于标识和定位互联网中某一台服务器或资源的名字。域名是URL的一部分，用于替代IP地址，使得人们可以更方便地访问网站。eg：www.example.com
2.URL编码（Encode）和解码（Decode）
http协议中url常会使用一些特殊符号用来分隔字符串。但是当我们输入的参数与特殊符号冲突时，就会将某些特殊字符转换为百分号（%）加上两位16进制数的格式。
编码规则：
- 字母（A-Z, a-z）、数字（0-9）：这些字符不需要编码，可以直接使用。
- 保留字符：如:、/、?、&、=等在URL中有特殊意义的字符需要编码。例如： 空格编码为%20或+ ，‘!’编码为%21， ‘/’编码为%2F
- 非ASCII字符：如中文、日文等其他语言字符，需要进行编码。例如，“中文”编码为%E4%B8%AD%E6%96%87。
有编码规则相应的就有解码规则：将URL中的百分号编码形式转换回原始字符：遇到%加上两位16进制数的序列，将其解码为对应的字符。
4.http协议格式
HTTP（超文本传输协议）是应用层协议，用于在BS，CS之间传输超文本数据。
http的请求格式：求由三部分组成：请求行、请求头部、请求正文。其基本格式如下：
请求行\r\n
请求头部字段1: 值1\r\n
请求头部字段2: 值2\r\n
...
<空行>\r\n
请求正文（可为空）\r\n
...
- 请求行: 包含请求方法、目标资源的URL路径、HTTP版本信息。
- 示例：GET /index.html HTTP/1.1
- 常见的请求方法包括：GET、POST、PUT、DELETE等。
- 请求报头: 请求的属性，使用kv结构，提供请求的附加信息，如客户端类型、数据格式、身份验证等
- 空行：用来标识后面的正文
- 请求正文: 包含需要发送给服务器的数据，仅在POST、PUT等方法中存在，在请求报头中中会有一个Content-Length属性来标识正文的长度;
http请求示例：
POST /api/v1/login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Accept: application/json, text/plain
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 85
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Origin: https://www.example.com
Referer: https://www.example.com/login
Connection: keep-alive
Cookie: sessionId=abcd1234; lang=en-US
Upgrade-Insecure-Requests: 1
{
"username": "user123",
"password": "password456"
}
http相应格式由三部分组成：状态行、响应头部、响应正文。其基本格式如下：
状态行
响应头部字段1: 值1
响应头部字段2: 值2
...
<空行>
响应正文（可选）
-
状态行: 包含HTTP版本信息、状态码及其描述。
- 格式：
- 示例：HTTP/1.1 200 OK
- 状态码分为五类：1xx（信息类），2xx（成功）：表示请求已成功被服务器接收、理解、处理。3xx（重定向）：表示要完成请求需要进一步操作。4xx（客户端错误）：表示请求有语法错误或无法被执行。5xx（服务器错误）：表示服务器在处理请求时发生了错误。
-
响应头部: 提供关于响应的附加信息，如服务器类型、响应数据格式、缓存控制等。
-
响应正文: 包含服务器返回的数据，如HTML页面、JSON数据等。
http响应示例：
HTTP/1.1 200 OK
Date: Sun, 25 Aug 2024 12:00:00 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Sun, 25 Aug 2024 11:45:00 GMT
Content-Length: 137
Content-Type: text/html; charset=UTF-8
<html>
<head><title>Hello World</title></head>
<body><h1>Hello, World!</h1></body>
</html>
5.http的方法和状态码
| 方法 | 描述 |
|---|---|
GET | 请求指定的资源。通常用于从服务器检索数据。请求应是安全的且无副作用。 |
POST | 提交数据到服务器，例如提交表单或上传文件。数据会被包含在请求正文中。 |
PUT | 更新指定的资源。客户端提供的资源替换服务器上的现有资源。 |
DELETE | 删除指定的资源。客户端请求删除资源，通常与URL指定的资源相关。 |
HEAD | 请求资源的元数据（头部信息），不包含实体主体。用于获取资源的元信息。 |
OPTIONS | 请求允许的HTTP方法和其他选项。用于探测服务器支持的功能或设置。 |
PATCH | 部分更新资源。客户端提供的部分数据用于更新服务器上的资源。 |
TRACE | 回显服务器收到的请求，用于诊断和调试。 |
CONNECT | 通过HTTP隧道建立一个到目标资源的网络连接。常用于代理服务器的设置。 |
一般我们在网络的行为分为上传数据和接受数据两种。当我们想提交参数给服务器时，使用GET方法提交的参数是通过url提交的，参数受限，POST方法也支持提交参数，通过请求的正文部分提交参数。
http状态码：
| 状态码 | 描述 | 说明 |
|---|---|---|
| 200 | OK | 请求成功，服务器返回请求的资源。 |
| 201 | Created | 请求成功并且服务器创建了新的资源。 |
| 202 | Accepted | 请求已接受，但未处理完成。 |
| 204 | No Content | 请求成功，但没有返回内容。 |
| 301 | Moved Permanently | 请求的资源已被永久移动到新的URL。 |
| 302 | Found | 请求的资源临时移动到新的URL。 |
| 303 | See Other | 客户端应使用GET方法访问新的URL。 |
| 304 | Not Modified | 请求的资源未被修改，客户端可以使用缓存的版本。 |
| 307 | Temporary Redirect | 请求的资源临时移动到新的URL，客户端应使用相同的方法发起请求。 |
| 308 | Permanent Redirect | 请求的资源永久移动到新的URL，客户端应使用新的URL进行请求，保持请求方法。 |
| 400 | Bad Request | 请求无效，服务器无法理解请求。 |
| 401 | Unauthorized | 请求未授权，客户端需要提供身份验证。 |
| 403 | Forbidden | 服务器理解请求，但拒绝执行。 |
| 404 | Not Found | 请求的资源未找到。 |
| 405 | Method Not Allowed | 请求方法不被允许。 |
| 408 | Request Timeout | 请求超时，客户端未在服务器指定的时间内发送请求。 |
| 409 | Conflict | 请求冲突，服务器无法处理请求。 |
| 410 | Gone | 请求的资源已被永久删除。 |
| 411 | Length Required | 服务器要求请求包含Content-Length头部。 |
| 412 | Precondition Failed | 请求的前提条件失败。 |
| 413 | Payload Too Large | 请求的负载过大，服务器无法处理。 |
| 414 | URI Too Long | 请求的URI过长。 |
| 415 | Unsupported Media Type | 请求的媒体类型不被支持。 |
| 416 | Range Not Satisfiable | 请求的范围无法满足。 |
| 417 | Expectation Failed | 服务器无法满足Expect请求头字段。 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求。 |
| 501 | Not Implemented | 服务器不支持请求的方法。 |
| 502 | Bad Gateway | 网关或代理服务器接收到无效的响应。 |
| 503 | Service Unavailable | 服务器当前无法处理请求，可能是由于过载或维护。 |
| 504 | Gateway Timeout | 网关或代理服务器在等待上游服务器响应时超时。 |
| 505 | HTTP Version Not Supported | 服务器不支持请求中所用的HTTP协议版本。 |
在HTTP协议中，状态码用于指示服务器对客户端请求的处理结果。其中，状态码3xx系列专门用于重定向，分有临时重定向和永久重定向，当浏览器访问服务器时，服务器返回307 Temporary Redirect（临时重定向）或者308 Permanent Redirect（永久重定向）状态码，Location头部字段常用于HTTP重定向响应，告知客户端请求的资源已被移动到新的URL。客户端会自动跟随这个URL进行新的请求。
示例：
HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/temporarypage
接着浏览器将去访问location字段给的新地址。
http短连接长连接：
短连接：
短连接指的是每个HTTP请求/响应对都使用一个独立的TCP连接。请求完成后，连接立即关闭，客户端和服务器在后续请求时需要重新建立连接。缺点就是会降低性能效率低。HTTP/1.0使用短连接。
长连接：
长连接指的是在一个TCP连接上可以发送多个HTTP请求和响应对。连接在一个请求/响应周期后不会立即关闭，而是保持打开状态，允许后续的请求和响应在同一连接上进行。HTTP/1.1及以后的版本使用长连接。
6.cookie和session
Cookie是由服务器发送并保存在客户端浏览器上的小块数据。实现http对登录用户的的会话保持功能。
示例：
如果我们之前已经登录过某网站，下次访问时无需再次输入账号密码，直接自动登录了：
其实都是在浏览器中的cookie中存储着多中数据，实现了此功能。
当我们删除cookie文件后：
再次进入网站就需要重新登录了。
但是cookie是有一定的安全问题的。在这基础上又衍生出了session。
Session是服务器端存储用户会话数据的机制。每个用户的会话数据存储在服务器上，通过一个唯一的Session ID在客户端和服务器之间进行关联。Session ID由服务器统一管理分配。
- 创建Session：用户首次访问网站时，服务器创建一个新的会话并生成一个唯一的Session ID。Session ID通常会被发送到客户端，保存在Cookie中。
示例：
HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure
- 在用户的后续请求中，客户端发送包含Session ID的Cookie，服务器ID检索用户会话数据。
GET /profile HTTP/1.1
Host: www.example.com
Cookie: sessionId=abc123
二.https
1.加密
HTTP协议的设计初衷是为了快速地传输网页内容。然而，由于HTTP的数据传输是明文的，导致在数据传输中隐含着数据被窃取篡改的风险。为了增强数据传输的安全性，SSL协议应运而生，后来发展为TLS（传输层安全协议）。
HTTPS是HTTP与SSL/TLS的结合体。它将SSL/TLS协议应用于HTTP协议之上。
所谓加密就是让传输的明文数据通过一系列手段加工成密文，解密就是将密文再进行一系列手段加工成明文，在加密解密过程中辅助这个过程完成的数据叫做密钥
对称加密：
对称加密即是CS双方都有密钥Y即可进行对明文的加密和密文的解密。
优点：
- 速度快：对称加密使用的加密算法（如AES、DES）计算速度较快，适合处理大数据量的加密任务。
- 计算资源消耗少：对称加密算法的计算复杂度通常较低，因此对计算资源的消耗较少。
- 实现简单：对称加密算法的实现通常较为简单，容易在各种设备和平台上应用。
缺点：
- 密钥管理难：所有参与通信的双方必须共享同一个密钥，密钥的安全管理和分发是一个挑战。一旦密钥泄露，所有使用该密钥加密的数据都会受到威胁。
- 不支持身份验证：对称加密本身并不提供身份验证功能，因此难以确认数据的发送者身份。
- 密钥交换问题：在建立安全通信之前，双方需要安全地交换密钥，这本身是一个挑战，特别是在未建立安全通信之前。
非对称加密：
这对密钥的特点在于，只有拥有私钥的服务器才能解密用公钥加密的数据，从而保证了信息传输的安全性。
优点：
- 密钥管理简单：非对称加密使用一对密钥（公钥和私钥）。公钥可以公开，而私钥必须保密。密钥的分发和管理变得更加简单，因为私钥不需要传输。
- 提供身份验证：非对称加密可以用来验证身份。例如，通过数字签名，接收者可以确认数据确实来自声称的发送者。
- 密钥交换安全：在通信过程中，非对称加密可以用来安全地交换对称加密密钥，从而结合了对称加密的高效性和非对称加密的安全性。
缺点：
- 速度较慢：非对称加密算法（如RSA、ECC）通常比对称加密算法速度慢，不适合加密大量数据。
- 计算资源消耗高：非对称加密需要复杂的数学运算，计算资源消耗较大，对性能要求较高。
- 实现复杂：非对称加密的算法实现较为复杂，需要处理更多的数学和安全问题，可能导致实施上的挑战。
2.https的方案与MITM
一种https方案：对称加密与非对称加密结合：
+---------------------------+ +---------------------------+
| 客户端 | | 服务器 |
| | | |
| 1. 发送HTTPS请求 | | |
|-------------------------->| | |
| | | |
| 2. 服务器发送公钥S | | 公钥S 私钥S* |
|<--------------------------| | |
| | | |
| 3. 生成会话密钥C并用 | | |
| 服务器的公钥加密 | | |
|-------------------------->| | |
| | | |
| 4. 服务器用私钥解密 | | |
| 会话密钥 | | |
|<--------------------------| | |
| | | |
| 5. 双方使用会话密钥进行 | | |
| 对称加密的数据传输 | | |
|<-------------------------->| | |
| | | |
| 6. 服务器解密数据 | | |
| 用会话密钥 | | |
|-------------------------->| | |
+---------------------------+ +---------------------------+
上面的方案还是有安全问题的。
MITM：中间人攻击(简称MITM）是一种网络攻击方式，攻击者通过插入到客户端与服务器之间的通信链路中，监听、截获甚至篡改数据。
在上面的对称加密加非对称加密方案中，如果出现的中间人攻击会是什么样的呢：
当客户端向服务器发送http请求获得公钥S时，其实是先发给了中间人，中间人再发送给服务器，这样服务器端发送的公钥S就被中间人截取到了，这时就可以给客户端发一个属于中间人的公钥M，C端误以为公钥M是S端发送过来的。使用M加密了自己的秘钥X，在发送给S端，中间人用自己的私钥M*解密再用公钥S加密发送给S端，这样就能完成对数据的篡改盗取，引发一系列的安全问题。
3.证书
为了解决以上的安全问题，引入了新的概念----证书。服务器网站管理员向证书颁发机构（CA）提交证书签名请求，其中包含公钥和服务器信息。身份验证：CA对申请者的身份进行验证，确保其拥有对所请求域名的合法控制权。证书签发：验证通过后，CA使用其私钥对申请者的公钥及其他信息签名，生成数字证书，并将证书发给申请者。
证书组成部分：
- 公钥：证书中包含服务器的公钥，用于加密数据或验证数字签名。
- 所有者信息：包括服务器的域名、组织名称等信息，用于识别服务器的身份。
- 证书颁发机构（CA）的信息：指明颁发该证书的CA，以及CA的数字签名，保证证书的可信度。
- 有效期：证书的有效时间范围。过期的证书需要更新，否则浏览器会提示用户连接不安全。
- 数字签名：由CA使用其私钥对证书内容进行签名，确保证书未被篡改。
数据摘要：数据摘要是一种通过哈希函数对任意长度的数据进行处理后生成的固定长度的字符串。
主要有以下特点：
- 固定长度输出：无论输入数据长度多长，数据摘要的长度始终固定。例如，SHA-256的摘要长度为256位（32字节）。
- 唯一性：不同的输入数据（即使仅有一位不同）应产生不同的摘要值。这一特性确保了数据的唯一表示。
- 不可逆性：数据摘要的生成过程是不可逆的，即从摘要值不能还原出原始数据。这确保了摘要的安全性。
- 高效性：哈希算法通常设计得非常高效，能快速处理大量数据并生成摘要。
几种常见的哈希算法：
- MD5（Message Digest Algorithm 5）：生成128位的哈希值，曾广泛用于校验和加密，但由于其易受碰撞攻击，已不再推荐用于安全场景。
- SHA-1（Secure Hash Algorithm 1）：生成160位的哈希值，曾被广泛应用，但同样由于安全性问题，已被逐渐淘汰。
- SHA-256：SHA-2家族中的一种，生成256位的哈希值，是目前被广泛使用的安全哈希算法。
数字签名：
字签名在信息安全中主要用来身份验证：数字签名可以确认信息的发送者身份，确保数据来自预期的合法发送者。因为只有发送者拥有对应的私钥，任何其他人都无法伪造签名。确保客户端啊收到服务器的公钥是可信的。
工作原理：
- 生成消息摘要：首先，对原始数据使用哈希函数消息摘要（Message Digest）。这个摘要唯一地代表了原始数据的内容。
- 加密摘要：发送者使用CA的私钥对消息摘要进行加密，生成数字签名。由于私钥是保密的，只有持有该私钥的实体才能生成有效的签名。
- 附加数字签名：发送者将数字签名附加到原始数据上，一并发送给接收者。原始数据保持未加密状态，以便接收者能够查看。
- 验证签名：接收者在收到数据后，使用发送者的公钥解密数字签名，得到解密后的哈希值。接收者再对收到的原始数据重新计算一个哈希值，并将其与解密后的哈希值进行比较。
如果两个哈希值一致，说明数据未被篡改，且签名确实由声称的发送者生成；否则，签名无效或数据可能被篡改。
所以https真实的加密方案是对称非对称加密和证书相结合。
HTTPS的加密过程可以分为以下几个步骤：
- 客户端发起请求：客户端向服务器发起HTTPS请求，服务器响应并提供其数字证书。
- 证书交换与身份验证：服务器发送包含公钥的数字证书给客户端。客户端使用预安装的受信任CA证书对服务器的证书进行验证（对证书明文数据进行数据摘要，对签名用CA公钥解密，比对两个数据摘要是否相同，即可证明证书是否可信。），确认服务器身份。
- 生成会话密钥：客户端生成一个对称加密密钥（会话密钥），并使用服务器的公钥对该密钥进行加密。加密后的会话密钥发送给服务器。
- 密钥解密与建立安全通道：服务器使用私钥解密收到的会话密钥。客户端和服务器双方均得到了相同的对称密钥，用于加密和解密随后的数据。
- 加密数据传输：使用对称密钥加密的数据被传输至对方，确保通信内容的机密性和完整性。
完整流程示意图：
在浏览器中也能查看已有的证书信息
