HTTP Priority RFC 9218 qua proxy: lab đo thứ tự phục vụ thật

HTTP Priority RFC 9218 qua proxy là câu hỏi về việc tín hiệu ưu tiên của client có còn sống khi đi qua một tầng trung gian hay không, và máy chủ có dùng tín hiệu đó hay không. Header Priority chỉ là lời đề nghị, nó không tự làm request nhanh hơn. ProxyVN dựng một origin HTTP/2 bằng thư viện h2, một proxy gom request bằng httpx và aiohttp, rồi đo thứ tự phục vụ của sáu request cùng tài nguyên với mức ưu tiên khác nhau.

HTTP Priority RFC 9218 qua proxy: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và những gì bài không bàn.

Bài toán cần giải

Một đội thu thập dữ liệu chạy crawler qua proxy. Họ muốn tải trang danh mục trước, ảnh và tệp lớn sau, nên gắn header Priority cho từng request. Sau một tuần, không ai biết header đó có tác dụng gì. Log chỉ có mã 200 và tổng thời gian. Bài này đưa ra cách đo để trả lời câu hỏi đó bằng số liệu.

Đầu ra nghiệm thu

Đầu ra là một bảng timeline cho sáu request cùng tài nguyên: lúc nhận byte đầu, lúc xong, thứ tự hoàn thành. Bảng được đo trên năm đường đi: thẳng tới origin có lập lịch, thẳng tới origin chia lượt, qua proxy giữ header, qua proxy bỏ header, qua proxy ghi đè header. Kèm theo là log phía máy chủ ghi từng khối dữ liệu đã gửi.

Ranh giới với giới hạn đồng thời

Priority khác với chuyện giới hạn số kết nối hay hàng đợi URL của crawler. Hàng đợi quyết định request nào được gửi đi. Priority chỉ gợi ý cho máy chủ nên trả response nào trước khi nhiều response cùng tranh băng thông trên một kết nối. Bài không bàn cách xếp hàng đợi URL.

Không hứa tăng tốc

Bài không hứa header Priority làm crawler nhanh hơn. Kết quả lab cho thấy tổng thời gian của cả lô gần như không đổi giữa các ca. Thứ thay đổi là request nào xong trước. Nếu máy chủ hoặc proxy không dùng tín hiệu, ngay cả thứ tự cũng không đổi.

Giới hạn của lab

Origin và proxy đều tự viết, chạy trên 127.0.0.1. Đường truyền hẹp được giả lập bằng cách chỉ gửi một khối 16 KB mỗi nhịp 20 mili giây. Thứ thật trong lab là thư viện h2 4.4.1, httpx 0.28.1, aiohttp 3.14.5, http_sfv 0.9.9 và Python 3.12.10 trên Windows.

Ai nên đọc

Người viết crawler có nhiều loại tài nguyên trên cùng host. Người vận hành reverse proxy hoặc proxy chuyển tiếp muốn biết có nên giữ header Priority. Người đang đọc log và thấy header này mà chưa rõ nó làm gì.

Phân tích trường Priority urgency/incremental và khả năng intermediary xử lý HTTP Priority RFC 9218 qua proxy

Trước khi đo, cần nắm chuẩn nói gì về hai tham số và về vai trò của tầng trung gian.

Header Priority là gì

RFC 9218 định nghĩa một sơ đồ ưu tiên mở rộng cho HTTP. Client gửi header Priority trong request để nói nó muốn response được ưu tiên ra sao. Máy chủ phía sau một tầng trung gian cũng có thể gửi header này trong response để báo cho tầng trung gian.

Thay thế cơ chế cây của HTTP/2 cũ

RFC 9218 ra đời vì sơ đồ ưu tiên dạng cây phụ thuộc trong đặc tả HTTP/2 đầu tiên phức tạp và ít được triển khai đúng. RFC 9113 đã bỏ cơ chế cây đó. Tham số SETTINGS_NO_RFC7540_PRIORITIES cho phép hai đầu báo rằng chúng không dùng cơ chế cũ.

Hai tham số chính

Tham số u là urgency, số nguyên từ 0 tới 7, số nhỏ là ưu tiên cao, mặc định là 3. Tham số i là incremental, kiểu boolean, mặc định là false. Nếu request không có tham số nào, máy chủ nên coi như request mang giá trị mặc định.

Header là end-to-end

RFC 9218 mục 14 giải thích vì sao Priority là header end-to-end. Cách client xử lý response là thuộc tính của client tạo request, không phải của tầng trung gian. Cache có thể lưu giá trị Priority cùng response để dùng lại khi phục vụ từ cache.

Khung PRIORITY_UPDATE chỉ đi một chặng

Sau khi gửi request, client có thể đổi ý bằng khung PRIORITY_UPDATE của HTTP/2 hoặc HTTP/3. Khung này chỉ đi một chặng. Tầng trung gian nhận khung không có nghĩa vụ chuyển nó tới máy chủ phía sau. Bài này chỉ đo header, không đo khung.

Tầng trung gian có ba lựa chọn

RFC 9218 mục 4 mô tả ba cách. Tầng trung gian chỉ chuyển header Priority thì giữ nguyên tín hiệu gốc của client. Nó có thể chuyển header và gửi thêm PRIORITY_UPDATE để bảo chặng sau dùng mức khác. Nếu nó thay hoặc thêm header Priority, tín hiệu gốc bị ghi đè cho mọi chặng sau.

Gom request từ nhiều client

Proxy gom request

RFC 9218 mục 13.1 cảnh báo về tầng trung gian gom request của nhiều client vào một kết nối HTTP/2 tới máy chủ. Nếu máy chủ tuân theo Priority, client khai mức cao có thể chiếm hết băng thông của client khác. Máy chủ có thể nhận ra tầng trung gian qua header Via hoặc Forwarded.

Phía sau là HTTP/1.1

RFC 9218 mục 13.2 nói CDN thường nói HTTP/2 hoặc HTTP/3 với client nhưng nói HTTP/1.1 với máy chủ phía sau. HTTP/1.1 không ghép nhiều response trên một kết nối, nên lập lịch giữa các response không còn ý nghĩa ở chặng đó. Máy chủ vẫn có thể đọc header để xếp việc nội bộ.

Chỉ là gợi ý

RFC 9218 mục 10 viết rõ: endpoint không thể phụ thuộc vào một cách xử lý cụ thể dựa trên tín hiệu ưu tiên. Biểu đạt ưu tiên chỉ là một gợi ý. Máy chủ còn cân nhắc nhiều yếu tố khác như cách triển khai và môi trường chạy.

Endpoints cannot depend on particular treatment based on priority signals. (RFC 9218, mục 10)

Đọc urgency và incremental của HTTP Priority RFC 9218 qua proxy theo đúng kiểu dữ liệu

Header Priority là một Dictionary theo chuẩn Structured Fields, nên phải parse đúng kiểu thay vì tách chuỗi bằng tay.

Cú pháp Dictionary

Giá trị của Priority được mã hóa theo RFC 9651, phiên bản mới của chuẩn Structured Fields. Ví dụ u=5, i nghĩa là urgency 5 và incremental true. Thành viên i không có giá trị đi kèm được hiểu là boolean true. Có thể viết i=?1 cho cùng ý nghĩa.

Luật bỏ qua của RFC 9218

RFC 9218 mục 4 thêm một yêu cầu sau khi parse Dictionary thành công. Tham số không biết, tham số có giá trị ngoài miền, hoặc giá trị sai kiểu phải bị bỏ qua. Nếu bản thân Dictionary parse lỗi, cả header không dùng được và máy chủ quay về mặc định.

Hàm parse trong lab

Origin của lab dùng http_sfv để parse, rồi áp luật bỏ qua. Hàm trả về cặp urgency, incremental và danh sách ghi chú để ghi log. Ghi chú cho biết tham số nào bị bỏ và vì sao, thay vì im lặng dùng mặc định.

import http_sfv
 
def parse_priority(raw):
    u, i, notes = 3, False, []
    if raw is None:
        return u, i, ["khong co header"]
    d = http_sfv.Dictionary()
    try:
        d.parse(raw.encode())
    except ValueError as e:
        return u, i, [f"loi parse: {e}"]
    for k, v in d.items():
        val = v.value
        if k == "u":
            if isinstance(val, int) and not isinstance(val, bool) and 0 <= val <= 7:
                u = val
            else:
                notes.append(f"bo qua u={val!r}")
        elif k == "i":
            if isinstance(val, bool):
                i = val
            else:
                notes.append(f"bo qua i={val!r}")
        else:
            notes.append(f"bo qua tham so la {k}")
    return u, i, notes

Bẫy kiểu boolean trong Python

Trong Python, True là một số nguyên. Nếu chỉ kiểm isinstance(val, int), giá trị u=?1 sẽ lọt qua thành urgency 1. Hàm của lab loại boolean ra trước. Đây là lỗi nhỏ nhưng dễ gặp khi tự viết bộ đọc.

Sáu giá trị sai đã thử

Lab gửi sáu header lỗi tới origin có lập lịch: u=9, u=abc, u=1.5, u=0,, (thừa dấu phẩy), U=0 (khóa viết hoa) và u=0, i=?1, x=1. Bảng dưới là kết quả parse ghi trong log máy chủ.

Bảng: Sáu giá trị sai đã thử

Header gửi	Kết quả parse	Ghi chú trong log
u=9	u=3, i=false	bỏ qua u=9, ngoài miền
u=abc	u=3, i=false	bỏ qua u='abc', sai kiểu
u=1.5	u=3, i=false	bỏ qua Decimal 1.5
u=0,,	u=3, i=false	lỗi parse cả header
U=0	u=3, i=false	lỗi parse cả header
u=0, i=?1, x=1	u=0, i=true	bỏ qua tham số lạ x

Ý nghĩa của bảng

Năm header đầu đều rơi về mặc định. Chỉ header cuối được dùng, vì Dictionary hợp lệ và tham số lạ x bị bỏ riêng. Khi đo thứ tự, request mang u=0, i=?1, x=1 xong trước cả năm request kia trong cả ba lần chạy.

Khóa viết hoa làm hỏng cả header

Structured Fields yêu cầu khóa viết thường. U=0 không phải là khóa U với giá trị 0 mà là lỗi cú pháp. Với một số bộ đọc tự viết dùng lower(), U=0 vẫn được chấp nhận. Vì vậy hai máy chủ có thể hiểu cùng một header theo hai cách.

Ghi log thay vì đoán

Một máy chủ âm thầm dùng mặc định thì người viết crawler không biết header của mình sai. Lab ghi lại header gốc, giá trị đã parse và ghi chú. Khi chẩn đoán, ba trường này đủ để biết lỗi nằm ở client hay ở cách máy chủ đọc.

Gửi request fixture có HTTP Priority RFC 9218 qua proxy với mức khác nhau

Phần này mô tả bộ request dùng chung cho mọi ca và cách client đo.

Cùng một tài nguyên

Cả sáu request đều gọi /blob, một tài nguyên 128 KB như nhau. Chọn cùng tài nguyên để loại yếu tố kích thước, loại tệp và cache. Khác biệt duy nhất giữa các request là header Priority và nhãn x-label để nhận diện trong log.

Bộ sáu request

R1 mang u=5, giống ảnh nền. R2 không có header, tức mặc định u=3. R3 mang u=0, giống CSS chặn hiển thị. R4 và R5 mang u=1, i, giống hai tệp xử lý dần được. R6 mang u=7, mức nền dành cho cập nhật phần mềm.

Thứ tự gửi

Client gửi sáu request lệch nhau 2 mili giây theo thứ tự R1 tới R6. Trên một kết nối HTTP/2, stream ID tăng theo thứ tự gửi. Nhờ vậy có thể so thứ tự hoàn thành với thứ tự gửi để biết máy chủ có sắp xếp lại hay không.

Client đo bằng httpx

Client dùng httpx 0.28.1 ở chế độ HTTP/2 không mã hóa với prior knowledge khi gọi thẳng origin. Khi gọi qua proxy, client dùng HTTP/1.1, mỗi request một kết nối. Client ghi ba mốc cho mỗi request: lúc gửi, lúc nhận byte body đầu tiên, lúc nhận hết body.

async with c.stream("GET", base + "/blob", headers=h) as r:
    async for ch in r.aiter_raw():
        if first is None:
            first = time.perf_counter()
        n += len(ch)
end = time.perf_counter()

Mở kết nối trước

Trước mỗi lô, client gửi một request warm để mở kết nối HTTP/2. Nếu bỏ bước này, request đầu tiên tự mở kết nối và các request sau có thể chờ bắt tay, làm lẫn thời gian kết nối với thời gian lập lịch.

Ba lần chạy mỗi ca

Mỗi ca chạy ba lần. Bảng kết quả dùng trung vị của ba lần cho mốc byte đầu và mốc xong. Thứ tự hoàn thành của từng lần được in riêng để thấy ca nào ổn định, ca nào dao động.

Giả lập đường truyền hẹp

Lập lịch chỉ có ý nghĩa khi các response tranh băng thông. Trên 127.0.0.1, băng thông gần như vô hạn. Origin của lab chỉ gửi một khối 16 KB mỗi nhịp 20 mili giây, cả lô sáu request mất khoảng 1,5 giây. Con số này do lab đặt, không đại diện cho mạng thật.

Bẫy đồng hồ asyncio trên Windows

Lần chạy đầu dùng nhịp 5 mili giây và cả lô xong trong khoảng 75 mili giây, nhanh hơn lý thuyết gấp bốn lần. Nguyên nhân là asyncio coi mọi hẹn giờ nằm trong độ phân giải đồng hồ là đã đến hạn. Độ phân giải này trên Windows khoảng 15,6 mili giây, nên nhịp 5 mili giây không có tác dụng. Lab chuyển sang nhịp 20 mili giây.

Thời gian chờ gom

Origin chờ 40 mili giây sau request đầu tiên rồi mới gửi dữ liệu, để cả sáu request kịp đến. Trong vài lần chạy, R1 vẫn được gửi một khối trước khi các request khác tới. Log ghi rõ điều này, và nó giải thích vì sao byte đầu của R1 sớm dù R1 mang u=5.

Ghi lịch phục vụ trên server và proxy hỗ trợ phép thử HTTP Priority RFC 9218 qua proxy

Phần này mô tả hai kiểu origin, ba kiểu proxy và cách ghi lịch phục vụ.

Origin có lập lịch

Origin prio đọc Priority, chọn stream có urgency nhỏ nhất còn dữ liệu. Trong cùng urgency, stream không incremental được gửi hết theo stream ID tăng dần. Các stream incremental cùng urgency được chia lượt từng khối. Đây là cách làm theo khuyến nghị ở RFC 9218 mục 10.

def pick(self):
    ready = [s for s, st in self.streams.items()
             if st["sent"] < BODY and self.conn.local_flow_control_window(s) > 0]
    top = min(self.streams[s]["u"] for s in ready)
    group = sorted(s for s in ready if self.streams[s]["u"] == top)
    non = [s for s in group if not self.streams[s]["i"]]
    if non:
        return non[0]
    inc = [s for s in group if self.streams[s]["i"]]
    self.rr += 1
    return inc[self.rr % len(inc)]

Origin chia lượt

Origin fifo bỏ qua Priority và chia lượt từng khối cho mọi stream đang mở. Nhiều máy chủ HTTP/2 đơn giản hoạt động gần giống vậy. Đây là ca đối chứng để thấy kết quả khi máy chủ không dùng tín hiệu.

Tôn trọng flow control

Origin chỉ chọn stream còn cửa sổ flow control lớn hơn 0 và cắt khối theo cửa sổ còn lại. Nếu bỏ điều kiện này, h2 sẽ báo lỗi khi gửi vượt cửa sổ. Trong lab, httpx cập nhật cửa sổ đủ nhanh nên không stream nào bị chặn lâu.

Proxy gom request

Proxy của lab nhận request HTTP/1.1 từ client bằng aiohttp, rồi chuyển tất cả lên một kết nối HTTP/2 duy nhất tới origin bằng httpx. Đây là mô hình gom request mà RFC 9218 mục 13.1 nói tới. Proxy thêm Via: 1.1 proxy-lab để origin biết có tầng trung gian.

Ba chế độ proxy

Chế độ pass chuyển nguyên header Priority. Chế độ strip bỏ header. Chế độ flatten ghi đè mọi request thành u=3. Ba chế độ đại diện cho ba hành vi có thể gặp ở proxy thật: giữ, làm mất do danh sách header cho phép, và chuẩn hóa theo chính sách.

h = {"x-label": req.headers.get("x-label", ""), "via": "1.1 proxy-lab"}
pr = req.headers.get("priority")
if MODE == "pass" and pr is not None:
    h["priority"] = pr
if MODE == "flatten":
    h["priority"] = "u=3"

Log phía máy chủ

Mỗi khi gửi một khối, origin ghi một dòng JSON: thời điểm, stream ID, nhãn, số byte, có phải khối cuối. Mỗi khi nhận request, origin ghi header gốc, urgency, incremental đã parse và header Via. Lịch phục vụ được dựng lại từ các dòng này.

Rút gọn lịch phục vụ

Lịch phục vụ từ log

Script gom các khối liên tiếp cùng nhãn thành dạng R3x8, nghĩa là tám khối của R3 liền nhau. Một lô ở origin prio trông như sau: R3x8, rồi R5 và R4 xen kẽ từng khối, rồi R2x8, R1x8, R6x8. Đọc dòng này là thấy ngay máy chủ đã làm gì.

Vì sao cần log hai phía

Client chỉ thấy thời điểm byte đến. Proxy có thể đệm dữ liệu, làm lệch thời điểm. Log phía máy chủ cho biết thứ tự gửi thật. Khi hai log cùng chỉ một thứ tự, kết luận mới đứng vững.

Báo trường hợp header bị bỏ qua và giới hạn kết luận hiệu năng của HTTP Priority RFC 9218 qua proxy

Đây là phần kết quả. Mọi con số là trung vị của ba lần chạy trong lab.

Ca 1: thẳng tới origin có lập lịch

Thứ tự xong trong cả ba lần là R3, R5, R4, R2, R1, R6. R3 mang u=0 xong ở 361 mili giây. R4 và R5 xen kẽ nhau và xong gần như cùng lúc ở khoảng 764 mili giây. R6 mang u=7 xong cuối ở 1475 mili giây.

Ca 2: thẳng tới origin chia lượt

Thứ tự xong thay đổi giữa ba lần chạy, ví dụ R1, R5, R6, R4, R3, R2 ở lần đầu. Mọi request xong trong khoảng 1263 tới 1478 mili giây. R3 mang u=0 xong ở 1447 mili giây, chậm hơn ca 1 khoảng bốn lần. Header vẫn tới máy chủ, chỉ là máy chủ không dùng.

Ca 3: qua proxy giữ header

Thứ tự xong giống ca 1 trong cả ba lần: R3, R5, R4, R2, R1, R6. R3 xong ở 426 mili giây. Các mốc chậm hơn ca 1 khoảng 30 tới 70 mili giây do thêm một chặng proxy. Tín hiệu đi qua tầng trung gian còn nguyên và origin dùng được.

Ca 4: qua proxy bỏ header

Thứ tự xong trở thành R1, R2, R3, R4, R5, R6, đúng thứ tự gửi. Origin thấy mọi request đều mặc định u=3 không incremental, nên gửi lần lượt theo stream ID. R3 xong ở 832 mili giây thay vì 426 mili giây ở ca 3.

Ca 5: qua proxy ghi đè u=3

Kết quả giống hệt ca 4. Khi proxy ghi đè mọi request thành cùng một mức, tín hiệu khác biệt của client mất đi. Từ phía client, không có cách nào phân biệt ca 4 với ca 5 nếu chỉ nhìn response.

Bảng tổng hợp

Timeline năm đường đi

Bảng: Bảng tổng hợp

Ca	Thứ tự xong	R3 (u=0) xong	Request cuối xong
1 thẳng origin prio	R3 R5 R4 R2 R1 R6	361 ms	1475 ms
2 thẳng origin fifo	thay đổi mỗi lần	1447 ms	1478 ms
3 proxy pass	R3 R5 R4 R2 R1 R6	426 ms	1546 ms
4 proxy strip	R1 R2 R3 R4 R5 R6	832 ms	1550 ms
5 proxy flatten	R1 R2 R3 R4 R5 R6	830 ms	1544 ms

Tổng thời gian không đổi

Cột cuối cho thấy request cuối cùng xong ở khoảng 1,5 giây trong mọi ca. Priority không làm lô request nhanh hơn. Nó chỉ chọn ai được trước. Request mức cao xong sớm thì request mức thấp xong muộn tương ứng.

Byte đầu không phải chỉ số tốt

Trong ca 1, R1 mang u=5 nhận byte đầu ở 11,5 mili giây, sớm nhất lô, nhưng xong ở 1228 mili giây. Đó là khối duy nhất được gửi trước khi các request khác kịp tới. Nếu chỉ đo thời gian tới byte đầu, kết luận sẽ ngược với thực tế phục vụ.

Incremental chia băng thông

R4 và R5 cùng u=1, i nhận khối xen kẽ, nên cả hai xong gần cùng lúc. Nếu chúng không incremental, máy chủ sẽ gửi hết R4 rồi mới tới R5. Với crawler lưu cả tệp rồi mới xử lý, chia băng thông không có lợi, vì không tệp nào dùng được trước khi xong.

Không suy rộng ngoài phép đo

Kết quả chỉ chứng minh hành vi của origin và proxy tự viết trong lab. Nó không chứng minh Nginx, Cloudflare hay proxy thương mại nào tôn trọng Priority. Muốn biết, phải đo trên chính đường đi đó bằng cùng phương pháp.

Đầu ra nghiệm thu HTTP Priority RFC 9218 qua proxy: lab request cùng tài nguyên với priority khác và timeline không suy diễn ngoài phép đo

Phần này gom đầu ra thành bản ghi có thể lưu và so sánh giữa các lần chạy.

Bản ghi của mỗi ca

Script lưu result.json gồm phiên bản Python, httpx, h2, aiohttp, hệ điều hành, thứ tự xong của từng lần chạy và trung vị từng mốc. Kèm theo là lịch phục vụ rút gọn đọc từ log máy chủ. Hai thứ này đủ để người khác kiểm lại kết luận.

Danh sách kiểm tra

Danh sách nghiệm thu

• Mỗi ca có ít nhất ba lần chạy và in thứ tự của từng lần.
• Lịch phục vụ đọc từ log máy chủ, không suy từ client.
• Có ca đối chứng máy chủ không dùng Priority.
• Có ca proxy bỏ hoặc ghi đè header.
• Header lỗi được ghi chú trong log thay vì im lặng dùng mặc định.
• Báo cáo ghi rõ đường truyền được giả lập và tốc độ giả lập.

Những gì lab chưa chạy

Chưa thử HTTP/3 và khung PRIORITY_UPDATE. Chưa thử TLS. Chưa thử máy chủ thật như Nginx, h2o, Caddy hay CDN. Chưa thử proxy thương mại. Chưa đo trên mạng có độ trễ và mất gói. Header Priority response từ origin cũng chưa được đưa vào phép đo.

Câu kết luận được phép viết

Câu được phép viết là: trên origin lab có lập lịch, qua proxy giữ header, request u=0 xong trước, tổng thời gian lô không đổi. Câu không được phép viết là: thêm Priority giúp crawler nhanh hơn. Câu thứ hai không có số liệu nào trong lab chống đỡ.

Mẫu báo cáo ngắn

Một báo cáo ngắn nên có bốn dòng: đường đi đã đo, máy chủ có dùng tín hiệu không, proxy giữ hay bỏ header, và thay đổi thứ tự quan sát được. Nếu dòng thứ hai là không, ba dòng còn lại cũng chỉ còn giá trị ghi nhận.

Vận hành crawler với HTTP Priority RFC 9218 qua proxy

Phần này chuyển kết quả lab thành quyết định cho crawler và proxy đang chạy.

Khi nào nên gửi header

Gửi Priority khi crawler tải nhiều tài nguyên song song trên cùng một kết nối HTTP/2 hoặc HTTP/3 và có tài nguyên cần sớm hơn. Với crawler mỗi request một kết nối HTTP/1.1, header không đổi được thứ tự giữa các kết nối. Lúc đó hàng đợi phía client mới là chỗ quyết định.

Đặt mức theo việc xử lý

Trang danh mục cần để sinh URL mới nên có mức cao hơn ảnh và tệp đính kèm. Tệp chỉ lưu trữ nên để u=6 hoặc u=7. Chỉ đặt i khi chương trình thật sự xử lý được từng phần, ví dụ parse luồng JSON Lines. Đặt i bừa bãi làm mọi tệp cùng xong muộn.

Kiểm proxy trước khi tin

Gửi một request có Priority qua proxy tới một máy chủ ghi log header mà anh em kiểm soát. Nếu header không tới, proxy đang bỏ nó. Nếu header tới với giá trị khác, proxy đang ghi đè. Bước này mất vài phút và trả lời câu hỏi mà mọi phép đo hiệu năng sau đó phụ thuộc vào.

Tunnel HTTPS khác proxy chuyển tiếp

Với HTTPS qua phương thức CONNECT, proxy chỉ chuyển byte đã mã hóa và không đọc được header. Header Priority đi thẳng tới máy chủ đích. RFC 9218 mục 11 có bàn về lập lịch với CONNECT. Trường hợp header bị bỏ chủ yếu gặp ở proxy giải mã hoặc reverse proxy.

Công bằng giữa các tác vụ

Nếu nhiều crawler dùng chung một proxy gom request, một tác vụ đặt mọi request u=0 có thể làm tác vụ khác chậm lại khi máy chủ phía sau tôn trọng Priority. Đây là vấn đề công bằng mà RFC 9218 mục 13.1 nêu. Quy ước mức ưu tiên chung cho cả đội tránh được chuyện này.

Ghi Priority vào log crawler

Thêm giá trị Priority đã gửi vào mỗi dòng log tải trang. Khi so thời gian tải theo mức ưu tiên, anh em sẽ thấy máy chủ đích có dùng tín hiệu hay không. Nếu các mức có phân bố thời gian giống nhau, header đang không có tác dụng trên đường đi đó.

Chạy lại lab trên máy của anh em

Lab gồm ba tệp origin.py, proxy.py và run.py, chỉ cần h2, httpx, aiohttp và http_sfv. Chạy run.py sẽ khởi động hai origin và ba proxy trên cổng 9871 tới 9875, rồi in bảng như trong bài. Đổi nhịp gửi và kích thước tài nguyên để gần với mạng của anh em hơn.

Proxy ở đâu trong luồng

Proxy chuyển tiếp cho crawler nên giữ nguyên header Priority, giống ca 3 của lab. Khi cần IP tại Việt Nam để thu thập dữ liệu trong nước, anh em có thể mua proxy tại trang chủ ProxyVN, rồi kiểm đường đi bằng máy chủ ghi log như trên. Vai trò của proxy trong thu thập dữ liệu có ở bài Web Scraping proxy là gì, cách ghi chuỗi cấu hình có ở bài định dạng proxy. Nếu cần biết thêm về dấu vân tay HTTP/2, xem bài HTTP/2 fingerprint.

HTTP Priority RFC 9218 qua proxy: câu hỏi thường gặp

Các câu dưới đây gom những điểm hay bị hỏi.

Thêm header Priority có làm request nhanh hơn không?

Không tự động. Trong lab, tổng thời gian lô gần như không đổi. Header chỉ đổi thứ tự khi máy chủ dùng nó.

Giá trị mặc định là gì?

Urgency 3 và incremental false. Request không có header được coi như mang hai giá trị này.

Proxy có phải chuyển header Priority không?

RFC 9218 không bắt buộc. Proxy chỉ chuyển header thì giữ tín hiệu gốc. Proxy thay header thì ghi đè cho mọi chặng sau.

Vì sao u=9 không có tác dụng?

Urgency chỉ nhận số từ 0 tới 7. Giá trị ngoài miền phải bị bỏ qua và máy chủ dùng mặc định.

PRIORITY_UPDATE có đi qua proxy không?

Khung này chỉ đi một chặng. Tầng trung gian không bắt buộc chuyển nó tới máy chủ phía sau.

HTTP/1.1 có dùng được Priority không?

Header gửi được, nhưng HTTP/1.1 không ghép nhiều response trên một kết nối. Máy chủ chỉ có thể dùng nó để xếp việc nội bộ.

Làm sao biết máy chủ có dùng Priority?

So thứ tự hoàn thành của nhiều request cùng tài nguyên với mức khác nhau, chạy nhiều lần. Nếu thứ tự theo mức ưu tiên, máy chủ đang dùng.

HTTP Priority RFC 9218 qua proxy và những điều cần nhớ

HTTP Priority RFC 9218 qua proxy là tín hiệu gợi ý end-to-end, chỉ có tác dụng khi proxy giữ nguyên header và máy chủ chọn dùng nó. Lab cho thấy proxy bỏ hoặc ghi đè header làm thứ tự quay về thứ tự gửi, còn tổng thời gian lô không đổi. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em đo thứ tự phục vụ trên chính đường đi của mình trước khi kết luận về HTTP Priority RFC 9218 qua proxy.