ネットワークスクランブルHTTP 2版物理本に対する訂正

woshidan.hatenablog.com

2版紙本の(及び1版紙本)にて上記エントリに追加で以下の修正が見つかりました。

電子版では修正されていますが、物理版は修正が間に合いませんでしたので必要に応じて下記をご参照ください。

ページ数	訂正前	訂正後
p.12	ところでTCPのハンドシェイクでは、最初にSYNセグメントを送ったクライアントとサーバからSYN+ACKセグメントを受け取るクライアントが一致しない場合、コネクションが確立されません。これを利用すると、コネクションが確立できるかどうかによって、クライアントが送信元IPアドレスを偽装していないかの確認ができるわけですね。この送信元IPアドレスの真偽確認により、たとえば犠牲者のコンピュータへ大量のレスポンスをサーバに返送させるリフレクション攻撃のようなセキュリティ上の危険を防いでいます。	ところで、TCP Fast Openではハンドシェイクを経ずにアプリケーションデータを送信できます。ということは、いきなり大きなアプリケーションデータのついたSYNセグメントをたくさん送りつけることでサーバのメモリを比較的簡単にあふれさせることができそうですね。
p.12	IPアドレスを偽装してないよ	一度ハンドシェイクをきちんとした相手だよ
p.12	具体的には、偽装してないかの確認でもある初回ハンドシェイクの時点から	具体的には、初回ハンドシェイクの時点から
p.13	サーバに送信可能です。	サーバに送信可能です。サーバはCookieが有効な場合のみ、データをバッファに格納します。
p.26	ファイルパスなどの設定でできる?	Webサーバでgzip圧縮用設定を行う際にファイル形式の指定を行うなどの形で可能です[久保達彦・道井俊介(2016)『nginx実践入門』(WEB+DB PRESS plus)、電子版「動的なgzip圧縮」、技術評論社]
p.29	15番	14番
p.51	// style.cssについてはサーバプッシュを行わないが、script.jsについては	// style.cssについてはサーバプッシュを行わないが、script.jsについてはサーバプッシュを行う
p.51	HTMLのドキュメント本体の処理と並行してHTMLが必要とするリソースを先読みさせるというものです。そして、ブラウザ上で動くWebサイトなどのアプリケーションから見た場合、ブラウザがHTMLのパースと並行して先読みするリソースの順序を調整する、というだけで両者に違いはありません。	この挙動はServer Pushのものとよく似ていて、どちらのリクエストに対するレスポンスもブラウザをはじめとしたユーザーエージェントにキャッシュされます。また、どちらで取得されたレスポンスに対する処理もクライアントがキャッシュと合致するリクエストを投げたときに実行します。
p.62	しかし、肝心の実装状況がFirefoxではバージョン58で対応されていますが、Google ChromeについてはChromiumの関連issueがオープンのまま未対応という状況なので、	実装状況についてはFirefoxではバージョン58やChromeにて対応されていますがすべてのブラウザでサポートされているわけではないので*1