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

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

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

กล่าวโดยย่อ: คุณควรจะสามารถบรรลุตามลำดับของการเชื่อมต่อ 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

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

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

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

cat / proc / sys / net / core / somaxconn

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

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

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

ดูเหมือนว่าคำตอบจะมีอย่างน้อย 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/

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

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

ในกรณีของโปรโตคอล 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 ซ็อกเก็ต

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

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

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

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

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