昨日に続き、アクセスが偏る系のエントリです。 なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。 DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。 基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。) この事は、Wikipediaの該当ページにも記載されています。 主にIPv6における宛先アドレス選択アルゴリズムとして定義され

This is strictly a violation of the TCP specification2016-08-12 I was asked to debug another weird issue on our network. Apparently every now and then a connection going through CloudFlare would time out with 522 HTTP error. CC BY 2.0 image by Chris Combe 522 error on CloudFlare indicates a connection issue between our edge server and the origin server. Most often the blame is on the origin server

TCPのキープアライブ(TCP keepalive) TCPでデータを転送する場合、データの転送を行う前にコネクションが確立されている必要があります。 一方で、TCPは状態を持つ(ステートフルな)プロトコルであり、サーバ・クライアントそれぞれが状態を持つため、サーバ・クライアントの一方のみがコネクションを確立している状態であるハーフコネクション・ハーフオープンになりえます。 アプリケーションでTCPのキープアライブが有効な場合は、コネクションが有効であることを確認するパケットを定期的に送信し、TCP通信が不可の状態を検知した場合、そのコネクションを強制的に閉じることが可能です。 TCPのハーフコネクション・ハーフオープンについての詳細は以下のエントリを参照してください。 tcpdumpとiptablesで理解するTCPのハーフコネクション・ハーフオープン また、TCPのコネクションの基本に

[root@server ~]# ss -help Usage: ss [ OPTIONS ] ss [ OPTIONS ] [ FILTER ] -h, --help this message -V, --version output version information -n, --numeric don't resolve service names -r, --resolve resolve host names -a, --all display all sockets -l, --listening display listening sockets -o, --options show timer information -e, --extended show detailed socket information -m, --memory show socket memo

Here at Cloudflare, we have a lot of experience of operating servers on the wild Internet. But we are always improving our mastery of this black art. On this very blog we have touched on multiple dark corners of the Internet protocols: like understanding FIN-WAIT-2 or receive buffer tuning. CC BY 2.0 image by Isaí Moreno One subject hasn't had enough attention though - SYN floods. We use Linux and

While working on our Spectrum server, we noticed something weird: the TCP sockets which we thought should have been closed were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! Image by Sergiodc2 CC BY SA 3.0 In our code, we wanted to make sure we don't hold connections to dead hosts. In our early code we naively thought enabling TCP keepalives wo

前々回と前回では、TCPにおける基本的な通信モデルと、TCPパケットの構造、TCPのオープン／クローズ処理について解説した。今回はTCPプロトコル解説の最後として、TCPオプションとTCPの状態遷移図、そして実際のTCPプロトコルの例についてみていく。 TCPのオープン処理では、3ウェイ・ハンドシェイクという手法を使っている。これは都合3つのパケットを往復させることにより、オープン要求の送信とそれに対する受信確認の返答を行うものである。TCPは双方向型の通信サービスなので、両方のノードがそれぞれオープン要求を送信し、それに対してそれぞれが応答を返信する。実際にネットワークをキャプチャして確認すると、この3ウェイ・ハンドシェイクの様子がよく分かるだあろう。 TCPのクローズ処理とは、もうこれ以上送信するデータがない、ということを相手に通知するためのものである。やはり双方がこのクローズ要求を送

F5 NGINX provides a suite of products that together form the core of what organizations need to create apps and APIs with performance, reliability, security, and scale.

What really are descriptors?The fundamental building block of all I/O in Unix is a sequence of bytes. Most programs work with an even simpler abstraction — a stream of bytes or an I/O stream. A process references I/O streams with the help of descriptors, also known as file descriptors. Pipes, files, FIFOs, POSIX IPC’s (message queues, semaphores, shared memory), event queues are all examples of I/

背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_