WindowsシステムとPOSIXシステムの両方で、名前付きパイプを使用すると、同じマシンで実行されているプロセス間でプロセス間通信を行うことができます。名前付きパイプを使用すると、ネットワークスタックを使用することによるパフォーマンスの低下を招くことなく、データを送信できます。
サーバーが着信要求のIPアドレス/ポートをリッスンしているように、サーバーはリクエストをリッスンできる名前付きパイプを設定することもできます。どちらの場合でも、クライアントプロセス（またはDBアクセスライブラリ）は、要求を送信するために特定のアドレス（またはパイプ名）を知っている必要があります。多くの場合、一般的に使用される標準のデフォルトが存在します（HTTPのポート80と同様に、SQLサーバーはTCP/IPでポート1433を使用し、名前付きパイプには\\。\ pipe\sql\queryを使用します）。
追加の名前付きパイプを設定することにより、それぞれ独自の要求リスナーを持つ複数のDBサーバーを実行できます。
名前付きパイプの利点は、通常、はるかに高速であり、ネットワークスタックリソースを解放できることです。
-ところで、Windowsの世界では、リモートマシンへの名前付きパイプを使用することもできますが、その場合、名前付きパイプはTCP/IPを介して転送されるため、パフォーマンスが低下します。ローカルマシンの通信に名前付きパイプを使用します。
UnixとWindowsにはどちらも「名前付きパイプ」と呼ばれるものがありますが、動作が異なります。 Unixでは、名前付きパイプは一方通行であり、通常は1人のリーダーと1人のライターのみです。ライターが書き込み、リーダーが読み取ります。
Windowsでは、「名前付きパイプ」と呼ばれるものは、IPCソケットに似たTCPオブジェクトです-両方の方向に流れることができ、メタデータがあります（資格情報を取得できます）反対側の事など）。
Unix名前付きパイプは、ファイルシステム内の特別なファイルとして表示され、シェルを含む通常のファイルIOコマンドでアクセスできます。 Windowsのものはそうではなく、特別なシステムコールで開く必要があります（その後、通常のwin32ハンドルのように動作します）。
さらに紛らわしいことに、Unixには「Unixソケット」またはAF_UNIXソケットと呼ばれるものがあります。これは、双方向のwin32「名前付きパイプ」に似ています（完全には似ていません）。
Linux Pipes
先入れ先出し（FIFO）プロセス間通信メカニズム。
名前のないパイプ
コマンドラインで、「|」で表されます2つのコマンド間。
名前付きパイプ
A FIFO特殊ファイル。作成したら、通常のファイルと同じようにパイプを使用できます（開く、閉じる、書き込む、読み取るなど）。
コマンドラインから「myPipe」という名前のパイプを作成するには（ man page ）：
mkfifo myPipe
Cから名前付きパイプを作成するには、「パス名」はパイプに付けたい名前であり、「モード」にはパイプに必要な許可が含まれます（ manページ ）：
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
Wikipedia ：によると
[...]従来のパイプは匿名で存在し、プロセスが実行されている間のみ持続するため、「名前なし」です。名前付きパイプはシステムに永続的であり、プロセスの存続期間を超えて存在し、使用されなくなったら「リンク解除」または削除する必要があります。プロセスは通常、名前付きパイプ（通常はファイルとして表示される）に接続して、IPC（プロセス間通信）を実行します。
比較する
echo "test" | wc
に
mkdnod apipe p
wc apipe
wcはまでブロックします
echo "test" > apipe
実行する
Windowsアプリケーションのプロセス間通信（主に）。 Unixのアプリケーション間で通信するためにソケットを使用するのに似ています。
パイプは、アプリケーション間でデータをストリーミングする方法です。 Linuxでは、これを常に使用して、1つのプロセスの出力を別のプロセスにストリーミングします。宛先アプリはその入力ストリームがどこから来たのかわからないため、これは匿名です。必要ありません。
名前付きパイプは、既存のパイプに積極的にフックし、そのデータをフーバーアップする方法にすぎません。これは、プロバイダーがどのクライアントがデータを食べているかを知らない状況のためです。
これはTechnetからの例です（マークされた答えが名前付きパイプの方が速いという理由がわかりませんか？）：
名前付きパイプとTCP/IPソケット
高速ローカルエリアネットワーク（LAN）環境では、伝送制御プロトコル/インターネットプロトコル（TCP/IP）ソケットと名前付きパイプクライアントはパフォーマンスに関して同等です。ただし、TCP/IPソケットと名前付きパイプクライアントのパフォーマンスの違いは、ワイドエリアネットワーク（WAN）やダイヤルアップネットワークなどの低速ネットワークでは明らかになります。これは、プロセス間通信（IPC）メカニズムがピア間で通信する方法が異なるためです。
名前付きパイプの場合、通常、ネットワーク通信はよりインタラクティブです。ピアは、別のピアが読み取りコマンドを使用してデータを要求するまでデータを送信しません。通常、ネットワーク読み取りには、データの読み取りを開始する前に、一連の名前付きパイプメッセージのピークが含まれます。これらは低速ネットワークでは非常にコストがかかり、過剰なネットワークトラフィックを引き起こすである可能性があり、これは他のネットワーククライアントに影響を与えます。
ローカルパイプとネットワークパイプのどちらについて話しているかを明確にすることも重要です。サーバーアプリケーションがSQL Serverのインスタンスを実行しているコンピューターでローカルに実行されている場合、ローカルの名前付きパイププロトコルはオプションです。ローカル名前付きパイプはカーネルモードで実行され、非常に高速です。
TCP/IPソケットの場合、データ伝送はより合理化され、オーバーヘッドが少なくなります。データ送信では、ウィンドウイング、遅延確認応答などのTCP/IPソケットのパフォーマンス強化メカニズムも利用できます。これは、低速ネットワークで非常に役立ちます。アプリケーションの種類によっては、このようなパフォーマンスの違いが顕著になる場合があります。
TCP/IPソケットは、バックログキューもサポートします。これにより、名前付きパイプと比較して、SQL Serverに接続しようとしているときにパイプビジーエラーが発生する可能性がある、制限された平滑化効果が得られます。
一般に、TCP/IPは低速のLAN、WAN、またはダイヤルアップネットワークで好まれますが、ネットワーク速度が問題にならない場合は、より多くの機能、使いやすさ、および構成オプションを提供するため、名前付きパイプの方が適しています。
シェルは他のシェルとは何も共有できないため、unix/linuxコンテキストの名前付きパイプを使用して通信する2つの異なるシェルを作成できます。
さらに、同じシェルで2回インスタンス化された1つのスクリプトは、2つのインスタンスを通じて何も共有できません。 start（）およびstop（）関数を含むデーモンをコーディングするときに名前付きパイプの使用法を見つけました。2つのアクションを実行するために同じスクリプトを使用したかったのです。
名前付きパイプ（または任意の種類のセマフォ）がなければ、スクリプトをバックグラウンドで開始しても問題はありません。問題は、それが終了すると、バックグラウンドでインスタンスにアクセスできなくなることです。
したがって、停止コマンドを送信する場合、名前付きパイプなしで同じスクリプトを実行し、実際に別のインスタンスを実行しているため、stop（）関数を呼び出しても何も実行されません。
解決策は、デーモンを起動するときに2つのパイプ、1つは読み取り、もう1つは書き込みを実装することでした。次に、他のタスクの中で、READパイプを聞いてもらいます。次に、Stop（）関数には、パイプにメッセージを書き込むコマンドが含まれています。このコマンドは、終了0を実行するバックグラウンド実行スクリプトによって処理されます。最初のインスタンスに停止するよう指示します。
このようにして、1つだけのスクリプトが自分自身を開始および停止できます。
もちろん、たとえばタッチで停止をトリガーすることで、さまざまな方法でそれを行うことができます。しかし、これは素晴らしく、コードにとって興味深いものです。
名前付きパイプは、プロセス間通信のためのWindowsシステムです。 SQLサーバーの場合、サーバーがクライアントと同じマシン上にある場合、TCP/IPではなく、名前付きパイプを使用してデータを転送できます。