UDPホールを成功裏に実行しました[再版]

この検査のパラメータ:
サーバーはパブリックネットワーク上の固定IPです。 2つのクライアント、AとBは異なるコンピュータ、異なるブロードバンド、異なるルーティングモデル(1つのホームルート、1つのエンタープライズルート)の背後に配置されており、ルートは特別に設定されていません。
このテスト自体に特別なものはなく、オンラインのデータによると実験自体が特別なものです。 以下に示すように:

説明：
A側がUDPを使ってサーバーにパケットを送信すると、サーバー側はA側のIPとポートを取得します:xxx.xxx.xxx.101:5841
B側がUDPを使ってサーバーにパケットを送信すると、サーバー側はB側からIPとポートを取得します:xxx.xxx.xxx.105:12584
この時点で、AとBの両端でのルーティングは、AとBと外部に通信するためのチャネルを開くのと同等です。 サーバーはAとBと通信できるだけでなく、チャネルが開いているため、次のようになります。
AはBが開いたチャネルに直接メッセージを送信できます(B=xxx.xxx.xxx.105:12584)。
同じです:
Bはまた、Aが開いたチャネル(A=xxx.xxx.xxx.101:5841)に直接メッセージを送信することも可能です。

注:AとBの間に通信の順序があるようですが、忘れていました~とにかく送ってください

最後に、UDP通信は場合によってはTCPよりも少し「感度が高い」ことがあります(少し違うかもしれませんが、どう説明すればいいかわかりません)。
例えば、ブロードバンドは正常にダイヤルしてもTCPがサーバーに接続できず、ブラウザがウェブページを開いてしまい、TCPが正常に通信するまでに長い時間がかかることがあります。
TCP接続できない期間中はUDPが正常です。
しかし、UDPの使用は決して手間がかからない作業ではありません:
--合理的なパッケージプロトコルを設計する必要があります
--情報の完全性が必要な場合は再送信が必要です
--TCPには高い適応性要件が必要
現在のネットワーク環境は比較的良好で、UDP送信の成功率は98%、99%、あるいはそれ以上に達することもあります(十分なテストはしていませんが、ただ感じています)。

当時の複雑で不安定なネットワーク環境において、QQは主要な通信プロトコルとしてUDPを選択しましたが、同時期にICQとMSNは主にTCPでした。
模倣とは、従って遅れを取ることではなく、古い枠組みのもとに新しい思考を注入できることが重要です。 これも馬の成功の必然的な要素の一つであるべきです。