CAT EARS – ページ 3

HTTP/1.1 の Transfer Codings (転送符号化)の理解メモ

6月 132019

参照 RFC7230 4, 3.3.1

HTTP メッセージボディーの転送は、HTTP/1.0 までは Content-Length で指定した長さのデータを転送する方式しかなかった
- 転送が終わるまでボディーデータの全てをメモリ上にとどめておく必要があるなどした
HTTP/1.1 にて chunked transfer coding (chunked) ができるようになり、ボディーデータを分割して転送することができるようになった
- 事前に最終的な長さが分からなくても転送可能
HTTP/2 には Transfer Codings の仕組み自体がない
- Stream に取って代わられたため

Transfer Codings の方式は、TE および Transfer-Encoding ヘッダーにて指定する
- TE ヘッダーでクライアントが受入可能な方式を指定
- Transfer-Encoding ヘッダーで送信するメッセージの符号化方式を指定
受信者は chunked を復号化できなければならない [RFC7230 4.1]
Transfer-Encoding は hop-by-hop ヘッダーであり、隣接ノード間にのみ適用される [RFC7230 3.3.1]
- 故に、プロキシなどの中継者は Transfer-Encoding を復号化し、Content-Length 方式や別の Transfer-Encoding に変換するなどしても良い
- Content-Encoding ヘッダーは end-to-end ヘッダーである点に注意

ICT, memo, 設計

6月 102019

コンポーネント凝集性の原則に閉鎖性共通の原則(CCP)もあるが、どちらも概念としては同じである。

モジュールはたったひとつのアクターに対して責務を負うべきである。
(Clean Architecture / Robert C.Martin)

クラスレベルでは、単一責任の原則(Single Responsibility Principle)。
コンポーネントレベルでは、閉鎖性共通の原則(Common Closure Principle)。

SOLID 原則は知っていても、どのようにクラスを定義するか、コンポーネントを分割するか、つまりどこに境界線を引くべきかを悩むことは多い。
単一責任、変更する理由は一つだけであるべきと言われても、その「責任」がふわっとしていて定まらないなんてことはよくある。

Clean Architecture の上記部分を読んでようやく、「責任」には当然「対象」が存在する事に気付いた。
つまりクラスにしろコンポーネントにしろ、必ず利用するアクターは存在する。

ICT, memo, 設計

6月 072019

ICT, PC, tips

5月 212019

ストレージのインターフェースは、物理的形状の規格、電気的接続の規格、論理的なコントローラーの規格の 3 層に分かれていると解釈できます。
これらを正しく認識することによって、製品の特性を判別できるようになるでしょう。
規格によって複数の範囲をカバーしていたりして非常にややこしくはあるのですが。

層	規格の例
物理的	SATA, mSATA, SATA-Express, PCI-Express, M.2, U.2, USB Type-C
電気的	SATA, PCI-Express, USB
論理的	IDE/ATAPI, SCSI, AHCI, NVMe

SCSI を SATA 上に乗せれば SAS になったり、USB に乗せれば UAS になったり、TCP/IP に乗せれば iSCSI になったりするのもこれで納得ですよね？

SSD が M.2 なのに中身 SATA 接続だったり、PCI-Express 接続なのに AHCI だったりするケースがあることも理解できるでしょう。

他にも M.2 NVMe → USB ブリッジする製品などは、PCIe & NVMe を USB & UAS(SCSI) に変換しているため、シーケンシャル速度はともかく NVMe の最大のメリットである並列性の高いコマンドキューイングなどがどの程度維持されるのか心配といったことも見えてきます。

古い規格ほど全域をカバーしていることが多いように感じます。
古い規格がパフォーマンス上の都合により電気的規格を乗り換える際も、互換性を維持するためか論理的規格は残されたりして、SCSI なんかはしぶとく生き残っているわけです。

5月 132019

参照 RFC7230 6

HTTP は、リクエスト・レスポンスのセットを TCP コネクション上で送受信する
HTTP/1.0 の既定では、1 つのリクエスト・レスポンスが完了したら TCP コネクションは閉じられる
- Connection: keep-alive リクエストヘッダーにより TCP コネクションを閉じず再利用する持続的接続 (Persistent Connection) ができるようになった
HTTP/1.1 では持続的接続は既定で有効であり、 Connection: keep-alive は必要ない
- HTTP/1.0 サーバーとの持続的接続を望む場合は送信される
HTTP/1.1 における「コネクション」とは、メッセージ経路全体ではなく隣接ノード間 (クライアントとプロキシ間など) のコネクションのことを指す