Lỗi 425 Too Early: early data, 0-RTT và rủi ro gửi lặp
Lỗi 425 Too Early là mã HTTP máy chủ trả khi không muốn xử lý một request đến quá sớm, tức đến trong early data của TLS 1.3 hoặc QUIC trước khi bắt tay xong. Early data giúp request đầu tiên của kết nối nối lại nhanh hơn, nhưng có thể bị kẻ xấu phát lại, nên máy chủ thận trọng với request có tác dụng phụ như đặt hàng. ProxyVN dựng máy chủ HTTP/3 bằng aioquic trên máy lab, gửi GET và POST trong 0-RTT và sau bắt tay, đo thời gian từng ca để anh em thấy 425 xuất hiện khi nào và tránh ra sao.
Lỗi 425 Too Early: lớp nào quyết định hành vi
Để hiểu 425, cần hiểu early data. Bắt tay TLS 1.3 đầy đủ cần một vòng đi về giữa client và máy chủ trước khi gửi dữ liệu ứng dụng. Với kết nối nối lại, client đã có vé phiên từ lần trước, có thể gửi dữ liệu ngay trong gói đầu tiên, không chờ vòng bắt tay. Dữ liệu đó gọi là early data, cơ chế gọi là 0-RTT.
0-RTT đổi lấy gì
Lợi ích là tốc độ: request đầu của kết nối nối lại tới máy chủ sớm hơn một vòng đi về. Với người dùng ở xa máy chủ, một vòng có thể là vài trăm mili giây.
Cái giá là an toàn. RFC 8446 của TLS 1.3 ghi early data không được bảo vệ khỏi phát lại. Kẻ nghe trộm có thể chép gói chứa early data và gửi lại cho máy chủ. Máy chủ có thể xử lý cùng request hai lần. Với GET đọc trang thì vô hại, với POST đặt hàng hay chuyển tiền thì nguy hiểm.
Vé phiên đến từ đâu
Sau khi bắt tay đầy đủ, máy chủ gửi cho client một hoặc nhiều vé phiên. Vé chứa thông tin để nối lại phiên mà không cần trao đổi khóa từ đầu, cộng thời hạn sử dụng và giới hạn early data. Client lưu vé theo tên máy chủ. Lần sau kết nối tới cùng tên, client đưa vé ra.
Vé chỉ có giá trị với máy chủ đã cấp hoặc nhóm máy chủ dùng chung khóa vé. Trong lab, client nhận vé ở ca một, dùng ở ca hai, rồi nhận vé mới ở ca hai để dùng ở ca ba. Mỗi lần nối lại thường nhận vé mới, vé cũ có thể bị máy chủ coi là đã dùng.
425 do ai trả
RFC 8470 định nghĩa mã 425 Too Early và header Early-Data. Máy chủ nhận request trong early data mà thấy không an toàn để xử lý trước khi bắt tay xong thì trả 425. Client nhận 425 nên chờ bắt tay hoàn tất rồi gửi lại request.
Khi có máy trung gian kết thúc TLS, như CDN hay reverse proxy, máy trung gian nhận early data từ client rồi chuyển request về máy chủ gốc kèm header Early-Data: 1. Máy chủ gốc thấy header này và có thể trả 425. Máy trung gian chuyển 425 về client.
Proxy forward không thấy early data
Với proxy HTTP dùng CONNECT, TLS diễn ra trực tiếp giữa client và máy chủ đích qua đường hầm. Proxy không kết thúc TLS, không biết early data có hay không. 425 nếu có là do máy chủ đích hoặc CDN phía máy chủ đích trả, proxy forward không liên quan.
Tài liệu MDN về 425 ghi trình duyệt tự gửi lại request sau khi bắt tay xong khi nhận 425. Người dùng trình duyệt hiếm khi thấy mã này. Người viết client riêng thì phải tự xử lý.
425 là lời máy chủ nói "gửi lại sau khi bắt tay xong", không phải lỗi của request hay của proxy.
Ai thường gặp 425
Người viết client HTTP/3 riêng, người viết ứng dụng di động dùng thư viện mạng có 0-RTT, và người vận hành máy chủ sau CDN là ba nhóm hay gặp 425. Người dùng proxy cho crawl hay quản lý tài khoản hiếm gặp, vì công cụ của họ thường chạy trên HTTP/1.1 hoặc HTTP/2 qua TCP và không gửi early data.
Dù vậy, crawler dựa trên trình duyệt như Playwright có thể dùng HTTP/3 và 0-RTT khi chạy không qua proxy. Khi bật proxy HTTP, trình duyệt thường dùng TCP qua đường hầm, nên hành vi 0-RTT có thể khác giữa hai chế độ.
Ranh giới với các bài đã có
Bài proxy HTTP/3 và QUIC nói về HTTP/3 nói chung. Bài lỗi SSL protocol error nói về bắt tay TLS thất bại. Bài này chỉ đi vào early data, 0-RTT và mã 425.
Giải thích request early data và rủi ro phát lại của 0-RTT, xác minh client có gửi early data khi gặp lỗi 425 Too Early
0-RTT đổi tốc độ lấy rủi ro
Trước khi xử lý 425, cần chắc client thật sự gửi early data. Phần này đi qua điều kiện để early data xảy ra và cách nhận biết.
Ba điều kiện cho early data
Thứ nhất, client phải có vé phiên từ một kết nối trước tới cùng máy chủ. Lần kết nối đầu tiên không bao giờ có early data. Thứ hai, máy chủ phải cho phép early data khi cấp vé, thể hiện qua giá trị max_early_data_size trong vé. Thứ ba, client phải chủ động gửi dữ liệu trước khi bắt tay xong.
Thiếu một điều kiện là không có early data và không thể có 425 do early data. Nếu gặp 425 ở lần kết nối đầu tiên, nguyên nhân không phải 0-RTT của client, mà có thể là máy trung gian nhận early data từ client khác hoặc cấu hình sai.
Client nào gửi early data
Thư viện ssl của Python không hỗ trợ gửi early data, nên requests, httpx trên TCP và urllib không bao giờ gửi. curl có tùy chọn cho TLS early data trên một số bản dựng. Trình duyệt hiện đại dùng 0-RTT với HTTP/3 và đôi khi với TLS trên TCP.
Thư viện QUIC như aioquic cho phép gửi 0-RTT khi có vé và mã gửi request trước khi chờ kết nối xong. Đây là cách lab tạo early data.
Phát lại nguy hiểm ra sao
Kẻ tấn công nằm trên đường mạng chép gói đầu của client, gói chứa vé phiên và early data đã mã hóa. Họ không đọc được nội dung, nhưng gửi lại nguyên gói tới máy chủ được. Máy chủ giải mã bằng khóa từ vé và thấy một request hợp lệ.
Máy chủ có cơ chế chống phát lại một phần, như ghi nhớ vé đã dùng trong một cửa sổ thời gian. Nhưng với hệ thống nhiều máy chủ phân tán, ghi nhớ chung khó làm kín mọi kẽ hở. Vì vậy chuẩn khuyên chỉ chấp nhận request an toàn khi lặp, như GET không thay đổi trạng thái, trong early data.
Early data trong HTTP/3 và TCP
Với QUIC và HTTP/3, early data là các gói 0-RTT gửi kèm gói Initial. Với TLS 1.3 trên TCP, early data đi sau ClientHello trên cùng kết nối, nhưng TCP vẫn cần bắt tay ba bước của riêng nó trước. Vì vậy 0-RTT trên TCP tiết kiệm một vòng của TLS, còn trên QUIC tiết kiệm cả vòng của tầng truyền tải.
Trình duyệt dùng 0-RTT phổ biến hơn với HTTP/3. Đây là lý do 425 gắn nhiều với HTTP/3 và các CDN hỗ trợ QUIC.
Idempotent và an toàn
GET đi sớm, POST chờ
Request an toàn là request không thay đổi trạng thái máy chủ, như GET và HEAD. Request idempotent là request gửi nhiều lần cho cùng kết quả như gửi một lần, như PUT đặt giá trị hay DELETE. POST thường không idempotent: gửi hai lần tạo hai đơn hàng.
Chính sách phổ biến là cho GET và HEAD đi trong early data, trả 425 cho POST và các phương thức thay đổi trạng thái. Lab dùng đúng chính sách này.
Thiết kế lab lỗi 425 Too Early: phiên bản và phép đo
Lab chạy ngày 29/10/2026 trên Windows 10, Python 3.12.10, aioquic 1.7.0 trong môi trường ảo. Cả máy chủ và client là HTTP/3 trên QUIC, chạy qua UDP loopback 127.0.0.1 cổng 9592.
Máy chủ
Máy chủ dùng chứng chỉ ECDSA tự ký cho localhost, lưu vé phiên trong bộ nhớ để nhận lại khi client nối lại. Với mỗi request, máy chủ xét request đến trước hay sau khi bắt tay hoàn tất. Đến trước là early data.
Chính sách: GET trong early data được xử lý, trả 200. POST trong early data trả 425. Mọi request sau bắt tay trả 200. Máy chủ ghi log mỗi lần bắt tay xong kèm cờ đã nối lại phiên và cờ đã chấp nhận early data.
Client
Client aioquic tin chứng chỉ tự ký, nhận vé phiên từ máy chủ và lưu lại cho lần sau. Có hai chế độ: chờ kết nối xong rồi gửi, hoặc gửi ngay khi có vé, tức gửi trong 0-RTT.
Bốn ca
Ca một là GET lần đầu, chưa có vé. Ca hai là GET trong 0-RTT với vé từ ca một. Ca ba là POST trong 0-RTT với vé từ ca hai. Ca bốn là POST có vé nhưng chờ bắt tay xong mới gửi.
Mỗi ca đo thời gian từ lúc bắt đầu kết nối tới lúc nhận mã trạng thái.
Vì sao chọn HTTP/3
Python ssl không hỗ trợ early data trên TCP, nên không dựng được lab TLS 1.3 early data trên TCP bằng thư viện chuẩn. aioquic hỗ trợ 0-RTT ở cả client và máy chủ, cho phép quan sát trọn vòng: cấp vé, nối lại, gửi early data, máy chủ quyết định. Kết quả về chính sách 425 áp dụng như nhau cho TCP và QUIC.
Kết quả kỳ vọng
Ca một 200 chậm nhất vì bắt tay đầy đủ. Ca hai 200 nhanh vì 0-RTT. Ca ba 425. Ca bốn 200 nhưng chậm hơn ca hai.
Tái lập lỗi 425 Too Early: luồng thành công và ca lỗi có kiểm soát
Phần này đưa mã cốt lõi và số liệu thật từ lab.
Phía máy chủ xác định early data
class S(QuicConnectionProtocol):
def quic_event_received(s, ev):
if isinstance(ev, ProtocolNegotiated):
s.h3 = H3Connection(s._quic)
if isinstance(ev, HandshakeCompleted):
s.done = True
if s.h3:
for e in s.h3.handle_event(ev):
if isinstance(e, HeadersReceived):
h = {k.decode(): v.decode() for k, v in e.headers}
early = not s.done
code = b"425" if (early and h[":method"] == "POST") else b"200"
s.h3.send_headers(e.stream_id, [(b":status", code)], end_stream=True)
s.transmit()Máy chủ đánh dấu request là early nếu header request đến trước sự kiện HandshakeCompleted. Cách xác định này đơn giản, đủ cho lab. Máy chủ thật dùng thông tin từ thư viện TLS về việc dữ liệu thuộc giai đoạn nào.
Phía client gửi 0-RTT
cfg = QuicConfiguration(alpn_protocols=H3_ALPN, is_client=True, server_name="localhost")
cfg.load_verify_locations("c.pem")
cfg.session_ticket = ve_cu
async with connect("127.0.0.1", 9592, configuration=cfg, create_protocol=C,
session_ticket_handler=luu_ve, wait_connected=False) as c:
print(await c.req("POST", "/order"))Tham số wait_connected=False cho phép gửi request ngay, trước khi bắt tay xong. Kết hợp với vé cũ, request đi trong early data.
Bảng kết quả
Bốn ca đo thời gian
Ca |
Phương thức |
Có vé |
Gửi trong early data |
Mã |
Thời gian |
|---|---|---|---|---|---|
1 |
GET |
Không |
Không |
200 |
29,8 ms |
2 |
GET |
Có |
Có |
200 |
7,2 ms |
3 |
POST |
Có |
Có |
425 |
6,3 ms |
4 |
POST |
Có |
Không, chờ bắt tay |
200 |
31,2 ms |
Ca hai nhanh hơn ca một khoảng bốn lần trên loopback, nhờ request đi ngay với gói đầu. Trên mạng thật có độ trễ, chênh lệch tính bằng số vòng đi về, lớn hơn nhiều so với lab.
Ca ba nhận 425 trong 6,3 ms. Máy chủ từ chối ngay vì POST đến trong early data. Không có đơn hàng nào được tạo. Máy chủ cũng không cần biết request này có phải bản phát lại hay không, vì đã từ chối mọi POST đến sớm.
Ca bốn gửi cùng POST nhưng chờ bắt tay xong, nhận 200 sau 31,2 ms. Đây chính là cách xử lý chuẩn khi gặp 425: gửi lại sau khi bắt tay hoàn tất.
Trên mạng thật chênh lệch lớn hơn
Loopback có độ trễ dưới một mili giây, nên phần lớn thời gian ca một và ca bốn là chi phí tính toán khóa và xử lý của thư viện. Trên mạng thật với độ trễ khứ hồi 100 ms, ca một cần ít nhất một vòng cho bắt tay trước khi gửi request, ca hai gửi request ngay. Chênh lệch khoảng một vòng, tức 100 ms.
Với người dùng di động hay người dùng ở xa máy chủ, một vòng có thể là 200 tới 300 ms. Đó là lý do các CDN lớn bật 0-RTT cho trang tĩnh, dù có rủi ro phát lại.
Log phía máy chủ
Máy chủ ghi bốn lần bắt tay. Lần đầu có cờ đã nối lại phiên bằng false và chấp nhận early data bằng false, đúng với kết nối mới. Ba lần sau đều có cả hai cờ bằng true.
Thứ tự sự kiện trong log cho thấy rõ: ở ca hai và ca ba, dòng request đến trước dòng bắt tay xong. Ở ca bốn, dòng bắt tay xong đến trước dòng request. Đây là dấu vết để xác minh request có thật sự là early data hay không.
Vé phiên cho phép bao nhiêu early data
Vé do máy chủ aioquic cấp có max_early_data_size bằng 4.294.967.295, giá trị lớn nhất có thể. Nghĩa là máy chủ cho phép early data không giới hạn dung lượng trong cấu hình mặc định. Máy chủ thật thường đặt giới hạn nhỏ hơn hoặc tắt hẳn.
Máy chủ chấp nhận early data ở tầng TLS không có nghĩa là chấp nhận mọi request ở tầng HTTP; 425 là cách tầng HTTP từ chối riêng request nguy hiểm.
Đọc log, gói tin và response để tách lỗi 425 Too Early với lỗi TLS và lỗi gần giống
Phần này giúp phân biệt 425 với lỗi bắt tay và các mã hay bị nhầm.
425 khác lỗi bắt tay TLS
Lỗi bắt tay TLS xảy ra trước khi có HTTP, client nhận lỗi kết nối, không có mã trạng thái nào. 425 là mã HTTP, nghĩa là bắt tay đã đủ để máy chủ đọc request. Có mã 425 tức kết nối mã hóa đã hoạt động.
Nếu gặp lỗi chứng chỉ, lỗi phiên bản TLS hay kết nối bị đặt lại, đó là lớp khác. Bài ERR_SSL_PROTOCOL_ERROR đi vào các lỗi này.
Bảng phân biệt
Mã hoặc lỗi |
Lớp |
Khi nào gặp |
Gửi lại có giúp |
|---|---|---|---|
425 Too Early |
HTTP, theo early data |
Request không an toàn trong 0-RTT |
Có, sau bắt tay |
421 Misdirected Request |
HTTP, theo kết nối |
Kết nối dùng lại cho tên miền sai |
Có, trên kết nối mới |
429 Too Many Requests |
HTTP, theo tần suất |
Gửi quá nhanh |
Có, sau thời gian chờ |
503 Service Unavailable |
HTTP, theo máy chủ |
Máy chủ quá tải |
Có, sau thời gian chờ |
Lỗi bắt tay TLS |
TLS |
Chứng chỉ, phiên bản, mật mã |
Không, phải sửa cấu hình |
421 hay bị nhầm với 425 vì đều liên quan kết nối và đều sửa bằng gửi lại. Bài lỗi 421 Misdirected Request giải thích mã đó.
Xác minh client có gửi early data
Nếu nhận 425, kiểm client có dùng vé phiên và gửi trước bắt tay không. Với thư viện dựa trên Python ssl trên TCP, câu trả lời là không, nên 425 phải đến từ máy trung gian. Với client QUIC hay trình duyệt, xem log của thư viện hoặc công cụ ghi log mạng của trình duyệt.
Tắt 0-RTT ở client rồi thử lại là phép kiểm nhanh. Nếu hết 425, nguyên nhân đúng là early data. Nếu vẫn 425, máy chủ hoặc máy trung gian có lỗi cấu hình.
Đọc log máy chủ theo thứ tự sự kiện
Cách lab xác định early data dựa trên thứ tự: request đến trước khi bắt tay xong. Trên máy chủ thật, ghi thời điểm bắt tay xong và thời điểm nhận request cho mỗi kết nối, so hai mốc. Request có thời điểm sớm hơn là early data. Đây là cách kiểm độc lập với cờ mà thư viện báo.
Nếu thấy request POST được xử lý trước mốc bắt tay mà không có 425, chính sách chống phát lại đang thiếu. Đây là lỗ hổng cần sửa ngay, không phải chuyện hiệu năng.
Header Early-Data
Khi máy chủ gốc đứng sau CDN hay reverse proxy, log máy chủ gốc nên ghi header Early-Data. Request có Early-Data: 1 là request máy trung gian nhận trong early data. Đếm số request như vậy và số lần trả 425 cho biết 0-RTT ảnh hưởng tới bao nhiêu lưu lượng.
Với Nginx làm reverse proxy, tài liệu module SSL của Nginx có chỉ thị ssl_early_data để bật early data và biến ssl_early_data để chuyển trạng thái về máy chủ gốc qua header.
Xử lý lỗi 425 Too Early theo bằng chứng và checklist
Checklist lỗi 425
Cách xử lý tùy anh em là người viết client, người vận hành máy chủ, hay người dùng proxy.
Người viết client
Khi nhận 425, chờ bắt tay hoàn tất rồi gửi lại đúng request đó, như ca bốn của lab. Không gửi lại trong early data lần nữa. Với client QUIC, gửi lại trên cùng kết nối sau khi kết nối đã sẵn sàng là đủ.
Chỉ gửi trong early data những request an toàn: GET, HEAD, và request mà anh em chắc lặp lại không gây hại. POST đặt hàng, gửi biểu mẫu, đăng nhập nên chờ bắt tay xong, dù máy chủ có trả 425 hay không.
Người vận hành máy chủ
Nếu bật 0-RTT, đặt chính sách rõ: chỉ xử lý phương thức an toàn trong early data, trả 425 cho phần còn lại. Đừng tin rằng client sẽ tự kiềm chế, vì kẻ tấn công phát lại không cần tuân theo chính sách của client.
Nếu ứng dụng có thao tác nhạy cảm qua GET, như đường dẫn xác nhận hay hủy đăng ký, cân nhắc trả 425 cho các đường dẫn đó trong early data. GET không phải lúc nào cũng an toàn trong thực tế.
Nếu không chắc, tắt 0-RTT. Tốc độ thêm một vòng đi về hiếm khi đáng đổi lấy rủi ro phát lại với ứng dụng có giao dịch.
Người vận hành máy chủ: thử lại có chủ đích
Sau khi đặt chính sách, chạy lại đúng bốn ca của lab với client hỗ trợ 0-RTT: GET lần đầu, GET 0-RTT, POST 0-RTT, POST sau bắt tay. Kết quả mong đợi là 200, 200, 425, 200. Bất kỳ ca nào lệch là chính sách chưa đúng.
Thêm ca phát lại: chép gói đầu của ca POST 0-RTT và gửi lại. Với chính sách đúng, cả bản gốc và bản phát lại đều nhận 425, không có đơn nào được tạo. Ca này cần công cụ bắt và phát lại gói, lab chưa làm.
Người dùng proxy
Nếu một trang trả 425 khi đi thẳng nhưng không trả khi qua proxy, khác biệt nằm ở giao thức chứ không phải IP. Đi thẳng có thể dùng HTTP/3 với 0-RTT, qua proxy thì dùng HTTP/2 trên TCP không có early data.
Với proxy HTTP dùng CONNECT, 425 không liên quan proxy. TLS và early data diễn ra giữa client và máy chủ đích. Đổi proxy không sửa được 425.
Với crawler bằng requests hay httpx trên HTTP/1.1 và HTTP/2, client không gửi early data, nên 425 gần như không xuất hiện. Nếu xuất hiện, máy trung gian phía trang đích có lỗi cấu hình. Bài proxy tunnel là gì giải thích vì sao proxy forward không chạm tới TLS.
Ứng dụng di động
Nhiều thư viện mạng trên điện thoại hỗ trợ HTTP/3 và 0-RTT, và ứng dụng di động hay mở lại kết nối khi chuyển mạng. Vé phiên được lưu, 0-RTT được dùng thường xuyên. Đội làm ứng dụng nên kiểm thư viện có tự gửi lại khi nhận 425 không. Nếu không, người dùng sẽ thấy lỗi ở thao tác đầu tiên sau khi mở lại ứng dụng.
Khi kiểm ứng dụng di động qua proxy gỡ lỗi như Charles hay mitmproxy, proxy thường kết thúc TLS và mở kết nối mới tới máy chủ. Early data từ ứng dụng không đi tới máy chủ, nên hành vi 425 lúc kiểm qua proxy có thể khác lúc chạy thật.
Giới hạn suy luận của bài
Lab chạy HTTP/3 trên loopback với aioquic ở cả hai phía. Cách máy chủ xác định early data dựa trên thứ tự sự kiện, đơn giản hơn cách thư viện TLS thật báo. Lab chưa thử TLS 1.3 early data trên TCP, chưa thử Nginx, CDN hay trình duyệt gửi 0-RTT. Thời gian đo trên loopback không phản ánh lợi ích 0-RTT trên mạng thật.
Chính sách trả 425 cho POST là do lab tự đặt theo khuyến nghị của RFC 8470, không phải hành vi mặc định của aioquic.
Ghi log cho client
Client tự viết nên ghi mỗi lần gửi request kèm hai cờ: có dùng vé phiên không, và request có đi trước bắt tay không. Khi nhận 425, ghi cả lần gửi lại. Tỷ lệ 425 trên tổng request 0-RTT cho biết chính sách của máy chủ chặt tới đâu, từ đó quyết định có đáng tiếp tục gửi early data cho máy chủ đó không.
Checklist lỗi 425 Too Early
- Xác nhận 425 là mã HTTP, không phải lỗi bắt tay.
- Kiểm client có vé phiên và có gửi trước bắt tay không.
- Thư viện Python ssl trên TCP không gửi early data.
- Gửi lại request sau khi bắt tay xong.
- Chỉ gửi GET, HEAD trong early data.
- Máy chủ trả 425 cho phương thức thay đổi trạng thái trong early data.
- Với reverse proxy, chuyển header Early-Data về máy chủ gốc.
- Không đổi proxy forward để sửa 425.
Với crawler dùng proxy HTTP và SOCKS5, phần TLS diễn ra giữa crawler và trang đích nên proxy không gây 425. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy tại trang chủ ProxyVN cho phần đường đi, còn 0-RTT xử lý ở client và máy chủ.
Câu hỏi thường gặp về lỗi 425 Too Early
Trình duyệt có hiện lỗi 425 không?
Hiếm. Trình duyệt tự gửi lại request sau bắt tay khi nhận 425, người dùng không thấy gì.
requests của Python có gặp 425 không?
Gần như không, vì requests không gửi early data. Nếu gặp, máy trung gian phía máy chủ có lỗi.
0-RTT có lộ dữ liệu không?
Early data vẫn được mã hóa, kẻ nghe trộm không đọc được. Rủi ro là phát lại, không phải lộ nội dung.
Vì sao lần đầu kết nối không bao giờ có 425 do 0-RTT?
Vì chưa có vé phiên. Early data chỉ có khi nối lại. Gặp 425 ở kết nối đầu tiên nghĩa là nguyên nhân khác, thường là máy trung gian chuyển Early-Data sai.
Có nên tắt 0-RTT trên máy chủ?
Với ứng dụng có giao dịch và không muốn tự viết chính sách 425, tắt là lựa chọn an toàn. Với trang tĩnh, bật 0-RTT giúp tải nhanh hơn với ít rủi ro.
425 có kèm header Retry-After không?
Thường không. 425 không phải lỗi do quá tải, client không cần chờ thời gian cụ thể. Chỉ cần bắt tay xong là gửi lại được ngay.
Proxy SOCKS5 có ảnh hưởng tới 0-RTT không?
Không trực tiếp. SOCKS5 chuyển tiếp byte giữa client và máy chủ. Với QUIC cần SOCKS5 có hỗ trợ UDP, chuyện này độc lập với early data.
Lỗi 425 Too Early và những điều cần nhớ
Lỗi 425 Too Early là cách máy chủ từ chối request không an toàn gửi trong early data 0-RTT, không phải lỗi của proxy. Lab HTTP/3 cho thấy GET 0-RTT nhanh hơn bốn lần, POST trong early data nhận 425, gửi lại sau bắt tay nhận 200. Gửi lại sau bắt tay, chỉ để request an toàn đi sớm. Cần proxy ổn định cho phần đường đi khi đã xử lý lỗi 425 Too Early, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.
