サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
Linux/UNIXサーバは立てたらまず時刻同期の設定 - Qiita
信頼できるタイムスタンプがログに残っていることが障害調査の重要な手がかりとなります。 正確な時刻の確保はサーバ管理の根本ですので、時刻同期の設定はOSをインストール後に最優先で行う作業と位置づけられるものです。 基礎知識として 時刻は ハードウェアクロック とOS上の ソフトウェアクロック がともに刻んでいます。 稼働中はソフトウェアクロックだけが参照されますが、ハードウェアクロックはマシン停止時にも動き続けているので 起動時にはハードウェアクロックがソフトウェアクロックへ読み込まれます。 ネットワークから現在時刻を提供するサービス(NTP)により時刻合わせをします。 このとき、特に時刻を遅らす場合、急に遅らせる操作はしません。時刻が後ろへ飛ぶことによりログの時刻の前後関係がひっくり返る可能性があるからです。 （ログ以外のソフトウェア動作も異常を来すかも知れません） ソフトウェアクロックの
GHOST脆弱性にyum update glibc、その後リブートする前に - Qiita
CentOS7で遭遇したトラブル。 本日話題のGHOST脆弱性にyum updateでパッチを当てたところ SSHログインできなくなってしまった というものです。 root権限でyum update → もちろん成功 (この時点で /root/.ssh/authorized_keys が空ファイルになってしまったよう) リブートしてSSHで再ログインを試みる。公開鍵認証が通らない。 パスワード認証でSSHログインを試みる。しかしパスワード認証は切ってあった！ VPSのリモートコンソールでログインし状況確認を試みる。この時点で、/root/.ssh/authorized_keys が空になっており、タイムスタンプがアップデート作業した頃になっているのを確認。 パスワードログインで入れるよう、sshdの設定ファイルを修正（ただし、リモートコンソールゆえの苦労がたくさん。キーボード配列がおかしく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
