SSL实现必须读取整条记录，哪怕select返回了一个字节可读，那么ssl也要读取整个记录，这种基于纪录的读写方式就是为了正确的加密个解密。因此如果用select模型的话可能会出现一些莫名其妙的问题，事实上也正是ssl消息需要加密解密从而需要整个消息整个消息读写才使得ssl协议的行为和tcp的有了少有的不一致。
tcp的特点是流式传输，流式的特点就是没有消息边界，一个连接就是一个流，需要应用程序自己去划分自己的数据，举个例子就是一端写入x字节，对端可能读出y字节，具体多少要看网络状况和窗口情况，tcp在这一点上是相当复杂的，应用程序的发送只是简单的将数据放入tcp的发送缓冲区，而接收只是简单的从接收缓冲区中取回数据，反观udp就不是这样子，udp是基于数据报的，就是说不能分段，一端写入多少另一端就读出多少，当然也可能永远收不到，也可能乱序等等。现在看看ssl，它看起来好像是结合了tcp和udp的特点，它是有连接的，必须可靠传输并且按照顺序收发，但是却不是流式的，每次调用SSL_read必须读入一个ssl纪录，一个ssl纪录有一个固定大小的头部(5字节)，该头部指示了消息类型，ssl版本号以及消息长度，首先需要读出一个ssl消息头部，接下来就要在该头部的消息长度字段的指导下进行消息体的读取，而且必须读取完整个完整消息之后才能返回成功，否则均返回失败，并且什么都不做，ssl读操作中，带有头的消息是read的最小单位。ssl3_read_bytes是openssl中SSL_read最终要调用的函数，它内部调用了ssl3_get_record：
static int ssl3_get_record(SSL *s)
{
...
rr= &(s->s3->rrec);
sess=s->session;
...
again:
if ((s->rstate != SSL_ST_READ_BODY) ||
(s->packet_length < SSL3_RT_HEADER_LENGTH)) {
n=ssl3_read_n(s, SSL3_RT_HEADER_LENGTH, s->s3->rbuf.len, 0);
if (n <= 0) return(n);
s->rstate=SSL_ST_READ_BODY;
p=s->packet;
rr->type= *(p++); //得到消息头中的消息类型
ssl_major= *(p++); //得到消息头中的主版本号
ssl_minor= *(p++); //得到消息头中的次版本号
version=(ssl_major<<8)|ssl_minor; //组合成版本号
n2s(p,rr->length); //得到消息的长度
...
}
if (rr->length > s->packet_length-SSL3_RT_HEADER_LENGTH) {
i=rr->length;
n=ssl3_read_n(s,i,i,1); //按照消息长度读取消息
if (n <= 0) return(n);
}
s->rstate=SSL_ST_READ_HEADER;
...
}
在ssl3_read_n的主要逻辑很简单：
while (newb < n) {
clear_sys_error();
s->rwstate=SSL_READING;
i=BIO_read(s->rbio, &(s->s3->rbuf.buf[off+newb]), max-newb);
if (i <= 0) { //只要没有读到数据，那么就返回
s->s3->rbuf.left = newb;
return(i);
}
newb+=i;
}
int ssl3_pending(const SSL *s)
{
if (s->rstate == SSL_ST_READ_BODY)
return 0;
return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ? s->s3->rrec.length : 0;
}
通过SSL_pending可以判断是否有消息数据还在缓冲区或者还没有到缓冲区，它实际上返回的就是消息的长度，因此如果使用select调用的话，很有可能select检测到的可读情况仅仅只有tcp送来的很少的数据量，远远不够ssl需要的数据量，那么只要SSL_pending返回非0，那么就需要循环调用SSL_read继续读取，否则你会认为这是一个莫名其妙的错误，明明select返回了，为何SSL_read却读不到数据，注意，在ssl读缓冲区被完全的消息填满前，SSL_read是不会返回任何数据的。同样的，SSL_write也是一样的道理，总之在openssl的实现中，一个ssl拥有一个SSL3_BUFFER类型的结构体(v3)：
typedef struct ssl3_buffer_st {
unsigned char *buf; /* at least SSL3_RT_MAX_PACKET_SIZE bytes,
size_t len; /* buffer size */
int offset; /* where to 'copy from' */
int left; /* how many bytes left */
} SSL3_BUFFER;
tcp的特点是流式传输，流式的特点就是没有消息边界，一个连接就是一个流，需要应用程序自己去划分自己的数据，举个例子就是一端写入x字节，对端可能读出y字节，具体多少要看网络状况和窗口情况，tcp在这一点上是相当复杂的，应用程序的发送只是简单的将数据放入tcp的发送缓冲区，而接收只是简单的从接收缓冲区中取回数据，反观udp就不是这样子，udp是基于数据报的，就是说不能分段，一端写入多少另一端就读出多少，当然也可能永远收不到，也可能乱序等等。现在看看ssl，它看起来好像是结合了tcp和udp的特点，它是有连接的，必须可靠传输并且按照顺序收发，但是却不是流式的，每次调用SSL_read必须读入一个ssl纪录，一个ssl纪录有一个固定大小的头部(5字节)，该头部指示了消息类型，ssl版本号以及消息长度，首先需要读出一个ssl消息头部，接下来就要在该头部的消息长度字段的指导下进行消息体的读取，而且必须读取完整个完整消息之后才能返回成功，否则均返回失败，并且什么都不做，ssl读操作中，带有头的消息是read的最小单位。ssl3_read_bytes是openssl中SSL_read最终要调用的函数，它内部调用了ssl3_get_record：
static int ssl3_get_record(SSL *s)
{
...
rr= &(s->s3->rrec);
sess=s->session;
...
again:
if ((s->rstate != SSL_ST_READ_BODY) ||
(s->packet_length < SSL3_RT_HEADER_LENGTH)) {
n=ssl3_read_n(s, SSL3_RT_HEADER_LENGTH, s->s3->rbuf.len, 0);
if (n <= 0) return(n);
s->rstate=SSL_ST_READ_BODY;
p=s->packet;
rr->type= *(p++); //得到消息头中的消息类型
ssl_major= *(p++); //得到消息头中的主版本号
ssl_minor= *(p++); //得到消息头中的次版本号
version=(ssl_major<<8)|ssl_minor; //组合成版本号
n2s(p,rr->length); //得到消息的长度
...
}
if (rr->length > s->packet_length-SSL3_RT_HEADER_LENGTH) {
i=rr->length;
n=ssl3_read_n(s,i,i,1); //按照消息长度读取消息
if (n <= 0) return(n);
}
s->rstate=SSL_ST_READ_HEADER;
...
}
在ssl3_read_n的主要逻辑很简单：
while (newb < n) {
clear_sys_error();
s->rwstate=SSL_READING;
i=BIO_read(s->rbio, &(s->s3->rbuf.buf[off+newb]), max-newb);
if (i <= 0) { //只要没有读到数据，那么就返回
s->s3->rbuf.left = newb;
return(i);
}
newb+=i;
}
int ssl3_pending(const SSL *s)
{
if (s->rstate == SSL_ST_READ_BODY)
return 0;
return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ? s->s3->rrec.length : 0;
}
通过SSL_pending可以判断是否有消息数据还在缓冲区或者还没有到缓冲区，它实际上返回的就是消息的长度，因此如果使用select调用的话，很有可能select检测到的可读情况仅仅只有tcp送来的很少的数据量，远远不够ssl需要的数据量，那么只要SSL_pending返回非0，那么就需要循环调用SSL_read继续读取，否则你会认为这是一个莫名其妙的错误，明明select返回了，为何SSL_read却读不到数据，注意，在ssl读缓冲区被完全的消息填满前，SSL_read是不会返回任何数据的。同样的，SSL_write也是一样的道理，总之在openssl的实现中，一个ssl拥有一个SSL3_BUFFER类型的结构体(v3)：
typedef struct ssl3_buffer_st {
unsigned char *buf; /* at least SSL3_RT_MAX_PACKET_SIZE bytes,
size_t len; /* buffer size */
int offset; /* where to 'copy from' */
int left; /* how many bytes left */
} SSL3_BUFFER;
可以看到在ssl_st结构体中有ssl3_state_st类型的字段，ssl3_state_st中有SSL3_BUFFER类型的rbuf和wbuf，它们并不是链表，而是只有一个缓冲区，并且在ssl_write中并没有看到有线程保护的措施，因此每一个ssl连接存在且仅存在一对SSL3_BUFFER，也就是说每次只能由一个线程操作一个读缓冲或者一个写缓冲，这就迎合了openssl文档中的一个FAQ：Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads).这就是不能在多个线程操作同一个ssl指针的原因，当初这个问题可害得我加了好几个周末的班啊。特别要注意的是，如果用select模型来写基于ssl的程序，一定要弄清楚ssl和tcp语义的不同，也正是这种不同点使得将传统套接字程序移植成ssl套接字程序并不是我一年前认为的那么简单。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271983
