54888
ネットワークの通信制御についてです。  
フロー制御は受信側の性能を考慮してパケットを送信しますが、途中の中継機器の性能は考慮してません。これがフロー制御の問題点でもあります。

ではこれに対する対策はなんなのでしょうか？  
フロー制御の欠点を補う技術がネットで調べても見つかりません。  
現状これらの対策などはないのでしょうか？
CC BY-SA 4.0
2019-05-10T13:56:03.843
54874
2019-05-11T07:08:34.147
question
network シリアル通信
フロー制御の問題点について
シリアル通信っつても山ほどありますし何を議題にしているか全くわかりませんが

PC <\--> 対象装置 の場合と  
PC <\--> 中継装置 <\--> 対象装置の場合で  
フロー制御なるものが何か違うのか？ という質問であるとします。

例としてその昔の電話回線を使った Modem + ダイアルアップ接続を考えるとき  
\- 中継装置は Modem  
\- 対象装置はプロバイダのアクセスポイント  
なわけですが、当然 PC-Modem 間にはフロー制御がありますし Modem-
アクセスポイント間にもフロー制御があります（この両者が使う手続きは異なります）。フツーに「フロー制御」という文言を使うときは両端の装置だけでなく途中の装置も対応しておかねばなりません。  
同様 Ethernet HUB においてもフロー制御はあります (IEEE802.3X)  
２０１９年時点で実用されている一般的な通信ハードウエアには「ある」と考えてよいです。

で、もし本当にフロー制御非対応な装置が通信経路の中に挟まったらどうなるか、ですが・・・そのときは途中でデータがあふれるでしょう (OSI
でいうデータリンク層で失敗する) 。

TCP
通信が途中で失敗したらトランスポート層が再試行するでしょう。アプリケーション層から見ると「通信が遅くなった」以外には普段と変化ないはずです。（実用できないほどあふれ続けているなら最終的には「失敗」になります）

UDP 通信が失敗するのはネットワーク層・トランスポート層としては仕様通りです。再試行する必要があればアプリケーション層で再試行するでしょうし (DNS
の解決など) 必要なければスキップして次に進むだけです（ UDP による動画再生等：一瞬画像が乱れても気にしない）

TCP
はエラーが多発したらゆっくりしていってね！になる仕様なので、最終的にはフロー制御がなくても何とかなる程度の速度まで通信を遅くしていくだけだと思われます。
CC BY-SA 4.0
2019-05-11T07:08:34.147
54888
2019-05-11T07:08:34.147
8589
54874
answer