SSL áp đặt bao nhiêu chi phí?

Tôi biết không có câu trả lời khó và nhanh duy nhất, nhưng liệu có một xấp xỉ ước tính thứ tự chung về độ lớn cho chi phí mã hóa của SSL so với giao tiếp ổ cắm không được mã hóa? Tôi chỉ nói về xử lý hoa hồng và thời gian dây, không tính xử lý cấp ứng dụng.

Cập nhật

Có một câu hỏi về HTTPS so với HTTP , nhưng tôi quan tâm đến việc tìm kiếm thấp hơn trong ngăn xếp.

(Tôi đã thay thế cụm từ "theo độ" để tránh nhầm lẫn, tôi đã sử dụng nó như là thuật ngữ chính thức chứ không phải theo nghĩa CompSci chính thức Tất nhiên nếu tôi. Đã có nghĩa là nó chính thức, như là một geek đúng tôi sẽ có được suy nghĩ nhị phân chứ không phải số thập phân! ;-)

Cập nhật

Mỗi yêu cầu trong nhận xét, giả sử chúng ta đang nói về các tin nhắn có kích thước tốt (trong khoảng 1k-10k) qua các kết nối liên tục. Vì vậy, thiết lập kết nối và chi phí gói không phải là vấn đề quan trọng.

Thứ tự cường độ: không.

Nói cách khác, bạn sẽ không thấy thông lượng của mình bị cắt làm đôi, hoặc bất cứ điều gì tương tự, khi bạn thêm TLS. Các câu trả lời cho câu hỏi "trùng lặp" tập trung rất nhiều vào hiệu suất của ứng dụng và cách so sánh với chi phí SSL. Câu hỏi này đặc biệt loại trừ xử lý ứng dụng và tìm cách so sánh không chỉ SSL với SSL. Mặc dù có ý nghĩa để có một cái nhìn toàn cầu về hiệu suất khi tối ưu hóa, đó không phải là câu hỏi này.

Chi phí chính của SSL là bắt tay. Đó là nơi xảy ra mật mã bất đối xứng đắt tiền. Sau khi đàm phán, mật mã đối xứng tương đối hiệu quả được sử dụng. Đó là lý do tại sao có thể rất hữu ích để kích hoạt các phiên SSL cho dịch vụ HTTPS của bạn, nơi có nhiều kết nối được thực hiện. Đối với một kết nối lâu dài, "hiệu ứng cuối" này không đáng kể và các phiên không hữu ích.

Đây là một giai thoại thú vị. Khi Google chuyển Gmail sang sử dụng HTTPS, không yêu cầu thêm tài nguyên nào; không có phần cứng mạng, không có máy chủ mới. Nó chỉ tăng tải CPU khoảng 1%.

Tôi thứ hai @erickson: Hình phạt tốc độ truyền dữ liệu thuần túy là không đáng kể. Các CPU hiện đại đạt được thông lượng tiền điện tử / AES vài trăm MBit / s. Vì vậy, trừ khi bạn ở trên hệ thống bị hạn chế tài nguyên (điện thoại di động), TLS / SSL đủ nhanh để xử lý dữ liệu xung quanh.

Nhưng hãy nhớ rằng mã hóa làm cho bộ nhớ đệm và cân bằng tải khó hơn nhiều. Điều này có thể dẫn đến một hình phạt hiệu suất rất lớn.

Nhưng thiết lập kết nối thực sự là một điểm dừng hiển thị cho nhiều ứng dụng. Trên băng thông thấp, mất gói cao, kết nối có độ trễ cao (thiết bị di động ở nông thôn), các vòng tròn bổ sung mà TLS yêu cầu có thể khiến một thứ gì đó chậm thành một thứ không thể sử dụng được.

Ví dụ: chúng tôi đã phải bỏ yêu cầu mã hóa để truy cập vào một số ứng dụng web nội bộ của chúng tôi - chúng ở nơi không thể sử dụng được nếu được sử dụng từ Trung Quốc.

Giả sử bạn không tính thiết lập kết nối (như bạn đã chỉ ra trong bản cập nhật của mình), điều đó phụ thuộc rất nhiều vào mật mã được chọn. Chi phí mạng (về băng thông) sẽ không đáng kể. Chi phí hoạt động của CPU sẽ bị chi phối bởi mật mã. Trên Core i5 di động của tôi, tôi có thể mã hóa khoảng 250 MB mỗi giây với RC4 trên một lõi. (RC4 là thứ bạn nên chọn để có hiệu suất tối đa.) AES chậm hơn, cung cấp "chỉ" khoảng 50 MB / s. Vì vậy, nếu bạn chọn mật mã chính xác, bạn sẽ không quản lý để giữ một lõi hiện tại bận rộn với chi phí tiền điện tử ngay cả khi bạn có dòng 1 Gbit được sử dụng đầy đủ. [ Chỉnh sửa : RC4 không nên được sử dụng vì nó không còn an toàn. Tuy nhiên, hỗ trợ phần cứng AES hiện có mặt trong nhiều CPU, giúp mã hóa AES thực sự nhanh trên các nền tảng như vậy.]

Thiết lập kết nối, tuy nhiên, là khác nhau. Tùy thuộc vào việc triển khai (ví dụ: hỗ trợ cho khởi động sai TLS), nó sẽ thêm các chuyến đi khứ hồi, điều này có thể gây ra sự chậm trễ đáng chú ý. Ngoài ra, tiền điện tử đắt tiền diễn ra ở cơ sở kết nối đầu tiên (CPU được đề cập ở trên chỉ có thể chấp nhận 14 kết nối mỗi lõi mỗi giây nếu bạn dại dột sử dụng khóa 4096 bit và 100 nếu bạn sử dụng khóa 2048 bit). Trên các kết nối tiếp theo, các phiên trước thường được sử dụng lại, tránh tiền điện tử đắt tiền.

Vì vậy, để tóm tắt:

Chuyển trên kết nối được thiết lập:

• Trì hoãn: gần như không có
• CPU: không đáng kể
• Băng thông: không đáng kể

Thiết lập kết nối đầu tiên:

• Trì hoãn: các chuyến đi khứ hồi bổ sung
• Băng thông: vài kilobyte (chứng chỉ)
• CPU trên máy khách: trung bình
• CPU trên máy chủ: cao

Các cơ sở kết nối sau đó:

• Trì hoãn: chuyến đi khứ hồi bổ sung (không chắc chắn nếu một hoặc nhiều người, có thể phụ thuộc vào việc triển khai)
• Băng thông: không đáng kể
• CPU: gần như không có