网络的基础知识
一, HTTP
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是因特网上应用最为广泛的一种网络传输协议,所有的WWW文件都必须遵守这个标准。
HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。
超文本传输协议
- 请求/响应报文
- 连接建立流程
- HTTP的特点
1,报文
请求报文 响应报文Q:HTTP的请求方式都有哪些?
序号 | 方法 | 描述 |
---|---|---|
1 | GET | 请求指定的页面信息,并返回实体主体。 |
2 | HEAD | 类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
5 | DELETE | 请求服务器删除指定的页面。 |
6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
7 | OPTIONS | 允许客户端查看服务器的性能。 |
8 | TRACE | 回显服务器收到的请求,主要用于测试或诊断。 |
9 | PATCH | 是对 PUT 方法的补充,用来对已知资源进行局部更新 。 |
Q: GET 和 POST 方式的区别
从使用方式来看
-
GET请求参数以?分割拼接到URL后面, POST请求参数在BODY里面
-
GET参数长度限制2048个字符,POST一般没有该限制
-
GET请求不安全,POST请求比较安全
从语义角度来看
GET : 获取资源
- 安全的
- 幂等的
- 可缓存的
POST : 处理资源
- 非安全的
- 非幂等的
- 不可缓存的
安全性
不应该引起Server端的任何状态变化。
幂等性
同一个请求方法执行多次和执行一次的效果完全相同。
可缓存性
请求是否可以被缓存。
Q: 状态码有哪些?
分类 | 分类描述 |
---|---|
1** | 信息,服务器收到请求,需要请求者继续执行操作 |
2** | 成功,操作被成功接收并处理 |
3** | 重定向,需要进一步的操作以完成请求 |
4** | 客户端错误,请求包含语法错误或无法完成请求 |
5** | 服务器错误,服务器在处理请求的过程中发生了错误 |
Q:链接简历流程是怎么样的?
三次握手和四次挥手2,HTTP的特点
- 无连接
HTTP的持久连接 - 无状态
Cookie/Session
http作为补偿,给到了持久连接的方案
持久连接和非持久连接Q:那么持久连接需要哪些头部字段呢?
- Connection: keep-alive
- time: 20
- max: 10
Q:怎样判断一个请求是否结束呢?
- Content-length: 1024
- chunked: null
Q:Charles抓包原理是怎样的?
A:利用了中间人攻击的特点
中间人攻击二, HTTPS与网络安全
Q:HTTPS和HTTP有怎样的区别?
A: HTTPS = HTTP + SSL/TLS
Q:HTTPS连接建立的流程是怎样的?
HTTPS监理流程 HTTPS监理流程-
在使用HTTPS是需要保证服务端配置正确了对应的安全证书
-
客户端发送请求到服务端
-
服务端返回公钥和证书到客户端
-
客户端接收后会验证证书的安全性,如果通过则会随机生成一个随机数,用公钥对其加密,发送到服务端
-
服务端接受到这个加密后的随机数后会用私钥对其解密得到真正的随机数,随后用这个随机数当做私钥对需要发送的数据进行对称加密
-
客户端在接收到加密后的数据使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户
-
SSL加密建立
会话秘钥 = random S + random C + 预主秘钥
Q: HTTPS都使用了哪些加密方式,为什么?
- 连接简历过程使用非对称加密,非对称加密非常耗时
- 后续通信过程使用对称加密
非对称加密
1公钥私钥的使用原则
①每一个公钥都对应一个私钥。
②密钥对中,让大家都知道的是公钥,不告诉大家,只有自己知道的,是私钥。 ③如果用其中一个密钥加密数据,则只有对应的那个密钥才可以解密。
④如果用其中一个密钥可以进行解密数据,则该数据必然是对应的那个密钥进行的加密。
非对称密钥密码的主要应用就是公钥加密和公钥认证。
2公钥加密、解密
加密的目的,是不希望第三者看到当前两个通讯用户的通讯内容。
2.1加密
A(客户)想给B(服务器)发送一段文字,但是不想让别人看到,因此想使用非对称加密方法来加密这段文字,当然,B需要有一对公钥和私钥:
① B将他的公钥发送给A
② A用B给他的公钥加密这段文字,然后传给B
③ B用他的私钥解密A发过来的消息,这里要强调的是,只要B的私钥不泄露,这封信就是安全的,即使落在别人手里,也无法解密。
通过这几步,B就能成功收到A发送的信息,同时又达到了保密的目的。
2.2解密
如果B想给A回信息,就简单的多了:
① B将要回复的信息通过自己的私钥加密,然后传送给A
② A用B之前给他的公钥解出这份信息。
参考链接: https://www.cnblogs.com/mujian/p/7665958.html
对称加密
对称加密三, TCP和UDP
传输协议层
- TCP 传输控制协议
- UDP 用户数据协议
UDP (用户数据协议)
特点
- 无连接
- 尽最大努力交付
- 面向报文 (即不合并,也不拆分)
面向报文
面向报文的传输方式是应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。若报文太长,则IP层需要分片,降低效率。若太短,会是IP太小。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这也就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。
功能
- 复用
- 分用
- 差错监测
复用/分用
复用 分用差错监测
差错监测TCP (传输控制协议)
特点
- 面向连接
- 可靠传输
- 面向字节流
- 流量控制
- 拥塞控制
面向连接
数据传输开始之前,需要建立连接 - 三次握手
数据传输结束之后,需要释放连接 - 四次挥手
可靠传输
- 无差错 (超时重传)
- 不丢失 (确认丢失)
- 不重复
- 按序到达(确认迟到)
面向字节流
面向字节流流量控制
使用<滑动窗口协议>
发送窗口
发送窗口
接收窗口
接收窗口
拥塞控制
- 慢开始、拥塞避免
- 快恢复、快重传
DNS 解析
Q: DNS解析的过程是怎么样的?
域名到IP地址的映射, DNS解析请求采用UDP数据报,明文
DNS解析过程DNS解析查询方式
- 递归查询
- 迭代查询
递归查询 - “我去给你问一下”
递归查询迭代查询 - “我告诉你谁可能知道”
迭代查询Q: DNS解析存在哪些常见的问题?
- DNS劫持问题
- DNS解析转发问题
DNS劫持
DNS劫持Q: DNS劫持和HTTP的关系是怎么样的?
A: 没有关系,DNS解析发生在HTTP建立连接之前,DNS解析请求使用UDP数据报,端口号53
Q: 怎么解决DNS劫持?
- httpDNS
- 长连接
httpDNS
将DNS协议向DNS服务器的53端口转成80端口
长连接
长连接DNS解析转发
Client -- www.aixue.com --> xx移动DNS -- 节省资源 --> xx电信DNS -- www.aixue.com --> 权威DNS {默认1.1.1.1 xx移动 2.2.2.2 xx电信 3.3.3.3}
四, Session 和 Cookie
Session和Cookie是对HTTP协议无状态特点的补偿
Cookie
Cookie 主要用来纪录用户状态,区分用户,状态保存在客户端
Cookie
客户端发送的cookie在http请求报文的Cookie首部字段中
服务端设置http响应报文的Set-Cookie首部字段
Q: 怎么样修改Cookie
- 新cookie覆盖旧cookie
- 覆盖规则: name, path, domain 等需要与原cookie保持一致
Q: 怎么样删除Cookie
- 新Cookie覆盖旧cookie
- 覆盖规则: name, path, domain 等需要与原cookie保持一致
- 设置Cookie的expires = pastTime。或者maxAge = 0
Q: 怎么样保证Cookie的安全?
- 对Cookie进行加密处理
- 只在https上携带Cookie
- 设置Cookie为httpOnly, 防止跨站脚本攻击
Session
Session 也是用来纪录用户状态,区分用户,状态保存在服务器端
Q: Session和Cookie的关系?
A:Session需要依赖于Cookie机制
Session工作流