WEB+DB PRESS Vol.123 を読んで
https://www.amazon.co.jp/dp/4297122073
を読んだので、かなりざっくりまとめました。
自分用のメモ。
○ PHPの型管理Psalm
もともとのPHPの型宣言の弱点
- 型の表現力の不足 。配列の型の指定がないなど
- PHPDocの型アノテーションの強制力がない。IDEでPHPDocをもとに型をチェックしているが、言語自体には含まれていない
- 型宣言が実行時に行われるため、実行されるまで誤りを検知できない
PHPSalmの特徴
○ Golangのメモリ管理
Golangのstructがどのようにメモリ領域を使うのかを説明している(Go1.16)
メモリ領域には アラインメント が鍵となる。
アラインメント: データがメモリ上にどのように配置されるかに関する取り決め
各型のアラインメントのサイズは、コンパイラによって決められている
Golangの場合
- Int8 => 1バイト
- Int16 => 2バイト
- Int64 => 4バイト
メモリ配置のルール
- 各型がメモリに配置される際、アラインメントの倍数の位置にデータの先頭が配置される。(Int64の場合は8 or 16 or 24... の位置から保存される。)
- これを実現するために
パッディングと呼ばれる余白がある。- 例: 3バイトまでデータが書き込まれていて、次にint64のデータを書き込む場合、4バイトのバッティングが追加されて、8バイト目からint64が配置される。
- これを実現するために
- 型のサイズ: アラインメントと一致する。
structの場合
- アラインメント: 内包されている型の中で一番大きいアラインメントのサイズと一致
- 型のサイズ: 内包されている型の中で一番大きいアラインメントのサイズの倍数と一致(パッディングが追加される場合もある)
struct定義時、アラインメントが大きい順に定義するとメモリ使用量が最適化されることもある
structのデータ①
type Hoge
{
A int64 // アラインメントサイズ8
B int16 // アラインメントサイズ2
C int8 // アラインメントサイズ1
}
↓
0~7: Aを保存 8~9: Bを保存 10: Cを保存 11~15: パッディング(Hogeのサイズは、Bのアラインメント8の倍数とする必要がある)
合計16byteを利用することになる
structのデータ②
type Fuga
{
A int16 // アラインメントサイズ2
B int64 // アラインメントサイズ8
C int8 // アラインメントサイズ1
}
↓
0~3: Aを保存 4~7: パッディング(Bのアラインメントは8のため、8の倍数から保存を始めるため) 8~16: Bを保存 17: Cを保存 18~23: パッディング(Fugaのサイズは、Bのアラインメント8の倍数とする必要がある)
合計24byteを利用することになる
構造体のサイズはどのように調べればよいか
- fieldalignmentコマンドをインストールする
- unsafe.Alignof、unsafe.SizeOf関数を使う
○ NextJS
Vercel
- Nextjsの開発、デプロイ環境を簡単に生成、設定してくれるツール。
- 僅かな設定でDevelop, Preview, Ship環境を作成できる。
○ HTTP3
※あまり理解できていない
一言でいうと、HTTP2の弱点を克服したHTTPプロトコルの通信方法。 トランスポート層でTCPではなくQUICを使っていることが鍵となっている。
バージョンごとの特徴と課題
HTTP/1.1
課題
HTTP/2
改善
- HTTPメッセージを細切れ(フレーム)にし並列(のように)で送るようにした。フレーム内の情報はそれらを格納する位置が決められていた。その仕組みでリクエストとレスポンスが紐付いていたため、リクエストの順番でレスポンスを返す必要がなくなった。
課題
- 4階層モデルでHTTP/2の下位層で利用しているTCPは信頼性の担保のため、送信者がパケットを送信した順番通りに受信者がバケットを処理する必要があった。
- そのためパケットロスが発生した場合は、再度送り直してもらう必要があり、後続のパケットが送られてきても、ロスしたパケットを取得し直すまではデータをアプリケーションに渡さずに待つ必要があった。
HTTP/3
改善
