Có sự khác biệt lớn nào về hiệu suất giữa http và https không? Tôi dường như nhớ lại việc đọc rằng HTTPS có thể nhanh bằng 1/5 so với HTTP. Điều này có hợp lệ với trình duyệt web / trình duyệt hiện tại không? Nếu vậy, có bất kỳ whitepapers để hỗ trợ nó?

Có một câu trả lời rất đơn giản cho vấn đề này: Hồ sơ hiệu suất của máy chủ web của bạn để xem mức phạt hiệu suất đối với tình huống cụ thể của bạn. Có một số công cụ hiện có để so sánh hiệu suất của máy chủ HTTP vs HTTPS (JMeter và Visual Studio) và chúng khá dễ sử dụng.

Không ai có thể cung cấp cho bạn một câu trả lời có ý nghĩa nếu không có một số thông tin về bản chất của trang web, phần cứng, phần mềm và cấu hình mạng của bạn.

Như những người khác đã nói, sẽ có một số mức phí do mã hóa, nhưng nó phụ thuộc rất nhiều vào:

• Phần cứng
• Phần mềm máy chủ
• Tỷ lệ nội dung động so với nội dung tĩnh
• Khoảng cách máy khách đến máy chủ
• Độ dài phiên thông thường
• Vv (yêu thích cá nhân của tôi)
• Hành vi lưu trữ của khách hàng

Theo kinh nghiệm của tôi, các máy chủ nặng về nội dung động có xu hướng bị tác động ít hơn bởi HTTPS vì thời gian mã hóa (chi phí SSL) không đáng kể so với thời gian tạo nội dung.

Các máy chủ nặng về việc phục vụ một tập hợp các trang tĩnh khá nhỏ có thể dễ dàng lưu vào bộ nhớ trong bộ nhớ phải chịu chi phí cao hơn nhiều (trong một trường hợp, thông lượng được đặt trên một "mạng nội bộ").

Chỉnh sửa: Một điểm đã được đưa ra bởi một số người khác là bắt tay SSL là chi phí chính của HTTPS. Điều đó là chính xác, đó là lý do tại sao "độ dài phiên thông thường" và "hành vi lưu trữ của khách hàng" là quan trọng.

Nhiều phiên rất ngắn có nghĩa là thời gian bắt tay sẽ lấn át bất kỳ yếu tố hiệu suất nào khác. Các phiên dài hơn có nghĩa là chi phí bắt tay sẽ phát sinh khi bắt đầu phiên, nhưng các yêu cầu tiếp theo sẽ có chi phí tương đối thấp.

Bộ nhớ đệm của khách hàng có thể được thực hiện ở một số bước, bất cứ nơi nào từ máy chủ proxy quy mô lớn cho đến bộ đệm của trình duyệt riêng lẻ. Nói chung, nội dung HTTPS sẽ không được lưu trong bộ đệm chung (mặc dù một số máy chủ proxy có thể khai thác hành vi loại trung gian để đạt được điều này). Nhiều trình duyệt lưu nội dung HTTPS cho phiên hiện tại và thường xuyên qua các phiên. Tác động của việc không lưu vào bộ nhớ cache hoặc ít bộ nhớ đệm hơn có nghĩa là các máy khách sẽ truy xuất cùng một nội dung thường xuyên hơn. Điều này dẫn đến nhiều yêu cầu và băng thông hơn để phục vụ cùng số lượng người dùng.

HTTPS yêu cầu một cái bắt tay ban đầu có thể rất chậm. Lượng dữ liệu thực tế được chuyển như một phần của cái bắt tay không lớn (thường dưới 5 kB), nhưng đối với các yêu cầu rất nhỏ, điều này có thể là một chút chi phí. Tuy nhiên, một khi bắt tay được thực hiện, một hình thức mã hóa đối xứng rất nhanh được sử dụng, do đó, chi phí hoạt động là tối thiểu. Điểm mấu chốt: thực hiện nhiều yêu cầu ngắn qua HTTPS sẽ chậm hơn một chút so với HTTP, nhưng nếu bạn chuyển nhiều dữ liệu trong một yêu cầu, sự khác biệt sẽ không đáng kể.

Tuy nhiên, keepalive là hành vi mặc định trong HTTP / 1.1, vì vậy bạn sẽ thực hiện một cái bắt tay duy nhất và sau đó rất nhiều yêu cầu trên cùng một kết nối. Điều này tạo ra sự khác biệt đáng kể cho HTTPS. Bạn có thể nên lập hồ sơ trang web của bạn (như những người khác đã đề xuất) để đảm bảo, nhưng tôi nghi ngờ rằng sự khác biệt hiệu suất sẽ không đáng chú ý.

Để thực sự hiểu làm thế nào HTTPS sẽ tăng độ trễ của bạn, bạn phải hiểu cách kết nối HTTPS được thiết lập. Đây là một sơ đồ tốt đẹp . Điều quan trọng là thay vì khách hàng nhận được dữ liệu sau 2 "chặng" (một chuyến khứ hồi, bạn gửi yêu cầu, máy chủ gửi phản hồi), khách hàng sẽ không nhận được dữ liệu cho đến ít nhất 4 chặng (2 chuyến khứ hồi) . Vì vậy, nếu phải mất 100 ms để một gói di chuyển giữa máy khách và máy chủ, yêu cầu HTTPS đầu tiên của bạn sẽ mất ít nhất 500 ms.

Tất nhiên, điều này có thể được giảm thiểu bằng cách sử dụng lại kết nối HTTPS (những trình duyệt nên làm), nhưng nó giải thích một phần của gian hàng ban đầu đó khi tải lên một trang web HTTPS.

Chi phí KHÔNG phải do mã hóa. Trên CPU hiện đại, mã hóa theo yêu cầu của SSL là không đáng kể.

Chi phí hoạt động là do các bắt tay SSL, kéo dài và tăng mạnh số lượng chuyến đi khứ hồi cần thiết cho phiên HTTPS so với phiên HTTP.

Đo (sử dụng một công cụ như Fireorms) thời gian tải trang trong khi máy chủ ở cuối liên kết có độ trễ cao mô phỏng. Các công cụ tồn tại để mô phỏng một liên kết có độ trễ cao - đối với Linux có "netem". So sánh HTTP với HTTPS trên cùng một thiết lập.

Độ trễ có thể được giảm thiểu đến một mức độ nào đó bằng cách:

• Đảm bảo rằng máy chủ của bạn đang sử dụng các thủ tục HTTP - điều này cho phép khách hàng sử dụng lại các phiên SSL, điều này tránh sự cần thiết phải bắt tay khác
• Giảm số lượng yêu cầu xuống càng ít càng tốt - bằng cách kết hợp các tài nguyên ở nơi có thể (ví dụ: .js bao gồm các tệp, CSS) và khuyến khích bộ nhớ đệm phía máy khách
• Giảm số lần tải trang, ví dụ: bằng cách tải dữ liệu không bắt buộc vào trang (có thể trong phần tử HTML bị ẩn) và sau đó hiển thị nó bằng tập lệnh máy khách.

Cập nhật tháng 12 năm 2014

Bạn có thể dễ dàng kiểm tra sự khác biệt giữa hiệu suất HTTP và HTTPS trong trình duyệt của riêng bạn bằng cách sử dụng trang web Thử nghiệm HTTP vs HTTPS của AnthumChris : Hồi Trang này đo thời gian tải của nó qua các kết nối HTTPS HTTP và mã hóa không an toàn. Cả hai trang đều tải 360 hình ảnh độc đáo, không lưu trong bộ nhớ cache (tổng cộng 2,04 MB).

Các kết quả có thể làm bạn ngạc nhiên.

Điều quan trọng là phải có kiến ​​thức cập nhật về hiệu suất HTTPS vì Cơ quan cấp chứng chỉ mã hóa của Let sẽ bắt đầu cấp chứng chỉ SSL miễn phí, tự động và mở vào mùa hè 2015, nhờ Mozilla, Akamai, Cisco, Electronic Frontier Foundation và IdenTrust.

Cập nhật tháng 6 năm 2015

Cập nhật về Let Encrypt - Đến tháng 9 năm 2015:

• Lịch trình ra mắt của Encrypt (ngày 16 tháng 6 năm 2015)
• Hãy mã hóa chứng chỉ gốc và chứng chỉ trung gian (ngày 4 tháng 6 năm 2015)
• Dự thảo Thỏa thuận thuê bao mã hóa (ngày 21 tháng 5 năm 2015)

Thông tin thêm trên Twitter: @letsencrypt

Để biết thêm thông tin về hiệu suất HTTPS và SSL / TLS, xem:

• TLS có nhanh không?
• Mạng trình duyệt hiệu suất cao, Chương 4: Bảo mật lớp vận chuyển
• Ép xung SSL
• Cấu tạo và hiệu suất xử lý SSL

Để biết thêm thông tin về tầm quan trọng của việc sử dụng HTTPS, hãy xem:

• Tại sao HTTPS cho mọi thứ? (Tiêu chuẩn chỉ HTTPS)
• Hãy mã hóa (Nhóm nghiên cứu bảo mật Internet)
• HTTPS ở mọi nơi (Tổ chức biên giới điện tử)

Tóm lại, hãy để tôi trích dẫn Ilya Grigorik : "TLS có chính xác một vấn đề về hiệu suất: nó không được sử dụng đủ rộng rãi. Mọi thứ khác đều có thể được tối ưu hóa."

Cảm ơn Chris - tác giả của bài kiểm tra HTTP vs HTTPS - cho những bình luận của anh ấy bên dưới.

Câu trả lời hàng đầu hiện nay là không hoàn toàn chính xác.

Như những người khác đã chỉ ra ở đây, https yêu cầu bắt tay và do đó thực hiện nhiều vòng tròn TCP / IP hơn.

Trong môi trường WAN thường thì độ trễ trở thành yếu tố giới hạn và không phải là việc sử dụng CPU tăng lên trên máy chủ.

Chỉ cần lưu ý rằng độ trễ từ Châu Âu đến Hoa Kỳ có thể là khoảng 200 ms (thời gian torundtrip).

Bạn có thể dễ dàng đo lường điều này (đối với trường hợp người dùng đơn) với HTTPWatch .

Ngoài mọi thứ được đề cập cho đến nay, xin lưu ý rằng một số trình duyệt web (tất cả?) Không lưu trữ nội dung được lưu trong bộ nhớ cache trên HTTPS trên ổ cứng cục bộ vì lý do bảo mật. Điều này có nghĩa là từ các trang phối cảnh của người dùng có nhiều nội dung tĩnh sẽ xuất hiện tải chậm hơn sau khi trình duyệt được khởi động lại và từ phối cảnh máy chủ của bạn, khối lượng yêu cầu cho nội dung tĩnh trên HTTPS sẽ cao hơn so với HTTP.

Không có một câu trả lời nào cho việc này.

Mã hóa sẽ luôn tiêu thụ nhiều CPU hơn. Điều này có thể được giảm tải cho phần cứng chuyên dụng trong nhiều trường hợp và chi phí sẽ thay đổi theo thuật toán được chọn. 3des đắt hơn AES chẳng hạn. Một số thuật toán đắt hơn cho bộ mã hóa so với bộ giải mã. Một số có chi phí ngược lại.

Đắt hơn tiền điện tử số lượng lớn là chi phí bắt tay. Các kết nối mới sẽ tiêu thụ nhiều CPU hơn. Điều này có thể được giảm bớt khi nối lại phiên, với chi phí giữ bí mật phiên cũ cho đến khi chúng hết hạn. Điều này có nghĩa là các yêu cầu nhỏ từ một khách hàng không quay trở lại nhiều hơn là đắt nhất.

Đối với lưu lượng truy cập internet chéo, bạn có thể không nhận thấy chi phí này trong tốc độ dữ liệu của mình, vì băng thông có sẵn quá thấp. Nhưng bạn chắc chắn sẽ nhận thấy nó trong việc sử dụng CPU trên một máy chủ bận rộn.

Tôi có thể nói với bạn (với tư cách là người dùng quay số) rằng cùng một trang qua SSL chậm hơn nhiều lần so với thông qua HTTP thông thường ...

Trong một số trường hợp, tác động hiệu suất của các bắt tay SSL sẽ được giảm thiểu bởi thực tế là phiên SSL có thể được lưu trong bộ đệm ở cả hai đầu (máy tính để bàn và máy chủ). Trên các máy Windows chẳng hạn, phiên SSL có thể được lưu trong bộ nhớ cache tối đa 10 giờ. Xem http://support.microsoft.com/kb/247658/EN-US . Một số trình tăng tốc SSL cũng sẽ có các tham số cho phép bạn điều chỉnh thời gian phiên được lưu trữ.

Một tác động khác cần xem xét là nội dung tĩnh được cung cấp qua HTTPS sẽ không được lưu trữ bởi các proxy và điều này có thể làm giảm hiệu suất của nhiều người dùng truy cập trang web trên cùng một proxy. Điều này có thể được giảm thiểu bởi thực tế là nội dung tĩnh cũng sẽ được lưu trong bộ nhớ cache trên máy tính để bàn, Internet Explorer phiên bản 6 và 7 nội dung tĩnh HTTPS được lưu trong bộ nhớ cache trừ khi được hướng dẫn làm khác (Menu Menu / Tùy chọn Internet / Nâng cao / Bảo mật / Không lưu các trang được mã hóa vào đĩa).

Tôi đã thực hiện một thử nghiệm nhỏ và nhận chênh lệch thời gian 16% cho cùng một hình ảnh từ flickr (233 kb):

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

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

Tất nhiên những con số này phụ thuộc vào nhiều yếu tố, chẳng hạn như hiệu suất máy tính, tốc độ kết nối, tải máy chủ, QoS trên đường dẫn (đường dẫn mạng cụ thể được lấy từ trình duyệt đến máy chủ) nhưng nó cho thấy ý tưởng chung: HTTPS chậm hơn HTTP, vì nó yêu cầu nhiều hoạt động hơn để hoàn thành (bắt tay SSL và mã hóa / giải mã dữ liệu).

Đây là một bài viết tuyệt vời (một chút cũ, nhưng vẫn tuyệt vời) về độ trễ bắt tay SSL. Đã giúp tôi xác định SSL là nguyên nhân chính gây ra sự chậm chạp cho các khách hàng đang sử dụng ứng dụng của tôi thông qua các kết nối Internet chậm:

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

Vì tôi đang điều tra vấn đề tương tự cho dự án của mình, tôi đã tìm thấy những slide này. Cũ hơn nhưng thú vị:

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

Dường như có một trường hợp khó chịu ở đây: Ajax qua tắc nghẽn wifi.

Ajax thường có nghĩa là KeepAlive đã hết thời gian sau 20 giây. Tuy nhiên, wifi có nghĩa là kết nối ajax (lý tưởng nhanh) phải thực hiện nhiều chuyến đi khứ hồi. Tồi tệ hơn, wifi thường mất các gói và có truyền lại TCP. Trong trường hợp này, HTTPS thực hiện thực sự tồi tệ!

TLS đã nhanh chưa? Đúng.

• Xem: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Đọc: https://istlsfastyet.com/

Có nhiều dự án ngoài kia nhằm mục đích làm mờ các dòng và làm cho HTTPS cũng nhanh như vậy. Giống như SPDY và mod-spdy .

CÔNG CỤ THỰC HIỆN HTTP VS HTTPS

Tôi luôn liên kết HTTPS với thời gian tải trang chậm hơn khi so sánh với HTTP cũ đơn giản. Là một nhà phát triển web, hiệu suất trang web rất quan trọng đối với tôi và bất cứ điều gì sẽ làm chậm hiệu suất của các trang web của tôi là không có.

Để hiểu được ý nghĩa hiệu suất liên quan, sơ đồ bên dưới cung cấp cho bạn ý tưởng cơ bản về những gì xảy ra dưới mui xe khi bạn yêu cầu tài nguyên bằng HTTPS.

Như bạn có thể thấy từ sơ đồ trên, có một vài bước bổ sung cần phải diễn ra khi sử dụng HTTPS so với sử dụng HTTP đơn giản. Khi bạn thực hiện một yêu cầu bằng HTTPS, một cái bắt tay cần phải xảy ra để xác minh tính xác thực của yêu cầu. Cái bắt tay này là một bước bổ sung khi so sánh với một yêu cầu HTTP và không may phải chịu một số chi phí.

Để hiểu được ý nghĩa của hiệu suất và tự mình xem liệu tác động hiệu suất có đáng kể hay không, tôi đã sử dụng trang web này làm nền tảng thử nghiệm. Tôi đã đi đến webpagetest.org và sử dụng công cụ so sánh trực quan để so sánh tải trang web này bằng HTTPS vs HTTP.

Như bạn có thể thấy từ đây là Kết quả video thử nghiệm sử dụng HTTPS đã ảnh hưởng đến thời gian tải trang của tôi, tuy nhiên sự khác biệt là không đáng kể và tôi chỉ nhận thấy sự khác biệt 300 mili giây. Điều quan trọng cần lưu ý là thời gian này phụ thuộc vào nhiều yếu tố, chẳng hạn như hiệu suất máy tính, tốc độ kết nối, tải máy chủ và khoảng cách từ máy chủ.

Trang web của bạn có thể khác và điều quan trọng là phải kiểm tra kỹ trang web của bạn và kiểm tra tác động hiệu suất liên quan đến việc chuyển sang HTTPS.

Có một cách để đo lường điều này. Công cụ từ apache được gọi là jmeter sẽ đo thông lượng. Nếu bạn thiết lập một mẫu lớn dịch vụ của mình bằng jmeter, trong môi trường được kiểm soát, có và không có SSL, bạn sẽ có được một so sánh chính xác về chi phí tương đối. Tôi sẽ quan tâm đến kết quả của bạn.

HTTPS có chi phí mã hóa / giải mã nên sẽ luôn chậm hơn một chút. Chấm dứt SSL rất tốn CPU. Nếu bạn có các thiết bị để giảm tải SSL, sự khác biệt về độ trễ có thể hầu như không đáng chú ý tùy thuộc vào tải của máy chủ của bạn.

Một sự khác biệt quan trọng hơn về hiệu suất là phiên HTTPS được mở ketp trong khi người dùng được kết nối. Một 'phiên' HTTP chỉ tồn tại cho một yêu cầu mục duy nhất.

Đó là bạn đang chạy một trang web với số lượng lớn người dùng đồng thời, dự kiến ​​sẽ mua rất nhiều bộ nhớ.

Điều này gần như chắc chắn sẽ đúng khi SSL yêu cầu thêm một bước mã hóa mà đơn giản là không yêu cầu HTTP không phải SLL.

HTTPS thực sự ảnh hưởng đến tốc độ trang ...

Các trích dẫn ở trên cho thấy sự ngu ngốc của nhiều người về bảo mật và tốc độ trang web. Bắt tay máy chủ HTTPS / SSL tạo ra một gian hàng ban đầu trong việc tạo kết nối Internet. Có độ trễ chậm trước khi mọi thứ bắt đầu hiển thị trên màn hình trình duyệt của khách truy cập của bạn. Độ trễ này được đo bằng thông tin Time-to-First-Byte.

Chi phí bắt tay HTTPS xuất hiện trong thông tin Thời gian đến đầu tiên (TTFB). TTFB phổ biến dao động từ dưới 100 mili giây (trường hợp tốt nhất) đến hơn 1,5 giây (trường hợp xấu nhất). Nhưng, tất nhiên, với HTTPS, nó tệ hơn 500 mili giây.

Kết nối khứ hồi, kết nối 3G không dây có thể từ 500 mili giây trở lên. Các chuyến đi thêm chậm trễ gấp đôi đến 1 giây trở lên. Đây là một tác động lớn, tiêu cực đến hiệu suất di động. Tin rất xấu.

Lời khuyên của tôi, nếu bạn không trao đổi dữ liệu nhạy cảm thì bạn hoàn toàn không cần SSL, nhưng nếu bạn thích một trang web thương mại điện tử thì bạn chỉ có thể kích hoạt HTTPS trên một số trang nhất định nơi dữ liệu nhạy cảm được trao đổi như Đăng nhập và thanh toán.

Nguồn: Trang

Các trình duyệt có thể chấp nhận giao thức HTTP / 1.1 với HTTP hoặc HTTPS, tuy nhiên các trình duyệt chỉ có thể xử lý giao thức HTTP / 2.0 với HTTPS. Sự khác biệt về giao thức từ HTTP / 1.1 đến HTTP / 2.0 tạo ra HTTP / 2.0, trung bình, nhanh hơn 4-5 lần so với HTTP / 1.1. Ngoài ra, trong số các trang web triển khai HTTPS, hầu hết đều làm như vậy qua giao thức HTTP / 2.0. Do đó, HTTPS hầu như luôn luôn nhanh hơn HTTP đơn giản do giao thức khác nhau mà nó thường sử dụng. Tuy nhiên, nếu HTTP qua HTTP / 1.1 được so sánh với HTTPS so với HTTP / 1.1, thì trung bình HTTP nhanh hơn một chút so với HTTPS.

Dưới đây là một số so sánh tôi đã chạy bằng Chrome (Phiên bản 64):

HTTPS qua HTTP / 1.1:

• Thời gian tải trang trung bình 0,47 giây
• Chậm hơn 0,05 giây so với HTTP so với HTTP / 1.1
• Chậm hơn 0,37 giây so với HTTPS so với HTTP / 2.0

HTTP qua HTTP / 1.1

• Thời gian tải trang trung bình 0,42 giây
• Nhanh hơn 0,05 giây so với HTTPS so với HTTP / 1.1
• Chậm hơn 0,32 giây so với HTTPS so với HTTP / 2.0

HTTPS qua HTTP / 2.0

• Thời gian tải trung bình 0,10 giây
• Nhanh hơn 0,32 giây so với HTTP qua HTTP / 1.1
• Nhanh hơn 0,37 giây so với HTTPS so với HTTPS / 1.1