เว็บเซิร์ฟเวอร์สามารถรองรับการเชื่อมต่อซ็อกเก็ตได้กี่ช่อง


114

สมมติว่าฉันต้องการแชร์โฮสติ้งเสมือนหรือเฉพาะฉันอ่านที่ไหนสักแห่งที่เซิร์ฟเวอร์ / เครื่องสามารถรองรับการเชื่อมต่อ TCP 64,000 รายการในครั้งเดียวได้หรือไม่ โฮสติ้งประเภทใดที่สามารถจัดการได้โดยไม่คำนึงถึงแบนด์วิดท์ ฉันสมมติว่า HTTP ทำงานผ่าน TCP

นี่หมายความว่ามีผู้ใช้ 64,000 คนเท่านั้นที่สามารถเชื่อมต่อกับเว็บไซต์ได้และถ้าฉันต้องการให้บริการมากขึ้นฉันต้องย้ายไปที่เว็บฟาร์มหรือไม่


2
ขอโทษผู้ตอบฉันฉีกกระทู้นี้เหมือนพายุทอร์นาโด มีคำตอบที่ไม่ถูกต้องมากเกินไปสำหรับความชอบของฉันและยังไม่มีคำตอบโดยตรง ฉันใช้ stackoverflow เป็นจำนวนมากและพบคำตอบคุณภาพสูงมากมาย ฉันหวังว่าคนอื่น ๆ จะสามารถค้นพบหัวข้อนี้และพบคำตอบที่เป็นประโยชน์
ทอดด์

สวัสดีเดวิดคุณพบคำตอบที่ถูกต้องสำหรับคำถามนี้หรือไม่?
จาน

64000 การเชื่อมต่อ TCP ผ่าน IP เดียวของเซิร์ฟเวอร์ คุณสามารถอัพเกรดเครือข่ายเซิร์ฟเวอร์ของคุณให้มีขนาดและรองรับมากกว่า 64000
Airy

คำตอบ:


109

กล่าวโดยย่อ: คุณควรจะสามารถบรรลุตามลำดับของการเชื่อมต่อ TCP ที่ใช้งานพร้อมกันหลายล้านรายการและตามคำขอ HTTP ส่วนขยาย สิ่งนี้จะบอกคุณถึงประสิทธิภาพสูงสุดที่คุณคาดหวังได้จากแพลตฟอร์มที่เหมาะสมพร้อมการกำหนดค่าที่เหมาะสม

วันนี้ฉันกังวลว่า IIS กับ ASP.NET จะรองรับการเชื่อมต่อพร้อมกัน 100 ครั้งหรือไม่ (ดูที่การอัปเดตของฉันคาดว่าจะได้รับการตอบกลับ ~ 10k ต่อวินาทีใน ASP.Net Mono เวอร์ชันเก่า) เมื่อฉันเห็นคำถาม / คำตอบนี้ฉันอดไม่ได้ที่จะตอบตัวเองว่าหลาย ๆ คำตอบของคำถามนี้ไม่ถูกต้องทั้งหมด

กรณีที่ดีที่สุด

คำตอบสำหรับคำถามนี้ต้องเกี่ยวข้องกับการกำหนดค่าเซิร์ฟเวอร์ที่ง่ายที่สุดในการแยกตัวออกจากตัวแปรและการกำหนดค่าที่เป็นไปได้นับไม่ถ้วน

ลองพิจารณาสถานการณ์ต่อไปนี้สำหรับคำตอบของฉัน:

  1. ไม่มีการรับส่งข้อมูลในเซสชัน TCP ยกเว้นแพ็กเก็ตที่มีชีวิตอยู่ (ไม่เช่นนั้นคุณจะต้องใช้แบนด์วิดท์เครือข่ายและทรัพยากรคอมพิวเตอร์อื่น ๆ ในปริมาณที่สอดคล้องกัน)
  2. ซอฟต์แวร์ที่ออกแบบมาเพื่อใช้ซ็อกเก็ตและการเขียนโปรแกรมแบบอะซิงโครนัสแทนที่จะเป็นเธรดฮาร์ดแวร์ต่อคำขอจากพูล (เช่น IIS, Node.js, Nginx ... webserver [แต่ไม่ใช่ Apache] พร้อมแอพพลิเคชั่นซอฟต์แวร์ที่ออกแบบโดย async)
  3. CPU / Ram ประสิทธิภาพดี วันนี้โดยพลการสมมติว่า i7 (4 core) พร้อม RAM 8GB
  4. ไฟร์วอลล์ / เราเตอร์ที่ดีที่จะจับคู่
  5. ไม่มีขีด จำกัด เสมือน / ผู้ว่าราชการจังหวัด - เช่น Linux somaxconn, IIS web.config ...
  6. ไม่มีการพึ่งพาฮาร์ดแวร์อื่น ๆ ที่ช้ากว่า - ไม่มีการอ่านจากฮาร์ดดิสก์เนื่องจากจะเป็นตัวหารและคอขวดที่พบบ่อยที่สุดไม่ใช่ IO ของเครือข่าย

คำตอบโดยละเอียด

การออกแบบที่เชื่อมโยงเธรดแบบซิงโครนัสมักจะมีประสิทธิภาพที่แย่ที่สุดเมื่อเทียบกับการใช้งาน IO แบบอะซิงโครนัส

WhatsApp ได้รับล้านกับการจราจรบนระบบปฏิบัติการยูนิกซ์เดียวรสเครื่อง OS - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/

สุดท้ายนี้http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.htmlลงรายละเอียดมากมาย สำรวจว่าแม้กระทั่ง 10 ล้านก็สามารถทำได้ เซิร์ฟเวอร์มักมีฮาร์ดแวร์ TCP offload engine ASIC ที่ออกแบบมาสำหรับบทบาทเฉพาะนี้มีประสิทธิภาพมากกว่า CPU ที่ใช้งานทั่วไป

ตัวเลือกการออกแบบซอฟต์แวร์ที่ดี

การออกแบบ IO แบบอะซิงโครนัสจะแตกต่างกันไปตามระบบปฏิบัติการและแพลตฟอร์มการเขียนโปรแกรม Node.js ถูกออกแบบด้วยตรงกันในใจ คุณควรใช้สัญญาอย่างน้อยและเมื่อ ECMAScript 7 asyncมาพร้อมawait/ C # / Net มีการสนับสนุนแบบอะซิงโครนัสเต็มรูปแบบเช่น node.js อยู่แล้ว ไม่ว่าระบบปฏิบัติการและแพลตฟอร์มใดก็ตามควรคาดว่าอะซิงโครนัสจะทำงานได้ดีมาก และไม่ว่าคุณจะเลือกภาษาใดให้มองหาคำหลัก "อะซิงโครนัส" ภาษาสมัยใหม่ส่วนใหญ่จะมีการรองรับแม้ว่าจะเป็นส่วนเสริมของบางประเภทก็ตาม

ไปที่ WebFarm?

ไม่ว่าสถานการณ์เฉพาะของคุณจะมีขีด จำกัด เท่าไหร่ใช่เว็บฟาร์มเป็นทางออกที่ดีทางหนึ่งในการปรับขนาด มีสถาปัตยกรรมมากมายสำหรับการบรรลุเป้าหมายนี้ หนึ่งใช้ตัวจัดสรรภาระงาน (ผู้ให้บริการโฮสติ้งสามารถเสนอสิ่งเหล่านี้ได้ แต่สิ่งเหล่านี้มีขีด จำกัด พร้อมกับเพดานแบนด์วิดท์) แต่ฉันไม่ชอบตัวเลือกนี้ สำหรับแอปพลิเคชันหน้าเดียวที่มีการเชื่อมต่อที่ใช้งานได้ยาวนานฉันต้องการที่จะมีรายการเซิร์ฟเวอร์ที่เปิดอยู่ซึ่งแอปพลิเคชันไคลเอนต์จะเลือกจากการสุ่มเมื่อเริ่มต้นระบบและใช้ซ้ำตลอดอายุการใช้งานของแอปพลิเคชัน สิ่งนี้จะลบจุดเดียวของความล้มเหลว (ตัวจัดสรรภาระงาน) และเปิดใช้งานการปรับขนาดผ่านศูนย์ข้อมูลหลายแห่งและทำให้แบนด์วิดท์มากขึ้น

ทำลายตำนาน - พอร์ต 64K

เพื่อตอบคำถามเกี่ยวกับ "64,000" นี่เป็นความเข้าใจที่ผิด เซิร์ฟเวอร์สามารถเชื่อมต่อกับไคลเอนต์มากกว่า 65535 ราย ดู/networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

อย่างไรก็ตาม Http.sys บน Windows อนุญาตให้หลายแอปพลิเคชันแชร์พอร์ตเซิร์ฟเวอร์เดียวกันภายใต้สคีมา HTTP URL พวกเขาแต่ละคนลงทะเบียนการผูกโดเมนแยกกัน แต่ในที่สุดมีแอปพลิเคชันเซิร์ฟเวอร์เดียวที่พร็อกซีคำขอไปยังแอปพลิเคชันที่ถูกต้อง

อัปเดต 2019-05-30

นี่คือการเปรียบเทียบล่าสุดของไลบรารี HTTP ที่เร็วที่สุด - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

  • วันที่ทดสอบ: 2018-06-06
  • ฮาร์ดแวร์ที่ใช้: Dell R440 Xeon Gold + 10 GbE
  • ผู้นำมี reponses ข้อความธรรมดา ~ 7M ต่อวินาที (การตอบสนองไม่ใช่การเชื่อมต่อ)
  • อันที่สอง Fasthttp สำหรับ golang โฆษณาการเชื่อมต่อพร้อมกัน 1.5M - ดูhttps://github.com/valyala/fasthttp
  • ภาษาชั้นนำ ได้แก่ Rust, Go, C ++, Java, C และแม้แต่ C # อันดับที่ 11 (6.9M ต่อวินาที) Scala และ Clojure มีอันดับลดลง Python อยู่ในอันดับที่ 29 ที่ 2.7M ต่อวินาที
  • ที่ด้านล่างของรายการฉันสังเกต laravel และ cakephp, ราง, aspnet-mono-ngx, symfony, zend ทั้งหมดต่ำกว่า 10,000 ต่อวินาที โปรดทราบว่าเฟรมเวิร์กเหล่านี้ส่วนใหญ่สร้างขึ้นสำหรับเพจแบบไดนามิกและค่อนข้างเก่าอาจมีตัวแปรใหม่กว่าที่มีคุณสมบัติสูงกว่าในรายการ
  • โปรดจำไว้ว่านี่เป็นข้อความธรรมดา HTTP ไม่ใช่สำหรับความสามารถพิเศษของ Websocket: หลายคนที่มาที่นี่น่าจะสนใจการเชื่อมต่อพร้อมกันสำหรับ websocket

2
ขอบคุณสำหรับการรวมลิงก์ไปยังผู้คนที่พูดคุยเกี่ยวกับวิธีการทำ
Rick Smith

จะเกิดอะไรขึ้นถ้าเซิร์ฟเวอร์เดียวที่ไคลเอนต์เชื่อมต่ออยู่หยุดทำงาน และจะเกิดอะไรขึ้นถ้าสปาทั้งหมดของคุณเชื่อมต่อแบบสุ่มกับเซิร์ฟเวอร์เดียวและทำงานหนักเกินไป? แนวคิดในการใช้
โหลดบาลานซ์

3
ลูกค้าจะสุ่มเลือกเซิร์ฟเวอร์ โอกาสในการเชื่อมต่อแบบสุ่มทั้งหมดเป็นไปไม่ได้ในทางปฏิบัติ แม้ว่าจะสามารถติดตามจำนวนไคลเอนต์และเซิร์ฟเวอร์สามารถขอให้ไคลเอนต์ย้ายไปยังเซิร์ฟเวอร์อื่นได้หากมีคนหนาแน่นเกินไป
Todd

1
เรื่องข้อ จำกัด 64K - สิ่งที่คุณพูดเป็นความจริง แต่เป็นเรื่องปกติที่แอปเซิร์ฟเวอร์จะร้องขอพร็อกซีผ่านบริการแบ็กเอนด์บางอย่างซึ่งในกรณีนี้ "เซิร์ฟเวอร์" จะกลายเป็น "ไคลเอนต์" และอาจมี ต้องกังวลเกี่ยวกับการหมดพอร์ตชั่วคราว (เช่น: nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus ) ฉันแน่ใจว่าคุณรู้ แต่พูดถึงคนอื่น (:
jwd

@jwd จุดดีตามบริบทสำหรับ nginx บนเว็บแอป แต่สำหรับเว็บไซต์พื้นฐานการพร็อกซีดังกล่าวไม่จำเป็นต้องเกิดขึ้น เช่นเดียวกันอาจกล่าวได้ว่าเชื่อมต่อกับฐานข้อมูลผ่าน TCP โดยเว็บแอปพลิเคชัน ตามทฤษฎีแล้วสิ่งนี้แก้ไขได้โดยใช้ที่อยู่ทั้งหมดในช่วง 127. *. *. * แต่ในทางปฏิบัติฉันไม่รู้ว่านี่เป็นตัวเลือกที่ใช้ได้หรือไม่
ทอดด์

54

คำถามนี้เป็นคำถามที่ยากพอสมควร ไม่มีข้อ จำกัด ของซอฟต์แวร์ที่แท้จริงเกี่ยวกับจำนวนการเชื่อมต่อที่ใช้งานอยู่ที่เครื่องสามารถมีได้แม้ว่าระบบปฏิบัติการบางระบบจะมีข้อ จำกัด มากกว่าระบบอื่น ๆ ก็ตาม ปัญหากลายเป็นทรัพยากรอย่างหนึ่ง ตัวอย่างเช่นสมมติว่าเครื่องเดียวต้องการรองรับการเชื่อมต่อพร้อมกัน 64,000 เครื่อง หากเซิร์ฟเวอร์ใช้ RAM 1MB ต่อการเชื่อมต่อจะต้องใช้ RAM ขนาด 64GB หากไคลเอนต์แต่ละรายต้องการอ่านไฟล์ปริมาณการเข้าถึงดิสก์หรืออาร์เรย์จัดเก็บข้อมูลจะมีขนาดใหญ่เกินกว่าที่อุปกรณ์เหล่านั้นจะจัดการได้ หากเซิร์ฟเวอร์จำเป็นต้องแยกหนึ่งกระบวนการต่อการเชื่อมต่อระบบปฏิบัติการจะใช้เวลาส่วนใหญ่ในการสลับบริบทหรือกระบวนการอดอาหารสำหรับเวลาของ CPU

ปัญหา C10Kหน้ามีการอภิปรายที่ดีมากของปัญหานี้


3
คำตอบที่หลากหลาย ดูเหมือนว่า OP จะอ้างถึงสถานการณ์กรณีที่ดีที่สุดและรวมถึงวิธีที่จะเป็นประโยชน์แทนที่จะค้นหากรณีที่เลวร้ายที่สุดแล้วอ้างถึงบทความที่อาจมีวิธีแก้ไข การสังเกตคอขวดของดิสก์มีประโยชน์ การใช้ IO แบบอะซิงโครนัสสามารถเข้าถึงไคลเอ็นต์พร้อมกันจำนวนมากได้
ทอดด์

คุณจะพูดได้อย่างไรว่าไม่มีข้อ จำกัด ของซอฟต์แวร์จริงเนื่องจากขนาดพอร์ตเป็น 16 บิตซึ่งทำให้ไม่มีพอร์ตสูงสุดในทันทีที่สูงสุด 65.5K ฉันเชื่อว่าคำตอบของคุณไม่ถูกต้อง
आनंद

เครื่องของคุณสามารถมีได้มากกว่า 1 IP ดังนั้นจึงมีพอร์ตมากกว่า 2 ^ 16 พอร์ต
Arman Ordookhani

8

ในการเพิ่มสองเซ็นต์ของฉันในการสนทนากระบวนการสามารถเปิดซ็อกเก็ตจำนวนหนึ่งที่เชื่อมต่อพร้อมกันได้เท่ากับจำนวนนี้ (ในระบบลินุกซ์ประเภท) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

หมายเลขนี้สามารถแก้ไขได้ทันที (โดยผู้ใช้รูทเท่านั้น)

เสียงสะท้อน 1024> / proc / sys / net / core / somaxconn

แต่ทั้งหมดขึ้นอยู่กับกระบวนการเซิร์ฟเวอร์ฮาร์ดแวร์ของเครื่องและเครือข่ายจำนวนจริงของซ็อกเก็ตที่สามารถเชื่อมต่อได้ก่อนที่ระบบจะล่ม


1
แม้ว่าอาจจะเป็นจริงสำหรับ Linux แต่สิ่งนี้หมายถึงขีด จำกัด เสมือนไม่ใช่เกณฑ์มาตรฐานของความเป็นไปได้ คำตอบนี้มีความเฉพาะเจาะจงเล็กน้อยสำหรับความชอบของฉันและไม่ได้ระบุตัวเลขหรือตัวบ่งชี้จำนวนการเชื่อมต่อพร้อมกัน แม้จะมีความพยายาม แต่ก็ไม่มีประโยชน์มากนัก บางทีคุณอาจตอบคำถามด้วยตัวเอง: "ทำไมฉันไม่สามารถใช้เซิร์ฟเวอร์มากกว่า X การเชื่อมต่อ TCP พร้อมกันบน Linux"
ทอดด์

2
เท่าที่ผมสามารถบอกได้ว่านี้คือการที่ไม่ถูกต้อง somaxconn คือจำนวนการเชื่อมต่อที่อยู่ในคิวสูงสุดบนซ็อกเก็ตแบบเปิด (กล่าวคือเป็นค่าสูงสุดของพารามิเตอร์ backlog ของlisten(int socket, int backlog)ซึ่งไม่เกี่ยวข้องกับจำนวนซ็อกเก็ตที่กระบวนการสามารถเปิดได้
Timmmm

8

ดูเหมือนว่าคำตอบจะมีอย่างน้อย 12 ล้านหากคุณมีเซิร์ฟเวอร์ที่แข็งแรงซอฟต์แวร์เซิร์ฟเวอร์ของคุณได้รับการปรับให้เหมาะสมคุณมีลูกค้าเพียงพอ หากคุณทดสอบจากไคลเอนต์หนึ่งไปยังเซิร์ฟเวอร์หนึ่งหมายเลขพอร์ตบนไคลเอ็นต์จะเป็นขีด จำกัด ทรัพยากรที่ชัดเจนอย่างใดอย่างหนึ่ง (การเชื่อมต่อ TCP แต่ละรายการกำหนดโดยการรวมกันของ IP และหมายเลขพอร์ตที่ไม่ซ้ำกันที่ต้นทางและปลายทาง)

(คุณต้องเรียกใช้ไคลเอนต์หลายตัวมิฉะนั้นคุณจะถึงขีด จำกัด 64K สำหรับหมายเลขพอร์ตก่อน)

เมื่อพูดถึงเรื่องนี้นี่เป็นตัวอย่างคลาสสิกของลัทธิที่เชื่อว่า "ความแตกต่างระหว่างทฤษฎีและการปฏิบัติมีขนาดใหญ่กว่าในทางปฏิบัติ" ในทางปฏิบัติการบรรลุตัวเลขที่สูงขึ้นดูเหมือนจะเป็นวัฏจักรของก. เสนอการเปลี่ยนแปลงการกำหนดค่า / สถาปัตยกรรม / รหัสเฉพาะ b. ทดสอบจนกว่าคุณจะถึงขีด จำกัด c. ฉันเสร็จแล้วหรือยัง? ถ้าไม่เช่นนั้นง. หาว่าอะไรเป็นปัจจัย จำกัด จ. กลับไปที่ขั้นตอน A (ล้างและทำซ้ำ)

นี่คือตัวอย่างที่มีการเชื่อมต่อ TCP 2 ล้านรายการบนกล่องที่มีเนื้อวัว (RAM 128GB และ 40 คอร์) ที่รัน Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - พวกเขาสิ้นสุดลงแล้ว ต้องการเซิร์ฟเวอร์ที่มีความสำคัญอย่างสมเหตุสมผลถึง 50 เครื่องเพื่อให้ไคลเอนต์โหลด (ไคลเอนต์ขนาดเล็กเริ่มต้นของพวกเขาสูงสุดจนถึงช่วงต้นเช่น "เพิ่มสูงสุด 4core / 15gb box ที่ไคลเอนต์ 450k")

นี่คือการอ้างอิงไปอีกคราวนี้ 10 ล้าน: http://goroutines.com/10m

สิ่งนี้ดูเหมือนจะใช้ java และการเชื่อมต่อ 12 ล้านครั้ง: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/


ลิงก์ใหม่ที่ยอดเยี่ยมพร้อมความเข้าใจที่ถูกต้องเกี่ยวกับคำถาม ฉันชอบคำแนะนำทั่วไปสำหรับการชนกั้น -> แก้ไขอุปสรรค ทุกคนมีสถานการณ์เฉพาะที่แตกต่างกัน แต่อย่างน้อยพวกเขาก็มีข้อบ่งชี้ว่าอะไรคือสิ่งที่สามารถทำได้ในเชิงเศรษฐกิจ / ในทางปฏิบัติ เราไม่ควรสัญญากับลูกค้า 100 ล้านคนต่อเซิร์ฟเวอร์เร็ว ๆ นี้
ทอดด์

5

โปรดทราบว่าโดยทั่วไป HTTP จะไม่เปิดการเชื่อมต่อ TCP ไว้นานเกินกว่าที่จะส่งเพจไปยังไคลเอนต์ และโดยปกติผู้ใช้จะใช้เวลาในการอ่านหน้าเว็บมากกว่าที่จะดาวน์โหลดหน้า ... ในขณะที่ผู้ใช้กำลังดูหน้าเว็บเขาไม่ได้เพิ่มภาระให้กับเซิร์ฟเวอร์เลย

ดังนั้นจำนวนคนที่สามารถเข้าชมเว็บไซต์ของคุณพร้อมกันจึงมีมากกว่าจำนวนการเชื่อมต่อ TCP ที่สามารถให้บริการพร้อมกันได้


13
นี่ไม่ตอบคำถามเลย โดยไม่คำนึงถึงความถูกต้องของสิ่งที่คุณพูดจะยังคงมีการเชื่อมต่อ TCP พร้อมกันจำนวนหนึ่งในเวลาที่กำหนดสูงสุดคืออะไร? นี่คือสาระสำคัญของคำถาม
ทอดด์

3
หากคุณมีสิ่งที่ควรค่าแก่การมีส่วนร่วม Todd ก็จงดำเนินการต่อไป
Jeremy Friesner

8
ฉันมีคำตอบแล้วเมื่อวันที่ 28 มีนาคมคุณต้องพลาด ในโลกสมัยใหม่ของแอปพลิเคชั่นหน้าเดียวที่มีการเชื่อมต่อแบบยาวและการเชื่อมต่อเว็บซ็อกเก็ต HTTP ไม่ใช่สิ่งที่สั้นเสมอไป แต่ถึงแม้ว่ามันจะสั้นก็ยังมีจำนวนการเชื่อมต่อพร้อมกันสูงสุด ความพยายามที่จะอธิบายคำถามนี้ไม่ใช่การอ้าง IMO คำตอบนี้ควรนำไปแสดงความคิดเห็นในคำถามได้ดีกว่าซึ่งมีประโยชน์อย่างแน่นอน แต่คำถามเกี่ยวข้องกับ "การเชื่อมต่อซ็อกเก็ต" ไม่ใช่ "คน" คำถามเกี่ยวกับอัตราส่วน (ผู้ใช้: การเชื่อมต่อที่ใช้งานอยู่) ควรเป็นคำถามแยกต่างหากหากต้องการ
ทอดด์

1
Keep Alive บนการเชื่อมต่อ HTTP TCP ได้รับการร้องขอจากเบราว์เซอร์ตั้งแต่สหัสวรรษที่แล้ว - ขึ้นอยู่กับเซิร์ฟเวอร์ว่าอนุญาตให้การเชื่อมต่อมีชีวิตอยู่หรือไม่และช่วงหมดเวลาที่ไม่ได้ใช้งานจะเป็นเท่าใด การอนุญาต Keep Alive ช่วยลดเวลาแฝงของกลุ่มคำขอ (เช่นหน้า html และเนื้อหาที่เกี่ยวข้อง) แต่จะเพิ่มการใช้ทรัพยากรบนเซิร์ฟเวอร์
iheggie

1

ในกรณีของโปรโตคอล IPv4 เซิร์ฟเวอร์ที่มีที่อยู่ IP เดียวที่รับฟังบนพอร์ตเดียวเท่านั้นที่สามารถรองรับที่อยู่ IP 2 ^ 32 x 2 ^ 16 พอร์ตดังนั้นซ็อกเก็ตที่ไม่ซ้ำกัน 2 ^ 48 หากคุณพูดเกี่ยวกับเซิร์ฟเวอร์เป็นเครื่องจริงและคุณสามารถใช้พอร์ต 2 ^ 16 ทั้งหมดได้อาจมีได้สูงสุด 2 ^ 48 x 2 ^ 16 = 2 ^ 64 ซ็อกเก็ต TCP / IP ที่ไม่ซ้ำกันสำหรับที่อยู่ IP เดียว โปรดทราบว่าพอร์ตบางพอร์ตถูกสงวนไว้สำหรับระบบปฏิบัติการดังนั้นจำนวนนี้จะต่ำกว่า สรุป:

1 IP และ 1 พอร์ต -> 2 ^ 48 ซ็อกเก็ต

1 IP และพอร์ตทั้งหมด -> 2 ^ 64 ซ็อกเก็ต

ซ็อกเก็ต IPv4 ที่ไม่ซ้ำกันทั้งหมดในจักรวาล -> 2 ^ 96 ซ็อกเก็ต


0

มีการอภิปรายสองแบบที่แตกต่างกันที่นี่หนึ่งคือจำนวนคนที่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ของคุณได้ ข้อนี้ได้รับคำตอบอย่างเพียงพอจากผู้อื่นดังนั้นฉันจะไม่พูดถึงเรื่องนั้น

อื่น ๆ คือกี่พอร์ตที่เซิร์ฟเวอร์ของคุณสามารถฟังได้? ฉันเชื่อว่านี่คือที่มาของตัวเลข 64K จริงๆแล้วโปรโตคอล TCP ใช้ตัวระบุ 16 บิตสำหรับพอร์ตซึ่งแปลเป็น 65536 (มากกว่า 64K เล็กน้อย) ซึ่งหมายความว่าคุณสามารถมี "ผู้ฟัง" ที่แตกต่างกันจำนวนมากบนเซิร์ฟเวอร์ต่อที่อยู่ IP


เพื่อประโยชน์ของคุณฉันได้เพิ่มส่วนพิเศษในคำตอบของฉันเพื่อตอบสนองความเข้าใจผิดของคุณ คำถามนี้เกี่ยวข้องกับ "การเชื่อมต่อซ็อกเก็ต" ไม่ใช่ "บุคคล" ซึ่งเป็นความแตกต่างที่สำคัญในบริบทของคำถามนี้
ทอดด์

หากเรากำลังพูดถึงเครื่องเซิร์ฟเวอร์เครื่องเดียวและเราเตอร์เครื่องเดียวฉันคิดว่าคำตอบนี้ถูกต้อง แต่ @Todd กำลังทำฟาร์มของเครื่องเซิร์ฟเวอร์ซึ่งผู้ใช้สามารถเชื่อมต่อกับเครื่องใดก็ได้แบบสุ่มผ่านตัวโหลดบาลานเซอร์
Amr

@amr ไม่ถูกต้อง คำตอบของฉันคือเกี่ยวกับเครื่องเดียว "Webfarm?" มีส่วนสำหรับความคมชัดและคำแนะนำสำหรับการก้าวไปไกลกว่านั้นและสรุปว่าตัวจัดสรรภาระงานไม่จำเป็นสำหรับสถาปัตยกรรมที่ดี คุณยังไม่ได้อ่านคำตอบของฉันอย่างละเอียด
ทอดด์

0

ฉันคิดว่าจำนวนการเชื่อมต่อซ็อกเก็ตพร้อมกันหนึ่งเว็บเซิร์ฟเวอร์สามารถจัดการได้ส่วนใหญ่ขึ้นอยู่กับจำนวนทรัพยากรที่แต่ละการเชื่อมต่อใช้และจำนวนทรัพยากรทั้งหมดที่มีอยู่บนเซิร์ฟเวอร์ซึ่ง จำกัด การกำหนดค่าทรัพยากรเว็บเซิร์ฟเวอร์อื่น ๆ

เพื่อเป็นตัวอย่างหากทุกการเชื่อมต่อซ็อกเก็ตใช้ทรัพยากรเซิร์ฟเวอร์ 1MB และเซิร์ฟเวอร์มี RAM 16GB ที่พร้อมใช้งาน (ในทางทฤษฎี) นั่นหมายความว่าจะสามารถรองรับการเชื่อมต่อพร้อมกัน (16GB / 1MB) เท่านั้น ฉันคิดว่ามันง่ายอย่างนั้น ... จริงๆ!

ดังนั้นไม่ว่าเว็บเซิร์ฟเวอร์จะจัดการกับการเชื่อมต่ออย่างไรในที่สุดการเชื่อมต่อทุกครั้งจะใช้ทรัพยากรบางอย่าง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.