下载链接
链接: 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