Mạng và Internet
Mạng và Internet
Bạn gõ một địa chỉ, chờ hai giây, trang hiện ra. Hai giây đó đi đâu? Câu trả lời quyết định việc nâng gói mạng có đáng tiền hay không.
Ở bài phần cứng và hệ điều hành bạn đã biết mạng cục bộ khác mạng diện rộng ở đâu, Wi-Fi không phải Internet, và một đường 100 Mbps chuyển được nhiều nhất 12,5 MB mỗi giây vì một byte có tám bit. Bài này đi tiếp từ đúng chỗ đó.
Vì con số 12,5 MB mỗi giây trả lời được rất ít. Một trang web nặng 2 MiB, chia cho 12,5 MB mỗi giây thì ra khoảng một phần sáu giây, nhưng thực tế bạn chờ gần hai giây. Chỗ chênh lệch không phải sai số đo: nó là phần lớn nhất của cái chờ, và nó không nằm trong phép chia đó.
Một địa chỉ web thành trang hiện ra, theo bốn chặng
Khi bạn gõ vku.udn.vn rồi nhấn Enter, máy bạn chưa biết phải nói với ai. Bốn việc xảy ra lần lượt, và mỗi việc đều tốn thời gian riêng.
Chặng một, phân giải tên miền. Máy tính không hiểu tên, nó chỉ hiểu địa chỉ số. Nên trước hết máy hỏi một máy chủ tên miền (DNS, Domain Name System): tên này ứng với địa chỉ nào? Nếu câu trả lời đã có sẵn trong bộ đệm của máy bạn hay của nhà mạng thì gần như miễn phí; nếu chưa, câu hỏi có thể phải đi qua vài máy chủ mới có đáp án.
Chặng hai, mở kết nối. Có địa chỉ rồi, máy bạn vẫn phải bắt tay với máy chủ trước khi nói bất cứ điều gì: máy bạn gửi lời chào, máy chủ đáp lại, máy bạn xác nhận. Đó là bắt tay của giao thức TCP, và nó tốn đúng một vòng đi và về. Vòng đi và về, viết tắt RTT (Round Trip Time), là đơn vị đắt nhất trong cả câu chuyện này.
Chặng ba, khoá kênh lại. Nếu địa chỉ bắt đầu bằng https thì còn một cuộc bắt tay nữa, của TLS, để hai bên thống nhất khoá mã hoá. Bản TLS 1.3 tốn thêm một vòng nữa.
Chặng bốn, hỏi và nhận. Giờ mới tới lúc máy bạn gửi câu hỏi thật, kiểu "cho tôi trang chủ". Byte đầu tiên của câu trả lời về sau một vòng nữa, rồi phần còn lại chảy về theo băng thông. Nhưng một trang web không phải một tệp: nó là một tệp HTML kéo theo hàng chục tệp khác, gồm ảnh, phông chữ, mã trang trí, mã chạy. Mỗi tệp lại cần một lượt hỏi và chờ.
Chặng bốn là chỗ chôn thời gian, vì nó lặp lại. Đây cũng là chỗ trình duyệt phải khôn: nó mở vài kết nối để hỏi nhiều tệp cùng lúc, và nó dùng lại kết nối đã mở thay vì bắt tay lại từ đầu cho từng tệp.
Khung dưới đây tính đúng bốn chặng đó thành từng khoảng thời gian. Bạn sửa được mọi con số và nó tính lại ngay.
1 · Một địa chỉ web thành trang, theo trình tự ✎ sửa được
| chặng | thuộc phần | mất bao lâu | xong ở mốc |
|---|---|---|---|
| Phân giải tên miền thành địa chỉ | độ trễ | 20,00 ms | 20,00 ms |
| Bắt tay TCP, mở kết nối cho lượt 1 | độ trễ | 178,00 ms | 198,00 ms |
| Bắt tay TLS, khoá kênh cho lượt 1 | độ trễ | 178,00 ms | 376,00 ms |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 1 | độ trễ | 178,00 ms | 554,00 ms |
| Nhận dữ liệu của 6 tệp, lượt 1 | băng thông | 20,97 ms | 574,97 ms |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 2 | độ trễ | 178,00 ms | 752,97 ms |
| Nhận dữ liệu của 6 tệp, lượt 2 | băng thông | 20,97 ms | 773,94 ms |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 3 | độ trễ | 178,00 ms | 951,94 ms |
| Nhận dữ liệu của 6 tệp, lượt 3 | băng thông | 20,97 ms | 972,91 ms |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 4 | độ trễ | 178,00 ms | 1,15 giây |
| Nhận dữ liệu của 6 tệp, lượt 4 | băng thông | 20,97 ms | 1,17 giây |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 5 | độ trễ | 178,00 ms | 1,35 giây |
| Nhận dữ liệu của 6 tệp, lượt 5 | băng thông | 20,97 ms | 1,37 giây |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 6 | độ trễ | 178,00 ms | 1,55 giây |
| Nhận dữ liệu của 6 tệp, lượt 6 | băng thông | 20,97 ms | 1,57 giây |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 7 | độ trễ | 178,00 ms | 1,75 giây |
| Nhận dữ liệu của 6 tệp, lượt 7 | băng thông | 20,97 ms | 1,77 giây |
| Gửi yêu cầu và chờ byte đầu tiên, lượt 8 | độ trễ | 178,00 ms | 1,95 giây |
| Nhận dữ liệu của 6 tệp, lượt 8 | băng thông | 20,97 ms | 1,97 giây |
Một chiều: 75 ms + 14 chặng × 1 ms = 89 ms một chiều. Một vòng đi và về là gấp đôi, tức 178,00 ms. Trang này phải trả 10 vòng: 2 vòng bắt tay cộng 8 lượt yêu cầu (vì kết nối được dùng lại nên bắt tay chỉ trả một lần). Cộng phân giải tên miền: 20 ms + 10 vòng × 178 ms = 1.800 ms.
2 · Hai phần của cái chờ, và mốc giao nhau ✎ sửa được
Mốc giao nhau tính ra từ hai con số đã có, không phải mò: đặt phần độ trễ bằng phần băng thông thì kích thước = độ trễ × tốc độ. Với cấu hình đang xem: 1.800 ms × 12.500.000 byte/giây ÷ 1000 = 22.500.000 byte, tức 21.972,66 KiB. Tốc độ đó lấy từ 100 Mbps × 1.000.000 ÷ 8 = 12.500.000 byte mỗi giây.
3 · Đường dày không chữa được đường xa ✎ sửa được
| nếu băng thông là | phần độ trễ | phần băng thông | tổng |
|---|---|---|---|
| 10 Mbps | 1,80 giây | 1,68 giây | 3,48 giây |
| 100 Mbps (gần mức bạn đặt nhất) | 1,80 giây | 167,77 ms | 1,97 giây |
| 1.000 Mbps | 1,80 giây | 16,78 ms | 1,82 giây |
| 10.000 Mbps | 1,80 giây | 1,68 ms | 1,80 giây |
| nếu đổi | phần độ trễ | phần băng thông | tổng | so với hiện tại |
|---|---|---|---|---|
| không đổi gì | 1,80 giây | 167,77 ms | 1,97 giây | 1,00× (mốc so sánh) |
| băng thông ×10 | 1,80 giây | 16,78 ms | 1,82 giây | 1,08× nhanh hơn |
| độ trễ một chiều ÷2 | 910,00 ms | 167,77 ms | 1,08 giây | 1,83× nhanh hơn |
| cả hai cùng lúc | 910,00 ms | 16,78 ms | 926,78 ms | 2,12× nhanh hơn |
| mở kết nối mới cho từng lượt | 4,29 giây | 167,77 ms | 4,46 giây | 0,44× chậm hơn |
4 · Khoảng cách, và mức sàn không thương lượng được ✎ sửa được
- Nó không dự báo thời gian tải thật. Nó cộng những chặng mà nó có mô hình, và bỏ qua nhiều thứ chỉ làm chậm thêm: TCP chưa đạt tốc độ tối đa ngay từ gói đầu, máy chủ cũng cần thời gian suy nghĩ, gói tin có thể mất và phải gửi lại, đường truyền chia sẻ với người khác, rồi trình duyệt còn phải dựng và chạy những gì nhận được. Thực tế luôn lâu hơn.
- Mô hình giả định TLS 1.3, tức một vòng bắt tay. TLS 1.2 cần hai vòng. Nó cũng giả định mỗi chặng thêm một khoảng thời gian như nhau, trong khi router thật thì lúc rảnh lúc tắc.
- Mô hình theo lối HTTP/1.1: nhiều tệp đi thành từng lượt, mỗi lượt trả một vòng chờ. HTTP/2 và HTTP/3 gửi nhiều tệp cùng lúc trên một kết nối nên số vòng ít hơn nhiều, và HTTP/3 gộp bắt tay lại còn một vòng. Nói cách khác, con số ở mục 1 là bức tranh của một trang chưa được tối ưu.
- Phân giải tên miền ở đây là một con số duy nhất bạn đặt. Ngoài đời nó là một chuỗi truy vấn có thể đi qua nhiều máy chủ, và thường đã có sẵn trong bộ đệm nên gần như miễn phí.
- Mọi giá trị mặc định là số minh hoạ, không phải số đo. Chỉ mức sàn vật lý là suy ra từ một hằng số đã định nghĩa. Cổng kiểm số canh phép tính, không canh chuyện đường truyền ngoài kia có đúng những con số này hay không.
Đọc trạng thái mở bài
Kịch bản mặc định là một trang 2 MiB gồm 48 tệp, đường 100 Mbps, máy chủ ở cách 15.000 km. Mọi con số dưới đây bạn tự dựng lại được bằng số học phổ thông.
Một vòng đi về mất 178 ms. Độ trễ một chiều gồm hai phần: 75 ms cho bản thân đường truyền, cộng 14 chặng router mỗi chặng 1 ms, thành 89 ms. Đi và về là 178 ms.
Trang này phải trả 10 vòng. Trình duyệt mở 6 kết nối song song, nên 48 tệp chia thành 48 / 6 = 8 lượt. Vì kết nối được dùng lại nên bắt tay chỉ trả một lần: 1 vòng TCP cộng 1 vòng TLS là 2 vòng. Cộng 8 lượt hỏi, tổng là 10 vòng.
Phần chờ đường truyền là 1.800 ms. Đó là 20 ms phân giải tên miền cộng 10 × 178 ms. Tức 1,80 giây, và trong 1,80 giây ấy chưa có một byte nội dung nào được tính.
Phần chờ dữ liệu là 167,77 ms. Đường 100 Mbps chạy được 12.500.000 byte mỗi giây; trang nặng 2048 × 1024 = 2.097.152 byte; chia ra được 167,77216 ms. Mỗi lượt chở 6 tệp, tức 256,00 KiB, mất 20,97 ms.
Cộng lại là 1,97 giây, trong đó 91,47% là chờ đường truyền và chỉ 8,53% là chờ dữ liệu.
Con số cuối làm rõ chuyện nhà mạng bán gì và bạn nhận gì. Chia tổng số byte cho tổng thời gian, băng thông hiệu dụng của trang này là 8,53 Mbps. Bạn trả tiền cho 100 Mbps và nhận về chưa tới một phần mười, không phải vì nhà mạng gian, mà vì 91,47% thời gian đường truyền của bạn đang rỗng: nó đang chờ tín hiệu đi và về. Đây không phải trùng hợp mà là một đẳng thức: băng thông hiệu dụng luôn đúng bằng băng thông danh nghĩa nhân với tỉ lệ thời gian thật sự dùng để truyền.
Độ trễ khác băng thông, và mốc giao nhau
Đây là mục đáng đọc kỹ nhất của bài.
Nhìn lại hai công thức. Phần độ trễ là dns + số vòng × RTT: trong đó không có kích thước trang. Phần băng thông là số byte / tốc độ: trong đó không có độ trễ. Hai công thức không dùng chung biến nào cả, nên nâng băng thông chỉ bóp được đúng một trong hai, và bóp bao nhiêu cũng không chạm được cái kia.
Bảng thang băng thông trong khung nói ra điều đó bằng hình ảnh: cột phần độ trễ giữ nguyên 1.800 ms ở cả bốn dòng, từ 10 Mbps tới 10.000 Mbps. Đường gấp nghìn lần chỉ hạ tổng thời gian từ 3,48 giây xuống 1,80 giây, và không bao giờ xuống dưới 1.800 ms được.
Cụ thể hơn, bấm thử bảng so sánh:
- băng thông ×10, từ 100 lên 1000 Mbps: tổng còn 1,82 giây, tức nhanh hơn 1,08 lần;
- độ trễ một chiều ÷2: tổng còn 1,08 giây, tức nhanh hơn 1,83 lần.
Cùng một trang, cùng một cái chờ, mà cắt đường xa đi một nửa ăn tiền hơn nhiều so với mua đường dày gấp mười.
Nhưng đừng đảo ngược thành một câu khẩu hiệu, vì nó chỉ đúng với trang nhiều tệp nhỏ. Bấm sang preset một tệp 500 MiB trên cùng đường truyền xa đó: tổng thời gian là 42,50 giây, trong đó phần độ trễ chỉ còn 1,30%. Lần này băng thông ×10 nhanh hơn 8,95 lần, còn độ trễ ÷2 chỉ nhanh hơn 1,01 lần. Đúng hai phép thay đổi ấy, đảo hẳn kết luận.
Vậy ranh giới ở đâu? Nó tính được, không phải cảm giác. Đặt phần độ trễ bằng phần băng thông thì kích thước trang tự hiện ra:
kích thước tại mốc = phần độ trễ × tốc độ
= 1.800 ms × 12.500.000 byte/giây ÷ 1000
= 22.500.000 byte = 21.972,66 KiB = 21,46 MiB
Dưới 21,46 MiB thì độ trễ áp đảo, trên 21,46 MiB thì băng thông áp đảo. Trang mở bài nặng 2,00 MiB, tức nhẹ hơn mốc gần 11 lần, nên nó nằm sâu trong vùng độ trễ quyết định. Trong khung có nút về đúng mốc giao nhau: bấm nó để đặt kích thước trang vào đúng chỗ đó, và bạn sẽ thấy hai con số bằng nhau tới từng chữ số, cách biệt đúng 0.
Mốc này không phải hằng số. Nó tỉ lệ thuận với băng thông và tỉ lệ thuận với phần độ trễ, nên:
- nâng băng thông lên 1000 Mbps thì mốc nhảy lên 214,58 MiB, tức vùng "độ trễ quyết định" rộng ra chứ không hẹp lại. Đường càng dày thì càng nhiều trang rơi vào vùng mà độ dày không giúp gì;
- đưa máy chủ về trong nước thì mốc tụt xuống 3,10 MiB, tức nhiều trang thoát ra khỏi vùng đó.
Nói cách khác: cứ nâng băng thông thì cái nút thắt càng dịch về phía độ trễ. Đó là lý do các trang lớn bỏ tiền vào việc đặt máy chủ gần người dùng và giảm số tệp, chứ không phải chỉ mua thêm đường.
Vì sao mạng nhà rất nhanh mà trang nước ngoài vẫn chậm
Ba nguyên nhân, và cả ba đều đo được.
Thứ nhất, tốc độ tín hiệu là có hạn. Ánh sáng trong chân không đi 299.792,458 km mỗi giây, con số này chính xác vì nó là định nghĩa của đơn vị đo. Trong lõi thuỷ tinh của cáp quang, ánh sáng chậm lại theo chiết suất, khoảng 1,47 lần. Chia ra: tín hiệu đi được khoảng 203,94 km mỗi milli giây. Nhớ một con số này là đủ để tự ước lượng mọi thứ còn lại.
Với 15.000 km cáp, mức sàn là 15.000 / 203,94 = 73,55 ms một chiều, tức 147,10 ms cho một vòng đi về. Cùng khoảng cách đó, nếu đi trong chân không thì chỉ mất 50,03 ms, nhưng bạn không có sợi chân không nào để dùng. Đây là mức sàn theo nghĩa chặt: không nhà mạng nào, không gói cước nào, không thiết bị nào đi nhanh hơn được. Còn 800 km, cỡ Đà Nẵng đi Hà Nội, thì mức sàn chỉ 3,92 ms một chiều, nhỏ hơn gần hai mươi lần.
Khung có nút lấy mức sàn làm độ trễ một chiều: bấm nó là bạn đang xem trường hợp lý tưởng tuyệt đối, và sẽ thấy tổng thời gian vẫn còn rất lớn.
Thứ hai, mỗi chặng router thu một khoản. Gói tin của bạn không bay thẳng tới máy chủ. Nó nhảy qua bộ định tuyến của nhà, của nhà mạng, của các nhà mạng trung gian, có thể vài chục chặng. Mỗi chặng phải đọc gói, quyết định gửi đi đâu, và có thể phải đợi trong hàng. Trong khung, 14 chặng mỗi chặng 1 ms cộng thêm 14 ms mỗi chiều, tức 28 ms mỗi vòng. Không nhiều so với 150 ms của khoảng cách, nhưng nó cộng dồn qua 10 vòng.
Thứ ba, và đây là chỗ ăn nhiều nhất, số vòng. So hai preset đầu để thấy rõ: đúng một trang đó, đúng băng thông đó, chỉ đổi khoảng cách và số chặng thì vòng đi về từ 178 ms xuống 24 ms, phần độ trễ từ 1.800 ms xuống 260 ms, và tổng thời gian từ 1,97 giây xuống 427,77 ms. Nhanh hơn khoảng 4,6 lần mà không đổi một chút băng thông nào. Băng thông hiệu dụng lên 39,22 Mbps.
Lý do là mỗi vòng bị nhân lên. Cắt 154 ms khỏi một vòng nghe nhỏ, nhưng trang này trả 10 vòng, nên nó thành hơn một giây rưỡi. Đây cũng là lý do hai kỹ thuật rất tầm thường lại hiệu quả tới vậy:
- dùng lại kết nối. Tắt ô đó trong khung: mỗi lượt phải bắt tay lại, số vòng nhảy từ 10 lên 24, phần độ trễ lên 4.292 ms và tổng thành 4,46 giây. Chỉ riêng việc giữ kết nối đã tiết kiệm 2.492 ms;
- giảm số tệp. Mỗi lượt hỏi là một vòng. Gộp 48 tệp lại còn ít hơn thì bớt được lượt, mà tổng số byte không đổi một chút nào.
HTTPS bảo vệ cái gì, và không bảo vệ cái gì
Chặng ba ở trên tốn một vòng, tức 178 ms trong kịch bản mặc định. Tắt ô https trong khung là thấy: phần độ trễ tụt từ 1.800 xuống 1.622 ms. Cái giá đó đổi được gì?
HTTPS bảo vệ ba thứ. Một, nội dung: mọi thứ bạn gửi lên và nhận về đều được mã hoá, gồm mật khẩu, số thẻ, nội dung tin nhắn, đường dẫn cụ thể trong trang. Ai đứng giữa đường cũng chỉ thấy một khối byte vô nghĩa. Hai, tính nguyên vẹn: không ai sửa được nội dung trên đường mà không bị phát hiện, nên nhà mạng hay chủ quán cà phê không chèn quảng cáo vào trang bạn đang xem. Ba, danh tính máy chủ: chứng thư số chứng minh bạn đang nói chuyện với đúng tên miền đó chứ không phải một máy giả mạo cùng địa chỉ.
Và đây là những thứ HTTPS không bảo vệ.
- Việc bạn đã vào trang nào. Tên miền vẫn lộ ra ở chặng phân giải tên miền và ở phần chào đầu của cuộc bắt tay, cộng với địa chỉ số của máy chủ. Nên Wi-Fi quán cà phê biết bạn vừa mở trang của một ngân hàng, chỉ không biết bạn làm gì trong đó.
- Sự tử tế của đầu bên kia. Cái ổ khoá nói rằng đường truyền kín, chứ không nói người nhận là người tốt. Một trang lừa đảo hoàn toàn có thể có ổ khoá hợp lệ, vì chứng thư số bây giờ xin rất dễ và miễn phí. Thấy ổ khoá rồi nhập mật khẩu ngân hàng vào một tên miền lạ là gửi mật khẩu cho kẻ lừa đảo một cách rất an toàn.
- Chính máy của bạn. Mã độc trên máy bạn thấy mọi thứ trước khi nó được mã hoá. HTTPS không cứu được một máy đã nhiễm.
- Chuyện xảy ra sau khi dữ liệu tới. Trang web nhận được dữ liệu rồi làm gì với nó, bán cho ai, giữ bao lâu, HTTPS không có ý kiến gì.
- Dấu vết về lưu lượng. Ai đứng giữa vẫn thấy bạn gửi bao nhiêu byte và vào lúc nào, và riêng chuyện đó đã nói ra khá nhiều.
Rút lại thành một câu để nhớ: ổ khoá nói đường truyền kín, không nói đầu bên kia đáng tin. Việc phải kiểm luôn là tên miền, đọc từ phải sang trái, chứ không phải cái ổ khoá.
Cái chờ khi mở một trang web gồm hai phần không dùng chung biến nào: phần độ trễ bằng dns + số vòng × RTT và không chứa kích thước trang, phần băng thông bằng số byte / tốc độ và không chứa độ trễ. Nên tồn tại đúng một kích thước trang mà tại đó hai phần bằng nhau, và nó tính được: độ trễ × tốc độ. Ở kịch bản mở bài mốc đó là 21,46 MiB, còn trang thật chỉ 2,00 MiB, nên 91,47% thời gian là chờ đường truyền và nâng băng thông gấp mười chỉ nhanh hơn 1,08 lần. Đổi sang một tệp 500 MiB thì đúng phép nâng ấy cho 8,95 lần: câu trả lời phụ thuộc bạn đang ở phía nào của mốc. Khoảng cách thì không thương lượng được, vì tín hiệu chỉ đi 203,94 km mỗi milli giây trong cáp quang. Cuối cùng, HTTPS mua được sự kín của đường truyền bằng một vòng đi về, chứ không mua được sự tử tế của đầu bên kia.
Nói cho đúng: mọi con số ở trên là số của mô hình trong khung, và mô hình bỏ qua nhiều thứ chỉ làm chậm thêm, ví dụ TCP chưa đạt tốc độ tối đa ngay, máy chủ cần thời gian suy nghĩ, gói tin có thể mất. Nên hãy dùng chúng để so hai phương án với nhau, đừng dùng để dự báo bạn sẽ chờ đúng bao nhiêu giây.
Tự kiểm
- 1Trang của bạn nặng 2 MiB gồm 48 tệp nhỏ, máy chủ ở rất xa, và phần chờ đường truyền chiếm 91,47% thời gian. Bạn có tiền để làm đúng một việc. Việc nào giảm thời gian tải nhiều nhất?
- 2Với một đường 100 Mbps và phần chờ đường truyền 1.800 ms, kích thước trang nào làm hai phần bằng nhau?
- 3Bạn dùng Wi-Fi công cộng, mở một trang có ổ khoá HTTPS và nhập mật khẩu ngân hàng. Điều nào sau đây là đúng?