从上面的差异我们可以看到，服务器处理心跳原来的方式是首先直接解析type和payload，什么都不做任何的检查。
unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
- /* Read type and payload length first */
- hbtype = *p++;
- n2s(p, payload);
- pl = p;
-
接下来我们再看看修复之后他们是如何处理的：
我们之前介绍的示例代码和openssl的代码的data数据格式有一点差别就是openssl的data进行了16字节的数据对齐，其他格式一致。示例代码是为了让大家更好的理解原理，所以很多细节的东西就没有添加，避免由于复杂度过高而不易理解。
接下来我们来看一下openssl添加的两个最重要的判断条件：
if (1 + 2 + 16 > s->s3->rrec.length)
return 0; /* silently discard */
这个判断的目的是为了避免data的length为0这一特殊情况的处理；
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */
从这个判断条件我们可以看出，对payload的大小做了检查，如果超出了length就表示你可能是恶意攻击，直接返回0。
结论从openssl的heartbleed漏洞我们可以看出，尽管已经被大家广泛使用的openssl技术，且应用于很多金融领域，但是这里面依然存在着很多致命的漏洞。从上面的分析，您或许可以得出为什么这次的漏洞会叫heartbleed漏洞了，确实太heart bleed了。
如果大家对openssl感兴趣的话，后续博文将继续深入分析其具体实现。
很多人在看完本文，了解漏洞的相关原理后，都很蠢蠢欲动，希望有攻击示例代码，这说明通过本文大家都已了解漏洞原理，也从侧面反应我写的还是比较简明易懂的。如果大家对攻击感兴趣的话，可直接在评论中加以回复，后续考虑创作相关博文。
Heartbleed 的详细介绍：请点这里
Heartbleed 的下载地址：请点这里