URGフラグがアップしたtcpセグメントには、通常のデータも存在する可能性があります。受信ホストは緊急パケットをどのように処理しますか？それがデータストリームの一部ではない場合、緊急データをどのように認識しますか？それはそれの残りの部分を認めていますか？緊急のtcpデータは確認応答されていますか？
通常は使用されていませんが、両方のホストがURGフラグについて同じRFCをサポートしているとすれば、帯域外データをどのように処理するのですか？
緊急データがアボートメッセージの場合、受信者は他のすべてのデータを破棄しますが、送信者は依然としてメッセージが受信されたことを確認する必要があります。
背景のビット：
はTCP緊急メカニズムは、緊急情報の末尾に指定されるデータ・ストリーム内の点を可能にします。したがって、このtcpセグメントのシーケンス番号からの正のオフセットを含むUrgent Pointerがあります。このフィールドは、URG制御ビットがセットされている場合にのみ重要です。緊急ポインタ約
不一致：
RFC 793（1981、17ページ）：
緊急データに続くオクテット のシーケンス番号に緊急ポインタポイント。
RFC 1011（1987年、8ページ）：
ページ17で間違っています。緊急ポインタは、 緊急データ（非緊急データの最初のオクテットではない）の最後のオクテットを指します。緊急の順序で
最後のオクテット のシーケンス番号に..the緊急ポインタポイント（+ 1続かない）：
RFC 1122で同じこと（1989年、84ページ）データ。
分かりRFC 6093は（2011年、ページ6-7）言う：
は限りTCP送信側とTCP受信機 両方が緊急ポインタのために同じセマンティクスを実装していないがあることを考慮すると 緊急ポインタが「緊急データに続くオクテットの シーケンス番号」対「最後の 緊急データオクテット」を指している点と、既知のすべての実装で緊急ポインタのセマンティクスが「シーケンス 緊急データに続くオクテットの番号 "。
したがって
更新RFC 793、RFC 1011及びRFC 1122は緊急データに続くオクテット のシーケンス番号に
緊急ポインタがあります。
これは事実上すべての既存のTCP実装を満たしています。
注：Linuxでは、デフォルトの動作を上書きするためにnet.ipv4.tcp_stdurgsysctlが提供されますが、このsysctlは着信セグメントの処理にのみ影響します。
は、次の2つの方法で緊急データを得ることができます扱うデータについて793
RFCに指定されているの発信セグメントにおける緊急ポインタがまだ設定されます（心に留めておくことのTCPコンセプト
recvとMSG_OOBフラグセットを使用して、「緊急情報」は、「アウト・オブ・バンド・データ」）としてソケットAPIにマッピングされます。 （通常は、ソケットの所有権をfcntl(sock, F_SETOWN, getpid());のように設定し、SIGURGのシグナルハンドラを確立する必要があります）。したがって、あなたはSIGURGシグナルで通知されます。データは通常のデータストリームとは別に読み込まれます。を使用すると、MSG_OOBフラグが設定されていません。以前は、SO_OOBINLINEソケットオプションように設定する必要があります
int so_oobinline = 1; /* true */
setsockopt(sock, SOL_SOCKET, SO_OOBINLINE, &so_oobinline, sizeof so_oobinline);
のデータは、「インライン」のまま。そして、あなたはioctlの助けを借りて、緊急ポインタを決定することができます。それ以外にも
int flag; /* True when at mark */
ioctl(sock, SIOCATMARK, &flag);
新しいアプリケーションは使用するすべてので緊急データのメカニズムを使用しないため（recommendedですそうであれば）上記のようにインラインで受信する。 RFC 1122から
：
TCP緊急メカニズムは、「アウトオブバンド」 データを送信するためのメカニズムではありません。いわゆる「緊急データ」とは、「インライン」配信されなければなりません TCPユーザー。
RFC 793からまた
：
TCPは、ユーザが、具体的 はあなたが望むように、あなたが扱うことができる緊急データ
保留を通知されると何をするかを定義しようとしません。これはアプリケーションレベルの問題です。
したがって、他のすべてのデータが破棄された場合の謝辞についての回答は、「アプリケーションに実装することができます」です。
tcp-ackに関しては、緊急データの場合には特別なことは何も見つかりませんでした。
「緊急データ」の長さは約
ほとんどすべての実装は、実際には「アウトオブバンドデータ」の1バイトのみを提供することができます。
RFC 6093は述べています：
アプリケーションがによって上書き保留バイト が破棄されることを保留中の「アウトオブバンド」バイト、（すなわち、読み込む前に「緊急データ」の連続表示が受信された場合「緊急の データの新しいバイト」）。
したがって、TCP緊急モードとその緊急ポインタは、実際に緊急データの境界をマーキングすることはできません。
受信したそれぞれの緊急バイトをキューに入れる実装がいくつかあるという噂があります。そのうちのいくつかは、緊急のデータの量に制限を設けず、キューに入れることができないことが知られています。したがって、彼らは些細な資源枯渇攻撃に対して脆弱になります。
P.上記のすべてはおそらく質問された以上のものをカバーしますが、これはこの問題に精通していない人にとっては明らかです。
いくつかのより便利なリンク：
TCP Urgent Pointer, buffer management, and the "Send" call
Difference between push and urgent flags in TCP
Understanding the urgent pointer