DTLS学习笔记 -- RFC 4347- 6347
想学习一下dtls，是因为想以后没有公司免费VPN可用的时候，我能买一个主机，自己建一个VPN。
1.介绍
Web, email大多用TLS协议来做安全的网络传输，它们必须跑在可靠的TCP传输通道里。
如果传输的是实时媒体数据，那么重传丢掉的包就没有意义，这个时候，我们希望它是跑在UDP传输通道里。
再有，应用层协议SIP可以用TCP或UDP来传，但我们更希望是UDP的。于是有了DTLS。
2. TLS有一些不同：
1)TLS不能单独对某个记录进行完整性检查，如果记录N没收到，那记录N+1无法被认证。因为MAC值是通过序列号计算的，而记录里并没有显示的包含序列号段。
2)TLS握手协议不用考虑丢包的问题
3.DTLS是跑在UDP上的TLS，这做了一些改变解决了几个问题
1) 禁止流加密。这样可以保证记录间加密上下文的独立性。
2) 给记录增加一个显示的序列号字段用来做重放攻击保护和记录数据认证。
3) 给握手包加入重传机制。为了requeset启用一个timer，如果没有收到response，而timer超时，那就重传request.
4) 保证握手包的顺序。每个握手包是有序列号的，如果不是期望收到的握手包，那么把它放入队列。如果是，立刻处理。
5) 消息的size。UDP包如果大于1500会被分片。所以每个DTLS握手报文包含一个段偏移和段长，如此便可还原被分片的握手报文。
6）重放保护。维护一个接收报文的bitmap window。过老的报文或者收到过的包都被扔掉。
4. DTLS记录的格式。除了上面提到的一些不同，很多字段和应用场景与TLS相同。
5. DTLS握手协议。DTLS握手协议基本与TLS相同，只有三个变化：
1) 加入一个无状态的cookie交换，以防止dos攻击。(就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复报文，就丢弃它)
2) 修改握手包头来处理丢包，重排序和IP包分片问题。
3) 重传timer，来处理丢包丢传问题。
6. DTLS握手包头，body较多不贴图了，细节参见RFC.
7. 握手流程
8.我写了一个简单的例子，client用dtls协议发送一个字符串到server的5000端口，在Mac OS上编译通过，正常工作。
https://github.com/andyhu-hz/mycode/tree/master/dtls_test
9.openssl中关于SSL_pending的一个错误认识。
开始以为SSL_pending是用来检测有数据到来的，当SSL_pending返回一个非零正整数时，再调用SSL_Read从buffer中读取数据。
事实上SSL_pending一直返回零，有人也遇到了类似的问题。见这里http://stackoverflow.com/questions/6616976/why-does-this-ssl-pending-call-always-return-zero
You are using SSL_pending() the completely wrong way. OpenSSL uses a state machine, whereSSL_pending() indicates if the state machine has any pending bytes that have been buffered and are awaiting processing. Since you are never calling SSL_read(), you are never buffering any data or advancing the state machine.
If the SSL_pending function returns a return code of 0, it does not necessarily mean that there is no data immediately available for reading on the SSL session. A return code of 0 indicates that there is no more data in the current SSL data record. However, more SSL data records may have been received from the network already. If the SSL_pending function returns a return code of 0, issue the select function, passing the file descriptor of the socket to check if the socket is readable. Readable means more data has been received from the network on the socket.
