  |
はてなキーワード: Udpとは
計算機科学は、情報の理論的基盤から実用的な応用まで、広範な領域をカバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます。
プログラミングパラダイム: 手続き型、オブジェクト指向、関数型、論理型など。
プロセス管理: CPUのスケジューリングとマルチタスキング。
機械学習アルゴリズム: 教師あり学習、教師なし学習、強化学習。
深層学習: ニューラルネットワークによる高度なパターン認識。
ネットワークは、情報の共有と通信を可能にする計算機科学の核心的な分野です。
OSI参照モデル: ネットワーク通信を7つのレイヤーに分割し、それぞれの機能を定義。
プレゼンテーション層: データ形式の変換。
アプリケーション層: ユーザーアプリケーションが使用するプロトコル。
TCP/IPモデル: 現実のインターネットで使用される4層モデル。
リング型: 各ノードが一方向または双方向に隣接ノードと接続。
IP（Internet Protocol）: データのパケット化とアドレッシング。
TCP（Transmission Control Protocol）: 信頼性のある通信を提供。
UDP（User Datagram Protocol）: 信頼性よりも速度を重視した通信。
ルーター: 異なるネットワーク間のパケット転送とルーティング。
IDS/IPS（侵入検知/防止システム）: ネットワーク攻撃の検出と防御。
VPN（仮想プライベートネットワーク）: 安全なリモートアクセスを提供。
SDN（Software-Defined Networking）: ネットワークの柔軟な管理と制御。
IoTプロトコル: MQTT、CoAPなどの軽量プロトコル。
SNMP（Simple Network Management Protocol）: ネットワークデバイスの管理。
ネットワークトラフィック分析: パフォーマンスとセキュリティの最適化。
ネットワークオーケストレーション: 自動化された設定と管理。
AIによるトラフィック最適化: パフォーマンスの向上と障害予測。
マイクロセグメンテーション: ネットワーク内部の細かなアクセス制御。
『コンピュータネットワーク』 アンドリュー・S・タネンバウム著
『ネットワークはなぜつながるのか』 戸根勤著
Coursera: 「コンピュータネットワーク」、「ネットワークセキュリティ」コース
edX: 「Computer Networking」、「Cybersecurity Fundamentals」
IETF（Internet Engineering Task Force）: ietf.org
IEEE Communications Society: comsoc.org
W3C（World Wide Web Consortium）: w3.org
要するに1Gbpsと10Gbps論争
最近は10Gbpsを諦めて2.5Gbpsになってきているので、1Gbps越え論争の方が正しい
5/10Gbps提供はかなり広まっているのでここはそんなに問題無い
価格も1Gbpsと大して変わらない
実測としては10Gbpsは絶対に出ないが、2〜3Gbpsなら出る
ただし、それはスピードテストをしたときの話であってEnd-to-Endでそれだけでるかどうかは全く別の話になる
10Gbpsは依然としてまだまだだが、1Gbpsを越えるという意味では使えるようになってはいる
またType-C接続のRJ-45ドングルも2.5Gbps対応が出てきている
ノートPCだけでなくスマホでもWiFi 6（11ax）対応が増えてきている
11axなら理論上は最大9.6Gbps使えるが、これは160MHz帯域を8本同時利用した場合で、そんなPCは無い
現状では2本同時利用なので2.4Gbpsが上限となるので、1Gbps越え通信は可能である
本題のアプリケーションだが、単体で1Gbpsを越えるような通信をするアプリケーションは存在しない
8K映像を非圧縮で送れば72Gbps必要だがH.265だとせいぜい100Mbps、将来的な規格では50Mbpsほどまで圧縮できる
10部屋あって全員が8K映像を同時視聴すれば1Gbpsを越えるかもしれない
オンラインゲームでは遅延を嫌ってUDPでバカスカ送ることもあるが、それでも100Mbpsもあれば十分である
非圧縮で送るとコーディング遅延がなくなるが、そもそも伝送遅延がバカみたいに大きいので圧縮しても大差が無い
一方でファイルなどの送受信では帯域幅がそのままダウンロード・アップロード時間に直結する
5GBのイメージをダウンロードする時間は1Gbpsから2.5Gbpsにすればまぁ半分ぐらいにはなる
オンラインストレージをバカスカ使う人にとっては1Gbps越えが魅力的に思えるのだが
実際にはソフトウェア側の工夫（キャッシュなど）によってそれを体感できるかどうか怪しい
実際にDropBox, iCloudやOneDriveはどれもよくできているので帯域幅による違いを感じにくい（細すぎるとダメダメだが）
モデムで28.8kbpsで頑張っていた頃は1Mbpsも出れば夢のような未来が待っているという期待があった
ADSLで1〜10Mbpsもつかえ始めると「1Gbpsも使えるの？」と思っていたが実際には10Mbps越えの通信は十分に需要があった
なので今、「1Gbps以上必要あるの？」と思っていても、将来的には必要になるかも知れない
否定はしないが、1〜10Mbpsの頃から4Kや8Kの話やクラウドストレージのような話はあって
将来的に1Gbpsが使えたときの利用方法は山のように案があった
今、10Gbpsの利用法として合理的なものは知る限り全くない
特にコーディングに関する技術が進みすぎて映像伝送に帯域が不要となったのが大きいように思う
何より1Gbpsの状況が10年以上続いているのが好例だと思う
特に5Gでモバイル網のスピードが固定網に追いついてしまっているので
ハンドオフ等を考えれば全て5G（もしくは6G）でカバーする方が接続性・速度ともに満足度が高い
5Gアンテナを多人数で共有している限りは速度上昇は見込めないので
この業界に求められているのは5GC内蔵の屋内5GプライベートアンテナをeSIM認証で自由にハンドオフできる世界線だと思う
PCにeSIMが入るようになれば屋内でも屋外でもシームレスにネットワーク接続できるし
スタバでWiFiに繋がらなかったりドコモフリーWiFiに勝手に繋がってLINEが来ない、という未来もなくなる
ただ、そのときであっても家庭の屋内配線は1Gbpsで十分である
マンションや店舗のように複数人で共有するなら当然1Gbps以上の回線が必要だが、伝送距離を考えればファイバーの方が有利である
ネットに公開されている情報は、初心者には難しいと感じました。
Yamahaのサイトにconfigは公開されていますが、exciteMEC光だと、クリアする注釈が多すぎて。
"NVR500 では、tunnel endpoint address コマンドを使用して、AFTR の IPv6アドレスを指定してください。"
って書いてますが、exciteMEC光はAFTR公開してないぞ！ってなるので。
正解は[gw.transix.jp]のIPv6アドレスを指定する、で
"tunnel endpoint address 2404:8e01::feed:101"です。
以下、全文。
#
# transixのIPv4接続（DS-Lite）でインターネット接続
#
#
#
#
# ゲートウェイの設定
#
ip route default gateway tunnel 1
#
#
ip lan1 address 192.168.100.1/24
#
#
ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan2 dhcp service client ir=on
ipv6 lan2 secure filter in 1010 1011 1012
ipv6 lan2 secure filter out 3000 dynamic 100 101 102 103 104 105 118 119
#
# トンネルの設定
#
tunnel select 1
tunnel endpoint address 2404:8e01::feed:101
tunnel enable 1
#
# フィルターの設定
#
ipv6 filter 1010 pass * * icmp6 * *
ipv6 filter 1011 pass * * tcp * ident
ipv6 filter 1012 pass * * udp * 546
ipv6 filter 3000 pass * * * * *
ipv6 filter dynamic 100 * * ftp
ipv6 filter dynamic 101 * * domain
ipv6 filter dynamic 102 * * www
ipv6 filter dynamic 103 * * smtp
ipv6 filter dynamic 104 * * pop3
# ipv6 filter dynamic 105 * * submission
ipv6 filter dynamic 118 * * tcp
ipv6 filter dynamic 119 * * udp
#
# DHCPの設定
#
dhcp service server
dhcp server rfc2131 compliant except remain-silent
dhcp scope 1 192.168.100.2-192.168.100.191/24
#
# DNSの設定
#
はてな匿名ダイアリーってデフォルトの文字が小さすぎる。しかも、幅が広すぎて、読みやすい幅に上限設定されてない。
:root { --main-font-family: 'BIZ UDPゴシック' } div.day { max-width: 100ch; } div.day p { line-height: 3.5rem; font-size: 1.25em; font-family: var(--main-font-family); } div.day div.section ul li, div.day div.section ol li{ line-height: 3rem; font-size: 1.25em; font-family: var(--main-font-family); } #text-body { line-height: 3rem; font-size: 1.3em !important; font-family: var(--main-font-family); } .main-content .card-text p { font-size: 1.8rem !important; font-family: var(--main-font-family); }
真に許されざるのはMS明朝，游明朝，游ゴシック，おまえらだ。
細すぎるんだよ。線が。画面でも紙でも見えにくい。ユニバーサルデザインを何と心得るか。
そうすると1kmは5μsだとすぐに分かるし、1000kmで5msです。（単位を上げるだけ）
東京-大阪間はざっくり500kmなので2.5msで到達できます。
片道の遅延を計測するのは難しいのでpingで往復を測ると5msぐらいです。
実際にはルーターを通過する時間なんかがあるので10msとかになったりします。（30msはちょっと遅い気がする）
ちなみにLTEとかWiFiを挟むと平気で100msぐらい増えます。
電波は共有資源なので誰かが使ってる間は使えないから、使えるようになるまで待つからです。
待ち時間が100msとかになります。5GとかWiFi6はその辺が早かったりします。
東京-サンフランシスコ間だと8000kmぐらいあるので40msです。往復で80msなので、まぁ100msぐらいです。
TCPの場合は送信前に3wayハンドシェイクっていうのをするので2往復ぐらい事前にやりとりします。
なので200msecぐらいかかりますが、最近はFast Openっていうのもあるので多分もっと早いです。
1GBのデータを送るとして、送り始めの先頭データが到達するのにこれだけの遅延がかかります。
1byteだけ送って、届いた確認が来たら次の1byteを送って・・・なんてやってたらいつまで経っても送れないので
届いてるかどうかは後回しにしてとにかくドンドン送るとします。
この場合、1GBのデータを送り終わるまでかかる時間は、使える帯域によって変わります。
1Gbps使えるなら、1GB送るのにざっくり8secの計算になりますが、まぁ諸々あってそんなわけはなくてもうちょっとかかります。
ちなみにUDPの場合、使える帯域以上にデータを送ると途中で捨てられるだけです。
パケットなので順番が逆転する可能性もありますが、それでも気付かずそのまま送ります。
TCPだと途中で「ここまでOK？」っていう確認をするのでその分の遅延が入りそうですが、SACKっていう仕組みで良い感じに遅延が少なく通信できます。
NUROでパケロスが酷いっていうのは問題だし対処してほしいけど
「パケットを破棄するなんて許せない」とか言ってるアホはインターネットを最初から勉強し直してこい
「UDPのパケットを落としてるのは問題」とか言ってるアホもL4の勉強やり直してこい
TCPが遅いだのなんだの文句付けてUDPでネットワークリソースを消費しておいて
いざUDPが輻輳したらNUROに文句言うとかお門違いにもほどがある
文句を言う先は任天堂だし任天堂はまともなネットワークエンジニアを雇えよ
今時のゲームはUDPで冗長に送るのがデフォだし輻輳制御とか全然考えてないから絞られて文句言う方がおかしいわ
ゲームじゃなくて仕事で使ってる人からすれば「そんなクソUDPパケットはバカバカ落としてしまっていい」っていう感じだし
TCPみたいなフェアネス考えてないパケットはもうガッツリブロックしていいんだよ
伸びててワロタ
1Gの先に100Mの回線繋がってたら「90%もパケロスしてる！」って騒いでるようなもん
送ってる奴が悪いに決まってるだろ
もちろんそんな単純な話では無いんだけど輻輳の原因がスプラで制御してくれないならUDP狙い撃ちで落とすしかないでしょ
他の人が困るんだからそれでいいし、パケロスしてても完全ブロックじゃないんだから端末側でどうにかせーよっていうのがインターネットですよ
まぁそもそも「ベストエフォート」っていう単語が良くないと思う
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
