کامپیوترهانرم افزار

نحوه پیکربندی دریافت اتصالات از طریق 8080 (پورت): دستورالعمل، نمودار و بازخورد

یک پورت در شبکه های کامپیوتری یک عدد طبیعی است که در هدر پروتکل OSI ضبط می شود. این طراحی برای شناسایی فرایند دریافت بسته در یک میزبان است.

به عنوان یک قاعده، در فضای کاربر در یک میزبان با یک سیستم عامل نصب شده، چندین فرایند به طور همزمان رخ می دهد، و در هر یک از آنها یک برنامه مشخص عمل می کند. اگر این برنامه ها بر روی شبکه کامپیوتری تاثیر می گذارد، "پوسته" از آن زمان به یک بسته ی IP که برای یکی از برنامه ها در نظر گرفته شده است، از طریق آن دریافت می کند.

چگونه کار می کند؟

اگر برنامه از تبادل داده ها از طریق شبکه استفاده می کند، این فرایند می تواند به شرح زیر رخ دهد:

  • سیستم عامل یک شماره پورت خاص را درخواست می کند. در این حالت، سیستم می تواند هر دو آن را به برنامه ارائه دهد و انتقال را ممنوع کند (این اتفاق می افتد در مواردی که این شماره پورت قبلا توسط برنامه دیگری استفاده می شود).
  • سیستم عامل هیچ پورت خاصی را در هر پورت آزاد نیاز ندارد. سیستم آن را انتخاب می کند و برنامه را فراهم می کند.

چگونه برای باز کردن پورت (8080، 80 و غیره)؟ در داخل شبکه، اطلاعات بر اساس یک پروتکل خاص (بین دو فرایند) مبادله می شود. برای برقراری ارتباط، به موارد زیر نیاز دارید:

  • آدرس IP های میزبان گیرنده و فرستنده (لازم است که مسیر بین آنها ساخته شود)؛
  • شماره پروتکل؛
  • شماره دو پورت (گیرنده و فرستنده).

اگر اتصال از طریق TCP باشد، سپس پورت فرستنده به عنوان سیستم دریافت کننده برای ارسال تصدیق از اطلاعات دریافت شده و روند دریافت کننده برای ارسال پاسخ استفاده می شود.

پورت های باز و بسته

از طرف فرستنده، میزبان و شماره پورت به عنوان یک آنالوگ آدرس بازگشتی عمل می کنند که در پاکت ها نشان داده شده است. این شماره عدد معکوس نامیده می شود.

در مواردی که یک فرآیند در میزبان از همان شماره پورت به صورت مستمر استفاده می کند، چنین پورت باز می شود. به عنوان مثال، یک برنامه مرتبط با سرور همیشه می تواند از 80 یا 8080 برای ارتباط استفاده کند. هنگامی که این فرآیند نمی تواند پورت را باز کند، بسته به نظر می رسد.

اعداد پورت

همه پورت ها شماره های خود را ثبت شده در دستورالعمل. هر یک از آنها برای هدف خاصی طراحی شده است. بنابراین، هنگام کار بر روی اینترنت، اغلب می توانید پورت 8080 را مشاهده کنید. این قابلیت برای چیست؟

با توجه به اطلاعات رسمی، این پورت بر روی پروتکل TCP کار می کند و برای استفاده با HTTP در نظر گرفته شده است. غیر رسمی، آن نیز توسط ظرف سروتله Tomcat، نوشته شده در جاوا استفاده می شود.

پورت TCP 8080 می تواند از یک پروتکل خاص برای ارتباطات، بسته به برنامه استفاده کند. پروتکل مجموعه ای از قوانین رسمی است که توضیح می دهد چگونه داده ها بر روی شبکه منتقل می شود. این می تواند به عنوان زبان ای ارائه شود که بین رایانه ها برای کمک به آنها به طور موثرتر ارتباط برقرار می شود.

پروتکل HTTP، که از طریق 8080 کار می کند، فرمت ارتباطات بین مرورگرهای اینترنت و وب سایت را تعریف می کند. مثال دیگر پروتکل IMAP است که ارتباط بین سرورهای پست الکترونیکی IMAP و مشتریان را مشخص می کند یا در نهایت پروتکل SSL که فرمت مورد استفاده برای پیام های رمز شده را مشخص می کند.

انتقال داده

بنابراین، پورت 8080 TCP از پروتکل کنترل انتقال استفاده می کند. این یکی از پروتکل های اصلی در شبکه های TCP / IP است. در حالی که پروتکل IP تنها با بسته ها سروکار دارد، TCP اجازه می دهد دو میزبان برای برقراری ارتباط و مبادله جریان داده ها. او تحویل خود را تضمین می کند، و همچنین حقیقت این است که بسته ها به بندر 8080 به همان ترتیبی که ارسال می شوند، تحویل می شود. اتصال تضمین شده 8080 تفاوت اصلی بین TCP و UDP است. UDP 8080 یک اتصال را یکسان تضمین نمی کند.

چگونه پورت 8080 را در ویندوز 7 باز کنیم؟

برای انجام این کار، به منوی «شروع» بروید و پانل کنترل را پیدا کنید. در آن شما باید بر روی زیر منو "شبکه" کلیک کنید و در آن "Branmauer" را پیدا کنید. در برگه "Exceptions"، گزینه "Add Port" را پیدا کنید. شما با یک کادر محاوره ای ارائه خواهید شد که از شما خواسته می شود که شماره پورت را وارد کنید. تأیید کنید که TCP در تنظیمات پیکربندی شده است و سپس روی OK کلیک کنید.

چگونه پورت 8080 را ببندیم؟ برای انجام این کار، اتصال به یک پورت خاص را پیکربندی کنید.

پیکربندی پروکسی HTTP و TCP پیشرفته

پروتکل HTTP در بالای پروتکل TCP کار می کند، اما اطلاعات اضافی در مورد تخصیص پیام را فراهم می کند. به همین دلیل، دو پروکسی به صورت پیکربندی متفاوت هستند.

ترافیک HTTP شامل میزبان مقصد و پورت برای پیام است. این یک اتصال TCP به یک نقطه پایانی TCP، یعنی بین یک میزبان خاص و یک پورت، ارسال می شود. به طور معمول یک پیام HTTP به نقطه پایانی همانند اتصال TCP اشاره می کند. اگر تنظیمات سرویس گیرنده را برای استفاده از یک پروکسی HTTP تغییر دهید، اتصال با میزبان و پورت متفاوت، به جای آن که در URL های HTTP مشخص شده است، ساخته شده است. این به این معنی است که نقطه پایانی TCP در پیام متفاوت از نقطه پایانی است که آن متصل است.

به عنوان مثال، اگر درخواست HTTP به صفحه http://192.0.2.1:8080/operation ارسال شود، درخواست شامل "192.0.2.1:8080" در قسمت "Host" پیام HTTP است که به پورت 8080 در میزبان 192.0 ارسال می شود. 2.1

با این حال، اگر سرویس گیرنده HTTP را برای استفاده از یک پروکسی سرور پیکربندی کنید، اتصال پایه TCP به نقطه پایانی TCP برای آن می رود، در حالی که پیام ها هنوز هم نقطه پایانی اولیه را شامل می شوند.

برای مثال، اگر مشتری را پیکربندی کنید تا پیام های خود را به سرور پروکسی در بندر 3128 198281.100.1 ارسال کنید و مشتری درخواستی برای http://192.0.2.1:8080/operation ارسال کند، این پیام همچنان حاوی "192.0.2.1: 8080" است. در سرآیند "میزبان"، و در حال حاضر نیز در قسمت "درخواست خط". با این حال، این پیام از طریق اتصال TCP به آدرس 198.51.100.1:3128 فرستاده می شود. بنابراین، پروکسی HTTP می تواند پیام ها را در یک پورت (پورت پروکسی 8080) دریافت کند و می تواند آنها را به چندین سرویس مختلف بر اساس اطلاعات گیرنده منتقل کند.

چگونه می توانم پذیرش اتصالات را از طریق پورت 8080 پیکربندی کنم؟

بنابراین، هدر "میزبان" به HTTP / 1.1 اضافه شد. اتصال HTTP / 1.0 شامل آن نمی شود. به همین دلیل، چنین اتصالاتی که از طریق پروکسی عبور نمی کنند، میزبان و پورت پیام را شامل نمی شوند. با این حال، اطلاعات HTTP / 1.0 ارسال شده از طریق پروکسی سرور هنوز شامل میزبان و پورت هدف در "رشته پرس و جو" است. بنابراین، عدم وجود هدر «میزبان» برای پروکسی مشکل ایجاد نمی کند.

برای فعال کردن پروکسی TCP، شما باید پیکربندی سرویس دهنده از نقطه پایانی TCP را در زمان واقعی به نقطه پایانی جایگزین تغییر دهید. برخلاف HTTP، این پروتکل توانایی درج در استفاده از پروکسی را فراهم نمی کند. به عبارت دیگر، اگر شما از طریق TCP به یک سرور پروکسی متصل شوید، هیچ مکانیزمی برای انتقال اطلاعات به مقصد فرستنده وجود ندارد.

نحوه پیکربندی اتصالات متعدد با 8080؟

تنها راه برای پروکسی TCP اجازه اتصال به سیستم های چندگانه (یعنی با نقطه پایانی)، صرف نظر از اینکه چه ترافیکی از طریق این اتصالات ارسال می شود، به پورت دیگر برای هر یک از سیستم ها گوش می دهد. این به شما اجازه می دهد که اطلاعات مربوط به کدام شماره های پورت مربوط به هر نقطه پایانی را به هم وصل کنید و نگه دارید. سپس سرویس گیرنده با یک پراکسی پورت مربوط به هر سیستم که نیاز به اتصال دارد پیکربندی شده است. پورت پروکسی TCP برای گوش دادن و نقطه انتهایی مربوطه در اپراتورهای در پرونده پیکربندی پرونده، RTCP_install_dir / httptcp / registration.xml پیکربندی شده است. اول از همه، شما باید پورت 8080 را چک کنید - اگر به طور پیش فرض باز باشد، تنظیمات بیشتر در چند دقیقه ساخته خواهد شد.

در این مثال، 198.51.100.1 آدرس آی پی سرور پروکسی است. هر ترافیکی که به پورت 3333 در سرور پروکسی ارسال می شود به پورت 8080 در آدرس WWW ارسال می شود. مثال کام:

بنابراین، هر زمان که یک مقصد جدید برای ترافیک اضافه می کنید، باید پرونده پیکربندی مشتری را تغییر دهید. این محدودیت به پروکسی HTTP اعمال نمی شود.

تعامل بین HTTP و TCP

برای درک اینکه چگونه پورت ها در سرورهای پروکسی HTTP و TCP پردازش می شوند، فرض کنید که شما دو سرویس دارید: 192.0.2.1:8080 و 192.0.2.1:8081 و یک پروکسی سرور در 198.51.100.1 اجرا می شود. اگر از طریق آدرس آی پی و نه با شماره پورت متفاوت باشد، این مثال به همان اندازه برای آدرس مربوطه برای هر سرویس متفاوت خواهد بود. اگر انتظار می رود ترافیک HTTP در هر پروکسی HTTP، درخواست ها برای هر نقطه انتهایی TCP می تواند به آن ارسال شود. هنگامی که HTTP می بیند که پیام به آدرس 192.0.2.1:8080 خطاب شده است، پروکسی پیام را به این آدرس هدایت می کند یا هر قاعده ای را که برای این سرویس ارائه می دهد، اعمال می کند. همان روش مربوط به 192.0.2.1:8081 است، با استفاده از همان پورت.

اگر این دو سرویس در عوض در انتظار ترافیک TCP باشند، دو پورت پروکسی TCP که توسط دو عنصر در پرونده پیکربندی تعریف شده اند باید باز شوند:

پیکربندی سرویس دهنده برای سرویس اول از "192.0.2.1:8080" به "198.51.100.1:3333" تغییر می کند و برای دومین از "192.0.2.1:8081" به "198.51.100.1:3334" تغییر می کند. مشتری یک پیام (بسته TCP) را به اولین سرویس در اولین آدرس می فرستد.

سرور پروکسی آن را در این پورت (3333) دریافت می کند، اما نمی داند چه داده ای از طریق این ارتباط ارسال می شود. همه چیز که او می داند اتصال به پورت 3333 است. بنابراین، سرور پروکسی با پیکربندی آن مشورت می کند و می بیند که ترافیک این پورت باید به 192.0.2.1:8080 هدایت شود (یا یک قاعده برای این سرویس باید به آن اعمال شود). اگر شما نمی توانید تمام ترافیک HTTP خود را هدایت کنید، زیرا پیکربندی سرویس دهنده از پیکربندی پروکسی HTTP پشتیبانی نمی کند، شما باید از پروکسی HTTP معکوس استفاده کنید.

در آن، به جای آدرس مقصد، شما یک مورد را مشخص می کنید. این روند مشابه پروسه پیکربندی TCP است که در آن شما را به عنوان نقطه پایانی TCP برای پیام در سیستم مشتری مشخص می کند و یک قانون حمل و نقل را ایجاد می کند.

تفاوت این است که ویژگی نوع را به حقیقی که HTTP را تعریف می کند اضافه می کند، همانطور که در مثال زیر: .

ترافیک چطور است؟

اکنون سرور پروکسی پیکربندی شده است تا فقط ترافیک HTTP را به پورت اختصاص داده شده دریافت کند و می تواند از فیلتر کردن غنی تر استفاده کند. به عنوان مثال، یک سرور می تواند ترافیک را به یک خرد تبدیل کند که مسیر خاصی در URL خود ندارد یا از روش HTTP خاص مانند POST استفاده نمی کند. با این حال، از آنجا که خرد است همیشه کار نمی کند، سرور هنوز هم نیاز به یک مقصد از عنصر برای ارسال ترافیک به سیستم است. برای مثال، فرض کنید که مشتری نیاز به اتصال به سرویس در 192.0.2.1:8080 داشته باشد و از پروکسی HTTP معکوس در 198.51.100.1:3333 استفاده کند.

قبل از اینکه مشتری بتواند از پروکسی سرور استفاده کند، پیکربندی سرویس دهنده برای این سرویس باید از یک URL، به عنوان مثال، http: // 192.0.2.1:8080/ operation، به http: // 198.51.100.1:3333/ عملیات تغییر کند. درخواستی که به این آدرس جدید ارسال می شود به سرور پروکسی می رود.

پیام درخواست حاوی نقطه پایانی TCP برای پروکسی (198.51.100.1:3333) در هدر «میزبان» و نه آدرس سیستم است، زیرا مشتری نمی داند که پیام فرستاده شده را ارسال می کند. این نقش مشتری ساده شده ماهیت چنین ارتباطی را تعیین می کند. بنابراین، پروکسی از عناصر استفاده می کند تا بدانند که درخواست به پورت 3333 نیاز به یکی از موارد زیر دارد: باید به سیستم live در 192.0.2.1:8080 هدایت شود و header "Host" در پیام باید به روز شد برای پیام، تمام قوانین این سرویس باید، به عنوان مثال، مسیریابی به یک خرد است.

Similar articles

 

 

 

 

Trending Now

 

 

 

 

Newest

Copyright © 2018 fa.unansea.com. Theme powered by WordPress.