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 における「コネクション」とは、メッセージ経路全体ではなく隣接ノード間 (クライアントとプロキシ間など) のコネクションのことを指す

Continue reading »

5月 082019
 

自作プロキシ (Nekoxy2) の WebSocket (RFC6455) 対応にあたっての私なりの理解をまとめました。

概要

WebSocket 自体はかなり単純で、TCP 上で投げっぱなし全二重通信をする方法と、HTTP/1.1 からのプロトコル アップグレード方法 (WebSocket の開始方法) が定義されているだけです。
実際に何を通信するかはサブプロトコル等のアプリケーション側にお任せとなります。

WebSocket over HTTP/2 (RFC8441) では、この内アップグレード方法が HTTP/2 向けに新しく定義されただけで、通信方法は同一となります。
※ 詳細は HTTP/2 理解メモ 参照。

注意点としては、接続・切断については到達保証がありますが、それ以外のメッセージには到達保証がないため、必要に応じてアプリケーション等で実装する必要があります。

また HTTP が利用するコネクションを再利用する形となるため、経路上に非対応の透過プロキシなどが存在する場合に通信が失敗する可能性があります。

Continue reading »

5月 072019
 

HTTP/2 理解メモ同様に、自作プロキシ (Nekoxy2) で実装した際の HPACK (RFC7541) への自分なりの理解をまとめたものです。
解説とかは他サイトのほうが良いかと。

HPACK は RFC の Appendix に具体例がたくさん載っているので、分からなくなったらそこを眺めると良いでしょう。

※RFC7541 ではバイト数は厳密に「オクテット数」と表現されているが、ここではバイト数とオクテット数は同じ意味とする

Continue reading »