プログラミング Tips

ITエンジニアの雑記ブログ。
IT関連ニュースの考察や、プログラミングに関するTipsの備忘録として…
育児や日常の雑記帳としても、記事を投稿していきます。

プログラミングと日常生活に関する情報を発信しています。

2017年10月

前回の投稿で、HTTP通信はレスポンス送信後に
毎回切断される仕様であることがわかった。

では、切断せず…接続を継続するにはどうすればいいのか?
方法はないのだろうか?

調べてみたので、まとめてみる。

「HTTPのバージョンで決まる!!」が答え

単純明快だったので、なんの焦らしもなく、答えを書いてしまった笑。

通信において、クライアントとサーバーがどのバージョンのHTTP接続を用いているかによって変わる。

【HTTP1.0】の場合

クライアント、サーバーのいずれかが"HTTP1.0のみ"のサポートの場合がこれにあたる。
クライアントからのリクエストに対して、サーバーはHTTPヘッダーと要求されたHTMLドキュメントもしくは画像ファイルなどのバイナリをレスポンスし終えると接続が切れる。
別のページや画像が要求されると、再接続してGET命令を送り、サーバーはレスポンスが終わると切断する。

つまり必要な時に、必要な分だけ接続されるのである。

この接続方法は、インターネット全体に流れるトラフィックを減らせるだけでなく、サーバーの帯域負荷も低減できる。
一方で、毎回TCP/IPでの接続手順を繰り返すことになる為、レスポンスは低下する。

しかし!!

Connection: Keep-Alive
をHTTPヘッダーに追加すると接続を維持することができる。
英文表記そのままであるが、接続を維持せよ!という命令である。

クライアントがGETリクエストを送信する際、この指定を同時にサーバーに送り、それに対してサーバーからも"Connection: Keep-Alive"と返って来れば、接続は維持される。
接続が維持されている間は、GETなどの命令を連続で送信することができ、その都度、TCP/IPの接続が繰り返されることが起きなくなる。

また、サーバー・クライアントのいずれかが、"Connection: close"を指定するとレスポンス終了後に切断される。


【HTTP1.1】 の場合

HTTP1.1の場合、クライアント・サーバー両方がHTTP1.1対応が前提となり、
1.0と違って最初からクライアント・サーバー共に"Keep-Alive"で動作する。

よって、明示的に"Connection: Keep-Alive"をヘッダーに宣言してリクエストする必要はない。

ちなみに実際には、ブラウザは"GET / HTTP/1.1"のGET命令と同時に"Connection: Keep-Alive"を送信しているケースも少なくない。



ところで…
「HTTPのバージョンの違いって?」って思ったので、調べてみた

HTTPのバージョン差異

例えば、"GET / HTTP/1.0"というリクエストに対して、"HTTP/1.1 200 OK"と返ってきた場合、
サーバー側は1.1に対応していることがわかる。

では、"GET / HTTP/1.1"というリクエストに変えた方がいいのか??
答えは「NO」だ。

TCP/IPのモニタリングソフトで見ると、一部ブラウザはGET命令を"HTTP/1.0"で送信している。
HTTP通信には、下位互換があるため、1.1対応のサーバーに対して1.0でリクエストを送っても正しく動作する。

つまり、GET命令を送信する場合、クライアント側が1.1を指定する必要はないのである。


さて、ここまで書いておいて…なんだが、2015年に"HTTP/2"がすでにリリースされていて、
"HTTP1.1"から順次移行が進むと考えられる。

現時点で1.0はほぼ皆無だろう…

今回はHTTPバージョンの差異をしりたかったので、とりあえず1.0/1.1を対象にしてしまったが、
近々2.0についても勉強していきたいと思う。



HTTP通信の中身は、基本的にテキストベース。

ただし、テキストを使ってHTTP通信を開始するには、
TCP/IP通信でサーバーとクライアントが接続されている必要がある。

HTTPだけでは、URLからIPアドレスへの変換や、サーバーへの経路探索、
コネクションの確立などの動作はできない。

つまり、HTTPというのはTCP/IPで接続された上を、
テキストでやり取りする仕組みといえる。

メールで使われているプロトコルのSMTPやPOP3なども同様。

HTTP通信の中身を確認するためには、
  1. ブラウザとサーバー間をモニタリングする
  2. 手動でサーバーとやり取りする
がある。

ブラウザとサーバー感をモニタリングする

TCP/IPのモニタリングソフトを使ってブラウザなどのアプリケーションが
Webサーバーとどのような通信を行なっているかを確認する。

モニタリングソフトを使うと、実際に
  • ブラウザがWebサーバーに送っているリクエスト
  • Webサーバーがブラウザに返しているレスポンス
を確認できる。

モニタリングソフトは基本的にHTTだけを監視するわけではなく、
TCP/IP通信全体を監視するため、慣れるまで必要な通信を探し出すのは
少し大変かもしれない…

TCP/IPをモニタリングすることで、
「PCは想像以上に様々な通信を裏で行なっている」
ことに気づくと思う。


手動でサーバーとやり取りする

"TeraTerm"や"Putty"などのTelnetやSSHクライアントソフトを利用して行う。
接続先として、WebサーバーのURLまたはIPアドレスとポート番号「80」を指定し接続する。

そして、表示される画面上に
"GET / HTTP/1.0"
と入力して、「Enter」を入力すると、WebサーバーからレスポンスやHTTPヘッダー、
要求されたページのHTMLデータがテキストで返ってくる。

ただし、HTTPの接続は持続的な接続をしないため、サーバー側がHTMLデータの
レスポンス送信が終わると切断される。

この影響で、クライアントソフトによっては、通信終了時にウィンドウが閉じてしまう場合がある。
通信終了に閉じる機能を無効化するオプションがあれば、設定しておくことをオススメしたい。


クライアントソフトを使わずに、C#やVisual Basicなどのプログラミング言語を使って
HTTPによる通信を行う場合、ソケット通信という形でサーバーと接続し、GETなどの
HTTP命令をテキストで送信すればWEBサーバーと通信できる。


WEBブラウザでサイトにアクセスする場合、URL欄に
"http://fizz.buzz/"
と入力すると、サーバーとブラウザ間では、GETの通信が発生する。

下記のようなページ遷移もGET通信で行われる。
  • リンクのクリック
  • ブックマークから移動
HTTPプロトコルで、ブラウザからサーバーへの要求を「リクエスト」、
リクエストに対してサーバーからの返答を「レスポンス」と呼ぶ。

URLを指定した場合のリクエストは、

"GET / HTTP/1.0"
のようになる。

リクエストは3つに分けられる。最初の「GET」が命令、真ん中の「/」は
ドキュメントルートのことを指す。

もし"http://fizz.buzz/index.html"と入力すると、リクエストは

"GET /index.html HTTP/1.0"
となる。ドメイン部分を除いたURLがリクエストとしてサーバーに送られる。

最後の"HTTP/1.0"は、クライアント側が使用しているHTTPのバージョンを示す。
ブラウザではなくTelnet端末やSSH端末でWEBサーバーに接続して、
"GET / HTTP/1.0"と入力して送信するとドキュメントルートが存在すれば
"HTTP/1.0 200 OK"のようなレスポンスが返る。

"/"を指定するだけでindex.htmlが返るのは、WEBサーバー側の仕様。
WEBサーバーには、多くでApatchが使われている。

一般的にApatchの初期設定では、"/"がリクエストされた際、ブラウザが
最初にアクセスするルートディレクトリに"index.html"や"index.php"があれば、
それをクライアントに返す。

この設定は、サーバー管理者側で自由に変更できる。
例えば…
  • ファイル名まで指定されていない時にはエラーを返す
  • ディレクトリにあるファイルの一覧を返す
などの設定も可能。
つまり厳密にいうなら、HTTPではドメイン名だけでなく、
ファイル名まで明記することが望ましい。

GETは文字通り「取得のため」の命令。
WEBサーバーは、クライアントブラウザから要求されたファイルが存在する場合、
"HTTP/1.0 200 OK"のレスポンスと、リクエストされたタイムスタンプ、
サーバープログラム名、要求されたファイルのサイズ、クッキー(cookie)などを含む
HTTPヘッダーをレスポンスし、続いてHTMLの内容を送信。

HTTPヘッダーに含まれる情報は決まっておらず、サーバーごとに異なる。
HTMLヘッダーの扱いに似ていて、ブラウザ上には表示されない。

またHTML内で、<img>タグを使って画像などの別ファイルを呼び出している場合、
ブラウザはその部分のHTMLを読み込む度に
"GET /img/hoge.jpg HTTP/1.0"
のような形で必要な分だけGET命令を送信する。

単純にWEBサイトを閲覧する場合、ほぼ100%がGET命令のみで成り立っている。





HTML5、JavaScriptとCSSを勉強するにあたって、
WEBブラウザについての情報からまとめる。

まずWEBブラウザの基本機能は下記3つ
  1. 通信ソフト
  2. レンダリングエンジン
  3. スクリプトエンジン

通信ソフト

WEBブラウザは、WEBサーバーとの通信仕様であるHTTPを使って、
サーバーに保管されているHTMLドキュメントをダウンロードする。


レンダリングエンジン

WEBサーバーから取得したHTMLドキュメントは、単純なテキストファイル。
WEBブラウザは、HTMLで参照している画像(<img>タグ)や、外部リンクされた
スクリプト(<script src>)、CSS(<link>)をファイルを順次ダウンロードする為、
WEBブラウザの通信ソフトの機能は、HTMLを理解しているということがわかる。

HTML本体と関連コンテンツをダウンロードしたら、WEBブラウザの画面で
見られるような形に成形する必要がある。

HTMLからタグを除去して、<h1>で囲まれた部分を大きな字に、<br>や<p>〜</p>で改行、
<table>による表組み、<img>部分への画像の書出しが必要。


スクリプトエンジン

HTMLを読める形に変換するだけでなく、CSSによる装飾もレンダリングエンジンが行う。
最新のCSSに対応しているかどうかはこのレンダリングエンジンの性能によって決まる。

JavaScriptのプログラムを動作させるための「スクリプトエンジン」も備えている。
JavaScriptプログラムは単純テキストで記述されていて、そのままCPUが解釈・実行できる
コンパイルされたプログラムではない。

よってWEBブラウザは、ソースコードを適宜コンパイルしながら、CPUが処理できる
コードに変換して動作させる必要がある。

スクリプトエンジンがソースコードを解釈して実行する速度が速いほど、ブラウザの閲覧は
快適ということになる。ブラウザ各社ごとに、速度を比較しているがこのスクリプトエンジンの
速度だ。

例えば、有名なスクリプトエンジンにGoogle Chromeが搭載ている「V8」がある。
V8は逐次コンパイルといった形を取らず、JavaScriptプログラムを読み込むと、
同時にCPUが理解できるネイティブコードへコンパイルすることで高速化を実現している。



色々な記事でも取り上げられているから、
すでに知っている人も多いと思うが、Googleから自動翻訳のデバイスが発表された!

159ドルで40カ国語が翻訳されるらしい。
しかも無線イヤホンタイプで見た目もおしゃれ…

これだけみて、まさにドラえもんの「ほんやくこんにゃくじゃないか!?」と思った笑


There's a new and formidable presence in the smart headphone market — Google.
訳:Googleはスマートヘッドフォン市場に新たな価値を見出した

Googleがスマードフォン市場へ乗り出し、更にAI工学を切り拓いてきたが、
新たに目をつけたのがスマーフォン市場ということである。

個人的には理にかなった選択だと思った。

理由は主に2つ
  1. 先進国のインターネット普及率が約85%、全世界でも約53%と過半数を超えてきた
  2. スマホ普及率が先進国全体で半数を超えてきた
つまり先進国において、スマホを通じて常にインターネット接続環境を
有している人は先進国の半数以上になっている。スマホを介さなくとも
インターネット環境が身近にある人も、半数を超えている。

その結果、現在の不便な事柄はインターネットを介したサービスで便利になる可能性を
秘めているということということができ、「翻訳」はまさにそのうちの一つであると思うし、
その機能をイヤホンを介したサービスとすることで、場所を選ばずにユーザの好きな場所と
時間で実現することができるのである。


Tethered to an Android phone, the buds can do nearly real-time translation in 40 languages. 
訳:Android端末に接続すると、40ヶ国の言語でほぼリアルタイムで翻訳を行うことができる。

更にこの機能はスマートフォンを介してインターネット上で翻訳を行うため
翻訳機能をイヤホンやスマホ内に閉じ込める必要がないため、プログラミング容量も
ほぼ無制限で利用できる。唯一必要なのはネットワーク通信速度くらいだが…

そちらも最近の通信環境はどんどん改善されているし、すくなくとも今後に向けて
進化することはあっても退化することにはならない分野である。

よって40ヶ国語に対応した点も不思議ではなく、必然と言える。
今後更に増えて行くことも想像に難しくない。


Pixel Buds offer about five hours of listening time on a single charge, and they ship with a charging case that can ratchet that up to about 24 hours.

訳:このデバイスは1回の充電で約5時間動作し、24時間までラッチングできる充電ケースを
同梱している。

起きている間常に動作して欲しいと思ったのは事実だが、ビジネスシーンにおいて、
5時間もでは全体の半分以上であるし、長時間持つ仕組みは小型化、軽量化には
反比例の関係にあるため、大きく重くなることは避けられなくなる。

よって、現時点で5時間は十分ではないかと考えた。


Google's offering them in three colors — Kinda Blue, Just Black, and Clearly White — for $159. Pre-orders start today, and the devices ship in November.
訳:Googleから、青・黒・白の3色が159ドルで発売予定。予約注文はすでに開始され、発送は11月になる。

159ドルは日本円で18,000円程度に換算される。
この価格を高いというか?手頃というか?は判断に難しいところである。

しかし現時点においても10,000円前後の無線イヤホンを持ったユーザーはいるが、
40ヶ国分の翻訳機能まで備え付けた機能は有していない。

よって、その点を付加価値と捉えると価格増に理解は得られると判断する。


以上から、このイヤホン型翻訳デバイスから目が離せない!

少し話はそれるが、このようなデバイスが普及し、更に翻訳制度が上昇すると
通訳という仕事が不要になるかもしれないし、バイリンガル、トリリンガルなど
「複数言語を話せる」ということは他者と比較した場合、差別化のポイントに
なりにくくなりそう。

AIが発達して、職を奪う…という話、
通訳関連も安泰ではないかもしれない…


出展はここ

↑このページのトップヘ

-->