並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 310件

新着順 人気順

TCPの検索結果81 - 120 件 / 310件

  • RDBMSでコネクションプールが必要な理由、わからない。

    Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない(解放まで多少遅延する)ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ(要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか?なぜ(べき、べきでない)のか?どういう要請でそうなのか?と言う問いに僕は答えられません。 2013-09-04 09:31:22

      RDBMSでコネクションプールが必要な理由、わからない。
    • 調べなきゃ寝れない!と調べたら余計に寝れなくなったソケットの話 - Qiita

      なるほど、最近ソケット通信、ソケット通信と言ってるのはUNIXドメインソケットの事か! UNIXドメインソケットって何がいいの? Performance Analysis of Various Mechanisms for Inter-process Communicationに素晴らしい検証があった。 It was hypothesized that pipes would have the highest throughtput due to its limited functionality, since it is half-duplex, but this was not true. For almost all of the data sizes transferred, Unix domain sockets performed better than both TCP so

        調べなきゃ寝れない!と調べたら余計に寝れなくなったソケットの話 - Qiita
      • 「192.168.0.100/24」のネットワークアドレスを即答するには? ipcalcコマンド

        「192.168.0.100/24」のネットワークアドレスを即答するには? ipcalcコマンド:ネットワーク管理の基本Tips TCP/IPネットワークの設定を手動で行うとき、IPアドレスだけでなくサブネットマスクについても正しい情報を指定する必要があります。「192.168.0.100/24」のようにマスク長が計算しにくい値のときは、ipcalcコマンドを使うと簡単に計算できます。

          「192.168.0.100/24」のネットワークアドレスを即答するには? ipcalcコマンド
        • ネットワークの状況を確認するコマンド色々 | DevelopersIO

          なんで相手に繋がらないの!? サーバ管理していてよく起こる問題は、「なんで繋がらないの!?」ですよね。そこで、今回は基本的なネットワークをご紹介したいと思います。OSやツールのバージョンにより動作が異なりますので、それぞれ調べてみて頂ければと思います。今回は、Amazon Linux 2015.03を用いています。 ping 基本はpingですね。ICMPのにあるエコー要求/応答のpingを使って接続確認を行います。 $ ping yahoo.co.jp PING yahoo.co.jp (182.22.59.229) 56(84) bytes of data. 64 bytes from f1.top.vip.ssk.yahoo.co.jp (182.22.59.229): icmp_seq=1 ttl=54 time=4.84 ms 64 bytes from f1.top.vip.s

            ネットワークの状況を確認するコマンド色々 | DevelopersIO
          • WebブラウザでP2Pを実現する、WebRTCのAPIと周辺技術

            HTML5 Conference 2017 発表資料です。 http://events.html5j.org/conference/2017/9/session/#c1

              WebブラウザでP2Pを実現する、WebRTCのAPIと周辺技術
            • nginxのパラメータチューニングとh2o - Qiita

              (追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調

                nginxのパラメータチューニングとh2o - Qiita
              • 第1章 進化するHTTPの歩み ~ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp

                HTTP/3入門 第1章進化するHTTPの歩み ~ HTTP/1.1とHTTP/2をおさらいし⁠⁠、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP(Hypertext Transfer Protocol)の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ

                  第1章 進化するHTTPの歩み ~ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
                • Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始

                  Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 Googleは、同社が開発したTCPの輻輳制御アルゴリズム「TCP BBR」をGoogle Cloud Platformで利用可能にしたと発表しました。 インターネットにおける通信にはTCPを用いる場合とUDPを用いる場合に分かれますが、BBRはTCPにおける輻輳制御アルゴリズムを改善したもの。すでにGoogleはTCP BBRをYouTubeのネットワークで利用しており、従来のパケットロスをベースにした輻輳制御アルゴリズムであるCUBICを用いた場合と比較して、スループットが平均で4%、最大で14%以上改善したことを明らかにしています。 TCP BBRは現在の高速なネットワークに適した輻輳制御アルゴリズム TCP BBRのBBRは「Bottleneck Ba

                    Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始
                  • RFCの読み方

                    こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC(Request For Comments)が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF(Internet Engineering Task Force)というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments(コメント募集)という名前にしていたようです

                    • [Windows 7編]ネットワーク設定を標準で使ってはいけない

                      Windows 7のネットワーク設定を標準で使ってはいけない。標準では「SNP(Scalable Networking Pack)」と呼ばれるネットワークを最適化する機能が有効化されている。この「SNPが有効化」されている設定のままPCを動作させると、ネットワーク処理が不安定になったり、ネットワーク処理とは関係ないアプリケーションの処理に影響を与えたりする可能性があるからだ。 SNPとは、通常はPC上のプロセッサが行っているネットワーク処理を、PC内部のNIC(ネットワークインタフェースカード)に担当させるなどしてプロセッサの負荷を下げる機能だ。 ハードにネットワーク処理を分担させるSNP SNPは三つの機能からなる。「SNPが有効」とは三つのうち、少なくとも一つが有効化していることを指す。 (1)TCP Chimney Offload TCPのネットワーク制御をプロセッサからNICにオフ

                        [Windows 7編]ネットワーク設定を標準で使ってはいけない
                      • TCP/IP構造と通信 - Qiita

                        OSIとTCP/IP構造 OSI参照モデルとTCP/IPプロトコルスタックの対応関係を示しています。 OSIモデルはデータ通信のための抽象的なモデルで、7つの階層(レイヤー)から成り立っています。 一方、TCP/IPプロトコルスタックはインターネットで実際に使用されているプロトコルの集まりで、4つの階層から構成されています。 TCP/IPの4層構造 アプリケーション層:OSIモデルのアプリケーション層、プレゼンテーション層、セッション層に相当します。HTTP、FTP、SMTPなどのプロトコルが含まれます。 トランスポート層:OSIモデルのトランスポート層に相当します。TCPやUDPがこの層で動作します。 インターネット層:OSIモデルのネットワーク層に相当します。IPプロトコルがこの層で主に使用されます。 ネットワークインターフェース層:OSIモデルのデータリンク層と物理層に相当します。E

                          TCP/IP構造と通信 - Qiita
                        • CloudFrontをかますとキャッシュなしのAPIコールでも速くなるようだ : sonots:blog

                            CloudFrontをかますとキャッシュなしのAPIコールでも速くなるようだ : sonots:blog
                          • SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記

                            tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど1年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も

                              SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
                            • Wireshark

                              Join us 4-8 November in Vienna for SharkFest'24 EUROPE, the official Wireshark Developer and User Conference The world's most popular network protocol analyzerGet started with Wireshark today and see why it is the standard across many commercial and non-profit enterprises. *{padding:0;margin:0;overflow:hidden}html,body{height:100%}img,span{position:absolute;width:100%;top:0;bottom:0;margin:auto;he

                                Wireshark
                              • スプラトゥーンのナワバリバトルの通信をパケットキャプチャによって解析してみた

                                ■なにをしたの スプラトゥーンのナワバリバトル中にどのような通信が行われているのか確認しました。ARPスプーフィングによって、Wii Uから自宅ゲートウェイへ送られるパケットを覗いてみました。使用したツールは下記の2つです。 nighthawk: ARPスプーフィングします Wireshark: パケットキャプチャします ■通信内容 ソフト起動後に、Amazon Web ServicesとSSLで通信していました。Miiverseと、ランク・ウデマエなどの戦績を、AWSとWii U本体間で同期していると思います。AWS導入事例で書かれているところの、「DataStore機能」と「Miiverse」ですかね。 ロビーに入ると、シリコンスタジオ株式会社のサーバーとUDPで定期的に通信していました。フレンドのオンライン状況を定期的にとりにいっているようです。マッチングについては、シリコンスタジオ

                                  スプラトゥーンのナワバリバトルの通信をパケットキャプチャによって解析してみた
                                • Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング - tehepero note(・ω<)

                                  2016 - 08 - 12 Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング Docker Linux もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回Dockerホストの TCP カーネル パラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、 インスタンス 数も削減できた上に安定して メシウマ状態 になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つの ケーススタディ であることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストは Ubuntu (EC2 Opt

                                    Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング - tehepero note(・ω<)
                                  • IBM - TCP/IP チュートリアルおよび技術解説書

                                    TCP/IP の基礎概念、アプリケーション・プロトコルについての概説、ネットワーキングにおける拡張概念とインフラストラクチャーの傾向について説明しています。

                                    • Kubernetesネットワーク 徹底解説

                                      Kubernetesのネットワークの構築要件に対して、世の中には様々なアプローチがあります。 本書ではTCP/IPは知っているけれど、Kubernetesのネットワークの実現方法は知らない人向けに、メジャーな実現アプローチについてできるだけ噛み砕いてステップバイステップで体系的に説明します。

                                        Kubernetesネットワーク 徹底解説
                                      • KENJI

                                        更新履歴 DNS拡張EDNS0の解析 Linuxカーネルをハッキングしてみよう Windowsシステムプログラミング Part 3 64ビット環境でのリバースエンジニアリング Windowsシステムプログラミング Part2 Windowsシステムプログラミング Part1 Contents インフォメーション 「TCP/IPの教科書」サポートページ 「アセンブリ言語の教科書」サポートページ 「ハッカー・プログラミング大全 攻撃編」サポートページ ブログ(はてな) BBS メール このサイトについて テキスト 暗号 詳解 RSA暗号化アルゴリズム 詳解 DES暗号化アルゴリズム crypt() アルゴリズム解析 MD5 メッセージダイジェストアルゴリズム crypt() アルゴリズム解析 (MD5バージョン) TCP/IP IP TCP UDP Header Format(IPv4) Ch

                                        • Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記

                                          まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注: 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY

                                            Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
                                          • QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記

                                            OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って

                                              QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
                                            • SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013

                                              SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY(スピーディ)。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究

                                                SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013
                                              • レイテンシ(遅延)とスループット(帯域幅)と帯域幅遅延積 - Qiita

                                                マルチクラウド展開にまつわる既成概念を覆すより データ転送では、特に長距離の場合にレイテンシ(遅延)が問題になることがありますが、現在はすべてのクラウド・プロバイダーがそれぞれの物理インフラストラクチャを互いの近くに配置(専門用語では「コロケーション」)しているため、これはさほど問題となりません。この近接性(場合によっては同一コロケーション施設内の別の部屋)は、クラウド間のレイテンシがミリ秒単位であることを意味します。それに加え、クラウド・データセンター・リージョンは世界中で増加しており、クラウド・リージョン間の距離は縮まっています。 という事で、レイテンシ(遅延)について、まとめてみてみます。 ■ Agenda レイテンシ(遅延)とスループット(帯域幅) レイテンシと TCP の動作 帯域幅遅延積(Bandwidth-Delay Product) TCP Window Size の調整と

                                                  レイテンシ(遅延)とスループット(帯域幅)と帯域幅遅延積 - Qiita
                                                • TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋

                                                  昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日本・北米間だと10

                                                    TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
                                                  • WindowsのChromeやEdgeでネットにつながりにくくなる現象、一部の家庭用ルーターが原因かも? DNSの“TCPクエリ”うまく扱えない機種も存在。ChromeのTCPクエリ送信が引き金に

                                                      WindowsのChromeやEdgeでネットにつながりにくくなる現象、一部の家庭用ルーターが原因かも? DNSの“TCPクエリ”うまく扱えない機種も存在。ChromeのTCPクエリ送信が引き金に
                                                    • なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes

                                                      Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか? 何が問題で、なぜ Google はそれらを作り変えるのか? SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか? 20% ルールで作ってみた Play プロジェクトでしかないのか? こうした新しい動きには、かならず「それまで」と「今」を踏

                                                        なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
                                                      • TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena

                                                        やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース(RDBMS)のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力(のIO負荷)を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で(notアプリケーションで)記録することで(大抵、サーバ台数の多い)アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている(例えば)クエリログを解析してログ

                                                          TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
                                                        • 通信用語の基礎知識

                                                          R05/04/15Twitterアカウントを廃止しました。今後はMisskey.ioでよろしくお願いします R03/02/18初版公開から26年になります H30/06/05常時SSL化(HTTPS化)しました H29/04/09新サーバーに移行しました

                                                          • Analyzing CPU traces from Linux with PerfView - Vance Morrison's Weblog - Site Home - MSDN Blogs

                                                            In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

                                                              Analyzing CPU traces from Linux with PerfView - Vance Morrison's Weblog - Site Home - MSDN Blogs
                                                            • netstatコマンドを使いこなす @IT:Windows TIPS -- Tips:

                                                              TCP/IP関連のトラブルシューティングを行う場合に、必ずといってよいほど使うコマンドとして「netstat」コマンドがある(実行ファイル名はnetstat.exe)。このコマンドは、主にTCPの通信状態を調べるためには必須であり、ぜひともその使い方をマスターしておきたい。 netstatの基本――通信中のTCPコネクションの調査 netstatコマンドの最も基本的な使い方は、通信中のTCPコネクション(TCP接続)の状態を表示させることである。このコマンドを実行すると、ローカルPCのTCP/IPプロトコルスタック上において、現在アクティブになっているTCP通信の状態を表示できる。 ●「TCP」とは? 「コネクション」とは? TCPとは、2つのアプリケーション間で、信頼性のある通信路(コネクション)を開設し、お互いにデータなどをやりとりするための機能である。通信するアプリケーションは、同一

                                                                netstatコマンドを使いこなす @IT:Windows TIPS -- Tips:
                                                              • 連載記事 「習うより慣れろ! iptablesテンプレート集」

                                                                ステートフルパケットフィルタを使ったサービスの公開 連載:習うより慣れろ! iptablesテンプレート集(1) 初心者にとって、iptablesは難しい。そこで、学習の第1歩としてテンプレートを自分の環境に適応させることから始めよう

                                                                • Amazon EC2 Eメール送信ベストプラクティス | DevelopersIO

                                                                  ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク

                                                                    Amazon EC2 Eメール送信ベストプラクティス | DevelopersIO
                                                                  • fluentdでログが欠損する可能性を考える : sonots:blog

                                                                      fluentdでログが欠損する可能性を考える : sonots:blog
                                                                    • net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita

                                                                      Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

                                                                        net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
                                                                      • 40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog

                                                                        2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が

                                                                          40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
                                                                        • Linuxサーバ上でホスト間コネクションを集約表示するツール lstf をつくった - ゆううきメモ

                                                                          概要 netstatやssコマンドにより、あるホストと他のホストとのコネクションを一覧表示できる。しかし、Webシステムの場合、クライアントが並行接続するため、 同一ホストから複数のポートを介してコネクションを確立しているケースが多い。コネクション数が大きい場合は、1万以上のコネクションが表示され、ホスト間のコネクション状況を人間の目で概観することが難しかった。 そこで、同一ホストとのコネクションを集約表示し、コネクション状況を概観する 「lstf」 (「えるえすてぃーえふ」)コマンドをつくった。 github.com lstfの特徴は以下の通り。 コマンド実行ホストを起点に、active openコネクションかpassive openコネクションを判定する。つまり、接続をする側かされる側かを判定する。 各ホストフローごとにコネクション数を表示する Goで実装されているポータビリティ。i3

                                                                            Linuxサーバ上でホスト間コネクションを集約表示するツール lstf をつくった - ゆううきメモ
                                                                          • MQTTについてのまとめ — そこはかとなく書くよん。 ドキュメント

                                                                            注釈 MQTT As a Service: sangoをリリースしました 2014年8月に、GitHubアカウントで簡単に登録できてMQTTを使い始められる sango を 時雨堂 がリリースしました。 無料プランもありますので、MQTTを一度使ってみたいという方はsangoを使うことをお勧めします。 最近voluntasさんが 活動 してお り、にわかにMQTT関連が熱くなってきました。たぶん観測範囲が狭いからだと は思いますが。 とはいえ、M2M (Machine to Machine)やIoT(Internet of Things)というバズワー ドもあり、モノがインターネットにつながる時代になってきて、MQTTの価値が 高くなってきている気もします。また、モバイル時代に適したプロトコルとい う意味でも注目されているのかもしれません。 ということ、MQTTについて一旦ここでまとめてみ

                                                                            • Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi

                                                                              上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました > デモ (ソースコード)*1 リアルタイ

                                                                                Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
                                                                              • WebRTCを仕組みから実装までやってみる - blog::wnotes.net

                                                                                このエントリはFrontrend Advent Calendar 2013 23日目の記事です。 2014/03/16追記 WebRTC-DataChannelについてもエントリ書きました。↓からどうぞ。 WebRTC-DataChannel使ってみたよ WebRTCを仕組みの理解から実装まで Advent Calendarを書くということでなんか新しいことやったほうがいいかなーって思ってたので、今回はWebRTCを調べてみました。 調べながらだったので間違っている箇所もあるかもですが、専門家の方のツッコミあれば歓迎です。 先に作ったサンプルデモを触りたい方は以下のアドレスからどうぞ。 WebRTC Video Chat Sample ※接続名は同時にアクセスしている方全員から見えますのでご注意ください!接続依頼が来た際にはダイアログが出るようにしてますが、安易に応答すると知らない人とつな

                                                                                • TCPに代わる次世代のインターネット通信プロトコル「QUIC」が正式スタート、RFC 9000の発表で

                                                                                  インターネット技術の標準化団体であるIETFが、TCPに代わるインターネット通信プロトコルとして注目を集めているQUICの技術仕様をまとめたRFC 9000を発表しました。これにより正式に「バージョン1」へと移行することが決まったQUICの将来について、RFC 9000の作成を手がけたジャナ・アイヤンガー氏が解説しています。 QUIC is now RFC 9000 | Fastly https://www.fastly.com/blog/quic-is-now-rfc-9000 QUIC is RFC 9000 | daniel.haxx.se https://daniel.haxx.se/blog/2021/05/27/quic-is-rfc-9000/ QUICは、現行のインターネットに使われているTCPの遅延を減らし、信頼性と安全性を改善させることを目的に開発された新しいトランスポ

                                                                                    TCPに代わる次世代のインターネット通信プロトコル「QUIC」が正式スタート、RFC 9000の発表で