HTTP2服務器發送FIN/ACK，然後RST沒有巨大的流量

Question

我在HTTP2上使用澤西。當流量高到一點時，異常就會升起。我得到了pcap發現服務器發送FIN/ACK而沒有收到FIN。我不確定這是否是一個FIN來關閉服務器端的連接。或單個FIN組合ACK到先前的分組。它看起來是後者，因爲客戶端沒有發送FIN。所以問題是服務器爲什麼只在小流量下發送FIN。我發現rece_q和send_q非常低。 CPU使用率並不高。我已經調整了一些TCP參數，結果是一樣的。這種行爲是不穩定的，有時可以，有時候不行。當我添加更多請求（使用相同的TPS）時，則不行。它看起來服務器完成了連接，但不知道確切的原因。它與HTTP2有關嗎？我們有一些地方可以看到確切的原因嗎​​？

下面是pcap快照。

pcap snapshot

---

更新2017年7月30日 調試日誌：

Sun Jul 30, 2017 8:31:35.591 PM org.glassfish.grizzly.http2.Http2FrameCodec parse 
 
FINE: Rx [2]: connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}}, frame=DataFrame {streamId=277, type=0, flags=[none], length=42, data=BuffersBuffer (154351355) [pos=0 lim=42 cap=42 bufferSize=1 buffers=[HeapBuffer (165674143) [pos=0 lim=42 cap=8391], null, null, null]]} 
 
Sun Jul 30, 2017 8:31:35.673 PM org.glassfish.grizzly.http2.Http2BaseFilter processFrames 
 
FINE: Http2ConnectionException occurred on connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}} during Http2Frame processing 
 
Sun Jul 30, 2017 8:31:35.684 PM org.glassfish.grizzly.http2.Http2FrameCodec serializeAndRecycle 
 
FINE: Tx: connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}}, frame=GoAwayFrame {streamId=0, type=7, flags=[none], length=64{lastStreamId=199, errorCode=REFUSED_STREAM}

而且在PCAP快照流277

pcap contains stream 277 from No 270,271 and 272

269包中有一個SETTINGS包。在交通中途發送SETTINGS是否正常？ 269之後，有三個數據包270,271和272正在使用蒸汽277.

奇怪的是，8：31：35.684左右我沒有找到GOWAY數據包。但僅在8：31：36.035 RST/ACK中發送。在回合時間的調試日誌如下：

Sun Jul 30, 2017 8:31:36.020 PM org.glassfish.grizzly.http2.Http2FrameCodec parse 
 
FINE: Rx [2]: connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}}, frame=DataFrame {streamId=465, type=0, flags=[END_STREAM], length=0, data=ByteBufferWrapper (1101850112) [visible=[java.nio.HeapByteBuffer[pos=0 lim=0 cap=0]]]} 
 
Sun Jul 30, 2017 8:31:36.023 PM org.glassfish.grizzly.http2.Http2BaseFilter processDataFrame 
 
FINE: Data frame received for non-existent stream: connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}}, frame=DataFrame {streamId=277, type=0, flags=[END_STREAM], length=0, data=ByteBufferWrapper (1101850112) [visible=[java.nio.HeapByteBuffer[pos=0 lim=0 cap=0]]]}, stream=277 
 
Sun Jul 30, 2017 8:31:36.024 PM org.glassfish.grizzly.http2.Http2BaseFilter processFrames 
 
FINE: Http2StreamException occurred on connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}} during Http2Frame processing 
 
Sun Jul 30, 2017 8:31:36.025 PM org.glassfish.grizzly.http2.Http2BaseFilter processFrames 
 
FINE: Http2ConnectionException occurred on connection=TCPNIOConnection{localSocketAddress={localhost/127.0.0.1:80}, peerSocketAddress={/127.0.0.1:57802}} during Http2Frame processing

日誌顯示出收到一個不存在的流277.這流是完全記錄在第一個日誌流。不確定這個蒸汽277會在接下來的幾毫秒內導致RST/ACK。我認爲它應該與包269〜272和流277有一些問題。

順便說一下，這次沒有FIN/ACK。

Answer 1

pcap顯示服務器上的異常終止。

您應該檢查服務器日誌以獲取有關發生這種情況的更多詳細信息。

一個可能的原因是服務器錯誤。

另一個可能的原因是客戶端在數據包14發送了一個無效的HEADERS幀;仍然，服務器應該發送一個GOAWAY幀，而不僅僅是關閉連接。

的RST在包17是正常的，因爲客戶端在數據包16在處理之前FIN發送的HEADERS幀，所以服務器與RST回覆指示發送的數據並沒有使其向用戶代碼層。

服務器日誌（可能在DEBUG級別）應該告訴你更多關於發生了什麼事情。