![mark](https://img.zouchanglin.cn///20200216/igy99NdTRXcF.png)

## Alibaba Java Coding Guidelines

写代码怎么能没有规范呢？这款插件是伴随阿里巴巴编码约规出现的，自我感觉是必须要安装的插件

## Lombok

以前的Java项目中，充斥着太多不友好的代码：各种getter/setter/toString；异常处理；I/O流的关闭操作等等，这些样板代码既没有技术含量，又影响着代码的美观，Lombok必备！不要忘记引入Lombok依赖



## GenerateSerialVersionUID

需要序列化某个类时候我们只需要实现 Serializable 接口，eclipse点击黄色的警告即可生成相应的序列化ID，那么我们在idea 中没有了黄色警告该如何自动生成这个序列化ID呢，此插件帮你快速生成序列化ID

## EasyCode

只需要配置好数据库，然后根据数据表可以直接生成Controller、Service、Dao层的所有代码，直接可以帮你省掉30%的代码，配合Lombok使用效果更佳

## Codota

支持智能代码自动提示，该功能可以增强 IDEA 的代码提示功能。支持 JDK 和知名第三方库的函数的使用方法搜索，可以看到其他知名开源项目对该函数的用法。当我们第一次使用某个类，对某个函数不够熟悉时，可以通过该插件搜索相关用法，快速模仿学习。

##  **GsonFormat**

有时候接口返回的是JSON对象，想要用一个JavaBean去接收，以便于处理后续，此时，可以根据JSON一键生成对JavaBean对象，免去手写的烦恼

## jclasslib bytecode viewer

虽然有自带的强大的反汇编工具 javap，不需要敲命令，简单直接，在右侧方便和源代码进行对比学习，对我们学习虚拟机指令有极大的帮助

## GenerateAllSetter

想依次调用 Setter 函数对属性赋值，如果属性较多很容易遗漏或者重复，此插件可以一键调用一个对象的所有的set方法，避免遗漏

##  **CodeGlance**

类似SublimeText的Mini Map插件，代码侧边小图，还是很实用的

## Java Stream Debugger

如果你是个经常使用JDK8的Stream特性的开发者，那么进行Debug的时候，可以将 Stream 的操作步骤可视化，非常有助于我们的学习

## Maven Helper

对于maven项目来说，jar包冲突非常常见，Maven Helper可以帮你快速找出插件冲突的 jar 包exclude掉

##  **VisualVM Launcher**

有时在本地开发进行压力测试，性能测试之类的监控器，其他场景一般不推荐使用此模式启动，还会启动另外一个Visual vm窗口，这个窗口是JDK bin目录下的JvisualVM

IDEA插件推荐

## 阻塞式IO与非阻塞式IO

传统的IO流都是阻塞式的。也就是说，当一个线程调用read() 或write()时，该线程被阻塞，直到有一些数据被读取或写入，该线程在此期间不能执行其他任务。因此，在完成网络通信进行IO操作时，由于线程会阻塞，所以服务器端必须为每个客户端都提供一个独立的线程进行处理，当服务器端需要处理大量客户端时，性能急剧下降。

Java NIO是非阻塞模式的。当线程从某通道进行读写数据时，若没有数据可用时，该线程可以进行其他任务。线程通常将非阻塞IO的空闲时间用于在其他通道上执行I0操作，所以单独的线程可以管理多个输入和输出通道。因此，NIO可以让服务器端使用一个或有限几个线程来同时处理连接到服务器端的所有客户端。

![](https://img.zouchanglin.cn///20200209/KXe8DDICWRg6.png)



选择器和通道的关系：通道注册到选择器上，选择器监控通道。当某一个通道上，某一个事件准备就绪时，那么选择器才会将这个通道分配到服务器端一个或多个线程上，再继续运行。比如说当客户端发送一些数据给服务器端，只有当客户端的所有数据都准备就绪时，选择器才会将这个注册的通道分配到服务器端的一个或者多个线程上。如果客户端的线程没有将数据准备就绪时，服务器端的线程可以执行其他任务，就不会阻塞在那里。

原先的传统的阻塞IO模式，相当于你没有手机去等快递，算准了EMS每天中午13:00会到你们公司门口，所以你12:50在那里等着他们来，在这10分钟里你被这件事情阻塞着，什么事情都做不了，真是浪费时间；而NIO的这种通道注册选择器，选择器监控通道，等到数据准备就绪才会占用服务器线程的非阻塞IO方式，更像是带着手机等外卖，我在饿了么注册了一个用户（通道在选择器上注册了），然后定完外卖就忙自己的去了，等到外卖送来之后我接到电话下去取就可以了。如果你学习过Linux内核的epoll多路复用模型，这一点应该不难理解，无非就是IO事件就绪通知！



## 选择器 Selector

选择器（ Selector） 是 SelectableChannle 对象的多路复用器， Selector 可以同时监控多个 SelectableChannel 的 IO 状况，也就是说，利用 Selector可使一个单独的线程管理多个 Channel。 Selector 是非阻塞 IO 的核心。

SelectableChannle 的结构如下图（注意：FileChannel不是可作为选择器复用的通道！FileChannel不能注册到选择器Selector！FileChannel不能切换到非阻塞模式！FileChannel不是SelectableChannel的子类！）

![](https://img.zouchanglin.cn///20200209/L1XXFe1koCDd.png)



当调用 register(Selector sel, int ops) 将通道注册选择器时，选择器对通道的监听事件，需要通过第二个参数 ops 指定，可以监听的事件类型，可使用 SelectionKey 的四个常量表示：

![](https://img.zouchanglin.cn///20200209/KodjKE4ujzdI.png)

若注册时不止监听一个事件，则可以使用位或操作符连接

![](https://img.zouchanglin.cn///20200209/Jpi13ac4hKdk.png)

SelectionKey： 表示 SelectableChannel 和 Selector 之间的注册关系。每次向选择器注册通道时就会选择一个事件(选择键)。 选择键包含两个表示为整数值的操作集。操作集的每一位都表示该键的通道所支持的一类可选择操作。

![](https://img.zouchanglin.cn///20200209/iiHChySw3m33.png)

Selector的常用API

![](https://img.zouchanglin.cn///20200209/sUtuDgTxOgY0.png)

## 阻塞式IO示例

阻塞式网络通信

![](https://img.zouchanglin.cn///20200209/lpp3Ix8tFriF.png)

有反馈的阻塞式通信

![](https://img.zouchanglin.cn///20200209/FE4OQxWL2Xg4.png)

## 非阻塞式IO示例

非阻塞式通信，其实与epoll的编程模式很像

![](https://img.zouchanglin.cn///20200209/1bCXK9huSKSW.png)

上面的功能类似于一个群聊，由于IDEA不支持junit控制台，所以我直接拿eclipse试了一下

![](https://img.zouchanglin.cn/20220731170223.gif)



## UDP使用NIO

其实和上面的示例没啥区别， UDP非阻塞网络，NIO中信息的接收端和发送端都是直接用DatagramChannel的open方法生成一个数据报通道，发送的时候指明地址和端口；接收的一方需要先bind一个端口号，监听着。接收方可能监听到多个发送端向其发送数据，为了单个线程能够处理多个客户端发送的数据，并且在发送的过程中不被某个发送端全程阻塞，同样需要用到选择器。

使用选择器仍然需要将通道注册到选择器上，并指明需要监听的事件，即选择键。

![](https://img.zouchanglin.cn///20200209/KhWnhT9Ok2Bt.png)

一旦向Selector注册了一或多个通道，就可以调用几个重载的select()方法。这些方法返回你所感兴趣的事件（如连接、接受、读或写）已经准备就绪的那些通道。换句话说，如果你对"读就绪"的通道感兴趣，select()方法会返回读事件已经就绪的那些通道。

* int select():阻塞到至少有一个通道在你注册的事件上就绪了
* int select(long timeout):select(long timeout)和select()一样，除了最长会阻塞timeout毫秒(参数)
* int selectNow():selectNow()不会阻塞，不管什么通道就绪都立刻返回，此方法执行非阻塞的选择操作。如果自从前一次选择操作后，没有通道变成可选择的，则此方法直接返回零。



## 管道 Pipe

Java NIO 管道是2个线程之间的单向数据连接。Pipe有一个source通道和一个sink通道。数据会被写到sink通道，从source通道读取

![](https://img.zouchanglin.cn///20200209/kijhEN89dvuq.png)

通过一个管道，在发送数据的源头线程内获取SinkChannel，将数据写入缓冲区，缓冲区切换成读模式，写入SinkChannel；通过该管道在接收数据的线程内获取SourceChannel，然后从SourceChannel读取数据放到缓冲区，然后切换缓冲区为读模式，将数据取出。

![](https://img.zouchanglin.cn///20200209/djmIAinIvKcC.png)

## NIO2中的几个实用类

随着 JDK 7 的发布， Java对NIO进行了极大的扩展，增强了对文件处理和文件系统特性的支持，以至于我们称他们为 NIO.2。因为 NIO 提供的一些功能， NIO已经成为文件处理中越来越重要的部分。

java.nio.file.Path 接口代表一个平台无关的平台路径，描述了目录结构中文件的位置。

![](https://img.zouchanglin.cn///20200209/rkEJPSbFjE6l.png)

java.nio.file.Files 用于操作文件或目录的工具类。

![](https://img.zouchanglin.cn///20200209/qfefHGnX8DdJ.png)

![](https://img.zouchanglin.cn///20200209/Jf221zkQhs98.png)





## 参考资料

http://tutorials.jenkov.com/java-nio/index.html

http://hg.openjdk.java.net/jdk/jdk/file/d8327f838b88/src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java

NIO网络通信

## NIO的通道

通道( Channel) ：由java.nio.channels包定义的。Channel 表示IO源与目标打开的连接。Channel类似于传统的“流”， 只不过Channel本身不能直接访问数据，Channel只能与Buffer进行交互。

应用程序与磁盘之间的数据写入或者读出，都需要由用户地址空间和内存地址空间之间来回复制数据，内存地址空间中的数据通过操作系统层面的IO接口，完成与磁盘的数据存取。在应用程序调用这些系统IO接口时，由CPU完成一系列调度、任务分配，在早期这些IO接口都是由CPU独立负责。所以当发生大规模读写请求时，CPU的占用率很高。

![mark](https://img.zouchanglin.cn///20200208/ERDg8DebUJIv.png)



之后，操作系统为了避免CPU完全被各种IO接口调用占用，引入了DMA，也就是直接存储器。当应用程序对操作系统发出一个读写请求时，会由DMA先向CPU申请权限，申请到权限之后，内存地址空间与磁盘之间的IO操作就全由DMA来负责操作。这样，在读写请求的过程中，CPU不需要再参与，CPU去做其他事情。当然，DMA来独立完成数据在磁盘与内存空间中的复制，需要借助于DMA总线。当频繁发生IO操作时，会导致DMA总线增多，但是当DMA总线过多时，大量的IO操作也会造成总线冲突的问题，即也会影响最终的读写性能。

![mark](https://img.zouchanglin.cn///20200208/DL24jwADvOgu.png)

为了避免DMA总线冲突对性能的影响，后来便有了通道的方式。通道，它是一个完全独立的处理器。CPU是中央处理器，通道本身也是一个处理器，完全独立的处理器，但是也附属于CPU，专门负责IO操作。既然是处理器，通道有自己的IO命令，与CPU无关。它更适用于大型的IO操作，性能更高。

![mark](https://img.zouchanglin.cn///20200208/BWvOPzGGQotn.png)

直接存储器DMA有独立总线。但在大量数据面前，可能会存在总线冲突，还是需要CPU来处理。通道是一个独立的处理器，DMA方式还是需要向CPU申请DMA总线的。通道有自己的处理器，适合与大量IO请求的场景，数据传输直接通过通道进行传输，不再需要请求CPU，这样便避免了大量IO导致CPU资源占用过高的问题！





## NIO完成文件复制

Channel 用于源节点与目标节点的连接，在JavaNIO中负责缓冲区数据的传输，本身不存储数据，所以需要配置缓冲区进行数据传输（铁路配合火车）

一、通道的主要实现类

实现的是java.nio.channels.Channel接口

 *      FileChannel 文件IO
 *      SocketChannel TCP的IO
 *      ServerSocketChannel TCP的IO
 *      DatagramChannel UDP的IO

二、获取通道

1、对支持通道的类提供了 getChannel()
 *      本地IO
 *      FileInputStream/FileOutputStream
 *      RandomAccessFile
 *      网络IO
 *      Socket
 *      ServerSocket
 *      DatagramChannel

2、JDK1.7中的NIO.2针对各种通道提供了静态方法

3、JDK1.7中的NIO.2的Files工具类的newByteChannel()



1、FileInputStream打开的通道，通过通道+非直接缓冲区完成文件复制

![mark](https://img.zouchanglin.cn///20200208/BmJ6IT1xTIBx.png)

2、这是通过把缓冲区建立在物理内存中的做法，使用了FileChannel的静态方法打开的通道

![mark](https://img.zouchanglin.cn///20200208/GbhIIAl2sn0q.png)

3、这是使用直接操作缓冲区完成的文件复制

![mark](https://img.zouchanglin.cn///20200208/63KgGwBE1lL4.png)

4、这是不建立缓冲区，直接通道数据传输

![mark](https://img.zouchanglin.cn///20200208/bTk0MTHOiWuJ.png)

我试了一下，复制1.3G的压缩包，四种方式分别用时为：

1、通道+非直接缓冲区完成文件复制：5956、 5645（内存有波动，不明显）

2、通道+直接缓冲区完成文件复制：5439、5302（内存有波动，不明显）

3、直接操作缓冲区完成的文件复制：1581、1560、1523（内存波动特别明显，见下图）

4、这是不建立缓冲区，直接通道数据传输：704、685、615 （内存几乎无波动）

![mark](https://img.zouchanglin.cn///20200208/xh4xBqqaYipz.png)

得出结论：直接缓冲区肯定比非直接缓冲区快，但是我这次测试效果不是很明显，直接操作内存映射文件速度明显提升，但是也会导致内存突然爆涨（因为是直接操作的内存映射文件），方式4就更狠了，直接通道传输数据，压根与内存没关系，因为没有缓冲区的存在，所以也是最快的！



## 分散读取和聚集写入

分散读取( Scattering Reads)是指从Channel中读取的数据“分散”到多个Buffer中。

![mark](https://img.zouchanglin.cn///20200208/MeGdxhhKGTmQ.png)

注意：按照缓冲区的顺序，从 Channel 中读取的数据依次将 Buffer 填满。

聚集写入（ Gathering Writes）是指将多个 Buffer 中的数据“聚集”到 Channel中，与分散读取是反的。  注意：按照缓冲区的顺序，写入 position 和 limit 之间的数据到 Channel 。

![mark](https://img.zouchanglin.cn///20200208/OuLJjDpur3rD.png)

下面是一个分散读取&聚集写入的示例：

![mark](https://img.zouchanglin.cn///20200209/wArb2DMjxIgh.png)

分散读取（Scattering Reads）：将通道中的数据分散到多个缓冲区中

聚集写入（Gathering Writes）：将多个缓冲区中的数据聚集到通道中



## 字符集Charset

只要是需要知道CharBuffer和ByteBuffer 的相互装换即可

![mark](https://img.zouchanglin.cn///20200208/qEGkaWWvsw8A.png)

## FileChannel常用的API

![mark](https://img.zouchanglin.cn///20200208/gpy47ikxFTqV.png)

NIO与通道数据传输

![mark](https://img.zouchanglin.cn///20200208/grYNG4qQBUjR.png)

## Java NIO简介

Java NIO (New IO/Non Blocking IO)，官方给的定义是New IO，但是我们也可以当作是Non Blocking IO，即非阻塞式IO，是从Java 1.4版本开始引入的一个新的IO API，可以替代标准的Java IO API。NIO与原来的IO有同样的作用和目的，但是使用的方式完全不同，NIO支 持面向缓冲区的、基于通道的IO操作。NIO将以更加高效的方式进行文件的读写操作。



## 传统IO与NIO区别

![mark](https://img.zouchanglin.cn///20200208/ai4NPS1c450y.png)

原来的IO是面向数据流的，包括网络流、文件流等等，要想双向传输只能分别建立输入流和输出流：输入输出流你可以把它当作管道，只能单向流动，一边作为输出，一边作为输入，这样我们操作的就是流，**面向输入输出流的编程！**

![mark](https://img.zouchanglin.cn///20200208/bymtTFdl4UgD.png)

现在看看NIO，NIO相当于建立的不是输入输出流，而是通道，通道只是负责连接，可以把通道看成是铁路，把缓冲区看成是火车，数据看作火车上的乘客，火车既能从应用程序到网络、扫描设备、文件，也能从网络、扫描设备、文件等到应用程序，是双向的IO，**所以NIO是面向缓冲区的！**

![mark](https://img.zouchanglin.cn///20200208/wVy3xa0tPQw9.png)

阻塞式IO与非阻塞IO、选择器等区别主要是针对网络通信而言的

## 通道和缓冲区

Java NIO系统的核心在于：通道(Channel)和缓冲区(Buffer)。通道表示打开到IO设备(例如:文件、套接字)的连接。若需要使用NIO系统，需要获取用于连接IO设备的通道以及用于容纳数据的缓冲区。然后操作缓冲区，对数据进行处理。**简而言之，Channel负责传输、Buffer存储**

## 缓冲区原理和操作

缓冲区(Buffer)：一个用于特定基本数据类型的容器。由java.nio包定义的，所有缓冲区都是Buffer抽象类的子类。Java NIO中的Buffer主要用于与NIO通道进行交互，数据是从通道读入缓冲区，从缓冲区写入通道中的。

缓冲区中的四个核心属性

* capacity：缓冲区中最大存储数据的容量，一旦声明不能改变
* limit：界限，表示缓冲区中可以操作数据的大小（limit后面的数据是不能进行读写的）
* position：位置，表示缓冲区中正在操作数据的位置
* mark：标记，表示记录当前position的位置，可以通过reset()恢复到mark的位置

关系：0 <= mark <= position <= limit <= capacity

![mark](https://img.zouchanglin.cn///20200208/sNeyJlS0XYxE.png)

下面是一段关于Buffer的联系代码，以ByteBuffer为例：

![mark](https://img.zouchanglin.cn///20200208/De22lcrUW4af.png)

如何分析这一段程序呢，下面这个张图可以很容易的理解这几个属性

![mark](https://img.zouchanglin.cn///20200208/OEgTVswy4fhs.jpg)

上述例子展示了其中position、capacity、limit的作用，没说到mark的作用，mark：标记，表示记录当前position的位置，可以通过reset()恢复到mark的位置

![mark](https://img.zouchanglin.cn///20200208/7EMwLr6DPlpO.png)

重点就是理解Buffer的四个属性，顺便总结一下API吧

* allocate() 开辟缓冲区
* put() 存数据
* flip() 切换到读模式
* get() 取数据
* rewind() 重复度数据
* clear() 清空缓冲区
* mark() 标记此时position值
* reset() 恢复到mark() 标记位置
* hasRemaining() 判断缓冲区还有没有可以操作的数据
* remaining() 缓冲区可操作数据的数量

![mark](https://img.zouchanglin.cn///20200208/N3EPp9DIcxjo.png)

## 直接缓冲区和非直接缓冲区

字节缓冲区要么是直接的，要么是非直接的。如果为直接字节缓冲区，则Java虚拟机会尽最大努力直接在此缓冲区上执行本机I/0操作。也就是说，在每次调用基础操作系统的一个本机I/O操作之前(或之后)，虚拟机都会尽量避免将缓冲区的内容复制到中间缓冲区中(或从中间缓冲区中复制内容)。



直接字节缓冲区可以通过调用此类的allocateDirect()工厂方法来创建。此方法返回的缓冲区进行分配和取消分配所需成本通常高于非直接缓冲区。直接缓冲区的内容可以驻留在常规的垃圾回收堆之外，因此，它们对应用程序的内存需求量造成的影响可能并不明显。所以，建议将直接缓冲区主要分配给那些易受基础系统的本机I/O操作影响的大型、持久的缓冲区。一般情况下，最好仅在直接缓冲区能在程序性能方面带来明显好处时分配它们。



直接字节缓冲区还可以通过FileChannel的map()方法将文件区域直接映射到内存中来创建。该方法返回MappedByteBuffer。Java 平台的实现有助于通过JNI从本机代码创建直接字节缓冲区。如果以上这些缓冲区
中的某个缓冲区实例指的是不可访问的内存区域，则试图访问该区域不会更改该缓冲区的内容，并且将会在
访问期间或稍后的某个时间导致抛出不确定的异常。



字节缓冲区是直接缓冲区还是非直接缓冲区可通过调用其isDirect()方法来确定。提供此方法是为了能够在
性能关键型代码中执行显式缓冲区管理。



### 非直接缓冲区

![mark](https://img.zouchanglin.cn///20200208/WkUz0CvKYdSY.png)

传统IO操作时，JVM在缓存在自己的JVM内存中，自己的JVM内存中的数据需要经过copy到内核缓存中，由操作系统决定何时把数据写入磁盘，但是一旦JVM把数据write到了缓存，操作系统把用户地址空间的缓存数据copy到自己的内核地址空间中，那么JVM时可以随时更改缓存中的数据的，但是程序员也没有操作JVM Gc的能力，这样应用程序IO就变得很低效，要经过copy到内核地址空间这一个步骤

### 直接缓冲区

![mark](https://img.zouchanglin.cn///20200208/grYNG4qQBUjR.png)

直接缓冲区时直接在物理内存中开辟了一个缓冲区，那么这个缓冲区是直接建立在OS的物理内存中的。相当于省略了中的copy的过程，可以提高效率，但是这样做也是有缺点的，比如非常消耗资源，缓冲区直接建立在物理内存中是一个非常巨大的消耗（主要是分配和销毁），而且一旦JVM把数据写入到物理内存缓冲区，那么这里的数据就不归JVM管了，这里的数据何时写到磁盘中，完全是由操作系统控制的。而且这块资源什么时候销毁呢？那就是JVM Gc 发生的时候，但是JVM GC这不是我们能控制的！



那么什么时候用这一块缓冲区比较好呢？比如有一些很大的数据长时间需要在内存中进行操作的话，就可以使用直接缓冲区！通过查看源码可以看到

```java
public native long allocateMemory(long var1); //建立直接缓冲区调用的方法

return new HeapByteBuffer(capacity, capacity); //非直接缓冲区直接新建数组放在堆中
```

![mark](https://img.zouchanglin.cn///20200208/rNwAmnrCABp6.png)

NIO与缓冲区

![mark](https://img.zouchanglin.cn///20200207/zezNAjgSvS3I.png)

## SYN泛洪攻击

SYN攻击其实就是Server收到Client的SYN，Server向Client发送SYN-ACK之后未收到Client的ACK确认报文， 这样服务器就需要维护海量的半开连接 ，等待客户端的 ACK, 最终导致服务器资源耗尽(sync queue 满)而丢弃新的连接。  Server会不断重发SYN-ACK，Linux服务器默认直到63秒才断开连接！

## SYN Cookie

其中一种防护方式是SYN Cookie， SYN Cookies 的应用允许服务器当 SYN 队列被填满时避免丢弃连接。相反，服务器会表现得像 SYN 队列扩大了一样。服务器会返回适当的SYN+ACK响应，但会丢弃 SYN 队列条目。如果服务器接收到客户端随后的ACK响应，服务器能够使用编码在 TCP 序号内的信息重构 SYN 队列条目。



## Linux内核实现

服务器会构造一个 sequence  number，根据 TCP 规范，由端点发送的第一个序号可以是由该端点决定的任何值。SYN Cookies 是根据以下规则构造的初始序号：  

- 令t为一个缓慢递增的时间戳（通常为 `time() >> 6 `，提供 64 秒的分辨率）；
- 令m为服务器会在 SYN 队列条目中存储的最大分段大小（maximum segment size，简称为 MSS）；
- 令s为一个加密散列函数对服务器和客户端各自的 IP 地址和端口号以及 t 进行运算的结果。返回得到的数值 s 必须是一个24位值，取低24位

为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以一般MSS值1460

则初始序列号`n`为：

- 高 **5** 位为`t mod 32`（mod是一种同余运算）
- 接下来**3**位为`m`的编码值
- 低 **24** 位为`s`



下面是具体过程，主要是低24位s得计算过程，服务器收到一个SYN包，计算一个消息摘要mac。

mac = MAC(A, k);

MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。在Linux实现中，MAC函数为SHA1

```
A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t || MSSIND
```

k为服务器独有的密钥，实际上是一组随机数。t为系统启动时间，每60秒加1。MSSIND为MSS对应的索引。

其实就是根据源IP、源端口、目的IP、目的端口、系统启动时间，MSS索引通过哈希函数计算出的一个值



SYN Cookie在Linux内核中的实现

如果SYN Cookie功能有编译进内核(CONFIG_SYN_COOKIE)，且选项tcp_syncookies不为0，那么可使用SYN Cookie。同时设置SYN Flood标志(listen_opt->synflood_warned)

![mark](https://img.zouchanglin.cn///20200207/WyWJ0MwUP5YJ.png)

![mark](https://img.zouchanglin.cn///20200207/LBg9Hbr6iWTI.png)

SHA1 安全哈希算法(Secure HASH Algorithm)主要适用于数字签名。

对于长度小于2^64位的消息，SHA1会产生一个160位的消息摘要。当接收到消息的时候，这个消息摘要可以用来
验证数据的完整性。在传输的过程中，数据可能会发生变化，那么这时候就会产生不同的消息摘要。
SHA1有如下特性：

* 不可以从消息摘要中复原信息。

* 两个不同的消息不会产生同样的消息摘要。



当客户端收到此`SYN+ACK` 报文后，根据`TCP`标准，它会回复`ACK`报文，且报文中`ack = n + 1`，那么在服务器收到它时，将`ack - 1`就可以拿回当初发送的`SYN+ACK`报文中的序号了！服务器巧妙地通过这种方式间接保存了一部分`SYN`报文的信息。 看到这里在回顾一个这个序列号的组成

- 高 **5** 位为`t mod 32`（mod是一种同余运算）
- 接下来**3**位为`m`的编码值
- 低 **24** 位为`s`

接下来，服务器需要对`ack - 1`这个序号进行检查：

- 将高 **5** 位表示的`t`与当前之间比较，看其到达地时间是否能接受。
- 根据`t`和连接元组重新计算`s`，看是否和低 **24** 一致，若不一致，说明这个报文是被伪造的。
- 解码序号中隐藏的`mss`信息

如果成功匹配， 服务器就会为新的连接创建和初始化一个传输控制块，然后把完成三次握手的req和新sock关联起来，下面看看验证这段逻辑的代码

![mark](https://img.zouchanglin.cn///20200207/XFz6jkwLFrbc.png)

`SYN Cookie`技术可以让服务器在收到客户端的`SYN`报文时，不分配资源保存客户端信息，而是将这些信息保存在`SYN+ACK`的初始序号和时间戳中。对正常的连接，这些信息会随着`ACK`报文被带回来。 

## SYN Cookie总结

由于cookie的计算只涉及到包头部分信息，在建立连接的过程。中不在服务器端保存任何信息，所以失去了协议的许多功能，比如超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN Cookie技术不能作为高性能服务器的防御手段。一些SYN攻击的防火墙也是基于SYN Cookie，只是把这个功能移动到内核之外的代理服务器上。



参考资料：

https://lwn.net/Articles/277146/ 

https://zh.wikipedia.org/wiki/SYN_cookie