沈阳做网站直播的公司,网站设计师联盟,创新型的赣州网站建设,稿定ai官网文章目录 下载链接网络问题综合问题访问一个网页的全过程#xff1f;WebSocket HTTPHTTP基本概念GET与POSTHTTP特性HTTP缓存技术HTTP的演变HTTP1.1 优化 HTTPSHTTP与HTTPS有哪些区别#xff1f;HTTPS解决了HTTP的哪些问题#xff1f;HTTPS如何解决的#xff1f;HTTPS是如何… 文章目录 下载链接网络问题综合问题访问一个网页的全过程WebSocket HTTPHTTP基本概念GET与POSTHTTP特性HTTP缓存技术HTTP的演变HTTP1.1 优化 HTTPSHTTP与HTTPS有哪些区别HTTPS解决了HTTP的哪些问题HTTPS如何解决的HTTPS是如何建立连接的HTTPS 的应用数据是如何保证完整性的HTTPS 一定安全可靠吗 TCPTCP基本认识TCP连接建立TCP连接断开socket编程重传机制滑动窗口流量控制拥塞控制TCP缺点如何基于UDP实现可靠传输TCP优化快速复用 TIME_WAITQUIC序列号和确认号 Mac地址表一个是设备的 MAC 地址另一个是该设备连接在交换机的哪个端口上 下载链接
链接: https://pan.baidu.com/s/1hRTh7rSesikisgRUO2GBpA?pwdutgp 提取码: 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 减少 SYNACK 重传次数
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 是过期的也不会丢弃 处于新连接建立可能收到旧的FINACK回RST 如果第四次挥手的 ACK 报文丢失了有可能被动关闭连接的一方不能被正常的关闭
QUIC 可靠传输 Packet Number 单调递增 配合 Stream ID 与 Offset 可以更加精确计算 RTT没有 TCP 重传的歧义性问题 可以支持乱序确认因为丢包重传将当前窗口阻塞在原地而 TCP 必须是顺序确认的丢包时会导致窗口不滑动 队头阻塞 每一个stream分配一个独立的滑动窗口 流量控制 window_update 帧告诉对端自己可以接收的字节数 BlockFrame 告诉对端由于流量控制被阻塞了 基于Stream和Connection的控制 拥塞控制 在应用层可以随便改算法主流使用TCP的 连接建立 321RTT - 210RTT 网络迁移 基于客户端服务端连接 ID无需重新建立
序列号和确认号 序列号 上一次发送的序列号 len 确认号 上一次收到的报文中的序列号 len
Mac地址表
一个是设备的 MAC 地址
另一个是该设备连接在交换机的哪个端口上
