2011年1月11日付けでウィルコムのIPアドレス帯域に追加があったようです
    このエントリをはてなブックマークに登録

2012/1/17 火曜日 matsui Posted in Willcom, サーバ, ニュース No Comments »

気づくのが遅れてしまいましたが、2011年1月11日付けでウィルコムのIPアドレス帯域に追加があったようです。

 

→　WILLCOM　ウィルコムのセンター情報 [willcom-inc.com]

 

追加IPアドレス帯域（2012年1月11日追加分）

125.28.6.0/24
125.28.7.0/24
125.28.11.0/24
125.28.12.0/24
125.28.13.0/24
125.28.14.0/24
211.18.238.0/24
211.18.239.0/24
219.108.2.0/24
219.108.3.0/24
219.108.4.0/24
219.108.5.0/24
219.108.6.0/24
221.119.5.0/24

 

上記の帯域からもうアクセスが来ているかどうかは確認できていませんが、まだ作業をしてないサイト管理者の方は、なるべく早めに対応した方がよさそうです。

 

関連：

タグ: , ,



2011年11月24日付けでspモードのIPアドレス帯域に追加が行われるようです
    このエントリをはてなブックマークに登録

2011/11/15 火曜日 matsui Posted in DoCoMo, サーバ, ニュース No Comments »

2011年11月24日付けで、ドコモのspモードのIPアドレス帯域に追加が行われるようです。

 

→　NTTドコモ　作ろうスマートフォンコンテンツ　その他技術情報　IPアドレス帯域 [nttdocomo.co.jp]

 

追加となる帯域は次の通りです。

1.78.0.0/19
1.78.32.0/21
1.78.40.0/22

 

「2011年11月24日に追加予定」となっています。

spモードの帯域で制限をかけている方は対応が必要になりますのでご注意ください。

 

関連：



iPhoneやAndroidからのSSLアクセスを早くするテクニックが紹介された記事「モバイルウェブ環境のHTTPSのチューニング」
    このエントリをはてなブックマークに登録

2011/10/27 木曜日 matsui Posted in サーバ, 記事紹介・リンク No Comments »

NAVERのエンジニアブログに、モバイルネタの記事がありましたのでご紹介させていただきます。

iPhoneやAndroidアプリからアクセスがあった場合のhttps応答速度をあげるためのチューニング方法が書かれた記事です。

 

→　NAVER Engineers’ Blog　モバイルウェブ環境のHTTPSのチューニング [tech.naver.jp]

 

上記の記事によりますと、iPhoneやAndroidからのhttpsアクセスは、SSLのHandshakeで時間を喰ってしまっているようです。

１.SSL handshakeの遅延を減らす。
２.SSL handshakeの回数を減らす。

という2つ方法を実現するための具体的な設定が書かれています。

 

iPhone（Cocoa frameworkのNSURL）の場合は、バッテリの消耗を防ぐためか、keep-aliveが2秒以上維持できない仕様らしく、それ以上の数値を入れても無駄のようです。

このようなモバイルならではの独自仕様が存在するんですね。
初めて認識しました。

 

memcacheDのDだけが大文字だったり、書き手が外国の方らしく、少しだけ文章が読みづらいところもありますが、ためになる良記事だと思います。

サーバの面倒をみる機会のある方は目を通してみてはいかがでしょうか。

 

関連：

タグ: , , ,



MySQLとPostgreSQLのRepeatable Read時の挙動の違いについて
    このエントリをはてなブックマークに登録

2010/7/2 金曜日 matsui Posted in サーバ 1 Comment »

モバイルとは全く関係ないですが、自分のメモ代わりに記事にしてみたいと思います。

たまたまテストしていて、MySQLとPostgreSQLのRepeatable Read時の挙動の違いを見つけました。

 

AさんとBさんという二人のユーザが同時に一つのレコードを更新している場合です。

user_tblのuser_typeというカラムを「0」→「1」にアップデートしています。

分離レベルはMySQL、PostgreSQLともにRepeatable Readです。

 

Aさん
Bさん
mysql> begin;
Query OK, 0 rows affected (0.00 sec)		 トランザクション開始
mysql> select user_type from user_tbl where user_id
= 1000;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 参照
mysql> begin;
Query OK, 0 rows affected (0.00 sec)		 トランザクション開始
mysql> select user_type from user_tbl where user_id
= 1000 for update;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 行ロック
mysql> update user_tbl set user_type = 1 where user_id
= 1000;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0		 更新
mysql> commit;
Query OK, 0 rows affected (0.05 sec)		 コミット
mysql> select user_type from user_tbl where user_id
= 1000;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 参照（ロックなし）
mysql> select user_type from user_tbl where user_id
= 1000 for update;
+———–+
| user_type |
+———–+
| 1 |
+———–+
1 row in set (0.00 sec)		 参照（ロックあり）

※結果が違うことに注意

 

最後のSELECTが、「FOR UPDATE」の有り無しで違う結果を返していることにご注意ください。

FOR UPDATE以外は全く同じSQL文なのに、結果が違うというのは、少し違和感がありますね。

 

Aさん
Bさん
test=# begin;
BEGIN		 トランザクション開始
test=# select user_type from user_tbl where user_id = 1000;
user_type
———–
1
(1 row)		 参照
test=# begin;
BEGIN		 トランザクション開始
test=# select user_type from user_tbl where user_id = 1000 for update;
user_type
———–
1
(1 row)		 行ロック
test=# update user_tbl set user_type = 0 where user_id = 1000;
UPDATE 1		 更新
test=# commit;
COMMIT		 コミット
test=# select user_type from user_tbl where user_id = 1000;
user_type
———–
0
(1 row)		 参照（ロックなし）
test=# select user_type from user_tbl where user_id = 1000 for update;
user_type
———–
0
(1 row)		 参照（ロックあり）

PostgreSQLの場合は「FOR UPDATE」の有る無しでSELECTの結果は変わりません。
こちらの方が直感的な感じがしますね。

 

（MySQLの内部構造には詳しくないのできっとですが）MySQLでは最初のSELECTでスナップショットが展開されるので、FOR UPDATEで取得した場合とそうじゃない場合でSELECTの結果が違うのだと思います。

「あるテーブルの値を元に、他テーブルの値を更新する」みたいなプログラムの場合、上記の例のようなパターンにはまることがありそうです。

そのような参照の前にはしっかりロックをかけましょう、というそんなお話でした。

 

関連：

タグ: ,



各キャリアのメールサーバのIPアドレス帯域をまとめてみました
    このエントリをはてなブックマークに登録

2010/3/3 水曜日 matsui Posted in サーバ No Comments »

ちょっと別件で各キャリアのメールサーバのIPアドレスをまとめたので、そのURLと現在の帯域をメモしておきます。

 

まずはドコモです。

→　NTTdocomo　作ろうiモードコンテンツ　iモードセンタの各種情報 [nttdocomo.co.jp]

メール送信時（インターネット→iモード）

203.138.180.0/24
203.138.181.0/24

メール受信時（iモード→インターネット）

203.138.203.0/24

 

続いてauです。

→　au by KDDI　技術仕様　EZwebメールサーバIPアドレス情報 [au.kddi.com]

メール送信時(EZweb→インターネット)

59.135.39.192/26
61.117.1.0/24
61.117.2.0/24
61.202.3.0/24
121.111.227.136/30
210.196.3.0/24
210.196.5.0/24
210.196.52.0/24
210.230.141.0/24
219.108.158.0/24
219.125.149.0/24
219.125.151.32/27
220.214.145.0/24
222.1.136.0/24
222.15.69.0/24

メール受信時(インターネット→EZweb)

222.15.69.195

 

最後にソフトバンクです。

→　ソフトバンクモバイルクリエイション　メール　IPアドレス [creation.mb.softbank.jp]

123.108.236.0/24
202.179.203.0/24
202.179.204.0/24
210.146.60.128/25
210.169.176.0/24
210.175.1.128/25
123.108.239.0/24

 

これらの情報は何に使うかというと、メールサーバのスパム対策やイタズラ・成りすまし対策などに利用できます。

ソフトバンクは送信・受信に帯域がわかれていませんが、試してみたところでは送受信で共通の帯域のようです。

なお、ここにあるIPアドレス帯域は、2010年3月3日現在のものですので、設定される際は上記のリンクから最新の情報を確認されるようくれぐれもご注意ください。

 

おまけとして、イーモバイルとウィルコムの情報はこちらです。

→　イーモバイル　技術情報　IPアドレス帯域 [developer.emnet.ne.jp]

→　ウィルコム　ウィルコムのセンター情報 [www.willcom-inc.com]

 

ケータイブラウザのIPアドレス帯域はこちらにまとめてあります。

→　ke-tai.org　ケータイキャリア・クローラIPアドレス [ke-tai.org]

 

関連：

タグ: ,



« Previous Entries