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