TCP ZeroWindow引入后会发生什么？

Question

在客户端/服务器通信中，我从客户端看到TCP ZeroWindow。

在这种情况之后，预期的场景是什么（设置并发送了哪些标志）？

以下是我正在获取的可能日志。在这种情况下，服务器发送RST数据包来终止连接。为什么发生这种情况？

客户机（HP-UX机），服务器（RHEL机）

Wireshark的转储服务器

17:55:03.756500  TCP 62 58304 → 1556 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1 
17:55:03.756522  TCP 62 1556 → 58304 [SYN, ACK] Seq=0 Ack=1 Win=14600 
        Len=0 MSS=1460 WS=128 
17:55:03.760562  TLSv1.2 571 Client Hello 
17:55:03.760588  TCP 54 1556 → 58304 [ACK] Seq=1 Ack=518 Win=15744 
        Len=0 
17:55:03.769564  TCP 1514 1556 → 58304 [ACK] Seq=1 Ack=518 Win=15744 
        Len=1460 [TCP segment of a reassembled PDU] 
17:55:03.769588  TLSv1.2 618 Server Hello, Certificate, Server Key 
        Exchange, Certificate Request, Server Hello Done 
17:55:03.769689  TCP 60 58304 → 1556 [ACK] Seq=518 Ack=1461 Win=32768 
        Len=0 
17:55:03.828427  TCP 60 58304 → 1556 [ACK] Seq=518 Ack=2025 Win=32768 
        Len=0 
17:55:23.789662  TLSv1.2 61 Alert (Level: Fatal, Description: Unexpected 
        Message) 
17:55:23.789748  TCP 54 1556 → 58304 [FIN, ACK] Seq=2032 Ack=518 
        Win=15744 Len=0 
17:55:23.789951  TCP 60 58304 → 1556 [ACK] Seq=518 Ack=2033 Win=32768 
        Len=0 
17:55:25.662787  TLSv1.2 192 [TCP ZeroWindow] , Certificate, Client Key 
        Exchange, Change Cipher Spec, Encrypted Handshake 
        Message 
17:55:25.662798  TCP 54 1556 → 58304 [RST] Seq=2033 Win=0 Len=0 

客户端卷曲日志

Info: ALPN, offering http/1.1 
Info: Cipher selection: 
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH 
Info: successfully set certificate verify locations: 
Info: TLSv1.2 (OUT), TLS header, Certificate Status (22): 
Info: TLSv1.2 (OUT), TLS handshake, Client hello (1): 
Info: TLSv1.2 (IN), TLS handshake, Server hello (2): 
Info: TLSv1.2 (IN), TLS handshake, Certificate (11): 
Info: TLSv1.2 (IN), TLS handshake, Server key exchange (12): 
Info: TLSv1.2 (IN), TLS handshake, Request CERT (13): 
Info: TLSv1.2 (IN), TLS handshake, Server finished (14): 
Info: TLSv1.2 (OUT), TLS handshake, Certificate (11): 
Info: TLSv1.2 (OUT), TLS handshake, Client key exchange (16): 
Info: TLSv1.2 (OUT), TLS change cipher, Client hello (1): 
Info: TLSv1.2 (OUT), TLS handshake, Finished (20): 
Info: TLSv1.2 (IN), TLS alert, Server hello (2): 
Info: error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected 
message 
Info: Closing connection 0 

的问题是，什么是预期的流何时控制何时发生TCP ZeroWindow以及在ZeroWindow超时之后如何重新启动通信？

以下是对ALERT数据包的描述。真的不知道什么是预期的。

Transmission Control Protocol,Seq: 2025, Ack: 518, Len: 7 

[Stream index: 2439] 
[TCP Segment Len: 7] 
Sequence number: 2025 (relative sequence number) 
[Next sequence number: 2032 (relative sequence number)] 
Acknowledgment number: 518 (relative ack number) 
0101 .... = Header Length: 20 bytes (5) 
Flags: 0x018 (PSH, ACK) 
Window size value: 123 
[Calculated window size: 15744] 
[Window size scaling factor: 128] 
Checksum: 0x9e59 [unverified] 
[Checksum Status: Unverified] 
Urgent pointer: 0 
[SEQ/ACK analysis] 
    [iRTT: 0.004062000 seconds] 
    [Bytes in flight: 7] 
    [Bytes sent since last PSH flag: 7] 
TCP payload (7 bytes) 
Secure Sockets Layer 
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unexpected Message) 
    Content Type: Alert (21) 
    Version: TLS 1.2 (0x0303) 
    Length: 2 
    Alert Message 
     Level: Fatal (2) 
     Description: Unexpected Message (10) 

请让我知道什么信息可能有助于通过。

Answer 1

对等体通告不同的窗口大小，可能是为了响应窗口探测器。然而零窗口只在最终的RST上，所以它不相关。

服务器在最终RST之前发送了FIN/ACK。不要忽视它。可能你已经发送了它不喜欢的东西，在这种情况下可能是客户端证书。

Answer 2

在这种情况下，上述问题是由于tomcat设置的connctionTimeout。

标准server.xml随Tomcat一起提供将其设置为20000（即20秒）。

ConnectionTimeout是tomcat Connector在接受客户端的连接以呈现请求uri行之后等待的毫秒数。

如果我们仔细看看wireshark转储，我们清楚地看到握手本身和ALERT之间的延迟时间为20秒。

因此，在这种情况下，慢客户端在设置了tcp连接后在套接字上延迟了http请求20秒，因此tomcat忽略了该套接字。

Tomcat设置此超时以防止DOS攻击。

更多关于connectionTimeout阅读https://tomcat.apache.org/tomcat-7.0-doc/config/http.html 更多关于DOS与connectionTimeout阅读http://grokbase.com/t/tomcat/users/137cxfqtr5/http-connection-timout