มีความแตกต่างที่สำคัญในประสิทธิภาพระหว่าง http และ https หรือไม่ ฉันดูเหมือนจะจำได้ว่าการอ่าน HTTPS นั้นอาจเร็วถึงห้าเท่าของ HTTP สิ่งนี้ใช้ได้กับ webservers / browser รุ่นปัจจุบันหรือไม่? ถ้ามีจะมีสมุดปกขาวให้สนับสนุนไหม?

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

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

ดังที่คนอื่น ๆ กล่าวว่าจะมีค่าใช้จ่ายในระดับหนึ่งเนื่องจากการเข้ารหัส แต่ขึ้นอยู่กับ:

• ฮาร์ดแวร์
• ซอฟต์แวร์เซิร์ฟเวอร์
• อัตราส่วนของไดนามิกเทียบกับเนื้อหาแบบคงที่
• ระยะทางของไคลเอ็นต์ไปยังเซิร์ฟเวอร์
• ความยาวเซสชันทั่วไป
• ฯลฯ (รายการโปรดส่วนตัวของฉัน)
• พฤติกรรมการแคชของลูกค้า

จากประสบการณ์ของฉันเซิร์ฟเวอร์ที่ใช้เนื้อหาแบบไดนามิกมีแนวโน้มที่จะได้รับผลกระทบน้อยลงโดย HTTPS เนื่องจากเวลาที่ใช้ในการเข้ารหัส (SSL-overhead) นั้นไม่มีนัยสำคัญเมื่อเทียบกับเวลาในการสร้างเนื้อหา

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

แก้ไข: อีกประเด็นหนึ่งที่หลายคนนำเสนอคือการจับมือกัน SSL นั้นเป็นต้นทุนหลักของ HTTPS ถูกต้องซึ่งเป็นสาเหตุที่ "ความยาวเซสชันปกติ" และ "พฤติกรรมการแคชของลูกค้า" มีความสำคัญ

เซสชันที่สั้นมากหลายครั้งทำให้เวลาจับมือจะทำให้ปัจจัยด้านประสิทธิภาพอื่น ๆ เซสชันที่ยาวขึ้นจะหมายถึงต้นทุนการจับมือกันเกิดขึ้นเมื่อเริ่มต้นเซสชัน แต่คำขอที่ตามมาจะมีค่าใช้จ่ายค่อนข้างต่ำ

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

HTTPS ต้องการการจับมือเริ่มต้นซึ่งช้ามาก จำนวนข้อมูลที่ถ่ายโอนจริงเป็นส่วนหนึ่งของการจับมือไม่มาก (ต่ำกว่า 5 kB โดยทั่วไป) แต่สำหรับคำขอที่มีขนาดเล็กมากนี่อาจเป็นค่าใช้จ่ายเล็กน้อย อย่างไรก็ตามเมื่อจับมือเสร็จแล้วจะมีการใช้การเข้ารหัสแบบสมมาตรในรูปแบบที่รวดเร็วดังนั้นค่าใช้จ่ายจึงน้อยมาก บรรทัดล่าง: การทำคำขอสั้น ๆ ผ่าน HTTPS จะช้ากว่า HTTP เล็กน้อย แต่ถ้าคุณถ่ายโอนข้อมูลจำนวนมากในคำขอเดียวความแตกต่างจะไม่มีนัยสำคัญ

อย่างไรก็ตาม keepalive เป็นพฤติกรรมเริ่มต้นใน HTTP / 1.1 ดังนั้นคุณจะจับมือเดียวแล้วขอจำนวนมากผ่านการเชื่อมต่อเดียวกัน สิ่งนี้สร้างความแตกต่างที่สำคัญสำหรับ HTTPS คุณควรจะทำโปรไฟล์เว็บไซต์ของคุณ (ตามที่คนอื่นแนะนำ) เพื่อให้แน่ใจ แต่ฉันสงสัยว่าจะไม่มีความแตกต่างด้านประสิทธิภาพ

เพื่อให้เข้าใจอย่างถ่องแท้ว่า HTTPS จะเพิ่มเวลาแฝงของคุณอย่างไรคุณต้องเข้าใจว่าการเชื่อมต่อ HTTPS นั้นถูกสร้างขึ้นอย่างไร นี่คือแผนภาพที่ดี กุญแจสำคัญคือแทนที่จะให้ลูกค้ารับข้อมูลหลังจาก 2 "ขา" (ไปกลับหนึ่งรอบคุณส่งคำขอเซิร์ฟเวอร์ส่งคำตอบ) ลูกค้าจะไม่ได้รับข้อมูลจนกว่าอย่างน้อย 4 ขา (2 รอบเดินทาง) . ดังนั้นถ้าใช้เวลา 100 ms สำหรับแพ็กเก็ตที่จะย้ายระหว่างไคลเอนต์และเซิร์ฟเวอร์คำขอ HTTPS แรกของคุณจะใช้เวลาอย่างน้อย 500 ms

แน่นอนว่าสิ่งนี้สามารถลดลงได้โดยใช้การเชื่อมต่อ HTTPS อีกครั้ง (ซึ่งเบราว์เซอร์ใดที่ควรทำ) แต่จะอธิบายบางส่วนของแผงควบคุมเริ่มต้นนั้นเมื่อโหลดเว็บไซต์ HTTPS

ค่าใช้จ่ายไม่ได้เกิดจากการเข้ารหัส บน CPU ที่ทันสมัยการเข้ารหัสที่ SSL ต้องการนั้นเป็นเรื่องเล็กน้อย

ค่าโสหุ้ยเกิดจากการจับมือ SSL ซึ่งมีความยาวและเพิ่มจำนวนรอบการเดินทางที่จำเป็นสำหรับเซสชัน HTTPS ผ่าน HTTP อย่างมาก

วัด (โดยใช้เครื่องมือเช่น Firebug) เวลาในการโหลดหน้าเว็บขณะที่เซิร์ฟเวอร์อยู่ที่ส่วนท้ายของลิงก์เวลาแฝงที่จำลองสูง มีเครื่องมือในการจำลองการเชื่อมโยงเวลาแฝงที่สูง - สำหรับ Linux นั้นมี "netem" เปรียบเทียบ HTTP กับ HTTPS ในการตั้งค่าเดียวกัน

เวลาแฝงสามารถลดลงได้บ้าง:

• ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ของคุณใช้ HTTP keepalives - สิ่งนี้ทำให้ลูกค้าสามารถใช้เซสชัน SSL ซ้ำได้ซึ่งจะช่วยลดความจำเป็นในการจับมืออีกครั้ง
• ลดจำนวนการร้องขอให้น้อยที่สุดเท่าที่จะทำได้โดยการรวมทรัพยากรเท่าที่เป็นไปได้ (เช่น. js รวมถึงไฟล์, CSS) และกระตุ้นการแคชฝั่งไคลเอ็นต์
• ลดจำนวนการโหลดหน้าเว็บเช่นโดยการโหลดข้อมูลที่ไม่จำเป็นในหน้า (อาจเป็นองค์ประกอบ HTML ที่ซ่อนอยู่) จากนั้นแสดงโดยใช้ไคลเอนต์สคริปต์

อัปเดตธันวาคม 2014

คุณสามารถทดสอบความแตกต่างระหว่างประสิทธิภาพ HTTP และ HTTPS ในเบราว์เซอร์ของคุณเองได้อย่างง่ายดายโดยใช้เว็บไซต์ทดสอบ vs vs HTTPSโดยAnthumChris :“ หน้านี้ทำการวัดความเร็วในการโหลดผ่าน HTTP ที่ไม่ปลอดภัยและการเชื่อมต่อ HTTPS ที่เข้ารหัส ทั้งสองหน้าโหลดภาพที่ไม่ซ้ำกันและไม่ซ้ำกัน 360 ภาพ (รวมทั้งหมด 2.04 MB)”

ผลลัพธ์อาจทำให้คุณประหลาดใจ

สิ่งสำคัญคือต้องมีความรู้ที่ทันสมัยเกี่ยวกับประสิทธิภาพของ HTTPS เนื่องจากLet's Encrypt Certificate Authority จะเริ่มออกใบรับรอง SSL อัตโนมัติและอัตโนมัติในฤดูร้อนปี 2015 ด้วย Mozilla, Akamai, Cisco, Electronic Frontier Foundation และ IdenTrust

อัปเดตมิถุนายน 2558

อัปเดตเกี่ยวกับ Let's Encrypt - มาถึงเดือนกันยายน 2558:

• Let's Encrypt Launch Schedule (16 มิ.ย. 2558)
• Let's เข้ารหัสรากและใบรับรองระดับกลาง (4 มิ.ย. 2015)
• ร่างข้อตกลงสมาชิกเข้ารหัส Let's Let's 21 พฤษภาคม 2015

ข้อมูลเพิ่มเติมเกี่ยวกับ Twitter: @letsencrypt

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับประสิทธิภาพ HTTPS และ SSL / TLS โปรดดู:

• TLS เร็วหรือยัง
• เครือข่ายเบราว์เซอร์ประสิทธิภาพสูงบทที่ 4: ความปลอดภัยของเลเยอร์การขนส่ง
• โอเวอร์คล็อก SSL
• กายวิภาคและประสิทธิภาพของการประมวลผล SSL

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความสำคัญของการใช้ HTTPS โปรดดู:

• ทำไมต้อง HTTPS สำหรับทุกสิ่ง (มาตรฐาน HTTPS เท่านั้น)
• Let's Encrypt (กลุ่มวิจัยความปลอดภัยทางอินเทอร์เน็ต)
• HTTPS ทุกที่ (มูลนิธิพรมแดนอิเล็กทรอนิกส์)

เพื่อสรุปให้ฉันพูดIlya Grigorik : "TLS มีปัญหาประสิทธิภาพการทำงานหนึ่งอย่าง: มันไม่ได้ใช้กันอย่างแพร่หลายพอทุกอย่างอื่นสามารถปรับให้เหมาะสม"

ขอบคุณChris - ผู้เขียนเกณฑ์ทดสอบ HTTP vs HTTPS - สำหรับความคิดเห็นของเขาด้านล่าง

คำตอบยอดนิยมปัจจุบันไม่ถูกต้องอย่างสมบูรณ์

ตามที่คนอื่น ๆ ชี้ไปที่นี่ https ต้องจับมือกันดังนั้นจึงมี TCP / IP roundtrips มากขึ้น

ในสภาพแวดล้อม WAN โดยทั่วไปเวลาแฝงจะกลายเป็นปัจจัย จำกัด และไม่ใช่การใช้ CPU ที่เพิ่มขึ้นบนเซิร์ฟเวอร์

เพียงจำไว้ว่าเวลาแฝงจากยุโรปไปยังสหรัฐอเมริกาอาจอยู่ที่ประมาณ 200 มิลลิวินาที (เวลา torundtrip)

คุณสามารถวัดนี้ (กรณีที่ผู้ใช้คนเดียว) กับHttpWatch

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

ไม่มีคำตอบเดียวสำหรับสิ่งนี้

การเข้ารหัสจะใช้ CPU มากขึ้นเสมอ สามารถถ่ายไปยังฮาร์ดแวร์เฉพาะในหลายกรณีและค่าใช้จ่ายจะแตกต่างกันตามอัลกอริทึมที่เลือก ยกตัวอย่างเช่น 3des มีราคาแพงกว่า AES อัลกอริทึมบางอย่างมีราคาแพงกว่าเครื่องเข้ารหัส บางแห่งมีค่าใช้จ่ายที่ตรงกันข้าม

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

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

ฉันสามารถบอกคุณ (ในฐานะผู้ใช้แบบ dialup) ว่าหน้าเดียวกันผ่าน SSL นั้นช้ากว่า HTTP ปกติหลายเท่า ...

ในหลายกรณีประสิทธิภาพของการจับมือ SSL จะลดลงเนื่องจากข้อเท็จจริงที่ว่าเซสชัน SSL สามารถถูกแคชทั้งสองด้าน (เดสก์ท็อปและเซิร์ฟเวอร์) บนเครื่อง Windows เช่นเซสชัน SSL สามารถแคชได้นานถึง 10 ชั่วโมง ดู http://support.microsoft.com/kb/247658/EN-US ตัวเร่งความเร็ว SSL บางตัวจะมีพารามิเตอร์ที่ช่วยให้คุณปรับเวลาที่เซสชันถูกแคช

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

ฉันทำการทดลองเล็กน้อยและมีความแตกต่างของเวลา 16% สำหรับภาพเดียวกันจาก flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

แน่นอนว่าตัวเลขเหล่านี้ขึ้นอยู่กับปัจจัยหลายอย่างเช่นประสิทธิภาพของคอมพิวเตอร์ความเร็วในการเชื่อมต่อโหลดเซิร์ฟเวอร์ QoS บนเส้นทาง (เส้นทางเครือข่ายเฉพาะที่นำมาจากเบราว์เซอร์ไปยังเซิร์ฟเวอร์) แต่มันแสดงให้เห็นถึงแนวคิดทั่วไป: HTTPS เป็น HTTP ช้าเพราะ HTTP ต้องการการดำเนินการเพิ่มเติมให้เสร็จสมบูรณ์ (SSL handshaking และการเข้ารหัส / ถอดรหัสข้อมูล)

นี่เป็นบทความที่ยอดเยี่ยม (เก่าไปหน่อย แต่ก็ยังยอดเยี่ยม) เกี่ยวกับ SSL handshake latency ช่วยฉันระบุ SSL ว่าเป็นสาเหตุหลักของความช้าสำหรับลูกค้าที่ใช้แอพของฉันผ่านการเชื่อมต่ออินเทอร์เน็ตที่ช้า:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

เนื่องจากฉันกำลังตรวจสอบปัญหาเดียวกันสำหรับโครงการของฉันฉันจึงพบสไลด์เหล่านี้ เก่ากว่า แต่น่าสนใจ:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

ดูเหมือนว่าจะมีกรณีขอบที่น่ารังเกียจที่นี่: อาแจ็กซ์มากกว่า wifi แออัด

อาแจ็กซ์มักจะหมายความว่า KeepAlive หมดเวลาหลังจากพูด 20 วินาที อย่างไรก็ตาม wifi หมายความว่าการเชื่อมต่อ ajax (เร็วอย่างยิ่ง) จะต้องเดินทางไปกลับหลายรอบ ยิ่งไปกว่านั้น wifi มักจะสูญเสียแพ็กเก็ตและมี TCP retransmits ในกรณีนี้ HTTPS ทำงานได้แย่มากจริงๆ!

TLS เร็วหรือยัง ใช่.

• ดู: https://www.youtube.com/watch?v=0EB7zh_7UE4
• อ่าน: https://istlsfastyet.com/

มีหลายโครงการที่มุ่งหวังที่จะทำให้เส้นพร่ามัวและทำให้ HTTPS เป็นไปอย่างรวดเร็ว เช่นเดียวกับSPDYและmod-SPDY

HTTP VS HTTPS เปรียบเทียบประสิทธิภาพ

ฉันเชื่อมโยง HTTPS กับหน้าโหลดช้าลงเสมอเมื่อเทียบกับ HTTP แบบเก่า ในฐานะนักพัฒนาเว็บประสิทธิภาพของหน้าเว็บเป็นสิ่งสำคัญสำหรับฉันและทุกสิ่งที่จะทำให้ประสิทธิภาพการทำงานของหน้าเว็บของฉันช้าลง

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

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

เพื่อให้เข้าใจถึงผลกระทบด้านประสิทธิภาพและดูว่าตัวเองมีผลกระทบต่อประสิทธิภาพหรือไม่ฉันใช้เว็บไซต์นี้เป็นแพลตฟอร์มทดสอบ ฉันมุ่งหน้าไปที่ webpagetest.org และใช้เครื่องมือเปรียบเทียบแบบเห็นภาพเพื่อเปรียบเทียบการโหลดเว็บไซต์นี้โดยใช้ HTTPS กับ HTTP

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

ไซต์ของคุณอาจแตกต่างกันและเป็นสิ่งสำคัญในการทดสอบไซต์ของคุณอย่างละเอียดและตรวจสอบผลกระทบด้านประสิทธิภาพที่เกี่ยวข้องกับการเปลี่ยนเป็น HTTPS

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

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

ความแตกต่างด้านประสิทธิภาพที่สำคัญกว่านั้นคือเซสชัน HTTPS เปิด ketp ขณะที่ผู้ใช้เชื่อมต่อ HTTP 'เซสชัน' ใช้เวลานานสำหรับคำขอรายการเดียว

คุณกำลังใช้งานเว็บไซต์ที่มีผู้ใช้งานพร้อมกันจำนวนมากคาดว่าจะซื้อหน่วยความจำจำนวนมาก

นี่เกือบจะเป็นจริงเนื่องจาก SSL ต้องการขั้นตอนเพิ่มเติมของการเข้ารหัสที่ไม่จำเป็นต้องใช้โดยไม่ใช่ SLL HTTP

HTTPS ส่งผลกระทบต่อความเร็วหน้าจริง ๆ ...

คำพูดข้างต้นแสดงให้เห็นถึงความโง่เขลาของหลาย ๆ คนเกี่ยวกับความปลอดภัยและความเร็วของเว็บไซต์ การจับมือกันเซิร์ฟเวอร์ HTTPS / SSL สร้างจุดเริ่มต้นในการเชื่อมต่ออินเทอร์เน็ต มีความล่าช้าเล็กน้อยก่อนที่อะไรจะเริ่มแสดงผลบนหน้าจอเบราว์เซอร์ของผู้เข้าชม การหน่วงเวลานี้วัดจากข้อมูล Time-to-First-Byte

HTTPS handshake overhead ปรากฏในข้อมูล Time-to-First-Byte (TTFB) TTFB ทั่วไปมีช่วงตั้งแต่ต่ำกว่า 100 มิลลิวินาที (ดีที่สุด) จนถึง 1.5 วินาที (กรณีเลวร้ายที่สุด) แต่แน่นอนด้วย HTTPS มันแย่กว่า 500 มิลลิวินาที

การเดินทางไปกลับ, การเชื่อมต่อ 3G แบบไร้สายอาจมี 500 มิลลิวินาทีหรือมากกว่า การเดินทางเพิ่มเติมล่าช้าสองเท่าเป็น 1 วินาทีหรือมากกว่า นี่เป็นผลกระทบด้านลบที่ใหญ่หลวงต่อประสิทธิภาพของมือถือ ข่าวร้ายมาก

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

ที่มา: Pagepipe

เบราว์เซอร์สามารถยอมรับโปรโตคอล HTTP / 1.1 ด้วย HTTP หรือ HTTPS แต่เบราว์เซอร์สามารถรองรับโปรโตคอล HTTP / 2.0 ด้วย HTTPS เท่านั้น ความแตกต่างของโปรโตคอลจาก HTTP / 1.1 ถึง HTTP / 2.0 ทำให้ HTTP / 2.0 โดยเฉลี่ยเร็วกว่า HTTP / 1.1 4-5 เท่า นอกจากนี้ไซต์ที่ใช้ HTTPS ส่วนใหญ่ทำผ่านโปรโตคอล HTTP / 2.0 ดังนั้น HTTPS เกือบจะเร็วกว่า HTTP เกือบทุกครั้งเนื่องจากโปรโตคอลต่างๆที่ใช้โดยทั่วไป อย่างไรก็ตามถ้าเปรียบเทียบ HTTP ผ่าน HTTP / 1.1 กับ HTTPS ผ่าน HTTP / 1.1 แสดงว่า HTTP นั้นเร็วกว่า HTTPS โดยเฉลี่ยเล็กน้อย

นี่คือการเปรียบเทียบบางอย่างที่ฉันใช้กับ Chrome (Ver. 64):

HTTPS ผ่าน HTTP / 1.1:

• เวลาเฉลี่ยในการโหลดหน้าเว็บโดยเฉลี่ย 0.47 วินาที
• 0.05 วินาทีช้ากว่า HTTP ผ่าน HTTP / 1.1
• ช้ากว่า HTTPS 0.37 วินาทีใน HTTP / 2.0

HTTP ผ่าน HTTP / 1.1

• เวลาเฉลี่ยในการโหลดหน้าเว็บ 0.42 วินาที
• 0.05 วินาทีเร็วกว่า HTTPS ผ่าน HTTP / 1.1
• ช้ากว่า HTTPS 0.32 วินาทีใน HTTP / 2.0

HTTPS ผ่าน HTTP / 2.0

• ความเร็วในการโหลดเฉลี่ย 0.10 วินาที
• 0.32 วินาทีเร็วกว่า HTTP ผ่าน HTTP / 1.1
• เร็วกว่า HTTPS 0.37 วินาทีใน HTTPS / 1.1