Kiến thức nền

Liên quan

Bản thiết kế · 1.807 từ · 8 phút đọc

Tại sao TCP được tách thành TCP và IP

TCP gốc là một giao thức làm định tuyến, độ tin cậy, và địa chỉ cùng một lúc. Lập luận năm 1978 của Jon Postel để tách nó thành hai đã mở khóa UDP, video thời gian thực, kiến trúc đồng hồ cát, và gần như mọi thứ đến sau.

Mục lục
  1. TL;DR
  2. Điều TCP gốc năm 1974 làm
  3. Phản đối của Postel
  4. Sự tách
  5. Điều UDP đã mở khóa
  6. Đồng hồ cát kết quả
  7. Phản thực
  8. Điều Postel thực sự thắng

#TL;DR

Khi Vint Cerf và Bob Kahn xuất bản bài báo giao thức năm 1974, nó mô tả một giao thức duy nhất gọi là TCP xử lý địa chỉ, định tuyến, độ tin cậy, và sắp xếp cùng một lúc. Đến năm 1978, Jon Postel — editor RFC sau này trở thành một trong những nhân vật có hậu quả lặng lẽ nhất của internet — đã dành bốn năm tranh luận rằng đây là một sai lầm. Độ tin cậy và định tuyến, ông chỉ ra, không phải cùng vấn đề, và hàn chúng lại với nhau có nghĩa là mọi ứng dụng trên mạng trả giá cho các đảm bảo mà hầu hết chúng không muốn. Postel thắng. Sự tách tạo ra stack phân tầng mà internet vẫn chạy trên — IP ở dưới, TCP và UDP như các truyền riêng biệt ở trên — và làm cho DNS, VoIP, streaming video, game online, và cuối cùng QUIC trở nên có thể.

#Điều TCP gốc năm 1974 làm

Bài báo Cerf và Kahn xuất bản trên IEEE Transactions on Communications tháng 5 năm 1974 — “A Protocol for Packet Network Intercommunication” — mô tả một giao thức làm mọi thứ cần thiết để lấy một thông điệp từ host A đến host B một cách đáng tin cậy qua các mạng trung gian tùy ý.

Giao thức đó xử lý:

  • Địa chỉ. Mỗi host có một định danh duy nhất toàn cầu.
  • Định tuyến. Các gateway giữa các mạng quyết định cách chuyển tiếp các gói.
  • Độ tin cậy. Các gói bị mất được phát lại; các gói không đúng thứ tự được sắp xếp lại; các bản sao bị loại bỏ.
  • Điều khiển luồng. Người gửi chậm lại nếu người nhận bị choáng ngợp.
  • Phân mảnh. Các thông điệp lớn được cắt nhỏ để vừa với mạng nhỏ nhất giữa người gửi và người nhận.

Nó thanh lịch như một phác thảo nghiên cứu. Nó cũng là một đặc tả nguyên khối cố gắng phục vụ mọi trường hợp sử dụng có thể, và đến năm 1977 những người triển khai thấy rằng nhiều trong những trường hợp sử dụng đó không cần mọi thứ TCP cung cấp. Tệ hơn, họ vẫn đang trả giá cho nó.

#Phản đối của Postel

Jon Postel đã biên tập RFC kể từ RFC 40. Đến năm 1977 ông là editor de facto của cả loạt, có nghĩa là ông đọc mọi đề xuất giao thức mà cộng đồng ARPANET sản xuất và có một góc nhìn rõ ràng bất thường về thiết kế nào có xu hướng hoạt động và thiết kế nào không.

Lập luận của Postel, xuất hiện trong một loạt RFC và ghi chú thiết kế năm 1977 và 1978, mang tính cấu trúc:

Định tuyến là tính chất của mạng. Độ tin cậy là tính chất của cuộc trò chuyện.

Chúng chạy ở các khoảng thời gian khác nhau, phục vụ các bên liên quan khác nhau, và thất bại vì các lý do khác nhau. Kết hợp chúng trong một giao thức có nghĩa là:

  • Các ứng dụng không cần độ tin cậy vẫn trả giá cho nó. Một lookup DNS gửi một yêu cầu và mong đợi một phản hồi. Bọc điều đó trong một bắt tay ba bước đầy đủ, logic phát lại, và tháo kết nối là tổn phí vô lý cho một truy vấn duy nhất.
  • Các ứng dụng cần ngữ nghĩa độ tin cậy khác không thể có chúng. Âm thanh thời gian thực thà rớt một gói muộn hơn chờ một lần phát lại làm playback treo.
  • Tầng mạng khó tiến hóa hơn. Mỗi khi bạn muốn thay đổi phương án địa chỉ hoặc định tuyến, bạn chạm vào code độ tin cậy nữa.

Postel đề xuất một phân tầng sạch: một giao thức cho địa chỉ và định tuyến, một giao thức riêng ở trên cho độ tin cậy, và tùy chọn bỏ qua hoàn toàn tầng độ tin cậy cho các ứng dụng không muốn.

#Sự tách

Đến IEN 2, rồi IEN 26, và cuối cùng trong các bản nháp RFC năm 1978 và 1980, TCP duy nhất trở thành ba thứ:

  ┌───────────────────────────────┐
  │            TCP                │   ← đáng tin cậy, có thứ tự, hướng kết nối
  ├───────────────────────────────┤
  │            UDP                │   ← không đáng tin cậy, không thứ tự, bắn-và-quên
  ├───────────────────────────────┤
  │            IP                 │   ← địa chỉ và định tuyến, nỗ lực tốt nhất
  └───────────────────────────────┘
  • IP trở thành tầng mạng. Nó làm địa chỉ (mọi host có địa chỉ IP) và giao hàng nỗ lực tốt nhất. Một gói hoặc đến hoặc không. IP không hứa gì.
  • TCP trở thành một tầng truyền nằm trên IP. Nó thêm độ tin cậy, sắp xếp, trạng thái kết nối, điều khiển luồng, và điều khiển tắc nghẽn. Nếu bạn muốn nghĩ về một kết nối như một luồng byte, TCP là thứ làm cho ảo tưởng đó hoạt động trên IP không đáng tin cậy.
  • UDP trở thành một tầng truyền thay thế, cũng trên IP, nhưng với gần như không có đảm bảo nào của TCP. UDP là một bao bọc mỏng xung quanh IP thêm số cổng (nên nhiều ứng dụng trên cùng host có thể chia sẻ một IP) và một checksum. Thế thôi.

Phần quan trọng của sự tách không chỉ là có hai giao thức trên IP. Đó là các ứng dụng được chọn.

#Điều UDP đã mở khóa

Không có UDP, cả một danh mục các ứng dụng hoặc sẽ không tồn tại hoặc sẽ phải phát minh lại một cơ chế bỏ-qua-TCP từ đầu.

  • DNS — mỗi lookup tên miền là một yêu cầu và phản hồi UDP duy nhất, hoàn thành trong một vòng quay. Chạy DNS trên TCP sẽ gấp ba số vòng quay và gấp bốn số byte trên dây. Root DNS sẽ đã sụp đổ dưới tổn phí TCP vào cuối những năm 1980.
  • VoIP và video thời gian thực — giọng nói và video nhạy cảm với độ trễ, chịu đựng mất. Một gói muộn là vô dụng; bạn thà bỏ qua nó hơn chờ. Hành vi phát lại của TCP chính xác là sai cho trường hợp sử dụng này.
  • Game online — cập nhật trạng thái game đa người chạy trên UDP vì game thà rớt một cập nhật vị trí cũ hơn treo người chơi đang chờ nó.
  • DHCP, NTP, SNMP, TFTP — các giao thức yêu cầu-phản hồi hoặc thông báo đơn giản vừa trong một gói duy nhất. TCP sẽ quá mức cần thiết.
  • Multicast và broadcast — TCP là một cuộc trò chuyện điểm-tới-điểm. Gửi cùng gói đến nhiều người nhận cùng lúc yêu cầu mô hình không-kết-nối của UDP.

UDP đơn giản về mặt cấu trúc hơn TCP vì nó không hứa gì. Đó cũng là lý do nó có thể làm những thứ TCP không bao giờ có thể.

#Đồng hồ cát kết quả

Sự tách tạo ra thứ các nhà thiết kế Internet Protocol bắt đầu gọi là mô hình đồng hồ cát — một sơ đồ nắm bắt tại sao internet có thể mở rộng và tiến hóa theo những cách các mạng trước không thể.

    HTTP  SSH  SMTP  DNS  QUIC  WebRTC  ...  ← nhiều giao thức ứng dụng
         ╲   │   │   │   │    ╱
           ╲ │   │   │   │  ╱
    ┌──────────────────────────┐
    │      TCP   UDP   ...     │              ← một vài giao thức truyền
    ├──────────────────────────┤
    │           IP             │              ← MỘT giao thức mạng
    ├──────────────────────────┤
    │      TCP   UDP   ...     │
    │                          │
    └──────────────────────────┘
         ╱   │   │   │   │   ╲
       ╱     │   │   │   │     ╲
  Ethernet  Wi-Fi  4G  5G  cáp quang  vệ tinh  ← nhiều tầng liên kết

Một giao thức ở eo hẹp — IP — và sự đa dạng tùy ý ở trên và dưới. Tầng liên kết có thể thay đổi (Ethernet, Wi-Fi, 4G, LTE, 5G) mà không phá vỡ các ứng dụng. Các giao thức ứng dụng mới có thể được phát minh (HTTP, WebRTC, QUIC) mà không chạm mạng. Điều duy nhất bạn không thể thay đổi, mà không thay đổi mọi thứ, là chính IP.

Đây là lý do IPv6 đã mất ba mươi năm để triển khai. Thay đổi eo hẹp đắt về mặt cấu trúc. Mọi tầng khác đều rẻ.

#Phản thực

Điều gì sẽ xảy ra mà không có sự tách?

Chúng ta có thể nhìn vào nỗ lực tiêu chuẩn cạnh tranh OSI của ISO để có câu trả lời một phần. OSI giữ một stack béo hơn nhiều — bảy tầng, với quản lý phiên, mã hóa trình bày, và các tính năng ứng dụng tất cả được đặc tả ở tầng mạng. OSI là kế vị chính thức, được chính phủ ban phước cho các giao thức ARPANET trong hầu hết những năm 1980.

OSI thua dứt khoát. Một lý do trong số nhiều là các tầng của nó được ghép quá chặt. Bạn không thể xuất xưởng một thay đổi nhỏ. Bạn không thể chạy một giao thức ứng dụng không-chuẩn trên một tầng truyền chuẩn. Đến khi các đặc tả được phê chuẩn, TCP/IP — lặp lại tự do qua các RFC trên stack phân tầng — đã vượt qua chúng.

Sự tách cũng cho phép nguyên tắc đầu cuối đến đầu cuối giữ vững. Nếu TCP không thể tách khỏi IP, các tính năng như mã hóa, điều khiển tắc nghẽn, và độ tin cậy sẽ là các mối quan tâm của tầng mạng — được nung vào các router, không thể tiến hóa mà không thay thế phần cứng. Vì TCP sống ở các điểm cuối và IP mỏng, đổi mới đầu-cuối-đến-đầu-cuối vẫn rẻ.

#Điều Postel thực sự thắng

Bài viết TCP/IP tóm tắt sự tách trong một đoạn. Điều dễ bỏ lỡ là bao nhiêu kiến trúc xuôi dòng phụ thuộc vào nó:

  • TLS tồn tại vì có một sự chuyển giao sạch từ TCP sang một phương án mã hóa tầng ứng dụng. Một TCP-với-bảo-mật nguyên khối sẽ khó tiến hóa hơn nhiều.
  • QUIC tồn tại vì UDP vẫn ngu và không có ý kiến. Xây dựng một truyền đáng tin cậy mới trên UDP là có thể chính xác vì UDP không hứa gì. Bạn không thể xây dựng một truyền mới trên TCP; TCP đã có ý kiến suốt xuống.
  • Cân bằng tải ở quy mô đám mây hoạt động vì trạng thái kết nối sống ở các điểm cuối. Một bộ cân bằng tải L4 có thể di chuyển một luồng TCP giữa các backend mà không cần hiểu TCP nội bộ.
  • IPv6 có thể triển khai được vì thay đổi tầng mạng không yêu cầu thay đổi tầng truyền. TCP và UDP chạy trên IPv4 và IPv6 với các điều chỉnh nhỏ.

Bản năng của Postel là độ tin cậy và định tuyến là các vấn đề khác nhau được phục vụ bởi các mối quan tâm khác nhau và nên được mã hóa riêng biệt. Ngành công nghiệp đã dành năm mươi năm tiếp theo xác nhận bản năng đó, không phải bằng cách tranh luận về nó, mà bằng cách khám phá rằng mọi hệ thống mới họ muốn xây dựng đều dễ hơn nhờ nó.

Năm 1978, tách một giao thức thành ba trông như một dọn dẹp nhỏ. Hóa ra nó là quyết định đã làm cho internet tiếp tục tiến hóa.