2020-02-26

「アフターデジタル」を読んだ

作者:藤井保文,尾原和啓
出版社/メーカー: 日経BP
発売日: 2019/03/23
メディア: Kindle版

目的、モチベーション

そんなに明確に目的がある理由ではなく、最新の中国の事例やサービスの考え方を知りたかったため。
また、周囲に読んでいる人がいて、オススメしていた。

全体の感想

中国の事例が多く紹介されていて、「アフターデジタル」の概念を少しずつ理解できた。
データやAIが前提となっていて、技術的には本当に差がこんなにもあるんだなと感じた。
決済サービスはデータ収集や支払いのインフラとなっていて、それをベースに開発されているサービスも多く、日本の決済サービスもまだまだ序盤でこれからの展開がどうなるか楽しみになった。

メモ

印象に残っている箇所をまとめました。

第1章知らずには生き残れない、デジタル化する世界の本質

1-5　デジタル中国の本質　データが市民の行動を変え、社会を変える

DiDiではジャイロセンサーとGPSで運転手の運転マナーを評価している。

第2章アフターデジタル時代のOMO型ビジネス～必要な視点転換～

2-1　ビフォアデジタルとアフターデジタル

オンラインを中心に展開する前提で、リアル店舗は信頼を獲得したりする手段にすぎない。

2-2　OMO：リアルとデジタルを分ける時代の終焉

OMOの発生条件

スマホとネットワークの普及
モバイル決済浸透率の上昇
幅広い種類のセンサーが高品質で安価に手に入り、偏在する
自動化されたロボット、人工知能の普及

リアルはユーザインターフェイスの一つにすぎないから、オンラインとオフラインを区別するのはナンセンス。

2-3　ECはやがてなくなっていく

フーマーはアリババのデータを元に出店を決めてる。結婚した若者の多い地域に出店するなど。データが豊富で正確に予想できるため、黒字になる前提で出店している。

2-4　転覆され続ける既存業態

飲食店は、デリバリーサービスがある前提で設計されたスタンド型の店舗が増えてきている。回転数や座席数に依存せず客の数を増やしたり、味に注力できたり、狭い土地に出店できるように前提が変わる。

第3章アフターデジタル事例による思考訓練

3-1　GDPR vs 中国データ共産主義〜データの取り扱いをめぐる議論〜

一部の学校ではカメラを設置してAIで表情から態度を評価する。常に見張られているようで気持ち悪くも感じるが、教師の主観や把握しきれていないところも平等に評価できる。また、表情から理解の度合いを把握して、授業のペースをコントロールできる。

3-2　「レアな接点」に価値がある時代

無人レジというと、無人になってコストが減るのが主な目的と思われがちだが、コスト削減は副次的なもので本当に取りたいのは、購入する際の行動のデータ。

アフターデジタル　オフラインのない時代に生き残る

作者:藤井保文,尾原和啓
出版社/メーカー: 日経BP
発売日: 2019/03/23
メディア: Kindle版

2020-02-10

「入門ＵＮＩＸシェルプログラミング」を読んだ

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

作者:ブルース・ブリン,Bruce Blinn
出版社/メーカー: ソフトバンククリエイティブ
発売日: 2003/02
メディア: 単行本

目的、モチベーション

今まではググりながら雰囲気でシェルスクリプトを書いていて、最近業務で使うことが増えてきて、シェル使いになりたいと思ったから。

全体の感想

一通りの文法がまとまっていたので、この1冊を理解すれば、ソースコードもガンガン読んでいけるレベルにはなると思う。
リダイレクトとかは特に雰囲気で使っていたレベルだったので、ちゃんと理解できてよかった。たまに見る、 /dev/nullの意味もわかったので、これからはガンガン使おうと思う。

概要

第1章書き方にかかわる基本的な説明

1.4 ファイル名称の補完

ワイルドカード	説明
*	文字列全部
?	1文字
[...]	の中に含まれている文字のどれか一つ
[!...]	の中に含まれてない文字

1.5 引用符の使い方

シングルクォートの中で変数を展開したい場合

'Part1'"$VAR"'Part2'

1.9 コマンドのグルーピング

()によるグルーピング: サブシェルで実行する。現在の環境を変えずに実行したい場合などに便利。
{}によるグルーピング: 現在のシェルで実行する。コマンドの結果をひとまとめにしたい場合などに便利。

1.10 制御文

testコマンドは []と同じ。

第2章シェル変数

変数を明示的に使うには、{}で囲む。

$ FOO=abc
$ echo ${FOO}abc

2.5 位置パラメータ, 2.6 特殊な変数

変数	説明
$#	引数の数
$*	引数全体。ダブルクォートで括ると、一つの文字列として扱われる。
$@	引数全体。ダブルクォートで括ると、それぞれが文字列として扱われる。
$?	コマンド実行時の終了ステータス
$$	プロセスID
$!	`&`でバックグラウンド実行させたときのプロセスID
$-	実行中のシェルのフラグの一覧

第3章シェル関数、組み込みコマンド

3.1 シェル関数

3.1.4 関数をカレントシェルで利用すること
通常、シェルスクリプトに含まれるコマンドはそのシェルスクリプト内で動作し、起動したシェル上で動くわけではない。
カレントシェルで実行させるには .という組み込み関数を使用する。

$ . script_file

3.2 組み込みコマンド

3.2.1 ヌルコマンド(:)
何もしないが、いつも成功を返すコマンド。

# 無限ループ
while :
do
  if .....
  then
    break
  fi
done

# 空ファイルの作成
$ : > file

3.2.7 evalコマンド
複数の変換処理を一度に実行。

$ VAR1=val
$ VAR2=$"$VAR1"
$ echo $VAR2
$val
$ eval echo $"$VAR2"                                                                                                                                               
val

3.2.10 exportコマンド
引数に指定した変数を、他のコマンドやシェルからも利用できるようにする。

3.2.12 readコマンド
キーボードからの入力を変数にセットする。

#!/bin/sh
echo -n "enter yes or no -->"
read ANSWER

3.2.13 readonlyコマンド
変数を書き換え不可にする。

3.2.19 typeコマンド
コマンドの取り扱いを表示。

$ type echo cd
echo is a shell builtin
echo is /bin/echo
cd is an alias for nocorrect cd
cd is a shell builtin
cd is /usr/bin/cd

3.2.20 umaskコマンド
ファイル生成時にどういうモードで作るかを決めれる。
ファイルの場合は666からumaskで指定した数字を指定したものができる。
デフォルト値は022なので、644のファイルができる。

$ umask
022
$ touch hoge
$ ls -l hoge
-rw-r--r--  1 user1  staff  0  2 10 10:34 hoge
$ umask 002
$ touch foo
$ ls -l foo
-rw-rw-r--  1 user1  staff  0  2 10 10:34 foo

3.2.21 unsetコマンド
変数や関数を消去する

3.2.22 waitコマンド
引数に渡したプロセスIDのプロセスが終了するまで待つ。

第4章リダイレクションによるファイル操作

4.1 ファイルディスクリプタ

0: 標準入力
1: 標準出力
2: 標準エラー

4.2 リダイレクト

リダイレクトとは、通常はキーボードからの入力を端末に出力するが、その入力元や出力先を変えること。

# 標準出力と標準エラーの両方をリダイレクト
$ cat abc def > nnn 2>&1

記法	説明
>file	標準出力をfileというファイルに書く
>file	標準出力をfileというファイルに追加書きする
>&m	標準出力をm番のファイルディスクリプタに書く
>&-	標準出力をクローズする
<file	標準入力をfileというファイルから読み込む
<&m	標準入力をm番のファイルディスクリプタから読み込む
<&-	標準入力をクローズする
<<word	標準入力をヒアドキュメントから読み込む

4.6 execコマンドとリダイレクション

execコマンドは、現在のシェルのプロセスをそのまま置き換えて新しいコマンドを実行させる。

# 標準出力を非表示に
exec > /dev/null

# 標準出力と標準エラーを非表示に
exec > /dev/null 2>&1 

# fileから入力する
exec < file

# n番目のファイルディスクリプタを使ってファイルをオープン
exec n> file

4.7 ファイルからの読み込み

# fileから一行ずつ読み込んで処理
while read LINE
do
   .....
done < file

4.10 ヒアドキュメント

# $VARは展開される
command << END
hoge is $VAR
END

# $VARは展開されない
command << \END
hoge is $VAR
END

# $VARは展開されない
command << 'END'
hoge is $VAR
END

# -をつけると行頭のtabが無視される
command <<- END
<tab>hoge is $VAR
END

# パイプにわたす
command << END | command
hoge is $VAR
END

第5章環境

5.3 ユーザ情報、マシン情報

5.3.1 ユーザ名の取得
USERやLOGNAMEという環境変数でも取得できるが、書き換えられるので信用はできない。

$ whoami
hoge_foo
$ logname
hoge_foo
$ sudo su -
# whoami
root # 切り替わる
# logname
hoge_foo # もとのまま

スーパーユーザのみで実行させたい場合は、ユーザidで判断する。

if id | grep "^uid=0(" > /dev/null 2>&1
then
  echo "Is superuser"
else
  echo "Is not superuser"
fi

5.4 シグナルの処理

プロセスはシグナルを受け取ると実行を中止する。ハンドリングするためには trapコマンドを使う。

trap command-list signal_number # シグナルを受け取って処理する
trap '' signal_number # シグナルを無視する
trap signal_number # シグナルをリセットする

# シングルクォートで渡して、後ほど展開させる
trap 'rm -f /tmp/*.$$; exit 1' 1 2 3 15

数字	種類	説明
1	ハングアップ(SIGHUP)
2	割り込み(SIGINT)	キーボードからの割り込みで中断させるためのキー。Ctrl-C
3	クイット(SIGQUIT)
9	キル(SIGKILL)	プロセスを強制終了させる。trap等でも捕まえることはできない。
15	終了(SIGTERM)	アプリケーションを終了させるときに用いられる。

第6章コマンド行の解析、処理

6.2 コマンド行の書き方

引数が -でスタートするとオプションとして認識されてしまうため、 --を前につける。

$ mkdir -- -p

6.3 シェルスクリプトでのオプション処理

getoptsコマンドを使う

FLAG=FALSE
VALUE=
OPT=
while getopts fv: OPT
do
  case $OPT in
    f) FLAG=TRUE ;;
    v) VALUE=$OPTARG ;;
    \?) echo "Usage: $0 [-f] [-v value]" 1>&2
         exit 1 
         ;;
  esac
done
shift `expr $OPTIND - 1`

第7章フィルタの使用法

7.2 sedコマンド

# 以下は同じ
cat file | sed -e 's/abc/ABC/'
sed -e 's/abc/ABC/' < file

# 慣習として使われてるだけで `/`のデリミータは任意の文字列でも大丈夫。
sed -e 's%abc%ABC%' file

7.3 sed を使っての編集

# 先頭に文字列追加
sed -e "s/^/top/"

# 末尾に文字列追加
sed -e "s/\$/top/"

# Pattern1とPattern2に囲まれてる部分の削除
sed -e "s/Pattern1*.Pattern2//"

# 大文字小文字の変換
cat file | tr '[a-z]' '[A-Z]' > upperfile

# タブをスペースに置換
sed -e "s/<tab>/<space>/"

# ホワイトスペースをスペースに置換
sed -e "s/[<tab><space>][<tab><space>]*/<space>/g"

# 空白行の削除
sed -e '/^[<tab><space>]*$/d'

# 行の指定
sed -e '5,$s/<tab>/<space>/g'

# 行の削除
sed -e '5,$d'

# 1行目からn行目まで表示
sed -n '1,np'

# BeginからEndの行を削除
sed -e '/Begin/,/End/d'

# ファイルを後ろから表示
grep -n '.*' | sort -n -r | sed 's/^[0-9]*://'

第8章シェルのいろいろな機能

8.6 ファイルとディレクトリ

# ファイル名やディレクトリ名の単体での取得
basename `pwd`
# ディレクトリ名の取得
dirname `pwd`

# dir以下のファイルとディレクトリをすべて表示
find dir -print

# カレントディレクトリ以下のディレクトリのみすべて表示
find . -type d -print

# カレントディレクトリ以下のファイルのみすべて表示
find . -type f -print

# カレントディレクトリ以下の.swiftファイルのみすべて表示
find . -type f -name '*.swift' -print

第11章デバッグの手順、手法

11.2 デバッグオプション

-vオプション: 何を実行しようとしているのかが表示される
-xオプション: 実行している途中経過が出色される

$ cat shscript
#!/bin/sh
ABC=0
for i in 1 2 3
do
  ABC=`expr $ABC + $i`
done
echo $ABC

$ sh -v shscript
#!/bin/sh
ABC=0
for i in 1 2 3
do
  ABC=`expr $ABC + $i`
done
expr $ABC + $i
expr $ABC + $i
expr $ABC + $i
echo $ABC
6

$ sh -x shscript
+ ABC=0
+ for i in 1 2 3
++ expr 0 + 1
+ ABC=1
+ for i in 1 2 3
++ expr 1 + 2
+ ABC=3
+ for i in 1 2 3
++ expr 3 + 3
+ ABC=6
+ echo 6
6

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

作者:ブルース・ブリン,Bruce Blinn
出版社/メーカー: ソフトバンククリエイティブ
発売日: 2003/02
メディア: 単行本

2020-01-07

「berlin.tech.meetup #1 ベルリンでエンジニアとして働く」に参加してきた

connpass.com

目的、モチベーション

海外で働きたいと思っていて、Twitterで拝見していたベルリンで働いてる方のお話を聞きたかった。

ベルリンは、ビザ取得のハードルが比較的低そうで、技術レベルが高そうで待遇も良ければ働いてみたいなという温度感だった。

感想

ベルリンでエンジニアとして実際に働くために必要な情報が広範に網羅されていて参考になった。

ビザの取得のしやすさばかりに気を取られていたが、実際に住んでみる上での話はあまり調べられてなかったので、面白かった。例えば、働く上でドイツ語はあまり必要ないとの話は聞いていたが、レイオフされたときに補償を受けるためなどで役所の手続きではドイツ語が必要になるなど、考えれば当たり前のことかもしれないが想像できていなかった。

また、エンジニアの人気都市の比較の紹介もあり、「海外で働ければどこでもいいや」ぐらいの温度感だったので、考えが甘かったなと思ったｗ

ベルリンに住んで週末はLCCでヨーロッパに出かけてる方がいると聞いて、以前は海外移住をハードルが高いものに思っていたが、1,2年だけ旅行気分で働くのもアリなのかなと思えた。
私は独身で身軽なので、英語と覚悟さえあれば、ベルリンで働けそうだと思った。

メモ

※ 悪意はないですが、ビザ情報等は必ずしも正確とは限らないので、一次情報を必ず参照してください。

「ベルリンでエンジニアとして働く」発表

クイズコーナー

ベルリンの最多外国人: トルコ人
移民政策の影響らしい。

ベルリンのテック企業のエンジニアチームの特徴

外国人が多い
- ドイツ人0の職場もある
なぜ英語が使われるのか？
- スタートアップの急増加して、外国人雇用が増える
- ビザが比較的簡単
- 元々、多様性のある都市（ベルリン崩壊で、東側の経済が崩壊して、いろんな人が集まった）

エンジニアの人気都市の比較

シリコンバレー

スタートアップ、大企業が多い
競争が激しい、ハードワークが求められる
給料も家賃も高い
GAFAの1会社では、中国・インドの移民が半分ぐらい占める
- エリート指向の人が多く集まるのでは？
- ベルリンはワークライフバランスを重視する方が多い？

ロンドン

スタートアップ、大企業結構多い
そこそこの給料、高い物価
Brexitによるビザへの影響

パリ

政府がスタートアップ都市を推進
- スタジオや、ビザとかのサポート
結構ドメスティック
- 英語OKの就労先が限定される

どうやって都市を選ぶ？

文化、環境に馴染めそうか

ワーク以外
- 外国人、アーティストが多い
- 多様性がある（LGBT、移民）
- 政治意識の高さ(移民政策、気候変動)
- 自然が多く、四季がある
- ドイツの首都、歴史がある
- 夜に遊べる、ナイトクラブ、地下鉄24h、ビールで賑やか
ワーク
- 有給25日以上（アメリカは半分ぐらいのイメージ）
- 病欠は別扱い(2,3日の場合は、医者の証明書が必要)
- 残業が少ない(9時スタート、18時にサクッと帰るイメージ)
- 個人のタスクが決まってる
- 多様性、フラット（イベントでダイバーシティ枠など）
- リモートワークも割と普及してる

就職先が多いか

AWS, Facebook, Microsoft, Zalando(社員1万人規模), Klarna(エンジニア300人ぐらい)などなど
失業、転職の際のリスクヘッジ
会社間の競争がまして、条件がよくなる（転居サポート）
コミュニティの充実

ビザが取りやすいか

ブルーカード（大卒以上、最低年収4.2万ユーロ）
- 最初は3,4年が多い
- 2,3年で無期限許可を取れる(ドイツ語が中級以上だと)
- EU永住許可もとれるので、他の都市で働けるようになる
就労ビザ
- 2,3年
ワーキングホリデー
- 1企業で働けるのは半年ぐらい
求職ビザ
- 現地で就活するための一時的なビザ

お金について

給与レベル

平均: 60k€
ジュニアで35k〜50k
ミドル: 50k〜65k
シニア: 6.5k〜
90k以上は結構頑張らないといけない

税金

未婚30歳で、ジュニア:36%, ミドル:40%, シニア: 42%

住宅費

人数	費用
一人暮らし、シェア	400-700€
一人暮らし、専用	500-1000€
ファミリー向け	800-2000€

生活費

1ヶ月乗り放題定期(地下鉄、バス) 80€
ケバブ 4€, コーヒー2€
ビール 1€
ジム 20-100€
一晩の遊び代 10-50€

モデルケース: 年収60k 独身エンジニアの場合

項目	費用
給料	額面5000€, 手取り3000€
家賃	900€
電気、通信費、テレビ代合計	100€
ジム	50€
交通費	80€
ランチの外食費	150€
食費	150€
その他交際費、旅行費など	500€
貯蓄 / 投資	1000€

仕事を見つける上で

必要なこと

英語力は必須
技術: 経験 or ポートフォリオ
CV & Cover Letter

業界、利用技術

増加傾向はフィンテック、モビリティ
スタートアップ多め
backend: JS&Node.js, Java, Rust
front: React(Native), Vue

よく使われるサイト

LinkedIn
Honeypot
Glassdoor
AngelList
リクルーター&紹介

情報収集

TechCrunchなどで調達調達
Glassdoorのレビュー
LinkedInですぐやめた人or内部の人を探して、コンタクトを取る

履歴書&カバーレター

履歴書は簡潔に1-2P
カバーレターは各社カスタマイズするだけで目立てる
Novoresumeなど便利なツールを活用する

面接

電話面接(自己紹介、ポジション　15-30分)
オンラインコーディングチャレンジ codewars 6-9級が目安?
課題&オンサイト
最終面接

日本からの就職活動

半分ぐらいの日本人は日本で行ってから移住
スタートアップなので渡航費は基本期待できない

厳しい現実

ドイツ語

意外と「ドイツ語オンリー」な状況（病院、役所）
超ローカル情報はドイツ語のみなことが多い
1,2年ならドイツ語をやらないと割り切るのもアリかも

住宅難

高騰する家賃
良い物件を見つけるまで時間がかかる
- 最初はairbnbで短期で借りて、期待せずじっくり探すとかが良いのでは

6ヶ月の試用期間

スタートアップでは結構簡単に切られる

不安定なスタートアップ

あっさりと行われるリストラ
1年働けば、半年の失業保険がでる

テクノロジーの活用に消極的

遅い、つながらないネット（地下鉄、）
キャッシュ文化（カード使えない場所も多い）
書面重視の文化（郵送で問い合わせしないといけないとか）
プライバシー重視（GAFAはあまり好まれておらず、Facebookでもなかなかつながらない）

寒くて暗い冬

短い日照時間
冬季うつ（ビタミンとったり、対処方法はある）

東京とベルリンの必須

色々な国の文化に触れられる、多様性
働く時間が減った: ワークライフバランス
- 一方で、緩いと感じる人も
気軽に旅行ができる
- LCCで数千円で週末旅行できる

自己紹介

佐藤有希(@yuki_sat)
2012年にベルリンへ
エンジニアではなく、フリーランスとして、スタートアップの取材をしてた
2018年にキャリアチェンジ
Ironhackを卒業して、ブロックチェーンのLiskのバックエンドエンジニア

Q&A

Q. 大学が無償というのを聞いたのですが、ベルリンのIT企業で働きながらベルリンの大学（コンピューターサイエンスなど）に無償で通う人はどのくらいいますか？
- A. 普通の学生は多いが、働きながら通う人は聞いたことない。
Q. 就労ビザの取得において、仕事内容と自分の持つ学位の関連性はどれくらい影響してきますか？修士or学士の違い、分野が異なる場合の影響が知りたいです
- A. ブルーカードは多少関係することもあるが、学士があれば文系でも就労ビザはとれる
Q. 例えばNZではエンジニアとしての実務経験があっても、コンピュータサイエンスまたはそれに近い学士が就職に必要だったりしますが、ドイツの場合は？
- A. 2問目と同じ

2020-01-05

「ハイパフォーマンスブラウザネットワーキング」を読んだ

ハイパフォーマンスブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

作者:Ilya Grigorik
出版社/メーカー: オライリージャパン
発売日: 2014/05/16
メディア: 大型本

目的、モチベーション

バックエンドのパフォーマンス改善の知識を深めるため。

全体の感想

広範にかつ様々なレイヤーでトピックがあり、バックエンド側に限らずネットワーク全般をカバーしていた。
HTTPやWebSocket, WebRTCなどのプロトコルや、モバイルデバイスを含むクライアント側のネットワークの種類の説明などが紹介されていた。
所謂バックエンドのサーバ改善だけを目的に読むのは微妙だが、トータルでパフォーマンス改善して、ユーザ体験を向上するためなら、網羅的に紹介されていてよかったと思う。
ただし、初版が2014年5月で少し古いので、HTTP2の説明は他の本を参考にした方が良さそう。

概要

今回はマイクロサービスにおけるバックエンドに関連の多かったI部しかまとめてないです。

I部　ネットワークの基礎

1章　レイテンシ・帯域幅入門

1.2 レイテンシを構成する多数の構成要素

種類	説明
伝播遅延	メッセージが送信元から宛先まで移動するためにかかる時間。距離を信号の伝搬速度で割ったもの。
伝送遅延	パケットの全ビットをリンクに載せるまでにかかる時間。パケット長とリンクのデータ転送速度の関数。
処理遅延	パケットヘッダの処理、ビットレベルのエラー検知、パケットの宛先決定にかかる時間。
キューイング遅延	パケットが処理できる状態になる前にキューで待機する時間。

1.3 光の速さと伝播遅延

当然だが、通信速度は光の速さが最大となる。光は地球を1秒間で約7周半できるため十分高速だと思われがちだが、実際の通信で何回か往復するため数秒になり、ユーザとしては不十分な速度となる。
そのため、CDNなどを利用してできるだけ物理的な距離を短くするか、圧縮などでデータ量を減らすことが重要。

2章　TCPの構成要素

2.1 3ウェイハンドシェイク

TCP接続を開始する際に、3ウェイハンドシェイクを行う。

SYN: クライアントは無作為にシーケンス番号xを選び、SYNパケットを送信。他のTCPフラグやオプションが含まれていることもある。
SYN ACK: サーバはxに1を加えてその値を確認応答番号とする。そして自信のシーケンス番号yを無作為に選び、自身のフラグとオプションを付加した上でレスポンスを送信する。
ACK: クライアントはxとyの両方に1を足し、xをシーケンス番号、yを確認応答番号としたACKパケットを送信してハンドシェイクを完了する。

これは数十msかかりコストが高いため、TCPコネクションの再利用の最適化が重要になる。

2.2 輻輳回避と輻輳制御

2.2.1 フロー制御
受信側が処理できないほどの大量のデータを送信しないように、受信ウィンドウサイズ(rwnd)でバッファサイズを指定できる。

2.2.2 スロースタート
クライアントとサーバ間のネットワークの利用状況に応じて、通信量をコントロールした方が効率的に利用できる。
しかしネットワークの状態は絶えず変化し、接続時には利用状況がわからないため、徐々にウインドウサイズを大きくしていくことで、解決する。
輻輳ウインドウサイズは、指数関数的に増加させていく。

そのため、TCP接続を再利用しない場合は、スロースタートしながら処理を開始するために、レイテンシーは大きくなる。

2.2.3 輻輳回避
パケットロスが発生したときに、セグメントを倍数的に減少させる。

2.5 TCPの最適化

サーバ設定のチューニング

サーバのカーネルのバージョンを最新にする
TCP 初期ウィンドウの増加
アイドル後のスロースタートを無効化
ウインドウスケーリングを有効にする

アプリケーションの動作のチューニング

不要なデータ送信を除去する
送信データを圧縮する
物理的に近い場所にサーバを設置する
TCP接続を再利用

3章　UDPの構成要素

4章　TLS

4.2 TLSハンドシェイク

下記のような流れで、TLSによる接続を確立する。

TCPコネクションを確立
クライアントが平文で動作仕様を送信
サーバがTLS プロトコルのバージョンや暗号スイートを決め、証明書を返す
クライアントがレスポンスに同意し、RSAかDiffie-Hellman鍵交換プロセスを開始し、セッションのための共通鍵を生成する
サーバはクライアントから送られた鍵交換パラメータを処理し、MACを検証することでメッセージの整合性を確認
クライアントは、サーバからのメッセージを共通鍵で復元してメッセージのMACを検証

4.3 TLSセッション再開（TLS Session Resumption）

TLSハンドシェイクはレイテンシと計算コストが必要となる。これを緩和するための機能が用意されている。

4.3.1 セッションID
サーバがセッションIDとパラメータ情報をキャッシュし、クライアントもセッションIDをキャッシュすることで、暗号スイートと鍵の生成プロセスをスキップして、パケットの往復を一回削れる。ただし、サーバがすべてのクライアントのセッションキャッシュを維持し続ける必要があり、大規模サービスでは複数のサーバ間でセッションを利用できるような工夫が必要。

4.3.2 セッションチケット
セッションIDでのデプロイメントの問題を払拭するために、セッションチケットが公開された。
この仕組みでは、サーバではセッション情報を保存せずに、TLSハンドシェイクの最後で、クライアントにセッションデータを返してクライアントが管理する。このセッション情報はサーバの秘密鍵で暗号化されているため安全。

4.6 TLSレコードプロトコル

4.7 TLSの最適化

4.7.4 TLS False Start
TLSのハンドシェイクの途中から、アプリケーションのデータの送信を行うことで、パケットの往復を減らすことができる。
ハンドシェイクのロジック自体は変更せずに、クライアントがデータを読み取れるようになる鍵の交換をした時点から、データのやり取りを行う。

4.7.6 TLS圧縮

サーバでのTLS圧縮は無効にすべき。
トランスポートレベルのTLS圧縮はコンテンツタイプを識別しないため、画像や動画などすでに圧縮されているデータを更に圧縮しようとする。そのため、二重に圧縮することでCPUを無駄に使用してしまう。

4.7.7 証明書チェーンの長さ

証明書チェーンのサイズを小さくするために、必要のない証明書はチェーンに含めないこと。
また、ルート証明書を含める必要もない。

II部　ワイヤレスネットワークのパフォーマンス

5章　ワイヤレスネットワーク入門

6章　WiFi

7章　モバイルネットワーク

8章　モバイルネットワークの最適化

III部　HTTP

9章　HTTPの歴史

10章　Webパフォーマンス入門

11章　HTTP 1.x

12章　HTTP 2.0

13章　アプリケーション配信最適化

IV部　ブラウザAPIとプロトコル

14章　ブラウザネットワーク入門

15章　XMLHttpRequest

16章　Server-Sent Events

17章　WebSocket

18章　WebRTC

次のアクション

ハイパフォーマンスブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

作者:Ilya Grigorik
出版社/メーカー: オライリージャパン
発売日: 2014/05/16
メディア: 大型本

2019-12-07

「OAuth徹底入門セキュアな認可システムを適用するための原則と実践」を読んだ

OAuth徹底入門セキュアな認可システムを適用するための原則と実践

作者:Justin Richer,Antonio Sanso
出版社/メーカー: 翔泳社
発売日: 2019/01/30
メディア: 単行本（ソフトカバー）

目的、モチベーション

OAuthの仕組みを雰囲気でしか理解していなかったので、理解を深めるため。
- 普通の認可と違い、何故セキュアなのか。
アプリケーションにSNS認証を導入する際に、どのように導入すればセキュアなのかを理解するため。

全体の感想

読み進めていくうちに、OAuthは認証プロトコルではなく移譲プロトコルであるというのが特に衝撃的で、OAuthのことを全く理解していなかったんだなと思った。
実際にコードを書いて簡単だが一連のやり取りを把握できたのが良かった。
また、何故このパラメータがないと脆弱性につながるのかなども詳しく説明してあり、理解も深まりやすかった。
入門書レベルだとは思うがボリュームもあり、OAuthを雰囲気で使っている人にはオススメ。

概要

github.com

英語版はこちら

OAuth 2 in Action

作者:Justin Richer,Antonio Sanso
出版社/メーカー: Manning Publications
発売日: 2017/03/18
メディア: ペーパーバック

第1章 OAuth 2.0とは何か？そして、なぜ気にかけるべきなのか？

OAuth2.0とは何か？

委譲プロトコルで、アプリケーション（twitterなど）のリソースの所有者に認可されるように許可を求めて、クライアント（twitterのデータを利用しているサービスなど）トークンによって所有者の代わりにアクセスできるようにする仕組み。
認可プロセスや暗号の方法などは定義しておらず、必ず認証がある訳ではなく、認証プロトコルでもない。

クレデンシャルの共有の問題点

クライアントが繰り返しパスワードを使うために、平文や可逆暗号でパスワードを保存してしまう
クライアントに与えるべきでない権限も付与してしまう

第2章 OAuthダンス - OAuthの構成要素間の相互作用

2.1　OAuth 2.0プロトコルの概要～トークンの取得と使用～

標準的な流れは以下の通り。

リソース所有者はクライアントにリソース所有者の代わりとして振る舞ってほしいことを指示する
クライアントは認可サーバにリクエストをし、そこでリソース所有者にクライアントを認可するかどうかの判断を行わせる
こうすることで、クライアントはクレデンシャルを知らないで済む
リソース所有者はクライアントを許可する
クライアントは認可サーバからトークンを受け取る
クライアントは保護対象リソースにトークンを提示する

2.2　OAuth 2.0における認可付与の詳細

認可コードによる付与（Authorization Code Grant）では、一時的なクレデンシャルである認可コードを使い、トークンを取得する。

リソース所有者がクライアントを許可すると、認可コードとともにクライアントにリダイレクトされる
クライアントは受け取った認可コードを、クライアント自身のクレデンシャルとともに認可サーバに送る
認可サーバは、認可コードのクライアントと、クレデンシャルのクライアントが一致した場合にトークンを返す（認可コードはrevokeされる）

2.4　トークン、スコープ、認可付与

アクセス・トークン
中身のないただの文字列で、クライアントは内容を知らずに扱うことができる。

スコープ
スペースで区切られた、保護対象リソースでの権限。

リフレッシュ・トークン
新しいアクセス・トークンを取得するのに必要なトークン。アクセス・トークンの期限が切れても、リソース所有者の認証を再度求めずに取得できる。

認可付与
OAuthのプロトコルを介して、アクセス権をクライアントが得る手段、即ちトークンを取得するフローのこと。

2.5　OAuthの構成要素間のやり取り

バック・チャネル・コミュニケーション
リソース所有者やブラウザ以外の、認可サーバやクライアント、保護対象リソースのHTTPのコミュニケーションのこと。

フロント・チャネル・コミュニケーション
サーバとの、ブラウザを介したコミュニケーションのこと。ブラウザを介すため、機密情報は渡らない方がベター。

第3章シンプルなOAuthクライアントの構築

第4章シンプルなOAuthの保護対象リソースの構築

第5章シンプルなOAuthの認可サーバの構築

この3つの章は、サンプルコードを元に実際に簡易なサーバを実装していった。手を動かすとイメージがつかめて良かった。
気になったのは下記。

stateパラメータははcallbackを直接叩かれ乗っ取りをされかけたときの防止策
Bearerは規約的には大文字小文字は区別しない

第6章実際の環境におけるOAuth 2.0

6.1　認可における付与方式

6.1.1 インプリシット付与方式

この付与形式では、認可エンドポイントから直接トークンを得る。

クライアントがブラウザ内部に埋め込まれたJavaScriptアプリケーションのような場合、認可コードによる付与を行う際に、認可コードをクライアントに返すとブラウザに認可コードが渡ってしまいクライアント以外も知ってしまうため、メリットがない。
ブラウザアプリケーションの場合、ユーザがいるためトークンが無効になっても再度認証を求められるため、TOFUも維持できる。

6.1.2 クライアント・クレデンシャルによる付与方式

バックエンドの認証などで、リソース所有者が明確に存在しなかったり、クライアント自体がリソース所有者の場合、この付与方式を用いる。
scopeなどを指定して、認可エンドポイントから直接トークンを得る。

6.1.3 リソース所有者のクレデンシャルによる付与方式

リソース所有者のクレデンシャルをクライアントに送り、それを使って認可サーバからアクセストークンを得る方法。
クライアントにクレデンシャルが渡り、アンチパターンなのでできれば避けるべき。

第7章よく狙われるクライアントの脆弱性

7.2　クライアントに対するCSRF攻撃

仕様ではstateパラメータは必須でないが、CSRF攻撃を防ぐために検証した方が良い。

7.3　クライアント・クレデンシャルの不当な取得

ネイティブ・アプリケーションなどは、デコンパイルされる可能性が0ではないため、クレデンシャルは動的に取得するようにして、各デバイス毎にクライアントIDを管理した方が安全。

7.4　リダイレクトURIの登録

リダイレクトURIは攻撃されやすく、バグも発生しやすいので、完全一致で検証するのがベスト。
サブディレクトリを検証しない場合、CGM型のサイトなどでユーザがページを作成できるときなどに、そのURLを指定されると漏洩の元になる。

HTTPリファラー: URLのパラメータにcodeが付与された状態で、攻撃者のページにリダイレクトした場合、imgやscriptを攻撃者のサイトにリクエストすることで、リファラー中のURLから盗まれる。
オープンリダイレクト: パラメータの値のURLを検証せずに、そのURLにリダイレクトしてしまうこと。URIフラグメントにトークン情報を含めた状態でリダイレクトすると盗まれる。

7.6　トークンの不正な取得

Authorizationヘッダを利用できず、URLのパラメータに含める場合は攻撃されやすくなるので、注意が必要。

access.logなどにパラメータとして書き出される
オンライン掲示板などに、ユーザが意図せず貼ってしまう
リファラーヘッダにトークンが含まれる

第8章よく狙われる保護対象リソースの脆弱性

8.2　保護対象リソースのエンドポイントの設計

HTTPヘッダを適切に設定すれば、XSS対策をより安全に行える。

ヘッダ	説明
Content-Type	jsonを指定することで、ブラウザがXSSから保護する
X-Content-Type-Options	MIMEスニッフィングを防ぐ。
X-XSS-Protection	自動的にXSS攻撃を除外

8.3　トークンのリプレイ攻撃

OAuth2.0ではTLSが前提となっているが、HSTS(HTTP Strict Transport Security)を使えば、サーバ側で安全なHTTPSのみを使うように宣言できる。
使い方は、レスポンスのヘッダに Strict-Transport-Securityを設定する。

第9章よく狙われる認可サーバの脆弱性

認可コード
- 一度使われたら、破棄する(URLに含まれるため、ブラウザの履歴などに残ってしまう可能性がある)
- クライアントが一致するか確認する
リダイレクト
- 絶対に、何の検証もなしにリダイレクトしないこと
- バグの元なので、redirect_uriは極力完全一致するか検証する
- エラーを返す際にも、Refererヘッダなどを介して情報漏洩しないように注意する

第10章よく狙われるOAuthトークンの脆弱性

トークンはシンプルである一方で、盗まれた際には何でもできてしまうため、工夫が必要。

盗まれないように保護
- 通信: TLSのような安全なトランスポート層の仕組みを使う
- 認可コード: PKCEで保護する
盗まれてしまった際の被害を小さくする
- クライアント: 必要最低限のscopeのトークンを要求する
- 認可サーバ: 有効期限を短くする
サーバを攻撃されてしまった際の被害を小さくする
- 認可サーバ: トークンをハッシュ値で保存する
- リソースサーバ: キャッシュする場合は、一時的なメモリを使用する

第11章 OAuthトークン

11.1　OAuthにおけるトークンとは何か？

OAuthでは、トークンの形式は定められていない。

よく用いられる乱数のトークンは、サイズを小さく保ちつつ、文字列を更に乱雑にすることでセキュアにできる。その一方で、認可サーバと保護対象リソースとの間でデータソースを共有できない場合は、通信処理がボトルネックになったりするなどのデメリットもある。

11.2　JWT（JSON Web Token）

トークンそのものに、必要な情報を詰め込んだものの例として、JWTが紹介されていた。
内部に情報を持つことで、認可サーバを介さずにリソースサーバがトークンの有効性やスコープを確認することができる。

11.2.1 JWTの構造
.で区切られた３つのパート(header, payload, verify signature)の文字列から成る。文字列はJSONオブジェクトをBase64 エンコードされている。
トークンが盗まれた場合、デコードされるとpayloadの情報が読み取れてしまうので、HTTPSを使いかつ機密情報はトークンに含めないこと。
Base64でエンコードされているのは、トークンを受け渡してる間にエンコードされてしまったり（URLのパーセントエンコーディングなど）して、処理を煩雑にしないための工夫である。

11.3　JOSE（JSON Object Signing and Encryption）

JWTでは、署名のアルゴリズムを指定することができる。
例として、RS256を使うと秘密鍵を認証サーバで管理して、公開鍵をリソースサーバが受け取り検証することでセキュアに検証できる。

トークン内の情報を暗号化するためにJWE(JSON Web Encryption)という仕組みもある。

11.4　トークン・イントロスペクション（Token Introspection）

トークン自身に情報を持たせると、scopeを最新の状態に更新できないなどのデメリットもある。それを解決する一つが、Token Introspection。認可サーバに /introspectのようなエンドポイントを用意し、tokenの詳細の情報を取得できるようにして解決するプロトコルである。
ただし、リクエスト数が増えて認可サーバに負荷がかかるので、リソースサーバ側でキャッシュするなどの工夫が必要。

11.5　トークン取り消し（Token Revocation）

ユーザがログアウトしたなど、クライアントが能動的にトークンを無効にしたい場合には、Token Revocationを利用する。
単にアクセストークンとリフレッシュトークンを無効にするだけだが、攻撃されないように、トークンのクライアントとリクエストしてきたクライアントが一致するかの検証を行い、無効であったとしても201を返すこと。401を返すとDoS攻撃が行われ、他のクライアントでトークンが有効であることがわかってしまう。

第12章動的クライアント登録（Dynamic Client Registration）

スケーラビリティを確保し、クライアントとの信頼関係を築くために動的にクライアントの管理を行いましょうという話だった。

第13章 OAuth2.0を使ったユーザ認証

OAuth 2.0自身は認証プロトコルでないが、認証プロトコルを構築するために用いられることもある。
その例として、OpenID Connectが紹介されていた。

第14章 OAuth2.0を使うプロトコルとプロファイル

OAuth2.0を拡張したプロトコルやプロファイルが紹介されていた。

14.1　UMA（User Managed Access）

第三者に自分のリソースの利用をクライアントで利用するのを許可する(ex. Aliceが自身のリソースの利用を、Bobに利用許可するとき)を安全に管理するために、UMA（User Managed Access）が利用できる。
UMAでは、自分のリソースポリシーを設定し、Aliceを介さずにトークンを取得できる。また、トークンも第三者である利用者毎に発行できるため、revokeなどの処理も行える。

処理の流れとしては、通常のOAuthに加えて、リソース所有者がポリシーを先に設定し、リソースサーバはトークンが有効な権限を持つか検証しないといけない。

14.2　HEART（HEAlth Relationship Trust）

OAuthは柔軟な反面、相互運用性や互換性の確保が難しい。医療分野などの単一分野を取り扱っている場合、共通のAPIを利用することがよくあり、サーバ同士が連携しやすいように、ガイドラインが利便性が高まる。
その一例として、HEART（HEAlth Relationship Trust）が紹介されていた。

14.3　iGov（international Government assurance）

HEARTと同じように、行政機関で使われることを目指すiGov（international Government assurance）が紹介されていた。
行政機関のシステムは、長期間使用される一方で、システムのアップデートが遅くなったりする傾向もあるため、互換性が担保できるように慎重に策定する必要がある。

第15章 Bearerトークンの次のもの

Bearerトークンはシンプルなため、トークンを奪われると再利用されてしまう。
よりセキュアな所有証明（Proof of Possession：PoP）トークンと、TLSトークン・バインディングが紹介されていた。

OAuth徹底入門セキュアな認可システムを適用するための原則と実践

作者:Justin Richer,Antonio Sanso
出版社/メーカー: 翔泳社
発売日: 2019/01/30
メディア: 単行本（ソフトカバー）

目的、モチベーション

全体の感想

目次

メモ

第1章 知らずには生き残れない、デジタル化する世界の本質

1-5 デジタル中国の本質 データが市民の行動を変え、社会を変える

第2章 アフターデジタル時代のOMO型ビジネス～必要な視点転換～

2-1 ビフォアデジタルとアフターデジタル

2-2 OMO：リアルとデジタルを分ける時代の終焉

2-3 ECはやがてなくなっていく

2-4 転覆され続ける既存業態

第3章 アフターデジタル事例による思考訓練

3-1 GDPR vs 中国データ共産主義 〜データの取り扱いをめぐる議論〜

3-2 「レアな接点」に価値がある時代

目的、モチベーション

全体の感想

目次

概要

第1章 書き方にかかわる基本的な説明

1.4 ファイル名称の補完

1.5 引用符の使い方

1.9 コマンドのグルーピング

1.10 制御文

第2章 シェル変数

2.5 位置パラメータ, 2.6 特殊な変数

第3章 シェル関数、組み込みコマンド

3.1 シェル関数

3.2 組み込みコマンド

第4章 リダイレクションによるファイル操作

4.1 ファイルディスクリプタ

4.2 リダイレクト

4.6 execコマンドとリダイレクション

4.7 ファイルからの読み込み

4.10 ヒアドキュメント

第5章 環境

5.3 ユーザ情報、マシン情報

5.4 シグナルの処理

第6章 コマンド行の解析、処理

6.2 コマンド行の書き方

6.3 シェルスクリプトでのオプション処理

第7章 フィルタの使用法

7.2 sedコマンド

7.3 sed を使っての編集

第8章 シェルのいろいろな機能

8.6 ファイルとディレクトリ

第11章 デバッグの手順、手法

11.2 デバッグオプション

目的、モチベーション

感想

メモ

「ベルリンでエンジニアとして働く」発表

クイズコーナー

ベルリンのテック企業のエンジニアチームの特徴

エンジニアの人気都市の比較

どうやって都市を選ぶ？

お金について

仕事を見つける上で

厳しい現実

東京とベルリンの必須

自己紹介

Q&A

目的、モチベーション

全体の感想

目次

概要

I部 ネットワークの基礎

1章 レイテンシ・帯域幅入門

1.2 レイテンシを構成する多数の構成要素

1.3 光の速さと伝播遅延

2章 TCPの構成要素

2.1 3ウェイハンドシェイク

2.2 輻輳回避と輻輳制御

2.5 TCPの最適化

3章 UDPの構成要素

4章 TLS

4.2 TLSハンドシェイク

4.3 TLSセッション再開（TLS Session Resumption）

4.6 TLSレコードプロトコル

4.7 TLSの最適化

II部 ワイヤレスネットワークのパフォーマンス

第1章知らずには生き残れない、デジタル化する世界の本質

1-5　デジタル中国の本質　データが市民の行動を変え、社会を変える

第2章アフターデジタル時代のOMO型ビジネス～必要な視点転換～

2-1　ビフォアデジタルとアフターデジタル

2-2　OMO：リアルとデジタルを分ける時代の終焉

2-3　ECはやがてなくなっていく

2-4　転覆され続ける既存業態

第3章アフターデジタル事例による思考訓練

3-1　GDPR vs 中国データ共産主義〜データの取り扱いをめぐる議論〜

3-2　「レアな接点」に価値がある時代

第1章書き方にかかわる基本的な説明

第2章シェル変数

第3章シェル関数、組み込みコマンド

第4章リダイレクションによるファイル操作

第5章環境

第6章コマンド行の解析、処理

第7章フィルタの使用法

第8章シェルのいろいろな機能

第11章デバッグの手順、手法

I部　ネットワークの基礎

1章　レイテンシ・帯域幅入門

2章　TCPの構成要素

3章　UDPの構成要素

4章　TLS

II部　ワイヤレスネットワークのパフォーマンス

5章　ワイヤレスネットワーク入門

6章　WiFi

7章　モバイルネットワーク

8章　モバイルネットワークの最適化

III部　HTTP

9章　HTTPの歴史

10章　Webパフォーマンス入門

11章　HTTP 1.x

12章　HTTP 2.0

13章　アプリケーション配信最適化

IV部　ブラウザAPIとプロトコル

14章　ブラウザネットワーク入門

15章　XMLHttpRequest

16章　Server-Sent Events

17章　WebSocket

18章　WebRTC

2.1　OAuth 2.0プロトコルの概要～トークンの取得と使用～

2.2　OAuth 2.0における認可付与の詳細

2.4　トークン、スコープ、認可付与

2.5　OAuthの構成要素間のやり取り

第3章シンプルなOAuthクライアントの構築

第4章シンプルなOAuthの保護対象リソースの構築

第5章シンプルなOAuthの認可サーバの構築

第6章実際の環境におけるOAuth 2.0

6.1　認可における付与方式

第7章よく狙われるクライアントの脆弱性

7.2　クライアントに対するCSRF攻撃

7.3　クライアント・クレデンシャルの不当な取得

7.4　リダイレクトURIの登録

7.6　トークンの不正な取得

第8章よく狙われる保護対象リソースの脆弱性

8.2　保護対象リソースのエンドポイントの設計

8.3　トークンのリプレイ攻撃

第9章よく狙われる認可サーバの脆弱性

第10章よく狙われるOAuthトークンの脆弱性

11.1　OAuthにおけるトークンとは何か？

11.2　JWT（JSON Web Token）

11.3　JOSE（JSON Object Signing and Encryption）

11.4　トークン・イントロスペクション（Token Introspection）

11.5　トークン取り消し（Token Revocation）

第12章動的クライアント登録（Dynamic Client Registration）

14.1　UMA（User Managed Access）

14.2　HEART（HEAlth Relationship Trust）

14.3　iGov（international Government assurance）