  |
はてなキーワード: パケットとは
急に入院が決まった時に持ち歩いていて役に立ったと思うものシリーズ(わたしの場合)
・格安SIMのちょい低速モードでパケット使い放題のプラン 使用料気にしなくてすむしYouTubeも普通に観られる
・筆記具
ちなみに食器、マスク、ティッシュ、歯磨きセット、タオル、下着以外の衣類はレンタルで賄えた。
下着や洗顔料、化粧水、暇つぶしの本は家族に持ってきてもらったが、そのくらいだったかな。
下着は自分で洗濯したかったので、病院のコンビニで洗剤や洗濯バサミを買って手洗いしました。
・S字フック ゴミ袋をひっかけたくなる、入院生活では絶対に便利だ。
・ハンガー S字フックと組み合わせたら干すの最強なのになぁ、コンビニになかった。
1111の日で遅くなったけどネットワーク機器のログをみたら、
親父が使っているスマホのデータ通信量が数日で10GB越えとかになってて、
流石にこれは異常だろと思っていたら
最近、NHKプラスを垂れ流しにしながら仕事をするようになっていたらしかった。
それで済めば良かったんだが、調べた所、スマホのパケットプランが最大料金になってた。（料金は俺が払っている）
どうやら親父がよく作業しているガレージでWi-Fiが美味く繋がらず（そんなところでハードに使うなんて想定してない）
4Gで接続されているようだった。
固定回線は1Gbpsで十分でせいぜい2.5Gbpsもあれば余裕で暮らしていける
例えばNETFLIXの4K映像でも「推奨速度：15Mbps以上」とか書いてあるぐらいで
10倍の150Mbpsを用意するとして、家の中のテレビ3台動員しても450Mbpsあれば十分
10Gbpsになって速くなったって言ってるやつはベンチマーク測ってるだけか
「自宅に光ファイバーを引いたらインターネットまで専用の光ファイバーが直結される！」
あなたの家の光ファイバーは隣の家とかと共用されていて、時間を区切って使ってる
なので10人いれば10分の1になるし100人いれば100分の1になる
確か最大で128分岐までされてて、その人数で2.4Gbpsを共有してる
NTTが不人気で使ってる人が少ないと1Gbpsが出るけど、人が増えてくると全然出なくなる
関東エリアではNTTが強いから全然速度は出ず、西エリアは競合が多いので逆にNTTのスピードが速い
10Gに変えると当然使ってる人が少ないからスピードは出るけど
そもそも使うアプリ無いから体感できないし、増えてきたら遅くなる
まずパケロスなんて相当なことがないと起きないから
遅延についても、ファイバー分岐で共有してる人数が多いと待ち時間が出るけど
実際には1〜2msぐらいでほぼ関係ない
光の伝送遅延はご存じの通り無視できるレベルで、途中経路の遅延もほとんどない
で、結局は最後のサーバーとかPCでやってる処理で遅延が発生してるっていうだけ
じゃぁなんで10Gbps売ってるのか？っていうと、お前らが買うからだよ！
10Gbpsなんて意味ないって通信業者はみんな知ってたから手を出さなかったんだけど
NUROが勝手に10Gとか2.5Gとか売り出してゴッソリ客を持って行ったわけ
そうすると防衛上しかたなく10Gとか売り出すしか無くて渋々提供してるのが10Gで
計算機科学は、情報の理論的基盤から実用的な応用まで、広範な領域をカバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます。
プログラミングパラダイム: 手続き型、オブジェクト指向、関数型、論理型など。
プロセス管理: 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
ある企業で、サーバ室に設置してたFirewallの電源を「電気代がもったいない」って理由でそこの偉いさんがわざわざoffにして
Firewallってその名の通り壁で、そこがパケットを転送しないのだから、内も外も遮断される
内部では物理的に直結されてて電源オフるとパケットをそのまま横流し「してくれる」の？
これもとからFirewallが機能していなかったとしか思えない
自販機って結構古い機体でも、「釣銭切れ」って売り切れと同義なんよ
ちな海外向けはforceベンドって機能があって釣銭無しでも売るフラグがある
海外で釣銭返ってこないとかの話はこれだと思っている
URI（Uniform Resource Identifier）
URL（Uniform Resource Locator）
大雑把にはそんな感じ
よく、「URIって呼べよ恥かしい」みたいな人いるけど、そっちが恥ずかしいです
例えば、下記のようなURLがあったとして
https://test:testpw@hogehogefugafuga.jp/index.html:8080
① スキーム
② オーソリティ
//test:testpw@hogehogefugafuga.jp/index.html:8080
ポート ：8080
hogehogefugafuga.jp にアクセスしますよぉ、提示した情報でというもの
インターネットを作った人は全世界の人が使うようになる前提で、ややこしいhttp://を決めたのかなぁ？
こんなに使われることになるくらいならもっとシンプルなものにしてた可能性が高かったんじゃないかなと技術脳ゼロの自分は思ってしまうわけです。
すげぇシンプルです
これ以上シンプルにするって逆にどうやるの？
例えばメールサーバーには、「mx」や「mail」などのサブドメインが付きます
これに対して、webサーバーを示すサブドメインとして「www」を使ったわけです
すげぇシンプルです
高校生の頃から登山をしてきた人間として、妥協的解決方法を挙げる。
子供が生まれてからは子供と一緒に行ける日帰り低山しか行かなくなった。低山は人が少ない分、道迷いのリスクはあるが、GPSが発達してきてそのリスクは大分減った。
もちろん、事前の地図読みと、上りの際の分岐確認は写真をとりながらチェック。登山口と下山口が異なる縦走などは極力避けている。
あと、日帰りだと、荒天時はそもそも行かなくなるので、さらにトラブルは少なくなる。
ただ、登山を始めたころは、高い山、有名な山にどうしても登りたくなる。
実際、有名で、沢山の登山者がいる北アルプスの表銀座だって、自分が歩いてきた稜線が円弧を描くように空中に伸びている景色は、自分の体の小ささと、それにもかかわらず、歩き続けられた自分の足の強さを同時に実感できる。
南アルプスの北岳からみた富士山は、山と山のあいだの空気の厚み、上空から地上までの空気の重なりを、青色のグラデーションが教えてくれる、絶景中の絶景だ。
とりあえずの必須条件として、子供用GPSを持たせることと、計画書の提出（所轄の警察と家庭用）から初めてはどうだろうか。
子供用GPSは位置情報を携帯電話のパケットでサーバーに定期的に送る機器だ。電池が長持ちし、自ら電源を切ることができない。保護者（妻）は数分ごとに地図で場所を確認できる。ここ数年で商品が増えた。
主な登山道なら、ほぼ携帯電話の圏内だ。音声メッセージを送ることもできる。月額700円くらいだ。
計画書は登山者のためでもある。ガイドブックを参考にしながらでもいいし、地図を見ながらでもいい。日帰りでも、行動の節目節目で計画した時間通りでなければ、引き返すきっかけになる。
どうしても、日本アルプスなど高山に登りたいなら、小屋泊まりをやめることから提案しよう。１日の行動時間や距離が長くなりがちだし、何かあったときの装備が貧弱になりがち。ウルトラライトは一見機能的だが、トラブルには弱い。あれは体力も経歴も十分な人がやる事だ。
あと、バリエーションルートもだめだ。滑落しやすい場所もふえるし、トラブル時に他人の目がない。登山道も迷いやすい。テントは災害時にも有用だ。（これは山好きが道具を買ったときに家族にする言い訳の典型だが。）
テント泊で夜明け前（夏場なら４時くらい）に歩き出し、10時か11時にはテン場に到着、あとは食事して夕方に寝るような計画にすれば、行動範囲は狭くなるが夕方の道迷いや午後の荒天に遭いにくい。
ご主人は、休みがとれるみたいなので、予備日は必須。焦らないで日程をこなせるようにしよう。自分は雨の日の停滞が意外と好きだった。
あと、冬は絶対ダメ。あと、秋も日が早いから要注意。8月の日照時間は、5月のそれとほとんど変わらない。道迷いは夕方におきる。
さらに、ご主人は、高尾山からスタートだということなので、首都圏在住だと思われるが、関東から東の山は早く日が暮れる（日本標準時で比較した西日本と比べて）。低山で練習したくなる時期の、ちょっと涼しくなる9月は、昼過ぎには登山口に帰るくらいの気持ちでないと危ない。
画面上でできなくしてもサーバーに直接リクエスト送ってくるからって同じことをサーバーでも実装しないといけなくてすごくめんどくさい
言語同じかつ単純な規則な共通化できたりするけど実際はそうじゃないものが多いし
画面での操作禁止とそれらを無視して編集後のデータだけ送ってくるのだとチェックの仕方も違う
追加できないなら追加ボタン出さないだけで済むが、サーバー側だと送られてきた件数だけじゃなくてもともとあったものと一致してるかもチェックが必要とかそういうの
ウェブのほうが楽だからデスクトップアプリからウェブに移すがここ数年は多かったが本当に楽か？って思う
画面の柔軟性はあるが、そのせいであれこれ細かい注文がついたりしてそれも面倒が増える原因だし
ウェブだとそれが当たり前だからってサーバー側もデータのチェックしてるけどデスクトップアプリじゃそんなことしてなかった
それのリプレースなんだし、別にしなくていいんじゃないかと思う
デスクトップアプリだってサーバーと通信してるんだから直接リクエスト投げれるわけだし
ウェブなら便利な開発者ツールがあるから今送ったものの中身を見てちょっとか書き換えて送るが楽なだけ
デスクトップアプリだってパケットキャプチャしたり、逆コンパイルしてソースコード見ればできるわけだし
クライアント証明書があるから～とかいう意見聞いたことあるけど、ローカルにあるファイルなんだから、直リクエストするときだってそれ使えるよね
デスクトップアプリだと起動後のホーム画面から順番にボタンを押さないと画面を開けない
だから一覧画面で編集ボタンを出さなければその項目の編集画面は開けない
そのせいで一覧画面で編集ボタンを出さないのに加えて編集画面で自分が編集可能かのチェックまで必要になる
めんどくさい
考えてみればURLで直接開けることは要件にあるわけじゃないんだし、URLにマッピングしないメモリ内でのルーティングでもいい気はする
リロードすれば毎回トップページに戻るけど普段使う上でリロードなんかしないし別に問題ないと思う
