c - 建立连接时的OpenSSL各种数字包(PSH)

标签 c ssl tcp openssl

我正在 tcpdumping 我用 C 编写的客户端应用程序的连接尝试。我还用 C 编写了服务器。它描述了 TLSv1.2 握手和客户端证书的交换。

第一次转储

21:58:54.472800 IP client.host50766 > server.host5995: Flags [S], seq 1085811090, win 14600, options [mss 1460,sackOK,TS val 4437544 ecr 0,nop,wscale 6], length 0
21:58:54.473049 IP server.host5995 > client.host50766: Flags [S.], seq 3283511122, ack 1085811091, win 14480, options [mss 1460,sackOK,TS val 4436964 ecr 4437544,nop,wscale 6], length 0
21:58:54.473069 IP client.host50766 > server.host5995: Flags [.], ack 1, win 229, options [nop,nop,TS val 4437544 ecr 4436964], length 0
21:58:54.473736 IP client.host50766 > server.host5995: Flags [P.], seq 1:102, ack 1, win 229, options [nop,nop,TS val 4437545 ecr 4436964], length 101
21:58:54.473843 IP server.host5995 > client.host50766: Flags [.], ack 102, win 227, options [nop,nop,TS val 4436965 ecr 4437545], length 0
**21:58:54.474478 IP server.host5995 > client.host50766: Flags [P.], seq 1:2234, ack 102, win 227, options [nop,nop,TS val 4436965 ecr 4437545], length 2233**
21:58:54.474529 IP client.host50766 > server.host5995: Flags [.], ack 2234, win 298, options [nop,nop,TS val 4437545 ecr 4436965], length 0
21:58:54.475934 IP client.host50766 > server.host5995: Flags [.], seq 102:1550, ack 2234, win 298, options [nop,nop,TS val 4437545 ecr 4436965], length 1448
21:58:54.475997 IP client.host50766 > server.host5995: Flags [P.], seq 1550:2548, ack 2234, win 298, options [nop,nop,TS val 4437545 ecr 4436965], length 998
21:58:54.476125 IP server.host5995 > client.host50766: Flags [.], ack 2548, win 303, options [nop,nop,TS val 4436965 ecr 4437545], length 0
21:58:54.478441 IP server.host5995 > client.host50766: Flags [P.], seq 2234:3324, ack 2548, win 303, options [nop,nop,TS val 4436966 ecr 4437545], length 1090
21:58:54.517533 IP client.host50766 > server.host5995: Flags [.], ack 3324, win 344, options [nop,nop,TS val 4437556 ecr 4436966], length 0

第二次转储

21:58:45.427868 IP client.host50765 > server.host5995: Flags [S], seq 76713337, win 14600, options [mss 1460,sackOK,TS val 4435283 ecr 0,nop,wscale 6], length 0
21:58:45.428082 IP server.host5995 > client.host50765: Flags [S.], seq 2802620812, ack 76713338, win 14480, options [mss 1460,sackOK,TS val 4434703 ecr 4435283,nop,wscale 6], length 0
21:58:45.428101 IP client.host50765 > server.host5995: Flags [.], ack 1, win 229, options [nop,nop,TS val 4435283 ecr 4434703], length 0
21:58:45.429034 IP client.host50765 > server.host5995: Flags [P.], seq 1:102, ack 1, win 229, options [nop,nop,TS val 4435283 ecr 4434703], length 101
21:58:45.429248 IP server.host5995 > client.host50765: Flags [.], ack 102, win 227, options [nop,nop,TS val 4434704 ecr 4435283], length 0
**21:58:45.429389 IP server.host5995 > client.host50765: Flags [.], seq 1:1449, ack 102, win 227, options [nop,nop,TS val 4434704 ecr 4435283], length 1448**
21:58:45.429458 IP client.host50765 > server.host5995: Flags [.], ack 1449, win 274, options [nop,nop,TS val 4435284 ecr 4434704], length 0
**21:58:45.429509 IP server.host5995 > client.host50765: Flags [P.], seq 1449:2234, ack 102, win 227, options [nop,nop,TS val 4434704 ecr 4435283], length 785**
21:58:45.429544 IP client.host50765 > server.host5995: Flags [.], ack 2234, win 319, options [nop,nop,TS val 4435284 ecr 4434704], length 0
21:58:45.431700 IP client.host50765 > server.host5995: Flags [.], seq 102:1550, ack 2234, win 319, options [nop,nop,TS val 4435284 ecr 4434704], length 1448
21:58:45.431785 IP client.host50765 > server.host5995: Flags [P.], seq 1550:2548, ack 2234, win 319, options [nop,nop,TS val 4435284 ecr 4434704], length 998
21:58:45.432803 IP server.host5995 > client.host50765: Flags [.], ack 2548, win 303, options [nop,nop,TS val 4434705 ecr 4435284], length 0
21:58:45.434776 IP server.host5995 > client.host50765: Flags [P.], seq 2234:3324, ack 2548, win 303, options [nop,nop,TS val 4434705 ecr 4435284], length 1090
21:58:45.473490 IP client.host50765 > server.host5995: Flags [.], ack 3324, win 364, options [nop,nop,TS val 4435295 ecr 4434705], length 0

如 ** 所示,服务器有时会发送大小为 2234 的完整包,有时却不会。这是为什么?有没有办法让这种行为更稳定? 我已经设置了

SSL_CTX_set_options(ctx,SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
SSL_CTX_set_options(ctx,SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);

我还在服务器套接字上设置了 TCP_NODELAY 以禁用 NAGLE,但它没有改变任何东西。

我已经为这两种情况上传了 pcap 文件:https://db.tt/PajbHdl3

最佳答案

编辑:我不再认为这是 PMTU 我猜这是由于 PMTU(路径 MTU 发现),例如服务器确定数据包在不被分段的情况下可以具有的最大大小,并且对于同一主机的更多数据,数据包会变得更小(所有数据包 <= 1448 字节)。

从这个细节我不知道为什么服务器问候语(和证书?)有时会在一个数据包中发送。也许您可以通过使用 wireshark 检查 SSL 协议(protocol)的哪些部分在哪个数据包中发送来提供更多详细信息。

无论如何,我认为不需要使这种行为更加一致:TCP(和 SSL)是流而不是数据包协议(protocol),如果有效载荷或协议(protocol)数据被拆分成多个 TCP 数据包应该无关紧要。

关于c - 建立连接时的OpenSSL各种数字包(PSH),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21891575/

相关文章:

c - 如何限制用户输入字符串的大小或动态分配内存

spring - 我们可以在 Spring MVC Controller 中动态更改 SSL 证书吗?

.net - 我可以在 Azure 上为常规网站设置 SSL吗? (不是 WCF 或 MVC)

java - Windows 和 Linux 上的 tcp 断开连接创建

c - 查找 2 个整数之间数字不重复的数字计数的算法

关闭非阻塞套接字

java - HTTP 传输错误 : javax.net.ssl.SSLHandshakeException

tcp - 基于 FreeBSD 或 NetBSD 的商业 TCP/IP 堆栈供应商?

c# - exe之间的通信?

c - 堆排序适用于字符串,但不适用于整数