TCP 的那些事儿（下）

这篇文章是下篇，所以如果你对TCP不熟悉的话，还请你先看看上篇《TCP的那些事儿（上）》 上篇中，我们介绍了TCP的协议头、状态机、数据重传中的东西。但是TCP要解决一个很大的事，那就是要在一个网络根据不同的情况来动态调整自己的发包的速度，小则让自己的连接更稳定，大则让整个网络更稳定。在你阅读下篇之前，你需要做好准备，本篇文章有好些算法和策略，可能会引发你的各种思考，让你的大脑分配很多内存和计算资源，所以，不适合在厕所中阅读。

TCP的RTT算法

从前面的TCP重传机制我们知道Timeout的设置对于重传非常重要。

• 设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
• 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

而且，这个超时时间在不同的网络的情况下，根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置，TCP引入了RTT——Round Trip Time，也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut），以让我们的重传机制更高效。 听起来似乎很简单，好像就是在发送端发包时记下t0，然后接收端再把这个ack回来时再记一个t1，于是RTT = t1 – t0。没那么简单，这只是一个采样，不能代表普遍情况。

TCP 的那些事儿（上）

TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1：协议》（当然，你也可以去读一下RFC793以及后面N多的RFC）。另外，本文我会使用英文术语，这样方便你通过这些英文关键词来查找相关的技术文档。

之所以想写这篇文章，目的有三个，

• 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清楚的能力。
• 另一个是觉得现在的好多程序员基本上不会认认真真地读本书，喜欢快餐文化，所以，希望这篇快餐文章可以让你对TCP这个古典技术有所了解，并能体会到软件设计中的种种难处。并且你可以从中有一些软件设计上的收获。
• 最重要的希望这些基础知识可以让你搞清很多以前一些似是而非的东西，并且你能意识到基础的重要。

所以，本文不会面面俱到，只是对TCP协议、算法和原理的科普。

我本来只想写一个篇幅的文章的，但是TCP真TMD的复杂，比C++复杂多了，这30多年来，各种优化变种争论和修改。所以，写着写着就发现只有砍成两篇。

• 上篇中，主要向你介绍TCP协议的定义和丢包时的重传机制。
• 下篇中，重点介绍TCP的流迭、拥塞处理。
  Read more »

Linux操作系统概览

物理内存

• 物理内存分 NUMA 节点，分别进行管理；
• 每个 NUMA 节点分成多个内存区域；
• 每个内存区域分成多个物理页面；
• 伙伴系统将多个连续的页面作为一个大的内存块分配给上层；
• kswapd 负责物理页面的换入换出；
• Slub Allocator 将从伙伴系统申请的大内存块切成小块，分配给其他系统

Linux操作系统概览

内核初始化

用户态 - 系统调用 - 保存寄存器 - 内核态执行系统调用 - 恢复寄存器 - 返回用户态

Just My Socks：搬瓦工官方翻墙服务，多条线路，IP不怕被墙

力荐！Just My Socks - 非常靠谱稳定的shadowsocks/V2ray代理服务！

文章目录

1. Just My Socks介绍
2. Just My Socks购买
3. Just My Socks优惠码
4. Just My Socks注册
5. Just My Socks信息查看
6. Just My Socks怎么用

Just My Socks是目前非常火热的一个Shadowsocks/V2ray服务商（机场），由搬瓦工官方推出，每个服务提供5条线路，包括最快的CN2 GIA线路。Just My Socks最大的优势是保证IP不被墙，如果IP被墙，会自动更换新的可用IP给用户。对于只是需要翻墙看看YouTube、ins或者谷歌以及谷歌学术的朋友，Just My Socks是一个非常合适的选择。

为什么查询一行数据也很慢?

1.MySQL数据库本身被堵住了，比如：系统或网络资源不够

2.SQL语句被堵住了，比如：表锁，行锁等，导致存储引擎不执行对应的SQL语句

3.确实是索引使用不当，没有走索引

4.表中数据的特点导致的，走了索引，但回表次数庞大

SQL语句被堵住的原因

• 表锁

1

mysql> select * from t where id=1;

长时间不返回,一般碰到这种情况的话，大概率是表 t 被锁住了。接下来分析原因的时候，一般都是首先执行一下

show processlist 命令，看看当前语句处于什么状态。然后我们再针对每种状态，去分析它们产生的原因、如何复

现，以及如何处理。

数据恢复过程

1.最近的一次全量备份 -> 2. 从备份的时间点开始,将备份的binlog 依次取出来重放到误删表之前的那个时刻

这样你的临时库就跟误删之前的线上库一样了,按需要恢复到线上库去。

日志模块

与查询流程不一样的是，更新流程还涉及两个重要的日志模块

redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）

查询优化

why?

优化的思路

客户端到服务器 其中包括 检验连接 查询缓存 解析 以及存储引擎涉及的调用 都会带来 cpu 内存 io等开销我们要

做的就是减少这些…

措施

​ 一个是检查是不是返回了 程序不需要的大量数据,大量数据会带来大量cpu以及io等损耗…

​ 一个是检查是不是扫了额外的行记录最简单的衡量查询开销的三个指标：1.响应时间2.扫描的行数3.返回的行

数, 关注数据的访问类型全表扫描 索引扫描 范围扫描 唯一索引扫描等…

为什么需要索引?

避免去扫全表,存储引擎先走索引找到对应值,然后根据索引记录找到对应的数据行.

优点的话,因为索引使用B+树结构 使得查询数据不再是随机IO,且避免去扫描全表

索引的策略(使用)

单列

不要在where 后面针对索引列计算,因为无法自动解析计算,所以需要避免索引列的一些计算

存储器结构

cpu -> 寄存器 -> 高速缓存 -> 主存 -> 磁盘

一种存储器抽象：地址空间

定义: 存储位置列表,存放可执行程序,程序的数据以及堆栈

地址空间是进程可以用来寻址内存的地址集。每个进程都有它自己的地址空间，独立于其他进程的地址空间，但是

某些进程会希望可以共享地址空间