Chuẩn HTTP/2 này đang gần hoàn thành, nếu không có gì thay đổi thì khoảng tháng 8 năm 2015 sẽ hoàn tất, và việc tiếp theo là triển khai và viết tài liệu hướng dẫn.
Kể từ khi phát hành HTTP/1.1 tới nay đã hơn 15 năm, nhưng chưa có một cải tiến nào đáng kể trong thế giới internet thay đổi không ngừng. Nay, IETF HTTP Working Group đề xuất phiên bản tiếp theo của HTTP với nhiều cải tiến lớn. Rất nhiều cải tiến được lấy cảm hứng từ SPDY của Google. Tôi sẽ điểm qua một số điểm nhấn chính đáng mong đợi.
1. HTTP API như cũ
Đây là điểm lợi đầu tiên: Developer sẽ không cần sửa đổi nhiều ứng dụng/server của họ để tương thích.
HTTP/2 không đưa ra các sự thay đổi API hay việc phải thêm một vài API để nó làm việc tốt. Việc này giúp việc triển khai HTTP/2 dễ dàng và nhanh chóng hơn.
Tất nhiên, nó sẽ có một vài API mới hoàn toàn, và dùng cho một vài mục đích chuyên biệt của HTTP/2 mà không ảnh hưởng đến API hiện có của HTTP/1.1
2. Ít tốn chi phí request hơn
Có một triết lý để tăng performance, đó là giảm số lượng request, và chúng ta đã biết rất nhiều kỹ thuật như concatenation (gộp nhiều file thành một), spriting (ghép nhiều icon nhỏ thành một hình), hay inlining (đưa JS nhỏ vào file HTML). Tất cả đều là kỹ thuật "hack", để giảm số lượng request khi truy cập một trang web.
Tại sao phải giảm số lượng request? Vì một request sẽ tốn chi phí DNS Lookup, rồi bắt tay, rồi truyền nhận header, mở connection và mở port, sau đó mới đến nội dung thật sự. Khi giảm số lượng request thì nội dung sẽ được gộp lại, nhưng các chi phí còn lại sẽ chỉ tốn 1 lần. Thêm một vấn đề nữa là các request sẽ đợi lẫn nhau, khi hoàn thành request thứ nhất thì mới bắt đầu request thứ 2, và nếu request thứ nhất quá lâu thì cũng sẽ ảnh hưởng đến request thứ 2. Chúng ta cũng có hướng đến cải thiện là thay đổi trình tự request, ưu tiên những cái quan trọng và nhỏ gọn hơn. Đó là cách làm hiện nay, tuy nhiên, phải sửa lại code khá nhiều.
HTTP/2 giới thiệu một cách tiếp cận tốt hơn. Đó là cho phép nhiều request khác nhau (đến từ một domain), có thể request đan xen nhau, và như thế có thể truyền nhận dữ liệu đồng thời.
Thậm chí, HTTP/2 còn có thể đưa thêm một số tuỳ chọn để nén header, giúp lượng dữ liệu truyền còn nhỏ gọn hơn.
3. Thân thiện với network và server
HTTP/2 được thiết kế để có thể mở ít connection hơn. Nói dễ hiểu, nếu trước đây một lượt truy cập vào một trang cần mở 12 connection thì nay chỉ còn lại 3 connection, như vậy server có thể phục vụ lượng truy cập gấp 4 lần mà không cần làm gì cả.
Thêm nữa, với việc hỗ trợ nén từ header đến content, băng thông sẽ giảm đáng kể. Việc này có lợi cho cả server lẫn người dùng, vốn có xu hướng sử dụng di động nhiều hơn.
4. Cache pushing
Trong tất cả các điểm mới, đây là điểm tôi bất ngờ và thú vị nhất.
Cache là gì? Cache là một bản sao của một file trên server, khi lần đầu truy cập nó sẽ được lưu vào máy người dùng, và ở lần truy cập tiếp theo, nó sẽ được sử dụng mà không cần request lên server để lấy lại.
Vậy còn Cache pushing? Nói một cách dễ hiểu: Các bản sao này được gửi về client (máy người dùng) trước cả khi client request.
Kỹ thuật này cho phép server bắt đầu chuẩn bị gửi các file CSS, JS, hình ảnh,... ngay khi client request file HTML đầu tiên, và gửi về client trong khi client đang parse HTML và xác định những file cần request tiếp theo.
Tất nhiên, nếu client không muốn push nội dung về thì có thể nói "không" bằng RST_STREAM (tôi sẽ đề cập ở đoạn tiếp theo).
5. Có thể dừng request lại
Với HTTP/1.x nếu muốn dừng request, client có thể đóng connection. Như thế sẽ không nhận response từ server nữa.
Nhưng, đóng connection không có nghĩa là server và network sẽ đóng, mà vẫn giữ đến khi gửi response về tới client thì thấy đã đóng rồi. Như vậy sẽ khiến lãng phí không nhỏ cho network và server. Thêm nữa, việc mở connection cần thực hiện bắt tay (handshake) mà việc này lại tốn tài nguyên để xử lý ở client và server.
Thực tế việc dừng request rất thường xuyên xảy ra. Khi bạn đang load trang web này và muốn reload, hay chuyển sang trang web khác, hay đơn giản là đóng tab lại,... Và mỗi lần như vậy lại tốn một lượng tài nguyên nhất định, sẽ khiến cho tổng cộng bị tốn khá nhiều tài nguyên.
HTTP/2 hỗ trợ RST_STREAM frame như là một cách để người dùng có thể làm điều này mà không tốn nhiều tài nguyên.
6. Mã hoá nhiều hơn
HTTP/2 không bắt buộc phải sử dụng TLS (một dạng chuẩn của SSL), nhưng performance đã được cải thiện rất nhiều khi sử dụng TLS, vì vậy chúng ta không còn lo ngại việc mã hoá TLS gây chậm trang web nữa.
Tuy là vậy, nhưng cả Chrome và Firefox đều tuyên bố chỉ hỗ trợ HTTP/2 chung với TLS (có nghĩa là nếu server muốn sử dụng HTTP/2 cho người dùng 2 trình duyệt này, thì họ phải hỗ trợ TLS). Phương án này không tốt tẹo nào nếu nhìn từ góc độ nhà cung cấp website, tuy nhiên lại bảo vệ tối đa cho người sử dụng. Và như vậy webmaster phải lựa chọn giữa HTTP/1.x chậm mà không cần TLS, với một HTTP/2 nhanh-tốt hơn mà phải chi tiền để mua chứng thực TLS.
Dù sao thì với việc triển khai HTTP/2, mọi người dùng trên thế giới sẽ tin tưởng rằng họ đang kết nối internet an toàn hơn rất nhiều.
Câu hỏi nhỏ là: Tại sao phải "force" như vậy? Đơn giản là vì mỗi lần triển khai HTTP phiên bản mới sẽ mất rất nhiều thời gian và công sức, cho nên nếu đã làm rồi thì làm cho "triệt để" luôn.
7. Nói không với text
HTTP/1 được thiết kế ra đầu tiên cho việc truyền tải dữ liệu HTML, và như vậy nó hỗ trợ text làm nền tảng. Sau đó thế giới cần gửi binary (ví dụ như hình ảnh, phim, zip file,...), và người ta phải xử lý binary. Tóm lại là HTTP/1.x đang sử dụng 2 phương cách để truyền tải là binary protocol và text protocol.
Với HTTP/2, tất cả đều phải là binary. Tại sao?
Ngoài những lý do như binary thì gần với mã máy, thân thiện với network,... thì có một lý do lớn là dễ xử lý hơn.
Với dạng text, nếu bạn muốn gửi ký hiệu "xuống hàng", bạn phải gửi "\n" hoặc "\r\n" tuỳ hệ điều hành. Còn nếu bạn muốn gửi ký hiệu "\n" (không phải xuống hàng mà là text), thì phải gửi "\\n". Câu chuyện này khá là phức tạp, với rất nhiều trường hợp khác nhau mà bạn phải xử lý. Tất nhiên, có rất nhiều thư viện xử lý giúp, nhưng nếu bạn làm một trình duyệt mới, hay một ngôn ngữ lập trình mới, thì phải xử lý từ đầu. Khá bất tiện...
Rồi còn chuyện kết thúc nữa, hiện không dưới 3 cách để báo cho server biết là đã kết thúc dữ liệu gửi đi. Như vậy độ phức tạp xử lý lại nhiều thêm nữa. Và còn dễ bị tấn công theo kiểu chèn thêm vào message gửi qua lại (response splitting attack).
Với dạng binary, tất cả đều quy về một chuẩn chung, giúp cho việc mã hoá, giải mã và gửi đi được thống nhất. Không cần phải lo lắng về các ký tự không có trên bàn phím hoặc kết thúc message nữa.
Thêm một lý do nữa để HTTP/2 phải sử dụng binary, đó là vì, như đã nói ở phần trên, HTTP/2 có thể xử lý song song nhiều request trên cùng một connection, nên việc sử dụng text sẽ không thể tách và ghép các message được.
8. Phải một thời gian sau mới đúng
HTTP/2 không phải là thứ muốn có là có liền được, mọi thứ không đơn giản như là chỉ cần gắn nó vào là xong.
Hướng tiếp cận của HTTP/2 là loại bỏ những thứ không cần thiết để tối ưu hiệu suất, việc này đồng nghĩa với việc cả server và client (các trình duyệt) đều phải thay đổi để hỗ trợ. Việc này cần thời gian, và mỗi trình duyệt lại có lộ trình riêng để hỗ trợ.
Điều khiến nhiều người bi quan nhất là rất nhiều trình duyệt và server có "hard code" theo chuẩn HTTP/1.x, và không hề có dự định sẽ hỗ trợ các chuẩn HTTP mới ở tương lai. Việc chuyển dịch sang chuẩn mới sẽ tốn một chi phí khổng lồ. Tuy là như thế, nhưng với xu hướng phát triển toàn cầu, tất cả các trình duyệt và server đều sẽ hỗ trợ để phục vụ người dùng tốt hơn.
Thậm chí, các nhà viết chuẩn của IETF còn "mơ mộng" hơn thế, khi bắt đầu đầu tư thời gian và công sức vào một chuẩn mới thay thế TCP hiện tại. Với kỳ vọng performance sẽ tốt hơn nữa. Tuy nhiên, còn quá sớm để đề cập tới TCP, vì hiện tại vẫn chưa ai nghĩ rằng để cải thiện chỉ cần một thay đổi nhỏ (tweak) giống như SPDY đã làm, hay đưa ra cải tiến về nền tảng cho một chuẩn mới như HTTP/2.
9. HTTP/3 và xa hơn nữa
HTTP/1.1 đã tồn tại hơn 15 năm, HTTP/2 thì sắp hoàn thành đặc tả, vậy tại sao chúng ta không bắt đầu suy nghĩ đến HTTP/3?
Lý do lớn nhất nằm ở chỗ việc triển khai HTTP/2 đã gặp rất nhiều khó khăn rồi. Rất nhiều phần mềm, ứng dụng chưa hỗ trợ chuyển đổi, thậm chí chúng còn nghĩ rằng HTTP/1 không bao giờ thay đổi.
Do đó, nếu việc chuyển đổi lên HTTP/2 mà không gặp vấn đề gì lớn, thì khi đó việc nâng lên version tiếp theo như HTTP/3 sẽ không gặp vấn đề gì. Còn nếu chỉ mới lên HTTP/2 mà đã nhiều vấn đề, thì còn quá sớm để nói về HTTP/3, vì chuyện đáng quan tâm nhất là nâng cấp lên HTTP/2 mà.
Và tất nhiên, không ai biết HTTP/3 sẽ có cái gì. HTTP/2 được lấy cảm hứng rất nhiều từ phương thức SPDY của Google, và SPDY lại dựa trên trải nghiệm thật trên HTTP/1 rồi cải tiến nó. Nếu thế thì sau khi HTTP/2 được triển khai rộng khắp sẽ có nhiều hướng để cải thiện nó lên, để rồi sẽ thống nhất về một mối lần nữa.
Trong khi chờ tới ngày đó, thì chúng ta sẽ tiếp tục hướng tới HTTP/2 và tận dụng triệt để sức mạnh của nó.
Lý do lớn nhất nằm ở chỗ việc triển khai HTTP/2 đã gặp rất nhiều khó khăn rồi. Rất nhiều phần mềm, ứng dụng chưa hỗ trợ chuyển đổi, thậm chí chúng còn nghĩ rằng HTTP/1 không bao giờ thay đổi.
Do đó, nếu việc chuyển đổi lên HTTP/2 mà không gặp vấn đề gì lớn, thì khi đó việc nâng lên version tiếp theo như HTTP/3 sẽ không gặp vấn đề gì. Còn nếu chỉ mới lên HTTP/2 mà đã nhiều vấn đề, thì còn quá sớm để nói về HTTP/3, vì chuyện đáng quan tâm nhất là nâng cấp lên HTTP/2 mà.
Và tất nhiên, không ai biết HTTP/3 sẽ có cái gì. HTTP/2 được lấy cảm hứng rất nhiều từ phương thức SPDY của Google, và SPDY lại dựa trên trải nghiệm thật trên HTTP/1 rồi cải tiến nó. Nếu thế thì sau khi HTTP/2 được triển khai rộng khắp sẽ có nhiều hướng để cải thiện nó lên, để rồi sẽ thống nhất về một mối lần nữa.
Trong khi chờ tới ngày đó, thì chúng ta sẽ tiếp tục hướng tới HTTP/2 và tận dụng triệt để sức mạnh của nó.
--------
Bài viết dựa trên https://www.mnot.net/blog/2014/01/30/http2_expectations.
No comments:
Post a Comment