CDNを使う理由

VPSのみの場合

リクエスト時にユーザーのブラウザで HTML が解析され、画像・動画・静的な JS ファイルが順次VPSサーバーからダウンロードされる
すべての静的ファイルは VPS が配信するため、アクセス集中時にサーバー負荷が高くなる

VPS + CDN の場合

画像・動画・静的 JS ファイルを CDN に分離して配信することで、VPS への負担を軽減できる
CDN は静的ファイルのコピーを世界各地に分散して持つため、ユーザーからのリクエストは地理的に近い CDN サーバーから応答され、レスポンス速度が向上する

ポート

3000番ポートが使われる理由：

特権ポートではなく、キリが良い数字だから
- 特権ポート（0-1023）: システムの重要なサービス（例: Webサーバーの80番、HTTPSの443番など）が使うポート。これらのポートを使うには管理者権限が必要

ポートはコンピュータ上でアプリケーションが通信を行うための窓口のようなもので、ブラウザは「ウェブサーバー」との通信にこの窓口を利用

ウェブサーバーのポート: ウェブサイトを配信するサーバーは、通常、80番（HTTP通信）や443番（HTTPS通信）といった特定のポートで待ち受けている。
ブラウザ（タブ）のポート: ブラウザはウェブサーバーと通信するために、PCの一時的なポート（1024から65535の範囲でランダムに選ばれることが多い）を使う。このポートは、ウェブサーバーからの応答を正確に受け取るための「返信用」の窓口として機能する
- *１つのサイトに対応するPC側のポートは１つとは限らない。サイトが複数のCDN を使っているなら、１つのサイトに見えても [ 複数ポート対複数ウェブサーバー ] の通信になる
- ウェブサーバーとの通信はブラウザ以外もできるが（例 curl）、ブラウザは画像やCSSを解釈できる = レンダリングエンジンを持っているのでよく使われる
- 通信ごとに一時的なポートはランダムに変わる。= 一時的なポートとウェブサーバーの紐づけはその通信時のみでリロードしたら変わる

TLS・TCP

TLS：

通信内容を暗号化して安全にやり取りするためのプロトコル。TLSはSSLの強化版みたいなものだが、習慣的にTLSが用いられていてもSSLと呼ばれることが多い

TCP：

インターネット上でデータを確実に送受信するための通信プロトコル。データをパケットに分けて送信し、受信側で順序どおりに再構築

まとめ：

TLS は通信の安全性（暗号化）を保証
TCP は通信の信頼性（届くこと）を保証

ブラウザ → TLS → TCP → インターネット

ドメイン：名前解決

名前解決 = ドメイン名を IP アドレスに変換する処理

DNS（ドメインネームシステム）サーバーの種類：

ルートネームサーバー：
- com, .net, .jp など「TLD（トップレベルドメイン）」を管理している場所を教える。ICANN / IANA が管理。a.root-servers.net など13種類
TLDネームサーバー：
- 各TLD（例: .com, .jp）のゾーン情報を管理。Verisign (.com), JPRS (.jp) など
権威DNSサーバー：
- 各ドメイン（例: example.com）の最終情報を持っている。Cloudflare, AWS Route53, Vercel DNS など（ns1.vercel-dns.com, ns-1234.awsdns-56.net）

サイトのIPアドレス情報を持っているのは最後に行き着く権威DNSサーバーだが、各段階でキャッシュがあれば上位サーバーまで行く必要はない

Storage / Cookie

検証ツールでサイト毎（ドメイン単位）に Local storage / Cookies 内のアイテムが違うのは、これらはドメインと紐づいている為
ブラウザの設定から全サイト（毎）の保存アイテム件数を確認できるが、詳細はそれぞれのサイトにアクセスして、検証ツールからじゃないとみれない
保存内容はブラウザの「Cookie と他のサイトデータを削除」でクリアされる

タブ（ = メモリで実行）を閉じても保存されているのは、データがPCのストレージに存在している為

├── RAM（揮発性メモリ）   ← 実行中のブラウザやJSが使う
└── SSD/HDD（永続ストレージ）
     ├── Cookieファイル（ブラウザごとに管理）
     ├── LocalStorage
     ├── IndexedDB
     └── Cache

Ubuntuの場合、~/snap/chromium/common/chromium/Default$ に「Cookies」というファイルがある

localStorage：

使い方（クライアント）： localStorage.getItem() / setItem() / removeItem()
localStorageは完全にブラウザ内専用の機能なので、アクセスできるのはクライアントコンポーネントだけ

cookie：

localStorageよりも難しく感じるが、cookieは「ブラウザが送るHTTP ヘッダー」なのでサーバー側でcookieを読んだり、値をセットしてレスポンスを返したり（HTTPヘッダーの書き換え）できるのでよく使われる
サーバー側はcookieをどうするか「命令」をHTTPヘッダーとして出す。クライアント側は命令に従ってcookieを操作することも出来るし、命令無しで自身でcookieをセットしたり出来る

Nextjsでの使い方（サーバー）

get：await cookies().get()

const Page = async () => {
  const val = (await cookies()).get("from")?.value;

set：await cookies().set("key" , "value")

  (await cookies()).set("key2", "value2");

*page.tsxでセットしようとすると「サーバーアクション or ルートハンドラーでしか使えない」旨のエラーがでる（ Cookies can only be modified in a Server Action or Route Handler）
--> await cookies().set()はレスポンスヘッダーを書き換える操作なので、サーバーアクション or ルートハンドラーでしかセットできない

サーバーアクション：

  const createCookie = async () => {
    "use server";
    (await cookies()).set("from", "hog423");
    const rwe = (await cookies()).get("from")?.value;
    console.log(rwe);
  };

  return (
    <div className="grid grid-cols-4 gap-4">
      <form action={createCookie}>
        <button type="submit">submit</button>
      </form>
    </div>
  );
};

route.ts：

import { cookies } from "next/headers";
import { NextResponse } from "next/server";

export async function GET() {
  const data = (await cookies()).set("from", "route.ts");

  return NextResponse.json({ message: "route.ts", data });
}

クライアント側

document.cookie：

  useEffect(() => {
    document.cookie = "name=hog"; // set

    const cookie = document.cookie; // 全取得
  }, []);

useEffect外に書くとSSR時にdocementへアクセスできないのでエラーが出る
全取得だとひと塊の文字列で取得されるのでセミコロンでアイテムを区切る

オブジェクトの set / get

localStorage / cookieともに文字列形式でしか保存できないのでオブジェクトはJSON.stringfy でJSON文字列化する。

set：JSON.stringfy

// localStorage
localStorage.setItem("user", JSON.stringify({ name: "fhos", age: 11 }));

// cookie
document.cookie = `user=${encodeURIComponent(
  JSON.stringify({ name: "fhos", age: 11 })
)};

*cookieの場合はHTTPヘッダーで送られる際に、許可されない文字や記号が含まれている可能性があるのでencodeが必要

get：JSON.parse

// localStorage
const usr = JSON.parse(localStorage.getItem("user"));

// cookie
const cookies = Object.fromEntries(
  document.cookie
    .split("; ")
    .map((c) => c.split("="))
);
const userJson = decodeURIComponent(cookies.user);
const user = JSON.parse(userJson);

V8エンジン / Node.js

V8エンジン：

Googleが開発した「JavaScript エンジン」
V8の役割は JavaScript のコードをコンピュータが理解できる機械語に変換して実行
Chromeに搭載されている
- ブラウザの場合はレンダリングが主な目的なので、V8だけでなくレンダリングエンジンもある
Node.js：サーバー用JavaScriptエンジンとして内部にV8が使われている
- JavaScript エンジンであるためNode.jsはV8なしでは動作しない

V8とCPU / メモリ：

[タブ1] ──> V8 ──> CPU ←→ メモリ
[タブ2] ──> V8 ──> CPU ←→ メモリ
[タブ3] ──> V8 ──> CPU ←→ メモリ

各タブは独立した V8 インスタンスを持つ
- ターミナルで ps aux と打つと複数の Chromium や Brave のプロセスが動いているのがわかる
  - プロセス：CPU やメモリを使っている「状態」の単位のこと
CPU：タブごとにV8が生成した機械語を高速に実行
メモリ（RAM）：タブごとのデータや JS オブジェクトを保持
- ブラウザDevツールの「memory / heap snapshot 」を実行すると、V8 が管理しているJS データの状態（大量のオブジェクトや配列）が確認できる

Lighthouse

Googleが公式に提供しているWebサイト品質の自動診断ツール

*注意点：

拡張機能が「Performance」項目の計測に大きな影響を与えるのでシークレットモードで行う（Ctrl + Shift + Nキー）
- 拡張機能無しの測定だとPerformanceが50近く加算された

ブラウザー