並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 26 件 / 26件

新着順 人気順

TCPの検索結果1 - 26 件 / 26件

  • Dockerのポートマッピングのデフォルト設定は危ない - JUNのブログ

    あらすじ 公衆WiFiに繋いだ状態でいつものように docker container run -p 8080:80 nginx のような感じでDockerコンテナを動かしていたら、外部からリクエストを受信した。 ファイアウォールを設定し、外部からのアクセスを拒否しているはずなのになぜアクセスできたんだ... 環境 Docker desktop for mac with apple silicon 4.21.0 何が起きた? Dockerはデフォルトの設定では-p 8080:80のようにポートマッピングするとファイアウォールの設定を書き換え、外部からそのポートへのアクセスを許可するようになっている。 その結果LAN内の他のPCから対象ポートにアクセス出来てしまう。 ちなみにこれはDocker公式からも注意が出ている。 Publishing container ports is insecur

      Dockerのポートマッピングのデフォルト設定は危ない - JUNのブログ
    • Goでゼロから作る 自作TCP/IPプロトコル サーバー

      「マスタリングTCP/IP を読んだけど理解がイマイチ進まない。Goがどのようにサーバーを立てているのか気になる。」 そんなスキマを埋めるための本です。 Goの標準パッケージである net package を一切利用せずに、自作TCP/IPプロトコルでサーバーを作ります。 パケットをどのようにやり取りするかハンズオン形式で解説し、最後にToDoリストAPIを実装します。

        Goでゼロから作る 自作TCP/IPプロトコル サーバー
      • 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
        • レイテンシ(遅延)とスループット(帯域幅)と帯域幅遅延積 - Qiita

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

            レイテンシ(遅延)とスループット(帯域幅)と帯域幅遅延積 - Qiita
          • WindowsのChromeやEdgeでネットにつながりにくくなる現象、一部の家庭用ルーターが原因かも? DNSの“TCPクエリ”うまく扱えない機種も存在。ChromeのTCPクエリ送信が引き金に

              WindowsのChromeやEdgeでネットにつながりにくくなる現象、一部の家庭用ルーターが原因かも? DNSの“TCPクエリ”うまく扱えない機種も存在。ChromeのTCPクエリ送信が引き金に
            • HTTP/3|Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)

              HTTP/3|Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ 新しい通信プロトコルとして普及が進んでいるHTTP/3については、エンジニアHubでも過去に概論的な記事を掲載しています。今回はアプリケーション開発者が自社サービスでHTTP/3を採用することを想定して、仕様上の留意点や、どのように使い始めるか、そしてサイトを制作する際に注意しておきたいポイントまでを藤吾郎(gfx)さんに解説していただきました。 本記事ではHTTP/3およびその通信プロトコルであるQUICを、アプリケーション開発者として活用する立場で入門します。HTTP/3は、HTTP/1.1とHTTP/2に続く新しいメジャーバージョンのHTTPプロトコルです。HTTP/3はHTTP/1.1およびHTTP/2を置き換えるポテンシャルを持っています。将来的にほとんどのインターネットトラフィ

                HTTP/3|Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)
              • Linux カーネルをバイパスして TCP 通信を 10 倍速くする | IIJ Engineers Blog

                【IIJ 2023 TECHアドベントカレンダー 12/16の記事です】 この記事について 背景:TCP はコンピュータネットワークの通信において広く利用されているプロトコル・標準化された通信規格です。コンピュータは TCP/IP スタックと呼ばれるようなソフトウェアを実行することで、定められた規格に則って通信を行います。汎用 OS 環境では、TCP/IP スタックは多くの場合、カーネル空間に OS 機能の一部として実装されています。 課題:通信に関するソフトウェアの研究コミュニティでは、そのようなカーネル空間に実装されている TCP/IP スタックは、近年の高速な NIC の性能を十分に引き出すことが難しいという課題が指摘されてきました。 テクニックの紹介:当記事では、近年の研究コミュニティにおいて比較的一般的な高速化テクニックとされている「カーネルをバイパス(迂回)して TCP 通信を

                  Linux カーネルをバイパスして TCP 通信を 10 倍速くする | IIJ Engineers Blog
                • カンファレンスイベントで会場回線を過信してはいけない - notokenの覚書

                  前段 PHP Conference Japan 2023が 10/08 に大田区産業プラザPiOで行われたわけですが、開会直後に提供している無線LANがいきなり不安定になってしまい、そのまま一部の部屋以外で提供できない状態になってしまった。 この記事では、なぜそのようなことが発生してしまったか?という点に関して解説しようと思う。 結論 会場側設備として入っているNAPT-BOXが YAMAHA RTX1200 という 15年前*1に発売されたルータで、来場者を捌けるだけのNAPTセッションテーブル*2が備わっておらず、NAPTテーブル溢れ*3を起こしてしまった。 事前知識 NAPT Network Address Port Translation 1つのグローバルIPアドレスを複数のホストで共有するための仕組み。この機能により1つのグローバルIPアドレスを複数のクライアント(コンピュータや

                    カンファレンスイベントで会場回線を過信してはいけない - notokenの覚書
                  • ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案

                    インターネット上のIPアドレスやドメイン名などの管理や調整を行っているICANN(Internet Corporation for Assigned Names and Numbers)は、プライベートネットワークやホームネットワークのためのトップレベルドメインとして「.INTERNAL」を予約語として割り当てるという提案を1月24日付で公開しました。 プライベートネットワークには、「192.168.xx.xx」などの専用のIPアドレス空間が公式に割り当てられており、このIPアドレス空間はインターネット上のIPアドレスと衝突しないことが約束されています。 しかし、このIPアドレス空間で管理されているプライベートネットワークのために公式に割り当てられたドメイン名の名前空間は、現時点ではありません。 そのため、プライベートネットワークの運用者がプライベートネットワーク内で何らかのドメイン名を運

                      ICANN、プライベートネットワークで使うための公式トップレベルドメイン「.INTERNAL」を提案
                    • Linuxの各種仮想ネットワークデバイスにおけるSegmentation Offloadの振る舞い

                      LinuxにおけるSegmentation OffloadとはTCPなどのトランスポートレイヤのプロトコルが送信するデータをMTUに収まるように分割する処理(Segmentation)をNICのレイヤにオフロードすることによってスループットを向上させる技術です. Segmentation Offloadを使った場合, トランスポートレイヤのプロトコルはIPレイヤで許容される最大のサイズ(64KB程度)までのデータを1つのIPパケットで送信することができます. 受信側は逆にネットワークから入ってきたSegmentation済みのパケットをNICのレイヤで1つの大きなIPパケットに集約した上でプロトコルスタックの処理にかけます. これによってプロトコルスタックで処理されるパケットの個数を減らすことができるため, スループットが上がるという仕組みです. Linuxには仮想ネットワークデバイスとい

                        Linuxの各種仮想ネットワークデバイスにおけるSegmentation Offloadの振る舞い
                      • Linux以外ではDockerでIPv6が扱えないので簡易なTCP Reverse Proxy Serverを書いた - 時計を壊せ

                        まずは公式ドキュメントをご覧ください。 docs.docker.com IPv6 is only supported on Docker daemons running on Linux hosts. 残念! Docker Desktop for Macなどでローカル開発をしているときに、ローカルで立ち上げたプロセスからDocker内にあるコンテナに通信したいことは割りとよくあるユースケースだと思う。 こういうときは、基本的には宛先をIPv4のLoopback Addressである127.0.0.1に向けてあげて、 IPv6を使わないようにしてあげるとよい。 localhostを使ってしまうと、名前解決でIPv6のLoopback Addressに名前解決されるケースがあり、そうなればIPv6に対して接続しようとしてしかしIPv4でしかlisten(2)されていないのでコケる。 しかし、世

                          Linux以外ではDockerでIPv6が扱えないので簡易なTCP Reverse Proxy Serverを書いた - 時計を壊せ
                        • NetworkPolicyでtrafficを制御しよう - enechain Tech Blog

                          はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri

                            NetworkPolicyでtrafficを制御しよう - enechain Tech Blog
                          • 1単語のように扱われる「TCP/IP」、実はTCPはIPより先に生まれていた

                            TCP(Transmission Control Protocol)とIP(Internet Protocol)といえば、インターネットを支える基盤のプロトコルだ。実はTCPはIPより先に存在していたのをご存じだろうか。 TCPが最初に登場したのは1974年。ビントン・サーフ氏とボブ・カーン氏がIEEE(米国電気電子学会)の学会誌『Transactions on Communications』に論文「A Protocol for Packet Network Intercommunication」を投稿した。この時点のTCPは現在のTCPとIPの両方の機能が盛り込まれていた。現在のインターネットの4階層モデルからすると、TCPはインターネット層とトランスポート層にまたがるプロトコルだったのだ。 ビントン・サーフ氏が描いたTCPのアイデア。1973年に描いたとされる初めて図示したものを、20

                              1単語のように扱われる「TCP/IP」、実はTCPはIPより先に生まれていた
                            • (小ネタ)NLBへ疎通確認する時はレイヤ4(トランスポート層)のコマンドを使用してほしい | DevelopersIO

                              この状態で再度ping,tracepathコマンドを実行しましたが、結果は変わりませんでした。。 どうやらNLBの仕様として、設定済みのリスナーに一致しないネットワークトラフィックは意図しないトラフィックとしてターゲットに転送せずにドロップするようです。 設定済みのリスナーに送信されるすべてのネットワークトラフィックが、意図されたトラフィックとして分類されます。設定済みのリスナーに一致しないネットワークトラフィックが、意図しないトラフィックとして分類されます。Type 3 以外の ICMP リクエストも、意図しないトラフィックとみなされます。Network Load Balancer は、意図しないトラフィックをターゲットに転送せずにドロップします。 出典:Network Load Balancer のリスナー - Elastic Load Balancing Pingで使われれるのはIC

                                (小ネタ)NLBへ疎通確認する時はレイヤ4(トランスポート層)のコマンドを使用してほしい | DevelopersIO
                              • TCPが再送しているケースだけではない?WiresharkでBad TCPが発生する原因 | 東陽テクニカ | “はかる”技術で未来を創る | ワン・テクノロジーズ・カンパニー

                                自宅でリモートワーク中に自分の通信をWiresharkでキャプチャしていると、実に多くの黒いパケットが発生していたりします。この黒いパケットの正体は、Wiresharkのデフォルトカラーリング設定の"Bad TCP"に分類されたパケットです。 自宅までは光通信となっていて、その先にはWifiルータを設置していて、PCとは無線で接続していますが、とても早くて快適です。遅いとか繋がらないとかいうことは一切感じません。

                                • GitHub - panjf2000/gnet: 🚀 gnet is a high-performance, lightweight, non-blocking, event-driven networking framework written in pure Go./ gnet 是一个高性能、轻量级、非阻塞的事件驱动 Go 网络框架。

                                  gnet is an event-driven networking framework that is ultra-fast and lightweight. It is built from scratch by exploiting epoll and kqueue and it can achieve much higher performance with lower memory consumption than Go net in many specific scenarios. gnet and net don't share the same philosophy about network programming. Thus, building network applications with gnet can be significantly different f

                                    GitHub - panjf2000/gnet: 🚀 gnet is a high-performance, lightweight, non-blocking, event-driven networking framework written in pure Go./ gnet 是一个高性能、轻量级、非阻塞的事件驱动 Go 网络框架。
                                  • KLab Expert Camp 6 - Day1

                                    TCP/IPプロトコルスタック自作開発 Day1 KLab株式会社 第6回 KLab Expert Camp

                                      KLab Expert Camp 6 - Day1
                                    • TCP over カスタムプロトコル における NIC オフロードに着目したパフォーマンスチューニングの考察 - Qiita

                                      はじめに 株式会社サイバーエージェント 24 卒 SRE 内定者の後藤 廉(@ren510dev)です。 Kubernetes が好きです。 普段は、セキュアオーバーレイネットワークプロトコルの研究・開発をしています。 以前、開発しているオーバーレイネットワークプロトコルのプロトタイプを検証・評価した際に、TCP のスループットが極端に劣化するという事象に直面しました。 今回の記事では、ソケットプログラミングの紹介を交えつつ、Raw ソケットを使用したユーザ空間プログラムによるカスタムプロトコルに TCP を乗せる際に気を付けることと、NIC(Network Interface Card)に備わっているオフロード機能及びマルチコアスケールを利用したパフォーマンス改善策について紹介したいと思います。 結論だけ知りたい人は こちら 【ぼやき】TCP はめんどくさい ※ TCP/UDP の通信メ

                                        TCP over カスタムプロトコル における NIC オフロードに着目したパフォーマンスチューニングの考察 - Qiita
                                      • Linuxで現在設定されている(使用可能な)TCP輻輳制御アルゴリズムを見る - CLOVER🍀

                                        これは、なにをしたくて書いたもの? 最近、こちらの本を読んでいるのですが。 TCP技術入門 ――進化を続ける基本プロトコル (WEB+DB PRESS plusシリーズ) 作者:安永 遼真,中山 悠,丸田 一輝発売日: 2019/07/06メディア: 単行本(ソフトカバー) 輻輳制御とそのアルゴリズムについて、いろいろと紹介されています。 このあたりについて、今まであまり意識したことがなかったので、「さて、手元のLinux環境ではどうなっているのか?」ということで 調べてみました。 輻輳制御自体については、こちらあたりを参考に。 第1回 TCPの輻輳制御とは何か:基本から学ぶ TCPと輻輳制御 ……押さえておきたい輻輳制御アルゴリズム|gihyo.jp … 技術評論社 アルゴリズムとしては、Googleが開発したBBRが注目されていたりするようで? TCPを高速化する新アルゴリズム「BBR

                                          Linuxで現在設定されている(使用可能な)TCP輻輳制御アルゴリズムを見る - CLOVER🍀
                                        • 【Wireshark】良好な通信状況でTCP Restranmissionが頻発している事象 - (O+P)ut

                                          事象 Wiresharkでパケットをキャプチャしたところ以下でエラーとして扱われていて [Coloring Rule Name: Bad TCP] [Coloring Rule String: tcp.analysis.flags && !tcp.analysis.window_update]該当のパケットには以下のようなメッセージが記されている。 ..."TCP","64","[TCP Retransmission] XX → XX [PSH, ACK] Seq=1 Ack=1 Win=XX Len=XX"..."TCP","66","[TCP Dup ACK 21#1] xx → xx [ACK] Seq=55 Ack=11 Win=xx Len=0 SLE=1 SRE=11" 環境情報 Wireshark 3.2.2 Windows10⇔WindowsServer2016 原因 同一

                                          • ネットワークの問題を効果的にトラブルシューティングするための Firepower ファイアウォールキャプチャの分析

                                            はじめに このドキュメントでは、ネットワークの問題を効果的にトラブルシューティングするための、さまざまなパケットキャプチャ分析手法について説明します。 前提条件 要件 次の項目に関する知識があることが推奨されます。 Firepower プラットフォーム アーキテクチャ NGFW ログ NGFW パケットトレーサ さらに、パケットキャプチャの分析を開始する前に、次の要件を満たすことを強くお勧めします。 プロトコルの動作を確認する:キャプチャされたプロトコルの動作を理解していない場合は、パケットキャプチャのチェックを開始しないでください。 トポロジを把握する:中継デバイスをエンドツーエンドで把握する必要があります。これが不可能な場合は、少なくともアップストリームデバイスとダウンストリームデバイスを知っている必要があります。 アプライアンスの把握:デバイスでのパケットの処理方法、関連するインター

                                            • 3way-handshakeからnmapのステルススキャンを理解する - Qiita

                                              3way-handshakeとnmapステルススキャン 以前の記事でpWnOS:2.0という脆弱性サーバーに、Kali Linuxを使ってroot権限を取得しました。 そのKali Linuxでポートスキャンを行うに使ったnmapというツールは、対象サーバーにログを残さないステルススキャンを行うことができました。 今回はこのnmapのステルススキャンを実現している、TCPプロトコルの3way-handshakeについてまとめていきたいと思います。 3way-handshakeとは? 3way-handshakeとは通信の信頼性を確保するための接続で、TCPヘッダ情報のフラグを利用した通信方法です。 この3way-handshakeが終了したことでTCPコネクションが確立したということを示し、上位レイヤーでHTTP通信などが行われます。 3way-handshakeを実現するTCPコネクショ

                                                3way-handshakeからnmapのステルススキャンを理解する - Qiita
                                              • Pythonでの再接続可能なServer, Clientの雛形 - Qiita

                                                Pythonで簡単なsocketのserver/clientプログラムを書くことが多いのですが、 いつも片方が死んだ時のリコネクト(再接続)の書き方をどうやるんだっけ、となるので、 雛形としてまとめました。 もっとスマートな書き方があればご教示ください。 #!/usr/bin/python # coding: utf-8 import socket import time host = '127.0.0.1' port = 65000 buff = 1024 if __name__ == '__main__': s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((host, port)) while True

                                                  Pythonでの再接続可能なServer, Clientの雛形 - Qiita
                                                • Stabilizerの概要

                                                  Stabilizer はWindows で動作するTCP・UDP・RS232C に対応した通信ソフトです。 単なる送受信モニタから通信テストやデータ解析まで、幅広いニーズに応えられるツールとしてご使用いただけます。 最強の通信ツールとして末永くご利用いただけるよう、最適な機能の追加、 機能の安定化を継続して行っております。是非、ご試用してみてください。 TCP、UDP、RS232Cで相互にプロトコル変換 TCP、UDP、RS232Cで相互にプロトコルを変換して通信を行うことができます。 シリアルポートが2つある場合には、 RS232CとRS232Cで相互通信を行うことでコミュニケーションアナライザと同等の処理が実現できます。 スクリプトによる自動実行 Luaスクリプトを記述することで、様々な処理を自動実行できます。 次の例は、5つのファイルを切り替えながら 3秒ごとにファイル送信を行うスク

                                                  • TCP (Transmission Control Protocol),伝送制御プロトコルについて

                                                    TCP (Transmission Control Protocol),伝送制御プロトコルについて解説しています。 TCPは「Transmission Control Protocol(伝送制御プロトコル)」の略で、クライアントとサーバーの間でやり取りされるデータを特定の方法で整理し保護するものである。データを、バイトのストリームとして配信し、バイトのストリームとして受信するという、信頼性の高いストリーム配信サービスを提供する。 なお、バイトストリームは、プログラムが情報の入出力に使用する一連のバイト(Bytes)で、バイトストリームは、一連の 8 ビット シーケンス(sequences,連続しているもの)として解釈できる。なお、ビット(Bits)ストリームは、1と0のシーケンス(sequences,連続しているもの)。 バイトストリームにすることで、データを小さなバンドル(結合,またはグ

                                                      TCP (Transmission Control Protocol),伝送制御プロトコルについて
                                                    • Wireshark TIPS | 東陽テクニカ | “はかる”技術で未来を創る | ワン・テクノロジーズ・カンパニー

                                                      カテゴリ:Wireshark TIPS 自宅でリモートワーク中に自分の通信をWiresharkでキャプチャしていると、実に多くの黒いパケットが発生していたりします。この黒いパケットの正体は、Wiresharkのデフォルトカラーリング設定の"Bad TCP"に分類されたパケットです。自宅までは光通信となっていて、その先にはWifiルータを設置していて、PCとは無線で接続していますが、とても早くて快適です。遅いとか繋がらないとかいうことは一切感じません。Wiresharkでキャプチャした自宅の通信パケット(Bad TCPのみフィルタ)今回は、Wiresharkで検出されるいくつかの"Bad TCP"について、そのアラートの種類となぜそのアラートが表示されるのかを解説します。list目次WiresharkでのTCP関連の表示フィルタTCPの再送が発生する仕組みBad TCPアラートが表示される原

                                                      1