443ポート以外が絶滅しそうです あちこちでポートは閉じられています。ssh や sftp もプロキシ利用も、各種ポートでは、全く外部に出れず、接続できないネットワークが多いです。 TCP/IPなのにIPとポートを使った通信ができない、壊れたネットワークが当然になりました。 これらの接続制限にとても不便を感じることが多いです。 サーバー管理者の気分一つでポートが空いたり閉じたり、私が触ってたネットワークではポリシーが統一されず、クソネットワーク管理者に振り回されて、動くはずのものが動かず、不便なことが多かったのです。そこで仕方なく４４３を使っています。 私達が利用する端末では80/443 のポートの外部接続が閉じられることは少なく、443であれば通信できます。 そのため、443ポートに様々なアプリケーションを起動していると思います。 443 ポートとIPアドレスが枯渇する・・・ よほどのG
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
インターネットバンキングの不正送金事件などで、発信元を隠すためにネットへの接続を中継するプロキシサーバーと呼ばれるサーバーが悪用されるケースが相次いでいることから、警視庁など２０の警察本部は、各地のサーバー管理会社が中国の顧客に不正に日本のインターネットに接続させようとしたなどとして、不正アクセス禁止法違反などの疑いで一斉摘発に乗り出しました。 摘発されたのは、全国各地にある「プロキシサーバー」と呼ばれるインターネットへの接続を中継するサーバーの管理会社です。 このうち、東京・豊島区駒込にあるサーバー管理会社「サンテクノ」には警視庁が捜索に入り、３２歳の社員ら２人が他人のＩＤとパスワードを使って、中国の顧客に日本のインターネットに不正に接続させようとしたとして、不正アクセス禁止法違反の疑いで逮捕する方針です。 プロキシサーバーは、発信元が海外でも国内から接続したように装うことができるため、
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
2013.4.20 追記 CNAMEの間違った使い方を書いていたので、「3. DNSレコードでCNAMEやAレコードを設定する」の項を一部修正しました。 というか、実際に痛い目に遭いました・・・(T T)。 詳しくは本文にて。 2014.10.10 追記 結局Herokuでは「Aレコード + ネイキッドドメイン」の設定を使うことはできなくなりました。 ネイキッドドメインを使う場合は、かわりに「CNAME flattening」という仕組みを使います。 詳しくは以下の記事で説明しているので、参考にしてみてください。 妻のパン屋のwebサイトをいろいろ更新した話 ～Rails 4アップデートとかサイトの高速化とか～ - give IT a try はじめに みなさん、DNS、ネームサーバー(NS)、Aレコード、CNAME、と言われて、「ああ、アレね」ってすぐに頭の中にイメージが浮かびますか？
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
何の話かというと RHEL7/CentOS7では最小構成でインストールすると、ifconfig、route、netstat、arpなどのネットワーク関連のコマンドが使えません。これは、次のコマンドで「net-tools」パッケージを導入すると解決します。 # yum -y install net-tools しかしながら！ RHEL7/CentOS7では、net-toolsを「deprecated（廃止予定）」としており、今後は、iproute2パッケージに含まれる「ip」「ss」などのコマンドを使用することが推奨されています。 ・お客さんのRHEL7サーバーのメンテを頼まれたらnet-toolsが入ってなかった！ ・「えー。まだifconfigつかってんのー。」と若い同僚に冷たい目で見られた！ ・などなど といった事態に備えて、RHEL7/CentOS7を導入した際には、iproute2
Copyright © 2013 株式会社日本レジストリサービス 1 Copyright © 2013 株式会社日本レジストリサービス 1 Copyright © 2013 株式会社日本レジストリサービス 1 初心者のためのDNS運用入門 - トラブルとその解決のポイント - 2013年7月19日 DNS Summer Days 2013 株式会社日本レジストリサービス（JPRS） 水野 貴史 Copyright © 2013 株式会社日本レジストリサービス 2 Copyright © 2013 株式会社日本レジストリサービス 2 Copyright © 2013 株式会社日本レジストリサービス 2 講師自己紹介 • 氏名：水野 貴史（みずの たかふみ） • 生年月日：1988年3月3日（25歳） • 所属：株式会社日本レジストリサービス（JPRS） システム部 • Unix歴：8年目（F
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
このブログの記事がGunosyに掲載されたことがきっかけで、Gunosyユーザーの本名フルネームと思われる文字列が、このブログのサーバーログに大量に記録されていることに気が付きました。Gunosyのサービスの特徴から、（非公開設定で使っているGunosyユーザーであっても）その利用者の興味関心に関する情報の一部が、外部サイトの管理者に漏れているとも考えられます。そこで今回は、その仕組みと、それを悪用するプロセスの例について考えてみたので、紹介します。 今回紹介する問題は、以前このブログで指摘し、すぐに修正された非公開アカウントの情報が漏れる問題（Gunosy経由で記事を読むとTwitterアカウントやFacebookアカウントが推測可能な情報がサイト側に提供される仕組みについて）と類似の問題です。前回の指摘で少々改善されていたものの、結局同じようなリスクが発生しているとわかりました。 ただ
Twitterで「なんかやばそうな本が出るぞ！！！」みたいな事を言っていたら、それが偶然拾われて、献本して頂く流れになりました。オライリーさん、ありがとうございます。 とりあえずざっと全体を流し読みした（と言っても3時間弱は読んだ）ので、書評っぽいことを書いておく。 ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化posted with amazlet at 14.05.10Ilya Grigorik オライリージャパン 売り上げランキング: 4,747 Amazon.co.jpで詳細を見る 読むべき人間 以下に該当する人間に対しては必読に値する本だと思う。 HTTPを扱うアプリケーション*1のアーキテクチャを設計する人間 Webサーバ等のHTTPに関連するインフラを担当する人間 HTTP 2.0、WebSocket、Server-S
このJPRSの発表に対し、この欠陥を発見した中京大学の鈴木常彦教授、前野年紀氏は「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」を懸念し、下記のブログ記事等でこの問題の危険性を訴えています。 この問題はインターネットの根幹に関わるものですが、どんな問題を孕んでいるのでしょうか。それを理解するために、まずはDNSの仕組みから見て行きましょう。 DNSの仕組みとDNSキャッシュサーバDNSとはインターネットの根幹に関わる仕組みで、目的のサーバにアクセスする為の重要な役割を持ちます。簡単に説明すると、"http://www.example.jp"というURLのサイトを見たい場合、それを管理するサーバのインターネット上の住所（IPアドレス）が必要になります。そこで、DNSサーバに上記URLのラベル（ドメイン）に相当する"www.example.jp"を管理するサー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く