वेब सेवाओं के लिए केवल पोर्ट 80 क्यों?


54

यह एक से अधिक टीसीपी / आईपी पोर्ट को http के लिए समर्पित करने के लिए समझदार क्यों नहीं है? हालाँकि यह माना जाता है कि सर्वर के प्रदर्शन को किसी भी तरह बढ़ाया जा सकता है, यह किसी भी तरह से सहज नहीं है?


17
आप बिल्कुल सही हैं। मैंने अपने वेब सर्वर को डिफ़ॉल्ट पोर्ट 80 से 90,91,92 और 93 में बदल दिया। सर्वर पर लोड काफी कम हो गया है।
डेविड होउड

17
... शायद इसलिए कि कोई भी क्लाइंट सर्वर को नहीं ढूंढ सकता है?
मार्कोस गोंजालेज

5
80 बस http के लिए उपयोग किया जाने वाला पोर्ट है। जब आप कहते हैं "something.com"; (या यहां तक ​​कि "something.com") ब्राउज़र इसे "something.com:80" के लिए अनुरोध करने के लिए पूरा करता है; (पोर्ट 80 पर, क्योंकि यह डिफ़ॉल्ट रूप से प्रसिद्ध http पोर्ट है)। 443 पर https के लिए समान। यदि आप इसे बदलने का निर्णय लेते हैं, तो आपको इसे URL में कहना होगा: "myserver.com:1280"; अन्यथा ब्राउज़र पोर्ट 80 पर कोशिश करेगा और इसे नहीं ढूंढेगा। विकिपीडिया पर
ओलिवियर दुलक

6
सॉरी मार्कोस, वह हास्य का एक खराब प्रयास था। मैं इसमें कभी अच्छा नहीं रहा।
डेविड होउडे

3
@DavidHoude, आपके लिए इमोटिकॉन्स पर रिफ्रेशर का समय। :-) cs.cmu.edu/~sef/sefSmiley.htm
सामान्य नेटवर्क '30

जवाबों:


70

पोर्ट 80 एक प्रसिद्ध बंदरगाह है, जिसका अर्थ है कि यह उस स्थान के रूप में अच्छी तरह से जाना जाता है जहां आप सामान्य रूप से HTTP सर्वर पाएंगे। आप इसे HTTP / 1.1 RFC में प्रलेखित पा सकते हैं ।

डिफ़ॉल्ट रूप से उपयोगी होना ठीक है क्योंकि आपको इसे अपने वेब ब्राउज़र में URI के साथ लिखना नहीं है। यदि आप एक गैर-मानक पोर्ट पर एक HTTP सर्वर (या वास्तव में कोई सेवा) चलाते हैं, तो आप क्लाइंट को यह याद रखने के लिए मजबूर करते हैं कि आपके द्वारा चुनी गई 16-बिट संख्या को किस मनमाने तरीके से टाइप करें और उसमें टाइप करें।

इस मित्रता के अलावा, कोई प्रदर्शन लाभ नहीं है: एक पोर्ट (dst ip:port, src ip:port)4-ट्यूपल का सिर्फ एक हिस्सा है जो विशिष्ट रूप से एक टीसीपी कनेक्शन की पहचान करता है। यदि दो कनेक्शन एक साझा करते हैं dst ip:port, तो इसका मतलब यह नहीं है कि वे कुछ सिस्टम संसाधन साझा करते हैं - वे विभिन्न थ्रेड्स, या विभिन्न प्रक्रियाओं में निवास कर सकते हैं।

अब, यदि आपके पास तार्किक रूप से भिन्न सेवाएँ हैं जो दोनों HTTP का उपयोग करने के लिए होती हैं , तो उन्हें अलग-अलग पोर्ट पर चलाने में कोई समस्या नहीं है । यह सिर्फ यूआरआई को थोड़ा बदसूरत बनाता है।


7
बस! पोर्ट 80 एक संसाधन नहीं है! यह सिर्फ एक टुप का हिस्सा है! इसे स्पष्ट रूप से रखने के लिए धन्यवाद।
मार्कोस गोंजालेज

2
यह भी कुछ भी नहीं है कि विभिन्न सेवाओं के लिए भी, वास्तविक HTTP कनेक्शन आमतौर पर सिस्टम-वाइड ड्राइवर द्वारा पोर्ट 80 पर प्राप्त किया जाता है, जो प्रारंभिक प्रोटोकॉल विश्लेषण करता है और फिर इसे सही सेवा को सौंप देता है, इस प्रकार विभिन्न प्रक्रियाओं में पूरी तरह से अलग-अलग सेवाओं की अनुमति देता है उसी पोर्ट को शेयर करें।
मॉन्स्टिएर

1
बेकार का उपयोगकर्ता का जवाब
डेकार्ड

26

सर्वर एक या एक से अधिक बंदरगाहों में कनेक्शनों को संभाल कर संसाधनों को बर्बाद नहीं करता है। सर्वर संसाधनों को कनेक्शन संभालने के लिए आवंटित किया जाता है, और पोर्ट नंबर एक विशिष्ट प्रोग्राम को एक विशिष्ट कनेक्शन से कनेक्ट करने का एक तरीका है।

उदाहरण के लिए: HTTP सर्वर जानता है कि वह पोर्ट 80 में आने वाले कनेक्शनों को सुनेगा। और सर्वर जानता है कि कभी भी उसे पोर्ट 80 पर कुछ अनुरोध प्राप्त होता है, तो वह इसे http सर्वर पर संभाल लेगा। उसके बाद, http सर्वर संचार को संभालेगा और फिर संसाधनों का उपभोग करेगा।


8
मैं इस उत्तर को जोड़ूंगा कि पोर्ट 80 किसी उपयोगकर्ता द्वारा इसका अनुरोध भेजने के लिए उपभोग नहीं करता है। यही कारण है कि केवल पोर्ट 80 (या आने वाले प्रोटोकॉल के लिए जो भी अच्छी तरह से ज्ञात पोर्ट का उपयोग कर रहे हैं) स्केलेबिलिटी के लिए एक अड़चन नहीं है।
क्रेग सिरकिन

1
यह वही है जो मुझे काफी समझ में नहीं आया। यहां तक ​​कि www.example.com:80 को एक साथ जोड़ने वाले 100,000 उपयोगकर्ता पोर्ट 80 का उपभोग नहीं करेंगे। स्पष्टीकरण के लिए धन्यवाद। मुझे नीचे @Useless की जानकारी बहुत ही ज्ञानवर्धक लगती है।
मार्कोस गोंजालेज

कुछ webservers सॉफ़्टवेयर में प्रति इंस्टेंस और / या प्रक्रिया की सीमाएँ हैं। कभी-कभी यह कई उदाहरणों को चलाने के लिए एक अच्छा विचार हो सकता है, लेकिन एक ही मशीन पर ऐसा करने के लिए दूसरे सुनने के पोर्ट की आवश्यकता होती है, पहला (TCP80 / 443) पहले उदाहरण के लिए कनेक्शन अग्रेषित किया जा रहा है।
रेमी लेटर्न्यू

22

आप बंदरगाहों को कुछ वास्तविक मानते हैं; इसका सिर्फ एक 16-बिट अहस्ताक्षरित नंबर (0-65535) है जो एक IP पैकेट के हेडर में एक लेबल है। यह एप्लिकेशन-लेवल मल्टीप्लेक्सिंग के साथ मदद करता है। जब एक आने वाला पैकेट एक नेटवर्क कार्ड पर आता है, तो ओएस को एक सूचना मिलती है। यह जाँच करता है कि आने वाले पैकेट को किस पोर्ट के लिए निर्देशित किया गया था, और फिर पैकेट को केवल सही अनुप्रयोग के लिए आगे बढ़ाया। यदि आप पोर्ट 80 पर सुनने के लिए अपना वेबसर्वर (nginx) चला रहे हैं, तो केवल nginx को पोर्ट 80 पर भेजे गए पैकेट मिलते हैं।

जब एक क्लाइंट (IP: 100.200.100.200) सर्वर से (55.55.55.55) HTTP अनुरोध करता है, तो वे उस पोर्ट 80 को सर्वर (55.55.55.55:80) पर गंतव्य के लिए अनुरोध करते हैं, लेकिन स्रोत पोर्ट यादृच्छिक रूप से चुना जाता है वेब ब्राउज़र के लिए ओएस (45490 की तरह कुछ)। वेब सर्वर से HTTP प्रतिक्रिया तब (55.55.55.55:80) से आती है, लेकिन गंतव्य (आपके आईपी) (100.200.100.200:45490) पर भेजी जाती है। आपके कंप्यूटर का OS जानता है कि पोर्ट 45490 (55.55.55.55:80 से) पर आने वाले पैकेटों को अनुरोध करने वाले वेब ब्राउज़र को दिया जाना चाहिए। चूंकि क्लाइंट से किसी वेब साइट के प्रत्येक अनूठे कनेक्शन का एक अद्वितीय यादृच्छिक पोर्ट मिलता है, इसलिए आपके पास एक ही वेब साइट से कनेक्ट करने के लिए कई वेब ब्राउज़र हो सकते हैं और जब एक पेज एक ब्राउज़र में पुनः लोड किया जाता है तो दूसरी विंडो प्रभावित नहीं होती हैं।

प्रत्येक आईपी पैकेट में हेडर में स्रोत और गंतव्य आईपी पते और पोर्ट दोनों उपलब्ध हैं। ओएस और एप्लिकेशन (वेब ​​ब्राउज़र या वेब सर्वर) पैकेट को संसाधित करने के तरीके पर उपयुक्त कार्रवाई का पता लगाने के लिए दोनों का उपयोग कर सकते हैं।


2
+2 वोट अगर मैं कर सका।
generalnetworkerror

13

पोर्ट 80 और 443 HTTP / HTTPS के लिए "डिफ़ॉल्ट" पोर्ट हैं

इसका मतलब है कि आपको वेब ब्राउज़र का उपयोग करते समय पोर्ट ( http://www.example.com:80 , https://www.example.com:443 ) को निर्दिष्ट करने की आवश्यकता नहीं है।

यदि आप किसी अन्य पोर्ट पर वेबसर्वर सुनना चाहते हैं, तो उपयोगकर्ताओं को मैन्युअल रूप से पोर्ट को URL में जोड़ना होगा, या इसे उस विशेष पोर्ट के किसी भी लिंक में इनकोड करना होगा।

इसके अलावा, अधिकांश प्रॉक्सी और फायरवॉल उन बंदरगाहों से कनेक्शन नहीं होने देंगे, जब तक कि विशेष रूप से ऐसा करने के लिए कॉन्फ़िगर न किया गया हो (बिना कॉन्फ़िगरेशन के, आउटगोइंग प्रॉक्सीज़ नॉन-डिफॉल्ट पोर्ट्स को नहीं सुनेंगे, इसलिए वेबर्सवर्कर्स के अनुरोध को आगे नहीं बढ़ाएंगे, जबकि फ़ायरवॉल बस होगा) गैर- TCP80 / 443 कनेक्शन प्रयासों को ब्लॉक करें)

यह सब टीसीपी / आईपी स्तर पर किया जा सकता है

प्रदर्शन को बढ़ावा देने का एक तरीका टीसीपी 80/443 को लोड बैलेंसिंग डिवाइस / सेवा के माध्यम से होगा जो तब विभिन्न बंदरगाहों और / या आईपी (स्थानीय संतुलन) या यहां तक ​​कि विभिन्न दूरस्थ साइटों (ग्लोबल बैलेंसिंग) पर सर्वरों के अनुरोध को पुनर्निर्देशित करेगा। लेकिन यह एक और विषय है


मुझे "लोड संतुलन" की अवधारणा से परिचित कराने के लिए धन्यवाद।
मार्कोस गोंजालेज

1
यदि आप कुछ लोड संतुलन अवधारणाओं पर कुछ "छद्म" हाथ-पर और विचार करना चाहते हैं, तो F5 के पास विश्वविद्यालय में मुफ्त ऑनलाइन प्रशिक्षण है। F5.com पंजीकरण मुफ़्त है और यह आपको LTM (स्थानीय ट्रैफ़िक प्रबंधक - उनके स्थानीय बैलेंसर तक पहुँच प्रदान करता है। ) प्रशिक्षण, जहां आप देख सकते हैं कि यह कैसा दिखता है और कुछ भार संतुलन अवधारणाओं को सीखता है (उदाहरण: रियल आईपी, वर्चुअल आईपी, पूल, स्वास्थ्य-जांच, आदि ...)
रेमी लेटर्न्यू

सलाह का अच्छा टुकड़ा!
मार्कोस गोंजालेज

9

अतिरिक्त बंदरगाहों को जोड़ने से अतिरिक्त बैंडविड्थ या ऐसा कुछ भी नहीं जोड़ा जाता है, एक बंदरगाह एक पाइप की तुलना में एक लेबल से अधिक है , यह पाइप के पूर्ण होने के बिना किसी भी धीमी गति से प्राप्त करने के लिए इसे जितना संभव हो उतना व्यापक रूप से "विकसित" कर सकता है।

यदि किसी सर्वर को बहुत अधिक अनुरोध प्राप्त होते हैं, तो सर्वर निश्चित रूप से धीमा हो जाएगा, हालांकि यह उस प्रकार की समस्या नहीं है जिसे अन्य पोर्ट संख्या को जोड़कर ठीक किया जा सकता है।


s / लेबल तो / से लेबल / - मैं संपादित करूँगा, लेकिन ऐसा लगता है कि केवल एक वर्ण स्वीकार्य संपादन नहीं है।
पॉल गियर

7

यदि आपने यादृच्छिक पोर्ट का उपयोग किया है, तो उपयोगकर्ता को आपकी साइट पर हर बार सही पोर्ट नंबर जोड़ना होगा। यानी www.example.com:80; www.example.com:81; www.example.com:82 आदि

यह अधिक बंदरगाहों का उपयोग करने के लिए प्रदर्शन को नहीं बढ़ाएगा। प्रत्येक कनेक्शन के लिए स्रोत पोर्ट एक पंचांग पोर्ट और वैसे भी बहुत अलग हैं


7

प्रत्येक टीसीपी / आईपी कनेक्शन में एक स्रोत है: सोर्सपॉर्ट और एक गंतव्य: गंतव्यपार्ट।

जब आप एक कनेक्शन शुरू करते हैं, तो आप हमेशा गंतव्य बंदरगाह के रूप में 80 का उपयोग करेंगे (जो समझ में आता है क्योंकि सर्वर को केवल HTTP के लिए पोर्ट 80 पर सुनना होगा और कई बंदरगाहों पर नहीं)। चाल है कि sourcePort प्रत्येक कनेक्शन के लिए गतिशील है।

उदाहरण:

user1: 1.1.1.1:29999 से 2.2.2.2:80

user2: 1.1.1.2:45333 से 2.2.2.2:80


2

एक अलग भौतिक कनेक्शन या एक उच्च नेटवर्क बैंडविड्थ या सर्वर प्रोसेसिंग प्रदर्शन के लिए एक अलग पोर्ट की गलती न करें। सर्वर को जो मिलता है वह टीसीपी या यूडीपी पैकेट होता है, जो पते के हिस्से के रूप में एक पोर्ट नंबर होता है। वे अभी भी एक ही तारों पर आते हैं, एक ही नेटवर्क इंटरफ़ेस हार्डवेयर और ड्राइवर के माध्यम से चलते हैं, और इसी तरह।

यदि आप सर्वर पर दो पैकेट भेजना चाहते थे, तो संसाधनों के संदर्भ में सर्वर इन दो पैकेटों को संसाधित करने का इरादा रखता है, इससे कोई फर्क नहीं पड़ता कि दोनों में से एक के पास अलग-अलग पोर्ट नंबर हैं या उनके साथ जुड़े समान पोर्ट नंबर हैं, आंतरिक हैंडलिंग होगी समान के करीब हो।

इसलिए, यह किसी भी तरह से प्रदर्शन को बढ़ाने का तरीका नहीं है।

इसका एकमात्र संभावित अपवाद यह है कि यदि आप दो अलग-अलग राक्षसों (या एक ही की दो प्रतियां) को एक ही समय में दो अलग-अलग पोर्ट संख्याओं के साथ जोड़ रहे थे, और यदि इनमें से प्रत्येक दानव लोड के साथ बेहद खराब होगा। जो आमतौर पर मामला नहीं है।


1

जैसा कि रेमी ने उल्लेख किया है, पोर्ट 80 और 443 HTTP / HTTPS के लिए "डिफ़ॉल्ट" पोर्ट हैं।

अधिकांश नेटवर्क और फ़ायरवॉल इस पोर्ट से जाने वाले ट्रैफ़िक को ब्लॉक नहीं करते हैं। इसलिए इस पोर्ट का उपयोग करना अधिक आसान है क्योंकि आपको अपनी सेवा को अवरुद्ध करने वाले फायरवॉल के बारे में चिंता करने की आवश्यकता नहीं है, अन्यथा आपको फ़ायरवॉल नियमों को पुन: कॉन्फ़िगर करने और उसी के अनुपालन / सुरक्षा से अनुमोदन प्राप्त करने की आवश्यकता हो सकती है।


1
आमीन, गैरमानक पोर्ट का उपयोग कर वेबसाइटों किसी भी सुरक्षा व्यवस्थापक के अस्तित्व के बने, अपने nedwork पर एक उपयोगकर्ता अजीब बंदरगाह = प्रॉक्सी परिवर्तन, परिवार कल्याण परिवर्तन, सुरक्षा समीक्षा आदि के साथ उपयोग करने के लिए एक वेबसाइट की जरूरत नहीं है
wintermute000

0

जैसा कि यहाँ पर अन्य सभी ने कहा है, मूल रूप से किसी वेब सर्वर को पोर्ट 80 के अलावा किसी अन्य पोर्ट पर होस्ट करना व्यर्थ है ... जब तक आप इसे घर से होस्ट नहीं कर रहे हैं। कई ISPs आउटबाउंड टीसीपी / यूडीपी पोर्ट 80 और 443 ( क्रमशः HTTP और HTTPS के रूप में आईएएनए को परिभाषित करता है), और इस मामले में, उन पोर्ट का उपयोग करने से साइट लोडिंग गति आदि से अलग हो जाएंगे, हालांकि, आईएएनए ने HTTP-ALT के लिए पोर्ट आवंटित किए हैं। टीसीपी और यूडीपी दोनों। ये हैं: 591, 8008 और 8080। इन पोर्ट का उपयोग करना भी स्वीकार्य है, लेकिन आप सर्वर एडिंस के जीवन को नरक बना रहे होंगे।

पोर्ट संख्याओं का स्रोत: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.