10月 022019
 

XPS 13 2-in-1 (7390) / 2019 年モデル を買って届くまでの続き。

買ったもの

おさらい

XPS 13 2-in-1 (7390) 2019 年モデル
CPU 型番 Core i7-1065G7
CPU 世代 IceLake-U (10nm)
コア/スレッド数 4コア 8スレッド
CPU ベースクロック 1.3 GHz
CPU ブーストクロック 3.9 GHz
TDP 15W (cTDP 25W 可能だがこのマシンは 15W らしい)
GPU Iris Plus
GPU 世代 11
GPU Tier GT2
EU 数 64
GPU クロック 1.1 GHz
メモリ 32GB 3733MHz LPDDR4x onboard
ストレージ 1TB PCIe NVMe onboard
ディスプレイ 13.4 インチ 3840 x 2400 (16:10)
タッチ
ペン AES 2.0 (ペン別売)
ディスプレイ表面 グレア/Gorilla Glass 5/反射防止・防汚コーティング
サイズ 296 x 207 x 13 mm
質量 1.33 kg
バッテリー 51Wh
AC アダプター出力 45W
AC アダプター端子 Type-C (USB-PD)
AC アダプターサイズ 60 x 55 x 23 mm
AC アダプター質量 142 g
充電時間 3h
キーボード配列 US
キーピッチ 19 mm
キーストローク 0.7 mm
キーボード方式 MagLev (磁気浮遊)
高精度タッチパッド
Wi-Fi Killer AX1650 Wi-Fi 6 (IEEE 802.11ax) 2×2
Bluetooth 5
ポート Thunderbolt 3 x 2 (USB-PD 電源入力兼用)
MicroSD x 1
3.5mmヘッドフォン・マイク x 1
Windows Hello 指紋
価格 24 万円くらい

Continue reading »

9月 292019
 

購入動機

  • MX-R の置き換え
  • MX-R のセンサー解像度は 800dpi しかなく、昨今の高解像度デスクトップ環境では不足する
  • ゲーミングマウスなら全く問題なく対応できるが、やはりスマートシフトはほしい
  • 今までの MX Master シリーズは、進む・戻るボタンがあまりにも使いにくい
  • MX Master 3 になって、進む・戻るボタンがまともに利用できる配置になった

Continue reading »

8月 212019
 

レビューというか感想はこちら

今の VAIO Z 2015 から買い換えるための要件は以下の通りだった。

  • 13 インチ程度
  • CPU 4 コア以上
  • メモリ 32GB 以上
  • 解像度 WQHD 程度
  • タッチ可
  • 質量 1.3 kg 前後以下
  • バッテリー 50Wh 程度以上 (Web ブラウジングで概ね 9 時間程度以上)
  • 中国企業以外

XPS 13 2-in-1 の 2019 年モデルでようやく、多少の不満はあるものの概ね満足できるものとなったため、購入した。
(今までは ThinkPad T490s がかなりいい線を行っていたが、Lenovo である点、WQHD だとタッチ不可な点でアウト)

2019年8月中旬時点でこれ以外に要件を満たすものがなく、来月以降出てくるものがあったとしても消費税の増税までに間に合わないだろうと考え、ここで妥協することにした。

Continue reading »

7月 082019
 

参照: 1903: dwm.exe goes to 100% CPU on remote host after disconnecting from RDP session... Can anyone reproduce? : Windows10

リモートデスクトップホストとなっているマシンが RDP セッションを切断された場合、dwm.exe が CPU を異常に消費するようになる問題があるらしい。
報告によると Intel, NVIDIA の GPU で発生しているようだが、私の再現環境は AMD(Radeon HD7750) なので、GPU メーカーには依存しない模様。

参照: Graphics Forum - Intel® Community Forum

以下のグループポリシーを 無効 にすることで回避できる。

グループポリシー
-> コンピューターの構成
-> 管理用テンプレート
-> Windows コンポーネント
-> リモート デスクトップ サービス
-> リモート デスクトップ セッション ホスト
-> リモート セッション環境
-> リモート デスクトップ接続に WDDM グラフィック ディスプレイ ドライバーを使用する

1903 からリモートデスクトップに WDDM ベースのドライバーが用いられるようになったが、そこにバグがあることが原因ではないかと推測されている。

このリリース以降、リモートデスクトップサービスでは、1つのセッションリモートデスクトップに Windows ディスプレイドライバーモデル (WDDM) ベースの間接ディスプレイドライバー (IDD) が使用されます。 Windows 2000 のディスプレイドライバーモデル (XDDM) ベースのリモートディスプレイドライバーのサポートは、今後のリリースで削除される予定です。 XDDM ベースのリモートディスプレイドライバーを使う独立系ソフトウェアベンダーは、WDDM ドライバーモデルへの移行を計画する必要があります。
Windows 10 バージョン 1903-削除された機能 | Microsoft Docs

追記 (2019/10/25)

オプションパッチながら KB4522355 で修正された模様。

Addresses an issue with high CPU usage in Desktop Window Manager (dwm.exe) when you disconnect from a Remote Desktop Protocol (RDP) session.
October 24, 2019—KB4522355 (OS Build 18362.449)

6月 182019
 

参照 RFC7231 6.2, 5.1.1

  • 1xx ステータスコードのレスポンスは、最終的なレスポンスに先立って情報を伝達するために返される
    • つまり 1xx レスポンスが返される時は、1リクエストに対して2レスポンス返されたりする
  • HTTP/1.0 ではサポートされない
  • RFC7231 は HTTP/2 でも変わっていない

  • Expect: 100-continue リクエストに対して 417 レスポンスが返された場合、クライアントは Expect ヘッダーを除いたリクエスト全体を送信すべきである

  • これらの動作はプロキシがクライアント・サーバー双方に対して代行することも有り得る
6月 172019
 

参照 RFC7230 6.7

  • Upgrade ヘッダーは、1つの HTTP/1.1 コネクション上で他のプロトコルへ移行するのに用いられる
  • HTTP/2 にはこの仕組みはなく、CONNECT メソッド拡張の protocol 擬似ヘッダーにて実現される [RFC8441 4]

  • クライアントは、Upgrade ヘッダーに優先度の高い順にプロトコル名のリストを設定し、送信する
  • サーバーは、リストから移行するプロトコルを選択して Upgrade ヘッダーに設定し、101 Switching Protocols レスポンスを返す
  • サーバー側からプロトコルの移行を指示する場合、426 Upgrade Required レスポンスを用いる

  • Upgrade ヘッダーは hop-by-hop ヘッダーであり、指定されたプロトコルに対応していない中継者による回送を防ぐために、Connection ヘッダーに upgrade を指定しなければならない

  • サーバーが Upgrade と Expect を同時に受信した場合、101 Switching Protocols より先に 100 Continue を送信しなければならない
  • 利用できるプロトコルのリストは、IANA に登録されなければならない
6月 142019
 

HTTP フォワードプロキシが介在する場合、単に通信を中継するだけでなく通信される内容も変化する。
もちろんプロキシの機能として HTTP メッセージの改変が行われる場合はあるが、それ以外の場合でも変化する部分はある。

  • request-target の形式
    • クライアントが送信するリクエストラインが変更される
    • サーバー直アクセス: GET /hoge HTTP/1.1
    • プロキシ経由アクセス: GET http://example.com/hoge HTTP/1.1
  • Transfer Codings の変更
    • chunked から Content-Length 形式に変更される、圧縮が解除されるといったことはあり得る
  • HTTP コネクションの持続的接続の有無
    • client-proxy 間と proxy-server 間では TCP コネクションの持続方法が異なる場合がある

いずれも HTTP の意味論的な変更ではなく、通信上の都合により変更が許されている部分である。

6月 142019
 

参照 RFC7230 5.3

  • HTTP リクエストメッセージのリクエストラインは、method request-target HTTP-version で構成される
    • GET / HTTP/1.1
  • この内の request-target にはいくつかの形式が存在する
型式名 用途
origin-form GET /where?q=now HTTP/1.1 最もよくある形式
absolute-form GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 プロキシ向けリクエストはこの形式でなければならない
authority-form CONNECT www.example.com:80 HTTP/1.1 CONNECT メソッドでは必須。CONNECT メソッド限定。
asterisk-form OPTIONS * HTTP/1.1 OPTIONS メソッドでは必須。OPTIONS メソッド限定。リソースのワイルドカード的に用いられる。

このうち、absolute-form は原則プロキシ向けのリクエストにのみ用いられるが、サーバーは absolute-form を受容可能でなければならない。
理由は将来の HTTP バージョンでは全て absolute-form への移行を可能にするためとされている。
実際に HTTP/2 では、リクエストラインに相当する機能は擬似ヘッダーフィールドに変更されているものの、absolute-form に相当するだけの情報を持つようになっている。

しかし実際に absolute-form を送信すると正しく動作しないサーバーが非常に多い。
恐らくはリバースプロキシでのリライトルールあたりとの相性が悪いせいではないかと考えられる。

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 ヘッダーである点に注意

Continue reading »