Sslvpn三期总结

Sslvpn三期总结

一 预研阶段

缺点

1)        对于可实现性的实验做得非常的不充分；

多连接、带宽有限、上下限不一致、优先级不相同等因素没有全面考虑和实验证明，导致后来的实现和预想的不是完全一致，尤其是优先级这一块。

2)        对于流量控制的原理没有更加深入的了解。

在预研期间，这方面我一直重视的不够，我一直认为只要我配置下规则，就一切ok了。由于没有对流控原理有个深入的理解，有一个问题在设计和实现的时候才暴漏出来。

如果用户没有关联流控规则，如果不给它指定一个默认流控规则，它会走一个现有的流控规则，导致默认流控规则的用户跟有流控规则的用户流控均等的问题。在预研和需求阶段，我一直认为如果用户不关联流控规则，它的流控会走fifo队列。其实这是错误的。一个接口只能配置一个流控队列类型。不可能既是htb qdisc又是fifo qdisc。

3)        对于性能的考虑不够全面。关于流控规则的下发对性能的影响，没有一个量化的考虑。这个实验不能在我的开发机上做，要在公共机上做；结果我在我的开发机上做，没有太大的意义。

优点

1)        比较及时的验证了该方案的可行性

二需求阶段

缺点

1)        需求最核心的地方是数据对象，包括数据的属性，方法，对外的通信接口和互斥等等。

要建立以对象为中心，面向对象的方式做需求分析，写需求。

2)        需求写的很不细致，很多异常情况没有考虑到。

例如

第三方同步用户时，要关联流控策略

生成用户证书时，添加用户

Tc filter的优先级不能配置为0

流控规则的下限不能为0

用户和用户组的属性的改变的各种情况

等等。

3)        写需求同时要考虑实现的架构，并进行评审。

这个地方我认为是这期工作最大失误。因为没有考虑要实现的架构，直接导致设计的全面更改。以后在需求编写和评审时，一定要想好实现的架构，并跟需求一起评审，非常重要。

4)         

三设计阶段

缺点

1)        设计写的过于粗略，异常考虑的太少。

设计文档要写到各个异常的分支有明确的处理过程。

2)        设计的耦合度太高，依赖性太强。

第一轮的设计sslvpn跟流控功能耦合度太高，不适合软件设计的可维护、可扩展的原则。

3)        对于模块间通信采用的方式不够明确，一定要明确。

对于配置管理来说，到底采用异步还是同步的方式操作，一直没有明确，导致后来工作的反复。虽然不同人有不同的意见，我应该尽早请求仲裁，来确定最终的实现方案。

4)        对于不同步的情况，考虑的不够周到，引入了一些bug。

为了避免配置的阻塞，tcuser采用异步操作，结果跟数据库不同步，引入了一些bug，这些都是考虑不够周全的地方，因此，以后出现异步的情况，不根据操作来进行分析。要根据对象来进行分析，判断哪些对象会出现哪些不同步，该如何处理。

5)        无论是内核的设计还是应用层的设计，都要考虑到互斥。

四编码自测阶段

缺点

1)        对于预研时候写的代码不能直接拿来用，要根据设计走查，看看是不是符合设计要求。

内核崩溃的bug可能就是因为我在内核的消息接收端没有设置互斥锁引起的。这段代码是预研时候写好的，以后就再也没有怎么关注它。

2)        重用代码一定要做到尽可能的紧凑。

要对代码进行聚合，将重用的代码进行单独的封装。

3)        复制粘贴的代码一定要走查一下，看看是不是做了相应的修改。上期出现了这个问题，没有想到这期我又出现了。

4)        对那些异常流程。在自测阶段就要想方法去覆盖到，不能把它遗留到测试阶段。