Làm cách nào để tối ưu hóa thời gian tải của kết nối ban đầu và giai đoạn bắt tay SSL của trang web trên mạng 3G?

Trang web của tôi www.example.com (bật SSL) được lưu trữ trên dịch vụ lưu trữ chia sẻ Amazon EC2. Nó tải nhanh hơn (thời gian tải <2 giây) trên kết nối wifi / băng thông rộng. Vấn đề là trên mạng 3G trong thiết bị di động ** (Chế độ H chứ không phải chế độ H +) **. Bắt đầu giai đoạn kết nối và quá trình bắt tay SSL mất rất nhiều thời gian - 12 giây. Đã theo dõi các thông số thời gian thông qua tab Mạng Chrome. Dưới đây là thời gian tải đo được cho trang web.

Loại dữ liệu được xử lý trên trang: Trang web được kiểm tra nhận 5 dữ liệu JSON được ghép nối với giá trị khóa thông qua AJAX và hiển thị trên trang web. Đây là một trang rất nhẹ chỉ có 5-6 nội dung văn bản.

Tôi đã thấy nhiều trang web tải nhanh hơn trên mạng di động 3G (chế độ H). Trang web của tôi quá chậm trong giai đoạn thiết lập kết nối ban đầu trên mạng 3G. Ai đó có thể vui lòng giúp tôi về cách giải quyết / tối ưu hóa độ trễ trong giai đoạn kết nối ban đầu không? Sẽ chuyển sang lưu trữ dành riêng giải quyết vấn đề hiện tại?

Máy chủ Web không bận rộn và luôn có sẵn rất nhiều CPU VÀ bộ nhớ.

Cấu hình máy chủ: Amazon EC2 Instance - Lưu trữ chia sẻ (32 CPU và 60 GB RAM). Máy chủ web - Apache. SSL - Symantec.

Kết nối ban đầu

Bạn sẽ thấy rằng kết nối ban đầu bao gồm việc đàm phán SSL, do đó, độ bắt tay cao, một dấu hiệu tốt cho thấy có gì đó không đúng với cách bạn thiết lập SSL.

Google Chrome: Hiểu thời gian tài nguyên

Phải mất thời gian để thiết lập kết nối, bao gồm bắt tay / thử lại TCP và đàm phán SSL.

Bắt tay SSL và TTFB

Bạn có hai vấn đề lớn, Thời gian dành cho việc hoàn thành bắt tay SSL và các máy chủ đang chờ TTFB (thời gian đến byte đầu tiên).

• TTFB: 4079ms (nên nhỏ hơn 1000ms)
• Bắt tay SSL 11830ms (nên dưới 100ms)

Cũng cần lưu ý rằng khi thử nghiệm với thiết bị 3G / 4G, nó có thể gây ra các byte đầu tiên dài hơn do thực tế là tín hiệu điện thoại có cường độ khác nhau ... điều này có thể gây ra sự cố kết nối không liên tục và thời gian trễ khác nhau.

Bước 1: Điều tra sự cố SSL

Rõ ràng là bạn có vấn đề SSL nghiêm trọng và rất có thể là do cài đặt OpenSSL bị lỗi hoặc tương tự. Bắt đầu bằng cách kiểm tra chứng chỉ SSL của bạn bằng SSL Labs và sau đó sửa bất kỳ vấn đề hoặc cảnh báo nào mà nó gợi ý.

Nếu SSL vẫn hoạt động chậm thì rất có thể bạn đã bị máy chủ quá tải hoặc lỗi máy chủ. Nếu đó là sau này, bạn sẽ cần phải cố gắng và thu hẹp lỗi nằm ở đâu. Sử dụng ngăn xếp Lỗi máy chủ nếu bạn cần hỗ trợ thêm về vấn đề này, một người dùng đã báo cáo rằng việc tạo khóa mới đã giải quyết vấn đề SSL chậm mà anh ấy / cô ấy gặp phải có thể hoặc có thể không liên quan.

Cân bằng tải có thể giúp đỡ nếu đó là vấn đề tài nguyên máy chủ.

Bước 2: Điều tra TTFB

Khi bạn đã điều tra giải quyết vấn đề của SSL và bạn vẫn có TTFB tăng thì bạn nên kiểm tra máy chủ của mình bằng cách đảm bảo rằng nó có đủ tài nguyên.

Thời gian byte đầu tiên bị ảnh hưởng bởi nhưng không giới hạn ở:

• Khoảng cách từ người dùng đến trung tâm dữ liệu lưu trữ máy chủ có thể tăng TTFB
• GZIP không được quản lý có thể tăng TTFB
• Mạng tắc nghẽn có thể tăng TTFB
• Máy chủ bị tắc nghẽn có thể tăng TTFB

Đôi khi, việc tăng CPU và RAM không phải lúc nào cũng là lựa chọn tốt nhất. Đôi khi tốt hơn để giới thiệu một bộ cân bằng tải bởi vì điều đó không chỉ có nghĩa là bạn có thể dễ dàng chạy nhiều máy chủ cạnh nhau mà nó còn thực sự giảm tải các yêu cầu bộ nhớ cache và SSL. Một số lợi ích khác bao gồm:

NGUỒN

• Bộ nhớ đệm: Công cụ có thể lưu trữ nội dung không thay đổi (như hình ảnh) và phục vụ chúng trực tiếp đến máy khách mà không gửi lưu lượng truy cập đến máy chủ web.
• Nén: Giảm lượng lưu lượng truy cập cho các đối tượng HTTP bằng cách nén các tệp trước khi chúng được gửi.
• Giảm tải SSL: Xử lý lưu lượng SSL là yêu cầu trên CPU của máy chủ web, do đó, bộ cân bằng tải có thể thực hiện việc xử lý này thay thế.
• Tính sẵn sàng cao: Hai thiết bị cân bằng tải có thể được sử dụng trong trường hợp một thiết bị không thành công.

Mẹo để hạ TTFB của bạn:

• Đảm bảo cơ sở dữ liệu của bạn nằm trên cùng một mạng hoặc đám mây SQL chất lượng .
• Đảm bảo cơ sở dữ liệu của bạn được đọc từ bộ nhớ và NEVER EVER các SWAP tập tin!
• Sử dụng một mạng phân phối nội dung , nó sẽ giảm tải các yêu cầu máy chủ và các tác vụ nén.
• Sử dụng Cache Varnish để giảm tải cho cơ sở dữ liệu bằng cách lưu các trang bộ đệm
• Điểm chuẩn các tệp tĩnh của bạn trên đĩa cứng bằng HDParm
• Điểm chuẩn máy chủ của bạn bằng công cụ đo điểm chuẩn máy chủ HTTP HTTP
• Điểm chuẩn trang web với 10 lượt đi với nhiều vị trí từ xa bằng WebPageTest

Đọc tiêu đề câu hỏi của bạn , có hai điều bạn có thể làm để tăng tốc kết nối ban đầu và bắt tay SSL / TLS. Chúng hoạt động cho mọi kết nối, không chỉ 3G, vì vậy dù sao bạn cũng nên sử dụng chúng như là cách thực hành tốt nhất.

Đầu tiên, sử dụng HTTP / 2 để phục vụ trang web. Điều này đòi hỏi Apache 2.4.17 trở lên .

Thứ hai, cấu hình Apache để sử dụng ghim OCSP. Điều này đòi hỏi Apache 2.3.3 trở lên cộng với OpenSSL 0.9.8h trở lên, với một hướng dẫn tốt để thiết lập nó ở đây . Việc dập ghim OCSP sẽ không tăng tốc mọi thứ lên nhưng nó sẽ thực hiện một số công việc cho khách hàng và giải quyết cho họ những rắc rối khi thử tra cứu OCSP.

Đọc văn bản cơ thể của câu hỏi của bạn , tôi nghĩ rằng bạn có một vấn đề lớn hơn nhiều với môi trường lưu trữ của bạn. Những thời gian tải là không thể chấp nhận. Bạn đề cập rằng đó là 'lưu trữ chia sẻ', bạn nên liên hệ với bất kỳ ai đang quản lý lưu trữ được chia sẻ đó và hỏi tại sao máy chủ của họ lại chậm một cách bất thường. Có lẽ bạn nên thử một máy chủ chia sẻ khác hoặc tự chạy VPS (đây là công việc nhiều hơn nhưng cho tốc độ và tính linh hoạt tốt hơn).

Vì bạn đã sử dụng AWS, tại sao không thử dùng cấp miễn phí của họ để kiểm tra mọi thứ và giúp máy chủ của bạn hoạt động và tối ưu hóa? Sử dụng nó với một tên miền phụ và một số trang HTML tĩnh để kiểm tra và sau đó di chuyển trang web chính của bạn qua (tăng tỷ lệ vượt quá giới hạn cấp miễn phí nếu cần).