SSL มีค่าใช้จ่ายเท่าใด

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

ปรับปรุง

มีคำถามเกี่ยวกับ HTTPS กับ HTTPแต่ฉันสนใจที่จะดูในสแต็กที่ต่ำกว่า

(ฉันแทนที่วลี "ลำดับความสำคัญ" ไปสู่ความสับสนหลีกเลี่ยง; ผมก็ใช้มันเป็นศัพท์แสงทางการมากกว่าในความรู้สึก compsci อย่างเป็นทางการแน่นอนถ้าฉัน. ได้หมายความว่ามันอย่างเป็นทางการเป็น geek จริงฉันจะได้รับความคิดไบนารีมากกว่า ทศนิยม! ;-)

ปรับปรุง

ตามคำขอในความคิดเห็นสมมติว่าเรากำลังพูดถึงข้อความขนาดดี (ช่วง 1k-10k) ผ่านการเชื่อมต่อแบบต่อเนื่อง ดังนั้นการตั้งค่าการเชื่อมต่อและโอเวอร์เฮดแพ็คเก็ตจึงไม่มีปัญหาที่สำคัญ

ลำดับความสำคัญ: ศูนย์

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

ค่าใช้จ่ายหลักของ SSL คือการจับมือกัน นั่นคือสิ่งที่การเข้ารหัสแบบอสมมาตรมีราคาแพงเกิดขึ้น หลังจากการเจรจาจะมีการใช้ ciphers สมมาตรที่ค่อนข้างมีประสิทธิภาพ นั่นเป็นสาเหตุที่เป็นประโยชน์อย่างมากในการเปิดใช้งานเซสชัน SSL สำหรับบริการ HTTPS ของคุณซึ่งมีการเชื่อมต่อมากมาย สำหรับการเชื่อมต่อที่ยาวนาน "end-effect" นี้ไม่สำคัญและเซสชันไม่มีประโยชน์

นี่เป็นเรื่องเล็ก ๆ น้อยที่น่าสนใจ เมื่อ Google เปลี่ยน Gmail ให้ใช้ HTTPS ไม่จำเป็นต้องมีทรัพยากรเพิ่มเติม ไม่มีฮาร์ดแวร์เครือข่ายไม่มีโฮสต์ใหม่ มันเพิ่มโหลด CPU เพียงประมาณ 1%

ฉันที่สอง @erickson: การลงโทษการถ่ายโอนข้อมูลความเร็วสูงนั้นเล็กน้อยมาก ซีพียูสมัยใหม่เข้าถึงปริมาณการเข้ารหัส / AES หลายร้อย MBit / s ดังนั้นหากคุณไม่ได้อยู่ในระบบที่ จำกัด ทรัพยากร (โทรศัพท์มือถือ) TLS / SSL นั้นเร็วพอสำหรับการสะพายข้อมูล

แต่โปรดจำไว้ว่าการเข้ารหัสทำให้การแคชและการโหลดบาลานซ์ยากขึ้นมาก ซึ่งอาจส่งผลให้เกิดการลงโทษอย่างมาก

แต่การตั้งค่าการเชื่อมต่อเป็นตัวหยุดการแสดงสำหรับแอพพลิเคชั่นมากมาย สำหรับแบนด์วิดท์ต่ำการสูญเสียแพ็กเก็ตสูงการเชื่อมต่อเวลาแฝงที่สูง (อุปกรณ์มือถือในชนบท) TLT ที่ต้องการโดย TLS อาจทำให้บางสิ่งช้าลงเป็นสิ่งที่ใช้ไม่ได้

ตัวอย่างเช่นเราต้องวางข้อกำหนดการเข้ารหัสสำหรับการเข้าถึงบางส่วนของเว็บแอพภายในของเรา - ซึ่งเป็นสิ่งที่ไม่สามารถใช้งานได้หากใช้จากจีน

สมมติว่าคุณไม่นับการตั้งค่าการเชื่อมต่อ (ตามที่คุณระบุในการอัปเดต) มันขึ้นอยู่กับรหัสที่เลือก เครือข่ายค่าใช้จ่าย (ในแง่ของแบนด์วิดธ์) จะเล็กน้อย โอเวอร์เฮดของ CPU จะถูกควบคุมด้วยการเข้ารหัส บนมือถือ Core i5 ของฉันฉันสามารถเข้ารหัสได้ประมาณ 250 MB ต่อวินาทีด้วย RC4 ในแกนเดียว (RC4 เป็นสิ่งที่คุณควรเลือกเพื่อให้ได้ประสิทธิภาพสูงสุด) AES ช้าลงโดยให้ "เฉพาะ" ประมาณ 50 MB / s ดังนั้นหากคุณเลือกเลขศูนย์ที่ถูกต้องคุณจะไม่สามารถจัดการแกนหลักปัจจุบันเดียวที่ยุ่งกับค่าใช้จ่ายการเข้ารหัสแม้ว่าคุณจะมีสาย 1 Gbit ที่ใช้งานอย่างเต็มที่ [ แก้ไข : ไม่ควรใช้ RC4 เนื่องจากไม่ปลอดภัยอีกต่อไป อย่างไรก็ตามการสนับสนุนฮาร์ดแวร์ AES นั้นมีอยู่ในซีพียูจำนวนมากซึ่งทำให้การเข้ารหัส AES เป็นไปอย่างรวดเร็วบนแพลตฟอร์มดังกล่าว]

อย่างไรก็ตามการสร้างการเชื่อมต่อนั้นแตกต่างกัน ขึ้นอยู่กับการนำไปใช้ (เช่นการสนับสนุน TLS false start) จะเพิ่มการเดินทางไปกลับซึ่งอาจทำให้เกิดความล่าช้าที่สังเกตเห็นได้ นอกจากนี้การเข้ารหัสลับที่มีราคาแพงเกิดขึ้นในการเชื่อมต่อครั้งแรก (CPU ที่กล่าวถึงข้างต้นสามารถรับได้ 14 การเชื่อมต่อต่อคอร์ต่อวินาทีหากคุณใช้คีย์ 4096 บิตและ 100 ถ้าคุณใช้คีย์ 2048 บิต) ในการเชื่อมต่อที่ตามมามักจะมีการใช้เซสชันก่อนหน้านี้อีกครั้งเพื่อหลีกเลี่ยง crypto ราคาแพง

ดังนั้นเพื่อสรุป:

ถ่ายโอนในการเชื่อมต่อที่จัดตั้งขึ้น:

• ล่าช้า: ไม่มีเลย
• CPU: ไม่สำคัญ
• แบนด์วิดธ์: เล็กน้อย

สถานประกอบการเชื่อมต่อครั้งแรก:

• ความล่าช้า: การเดินทางไปกลับเพิ่มเติม
• แบนด์วิดท์: หลายกิโลไบต์ (ใบรับรอง)
• CPU บนไคลเอ็นต์: ปานกลาง
• CPU บนเซิร์ฟเวอร์: สูง

สถานประกอบการเชื่อมต่อที่ตามมา:

• ล่าช้า: ไปกลับเพิ่มเติม (ไม่แน่ใจว่าหนึ่งหรือมากกว่านั้นอาจขึ้นอยู่กับการใช้งาน)
• แบนด์วิดธ์: เล็กน้อย
• CPU: ไม่มีเลย