グローバルカタログサーバーへの接続中に[PSH、ACK]は何をしますか？

私のLinuxサーバーは、グローバルカタログサーバーへのLDAPS接続を確立しようとしていますが、接続は（おそらくGC側によって）ドロップされています。

議論のために、1.1.1.1がLinuxサーバーであり、1.2.3.4がグローバルカタログサーバーであるとしましょう。

telnetLinuxボックスから使用しようとすると、次のように表示されます。

[root@foobox ~]# telnet gcfoo.exampleAD.local 3269
Trying 1.2.3.4...
Connected to gcfoo.examplead.local.
Escape character is '^]'.
Connection closed by foreign host.

4行目と5行目の間に遅延はありません。ただちに接続を切断します。

telnet結果は少し誤解を招くかもしれないと思ったので（実際にはどのタイプのセキュアな通信にも適切ではないため）、実際の接続試行のパケットキャプチャをアプライアンスから収集しました（LDAPSを必要とする実際のプログラムを使用）。

私が見るものは次のとおりです（ここでも、IPと送信元ポートは無実の人を保護するために名前が変更されています）：

No.     Time      Source     Destination      Protocol    Length    Info
1       0.000000  1.1.1.1    1.2.3.4          TCP         66        27246 > msft-gc-ssl [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SAC_PERM=1 WS=128
2       0.000162  1.2.3.4    1.1.1.1          TCP         62        msft-gc-ssl > 27246 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1
3       0.000209  1.1.1.1    1.2.3.4          TCP         54        27246 > msft-gc-ssl [ACK] Seq=1 Ack=1 Win=5840 Len=0
4       0.003462  1.1.1.1    1.2.3.4          TCP         248       27246 > msft-gc-ssl [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=194
5       0.007264  1.2.3.4    1.1.1.1          TCP         60        msft-gc-ssl > 27246 [RST] Seq=1 Win=64046 Len=0

私はTCP / IPに少しさびているので、私の無知を許してください。パケット1-3でスリーウェイハンドシェイクが行われているのがわかります。それは理にかなっている。パケット4で何が起こっているのでしょうか？どういう[PSH, ACK]意味ですか？これは不要な確認応答のようです。この4番目のパケットで実際のデータが送信されていますか？または、これはハンドシェイクの奇妙な継続ですか？

PSHプッシュフラグです：http : //ask.wireshark.org/questions/20423/pshack-wireshark-capture

Pushフラグは、受信側のネットワークスタックに、データを受信側のソケットに直接「プッシュ」するように指示します。そうする前にパケットを待機することはありません。

プッシュフラグは、通常、NagleのAlgorithmやDelayed Acknowledgmentsなどの組み込みのTCP効率の遅延をオーバーライドしながら、データが送信されたことを意味します。

これらの遅延により、多少の遅延（通常は数十ミリ秒程度）が発生しますが、TCPネットワーキングはより効率的になります。遅延の影響を受けやすいアプリケーションは、TCPの効率の遅延を待ちたくないため、通常はアプリケーションがそれらを無効にし、プッシュフラグを設定してデータを可能な限り迅速に送信します。

Linuxでは、これはsetsockopt()フラグTCP_QUICKACKとで行われTCP_NODELAYます。詳細についてはman 7 socket、を参照してください。

@DarkMoonは、PSHフラグの意味を説明しました。データに関しては、接続の確立が完了し（3ウェイハンドシェイク）、その後、はい、クライアントは194バイトのデータをサーバーに送信しました（Len=194）。サーバーはデータが気に入らず、接続を閉じました。SSL / TLSの不一致など、クライアントがサーバーと通信するように適切に構成されていない可能性があります。

アクセスできる場合は、サーバーのログを調べて、クライアントのデータに関して好ましくないものがログに記録されたかどうかを確認することをお勧めします。