TCP 流量控制与窗口管理
TCP 必需要解决的可靠传输以及包乱序( reordering )的问题,所以, TCP 必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。
fmt.Println("Hello 久久 and 长长")
TCP 必需要解决的可靠传输以及包乱序( reordering )的问题,所以, TCP 必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。
由于 下层网络层( IP )可能出现丢失、重复或包乱序的情况,因此必须在 TCP 协议中提供可靠数据传输服务。 TCP 根据接收端返回至发送端的一系列确认信息来判断是否出现丢包。当数据段或 ACK 信息丢失,TCP 将启动重传操作。
Nagle 算法由 John Nagle 在1984年提出,这个算法可以减少网络中小的 packet 的数量,从而降低网络的拥塞程度。一个常见的例子就是 Telnet 程序,用户在控制台的每次击键都会发送一个 packet ,这个 packet 通常包含41个字节( IP 头部 20 字节 + TCP 头部 20 字节 + 1 个字节数据 ),然而只有一个字节是 payload ,其余 40 个字节都是 header ,如果每次击键都发送一个 packet ,那就会造成了巨大的开销。
[主动关闭]的一方发出 FIN 包,[被动关闭]的一方响应 ACK 包,此时,[被动关闭]的一方就进入了 CLOSE_WAIT 状态。如果一切正常,稍后[被动关闭]的一方也会发出 FIN 包,然后迁移到 LAST_ACK 状态。
我们都知道,TCP 关闭连接时,[主动关闭]连接一方会在接收到[被动关闭]连接一方的 FIN 包时,将会进入 TIME_WAIT 状态,再等待 2MSL 之后,再进入到 Closed 状态,以下是在 TCP 四次挥手的状态迁移图:
通常我们可以将备份的方法分为以下三种:
原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作都执行成功,才算整个事务成功。事务中任何一个 SQL 语句执行失败,已经执行成功的 SQL 语句也必须撤销,数据库状态应该回退到执行事务前的状态。
锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访问。 InnoDB 存储引擎会在行级别上对表数据进行上锁,也会在数据库内部其他多个地方使用锁,从而允许对多种不同资源提供并发访问。因此数据库使用锁是为了支持对共享资源进行并发访问,并提供数据库的完整性和一致性。
InnoDB 存储引擎支持以下几种常见的索引:
InnoDB 所支持的哈希索引是自适应的,会根据表的使用情况自动生成哈希索引,并且无法人为干预。
B+树索引就是传统意义上的索引,构造类似于二叉树,根据 Key Value 快速找到数据。需要注意的是,B+树的B不是代表二叉( binary ),而是表示平衡( balance ),因为 B+树是从最早的平衡二叉树演化而来的。需要注意的是:B+树索引并不能找到一个给定键值的具体行,而只是能查找到数据行所在的页,通过把页读入到内存之后,再在内存上进行查找到具体的行。
mysql 在启动时,会先读取一个配置参数文件,用来寻找数据库的各种文件所在位置以及指定某些初始化参数,配置文件的所在位置可以通过如下的命令查询:
|
|