連接建立時的OpenSSL各種數字包（PSH）

Question

我是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

Answer 1

編輯：我不認爲任何更長，這是PMTU 我想這是由於PMTU（路徑MTU發現），例如服務器確定了數據包在不被分段的情況下可以具有的最大大小，並且爲了進一步向同一主機發送數據，數據包變小（所有數據包爲< = 1448字節）。

從這個細節我不知道爲什麼服務器hello（和證書？）有時會在一個數據包中發送。也許你可以通過使用wireshark檢查SSL協議的哪些部分在哪個數據包中發送來提供更多詳細信息。

無論如何，我不認爲應該有必要使此行爲更加一致：TCP（和SSL）是流而不是數據包協議，如果有效載荷或協議數據拆分爲多個TCP數據包應該沒有關係。