[网络协议]Remember this！

Remember this！

mysql高级（底层存储引擎、事务、索引及优化、查询优化、锁机制、读写分离-主从结构）

一、内部结构：

mysql是一个可拔插的内部结构，包括连接池、解析器、查询优化器、缓存区（cache和buffer）、file system（redo、undo、binlog、索引等）、存储引擎。
常用的知识点:

• WAL: 写前日志包括redo和undo

• redo log : 记录事务的动作

• undo log： 记录事务的操作

• bin log: 主从数据库中记录主的日志

• relay log : 主从数据库中从数据库的日志

• 存储引擎：innodb 、myisam、 dbd、 memory

问题1 : select语句的执行过程:

问题2：INNODB和MYISAM的比较：

INNODB有事务、支持外键、支持聚集索引、支持行锁、适用于安全性较高、且写操作较多的表（订单表、账号表）
MYISAM无事务、无外键、支持非聚集索引、支持表锁、查询所读快、支持批量插入、适用于读操作较多、或需要大规模插入的表（论坛表、回复表）

二、事务：

问题1 ： 什么是事务、有哪些特性?

事务就是一组对数据操作的集合

• A 原子性：事务要么都做、要么都不做

• C 一致性：事务不影响数据库完整性（约束完整性、数据完整性）

• 隔离性：两个事务之前互相不影响（锁+MVCC）

• D 持久性：事务修改后，进行持久化保存

其中原子性、持久性、隔离性中的MVCC由redo和undo来实现。而一致性中的数据完整性是由其他三个特征共同作用的结果，并不是依赖于某一种单独的技术。

原理：在操作事务前，先要在磁盘中写数据到buffer pool中，当此时出现断网等意外操作时，会先去redo log中寻找事务做了哪些操作，再去undo log中找到事务到底改变了什么数据，这样整个事务就完成了恢复。

问题2 ： 事务的隔离级别于数据库隔离出现问题的对应关系是什么？

脏读：RU下，事务A读到了事务B未提交的数据。

不可重复度：RC下，事务A前后两次读到了同一字段不同值（UPDATE操作，值改变）事务B修改了字段值。
幻读：RR下，事务A读到前后两次读到了不同数量的同一字段（INSERT操作，数量改变）事务B插入了数据

脏读：指一个事务读取了另外一个事务未提交的数据

不可重复读：在一个事务内读取表中的某一行数据，多次读取结果不同（这个不一定是错误，只是某些场合不对）

虚读（幻读）是指在一个事务内读取到了别的事务插入的数据，导致前后读取数量总量不一致。

问题3 ： MVCC实现原理

事务1在修改数据前：

• 排它锁锁定事务1、记录操作到redo log

• 将原修改行复制到 undo log 中 ， 记录数据

• 增加事务号、讲回滚指针连接

• purge 线程用来扫描这次事务最早的操作，将之前的日志进行删除以保证redo log 不会无限写入

MVCC优点：读不加锁、读写分离

问题4 ： 事务的开启方式：

第一种：直接开启事务

START TRANSACTION;
		事务代码
		commit;

第二种：关闭自动提交

set autocommit=0
		事务代码
		commit

三、索引及优化：

问题1 ： mysql有什么索引：

以内部结构来分类

• 哈希索引：通过哈希函数计算哈希值，对应某个地址，查询速度快。但无法范围查询，且会出现哈希碰撞（解决方式为碰撞位置组成单链表）

• B+树索引：mysql的主流索引。

以索引类型来划分

• 聚集索引： innodb的索引类型，B+树的叶子节点里存的是索引和数据。对应着Innodb的表，只有表文件和索引数据文件两个。

• 非聚集索引：myisam的索引类型，B+树的叶子节点里存的是数据文件所在的地址。对应着myisam的表，存在表文件、索引文件、数据文件三个文件。

以功能类型来划分
主键索引、单值索引、唯一索引、联合索引、覆盖索引

问题2 ：为什么选用B+树作为索引：

二叉搜索树:

• 左子树key<根节点key<右子树的key

• 所有树都是二叉树

• 该类型极端的时候，会变成链表、导致效率降低。

AVL完全平衡二叉树:

• 左右子树的高度差不大于1

• 插入节点改变了高度后通过自旋（左旋、右旋、左右旋、右左旋）操作实现高度特性

• 插入操作过多会导致性能下降

• 适用于查找较多的场景 如windows底层

红黑树:

• 根结点为黑

• 每个红色节点有两个黑色节点

• 叶子结点是黑色节点

• 任一结点到每一个叶子结点的所有路径都有相同个数的黑色结点

• 从根结点到叶子结点的最长路径 <= 两倍的最短路径

• 解决了AVL的问题，插入操作在最坏情况下也是高效的

• 可以被使用到操作插入、删除较多的场景（linux 进度调动、java和哈希map）

到这里已经是mysql索引底层的基本结构了，但是由于mysql的工作性质需要进行大量的I/O磁盘读写操作，为了降低刷盘的次数、我们将红黑树进行放矮、放宽、并将每个节点存储多个值、就出现了B+树:

B+树:将整个树进行放矮、放宽后，对于刷盘的次数就降低到了个位数。B+树被广泛用于mysql的索引。

在线数据结构模拟网站

https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

问题3 ：如何使用索引：

# 创建索引

Create Index index_name on Table(name, age)

# 更改索引

Alter Table ADD index index_name on Table(name, age)

# 删除索引

Drop index index_name on Table

# 查看索引

Show index From table_name

问题4 ：索引的使用场景：
适合创建索引条件

• 主键自动建立唯一索引
• 频繁作为查询条件的字段应该建立索引
• 查询中与其他表关联的字段，外键关系建立索引
• 单键/组合索引的选择问题，组合索引性价比更高
• 查询中排序的字段，排序字段若通过索引去访问将大大提高排序效率（order by 要注意覆盖索引顺序和使用顺序相同）
• 查询中统计或者分组字段(group by 实质是先排序再分组，也需要保持索引字段使用和覆盖索引顺序的一致性)

不适合创建索引条件

• 表记录少的
• 经常增删改的表或者字段
• where条件里用不到的字段不创建索引
• 过滤性不好的不适合建索引（查询结果范围太大）

问题5 ：7种join连接

# 由于mysql没有外连接，因此使用union进行相加得到外连接

# 此处为全部A+B

select * from A left join B on A.id = B.id where B.id = NULL 
union 
select * from a left join B on A.id = B.id where A.id = NULL

# A+B 减去公共部分

select * from A left join B on A.id = B.id where B.id = NULL 
union 
select * from a left join B on A.id = B.id where A.id = NULL

问题6 ：如何分析sql的性能（执行顺序、索引使用性能）

explain select * from A

id:执行顺序

• id相同时，执行顺序由上至下

• id不同时，执行顺序由大到小

• id又相同又不同，先大小再上下

type:访问类型
性能排行：system>const>eq_ref>ref>range>index>all

• system:系统表
• const：常量
• eq_ref: 唯一索引或主键索引，返回为一行数据
• ref: 非唯一索引，返回为多行数据
• range: 给定范围内检索，使用一个索引来选择行数据
• index: 全索引检索
• all: 全表检索

正常情况，优化到ref/eq_ref

possible_keys

• 推测可能使用的索引字段
  keys

• 实际使用的索引字段
  key_len

• 使用索引检索用到了多少行数据，同结果下越少越好
  extra

• using filesort: 见于order by的索引失效，需要优化

• using temporary：见于 group by的索引失效，需要优化

• using index ：使用索引，不需要优化

四、查询优化：

问题1 ：数据库性能下降的原因由哪些？

• select 语句写的烂

• 索引失效

• 关联查询太多（设计缺陷）

• 服务器调优以及各个参数设置问题（缓冲、线程数等）

• 未使用读写分离（主从架构模式）

  问题2 ：如何避免索引失效：

  全值匹配我最爱，最左前缀要遵循
  带头大哥不能死，中间兄弟不能断
  索引列上少计算，范围之后全失效
  like百分写最右，覆盖索引不写星
  不等控制还有or，用了索引就失效

• 最左前缀原则的特殊情况包含全部正确的 反序列（如原ABC 使用为CBA）

• like 的百分号放到左侧，相当于可以排序出前面开头的部分，这种情况并不失效

• group by 和 order by 也遵守上述原则

**问题3 ：查询优化思路：

** 永远用小表驱动大表****

# 当表A的数据量   >    表B       使用in

select * from A in (select id from B )

# 当表A的数据量   <    表B       使用exist

select * from A exist (select id/'a'/1 from B where B.id = A.id )

# exist 的原理是,拿到某一行数据，去A表查看是否存在

# 后面的select 其实查的是一条记录，因此 id/'A'/1 相同

**group by 和 sort by尽量使用索引进行排序 **

• mysql的排序方式分为：indexsort 和 filesort

• filesort分为单路查询和双路查询

• 单路查询：在buffer中处理数据，只访问一次I/O磁盘（当buffer中数据过多时，会分多次处理数量，导致多次访问磁盘）

• 双路查询：访问两个I/O磁盘

当group by 或 sort by 没有遵循最左原则时，会导致文件内排序中的多路查询（双路或单路失效变成多路）

解决方案：

• 使用索引方式（indexsort）进行排序，不让索引失效
• select * 语句用select id, age 的形式，减少进入buffer pool 的字段数量
• 提高 sort_buffer_size
• 提高 max_length_for_sort_data

问题4 ：如何分析慢sql的具体原因（底层各部分耗时原理）：

• 开启慢sql日志，设置慢sql阈值（如5s以上为慢sql）
• 抓取所有慢sql进行分析
• 使用explain + 慢 sql 分析（一般到这里已经解决了）
• 使用show profile 关键字进行分析（少部分进行底层分析）

五、锁机制：

问题1 ：mysql锁机制基础

问题2 ：锁分类

以锁的作用分类：

• 共享锁 （读锁）

• 排它锁 （写锁）

以使用方式分类：

• 乐观锁： 人为实现， 首先增加版本号version = 1 ，当更新数据时对比版本号，相等时更改，不等时返回
• 悲观锁：现有的共享锁、排他锁都是悲观锁
• 区别： 乐观锁处理的是程序操作，不影响数据库层面的数据操作，悲观锁影响的是数据库数据的操作。

问题3 ：MYISAM表锁实现

# 给 t1 表上写锁

lock table T1 write

# 给 t1 表上读锁

lock table T1 read

# 解锁

unlock table 

• 读锁会阻塞写，但不会阻塞读
• 写锁会直接阻塞读写

问题4 ：INNDB行锁实现

# 给 T1表 一行上读锁

select * from T1 where id = 1 lock in share mode

# 提交就完成了解锁

commit

# 给 T1表 一行上写锁

select * from T1 where id = 1 for update 

# 解锁

commit 

• 共享锁会阻塞写操作，不会阻碍读操作，加了共享锁后只能再加共享锁

• 排它锁会阻塞读写操作，加了排它锁后不能再加锁

问题5 ：行锁的缺陷
当无索引进行查询时，行锁会升级为表锁

update table set b = '9002' and a = 1111 for update# (注意这里a字段是字符型，不加引号使得索引失效，行锁升级为表锁)

间隙锁使用范围条件查询会锁住无数据的行

update table set b = '9002' and a >'0' and a<'100' for update# 这里的a 会锁住 (0,100)区间内的所有值，即便不存在的值也会被锁住

问题6 ：锁的优化建议

• 让数据通过索引来完成，避免行锁升级为表锁
• 合理设计索引，减少锁的使用
• 减少检索条件，避免间隙锁（锁住不存在的行数据）
• 控制事务大小，减少资源锁定时间和范围
• 尽可能的降低隔离级别

六、读写分离：

• Master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；

• Slave将Master的二进制日志事件(binary log events)拷贝到它的中继日志(relay log)；

• I/O thread 和 sql thread 负责slave数据库的I/O读写和sql解析

主从架构具有多种形式：一般使用一主多从（一主四从）
还有双主、环形多主、一主一从（备用主服务器）多从
等多种架构方式，根据具体场景进行得失的考量

深入理解 JVM 垃圾回收机制及其实现原理

前言

对于 JVM 来说，我们都不陌生，其是 Java Virtual Machine（Java 虚拟机）的缩写，它也是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM 有自己完善的硬件架构，如处理器、堆栈等，还具有相应的指令系统，其本质上就是一个程序，当它在命令行上启动的时候，就开始执行保存在某字节码文件中的指令。

Java 语言的可移植性就是建立在 JVM 的基础之上的，任何平台只要装有针对于该平台的 Java 虚拟机，字节码文件（.class）就可以在该平台上运行，这就是“一次编译，多次运行”。除此之外，作为 Java 语言最重要的特性之一的自动垃圾回收机制，也是基于 JVM 实现的。那么，自动垃圾回收机制到底是如何实现的呢？在本文中，就让我们一探究竟。

垃圾

什么是垃圾？
在 JVM 进行垃圾回收之前，首先就是判断哪些对象是垃圾，也就是说，要判断哪些对象是可以被销毁的，其占有的空间是可以被回收的。根据 JVM 的架构划分，我们知道， 在 Java 世界中，几乎所有的对象实例都在堆中存放，所以垃圾回收也主要是针对堆来进行的。

在 JVM 的眼中，垃圾就是指那些在堆中存在的，已经“死亡”的对象。而对于“死亡”的定义，我们可以简单的将其理解为“不可能再被任何途径使用的对象”。那怎样才能确定一个对象是存活还是死亡呢？这就涉及到了垃圾判断算法，其主要包括引用计数法和可达性分析法:

引用计数法
在这种算法中，假设堆中每个对象（不是引用）都有一个引用计数器。当一个对象被创建并且初始化赋值后，该对象的计数器的值就设置为 1，每当有一个地方引用它时，计数器的值就加 1，例如将对象 b 赋值给对象 a，那么 b 被引用，则将 b 引用对象的计数器累加 1。

反之，当引用失效时，例如一个对象的某个引用超过了生命周期（出作用域后）或者被设置为一个新值时，则之前被引用的对象的计数器的值就减 1。而那些引用计数为 0 的对象，就可以称之为垃圾，可以被收集。

特别地，当一个对象被当做垃圾收集时，它引用的任何对象的计数器的值都减 1。

• 优点：引用计数法实现起来比较简单，对程序不被长时间打断的实时环境比较有利。

• 缺点：需要额外的空间来存储计数器，难以检测出对象之间的循环引用。

可达性分析法
可达性分析法也被称之为根搜索法，可达性是指，如果一个对象会被至少一个在程序中的变量通过直接或间接的方式被其他可达的对象引用，则称该对象就是可达的。更准确的说，一个对象只有满足下述两个条件之一，就会被判断为可达的：

• 对象是属于根集中的对象

• 对象被一个可达的对象引用

在这里，我们引出了一个专有名词，即根集，其是指正在执行的 Java 程序可以访问的引用变量（注意，不是对象）的集合，程序可以使用引用变量访问对象的属性和调用对象的方法。在 JVM 中，会将以下对象标记为根集中的对象，具体包括：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象

• 方法区中的常量引用的对象

• 方法区中的类静态属性引用的对象

• 本地方法栈中 JNI（Native 方法）的引用对象

• 活跃线程（已启动且未停止的 Java 线程）

根集中的对象称之为GC Roots，也就是根对象。可达性分析法的基本思路是：将一系列的根对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，如果一个对象到根对象没有任何引用链相连，那么这个对象就不是可达的，也称之为不可达对象。

如上图所示，形象的展示了可达对象与不可达对象的示例，其中灰色的对象都是不可达对象，表示可以被垃圾收集的对象。在可达性分析法中，对象有两种状态，那么是可达的、要么是不可达的，在判断一个对象的可达性的时候，就需要对对象进行标记。关于标记阶段，有几个关键点是值得我们注意的，分别是：

• 开始进行标记前，需要先暂停应用线程，否则如果对象图一直在变化的话是无法真正去遍历它的。暂停应用线程以便 JVM 可以尽情地收拾家务的这种情况又被称之为安全点（Safe Point），这会触发一次 Stop The World（STW）暂停。触发安全点的原因有许多，但最常见的应该就是垃圾回收了。

• 安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的。“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生安全点。对于安全点，另一个需要考虑的问题就是如何在 GC 发生时让所有线程（这里不包括执行 JNI 调用的线程）都“跑”到最近的安全点上再停顿下来。两种解决方案：

• 抢先式中断（Preemptive Suspension）：抢先式中断不需要线程的执行代码主动去配合，在 GC 发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机采用这种方式来暂停线程从而响应 GC 事件。

• 主动式中断（Voluntary Suspension）：主动式中断的思想是当 GC 需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志地地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

• 暂停时间的长短并不取决于堆内对象的多少也不是堆的大小，而是存活对象的多少。因此，调高堆的大小并不会影响到标记阶段的时间长短。

• 在根搜索算法中，要真正宣告一个对象死亡，至少要经历两次标记过程：

• 如果对象在进行根搜索后发现没有与根对象相连接的引用链，那它会被第一次标记并且进行一次筛选。筛选的条件是此对象是否有必要执行 finalize()方法（可看作析构函数，类似于 OC 中的dealloc，Swift 中的deinit）。当对象没有覆盖finalize()方法，或finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为没有必要执行。

• 如果该对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行finalize()方法。finalize()方法是对象逃脱死亡命运的最后一次机会（因为一个对象的finalize()方法最多只会被系统自动调用一次），稍后 GC 将对F-Queue中的对象进行第二次小规模的标记，如果要在finalize()方法中成功拯救自己，只要在finalize()方法中让该对象重新引用链上的任何一个对象建立关联即可。而如果对象这时还没有关联到任何链上的引用，那它就会被回收掉。

• GC 判断对象是否可达看的是强引用。

当标记阶段完成后，GC 开始进入下一阶段，删除不可达对象。当然，可达性分析法有优点也有缺点，

• 优点：可以解决循环引用的问题，不需要占用额外的空间

• 缺点：多线程场景下，其他线程可能会更新已经访问过的对象的引用

在上面的介绍中，我们多次提到了“引用”这个概念，在此我们不妨多了解一些引用的知识，在 Java 中有四种引用类型，分别为：

• 强引用（Strong Reference）：如Object obj = new Object()，这类引用是 Java 程序中最普遍的。只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象。

• 软引用（Soft Reference）：它用来描述一些可能还有用，但并非必须的对象。在系统内存不够用时，这类引用关联的对象将被垃圾收集器回收。JDK1.2 之后提供了SoftReference类来实现软引用。

• 弱引用（Weak Reference）：它也是用来描述非必须对象的，但它的强度比软引用更弱些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在 JDK1.2 之后，提供了WeakReference类来实现弱引用。

• 虚引用（Phantom Reference）：也称为幻引用，最弱的一种引用关系，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的是希望能在这个对象被收集器回收时收到一个系统通知。JDK1.2 之后提供了PhantomReference类来实现虚引用。

垃圾回收

通过上面的介绍，我们已经知道了什么是垃圾以及如何判断一个对象是否是垃圾。那么接下来，我们就来了解如何回收垃圾，这就是垃圾回收算法和垃圾回收器需要做的事情了。

垃圾回收算法

标记-清除算法
标记-清除（Tracing Collector）算法是最基础的收集算法，为了解决引用计数法的问题而提出。它使用了根集的概念，它分为“标记”和“清除”两个阶段：首先标记出所需回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程其实就是前面的可达性分析法中判定垃圾对象的标记过程。

• 优点：不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效。
• 缺点：标记和清除过程的效率都不高，这种方法需要使用一个空闲列表来记录所有的空闲区域以及大小，对空闲列表的管理会增加分配对象时的工作量；标记清除后会产生大量不连续的内存碎片，虽然空闲区域的大小是足够的，但却可能没有一个单一区域能够满足这次分配所需的大小，因此本次分配还是会失败，不得不触发另一次垃圾收集动作。

下图为“标记-清除”算法的示意图：

下图为使用“标记-清除”算法回收前后的状态：

标记-整理算法
标记-整理（Compacting Collector）算法标记的过程与“标记-清除”算法中的标记过程一样，但对标记后出的垃圾对象的处理情况有所不同，它不是直接对可回收对象进行清理，而是让所有的对象都向一端移动，然后直接清理掉端边界以外的内存。在基于“标记-整理”算法的收集器的实现中，一般增加句柄和句柄表。

• 优点：经过整理之后，新对象的分配只需要通过指针碰撞便能完成，比较简单；使用这种方法，空闲区域的位置是始终可知的，也不会再有碎片的问题了。
• 缺点：GC 暂停的时间会增长，因为你需要将所有的对象都拷贝到一个新的地方，还得更新它们的引用地址。
  下图为“标记-整理”算法的示意图：

下图为使用“标记-整理”算法回收前后的状态：

复制算法
复制（Copying Collector）算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它将内存按容量分为大小相等的两块，每次只使用其中的一块（对象面），当这一块的内存用完了，就将还存活着的对象复制到另外一块内存上面（空闲面），然后再把已使用过的内存空间一次清理掉。

复制算法比较适合于新生代（短生存期的对象），在老年代（长生存期的对象）中，对象存活率比较高，如果执行较多的复制操作，效率将会变低，所以老年代一般会选用其他算法，如“标记-整理”算法。一种典型的基于复制算法的垃圾回收是stop-and-copy算法，它将堆分成对象区和空闲区，在对象区与空闲区的切换过程中，程序暂停执行。

• 优点：标记阶段和复制阶段可以同时进行；每次只对一块内存进行回收，运行高效；只需移动栈顶指针，按顺序分配内存即可，实现简单；内存回收时不用考虑内存碎片的出现。
• 缺点：需要一块能容纳下所有存活对象的额外的内存空间。因此，可一次性分配的最大内存缩小了一半。
  下图为复制算法的示意图：

下图为使用复制算法回收前后的状态：

分代收集算法
分代收集（Generational Collector）算法的将堆内存划分为新生代、老年代和永久代。新生代又被进一步划分为 Eden 和 Survivor 区，其中 Survivor 由 FromSpace（Survivor0）和 ToSpace（Survivor1）组成。所有通过new创建的对象的内存都在堆中分配，其大小可以通过-Xmx和-Xms来控制。分代收集，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，可以将不同生命周期的对象分代，不同的代采取不同的回收算法进行垃圾回收，以便提高回收效率。

• 新生代（Young Generation）：几乎所有新生成的对象首先都是放在年轻代的。新生代内存按照 8:1:1 的比例分为一个 Eden 区和两个 Survivor（Survivor0，Survivor1）区。大部分对象在 Eden 区中生成。当新对象生成，Eden 空间申请失败（因为空间不足等），则会发起一次 GC（Scavenge GC）。回收时先将 Eden 区存活对象复制到一个 Survivor0 区，然后清空 Eden 区，当这个 Survivor0 区也存放满了时，则将 Eden 区和 Survivor0 区存活对象复制到另一个 Survivor1 区，然后清空 Eden 和这个 Survivor0 区，此时 Survivor0 区是空的，然后将 Survivor0 区和 Survivor1 区交换，即保持 Survivor1 区为空， 如此往复。当 Survivor1 区不足以存放 Eden 和 Survivor0 的存活对象时，就将存活对象直接存放到老年代。当对象在 Survivor 区躲过一次 GC 的话，其对象年龄便会加 1，默认情况下，如果对象年龄达到 15 岁，就会移动到老年代中。若是老年代也满了就会触发一次 Full GC，也就是新生代、老年代都进行回收。新生代大小可以由-Xmn来控制，也可以用-XX:SurvivorRatio来控制 Eden 和 Survivor 的比例。

• 老年代（Old Generation）：在新生代中经历了 N 次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。内存比新生代也大很多（大概比例是 1:2），当老年代内存满时触发 Major GC 即 Full GC，Full GC 发生频率比较低，老年代对象存活时间比较长，存活率高。一般来说，大对象会被直接分配到老年代。所谓的大对象是指需要大量连续存储空间的对象，最常见的一种大对象就是大数组。当然分配的规则并不是百分之百固定的，这要取决于当前使用的是哪种垃圾收集器组合和 JVM 的相关参数。

• 永久代（Permanent Generation）：用于存放静态文件（class类、方法）和常量等。永久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如 Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。对永久代的回收主要回收两部分内容：废弃常量和无用的类。永久代在 Java SE8 特性中已经被移除了，取而代之的是元空间（MetaSpace），因此也不会再出现java.lang.OutOfMemoryError: PermGen error的错误了。

特别地，在分代收集算法中，对象的存储具有以下特点：

1.对象优先在 Eden 区分配。
2.大对象直接进入老年代。
3.长期存活的对象将进入老年代，默认为 15 岁。

对于晋升老年代的分代年龄阈值，我们可以通过-XX：MaxTenuringThreshold参数进行控制。在这里，不知道大家有没有对这个默认的 15 岁分代年龄产生过疑惑，为什么不是 16 或者 17 呢？实际上，HotSpot 虚拟机的对象头其中一部分用于存储对象自身的运行时数据，如哈希码、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，这部分数据的长度在 32 位和 64 位的虚拟机（未开启压缩指针）中分别为 32bit 和 64bit，官方称它为Mark word。

例如，在 32 位的 HotSpot 虚拟机中，如果对象处于未被锁定的状态下，那么Mark Word的 32bit 空间中 25bit 用于存储对象哈希码，4bit 用于存储对象分代年龄，2bit 用于存储锁标志位，1bit 固定为 0，其中对象的分代年龄占 4 位，也就是从0000到1111，而其值最大为 15，所以分代年龄也就不可能超过 15 这个数值了。

除此之外，我们再来简单了解一下 GC 的分类：

• 新生代 GC（Minor GC / Scavenge GC）：发生在新生代的垃圾收集动作。因为 Java 对象大多都具有朝生夕灭的特性，因此 Minor GC 非常频繁（不一定等 Eden 区满了才触发），一般回收速度也比较快。在新生代中，每次垃圾收集时都会发现有大量对象死去，只有少量存活，因此可选用复制算法来完成收集。

• 老年代 GC（Major GC / Full GC）：发生在老年代的垃圾回收动作。Major GC 经常会伴随至少一次 Minor GC。由于老年代中的对象生命周期比较长，因此 Major GC 并不频繁，一般都是等待老年代满了后才进行 Full GC，而且其速度一般会比 Minor GC 慢10倍以上。另外，如果分配了 Direct Memory，在老年代中进行 Full GC 时，会顺便清理掉 Direct Memory 中的废弃对象。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清除”算法或“标记-整理”算法来进行回收。

新生代采用空闲指针的方式来控制 GC 触发，指针保持最后一个分配的对象在新生代区间的位置，当有新的对象要分配内存时，用于检查空间是否足够，不够就触发 GC。当连续分配对象时，对象会逐渐从 Eden 到 Survivor，最后到老年代。

再多说一句，在某些场景下，老年代的对象可能引用新生代的对象，那标记存活对象的时候，需要扫描老年代中的所有对象。因为该对象拥有对新生代对象的引用，那么这个引用也会被称为GC Roots。那是不是要做全堆扫描呢？成本也太高了吧?

HotSpot 给出的解决方案是一项叫做卡表（Card Table）的技术，该技术将整个堆划分为一个个大小为 512 字节的卡，并且维护一个卡表，用来存储每张卡的一个标识位。这个标识位代表对应的卡是否可能存有指向新生代对象的引用。如果可能存在，那么我们就认为这张卡是脏的。

在进行 Minor GC 的时候，我们便可以不用扫描整个老年代，而是在卡表中寻找脏卡，并将脏卡中的对象加入到 Minor GC 的GC Roots里。当完成所有脏卡的扫描之后，Java 虚拟机便会将所有脏卡的标识位清零。

想要保证每个可能有指向新生代对象引用的卡都被标记为脏卡，那么 Java 虚拟机需要截获每个引用型实例变量的写操作，并作出对应的写标识位操作。

卡表能用于减少老年代的全堆空间扫描，这能很大的提升 GC 效率。

垃圾回收器

垃圾回收（GC）线程与应用线程保持相对独立，当系统需要执行垃圾回收任务时，先停止工作线程，然后命令 GC 线程工作。以串行模式工作的收集器，称为Serial Collector，即串行收集器；与之相对的是以并行模式工作的收集器，称为Paraller Collector，即并行收集器。

Serial 收集器

串行收集器采用单线程方式进行收集，且在 GC 线程工作时，系统不允许应用线程打扰。此时，应用程序进入暂停状态，即 Stop-the-world。Stop-the-world 暂停时间的长短，是衡量一款收集器性能高低的重要指标。Serial 是针对新生代的垃圾回收器，采用“复制”算法。

ParNew 收集器

并行收集器充分利用了多处理器的优势，采用多个 GC 线程并行收集。可想而知，多条 GC 线程执行显然比只使用一条 GC 线程执行的效率更高。一般来说，与串行收集器相比，在多处理器环境下工作的并行收集器能够极大地缩短 Stop-the-world 时间。ParNew 是针对新生代的垃圾回收器，采用“复制”算法，可以看成是 Serial 的多线程版本

Parallel Scavenge 收集器

Parallel Scavenge 是针对新生代的垃圾回收器，采用“复制”算法，和 ParNew 类似，但更注重吞吐率。在 ParNew 的基础上演化而来的 Parallel Scanvenge 收集器被誉为“吞吐量优先”收集器。吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。如虚拟机总运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是99%。

Parallel Scanvenge 收集器在 ParNew 的基础上提供了一组参数，用于配置期望的收集时间或吞吐量，然后以此为目标进行收集。通过 VM 选项可以控制吞吐量的大致范围：

• -XX：MaxGCPauseMills：期望收集时间上限，用来控制收集对应用程序停顿的影响。

• -XX：GCTimeRatio：期望的 GC 时间占总时间的比例，用来控制吞吐量。

• -XX：UseAdaptiveSizePolicy：自动分代大小调节策略。

但要注意停顿时间与吞吐量这两个目标是相悖的，降低停顿时间的同时也会引起吞吐的降低。因此需要将目标控制在一个合理的范围中

Serial Old 收集器

Serial Old 是 Serial 收集器的老年代版本，单线程收集器，采用“标记-整理”算法。这个收集器的主要意义也是在于给 Client 模式下的虚拟机使用。

Parallel Old 收集器

Parallel Old 是 Parallel Scanvenge 收集器的老年代版本，多线程收集器，采用“标记-整理”算法。

CMS收集器

CMS（Concurrent Mark Swee）收集器是一种以获取最短回收停顿时间为目标的收集器。CMS 收集器仅作用于老年代的收集，采用“标记-清除”算法，它的运作过程分为 4 个步骤：

• 初始标记（CMS initial mark）

• 并发标记（CMS concurrent mark）

• 重新标记（CMS remark）

• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要 Stop-the-world。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始阶段稍长一些，但远比并发标记的时间短。

CMS 以流水线方式拆分了收集周期，将耗时长的操作单元保持与应用线程并发执行。只将那些必需 STW 才能执行的操作单元单独拎出来，控制这些单元在恰当的时机运行，并能保证仅需短暂的时间就可以完成。这样，在整个收集周期内，只有两次短暂的暂停（初始标记和重新标记），达到了近似并发的目的。

• CMS 收集器优点：并发收集，低停顿。

• CMS 收集器缺点：

• CMS 收集器对 CPU 资源非常敏感；

• CMS 收集器无法处理浮动垃圾；

• CMS 收集器是基于“标记-清除”算法，该算法的缺点都有。

CMS 收集器之所以能够做到并发，根本原因在于采用基于“标记-清除”的算法并对算法过程进行了细粒度的分解。前面已经介绍过“标记-清除”算法将产生大量的内存碎片这对新生代来说是难以接受的，因此新生代的收集器并未提供 CMS 版本。

G1 收集器

G1（Garbage First）重新定义了堆空间，打破了原有的分代模型，将堆划分为一个个区域。这么做的目的是在进行收集时不必在全堆范围内进行，这是它最显著的特点。区域划分的好处就是带来了停顿时间可预测的收集模型：用户可以指定收集操作在多长时间内完成，即 G1 提供了接近实时的收集特性。G1 与 CMS 的特征对比如下：

?
?
?
?

G1 具备如下特点：

• 并行与并发：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU 来缩短 Stop-the-world 停顿的时间，部分其他收集器原来需要停顿 Java 线程执行的 GC 操作，G1 收集器仍然可以通过并发的方式让 Java 程序继续运行。

• 分代收集：打破了原有的分代模型，将堆划分为一个个区域。

• 空间整合：与 CMS 的“标记-清除”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的。但无论如何，这两种算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。

• 可预测的停顿：这是 G1 相对于 CMS 的一个优势，降低停顿时间是 G1 和 CMS 共同的关注点。

在 G1 之前的其他收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。在堆的结构设计时，G1 打破了以往将收集范围固定在新生代或老年代的模式，G1 将堆分成许多相同大小的区域单元，每个单元称为 Region，Region 是一块地址连续的内存空间，G1 模块的组成如下图所示：

堆内存会被切分成为很多个固定大小的 Region，每个是连续范围的虚拟内存。堆内存中一个 Region 的大小可以通过-XX:G1HeapRegionSize参数指定，其区间最小为 1M、最大为 32M，默认把堆内存按照 2048 份均分。

每个 Region 被标记了 E、S、O 和 H，这些区域在逻辑上被映射为 Eden，Survivor 和老年代。存活的对象从一个区域转移（即复制或移动）到另一个区域，区域被设计为并行收集垃圾，可能会暂停所有应用线程。

如上图所示，区域可以分配到 Eden，Survivor 和老年代。此外，还有第四种类型，被称为巨型区域（Humongous Region）。Humongous 区域是为了那些存储超过 50% 标准 Region 大小的对象而设计的，它用来专门存放巨型对象。如果一个 H 区装不下一个巨型对象，那么 G1 会寻找连续的 H 分区来存储。为了能找到连续的 H 区，有时候不得不启动 Full GC。

G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 会通过一个合理的计算模型，计算出每个 Region 的收集成本并量化，这样一来，收集器在给定了“停顿”时间限制的情况下，总是能选择一组恰当的 Region 作为收集目标，让其收集开销满足这个限制条件，以此达到实时收集的目的。

对于打算从 CMS 或者 ParallelOld 收集器迁移过来的应用，按照官方的建议，如果发现符合如下特征，可以考虑更换成 G1 收集器以追求更佳性能：

实时数据占用了超过半数的堆空间；
对象分配率或“晋升”的速度变化明显；
期望消除耗时较长的GC或停顿（超过 0.5 ~ 1 秒）。
G1 收集的运作过程大致如下：

• 初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改 TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的 Region 中创建新对象，这阶段需要停顿线程，但耗时很短。

• 并发标记（Concurrent Marking）：是从GC Roots开始堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。

• 最终标记（Final Marking）：是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中，这阶段需要停顿线程，但是可并行执行。

• 筛选回收（Live Data Counting and Evacuation）：首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。这个阶段也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

G1 的 GC 模式可以分为两种，分别为：

• Young GC：在分配一般对象（非巨型对象）时，当所有 Eden 区域使用达到最大阀值并且无法申请足够内存时，会触发一次 YoungGC。每次 Young GC 会回收所有 Eden 以及 Survivor 区，并且将存活对象复制到 Old 区以及另一部分的 Survivor 区。

• Mixed GC：当越来越多的对象晋升到老年代时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即 Mixed GC，该算法并不是一个 Old GC，除了回收整个新生代，还会回收一部分的老年代，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些 Old 区域进行收集，从而可以对垃圾回收的耗时时间进行控制。G1 没有 Full GC概念，需要 Full GC 时，调用 Serial Old GC 进行全堆扫描。

  ：

查看 JVM 使用的默认垃圾收集器
在 Mac 终端或者 Windows 的 CMD 执行如下命令

java -XX:+PrintCommandLineFlags -version

以我的电脑为例，执行结果为：

在此，给出垃圾收集相关的常用参数及其含义：

由此可知，JDK 8 默认打开了UseParallelGC参数，因此使用了Parallel Scavenge + Serial Old的收集器组合进行内存回收。

TCP/IP协议、UDP、HTTP协议、SOCKET通讯

UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。

1、TCP连接

TCP(Transmission Control Protocol) 传输控制协议。TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接。位码即tcp标志位，有6种 标示:SYN(synchronous建立连接) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)(seq)Sequence number(顺序号码)(ack) Acknowledge number(确认号码)。

手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。建立起一个TCP连接需要经过“三次握手”：

第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手完成后，两台主机开始传输数据了。

为什么要三次握手？

• 如果只有一次握手，Client不能确定与Server的单向连接，更加不能确定Server与Client的单向连接；
• 如果只有两次握手，Client确定与Server的单向连接，但是Server不能确定与Client的单向连接；
• 只有三次握手，Client与Server才能相互确认双向连接，实现双工数据传输。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次挥手”。

实例一:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。

实例二:
TCP的作用是流量控制，主要是控制数据流的传输。下面以浏览网页为例，根据自身理解来解释一下这个过程。（注：第二个ack属于代码段ack位）
pc浏览服务器网页此过程不包括域名查询，只描述TCP与http数据流的变化。
pc与http服务器进行三次握手来建立连接。
1.pc：seq=0 ack=0 syn=1 ack=0 发送给服务器建立同步请求。
2.server： seq=0 ack=1 syn=1 ack=1 发送给客户端建立同步响应.
3.pc:seq=1 ack=1 syn=0 ack=1 发送给服务器,三次握手完成建立同步信息成功.
4.pc产生http数据消息,向服务器发送get请求.
5.服务器收到请求并发送TCP确认,然后发送http数据信息给客户端的浏览器.
6.客户端收到服务器的http信息,然后发送TCP确认信息给服务器.
7.客户端发送FIN+ACK给服务器,要求结束数据传输.
8.服务器发送TCP确认消息用于确认pc的TCP的FIN消息
9.服务器向客户端发送FIN+ACK消息用于结束TCP会话.
10.客户端发送确认信息给服务器,整个会话结束.

四次挥手:

• 第一次挥手：
  Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
• 第二次挥手：
  Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
• 第三次挥手：
  Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
• 第四次挥手：
  Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为什么要四次挥手？

“三次握手”的第二次握手发送SYN+ACK回应第一次握手的SYN，但是“四次挥手”的第二次挥手只能发送ACK回应第一次挥手的FIN，因为此时Server可能还有数据传输给Client，所以Server传输数据完成后才能发起第三次挥手发送FIN给Client，等待Client的第四次挥手ACK。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

2、HTTP连接
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。

2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道 客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

3、SOCKET原理

3.1 套接字（socket）概念

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议口。

应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

3.2 建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。

套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。

客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。

连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发 给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

4、SOCKET连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

5、Socket连接与HTTP连接

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端； 若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

6、IP协议

IP是英文Internet Protocol（网络之间互连的协议）的缩写，中文简称为“网协”，也就是为计算机网络相互连接进行通信而设计的协议。在因特网中，它是能使连接到网上的所有计算机网络实现相互通信的一套规则，规定了计算机在因特网上进行通信时应当遵守的规则。任何厂家生产的计算机系统，只要遵守 IP协议就可以与因特网互连互通。IP地址具有唯一性，根据用户性质的不同，可以分为5类。另外，IP还有进入防护，知识产权，指针寄存器等含义。

IP是怎样实现网络互连设备，如以太网、分组交换网等，它们相互之间不能互通，不能互通的主要原因是因为它们所传送数据的基本单元（技术上称之为“帧”）的格式不同。IP协议实际上是一套由软件、程序组成的协议软件，它把各种不同“帧”统一转换成“IP数据包”格式，这种转换是因特网的一个最重要的特点，使所有各种计算机都能在因特网上实现互通，即具有“开放性”的特点。

IP协议中还有一个非常重要的内容，那就是给因特网上的每台计算机和其它设备都规定了一个唯一的地址，叫做“IP 地址”。由于有这种唯一的地址，才保证了用户在连网的计算机上操作时，能够高效而且方便地从千千万万台计算机中选出自己所需的对象来。如今电信网正在与 IP网走向融合，以IP为基础的新技术是热门的技术，如用IP网络传送话音的技术（即VoIP）就很热门，其它如IP overATM、IPoverSDH、IP over WDM等等，都是IP技术的研究重点。

Linux常用命令

一、目录操作

pwd				查看当前工作目录
clear 			清除屏幕
cd ~			当前用户目录
cd /			根目录
cd -			上一次访问的目录
cd ..			上一级目录

查看目录内信息

ll				查看当前目录下内容（LL的小写）

创建目录

mkdir aaa		在当前目录下创建aaa目录，相对路径；
mkdir ./bbb		在当前目录下创建bbb目录，相对路径；
mkdir /ccc		在根目录下创建ccc目录，绝对路径；

递归创建目录（会创建里面没有的目录文件夹）

mkdir -p temp/nginx 

搜索命令

find / -name 'b'		查询根目录下（包括子目录），名以b的目录和文件；
find / -name 'b*'		查询根目录下（包括子目录），名以b开头的目录和文件； 

重命名

mv 原先目录 文件的名称   mv tomcat001 tomcat 

剪切命令(有目录剪切到制定目录下，没有的话剪切为指定目录）

mv	/aaa /bbb			将根目录下的aaa目录，移动到bbb目录下，在bbb，麚也叫aaa目录；
mv	bbb usr/bbb			将当前目录下的bbbb目录，移动到usr目录下，并且修改名称为bbb；

复制目录

cp -r /aaa /bbb			将/目录下的aaa目录复制到/bbb目录下，在/bbb目录下的名称为aaa
cp -r /aaa /bbb/aaa		将/目录下的aa目录复制到/bbb目录下，且修改名为aaa;

强制式删除指定目录

rm -rf /bbb			强制删除/目录下的bbb目录。如果bbb目录中还有子目录，也会被强制删除，不会提示；

删除目录

rm -r /bbb			普通删除。会询问你是否删除每一个文件

二、文件操作

删除

rm -r a.java		删除当前目录下的a.java文件（每次回询问是否删除y：同意）

强制删除

rm -rf a.java		强制删除当前目录下的a.java文件
rm -rf ./a*			强制删除当前目录下以a开头的所有文件；
rm -rf ./*			强制删除当前目录下所有文件（慎用）

创建文件

touch testFile

递归删除.pyc格式的文件

find . -name '*.pyc' -exec rm -rf {} \;

打印当前文件夹下指定大小的文件

find . -name "*" -size 145800c -print

递归删除指定大小的文件(145800)

find . -name "*" -size 145800c -exec rm -rf {} \;

递归删除指定大小的文件，并打印出来

find . -name "*" -size 145800c -print -exec rm -rf {} \;

• “.” 表示从当前目录开始递归查找
• “ -name ‘*.exe’ "根据名称来查找，要查找所有以.exe结尾的文件夹或者文件
• " -type f "查找的类型为文件
• “-print” 输出查找的文件目录名
• -size 145800c 指定文件的大小
• -exec rm -rf {} ; 递归删除（前面查询出来的结果）

三、文件内容操作（查看日志，更改配置文件）

修改文件内容

vim a.java   	进入一般模式
i(按键)   		进入插入模式(编辑模式)
ESC(按键)  		退出
:wq 			保存退出（shift+：调起输入框）
:q！			不保存退出（shift+：调起输入框）（内容更改）
:q				不保存退出（shift+：调起输入框）（没有内容更改）

文件内容的查看

cat a.java		查看a.java文件的最后一页内容；
more a.java		从第一页开始查看a.java文件内容，按回车键一行一行进行查看，
                    按空格键一页一页进行查看，q退出；
less a.java		从第一页开始查看a.java文件内容，按回车键一行一行的看，
                    按空格键一页一页的看，支持使用PageDown和PageUp翻页，q退出；

总结下more 和 less的区别:

1.less可以按键盘上下方向键显示上下内容,more不能通过上下方向键控制显示
2.less不必读整个文件，加载速度会比more更快
3.less退出后shell不会留下刚显示的内容,而more退出后会在shell上留下刚显示的内容.
4.由于more不能后退.

实时查看文件后几行(实时查看日志)

tail -f a.java			查看a.java文件的后10行内容；

前后几行查看

head a.java				查看a.java文件的前10行内容；
tail -f a.java			查看a.java文件的后10行内容；
head -n 7 a.java		查看a.java文件的前7行内容；
tail -n 7 a.java		查看a.java文件的后7行内容；

文件内部搜索指定的内容

grep under 123.txt			在123.txt文件中搜索under字符串，大小写敏感，显示行；
grep -n under 123.txt		在123.txt文件中搜索under字符串，大小写敏感，显示行及行号；
grep -v under 123.txt		在123.txt文件中搜索under字符串，大小写敏感，显示没搜索到的行；
grep -i under 123.txt		在123.txt文件中搜索under字符串，大小写敏感，显示行；
grep -ni under 123.txt		在123.txt文件中搜索under字符串，大小写敏感，显示行及行号；

终止当前操作

Ctrl+c和Ctrl+z都是中断命令，但是作用却不一样。

ctrl+z
ctrl+c

Ctrl+Z就扮演了类似的角色，将任务中断，但是任务并没有结束，在进程中只是维持挂起的状态，用户可以使用fg/bg操作前台或后台的任务，fg命令重新启动前台被中断的任务，bg命令把被中断的任务放在后台执行。
Ctrl+C也扮演类似的角色，强制中断程序的执行。

重定向功能
可以使用 > 或 < 将命令的输出的命令重定向到test.txt文件中（没有则创建一个）

echo 'Hello World' > /root/test.txt

四、系统日志位置

cat /etc/redhat-release		查看操作系统版本
/var/log/message			系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一
/var/log/message			系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一 
/var/log/secure				与安全相关的日志信息 
/var/log/maillog			与邮件相关的日志信息 
/var/log/cron				与定时任务相关的日志信息 
/var/log/spooler			与UUCP和news设备相关的日志信息 
/var/log/boot.log			守护进程启动和停止相关的日志消息 

查看某文件下的用户操作日志
到达操作的目录下，执行下面的程序：

cat .bash_history

五、创建与删除软连接

1、创建软连接

ln -s /usr/local/app /data

注意：创建软连接时，data目录后不加 / (加上后是查找其下一级目录)；

2、删除软连接

rm -rf /data

注意：取消软连接最后没有/，rm -rf 软连接。加上/是删除文件夹；

六、压缩和解压缩

tar

tar -zcvf start.tar.gz a.java b.java	将当前目录下a.java、b.java打包
tar -zcvf start.tar.gz ./*				将当前目录下的所欲文件打包压缩成haha.tar.gz文件

tar -xvf start.tar.gz				解压start.tar.gz压缩包，到当前文件夹下；
tar -xvf start.tar.gz -C usr/local（C为大写，中间无空格）
									解压start.tar.gz压缩包，到/usr/local目录下；

unzip

unzip file1.zip  				解压一个zip格式压缩包
zip lib.zip tomcat.jar			将单个文件压缩(lib.zip)
zip -r lib.zip lib/				将目录进行压缩(lib.zip)
zip -r lib.zip tomcat-embed.jar xml-aps.jar		将多个文件压缩为zip文件(lib.zip)	

将english.zip包，解压到指定目录下/usr/app/

unzip -d /usr/app/com.lydms.english.zip

七、Linux下文件的详细信息

 R:Read  w:write  x: execute执行
-rw-r--r-- 1 root root  34942 Jan 19  2018 bootstrap.jar
前三位代表当前用户对文件权限：可以读/可以写/不能执行
中间三位代表当前组的其他用户对当前文件的操作权限：可以读/不能写/不能执行
后三位其他用户对当前文件权限：可以读/不能写/不能执行

更改文件的权限

chmod u+x web.xml （---x------）		为文件拥有者（user）添加执行权限；
chmod g+x web.xml （------x---）		为文件拥有者所在组（group）添加执行权限；
chmod 111 web.xml  （---x--x--x）	为所有用户分类，添加可执行权限；
chmod 222 web.xml （--w--w--w-）		为所有用户分类，添加可写入权限；	
chmod 444 web.xml （-r--r--r--）		为所有用户分类，添加可读取权限；

八、常用的docker容器的命令：

1、下载镜像
Linux服务器下载安装包镜像命令

wget https://mirrors.huaweicloud.com/elasticsearch/7.8.0/elasticsearch-7.8.0-windows-x86_64.zip

华为开源镜像站

https://mirrors.huaweicloud.com/

2、常用命令

#1、查看docker中下载好的镜像：
docker images
 #2、查询需要的容器名称：
docker search mysql
#3、将需要的docker容器下载运行到本地(名称、端口号、msyql密码、ID)：
docker run -di --name=first -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root 26d26dsfsd31a
#4、查看运行的docker容器：
docker ps
#5、查看所有的docker容器（包括未运行的）：
docker ps -a
#6、停止当前运行的docker容器：
docker stop first
#7、启动docker容器：
docker start first
#8、重启docker容器：
docker restart first
#9、删除docker容器：
docker rm first

九、运维常用命令

1、查看服务器端口号是否可用
查看服务器是否可用

ping 49.32.587.164

查看服务器指定端口是否可用

telnet 49.32.587.164 8093

Telnet安装

这是我写过的一个Linux安装Telnet的文章。

https://blog.csdn.net/lydms/article/details/113698856

1、shutdown(关闭计算机)

shutdown是最常用也是最安全的关机和重启命令，它会在关机之前调用fsck检查磁盘，其中-h和-r是最常用的参数：

-h：停止系统服务并关机  
-r： 停止系统服务后重启  

案例：

shutdown -h now  --立即关机  
shutdown -h 10:53  --到10:53关机，如果该时间小于当前时间，则到隔天  
shutdown -h +10  --10分钟后自动关机  
shutdown -r now  --立即重启  
shutdown -r +30 'The System Will Reboot in 30 Mins'   --30分钟后重启并并发送通知给其它在线用户

2、查看处于各种连接状态数量(ESTABLISHED、CLOSE_WAIT、TIME_WAIT)

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

查看处于ESTABLISHED状态连接

netstat -nt | awk '{if($NF=="ESTABLISHED"){wait[$5]++}}END{for(i in wait) print i,wait[i]}'

查看处于CLOSE_WAIT状态连接

netstat -nt | awk '{if($NF=="CLOSE_WAIT"){wait[$5]++}}END{for(i in wait) print i,wait[i]}'

查看处于TIME_WAIT状态连接

netstat -nt | awk '{if($NF=="TIME_WAIT"){wait[$5]++}}END{for(i in wait) print i,wait[i]}'

3、ping命令
对 www.lydms.com 发送 4 个 ping 包, 检查与其是否联通

ping -c 4 www.lydms.com

4、netstat 命令
netstat 命令用于显示各种网络相关信息，如网络连接, 路由表, 接口状态等等;
列出所有处于监听状态的tcp端口:

netstat -lt

查看所有的端口信息, 包括 PID 和进程名称

netstat -tulpn

5、查看当前端口号占用情况
1.用于查看某一端口的占用情况

lsof -i:8080

2.显示tcp，udp的端口和进程等相关情况

netstat -tunlp

3.指定端口号的进程情况

netstat -tunlp|grep 8080

4.查看PID进程信息

ps -aux |grep 28990

根据PID，查看JVM中各线程信息('0x9eb’为nid值)

jstack 2246|grep '0x9eb' -A 50

6、ps 命令
过滤得到当前系统中的 ssh 进程信息

ps aux | grep 'ssh'

7、管道命令
简单来说, Linux 中管道的作用是将上一个命令的输出作为下一个命令的输入, 像 pipe 一样将各个命令串联起来执行, 管道的操作符是 |
管道命令查看当前运行的程序中，名称为java的程序

ps -ef|grep java

查看/etc/passwd文件中的root内容

cat /etc/passwd | grep 'root'

查看当前系统的ip连接（Windows和Linux通用）

netstat -an

将sh test.sh任务放到后台，并将打印的日志输出到nohup.out文件中，终端不再能够接收任何输入（标准输入）

nohup sh test.sh  &

将sh test.sh任务放到后台，并将打印的日志输出到nohup.out文件中，终端能够接收任何输入

nohup sh test.sh  &

8、添加Host地址
打开配置文件

vim /etc/hosts

在打开的文件中添加

49.235.32.164 www.lydms.com

保存文件后，重启网络

/etc/init.d/network restart

重新加载成功：

十、yum常用命令

yum install iptables-services		下载并安装iptables
yum list					列出当前系统中安装的所有包
yum search package_name		在rpm仓库中搜寻软件包
yum update package_name.rpm		更新当前系统中所有安装的rpm包
yum update package_name		更新一个rpm包
yum remove package_name		删除一个rpm包
yum clean all				删除所有缓存的包和头文件

十一、其他命令

查看占用资源

ps -au		占用的资源是从进程启动开始，计算的平均占用资源，比如cpu等
top			实时占用的资源；

查看当前目录所占存储

du -lh			查看当前文件下各文件夹占用存储空间
du -sh			查看当前文件夹所占存储空间
du --max-depth=<目录层数> 	超过指定层数的目录后，予以忽略。
du --max-depth=1 			只查看当前目录下文件占用的存储空间

管道命令：
根据项目查看进程，更加PID查看项目，以及项目路径

ps -ef 						查看所有的进程
ps -ef | grep mysql			查看mysql相关的进程

通过进程PID查看所占用的端口号

netstat -nap |grep 进程ID(PID)

查看Linux下系统存储使用率

df -h			查看系统硬盘使用情况

杀死进程(根据PID)

kill -9 2630		进程pid

关闭防火墙

service iptables stop      临时关闭防火墙
chkconfig iptables off     防火墙开启不启动
service iptables status    查看防火墙状态

开机启动选项

msconfig					查看开机启动选项
chkconfig					查看开机启动服务列表

查看MySQL服务的程序的状态

service mysql start        开启MySQL    
service mysql status       查看MySQL的状态    
service mysql stop         关闭MySQL    

十二、Linux内核优化

打开配置文件

vim /etc/sysctl.conf

加载新的配置(需开启防火墙iptables，否则会报错)

sysctl -p

收藏的详情地址

https://www.cnblogs.com/lldsn/p/10489593.html

十三、用户权限操作

1、添加用户
添加用户sum:

useradd –d /usr/sum -m sum

关于useradd的某些参数：

-u： 指定 UID，这个 UID 必须是大于等于500，并没有其他用户占用的 UID

-g： 指定默认组，可以是 GID 或者 GROUPNAME，同样也必须真实存在

-G： 指定额外组

-c： 指定用户的注释信息

-d： 指定用户的家目录

已创建的用户sum设置密码

passwd sum

新建的用户在面显示

cat /etc/passwd

删除用户sum

userdel sum

删除用户文件夹

rm -rf /usr/sum

切换下刚才添加的用户

su sum

回到root用户

exit

2、添加组
添加用户组

groupadd groupname

删除用户组

groupdel groupname

可以看到自己的分组和分组id

cat /etc/group

sum: x:1000:1000:: /usr/sum :/bin/bash
sum: x:0:1000:: /usr/sum :/bin/bash

十四、TOP

实时占用的资源:

top

top命令执行结果分为两个区域：统计信息区和进程信息区

1、统计信息区
TOP：任务队列信息，与uptime命令执行结果相同.

• 15:33:39：系统时间
• up 5:40：主机已运行时间
• 2 users：用户连接数（不是用户数，who命令）
• load average: 1.09, 1.04, 0.98：系统平均负载，统计最近1，5，15分钟的系统平均负载

Tasks：进程信息

• 123 total：进程总数
• 3 running：正在运行的进程数
• 120 sleeping：睡眠的进程数
• 0 stopped：停止的进程数
• 0 zombie：僵尸进程数

%CPU(s)：CPU信息（当有多个CPU时，这些内容可能会超过两行）

• 42.1 us：用户空间所占CPU百分比
• 2.0 sy：内核空间占用CPU百分比
• 0.0 ni：用户进程空间内改变过优先级的进程占用CPU百分比
• 49.2 id：空闲CPU百分比
• 0.0 wa：等待输入输出的CPU时间百分比
• 6.0 hi：硬件CPU终端占用百分比
• 0.7 si：软中断占用百分比
• 0.0 st：虚拟机占用百分比

KiB Mem：内存信息（与第五行的信息类似与free命令类似）

• 3780.9 total：物理内存总量
• 727.4 free：已使用的内存总量
• 668.8 used：空闲的内存总量（free + userd = total）
• 2384.7 buff/cache：用作内核缓存的内存量

KiB：swap信息

• 2048.0 total：交换分区总量
• 2046.0 free：已使用的交换分区总量
• 2.0 used：空闲交换分区总量
• 859.6 avail：缓冲的交换区总量，内存中的内容被换出到交换区，然后又被换入到内存，但是使用过的交换区没有被覆盖，交换区的这些内容已存在于内存中的交换区的大小，相应的内存再次被换出时可不必再对交换区写入。

2、进程信息区

• PID:进程id

• USER:进程所有者的用户名

• PR:优先级

• NI:nice值。负值表示高优先级，正值表示低优先级

• RES:进程使用的、未被换出的物理内存的大小

• %CPU:上次更新到现在的CPU时间占用百分比

• %MEM:进程使用的物理内存百分比

• TIME+：进程所使用的CPU时间总计，单位1/100秒

• COMMAND:命令名/行

• PPID:父进程id

• RUSER:Real user name（看了好多，都是这样写，也不知道和user有什么区别，欢迎补充此处）

• UID:进程所有者的id

• VIRT:进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES

• GROUP:进程所有者的组名

• TTY:启动进程的终端名。不是从终端启动的进程则显示为?

• NI:nice值。负值表示高优先级，正值表示低优先级

• P:最后使用的CPU，仅在多CPU环境下有意义

• TIME:进程使用的CPU时间总计，单位秒

• SWAP:进程使用的虚拟内存中被被换出的大小

• CODE:可执行代码占用的物理内存大小

• DATA:可执行代码以外的部分（数据段+栈）占用的物理内存大小

• SHR:共享内存大小

• nFLT:页面错误次数

• nDRT:最后一次写入到现在，被修改过的页面数

• S:进程状态（D=不可中断的睡眠状态，R=运行，S=睡眠，T=跟踪/停止，Z=僵尸进程）

• WCHAN:若该进程在睡眠，则显示睡眠中的系统函数名

• Flags:任务标志

*TCP connection*

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pDjC0ORY-1630203549065)(https://pics1.baidu.com/feed/4afbfbedab64034f641e67dffe1d813408551d7f.jpeg?token=341c4a88025d5441f6efeadd184f0968&s=0A007B220D6A452093CDFDC8030070B1)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bcTc5ePT-1630203549070)(https://pics4.baidu.com/feed/5ab5c9ea15ce36d35970c9af6c2dc282e850b119.png?token=7bee1e859605f019d0de2a3912fc6882&s=D1B0147246C8FF2429DA4D53020010FA)]

客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西；

由于TCP不存在连接的概念，只存在请求和响应，请求和响应都是数据包，它们之间都是经过由TCP创建的一个从客户端发起，服务器接收的类似连接的通道，这个连接可以一直保持，http请求是在这个连接的基础上发送的；

在一个TCP连接上是可以发送多个http请求的，不同的版本这个模式不一样。

在HTTP/1.0中这个TCP连接是在http请求创建的时候同步创建的，http请求发送到服务器端，服务器端响应了之后，这个TCP连接就关闭了；

HTTP/1.1中可以以某种方式声明这个连接一直保持，一个请求传输完之后，另一个请求可以接着传输。这样的好处是：在创建一个TCP连接的过程中需要“三次握手”的消耗，“三次握手”代表有三次网络传输。

如果TCP连接保持，第二个请求发送就没有这“三次握手”的消耗。HTTP/2中同一个TCP连接里还可以并发地传输http请求。

TCP报文格式简介

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GowB0u1c-1630203549071)(https://pics3.baidu.com/feed/64380cd7912397ddb480a4110c5c4ab2d1a28709.jpeg?token=45d9d76830f1e8052a5f5394378e459a&s=048A5F31C60E77495EC7C14D0300C0E2)]

其中比较重要的字段有：

（1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

URG：紧急指针（urgent pointer）有效。ACK：确认序号有效。PSH：接收方应该尽快将这个报文交给应用层。RST：重置连接。SYN：发起一个新连接。FIN：释放一个连接。

需要注意的是：

不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1，两端配对。

*TCP的三次握手（Three-Way Handshake）*

1.”三次握手”的详解

所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j940qP74-1630203549073)(https://pics1.baidu.com/feed/d8f9d72a6059252d20d93b0a6645fb3e59b5b9d2.jpeg?token=c86d4509157378798ebbccbe843486d1&s=9746F8123F5754CA48D574DA0300D0B2)]

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）首先客户端向服务器端发送一段TCP报文，其中：

标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；随后客户端进入SYN-SENT阶段。（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；序号为Seq=y；确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；随后客户端进入ESTABLISHED阶段。服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。

2.“三次握手”的动态过程

3.“三次握手”的通俗理解

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eyS54PiJ-1630203549076)(https://pics2.baidu.com/feed/838ba61ea8d3fd1f488fcc3a6790dd1a94ca5f0b.jpeg?token=b04e8b986fcc6303a2871b92b6e7e44a&s=0450E432491271CA18ED00CF0300E0B1)]

举个栗子：把客户端比作男孩，服务器比作女孩。用他们的交往来说明“三次握手”过程：

（1）男孩喜欢女孩，于是写了一封信告诉女孩：我爱你，请和我交往吧！;写完信之后，男孩焦急地等待，因为不知道信能否顺利传达给女孩。

（2）女孩收到男孩的情书后，心花怒放，原来我们是两情相悦呀！于是给男孩写了一封回信：我收到你的情书了，也明白了你的心意，其实，我也喜欢你！我愿意和你交往！;

写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。

（3）男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！

女孩收到男孩的回信之后，也很开心，因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意，之后就快乐地交流起来了~~

这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。

4.为什么要进行第三次握手？

为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。

如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，

服务器端是不知道客户端有没有接收到服务器端返回的信息的。

这个过程可理解为：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-atbZ9xzV-1630203549077)(https://pics3.baidu.com/feed/1c950a7b02087bf4cf316c92aa0daf2913dfcfd4.jpeg?token=7e26ac525676d063251da3d6bf395e8a&s=3172483221D25DCA14F115DA0300E0B0)]

这样没有给服务器端一个创建还是关闭连接端口的请求，服务器端的端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。那么服务器端上没有接收到请求数据的上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器端开销的严重浪费。

还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。

所以我们需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待。

也可以这样理解：“第三次握手”是客户端向服务器端发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。若发送的这个数据是“收到了”的信息，接收后服务器就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

5.抓包验证

下面是用抓包工具抓到的一些数据包，可用来分析TCP的三次握手：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P6BGxSrs-1630203549078)(https://pics7.baidu.com/feed/ca1349540923dd54b004ffbc86d74bdb9e8248d7.jpeg?token=d79c25e5a05e3b9b583e576d0d39d3fb)]

图中显示的就是完整的TCP连接的”三次握手”过程。在52528 -> 80中，52528是本地(客户端)端口，80是服务器的端口。80端口和52528端口之间的三次来回就是"三次握手"过程。

注意到”第一次握手”客户端发送的TCP报文中以[SYN]作为标志位，并且客户端序号Seq=0；

接下来”第二次握手”服务器返回的TCP报文中以[SYN，ACK]作为标志位；并且服务器端序号Seq=0；确认号Ack=1(“第一次握手”中客户端序号Seq的值+1);

最后”第三次握手”客户端再向服务器端发送的TCP报文中以[ACK]作为标志位；

其中客户端序号Seq=1（“第二次握手”中服务器端确认号Ack的值）；确认号Ack=1(“第二次握手”中服务器端序号Seq的值+1)。

这就完成了”三次握手”的过程，符合前面分析的结果。

*TCP的四次挥手（Four-Way Wavehand）*

1、前言

对于"三次握手"我们耳熟能详，因为其相对的简单。但是，我们却不常听见“四次挥手”，就算听过也未必能详细地说明白它的具体过程。下面就为大家详尽，直观，完整地介绍“四次挥手”的过程。

2、“四次挥手”的详解

所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kc1dKX3w-1630203549078)(https://pics5.baidu.com/feed/48540923dd54564e5260495ce0006487d0584fb6.jpeg?token=c3a743af38e25ff66deb6a07891be58e&s=C584FC1A71CFF4EE1A75A45203007073)]

挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：

（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL

为什么要客户端要等待2MSL呢？见后文。

服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。

客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

3、“四次挥手”的通俗理解

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JlFF6dtJ-1630203549079)(https://pics3.baidu.com/feed/caef76094b36acaf042ba27e2f07751503e99c48.jpeg?token=82e7f4e96e77dc4f3a6b5d9d1e36af2c&s=C150C53249BAC4CA586931D6030050B2)]

举个栗子：把客户端比作男孩，服务器比作女孩。通过他们的分手来说明“四次挥手”过程。

“第一次挥手”：日久见人心，男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。“第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！于是立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝！“第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天……

倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。

4.为什么“握手”是三次，“挥手”却要四次？

TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

所以是“三次握手”，“四次挥手”。

5.为什么客户端在TIME-WAIT阶段要等2MSL?

为的是确认服务器端是否收到客户端发出的ACK确认报文

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因

6.抓包验证

图中显示的就是完整的TCP连接释放的”四次挥手”过程。在 80 -> 55389 中，假设80是本地(客户端)端口，55389是服务器端口。80端口与55389之间的四次来回就是"四次挥手"过程。

”第一次挥手”客户端发送的FIN请求释放连接报文以[FIN，ACK]作为标志位，其中报文序号Seq=2445；确认号Ack=558；注意：这里与“第三次握手”的ACK并不是表示确认的ACK报文。”第二次挥手”服务器端返回的ACK确认报文以[ACK]作为标志位；其中报文序号Seq=558；确认号Ack=2246；”第三次挥手”服务器端继续返回的FIN同意释放连接报文以[FIN，ACK]作为标志位；其中报文序号Seq=558；确认号Ack=2246；”第四次挥手”客户端发出的ACK确认接收报文以[ACK]作为标志位；其中报文序号Seq=2446；确认号Ack=559。后一次“挥手”传输报文中的序号Seq值等于前一次"握手"传输报文中的确认号Ack值；后一次“挥手”传输报文中的确认号Ack值等于前一次"握手"传输报文中的序号Seq值；

故这是连续的“四次挥手”过程，与前面的分析相符。
男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。“第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！于是立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝！“第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天……

倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。

4.为什么“握手”是三次，“挥手”却要四次？

TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

所以是“三次握手”，“四次挥手”。

5.为什么客户端在TIME-WAIT阶段要等2MSL?

为的是确认服务器端是否收到客户端发出的ACK确认报文

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因

6.抓包验证

图中显示的就是完整的TCP连接释放的”四次挥手”过程。在 80 -> 55389 中，假设80是本地(客户端)端口，55389是服务器端口。80端口与55389之间的四次来回就是"四次挥手"过程。

”第一次挥手”客户端发送的FIN请求释放连接报文以[FIN，ACK]作为标志位，其中报文序号Seq=2445；确认号Ack=558；注意：这里与“第三次握手”的ACK并不是表示确认的ACK报文。”第二次挥手”服务器端返回的ACK确认报文以[ACK]作为标志位；其中报文序号Seq=558；确认号Ack=2246；”第三次挥手”服务器端继续返回的FIN同意释放连接报文以[FIN，ACK]作为标志位；其中报文序号Seq=558；确认号Ack=2246；”第四次挥手”客户端发出的ACK确认接收报文以[ACK]作为标志位；其中报文序号Seq=2446；确认号Ack=559。后一次“挥手”传输报文中的序号Seq值等于前一次"握手"传输报文中的确认号Ack值；后一次“挥手”传输报文中的确认号Ack值等于前一次"握手"传输报文中的序号Seq值；

故这是连续的“四次挥手”过程，与前面的分析相符。