C# Tokyo LT 大会 2020/02 - connpass で話したやつです。
2月 142020
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 万円くらい |
9月 292019
購入動機
- MX-R の置き換え
- MX-R のセンサー解像度は 800dpi しかなく、昨今の高解像度デスクトップ環境では不足する
- ゲーミングマウスなら全く問題なく対応できるが、やはりスマートシフトはほしい
- 今までの MX Master シリーズは、進む・戻るボタンがあまりにも使いにくい
- MX Master 3 になって、進む・戻るボタンがまともに利用できる配置になった
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月中旬時点でこれ以外に要件を満たすものがなく、来月以降出てくるものがあったとしても消費税の増税までに間に合わないだろうと考え、ここで妥協することにした。
7月 082019
リモートデスクトップホストとなっているマシンが 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月 192019
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 に登録されなければならない
- Hypertext Transfer Protocol (HTTP) Upgrade Token Registry
- 事実上 WebSocket にしか用いられていないのでは
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 を送信すると正しく動作しないサーバーが非常に多い。
恐らくはリバースプロキシでのリライトルールあたりとの相性が悪いせいではないかと考えられる。