ssl的消息读写以及和tcp语义的异同

   SSL实现必须读取整条记录，哪怕select返回了一个字节可读，那么ssl也要读取整个记录，这种基于纪录的读写方式就是为了正确的加密个解密。因此如果用select模型的话可能会出现一些莫名其妙的问题，事实上也正是ssl消息需要加密解密从而需要整个消息整个消息读写才使得ssl协议的行为和tcp的有了少有的不一致。

     1、tcp的特点是流式传输， 流式的特点就是没有消息边界，一个连接就是一个流，需要应用程序自己去划分自己的数据，举个例子就是一端写入x个字节，对端可能读出y个字节，具体多少要看网络状况和窗口情况，tcp在这一点上是相当复杂的，应用程序的发送只是简单的将数据放入tcp的发送缓冲区，而接收只是简单的从接收缓冲区中取回数据。

    2、反观udp就不是这样子， udp是基于数据报的，就是说不能分段，一端写入多少另一端就读出多少，当然也可能永远收不到，也可能乱序等等。

     3、现在看看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套接字程序并不是我一年前认为的那么简单。