文章目录
- 下载链接
- 网络问题
- 综合问题
- 访问一个网页的全过程?
- WebSocket
- HTTP
- HTTP基本概念
- GET与POST
- HTTP特性
- HTTP缓存技术
- HTTP的演变
- HTTP1.1 优化
- HTTPS
- HTTP与HTTPS有哪些区别?
- HTTPS解决了HTTP的哪些问题?
- HTTPS如何解决的?
- HTTPS是如何建立连接的?
- HTTPS 的应用数据是如何保证完整性的
- HTTPS 一定安全可靠吗?
- TCP
- TCP基本认识
- TCP连接建立
- TCP连接断开
- socket编程
- 重传机制
- 滑动窗口
- 流量控制
- 拥塞控制
- TCP缺点
- 如何基于UDP实现可靠传输?
- TCP优化
- 快速复用 TIME_WAIT
- QUIC
- 序列号和确认号
- Mac地址表
- 一个是设备的 MAC 地址,
- 另一个是该设备连接在交换机的哪个端口上
下载链接
链接: https://pan.baidu.com/s/1hRTh7rSesikisgRUO2GBpA?pwd=utgp 提取码: utgp
最近总结了Linux网络的内容,总结内容如下:
网络问题
综合问题
访问一个网页的全过程?
-
发过去
-
应用层
-
- 浏览器地址输入URL
- 1.1 浏览器查看缓存,强制和协商缓存
-
- 解析URL获取协议,主机,端口,路径
-
- 生成HTTP请求报文
-
- 获取主机IP
-
4.1 浏览器缓存
-
4.2 主机缓存
-
4.3 DNS域名解析
-
4.4 路由器解析
-
-
传输层
-
- 建立TCP连接,三次握手
-
- 给报文添加TCP报头
-
- 向下传输,发送报文
-
-
网络层
-
- 通过解析出的IP添加IP报头
-
- 向下传输,发送报文
-
-
网卡
- 转换为电信号
-
交换机
-
电信号到达网线接口,交换机里的模块进行接收,接下来交换机里的模块将电信号转换为数字信号
-
将包存入缓冲区后,接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录
- 如果没有匹配,全部转发
-
-
路由器(网卡)
-
检查MAC地址看看是不是给自己的
- 是,收到缓冲区当中
-
去掉MAC头部,查询路由表确定端口
-
发送包
-
看网关,如果有网关就向这个IP发
-
利用ARP查询MAC地址
-
再做一个有MAC的包
- 通过交换机到达下一个路由器
-
-
-
-
-
-
收回来
-
- 接收HTTP响应
-
- 根据状态码处理情况
-
-
这个问题我基于TCP/IP的网络模型来回答,并且暂时不考虑浏览器缓存的情况。
首先看一下应用层:对于应用层,当用户输入一个网址后,此时会进行URL解析,根据URL构建出想要请求的资源路径,使用的协议,具体方法,请求的IP和端口信息。其中IP需要使用DNS域名解析协议来进行获取,基于这些内容,一个初步的报文就在应用层构建完毕了,此时应用层就完成了自己的任务。
现在数据包来到传输层了,Http协议基本都是遵循TCP协议的,因此我们只考虑TCP协议的情况,到达传输层后,建立TCP的三次握手,如果是HTTPS再构建四次TLS握手,最终可以进行收发数据,此时就给报文添加一个TCP的报头,然后继续向下传递
现在数据包来到网络层了,网络层根据解析出的IP地址以及自身的属性,最终构建出一个IP的报头,添加到数据包前,然后继续向下传递
此时数据包来到了网络接口层,数据包在网络中的传输依赖于路由器和交换机的协同工作。路由器根据路由表选择最佳路径,将数据包转发到下一个网络。交换机则根据MAC地址表快速转发帧到目标网络接口。如果MAC地址表中没有目标MAC地址,交换机会将帧广播到所有端口,直到找到正确的接收者
数据包在进行传输的过程中,网络中的每一个设备都可以对这个包进行接受,接受到包之后,根据MAC地址来判断是不是给自己的,如果是给自己的就留下来,收到缓冲区中,去掉这个没有用的MAC头部,然后到自己的路由表中进行查询,如果此时网关列中没有信息,那么就说明这个数据包已经传输到了指定的服务器,如果网关列中有数据,那么就根据网关中的这个IP,利用ARP协议来获取IP对应的MAC地址,然后插入到这个包前,然后继续进行发送,通过交换机到达下一个路由器,直到到达指定的服务器
到达指定的服务器后,服务器就会对于包进行层层解析,一直解析到应用层的数据,之后构建一个Http响应,再发回去即可
WebSocket
-
借助HTTP协议进行升级
-
101状态码 -> 协议切换
-
完美继承全双工
-
用报头+有效载荷解决粘包问题
HTTP
HTTP基本概念
-
HTTP是什么?
-
HTTP常见的状态码有哪些?
-
HTTP常见字段有哪些?
GET与POST
-
有什么区别?
-
是安全和幂等的吗?
HTTP特性
-
HTTP/1.1 优点有哪些?
-
简单
-
跨平台
-
扩展
-
报头随意补充
-
下层随意变化
-
-
-
HTTP/1.1 缺点有哪些?
-
无状态
-
明文传输
-
不安全
-
-
HTTP/1.1 性能如何?
-
长连接
- 对比1.0和1.1
-
管道
- 请求和响应的队头阻塞
-
HTTP缓存技术
-
HTTP缓存有哪些实现方式?
- 强制和协商
-
什么是强制缓存?
-
什么是协商缓存?
HTTP的演变
-
HTTP1.1 相比 HTTP/1.0 提高了什么性能?
-
问题
-
报头不压缩
-
冗余头部
-
响应对头阻塞
-
无请求优先级
-
无全双工
-
-
-
HTTP/2 做了什么优化?
-
头部压缩
-
二进制格式
-
并发传输
-
服务器主动推送资源
-
-
HTTP/3 做了什么优化?
-
解决TCP队头阻塞
-
无队头阻塞
- 只阻塞当前流,其他流不影响
-
更快的连接建立
- 1 个 RTT 就可以完成建立连接与密钥协商
-
连接迁移
- TCP换连接成本很高
-
HTTP1.1 优化
-
如何避免发送HTTP请求?
- 缓存
-
如何减少HTTP请求次数?
-
减少重定向次数
-
合并请求
-
延迟发送
- 一个网页里面的内容慢慢加载
-
-
如何减少HTTP响应数据大小?
-
无损压缩
-
有损压缩
-
HTTPS
HTTP与HTTPS有哪些区别?
- HTTPS 在 TCP 三次握手之后,还需进行 SSL/TLS 的握手过程
HTTPS解决了HTTP的哪些问题?
-
窃听风险
-
篡改风险
- 冒充风险
-
-
信息加密
-
校验机制
- 身份证书
-
HTTPS如何解决的?
-
混合加密(不窃听)
-
非对称加密用于密钥交换
- 客户端发给服务端一个会话密钥(CA),服务端用私钥解开,双方就获得了一个通信的密钥对
-
对称加密用于数据传输
- HTTPS使用对称加密的会话密钥来加密和解密数据
-
-
摘要算法+数字签名
-
通过哈希算法可以确保内容不会被篡改
- 通过数字签名(私钥解密)确保哈希值不被替换
-
-
数字证书
-
防止又换私钥又换公钥
- 进行一个注册(个人信息 + 公钥 + 数字签名)
-
-
公钥加密,私钥解密
- 保证内容传输的安全
-
私钥加密,公钥解密
- 保证消息不会被冒充
HTTPS是如何建立连接的?
-
SSL/TLS 协议基本流程
-
客户端向服务器索要并验证服务器的公钥
-
双方协商生产「会话秘钥」
-
双方采用「会话秘钥」进行加密通信
-
-
TLS 握手
-
ClientHello
-
SeverHello
-
客户端回应
- 确认数字证书,取出公钥
-
服务器的最后回应
- 计算出本次通信的「会话秘钥」
-
HTTPS 的应用数据是如何保证完整性的
-
握手协议
- TLS 四次握手的过程负责协商加密算法和生成对称密钥
-
记录协议
- 保护应用程序数据并验证其完整性和来源,对 HTTP 数据加密
-
数据加密过程
-
消息被分割和压缩
-
加上消息认证码MAC 值
-
压缩的片段和消息认证码一起进行加密
-
带上报头,组成报文
-
HTTPS 一定安全可靠吗?
-
https本身一定是没问题的,一定是客户端本身有问题
-
电脑中病毒,证书被换了
- 提醒证书可能被劫持,执意访问
-
-
HTTPS双向认证,如果服务端觉得客户端不值得信任,就不通信
TCP
TCP基本认识
-
TCP报头?
-
为什么需要TCP?工作在哪?
-
什么是TCP?
- 面向连接可靠字节流
-
什么是TCP连接?
-
需要客户端与服务端达成上述三个信息的共识
-
socket
- ip+端口
-
序列号
-
窗口大小
-
-
-
如何确定TCP连接?
-
四元组
- 这个很重要,当判断TCP连接建立,就要看这个四元组
-
-
TCP和UDP的区别和应用场景?
-
连接
-
可靠性
-
传输方式
-
服务对象
- 一对一…
-
拥塞和流量控制
-
首部开销
-
分片不同
-
-
为什么TCP有首部长度而UDP没有?
-
为什么UDP有包长度而TCP没有?
- 历史问题
TCP连接建立
-
TCP三次握手过程和状态变迁?
- 第三次握手是可以携带数据的,前两次握手是不可以携带数据的
-
如何查看TCP状态?
-
为什么是三次,不是两次四次?
-
验证收发能力
-
历史连接
-
同步序列号
- 资源浪费
-
-
-
「两次握手」:无法防止历史连接的建立,会造成双方资源的浪费,也无法可靠的同步双方序列号;
-
「四次握手」:三次握手就已经理论上最少可靠连接建立,所以不需要使用更多的通信次数。
-
-
为什么初始化序列号都不一样?
-
为了防止历史报文被下一个相同四元组的连接接收
-
为了安全性,防止黑客伪造的相同序列号的 TCP 报文被对方接收
-
-
序列号是如何随机产生的?
- 随机数是会基于时钟计时器递增的,基本不可能会随机成一样的初始化序列号
-
TCP层为什么需要MSS?
- 如果一个 IP 分片丢失,整个 IP 报文的所有分片都得重传
-
第一次握手丢失会怎么样?
-
第二次握手丢失会怎么样?
- 都发
-
第三次握手丢失会怎么样?
-
什么是SYN攻击?如何避免?
-
占满服务端的半连接队列
-
调大 netdev_max_backlog
-
增大 TCP 半连接队列
-
开启 tcp_syncookies
- 减少 SYN+ACK 重传次数
-
-
-
TCP连接断开
-
TCP四次挥手过程和状态变迁?
-
为什么需要四次挥手?
- close和shutdown的区别
-
第一次挥手丢失了会怎么样?
-
第二次挥手丢失了会怎么样?
-
第三次挥手丢失了会怎么样?
-
第四次挥手丢失了会怎么样?
-
为什么TIME_WAIT时间是2MSL?
- 2个报文最大生存时间
-
为什么需要TIME_WAIT?
-
防止历史数据
-
优雅的关闭
-
-
TIME_WAIT太多会怎么样?
- 系统+端口
-
如何优化TIME_WAIT?
-
如果建立连接后,客户端故障怎么办?
-
TCPkeepalive
- 失活报文看看活不活
-
-
如果建立连接后,服务端进程崩溃怎么办?
socket编程
-
TCP的socket编程?
-
listen参数的意义?
- accept队列大小
-
accept是在哪一步?
-
客户端close后的流程?
-
没有accept还能连接吗?
- accept只是从队列取元素
-
没有listen还能连接吗?
- 自连接,哈希表
重传机制
-
超时重传?
-
数据包丢失
- 确认应答丢失
-
-
快速重传?
- 优化,但不保底
-
SACK是什么?
- 标识已收到的报文
-
D-SACK是什么?
- 标识重复收到的报文
滑动窗口
-
发送窗口?
-
接收窗口?
流量控制
-
缓冲区和滑动窗口的关系?
- 不能又收缩又少缓存
-
窗口关闭?
-
打满了,不再收数据
-
问题?解决?
-
-
什么是糊涂窗口综合征?
- 每次发送数据很小,效率低
拥塞控制
-
慢启动
-
拥塞避免
-
拥塞发生
-
快速恢复
TCP缺点
-
升级困难 改内核
-
队头阻塞
-
建立连接延迟
-
网络迁移
如何基于UDP实现可靠传输?
-
序列号
-
确认应答
-
超时重传
-
流量控制
-
拥塞控制
-
优化TCP连接建立
-
网络迁移
TCP优化
-
绕过三次握手
- cookie
快速复用 TIME_WAIT
-
历史 RST 报文可能会终止后面相同四元组的连接,因为 PAWS 检查到即使 RST 是过期的,也不会丢弃
-
处于新连接建立可能收到旧的FIN+ACK,回RST
如果第四次挥手的 ACK 报文丢失了,有可能被动关闭连接的一方不能被正常的关闭
QUIC
-
可靠传输
-
Packet Number 单调递增
配合 Stream ID 与 Offset-
可以更加精确计算 RTT,没有 TCP 重传的歧义性问题;
-
可以支持乱序确认,因为丢包重传将当前窗口阻塞在原地,而 TCP 必须是顺序确认的,丢包时会导致窗口不滑动
-
-
-
队头阻塞
- 每一个stream分配一个独立的滑动窗口
-
流量控制
-
window_update 帧告诉对端自己可以接收的字节数
-
BlockFrame 告诉对端由于流量控制被阻塞了
-
基于Stream和Connection的控制
-
-
拥塞控制
- 在应用层可以随便改算法,主流使用TCP的
-
连接建立
- 321RTT -> 210RTT
-
网络迁移
- 基于客户端服务端连接 ID,无需重新建立
序列号和确认号
-
序列号 = 上一次发送的序列号 + len
-
确认号 = 上一次收到的报文中的序列号 + len