データによってはソケットが閉じています。アクティブなファイアウォールに直面していますか？ （DPI-ディープパケットインスペクション）
TLS接続のトラブルシューティング（参照： opensslを使用したTLSのテスト を参照）の結果、アクティブなファイアウォールが配置されている可能性があります。
そのポートの接続は両側のncで機能します（
nc -l -p 8883サーバー上、nc server.com 8883クライアント上）TLS接続を確立するために手動でバイナリプリアンブルを送信し、最後のバイトは省略した場合も機能します（ここでも、
nc -l -p 8883 | xxd）。遅延が発生しているようです...念のため、接続が289バイトで強制的に閉じられているかどうかも確認したので、ランダムなテキストを大量に送信したところ、問題なく通過しました。
完全なTLSプリアンブルを送信すると、サーバーで何も受信されず、接続は閉じられます。最後のバイトの前に遅延を追加しようとしました、それが通過し、接続は開いたままです！
これは一体何なのか、それを会社のITに要求することを許可するにはどうすればよいですか？ （私たちはAT＆Tで特別なAPNをセットアップしていて、それがそこにあると思います）
トラブルシューティングの詳細：
私はnc -l -p 8883を使用して、他の場所からサーバーへの正常な接続試行からのTLSプリアンブルをキャプチャしました（289バイト）
0000000: 1603 0101 1c01 0001 1803 03f4 f363 0180
0000010: 3ce4 957f ee17 8b7f d8ef 9ce0 e608 1cac
0000020: d328 798d 8b10 cc7b b521 0....
...
0000120: 01
次に、それを再現するクライアントコマンドを示します。
(head TLS1.hex -n18 | xxd -r; sleep 0.3; echo 0: 01 | xxd -r )
| nc server.com 8883 -q 1
- 0.3秒未満、失敗
- = 0.3sが断続的に失敗する
- > 0.3秒、成功
暗闇の中で撮影しますが、たぶんこれは、長さフィールド> = 256のClientHelloを処理できないファイアウォール（またはエンコードの両方のバイトを使用する）などのミドルボックスです。
OpenSSL 1.0.1が2012年に初めてTLS1.2（および1.1）を実装した結果、ClientHelloに追加の暗号スイートと追加の拡張が含まれるようになり、デフォルトで初めて256を超えたため、サーバーに破損の報告が多数ありました。これを処理するように正しくコーディングされています。ファイアウォールに関する同様の問題を思い出しませんが、それは不可能ではありません。
テストするには、s_clientと-no_tls1_2（またはより簡単に-tls1または-tls1_1を選択してください）。あなたは付け加えられます -debugからs_client送受信される内容を正確に確認します。特に、各レコードのオフセット3から始まる2バイトは、そのレコードのコンテンツの（ビッグエンディアン）長さです。例では、これは011cおよび5バイトのレコードヘッダーと0x011cバイトのコンテンツは、合計0x0121バイトと一致します。