新しいプロコトル思いついたんやが

概要：
ネットワーク層のプロコトルであり、接続IDを用いて事前にプロコトルの宣言と、経路制御を行い、ヘッダ情報を大幅に省略することでパケットのサイズを小さくし、より大容量かつ長期の接続を効率よく行える。

接続確立のためのプロコトル：

【接続フロー】

１，接続元(ホストA)から通信規則・経路宣言パケット(以下経路宣言)を接続先(ホストB)へ送信する。
経路宣言は、接続ID、接続元と接続先のIP、相互のポート番号、使用するプロコトル、そして使用する共通鍵を公開鍵で暗号化したもの、自身のホスト証明書及び電子署名を記載する。

２，経路上の機器はパケットを転送しつつ、必要な情報と接続IDを保持しする。各機器が保持するこれを経路情報と呼ぶ。
また、接続ＩＤのコリジョンを検出した場合、転送を止め、パケットが来た反対方向にエラーメッセージを送信し、経路上の機器及び送信元へ接続ＩＤの無効化を伝える。無効化された場合、送信元は新たな接続ＩＤで１からやり直す。

３，接続先(ホストB)へ経路宣言が届いたら、ホストBは内容を記録する。
相互に通信を行わない場合接続承認パケットを送信し、６へ。
相互に通信を行う場合接続日接続関係を入れ替え、１と同じ様に接続元(ホストB)から接続先(ホストB)へ経路宣言を送信する。

４、２と同じ様に経路宣言を転送

５、接続先(ホストA)へ経路宣言が届いたら、ホストAは内容を記録する。
また、ホストBへ接続承認パケットを送信する。


６、接続承認パケットが送信先へ届いた時点で接続は確立される


・接続を拒否する場合および経路宣言の破損があった場合、RSTと任意の切断理由を送信。(ポートスキャンへの悪用については、検出時点で「認証失敗」とかでたらめいえば大丈夫でしょう。攻撃検出時点で切断おパケットなしに関連情報削除しても良いですしね)
・セキュリティについては暗号化と電子署名によって保障する。これは接続確立後についても同じ。

接続確立後の通信プロコトル：

各通信経路の機器が、パケットの接続IDをもとにパケットを転送していく。その他細かいところはより上位層で実装

【パケットの中身】
ヘッダ情報は接続IDのみで構成される。データ部分には、接続時に受け渡しした共通鍵で暗号化したデータと、その電子署名が記載される。


・通信制御は事前に接続IDと経路情報の組み合わせを通信経路に保持する機器が持つため、他のプロコトルに頼らなくてよい。
・それ以外のプロコトルについても、事前に宣言が行われているため個々のパケットで明記しなくてもデコードが可能

質問や詰めの甘いところへの指摘、感想、批評等自由に意見をください。思いつく限り懸念材料は詰めたつもりなので、具体的にここの意見が欲しいって言うのはないですけど、しょせん高１の基本情報に毛が生えた程度の知識なんで見落としは多いと思います。
セキュリティ、ソフトウェア、ハードウェア、ネットワーク、アルゴリズム等の点からの批評、感想、指摘、改善案、追加案などをください！！

TCPすらしならなそう

>>5
TCPくらいは知ってるよ。というか安全な接続の確立のためにかなり参考にさせてもらってるさ。
でもTCPはヘッダ情報削減できないでしょ？

君もできてない

synやackすら知らなさそう

>>8
どう読んだらそういう解釈になるんだろう。
大容量データをフラグメント化して送る際、全体でみるとヘッダ重複するから無駄に多くなるよね。
先にヘッダ情報共有しておいて一意のID振っておけば一つ一つのパケットにはヘッダをほとんど記述せずで通信できるんじゃないのかな
そうできれば何パーセントかパケットサイズ小さく済むよね
そのためにはTCP的な接続フローで相互接続を確立する必要があるよね
という割と単純な話のつもりなのだが

そのフローすら知らないんだろうね君

ルーターやスイッチを殺す気か…？

tcp/ipが設計された意図を知らないでヘッダーガーとか流石に草

世の中が全て専用線ならidすら不要だが、ならばなぜidを振ろうと思うのか？

>>11
それは一理あると思う．．
ただ、経路上の機器は、あるIDのパケットが来たときどのノードに転送するか、さえ記憶できればいいから、最悪機器をアップグレードすれば実現できると予想してる。そこは試算と実験結果からの必要スペック次第かな。

>>12
接続確立時はパケットをどこへ転送するかわからないからIPも使うよ。ただ、その時にIDと転送先のノードの組み合わせを記憶すれば、特定のＩＤのパケットが来たときに転送を行えるでしょう。
接続先と接続元とプロコトルの三つの組み合わせ毎に、仮想的な専用線を、接続時作り上げる＆終了時に解消する、というイメージかな
質問に対する回答としては、どの仮想専用線を利用してるかを識別するために必要だから。

UDPでも使ってろよ

ちなみにUDPを拡張してデータ保証する通信ソフトを富士通が発明していた

UDPとかSCTPとも異なるよ。このプロコトル自体別にパリティビットとかその辺の４層はぶっちゃけどうでもよくて、単に経路情報の共有のために接続に近いことが必要なだけで。
図解しないとわかりにくいかな．．．

全然わかってなくて草
自信があるならこんなとこで喚かずにrfc書くべき。俺の考えた最強プロトコルとか厨二病は要らん。

802.3のEthernetのところだけ読んでても良くこんなもの思いつくなと感心する。
長い研究の果てにosi の概念が構築されてるのに、都合の良いところだけ摘んで経路制御も出来ないプロトコルとか誰得

https://i.imgur.com/Yc18BZn.jpg
すぐに2500P+2500Pが手に入ります。

>>19
もう皆も知ってるが

近距離ならtcpipすら不要
長距離は別

多分1はその概念すら想定できていない

総務省解体