  |
はてなキーワード: tcpとは
「HTTPS時代においては、HTMLコメントへのNGワード挿入によるGFW（金盾）ブロックは機能しない」という意見は、技術的に完全に正しい認識です。
1. なぜ「HTTP時代」は有効で「HTTPS時代」は無効なのか？
かつてHTTPで通信していた頃、GFWはパケットの内部（HTMLのレスポンスボディ）をリアルタイムにスキャンするDPI（Deep Packet Inspection: 深層パケット検査）を行っていました。
ユーザーがWebページを閲覧すると、サーバーから送られてくるHTMLデータの中に「六四天安門」などの検閲ワードが含まれているかをGFWが途中のルーターで検知。
検知した場合、GFWが即座に偽のTCP Reset (RST) パケットを注入し、接続を強制切断（ブロック）していました。
そのため、HTMLのコメントアウトであっても「文字列として通信上を流れていた」ため、ハックとして実際に効果がありました。
現在主流のHTTPS通信では、サーバーとブラウザの間でTLS暗号化ハンドシェイクが完了した後のデータ（HTML本文、ヘッダー、コメントなど一切）は、完全にエンドツーエンドで暗号化されます。
クライアント <--- [平文: <html></html>] ---> サーバー
クライアント <--- [暗号化データ: 8f3a9b...（読めない）] ---> サーバー
GFWなどの途中のネットワーク機器（Middlebox）は、暗号化を復号する鍵を持っていないため、HTMLコメントに何が書いてあっても読み取ることができません。
現在GFWがHTTPS通信をブロックする主な対象は、以下の暗号化される前の情報です。
SNI（Server Name Indication）: TLS接続開始時に平文で送られる「アクセス先のドメイン名」
IPアドレス / ASN: サーバーのIPアドレスそのものをブラックリスト化して遮断
DNS汚染（DNS Poisoning）: そもそもドメインからIPアドレスへの変換を妨害する
したがって、特定のドメイン自体がGFWにマークされていない限り、HTML内のコメント文言によって自動的にブロックされることはありません。
2. HTTPS時代に効果的な「中国からのスパム（迷惑アクセス）回避策」
暗号化時代において、サーバー側のリソースを無駄にせずシンプルかつ強力に効果を発揮するスパム回避策は以下の通りです。
① GeoIPによる国別IPブロック（最もシンプルかつ強力）
中国国内からの正規アクセスや集客が不要なWebサイトであれば、「中国（CN）のIPアドレス帯からの接続をすべて遮断する」のが最も確実です。
Firewall / OSレベル（iptables / nftables + ipset）:
ipdeny や MaxMind GeoLite2 などのデータベースから中国（CN）のIPリストを取得し、OSのファイアウォールでドロップします。
ngx_http_geoip2_module などを使い、国コードが CN の場合に 403 Forbidden を返すか接続を破棄します。
② CloudflareなどのクラウドWAF / CDNの導入
自作サーバーの前段にCloudflare（無料プランで十分対応可能）などのCDNを挟む方法です。
「Country == China だったらブロック」または「Turnstile（キャプチャ認証）を要求する」といったルールを数クリックで設定できます。
メリット:
悪質なBotやスパムアクセスが自作サーバーのNICやCPUに到達する前（Cloudflareのエッジサーバー上）で遮断されるため、サーバーの帯域やリソースを消費しません。
③ 中国系ASN（事業者のネットワーク識別番号）単位のブロック
中国からのスパムは、一般家庭の回線からだけでなく、中国の主要クラウド事業者（Alibaba Cloud, Tencent Cloud, Baidu Cloud等）や通信キャリア（China Telecom, China Unicom, China Mobile）のデータセンターIP帯からプログラム（Bot）で大量に実行されるケースが非常に多く見られます。
クラウド事業者（例: Alibaba Cloud = AS37963, AS45102 など）のASNごとブロックすることで、海外プロキシを経由した悪質なクローラーもピンポイントで弾くことができます。
まとめ
HTMLコメントハック: HTTP時代には有効だったが、HTTPS時代は暗号化されているため効果なし。
現代の推奨対策: クラウドWAF（Cloudflare等）を利用した国別（GeoIP）ブロックやASN指定のアクセス制限が、費用もかからず最もシンプルかつ効果的です。
資格取得向けではない
賛否両論もあると思うが、IT系現場で働いていたり交流すると話に上がる本がメイン
勉強ももちろんだが、現場の話題についていくという点において読んでおいて損はなさそう
| 書籍 | 主なテーマ | 現在の位置づけ |
| ------------------------ | -------------------- | -------------- |
| 人月の神話 | ブルックスの法則、概念的完全性、銀の弾丸 | ソフトウェア工学の最重要古典 |
| ピープルウエア | 生産性、組織、作業環境、チーム形成 | 開発組織論の古典 |
| 達人プログラマー | 技術者の姿勢、抽象化、自動化、変更容易性 | 現代でも読みやすい準古典 |
| Code Complete | コーディング、設計、レビュー、品質 | 実装技術の百科事典 |
| ソフトウェア作法 | UNIX的なプログラム設計と思考法 | プログラミング文化の古典 |
| プログラミング作法 | 命名、デバッグ、テスト、性能、移植性 | C中心だが原則は普遍的 |
| 珠玉のプログラミング | アルゴリズム的問題解決 | 計算量・問題分解の古典 |
| 計算機プログラムの構造と解釈 SICP | 抽象化、評価、言語処理系 | コンピュータ科学寄りの古典 |
| 書籍 | 内容 |
| ------------------------------------------------------- | ------------------- |
| リファクタリング 第2版 | 振る舞いを変えずに内部設計を改善する |
| レガシーコード改善ガイド | テストのない既存コードを安全に変更する |
| Clean Code | 命名、関数、クラス、可読性 |
| テスト駆動開発 | TDDの基本的な進め方 |
| Growing Object-Oriented Software, Guided by Tests | テストからオブジェクト設計を成長させる |
| Working Effectively with Unit Tests | 単体テストの設計とテスト容易性 |
| A Philosophy of Software Design | 複雑性を減らす設計 |
| The Programmer’s Brain | コードを読むときの認知負荷 |
| 書籍 | 位置づけ |
| --------------------------------- | ------------------ |
| オブジェクト指向における再利用のためのデザインパターン | GoFデザインパターンの原典 |
| Head Firstデザインパターン | パターンの入門書 |
| アジャイルソフトウェア開発の奥義 | SOLID、パターン、アジャイル設計 |
| エンタープライズアプリケーションアーキテクチャパターン | 業務アプリの設計パターン |
| 実践UML | オブジェクト指向分析・設計 |
| オブジェクトデザイン | 責務駆動設計 |
| 書籍 | 内容 |
| ------------------------------------------- | ------------------- |
| ソフトウェアアーキテクチャの基礎 | アーキテクチャ特性、スタイル、意思決定 |
| ソフトウェアアーキテクチャ・ハードパーツ | 分割、粒度、データ、トレードオフ |
| Clean Architecture | 依存関係、境界、ユースケース |
| エンタープライズアプリケーションアーキテクチャパターン | 業務システムの設計パターン |
| Domain-Driven Design | 複雑な業務領域のモデル化 |
| 実践ドメイン駆動設計 | DDDの実践的な適用 |
| Building Evolutionary Architectures | 変更可能なアーキテクチャ |
| Fundamentals of Software Architecture | 現代アーキテクチャの概論 |
唯一の正解ではない
「依存関係を内側に向ける」「業務ルールをフレームワークから分離する」という考え方を学ぶ本であり、すべてのアプリを同じ円形の構造にする本ではない
| 書籍 | 内容 |
| ------------------------------------------- | -------------------- |
| データ指向アプリケーションデザインDDIA | DB、分散処理、一貫性、レプリケーション |
| 分散システムタネンバウム | 分散システム全般の教科書 |
| Designing Distributed Systems | 分散システムの設計パターン |
| Release It! | 本番障害、安定性、回復性 |
| Site Reliability Engineering | SRE、SLI、SLO、運用 |
| Building Secure and Reliable Systems | セキュリティと信頼性 |
| Web Scalability for Startup Engineers | Webシステムのスケーリング |
| System Design Interview | システム設計の考え方を広く学ぶ |
| 書籍 | 内容 |
| -------------------------------- | ----------------- |
| マスタリングTCP/IP 入門編 | 日本で最も定番のTCP/IP入門書 |
| コンピュータネットワークタネンバウム | ネットワーク全般の教科書 |
| コンピュータネットワーキング トップダウンアプローチ | アプリケーション層から学ぶ |
| ネットワークはなぜつながるのか | ブラウザからサーバーまでの流れ |
| 書籍 | 内容 |
| ----------------------------------------- | ------------------- |
| 詳解TCP/IP | TCP/IPの古典 |
| TCP/IP Illustrated | パケットレベルの詳細 |
| High Performance Browser Networking | TCP、TLS、HTTP、ブラウザ通信 |
| パケットキャプチャの教科書 | Wiresharkなどを使った解析 |
| 書籍 | 内容 |
| -------------------------------- | ---------------- |
| Real World HTTP | HTTPの歴史と現代的機能 |
| Webを支える技術 | HTTP、URI、REST |
| HTTP: The Definitive Guide | HTTP/1.1時代の体系的解説 |
| Web API: The Good Parts | Web API設計 |
| 書籍 | 内容 |
| -------------------------------- | --------------- |
| オペレーティングシステム 3つの簡単なピースOSTEP | 仮想化、並行性、永続性 |
| Operating System Concepts恐竜本 | OSの標準的教科書 |
| 詳解UNIXプログラミング | UNIXシステムコール |
| Linuxプログラミングインタフェース | Linux APIの詳細 |
| Linuxのしくみ | Linux内部の入門 |
| ふつうのLinuxプログラミング | Linux上でのプログラム実行 |
| 30日でできる！OS自作入門 | OSの動作を作りながら学ぶ |
| コンピュータシステムの理論と実装Nand2Tetris | 論理回路からOSまで |
| 書籍 | 内容 |
| ------------------------------ | --------------- |
| データベースシステム | DB理論の教科書 |
| Database System Concepts | DBの標準的教科書 |
| SQLアンチパターン | よくあるDB・SQL設計の失敗 |
| 達人に学ぶDB設計 徹底指南書 | 論理設計、正規化、性能 |
| 達人に学ぶSQL徹底指南書 | SQLの考え方 |
| SQLパフォーマンス詳解 | インデックスと実行計画 |
| High Performance MySQL | MySQLの性能設計 |
| PostgreSQL徹底入門 | PostgreSQL固有機能 |
| 書籍 | 内容 |
| ------------------------------------------- | -------------- |
| 体系的に学ぶ 安全なWebアプリケーションの作り方徳丸本 | Webセキュリティの国内定番 |
| Web Application Security | Webアプリの脆弱性と防御 |
| The Web Application Hacker’s Handbook | Web攻撃手法の古典 |
| Security Engineering | セキュリティ工学全般 |
| 暗号技術入門 | 暗号、ハッシュ、署名、証明書 |
| マスタリングTCP/IP 情報セキュリティ編 | ネットワークセキュリティ |
| Threat Modeling | 脅威モデリング |
| Building Secure and Reliable Systems | セキュアで信頼できる運用 |
| 書籍 | 内容 |
| ------------------------------------ | -------------- |
| アルゴリズムイントロダクションCLRS | アルゴリズム分野の標準教科書 |
| アルゴリズムとデータ構造 | 大学教科書的な基礎 |
| 珠玉のプログラミング | 問題解決の古典 |
| プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 | 実装を伴う学習 |
| 問題解決力を鍛える！アルゴリズムとデータ構造 | 日本語での実践的入門 |
| The Algorithm Design Manual | 問題に適したアルゴリズム選択 |
| 書籍 | 内容 |
| --------------------------- | ------------- |
| テスト駆動開発 | TDDの原典 |
| ソフトウェアテスト技法ドリル | 同値分割、境界値など |
| はじめて学ぶソフトウェアのテスト技法 | テスト技法の定番 |
| 実践ソフトウェアエンジニアリング | 開発工程と品質全般 |
| Googleのソフトウェアエンジニアリング | 大規模開発、テスト、保守 |
| 単体テストの考え方／使い方 | 良い単体テストの設計 |
| xUnit Test Patterns | テストコードのパターン集 |
| Continuous Delivery | 自動テストからリリースまで |
| 書籍 | 内容 |
| ----------------------------------- | ------------------ |
| The DevOps ハンドブック | DevOpsの実践体系 |
| Accelerate | 開発組織とデリバリー性能の研究 |
| Continuous Delivery | 継続的デリバリーの原典的書籍 |
| Site Reliability Engineering | GoogleのSRE |
| The Site Reliability Workbook | SREの実践 |
| LeanとDevOpsの科学 | Accelerateの日本語版 |
| Infrastructure as Code | IaCの原則 |
| Kubernetes Patterns | Kubernetes上の設計パターン |
| Release It! | 本番耐性と障害対策 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
| Kubernetes完全ガイド | Kubernetesの体系的な理解 |
| Kubernetes Patterns | Kubernetesの設計パターン |
| 入門 Kubernetes | Kubernetesの概念 |
| Docker系の入門書 | コンテナの操作 |
| Infrastructure as Code | インフラのコード化 |
| Cloud Native Patterns | クラウドネイティブ設計 |
| クラウドデザインパターン | クラウド上の設計パターン |
AWS、Azure、Google Cloudについては、以下を優先する
| 書籍 | 内容 |
| ------------------------------------- | -------------- |
| 要求工学系の教科書 | 要求の抽出・分析・管理 |
| ソフトウェア要求 | 要求定義の体系 |
| ユーザーストーリーマッピング | ユーザー行動と開発計画 |
| ユースケース実践ガイド | ユースケース記述 |
| RDRA2.0ハンドブック | 要求とシステム構造の整理 |
| 実践ドメイン駆動設計 | 業務モデリング |
| Domain Modeling Made Functional | 型を使ったドメインモデリング |
| イベントストーミング | 業務知識の探索 |
| 書籍 | 内容 |
| ------------------------- | ------------ |
| 誰のためのデザイン？ | 人間中心設計の古典 |
| インタフェースデザインの心理学 | 認知心理とUI |
| ノンデザイナーズ・デザインブック | レイアウト・配色・文字 |
| Don’t Make Me Think | Webユーザビリティ |
| About Face | インタラクションデザイン |
| デザインシステムの育て方 | デザインシステム |
| Lean UX | 仮説検証型のUX開発 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
ある伝説によると、とある国のとあるプログラマーの退職後に残ったスクリプトを社員が見たら、恐ろしいレベルで自動化してたそうだ
https://github.com/NARKOZ/hacker-scripts
うちのビルドエンジニアが別の会社に行った。あの男は文字通りターミナルの住人。Vimを愛用して、Dotで図を作成し、Markdownでwiki記事を書くようなタイプ。
どんなものでも、90秒以上かかるならそれを自動化するスクリプトを書く奴。
それで今、我々は奴の「遺産」を見ているわけだ。
これ、お前も気に入ると思うぞ。
奥さんに「仕事で遅くなる」というテキストメッセージを送る。文字列の配列から理由をランダムに自動で選ぶ。cronジョブとして動作。奴のアカウントで午後9時以降にサーバーでアクティブなSSHセッションがある場合にジョブが実行される。
「Kumar」（うちのクライアント）からのメールを受信箱でスキャン。「help」、「trouble」、「sorry」などのキーワードを探す。キーワードが見つかると、スクリプトはクライアントのサーバーにSSH接続し、ステージングデータベースを最新のバックアップにロールバックする。「直したぞ。次からは気を付けろよ」という返信を送る。
特定の日に設定された別のcronジョブ。「体調が悪い/家で仕事をする」といった自動メールを送る。別の事前定義された文字列の配列からランダムな「理由」を追加。午前8時45分にサーバーで対話型のセッションがない場合に実行。
正確に17秒待ってから、うちのコーヒーマシンにtelnetセッションを開き（コーヒーマシンがネットワークに繋がっていて、Linuxが動いていて、TCPソケットが立ち上がっているなんて、誰も知らなかった）、sys brewのようなコマンドを送る。判明したところ、これでミディアムサイズのハーフカフェラテを淹れ始め、カップに注ぐまでさらに24秒待つ。この時間は、奴のデスクからマシンまで歩くのにかかる時間と完全に一致している。
もうアラフォーになるんだけど、でも、夢は捨てきれていない。
劣っている自分でも、プログラミングなら負けないと言えるようになりたかった。
諦めればいいんだけど、でも、自分にはプログラミングしかない。
「コンピューターサイエンスのすべての分野に精通」してないのを恥じている。
いや、「インフォメーションエンジニアリングのすべての分野に精通」してないのも恥じている。
全部を上手くできない自分が、ただただ劣っていて嫌で仕方がない。
「コンピューターサイエンスのすべての分野に精通」している人がいるなかで、自分ができてないのが嫌になる。
なんで、自分にはできないんだと永遠に責め続けてしまう。できる人がいるのに、どうして自分にはできないのか。
全部できていたい、なんで全部できていないのか、それが自分の頭の問題だということを受け入れたくない。
UT入ってIS行くような人ができることが出来ないことに勝手に差を感じてる。
プログラミングが得意になるように頑張った。
お前は劣っているのだから、要領よく文系としては生きられないからと。
しかし、だからといってあきらめたくない。全部上手くできるようになりたい。
少しづつあがいてるけど、結局、やることなすことうまくいかない。
React/Vueみたいなフロントエンドフレームワークも作れてない。
出来てないことだらけなのに、まだ挑戦していたいと思ってしまう。
たぶん、脳の病気なんだと思うけど、でも、やめたくない
一等賞になれないのだろうけど、でも、一等賞を目指したくなる
テスラの「Sr. Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | What You’ll Do | What You’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800 USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| Woven by Toyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterprise AIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | Fuyao AI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
提示してる「そうめんでいい」バリアントの発話仕様、あれってコミュニケーション・レイヤーでいうと意味論的優先度フィールドがゼロ初期化されてるパケットなんだよな。
で、そのゼロ初期化パケットが相手の感情OSに到達すると、そこに実装されてる価値評価アルゴリズム（通称 Pride-Driven Interaction Protocol）が、受信値を「非積極的承認」としてパースする。
つまり、入力信号の中に“熱量ビット”が存在しないと、即座にException: DEVALUATION_ERRORがスローされる仕様なんだわ。
その例外は通常のtry-catchでハンドリングされず、感情カーネルを通じてフロントエンドの態度・表情UIに直結するから、結果的に「何様だよ」っていう可視化出力が生成される。
さらに、相手の感情モジュールは言語的同値判定じゃなくて意図ベースのベクトル比較を行ってるから、
「そうめんがいい」(積極的選好ベクトル) と 「そうめんでいい」(受動的妥協ベクトル) は、同一文字列近似度99%でも意味論距離が閾値越えしてエラー扱いになる。
これを無視して「ただの晩飯APIコール」だと軽視するのは、TCPレベルのパケットロスを「まぁ届くっしょ」で放置するようなもんで、
通信の確実性よりも自己CPUサイクルの節約を優先する、お前側のシステム設計思想が原因なんだよな。
結局のところ、感情という非決定性システムに対して最適化パラメータ調整を怠ってる時点で、お前の通信モデルは高確率でクラッシュを引き起こす。
もし稼働安定性を確保したいなら、相手のEmotional API Referenceを逆コンパイルして、推奨トークン列を生成するスクリプトを実装すべきだわ。
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらく TCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前に HTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えば anond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見える client IP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2035 | 日本料理大全/JAPANESE CUISINE ｜ 京都府立大学 | www.kpu.ac.jp |
| 970 | Mac やめて Linux PC を自作した - IT戦記 | amachang.hatenablog.com |
| 811 | 科学的根拠に基づく「健康に良い食事」について｜国立健康・栄養研究所 | www.nibiohn.go.jp |
| 806 | 50代、「1日1捨」を11か月続けて革命が起きた。ものが減る以外の絶大の効果も ｜ ESSEonline（エッセ オンライン） | esse-online.jp |
| 768 | コイン電池、交換不要に 業界初の自立給電型開発 CR2032代替 SMK ｜ 電波新聞デジタル | dempa-digital.com |
| 729 | Google Playの住所公開に開業届で対応する | blog.mrym.tv |
| 607 | 人間をリソースと呼ぶことの何が問題なのか - valid,invalid | ohbarye.hatenablog.jp |
| 581 | 京都府立大学、『日本料理大全』のデジタル版を一般公開 | current.ndl.go.jp |
| 551 | 勉強から研究へ | member.ipmu.jp |
| 514 | 出版のお知らせ 「普通の人が資産運用で99点をとる方法とその考え方」 - hayato | hayatoito.github.io |
| 509 | もうすぐ 40 歳になるが労働を 3 年以上続けられたことがない IT エンジニアの話 - 30歳からのプログラミング | numb86-tech.hatenablog.com |
| 506 | news16 ｜ 株式会社ポケットペア | www.pocketpair.jp |
| 486 | Evernoteの華麗なるリブートとその未来 | lifehacking.jp |
| 479 | ディズニーのゲスト（入園者）が高齢化しているのは年間パスポート廃止だけが原因ではないらしい？ | ppc-log.com |
| 471 | 外部クリエイターによる当社所属ライバーの権利侵害行為等に関するご報告 ｜ ANYCOLOR株式会社（ANYCOLOR Inc.) | www.anycolor.co.jp |
| 457 | AIによってナスカ調査が加速したことで、既知の具象的な地上絵の数がほぼ倍増し、地上絵の目的が明らかになった｜国立大学法人 山形大学 | www.yamagata-u.ac.jp |
| 442 | コードレビュー開発者ガイド | fujiharuka.github.io |
| 417 | 10ギガ・ネットの不必要性(10G詐欺) ｜ www.kosho.org | www.kosho.org |
| 412 | ゲーム情報！ゲームのはなし | gamestalk.net |
| 392 | 【スパイファミリー×かまいたちの夜特別コラボ】スペシャル試し読み | promo.shonenjump.com |
| 388 | なぜ日比谷公園に一万人の陰謀論者が集まったのか - やばいブログ | y-ryukichi.hatenablog.com |
| 360 | 【富裕層】資産1億になって変わったお金の使い方、価値観【FIRE | 2week.net |
| 340 | iPhone 16：バッテリー - Apple サポート (日本) | support.apple.com |
| 337 | 📗 なぜ依存を注入するのか DIの原理・原則とパターンを読んだ感想 ｜ Happy developing | blog.ymgyt.io |
| 337 | なるほどTCPソケット ― Rubyで学ぶソケットプログラミングの基礎 ｜ snoozer05.org | www.snoozer05.org |
| 332 | Parquetフォーマット概観 - 発明のための再発明 | mrasu.hatenablog.jp |
| 322 | 一部報道の件について ｜ ニュースリリース ｜ アイコム | www.icom.co.jp |
| 317 | Xiaomi TV A Pro 43 2025 購入レビュー：「量子ドット」はウソですが･･･コスパは凄い！ ｜ ちもろぐ | chimolog.co |
| 307 | 「SwitchBot CO2センサー（温湿度計）/温湿度計 Pro」国内投入確定 | jetstream.blog |
| 296 | サンルーフはなぜ、採用車種が減ったのか?｜特集｜JAF Mate Online | jafmate.jp |
多人数マルチゲーや長時間配信で明らかに家庭用安物ルータが泡吹いて死んで「あれ～おっかしいな～繋がらないな～見えないな～」ってやってる時間。
立派なゲーミングパソコン揃えてるんだろうよ、回線も吟味して速い光回線引いてんだろうよ。でも間に入ってるそのルータ、nuroの必須ルータかバッファローのワイファイか知らねえけどさ、本棚の後ろに突っ込まれて熱暴走してるか、ソフトがポンコツでNAT溢れしてるかどっちかで死にかけてるだろ。
NVR500の中古でも何でもいいから強いルータに変えるなり安物ゲーミングならちゃんと風当てて冷やすなりパケロスしないようにしてくれよ。回線ガチャって言うけどネット回線の業者だけが変数じゃねえだろ。それかもうVPN張って無理矢理TCPセッションを1本に絞るとかさ、「また〇〇さんが繋がらないな～」「あれ～突然調子悪くなったな～」って毎回毎回毎回毎回毎回毎回毎回同じことすんなよ。裏ではDiscordで繋がってんだろ、何か知り合いのプロに聞いて同業者で対策回せよ。
リモートワークになってしばらく経つんだけど、いまだに文字ベースなのになぞなぞ構文で仕事してる人が多くて辛い
「はいなんでしょう」
「○○の件なんですがご存じですか？」
「それについていま部内で議論してるんです。それについてご相談しても良いでしょうか？」
「はいどうぞ」
（やっと本題）
これなんなん？こういうコミュニケーションしろって学校で習ってるんか？
「○○さんお疲れ様です、～の件についてご存じでしたら確認したいのですが、部内でそれについて検討してまして以下の内容をご相談したいです」
おっちゃんな、３５年パソコン弄ってて、３０年パソコンで飯食ってんだが
定期的に「世界が変わる画期的IT新製品」って奴が陳列されるのを見てきたの
インターネットもそう
iPhoneもそうだね
なにが変わった？なんも変わってねぇよ
人の営みの基本は変わらんの、メシ食って射精して寝る
「アレクサ、照明を明るくして」。。。
紐垂らして引っ張ったほうが早いっちゅうねん
ChatGPTやらも技術キャッチアップで使いましたよ、てか使ってるが
これで何が変わるのか？
多少効率化するかもしれんが業務全体の効率化への寄与は誤差程度でしかない。
もちろんこの誤差程度が積み重なって社会は少しずつ変わっていく、便利にはなっているが。
例えば、ちょっとした経費伝票の処理、昔は完全アナログだったが
事務職の女の子に、「あんじょうよろしく」と領収書を渡しておけば秒で終わった
怪しげな領収書も優秀な事務職さんが華麗な魔法で処理してくれていた
ところが電子化された今はゴチャゴチャゴチャゴチャと自力で入力して電子承認手続きして、
不正防止とやらで新幹線は乗車号数まで書かなきゃならない、時間的に矛盾する報告書出したらチェックされて返ってくるの、暇だねぇ
んでいずれAIで経費の不正検出できます、みたいなソリューションが出てくるのだろう、無駄の上乗せ屋上屋
利益だしとんねんからごちゃごちゃうっせぇわと言いたいが言うても無駄なので時代に迎合
さっき冷え性の事務職さんに「こんなの通りません」って伝票突っ返されたので愚痴でこれを書いてる
わいインターネットはまだ国内プロバイダーが個人商用サービスを始める前、WindowsがTCPソケットを実装する前、Asahi-NETがパソコン通信からテキストベースでインターネットゲートウェイしてた時代から使ってるからね
がっつりネットつかって、きっちりITで飯食ってる、一応プロのプログラマーっすよ
大友克洋のAKIRAは金字塔として評価されているが、その直後に作られたほぼ無評価の「老人Z」って作品がある。思い出しちゃった、わいこっちのほうが好きなんよね
随分と便利になった、そりゃ否定せんよ、でも変わってないよ
メシ食って射精して寝る、なにが変わったよ
今はみんなAIに熱狂してる、世界が変わると、なーんも変わらんよ
でも思ってるほど世界は変わらんと警告してやってんの、よろぴく
最近になって自分がSEというかIT職に興味がないと薄々感じています。
自分で好き勝手にプログラミングをすることはまあまあ好きなんですが、
それ以外のインターネットの仕組み(HTTPやらTCPやら)だとか、DBの管理だとか、フレームワークだとか。
この仕事を進めるうえで必要にはなるであろう知識を学ぼうという気が起きません。
テレワークで人の目がないからか頻繁にスマホいじったり部屋の中を意味もなくウロウロしてしまいます。
明確な作業がないときは指示をこちらから乞うこともしません。やっても1,2日経ってから。
「もう何年もSEやってるのにそんなこともわからないのか」と思われるのが怖いからかと思います。
(もうすでにそう思われであろうにも関わらず)
転職をしようにもケアレスミスが多く注意力散漫だから事務職は出来なさそうで、
そのくせ人と接するのが苦手で体力もないものだから肉体労働もすこぶる不安。
本当にどうしようもない。
引きこもって氏ねるのならそうなりたい。
以上、駄男のチラ裏文でした。
ネットに公開されている情報は、初心者には難しいと感じました。
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の設定
#
そうすると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っていう仕組みで良い感じに遅延が少なく通信できます。
ほいノ
高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。
18歳までフリーター。
18歳〜21歳まで定時制に通った。
英語は個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルのバカ校。
この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。
24歳でうつになって、30歳くらいまで日雇い・派遣↔無職を半々くらいでリピートしてた。
やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。
この時にプログラミングを始めた。
ここで年収どんどん上がった。
36歳でうつが再発して辞めて今に至る。
基本は、仕事で使えそうなもの・必要なものをその都度吸収していった感じ。
Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。
| Excel VBA | 1年 |
| VB.NET | 半年 |
| JavaScript（Node.js） | 4年 |
| HTML | 1年 |
| SQL | 4年 |
| GAS | 3年 |
| C# | 1年半 |
| TypeScript | 2年 |
| Java | 半年 |
| C++ | 半年 |
| ラダー、FB（三菱、シーメンス） | 1年 |
実務経験があるって胸張って言えるのはこれくらい。
大体習得順。
他には、Python、Julia、R、Fortran、Rust、Go、Dart、Shell、Deno、CSSなんかは少しずつかじってる。
最近はWebに関してはほとんどJS（TS）で済む感じになったので楽。
なんでPLCが最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。
RDBはPostgreSQL、SQL Server、MySQL、SQLiteの順で実務経験あり。
NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。
PaaSはGCP（Firebase）、AWSの順で実務経験あり。AzureはADとVM周りをちょっと触った程度。
Dockerはよく使うけどKubernetesとかまでは行ってない。
後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本とドイツとアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。
閑話休題。
フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん？
以下、俺の場合ね。
次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない？」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。
作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るから、イラッとして仕事用のPCで勝手にExcelで業務日報を付けるようにして、イントラのファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。
それだけでめちゃくちゃ喜ばれる。
で、今度はその次長が「この製造番号どれくらいの時間で作業終わった？」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelでストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。
それでまた、めちゃくちゃ喜ばれる。
最初はプライベートな時間も結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分のスキルアップに直結する時間を作れるようになる。
自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって？てのを考える。
ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。
大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。
これはiPaaSっていうサービスの一種で、まあ言葉の意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス。
例えば、あなたが日雇いの会社にいて、毎日違う現場に働きに行くとする。
で、出勤前、現場到着時、勤務終了の時にLINEで毎日報告しなきゃいけないとする。
で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。
面倒くさいし、お金がかかる。
そこで、「特定のグループでLINEを受信したら（イベントA）、特定のGoogleスプレッドシートに情報を記録せよ（イベントB）」っていうのをIFTTTに登録すると、少なくとも事務員の入力の手間は省けるってえ寸法だ。
IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。
月1000円で学べる。コスパは圧倒的。
入門コース（学習に180時間と公称してる）がしっかり理解できていれば、Webで大抵のものは作れる。
ただし、大筋は問題ないんだけど、細かい部分で最新技術をキャッチアップできてない可能性があるので、そこは注意した方が良いかも。
https://www.nnn.ed.nico/pages/programming/
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。
そしたら、職歴書の作り方次第で中小企業の社内SEにはまず転職できる。
中小企業の社内SEは、ITリテラシーの低い社員が多い中で「Excelのセルの色が変わらなくなっちゃったんだけど！」とか「複合機が紙詰まりって言ってるけどその紙が見つからない！」とかクソイージーなクエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。
ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。
けど安定なのは間違いない。
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。ここは社内SEと同じ。
生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。
あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。
で、中小企業の生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。
IoTは最近、セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。
そこに滑り込むのはアリだと思う。
よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。
ま、橋渡しって自然とプロマネとか任されがちで、裁量大きくて大変なんだけどね。
質問あればどうぞ。頑張って。
TCPでパケロスとか言ってる奴は自分が何を言っているのか分かってんのか
NUROをきっちり糾弾するためにレイヤーのことぐらいは分かってくれ
例えばLTEなんてバンバンパケロスするけどTCPやUDPだと全然パケロスが無い
モバイルバックホールはそもそも品質が凄く悪いのを前提にしている（無線区間のことではない）
パケロスしてるからダメでしてないからOKっていう単純な話では無い
単純に「NUROは遅い」って言えばいいし、NUROはそれを向上させればそれでいいんだよ
適当にSNSやググって聞きかじった程度の知識でデタラメ言うのやめてくれません？
＞LAG WATCHもping(ICMP echo)で計測しているのであてにならないね
＞ちゃんとTCPのコネクション毎にパケロス起こってるか見ないと正確なことはわからない
どうせICMPはルーターでの優先度低いからドロップしても問題ない当てにならないとかどこかで見たんでしょうけど
パケロスしてるって言ってるNUROユーザー、実際はパケロスしてない。
speedtest.netで速度測定するときにサーバーが自動で選択されるんだけど、
NUROを使っているとGSL Networksってサーバーが自動選択されやすい。
GSL Networksってサーバーに対してスピードテストするとNUROでなくてもパケットロスが出る(ひどいと60%以上)
試しにNURO以外からspeedtest.netでGSL Networksを手動選択してスピードテストしてみてほしい。絶対パケロスが出るから。
ほとんどの場合テストサーバーがGSL Networksなんだよね。
NUROユーザーはspeedtest.netでテストするならGSL Networks以外のサーバー、例えばi3D.netでもう一度テストしてほしい。
【追記】
FF14のこれはパケロスを測定する方法じゃなくて経路を報告するためのもの
https://jp.finalfantasyxiv.com/lodestone/topics/detail/b4448590f9576b7c847824215f4ce11d545b48cb
けど報告を見るにそんな重大なパケロスは起こってなさそう
パケロスじゃなくてBufferbloatが起こってるんじゃないかと疑ってる
https://evenroute.com/bufferbloat
Bufferbloatのテストはここでできる
https://www.waveform.com/tools/bufferbloat
【再追記】
GSL Networksでパケロスが起きる問題、どうやらICMPだけで起こる様子
https://twitter.com/hasegaw/status/1575694680641007616
LAG WATCHもping(ICMP echo)で計測しているのであてにならないね
ちゃんとTCPのコネクション毎にパケロス起こってるか見ないと正確なことはわからない
で、ちゃんと計測している人を探してきましたが9月22日頃の19時-翌1時は普通にレスポンス悪化してますね
https://twitter.com/Clorets8lack/status/1575256365517639680
