网络原理基础知识点总结
文章目录
网络模型
OSI七层模型
TCP/IP四层模型
- 应用层：负责应用程序之间的通信和交互,该层协议定义了交换的报文的类型，语法，字段的语义以及进程何时，如何发送报文并对报文进行响应
- 传输层：负责端对端的连接的建立管理和维护
- 网络层：负责地址管理和IP选择
- 数据链路层：负责传输和识别数据帧
两种模型的对比总结
常用协议总结
HTTP协议
-
定义：HTTP协议是基于TCP/IP协议传送数据的协议，主要传送的数据类型有HTML文本，图片文件，查询结果等，一般用于B/S架构；
-
特点：
- 无连接：每次连接只会处理一个请求，处理完请求之后就会立即断开连接，节省传输时间
- 无状态：协议处理事务没有记忆能力，服务器处理完请求后不会记录任何信息
- 灵活：传输类型很灵活，可以在请求报头中content-type中标记
-
请求方法：
- GET：获取类请求
- PUST：新建类请求
- PUT：更新类请求
- DELETE：删除类请求
-
GET和POST的区别：
- get相对于post不安全，get的数据存在url上，对用户透明可见，而post的数据对用户相对不可见，使数据更加安全；
- get的数据长度有限制，存放在url上数据不宜过长，post对数据长度没有限制，放在请求体中；
- get支持的表单字符集只有ASCII，而post支持的字符集更加广泛；
- get支持浏览器回退，再次前进仍会保留原来的数据，而post回退后前进需要重新提交表单数据；
- get在浏览器中有缓存机制，post不会缓存；
- get的url可以保存为书签，post不可以；
-
请求报文格式：
- 请求报头eg：
-
HTTP1.0与HTTP1.1的区别：
- 支持长连接，一个TCP连接可以处理多个http请求，减少了三次握手的开销
- 节约带宽，http1.1支持先发送header信息，如果服务器认为客户端有权访问，则返回100，客户端继续发送请求信息，反之如果服务端认为客户端没有权限访问，则客户端不需要再发送请求信息，节约了带宽
- 缓存处理，http1.1支持更多的缓存控制策略
- 新增host域
-
HTTP1.1与HTTP1.2的区别：
- 多路复用，同一个连接并发处理多个请求
- 头部数据压缩，对header的数据压缩
- 服务器推送，允许服务器端推送资源给客户端
HTTPS协议
- 定义：基于HTTP协议，通过SSL或TLS提供加密处理数据，验证对方身份以及数据完整性保护
-
特点：
- 信息加密
- 身份验证
- 数据完整性校验
-
具体过程：
HTTP和HTTPS协议的区别
- 是否免费
- HTTP免费
- HTTPS需要到CA申请证书，免费的证书很少，一般都需要收费
- 安全性
- HTTP是超文本明文传输
- HTTPS有SSL加密传输，相对安全一些
- 连接方式
- HTTP默认端口是80
- HTTPS默认端口是443
- 连接复杂程度
- HTTP简单，无状态
- HTTPS加密传输，身份认证
DNS协议
- 域名解析协议：将网址转换为对应的IP
- 解析网址的过程：本地DNS服务器→根DNS服务器→*域DNS服务器→权威DNS服务器
TCP协议
- 传输控制协议
- 特点：
- 面向连接
- 可靠传输
- 有拥塞控制
- 首部开销大
- 面向字节流
- 全双工
-
三次握手与四次挥手
- 三次握手
- 具体过程：
-
问：为什么要三次握手而不是四次或者两次？
- 原因主要有两点：
- ① 防止数据传输延迟或者丢包的情况发生。如果客户端发送的数据发生延迟传输，而服务端过了很久才收到数据并返回给客户端应答数据，此时如果只有两次握手，服务端就以为自己与客户端已经建立了连接并等待客户端发送具体的请求数据，而客户端没有在规定时间内收到来自服务端的确认连接应答，并没有建立起连接，导致服务端资源空等浪费。
- ② 确认连接双方的接收发送数据的功能正常。第一次握手，客户端发送数据，服务端收到了，服务端可以确认自己的接收数据能力和对方的发送数据能力正常。第二次握手，服务端发送数据，客户端接收了，客户端可以确定自己的接收发送数据的能力以及服务端的接收发送数据能力都很正常。第三次握手，客户端发送数据，服务端接收数据，服务端可以确定自己和对方的接收发送功能都正常。
- 具体过程：
- 四次挥手
- 具体过程：
- 具体过程：
- 问：为什么要四次挥手？
- TCP是全双工通信的，因此服务端和客户端双发都可以发送数据和接收数据，客户端发送结束请求仅代表客户端自身不再发送数据给服务端，但依然可以接收来自服务端的数据，服务端同理，发送结束传输请求仅代表自身不再发送数据。
- 问：为什么客户端在确认服务端停止传输后要再等待一段时间？
- 等待的这一段时间是最长报文段寿命，同样是防止传送的数据发生延迟或者丢失。如果客户端最后确认的数据丢失或者延迟，服务端没有接收到确认数据 ，会再次发送结束传输的数据，如果没有等待的这一段，服务端就不能正常结束传输。
- 三次握手
UDP协议
- 用户数据报协议
- 特点：
- 无连接协议
- 信息报头短，额外开销小
- 吞吐量不受拥塞控制算法的调节，传输速率快
- 最大努力交付，但不保证可靠交付
- 一对一，一对多，多对多传输
TCP与UDP的区别
IP协议
- 网络之间互联的协议
- IPv4网络使用32位地址，以点分十进制表示，如192.168.0.1
- 127.0.0.1：本机；192.168.* .* ，10.* .*. * ：内部局域网；其他外部广域网；
- ip地址=网络号+主机号
- ip地址的分类：
- A类地址以0开头，第一字节作为网络号，地址范围为：0.0.0.0~127.255.255.255
- B类地址以10开头，前两个字节作为网络号，地址范围为：128.0.0.0~191.255.255.255
- C类地址以110开头，前三个字节作为网络号，地址范围为：192.0.0.0~223.255.255.255
- D类地址以1110开头，为组播地址，地址范围为：224.0.0.0~239.255.255.255
- E类地址以1111开头，为保留地址，地址范围为：240.0.0.0~255.255.255.255
- 注：只有A,B,C有网络号和主机号之分，D类地址和E类地址没有划分网络号和主机号。
ARP协议
- 地址解析协议：
- 将网络中的IP地址映射到主机的MAC地址，如交换机可以根据网络中的IP地址来找到本地主机的MAC地址。
- MAC地址：
- 媒体访问控制地址（物理地址，具有唯一性）。MAC地址用于在网络中唯一标示一个网卡，一台设备若有一或多个网卡，则每个网卡都需要并会有一个唯一的MAC地址
- 具体过程：
- 当交换机接收到来自网上一个数据包时，会根据该数据包的目标IP地址，查看交换机内部是否有跟该IP地址对应的MAC地址 ，如果有上次保留下来的对应的MAC地址，就会将该数据包 转发到对应MAC地址的主机上去。如果在交换机内部没有与目标)地址对应的MAC地址，则交换机会根据ARP协议将目标IP地址按照“表”中的对应关系映射成MAC地址 ，数据包就被转送到对应的MAC地址的主机上 。
数据的封装与解封过程
问：访问某网页的过程？
- 浏览器拿到网页的URL之后，通过DNS服务器找到URL中域名对应的IP地址；
- 拿到IP地址后，即可通过IP地址和默认端口号与对应的服务器建立TCP连接；
- 发送数据（封装过程）：
- 应用层： 为数据加上对应的应用层协议头
- 传输层： 将数据分段，标序号，添加端口号
- 网络层： 添加IP协议头，源IP，目的IP
- 数据链路层： 为数据添加帧头帧尾以及MAC地址
- 接收数据（解封过程）：与封装过程相反
- 传输完毕后断开TCP连接；
cookie与session
cookie
- 将用户的信息通过cookie保存到本地浏览器
session
- 将用户敏感的信息通过session保存到服务器端，服务器通过MD5加密算法生成一个sessionID，保存到cookie中
二者的区别对比
- Cookie机制是通过检查客户身上的"通行证"来确定客户身份的话， 那么Session机制就是通过检查服务器上的"客户明细表"来确认客户身份。 Session相当于程序在服务器上建立的一份客户档案， 客户来访的时候只需要查询客户档案表就可以了
- 存储位置
- cookie存储在客户端
- session存储在服务端
- 存储容量
- cookie每个不超过4KB，一个站点最多20个
- session没有上线，但为了服务器找想，会有session删除机制
- 存储方式
- cookie只能保存ASCII字符串，并通过编码方式存储为unicode字符或者二进制
- session可以存放任意类型的数据
- 隐私策略
- cookie对客户端可见，不安全
- session对客户端透明，不会有敏感信息泄漏的风险
- 有效期
- cookie 可通过设置参数达到长期有效
- session不会长期有效
- 适用场景
- cookie保存在客户端，不占用服务端，对于并发用户多的网站很友好
- session保存在服务端，如果用户过多，会消耗掉大量内存
- 跨域访问
- cookie支持跨域访问
- session不支持跨域访问
问：session产生的session_id放在cookie里面，如果用户把cookie禁止掉，是不是session也不能用了呢？
- 禁止掉cookie后，session当然可以用，不过通过其他的方式来获得这个sessionid，比如，可以跟在url的后面，或者以表单的形势提交到服务器端。从而使服务器端了解客户端的状态。
问：为什么说session 比cookie更安全？
- 真正的cookie存在于客户端硬盘上的一个文本文件，如果两者一样的话，只要cookie就好了，让客户端来分提服务器的负担，并且对于用户来说又是透明的。但实际上不是。
- session的sessionID是放在cookie里，要想功破session的话，得分两步：
- 第一要得到sessionID。攻破cookie后，你要得到sessionID,sessionID是要有人登录，或者启动session_start才会有，你不知道什么时候会有人登录。
- 第二取有效sessionID。sessionID是加密的，第二次session_start的时候，前一次的sessionID就没有用了，session过期时sessionid也会失效，想在短时间内功破加了密的 sessionID很难。session是针对某一次通信而言，会话结束session也就随着消失了。