raw ソケットを使用すると、イーサネット、IP などの下位レベルのプロトコルと通信できます。はい、下位に行くといくつかの利点が得られますが、失うものとのバランスを取る必要があります。
この場合、サーバーは Udp プロトコルを使用するように作成されているため、通信は Udp でなければなりません。raw ソケットを使用する場合は、アプリケーション データを Udp パケットにカプセル化して送信する必要があります。また、クライアントが別の Udp クライアントとしてサーバーに表示されるように、Udp プロトコルとステート マシンに従うことを確認するコードを記述する必要もあります。これをすべて行うには、大量のコードを記述する必要があり、メンテナンスの増加、正しく機能させるためのコストの増加などの欠点があります。
私はあなたが上でリンクした論文を完全には読んでいませんが、自問すべき問題は、その研究論文で与えられた利益を得て、あなたのシナリオでそれらを再現できるかということです.
私の意見では、最初に、クライアントが非常に遅い理由を理解しようとする必要があります。あなたの要件は何ですか?優れた高速クライアントを構成するものについての指標はありますか? もし私があなたなら、最初に現在の実装を測定し、たとえば、転送されたバイト/秒など、シナリオに役立ついくつかのメトリックを念頭に置きます。次に、クライアントをプロファイリングして、時間がかかりすぎている場所を確認します。オーバーヘッドを削減して、はるかに高速化できるかどうかを確認してください。
要約すると、スタックを下に移動する前に、スタックの一番上 (つまり、アプリケーション内) で節約を探します。アプリが適切に作成されていない場合、どれだけ低くしても、期待するパフォーマンスの向上は見られません。