Javaエンドポイント（Oracle GlassFish 3.1.Xでホストされている）への非常に小さなWebサービス呼び出しが多数あるという問題があります。このサービスを（リモートwsdlファイルを使用して）サービス参照として追加し、BasicHttpBindingを使用してアクセスしました。
このサービスは世界の半分離れた場所にあり、インターネットを経由しているため、宛先に到達するときにパケット損失が発生することがよくあります。これらの発生の影響を減らすために、可能な限りの方法を検討しています。私たちはWiresharkを使用して、目的地までのネットワークを通過し、また戻ってくるものについての詳細な知識を提供してきました。私たちが生成するすべてのリクエストに対して、2つのパケットを送信しているのを見て興味がありました。パケット境界は常にHTTPヘッダーと<s:Envelope>タグの間にあります。私にとって、これは大きなオーバーヘッドです。特に、送信されるパケットの量を最小限に抑えたい（全体的なパケット損失を減らすために）環境ではそうです。
ほとんどの場合（呼び出しの99％）、HTTPヘッダーパケットは210バイトで、その後に291バイトのSOAPエンベロープパケットが続きます（各パケットの54バイトのTCP / IPオーバーヘッドを除く）。これらを合計すると、501バイトになります。これは、最大セグメントサイズである1460バイトの3分の1強です。WCFがこのHTTPPOST要求を501バイトの単一パケット（54バイトのTCP / IPオーバーヘッドを含めると555バイト）として送信しないのはなぜですか？
なぜそれがこれを行うのか誰かが知っていますか？HttpWebRequestオブジェクトがヘッダーを書き込んだ後にストリームで.Flush（）を呼び出しているように見えますが、なぜこれを行うのかわかりません。
私はこれらにさまざまな組み合わせを試しました：
ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false;
効果なし。
編集
間違い：もう少し調べてみましたが、HttpWebRequest.GetRequestStream（）が呼び出されると、ヘッダーがすぐにストリームに書き込まれます。返されるストリームに書き込む前のある段階で、ネットワークはこれらをフラッシュします（意図的なフラッシュがどこかで行われていない限り）。最終的にストリームへの書き込みを開始すると、すでにヘッダーパケットが送信されています。これを防ぐ方法がわからないため、GetRequestStream（）を呼び出したHttpWebRequestコード内の非常に難しいアサーションがヘッダーを書き込むようです。私の小さなリクエストについては、ストリームを閉じるまで何も書かないようにしたいのですが、それはストリームの性質に反します。