ＴＣＰから上位のアプリケーション層にデータを送る速度はQualnetではどうなっているのでしょうか？
またどこのソースコードをみたらその速度はわかるのでしょうか？

整理を兼ねておさらいをしましょう。

ネットワークからデータが届いてアプリケーションが受け取るまでの流れです。

概念であり実態を正確に表現しているわけではありませんので注意して下さい。
一般的な*nix環境を基にしていますが、Windows環境でも概ね同様の処理です。

1: NetWork
↓
2: NetWork Controller
↓
3: Device Driver
↓
4: IP Protocol Processing
↓
5: TCP Prorocol Processing
↓
6: Kernel to User Memory Copy (mbuf to Buffer)
↓
7: Socket Receive System Call
↓
8: Receive Socket Buffer
↓
9: User Application

実環境においては、1から6まではKernel(OS)内部の処理となります。
また、7から9まではuser空間の処理となります。

『TCPから上位のアプリケーション層』ということであれば、5から9までの流れになります。

ここで、QualNetではどのような処理になっているか考えます。
まず、QualNetは全てUser空間で動作するひとつのアプリケーションです。
したがって、6におけるKernelからユーザ空間へのデータコピーは発生しません。
あくまでもユーザ空間内の単なるメモリ転送が行われます。

つまり単なるメモリ転送なので、処理時間についてはQualNet実行環境のメモリ転送速度に依存します。

さて、QualNetによるシナリオ実行中の話です。
実際の速度については単位時間あたりのデータコピー量を計測して求めることになります。

まず、この単位時間を知るためにQualNet内の時間が必要になります。
QualNet時間については次のAPIを使うことで知ることができます。

getSimTime(node);

次に、データのコピー量ですが、これはデータを受け取るアプリケーション側でも測定可能ですし、
QualNet内のTCPパケットをカウントする方法もあります。

QualNet内のTCPパケットカウントについては次の辺りが参考になると思います。

tcp_input.cppにsubmit_dataという関数があります。
この中に;
msg = MESSAGE_Alloc(node, APP_LAYER, app_type, MSG_APP_FromTransDataReceived);
という記述があり、データを受け取った、という処理に相当する部分です。

また、関数の終わりには;
MESSAGE_Send(node, msg, TRANSPORT_DELAY);
という記述があり、TRANSPORT_DELAYを意図的に発生させています。

参考になりましたか?

『TCPから上位のアプリケーション層』の速度を何のために知りたいのでしょう。
それがハッキリすれば、もう少し具体的なアドヴァイスが出来るかもしれません。

なぜ受信側バッファからアプリケーション層に
送る速度を知りたかったのは、ノードの受信側バッファと送信側バッファでパケットがどう行き来するかを知りたかったからです。

例えば、バッファには３個しかパケットがたまらないとすると
受信側バッファに３個パケットたまっていると、送信側バッファは
受信側バッファにパケットを送れません。
受信側バッファに一個あきがあると、送信側バッファは一個送信できる。
送信側バッファが受信側バッファにあきがあるかを確認できる、
もしくは受信側バッファが送信側バッファにあきがあるのを知らせるプログラムを組みたいんですが、
そこで受信側バッファからアプリケーションに送る速度を知っていれば
このようなプログラムを組めるのではないかと思い、質問しました。

一部引用の順序を変更しています。

> 送信側バッファが受信側バッファにあきがあるかを確認できる、
> もしくは受信側バッファが送信側バッファにあきがあるのを知らせるプログラムを組みたいんですが、

何らかの情報(たとえば受信側バッファ容量,受信側バッファ使用量)を受信側から送信側へ送るわけですね。
これは、受信側がデータを受信した応答として送信側へ応答を返せばよさそうですね。

受信側バッファからからアプリケーションにデータが転送される行為は、アプリケーション側主導で行われます。
したがって、受信側バッファにデータが届きそれがアプリケーションに通知されても、
そのデータが受信側バッファに転送され、結果として受信側バッファに空きができるのはアプリケーション側の処理内容に依存します。

ここで、
> ノードの受信側バッファと送信側バッファでパケットがどう行き来するかを知りたかったからです。

についてですが、ネットワークからデータ届いてアプリケーションまで届く流れについてはすでに紹介させていただきました。
その逆ですが、送信側のアプリケーションからネットワークに流れるまでを同様に記述してみます。

1: User Application
↓
2: Send Socket Buffer
↓
3: Socket Send System Call
↓
4: User to Kernel Copy (Buffer to mbuf)
↓
5: TCP Protocol Processing
↓
6: IP Protocol Processing
↓
7: Device Driver
↓
8: Network Controller

となります。

一般的なTCP/IPであればバッファ制御が動的に行行われます。
まず、mbufをキーワードにしてTCP/IPを調査すると色々なことがわかってくると思います。