3

WebサーバーでSSLハンドシェイクを実行するためのコードを記述しました。SSLハンドシェイクが発生していることがわかりますが、クライアントがFIN、ACKを送信した後、再びRSTを送信します。以下はSSLストリームです

番号タイムソース宛先プロトコル情報

 33 1.350030    client          server         TCP      45447 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=803408331 TSER=0 WS=7
 34 1.351219    server         client          TCP      https > 45447 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1994962735 TSER=803408331 WS=3
 35 1.351231    client          server         TCP      45447 > https [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=803408331 TSER=1994962735
 36 1.351290    client          server         SSLv2    Client Hello
 37 1.352087    server         client          TCP      https > 45447 [ACK] Seq=1 Ack=106 Win=5792 Len=0 TSV=1994962735 TSER=803408331
 38 1.364899    server         client          TLSv1    Server Hello, Certificate, Server Key Exchange, Server Hello Done
 39 1.364905    client          server         TCP      45447 > https [ACK] Seq=106 Ack=1351 Win=8576 Len=0 TSV=803408335 TSER=1994962738
 40 1.391410    client          server         TLSv1    Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
 41 1.401229    server         client          TLSv1    Change Cipher Spec, Encrypted Handshake Message
 42 1.401351    client          server         TCP      45447 > https [FIN, ACK] Seq=304 Ack=1410 Win=8576 Len=0 TSV=803408344 TSER=1994962747
 43 1.403212    server         client          TLSv1    Encrypted Alert
 44 1.403222    client          server         TCP      45447 > https [RST] Seq=305 Win=0 Len=0
 45 1.403238    server         client          TCP      https > 45447 [FIN, ACK] Seq=1447 Ack=305 Win=6864 Len=0 TSV=1994962748 TSER=803408344
 46 1.403240    client          server         TCP      45447 > https [RST] Seq=305 Win=0 Len=0

サーバーにRSTを送信する理由を教えてください。これは問題を引き起こしますか?問題を引き起こすコードの一部:

apr_socket_t *sock;
    apr_sockaddr_t *backend;

    // set up the backend apr_sockaddr_t
    rv = apr_sockaddr_info_get( &backend, host, APR_UNSPEC, port,  0, p);
    rv = apr_socket_create( &sock, backend->family, SOCK_STREAM, 0,   p);
    rv = apr_socket_opt_set(sock, APR_SO_NONBLOCK, 1);
    rv = apr_socket_timeout_set(sock, timeout * 1000);

    c = (ssl_connection *)malloc (sizeof (ssl_connection));
    c->ssl = NULL;
    c->ssl_ctx = NULL;

    c->ssl_ctx = SSL_CTX_new (SSLv23_client_method ());//Create a new ssl_ctx structure


    SSL_CTX_set_options(c->ssl_ctx, SSL_OP_ALL);


    c->ssl = SSL_new (c->ssl_ctx);
    ssl_rand_seednum();

    apr_os_sock_get(&fd, sock);

    bio = BIO_new_socket(fd, BIO_NOCLOSE);
    SSL_set_bio(c->ssl, bio, bio);
    SSL_set_connect_state(c->ssl);
    apr_socket_connect(sock, backend);


   while (do_next) {

        ret = SSL_do_handshake(c->ssl);
        ecode = SSL_get_error(c->ssl, ret);
        switch (ecode) {
            case SSL_ERROR_NONE:
                ap_log_perror(APLOG_MARK, APLOG_ERR, 0, p,
                        "connect_ssl_backend_ws()- Handshake Completed SuccessFully ");

                do_next = 0;
                rv = APR_SUCCESS;
                break;
            case SSL_ERROR_WANT_READ:
                do_next = 1;
                break;
            case SSL_ERROR_WANT_WRITE:
                do_next = 1;
                break;
            case SSL_ERROR_WANT_CONNECT:
                do_next = 0;
                rv = APR_INCOMPLETE;
                break;
            case SSL_ERROR_SSL:
                do_next = 0;
                rv = APR_INCOMPLETE;
                break;
            case SSL_ERROR_SYSCALL:
                /* Unexpected result */
                do_next = 0;
                rv = APR_INCOMPLETE;
                break;
        }
    }
  for (i = 0; i < 4 ; i++) {
            if ((rc = SSL_shutdown(c->ssl)))
                break;
        }
        SSL_free(c->ssl);

    }
    if (c->ssl_ctx)
        SSL_CTX_free (c->ssl_ctx);

    free (c);
    c->ssl = NULL;
    c->ssl_ctx = NULL;
    apr_socket_close(sock);
4

1 に答える 1

0

はい。不具合や性能低下などの原因となります。

私が持っていたケースでは、RST メッセージは間違ったネットワーク構成 (片側が全二重 100Mbps、もう一方が半二重 10Mbps)、パッケージの紛失につながるその他の遅延の問題が原因でした...ソリューション全体を確認して見つける必要があります犯人を出します。

于 2012-09-07T15:24:57.583 に答える