后端开发:计算机网络、数据库常识

文章目录

TCP和UDP的区别

TCP(传输控制协议)和UDP(用户数据报协议)是互联网协议栈中两种重要的传输层协议,在多个方面存在显著区别,以下是具体介绍:

连接方式
  • TCP :是面向连接的协议。在数据传输之前,需要先建立连接,经历"三次握手"过程,确保通信双方准备好传输数据。数据传输完成后,还需要通过"四次挥手"来释放连接。
  • UDP:是无连接的协议。发送数据时不需要事先建立连接,直接将数据报发送出去,发送方和接收方之间没有建立连接的过程。
可靠性
  • TCP :具有高可靠性。通过确认机制、重传机制 来确保数据准确无误地到达接收方。当发送方发送数据后,会等待接收方的确认应答,如果在规定时间内未收到确认,就会重新发送数据。同时,TCP还会对数据进行排序和去重,保证数据按照正确的顺序到达,并且不会有重复的数据。
  • UDP :可靠性较低。发送数据后不会等待接收方的确认,也没有重传机制,数据是否到达接收方完全取决于网络状况。此外,UDP也不对数据进行排序和去重,数据可能会出现丢失、重复或乱序的情况。
传输效率
  • TCP:由于需要建立连接、确认数据、重传数据等操作,会引入一定的开销,传输效率相对较低。
  • UDP:不需要建立连接和进行复杂的确认机制,传输过程简单,开销小,传输效率相对较高。
传输速度
  • TCP:传输速度相对较慢,因为其可靠性机制会增加数据传输的延迟。
  • UDP:传输速度相对较快,适合对实时性要求较高的应用场景,如视频会议、直播等。
数据传输单位
  • TCP:以字节流的形式传输数据,数据没有边界,发送方和接收方需要自己处理数据的边界问题。
  • UDP:以数据报的形式传输数据,每个数据报都有明确的边界,发送方将数据分成若干个数据报进行发送,接收方每次接收一个完整的数据报。
流量控制和拥塞控制
  • TCP :支持流量控制和拥塞控制。通过滑动窗口机制来实现流量控制,防止发送方发送数据过快,导致接收方缓冲区溢出。同时,TCP还通过拥塞控制算法来避免网络拥塞,当网络出现拥塞时,TCP会降低数据传输速率。
  • UDP:不支持流量控制和拥塞控制,发送方会以固定的速率发送数据,不会根据网络状况调整发送速率。
应用场景
  • TCP:适用于对可靠性要求高的应用场景,如文件传输、电子邮件、远程登录等。
  • UDP:适用于对实时性要求高、对可靠性要求不高的应用场景,如视频会议、直播、网络游戏等。
头部开销
  • TCP:头部开销较大,通常为20字节,当有可选字段时,头部长度会更长。
  • UDP:头部开销较小,固定为8字节,包括源端口号、目的端口号、长度和校验和。

以下是TCPUDP区别的表格总结:

对比项 TCP UDP
连接方式 面向连接 无连接
可靠性 高可靠性 低可靠性
传输效率 较低 较高
传输速度 较慢 较快
数据传输单位 字节流 数据报
流量控制和拥塞控制 支持 不支持
应用场景 文件传输、电子邮件等 视频会议、直播等
头部开销 较大(20字节+可选字段) 较小(8字节)
TCP三次握手

TCP三次握手是建立TCP连接的重要过程,用于确保通信双方的发送和接收能力正常,并协商初始序列号(ISN)。下面详细解释这一过程:

三次握手的具体步骤
1. 客户端向服务器发送SYN包(第一次握手)
  • 目的:客户端向服务器表明"我想要建立连接",并请求服务器分配资源。
  • 发送内容
    • SYN标志位:置为1,表示这是一个连接请求。
    • 初始序列号(ISN) :客户端随机生成一个序列号(如x),后续数据传输将基于此序列号递增。
  • 状态变化 :客户端从CLOSED状态变为SYN_SENT状态。
2. 服务器响应SYN+ACK包(第二次握手)
  • 目的:服务器确认客户端的请求,并分配资源(如缓冲区)。
  • 发送内容
    • SYN标志位:置为1,表示这是一个连接请求的响应。
    • ACK标志位:置为1,表示确认客户端的请求。
    • 确认号(ACK) :值为x+1,表示"我已收到你发送的序列号x,期待下一个序列号是x+1"。
    • 服务器的初始序列号(ISN) :服务器随机生成一个序列号(如y)。
  • 状态变化 :服务器从LISTEN状态变为SYN_RCVD状态。
3. 客户端发送ACK包(第三次握手)
  • 目的:客户端确认服务器的响应,完成连接建立。
  • 发送内容
    • ACK标志位:置为1,表示确认服务器的连接请求。
    • 确认号(ACK) :值为y+1,表示"我已收到你发送的序列号y,期待下一个序列号是y+1"。
  • 状态变化
    • 客户端从SYN_SENT状态变为ESTABLISHED状态(连接已建立)。
    • 服务器收到ACK后,从SYN_RCVD状态变为ESTABLISHED状态。
为什么需要三次握手?
1. 确认双方的发送和接收能力
  • 第一次握手 :服务器收到客户端的SYN包,确认客户端的发送能力正常。
  • 第二次握手 :客户端收到服务器的SYN+ACK包,确认服务器的发送和接收能力正常。
  • 第三次握手 :服务器收到客户端的ACK包,确认客户端的接收能力正常。
2. 防止历史连接的初始化
  • 如果网络延迟导致旧的SYN包到达服务器,服务器会响应SYN+ACK。此时客户端发现序列号不匹配(非当前连接的ISN),会发送RST包拒绝连接,避免错误地建立连接。
3. 协商初始序列号(ISN)
  • 双方通过随机生成的ISN作为初始序列号,避免数据混乱。后续传输的数据序列号基于此递增,确保可靠性。
图示
复制代码
客户端                         服务器
  |                             |
  | SYN=1, Seq=x                |
  | --------------------------> |  LISTEN
  |                             |  SYN_RCVD
  | SYN=1, ACK=1, Seq=y         |
  | Ack=x+1 <------------------ |
  |                             |
  | ACK=1, Seq=x+1              |
  | Ack=y+1 ------------------> |  ESTABLISHED
  | ESTABLISHED                 |
常见问题
1. 为什么不是两次握手?
  • 若只有两次握手,服务器无法确认客户端是否收到自己的SYN包。例如:
    • 客户端发送SYN包(序列号为1),但该包丢失。
    • 客户端重发SYN包(序列号为2),服务器响应SYN+ACK
    • 客户端收到响应后,连接建立。但如果第一个SYN包在网络中延迟后到达服务器,服务器会误认为是新的连接请求并响应,导致错误地建立连接。
2. SYN Flood攻击与防御
  • 攻击原理 :攻击者伪造大量SYN包发送给服务器,服务器响应SYN+ACK后无法收到第三次握手的ACK,导致连接资源被耗尽(半连接队列满)。
  • 防御方法
    • TCP SYN Cookie :服务器不缓存半连接状态,而是通过算法生成确认号(如f(x)),收到ACK时验证其有效性。
    • 增大半连接队列 :通过系统参数调整(如Linuxnet.ipv4.tcp_max_syn_backlog)。
总结

TCP三次握手通过"请求-响应-确认"的方式,确保双方通信能力正常、防止历史连接干扰,并为后续数据传输建立可靠的序列号基础。这一机制是TCP协议可靠性的重要保障。

https如何保证安全性

HTTPS(Hyper Text Transfer Protocol Secure)通过加密、身份验证和数据完整性保护等多重机制来保证网络通信的安全性,其核心原理围绕TLS/SSL协议(传输层安全/安全套接层)展开。以下是具体的安全保障机制:

一、HTTPS的核心架构与安全组件

HTTPS基于TCP/IP协议,在应用层(HTTP)和传输层(TCP)之间引入TLS/SSL协议层,主要通过以下组件实现安全通信:

  1. 对称加密:使用单一密钥对数据进行加密和解密,效率高但密钥传输存在风险。
  2. 非对称加密:使用公钥加密、私钥解密(或反之),安全性高但计算开销大。
  3. 数字证书 :由可信证书颁发机构(CA)签发,用于验证服务器身份。
  4. 哈希算法:用于验证数据完整性,确保内容未被篡改。
二、HTTPS的安全保障机制详解
1. 加密通信:混合加密机制
  • 非对称加密用于密钥协商
    • 客户端与服务器通过非对称加密(如RSA、ECC)协商一个对称加密密钥(会话密钥)。
    • 服务器将公钥通过数字证书发送给客户端,客户端用公钥加密会话密钥并发送给服务器,服务器用私钥解密获取密钥。
  • 对称加密用于数据传输
    • 双方使用协商好的会话密钥对实际传输的数据进行加密和解密,避免明文传输。
    • 优势:结合非对称加密的安全性和对称加密的效率,解决了对称加密密钥传输的风险。
2. 身份验证:数字证书与CA体系
  • 数字证书的作用
    • 服务器向CA(如DigiCert、Let's Encrypt)申请数字证书,证书包含服务器公钥、域名、有效期及CA签名等信息。
    • 客户端收到证书后,通过CA的根证书(内置在浏览器/系统中)验证证书的合法性,确保连接的服务器是真实可信的(而非伪造的钓鱼网站)。
  • 证书验证流程
    1. 客户端获取服务器的数字证书。
    2. CA的公钥解密证书中的CA签名,得到证书的哈希值。
    3. 客户端对证书内容计算哈希值,与解密后的哈希值对比,验证证书是否被篡改。
    4. 检查证书的域名是否与当前访问的域名一致,防止域名劫持。
3. 数据完整性保护:哈希与MAC(消息认证码)
  • 哈希算法的应用
    • 发送方将数据通过哈希算法(如SHA-256)生成消息摘要,并将摘要与数据一起发送。
    • 接收方对收到的数据计算哈希值,与收到的摘要对比,若一致则证明数据未被篡改。
  • MAC机制增强安全性
    • 结合会话密钥与哈希算法生成消息认证码(MAC),确保数据在传输过程中未被篡改或伪造。
    • 即使攻击者篡改数据,由于没有会话密钥,无法生成正确的MAC,接收方会检测到数据异常。
4. 握手过程:建立安全连接的关键步骤

HTTPSTLS握手过程(以TLS 1.3为例)如下:

  1. 客户端发送ClientHello
    • 包含支持的TLS版本、加密算法套件、随机数(Random1)等信息。
  2. 服务器响应ServerHello
    • 选择TLS版本和加密算法,返回服务器数字证书、随机数(Random2),并发送ServerHelloDone
  3. 客户端验证证书并生成会话密钥
    • 验证证书合法性,提取服务器公钥,生成预主密钥(Pre-Master Secret),用公钥加密后发送给服务器。
    • 客户端与服务器通过Pre-Master Secret和两个随机数计算出会话密钥。
  4. 双向验证(可选)
    • 若要求客户端认证,服务器会发送CertificateRequest,客户端返回自己的证书。
  5. 握手完成
    • 双方发送Finished消息,使用会话密钥加密,验证握手过程的完整性。
    • 后续数据传输均使用会话密钥加密。
三、HTTPS抵御的安全风险
  1. 窃听攻击:加密机制防止数据被中间人监听获取明文。
  2. 中间人攻击(MITM)
    • 数字证书验证确保客户端连接的是真实服务器,而非伪造的中间人。
    • 若中间人伪造证书,客户端会提示"证书无效",阻止连接。
  3. 数据篡改:MAC机制确保数据在传输中未被篡改,若篡改则会被检测到并丢弃。
  4. 身份伪造:数字证书由CA签发,确保服务器身份真实可信,防止钓鱼网站伪装。
四、HTTPS的局限性与安全隐患
  1. 证书信任链的风险
    • 若CA机构被攻击或恶意签发证书,可能导致中间人攻击(如2011年DigiNotar证书伪造事件)。
  2. 加密流量的隐私与监控
    • 企业或政府可能通过部署SSL证书代理(如WAF设备)解密流量,存在隐私泄露风险。
  3. 老旧协议与算法的漏洞
    • 若服务器支持过时的TLS版本(如TLS 1.0)或弱加密算法,可能被破解(如POODLE漏洞利用TLS 1.0的缺陷)。
  4. 性能开销
    • 加密和解密过程会增加服务器负载和通信延迟,可通过硬件加速(如SSL卸载)或优化握手流程(如TLS 1.3减少握手延迟)缓解。
五、HTTPS的最佳实践
  1. 使用最新的TLS版本:优先使用TLS 1.3,禁用TLS 1.0/1.1及不安全的加密算法。
  2. 选择可信的CA证书:避免使用自签名证书,定期更新证书防止过期。
  3. 启用HSTS(HTTP Strict Transport Security):强制浏览器只能通过HTTPS访问,防止HTTP劫持。
  4. 监控证书状态:通过OCSP(在线证书状态协议)或CRL(证书吊销列表)验证证书是否被吊销。
  5. 部署前向保密(Perfect Forward Secrecy, PFS):使用ECDHE等算法,确保会话密钥的安全性,即使私钥泄露也无法解密历史通信。
总结

HTTPS通过加密通信、身份验证、数据完整性保护 的组合机制,构建了一套完整的安全体系,有效抵御了网络中的窃听、篡改和伪造等风险。尽管存在一定的性能开销和信任链风险,但通过技术优化和规范管理,HTTPS已成为互联网安全通信的标准配置。

数据库索引

数据库索引是提升查询效率的关键技术,通过不同的数据结构和组织方式优化数据检索。以下是常见的索引类型及其特点:

1. B树与B+树索引
B树(B-Tree)
  • 结构:平衡多路搜索树,每个节点可存储多个键值和指向子节点的指针。
  • 特点
    • 所有节点都包含数据(键值和记录指针)。
    • 适用于范围查询和等值查询。
  • 应用 :早期数据库系统(如IBM DB2)。
B+树(B+Tree)
  • 结构:B树的变种,非叶子节点仅存储索引键,数据仅存储在叶子节点。
  • 特点
    • 叶子节点通过指针相连,支持高效的范围查询。
    • 所有查询路径长度相同,保证稳定的查询性能。
  • 应用 :主流数据库(如MySQL InnoDB、Oracle、SQL Server)的默认索引结构。
2. 哈希索引
  • 原理:使用哈希表存储索引键与数据行的映射关系。
  • 特点
    • 等值查询极快(O(1)时间复杂度)。
    • 不支持范围查询,且存在哈希冲突问题。
  • 应用
    • MySQLMemory引擎默认使用哈希索引。
    • Redis等内存数据库的主键索引。
3. 全文索引
  • 原理 :对文本内容(如文章、评论)建立倒排索引,记录每个词在哪些文档中出现。
  • 特点
    • 支持复杂的文本搜索(如关键词匹配、模糊查询)。
    • 需要分词处理,占用空间较大。
  • 应用
    • MySQL的FULLTEXT索引(适用于MyISAMInnoDB)。
    • 搜索引擎(如Elasticsearch、Solr)。
4. 空间索引
  • 原理:针对地理空间数据(如坐标、多边形)优化查询。
  • 常见结构
    • R树:类似B树,用于多维空间数据。
    • 四叉树/八叉树:递归分割空间为子区域。
  • 应用
    • PostgreSQLPostGIS扩展。
    • MySQLSPATIAL索引。
    • 地图应用(如查找附近的POI)。
5. 位图索引
  • 原理:为每个键值创建一个位图,用位(0/1)表示记录是否包含该键。
  • 特点
    • 适合低基数列(如性别、状态)。
    • 支持高效的AND、OR等布尔运算。
  • 应用
    • 数据仓库(如Oracle、Teradata)。
    • 不适合频繁更新的场景(位图更新开销大)。
6. 聚簇索引(Clustered Index)
  • 定义:物理存储顺序与索引顺序一致的索引,一个表只能有一个聚簇索引。
  • 特点
    • 数据行直接存储在索引的叶子节点中(如InnoDB的主键索引)。
    • 查询时无需二次查找,效率高。
  • 应用
    • MySQL InnoDB的主键索引(聚簇索引)。
    • SQL ServerCLUSTERED INDEX
7. 非聚簇索引(Non-Clustered Index)
  • 定义:索引与数据物理存储分离,叶子节点存储指向数据行的指针。
  • 特点
    • 一个表可以有多个非聚簇索引。
    • 查询时可能需要回表(先查索引,再查数据)。
  • 应用
    • InnoDB的二级索引(辅助索引)。
    • 所有非主键索引通常是非聚簇的。
8. 覆盖索引(Covering Index)
  • 定义:索引包含查询所需的所有列,无需回表。

  • 特点

    • 显著提升查询性能,减少I/O操作。
  • 示例

    sql 复制代码
    SELECT user_id, name FROM users WHERE age > 18;
    -- 使用 (age, name, user_id) 复合索引可覆盖查询
9. 复合索引(组合索引)
  • 定义:多个列组合成一个索引,遵循"最左前缀原则"。
  • 特点
    • 适用于多条件查询(如WHERE a=1 AND b=2)。
    • 索引顺序影响查询效率(高频过滤条件优先)。
  • 应用
    • MySQLCREATE INDEX idx_name ON table(a, b, c)
10. 自适应哈希索引(Adaptive Hash Index)
  • 原理:数据库自动为频繁访问的索引页建立哈希索引,加速访问。
  • 特点
    • 完全自动管理,无需人工干预。
    • InnoDB的优化特性之一。
11. 倒排索引(Inverted Index)
  • 原理:记录每个值出现的位置(如全文索引)。
  • 应用
    • 搜索引擎、日志分析系统。
    • 某些NoSQL数据库(如Apache Solr)。
总结
索引类型 适用场景 典型应用
B+树 范围查询、等值查询 MySQL、Oracle
哈希索引 等值查询 MySQL Memory引擎
全文索引 文本搜索 Elasticsearch
空间索引 地理数据查询 PostGIS
位图索引 低基数列的布尔运算 数据仓库
聚簇索引 主键查询 InnoDB主键
复合索引 多条件查询 联合查询
覆盖索引 避免回表 优化查询

选择合适的索引类型需结合业务场景、数据特点和查询模式,错误的索引可能导致性能退化。

相关推荐
汪子熙2 小时前
HSQLDB 数据库锁获取失败深度解析
数据库·后端
用户2018792831672 小时前
通俗易懂的讲解:Android系统启动全流程与Launcher诞生记
android
VvUppppp2 小时前
MYSQL进阶
mysql
二流小码农2 小时前
鸿蒙开发:资讯项目实战之项目框架设计
android·ios·harmonyos
用户2018792831673 小时前
WMS 的核心成员和窗口添加过程
android
用户2018792831674 小时前
PMS 创建之“软件包管理超级工厂”的建设
android
用户2018792831674 小时前
通俗易懂的讲解:Android APK 解析的故事
android
渣渣_Maxz4 小时前
使用 antlr 打造 Android 动态逻辑判断能力
android·设计模式
Android研究员4 小时前
HarmonyOS实战:List拖拽位置交换的多种实现方式
android·ios·harmonyos
无色海4 小时前
mysql连接生命周期-连接阶段
数据库