????声明: 1. 本文为我的个人复习总结, 并非那种从零基础开始普及知识?内容详细全面, 言辞官方的文章
??????????????2. 由于是个人总结, 所以用最精简的话语来写文章
??????????????3. 若有错误不当之处, 请指出
基础
HTTP是什么?
HTTP 是超文本传输协议, ?个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」
URI, URL, URN
URI 指的是一个资源，URL 指的是用地址定位一个资源，URN 指的是用名称定位一个资源
HTTP状态码:
301: 永久重定向
**302: ** 临时重定向
304: 资源未修改
400: 客户端请求的报文有错, 笼统的客户端错误
403: 禁止访问此资源
404: 请求的资源寻找不到
500: 服务端出错, 笼统的服务端错误
502: 网关服务器自身正常, 后端服务器出错
503: 服务端忙碌
请求头字段:
**Host: ** 指定服务器的域名, 有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站
Content-Length: 本次响应的数据长度
Connection: 长连接
Content-Type: 数据格式
Content-Encoding: 压缩方式
请求报文格式:
- 请求行（请求方法+URI协议+版本）
- 请求头
- 空行
- 请求体
示例:
GET/sample.jspHTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234 请求主体
响应报文格式:
- 响应行（版本+状态码+原因短语）
- 响应头
- 空行
- 响应体
示例:
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<head>
<title>HTTP响应示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
请求方法:
Get: 幂等 & 安全
POST: 不幂等 & 不安全
PUT: 幂等 & 不安全
DELETE: 幂等 & 不安全
幂等:
幂等是指不管进行多少次操作，结果都一样
安全:
发送请求不会改变服务端的状态
Get & Post:
-
幂等安全方面:
Get 幂等, 不会修改服务端数据(安全)
Post 非幂等, 会修改服务端数据(不安全)
-
浏览器地址栏
Get 使用 URL 传参, 会将携带的数据(如用户名密码)展现出来
Post 使用 Body 传参, 不会将携带的数据展现出来
-
携带数据长度大小
GET 携带的数据长度较小, POST 携带的数据长度较大
Cookie 和 Session 是如何配合的呢？
第一次请求服务器的时候，创建对应的 Session, Cookie 记录此 SessionID
第二次访问服务器的时候，服务端会从 Cookie 中获取 SessionID 查找其对应的 Session 信息
- 如果找得到, 则维护原本的会话
- 如果找不到, 则创建新的会话返回SessionID
Cookie和Session的区别？
-
作用范围:
Cookie 保存在客户端; Session 保存在服务端
-
有效期:
Cookie 可设置为长时间保持; Session 一般失效时间较短默认为30min
-
隐私策略:
Cookie 存储在客户端 安全性不高；Session 存储在服务端 安全性高
-
存储大小:
单个 Cookie 保存的数据不能超过 4K，Session 可存储数据要高于 Cookie
-
所支持的数据类型:
Cookie 只能保存 ASCII; Session 可以存任意数据类型
DNS:
主机向本地域名服务器的查询是递归查询(热心肠)，本地域名服务器向根域名的查询是迭代查询, 根域名服务器向顶级域名的查询是迭代查询
流程:
浏览器DNS缓存 -> 操作系统DNS缓存-> 本地的hosts文件 -> 本地服务器(热心肠)
-> 根域名服务器 -> 顶级域名服务器 -> 权限域名服务器 -> 本地服务器响应给主机 所查到的ip地址
浏览器地址栏键入www.baidu.com后的执行流程:
-
域名解析
并缓存新的ip域名映射
-
TCP三次握手
-
建立 TCP 连接后发起 Http 请求
-
ARP的 ip转MAC
-
服务器响应 http 请求, 返回给客户端http代码
-
浏览器解析 html 代码，并请求 html 中的资源, 并对页面进行渲染
HTTPS
公钥/私钥 那个用来加密/解密?
加密数据: 那肯定是不希望别人知道我的消息, 所以只有我才能解密; 所以公钥负责加密，私钥负责解密
签名: 那肯定是不希望有人冒充我发消息, 只有我才能发布这个签名; 所以私钥负责签名，公钥负责验证
加密、摘要、签名、证书 都是什么?
摘要算法/ 签名算法: 一种生成哈希值的算法, 防止数据被篡改
签名: 是使用私钥 对 hash值 进行加密后的结果, 防窃听
数字证书: 由CA机构颁发, 防冒充
HTTPS 与 HTTP 的区别？
- HTTP默认端口是80，HTTPS默认端口是443
- HTTP运行在TCP协议之上；HTTPS运行在SSL协议之上，SSL运行在TCP协议之上
- HTTPS比HTTP更安全:
- HTTP是明文传输; HTTPS是ssl加密传输
- HTTPS要验证证书, 防止服务端被冒充, 向CA机构申请证书需要付费
数字签名的制作过程?
- 使用签名算法对证书内容进行hash运算
- 对hash值进行私钥加密, 即得到数字签名
验证证书的过程?
- 用CA机构的公钥对数字签名解密
- 用签名算法对证书内容进行hash运算
- 比较解密后的数字签名 和 对证书内容做hash运算后得到的哈希值，相等则表明证书可信
HTTPS原理 / SSL四次握手过程?
- 客户端向服务端发送请求 进行协商加密算法
- 服务端响应自己选中的加密算法, 并返回证书(证书内容、签名算法、签名)
- 客户端进行验证证书, 若验证成功, 则继续请求服务端执行后续握手, 否则进行断开
- 服务端生成密钥, 响应给客户端
HTTPS 的优缺点 / 特点?
优点：
-
安全性：-
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被
窃取、改变，确保数据的完整性 -
HTTPS是现行架构下最安全的解决方案，
虽然不是绝对安全，但它大幅增加了中间人攻击的成本
-
-
SEO方面：比起同等的HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高
缺点：
- HTTPS 相比于 HTTP 的开销更大, 响应时间更久
- HTTPS 的安全是有限的
HTTP
HTTP 的优点:
-
简单
HTTP 基本的报?格式就是 header + body ，头部信息也是 key-value 简单?本的形式
-
灵活和易于扩展
- 请求方法、状态码、头字段 可以自定义扩充
- 网络分层, 下层可以随意变化
- 如HTTPS在TCP上方加了一层SSL层
- 如HTTP3.0 将TCP替换成了基于UDP的Quic
-
应用广泛和跨平台
HTTP 的缺点:
-
无状态(双刃剑)
好处:
服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的
负担坏处:
每次验证身份登录信息时, 都显示未登录
解决方案:
Cookie-Session
-
不安全
- 明文传输，内容可能会被
窃听 - 不验证通信方的身份，服务端可能是
冒充的 - 无法证明报文的完整性，所以报文有可能已遭
篡改
- 明文传输，内容可能会被
HTTP1.1和HTTP1.0的区别?
-
长连接
-
缓存处理, 如果访问的资源没有被修改且缓存没过期 则不再重新请求服务端
-
新增了一些状态响应码
-
新增了请求头range字段, 可以用来指定只访问局部资源 节省网络带宽
-
断点续传的功能
-
新增了Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此请求消息中的URL并没有传递主机名;
到了HTTP1.1时代，在一台物理服务器上可以存在多个虚拟主机 并且它们共享一个IP地址，故HTTP1.1增加了HOST信息
-
异步发送多个请求, 但不完善, 服务端依旧按序响应 可能会发生队头阻塞
缺陷: 队头阻塞
HTTP2.0和 HTTP1.1的区别？
- 二进制格式：HTTP1.1的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
- 多路复用，服务端异步响应, 防止队头阻塞
- 头部压缩，HTTP1.1的头部（header）带有大量信息，而且每次都要重复发送；HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
- 服务端推送：服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。
- 指定请求的优先级
缺陷: 粒度太大, 丢包时 导致所有同批次的请求都得重传
HTTP3.0和 HTTP2.0的区别？
采用基于 UDP 的 QUIC 协议, 可以实现类似 TCP 的可靠性传输
-
粒度小, 丢包时 其他同批次的请求不受影响
-
头部压缩算法升级成了 QPack
-
连接迁移时(wifi 转换为 流量)不必重新建立连接
基于四元组（源 IP、源端口、目的 IP、目的端口）
