HTTP2でJerseyを使用しています。トラフィックが少し高くなり、例外が発生したとき。そして私は、pcapがFINを受け取らずにFIN/ACKを送ることを発見しました。私はそれがサーバー側からの接続を閉じるための単一のFINであるとは確信していません。または、単一のFINとACKを組み合わせて以前のパケットにします。後者は、クライアントがFINを送信しなかったために表示されます。だから問題は、サーバーが小さなトラフィックの下でFINを送信する理由です。そして、私はrece_qとsend_qが非常に低いことを発見しました。 CPU使用率があまり高くありません。私はすでにいくつかのTCPパラメータを調整しており、結果は同じです。この動作は不安定ですが、いつかはOKですが、まあまあOKではありません。私は（同じTPSと）より多くのリクエストを追加するとOKではありません。サーバーが接続を完了したように見えますが、正確な理由はわかりません。それはHTTP2に関連していますか？正確な理由を確認する場所がありますか？HTTP2サーバがFIN/ACKを送信し、その後にRSTを送信します。
以下はpcapスナップショットです。
アップデート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 contains stream 277 from No 270,271 and 272
269パケットにSETTINGSパケットがあります。輸送の途中で設定を送信するのは普通ですか？そして269の後に、3つのパケット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はありません。
8でのログ行：31：35.591 'HEADERS'フレームは何とかストリーム277のために解析されたことを示しているようだが、どうやら' GOAWAY'を起こし、成功しませんでした。 'FINEST'ログレベルを試しましたか？おそらくそれは何がうまくいかなかったのかをより多く示しているのかもしれないまた、あなたは、このような桟橋HTTP/2などの別の実装を試してみました（免責事項、私は、突堤HTTP/2メンテナですか）？ – sbordet
実は私は、ジャージーに桟橋HTTP/2を注入して設定する方法がわかりません。私はジャージーでは非常に限られたHTTP/2コンテナの使用しか見つけることができません。これについてもっと情報を提供できると感謝しています。ありがとう。 – user3675334
私はFINESTにログを設定しているが、その後、GoAwayFrameを送っ同じ、プロセスのエラーを探します。 pcapでは、RST/ACKが最後に送信されます。しかし、私は今日のpcapで気づいた別の奇妙なことと私は昨日のpcapで見つけた。 RST/ACKを送信するまでサーバーの収量は応答しませんでした。応答も大きなものでしたが、予想されるすべての応答は含まれていませんでした。昨日のpcapは、クライアントへのRST/ACKパケット以外の応答もありませんでした。 – user3675334