gpt4 book ai didi

客户端在 ssl 握手期间 FIN、ACK 后向服务器发送 RST

转载 作者:行者123 更新时间:2023-12-03 10:38:22 25 4
gpt4 key购买 nike

编写了一些代码来与网络服务器进行 ssl 握手。我可以看到 SSL 握手正在发生,但在客户端发送 FIN、ACK 后,它再次发送 RST。下面是 ssl 流

没有。时间源目的地协议(protocol)信息

 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);

最佳答案

是的。它可能会导致问题、性能下降等。

在我遇到的情况下,RST 消息是由于错误的网络配置(一侧全双工 100Mbps,另一侧半双工 10Mbps),导致丢失包的其他延迟问题,......整个解决方案必须是检查找出罪魁祸首。

关于客户端在 ssl 握手期间 FIN、ACK 后向服务器发送 RST,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12320998/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com