Kiến thức nền

Liên quan

Xưởng · 1.589 từ · 7 phút đọc

RFC 1: Tài liệu đã phát minh ra quản trị Internet

Steve Crocker viết RFC 1 trong nhà tắm vào ban đêm vì anh không muốn nghe có vẻ chuyên quyền. Tài liệu rụt rè mà anh tạo ra đã trở thành khuôn mẫu cho mọi tiêu chuẩn internet sau này.

Mục lục
  1. TL;DR
  2. Tình huống tháng 4 năm 1969
  3. Nhà tắm, bồn tắm, và tiêu đề
  4. Nội dung thực sự của RFC 1
  5. Điều RFC 1 đã khởi động
  6. Tai nạn quản trị
  7. Tài liệu không phải là một mệnh lệnh

#TL;DR

Tháng 4 năm 1969, một nghiên cứu sinh 24 tuổi của UCLA tên Steve Crocker đã viết một ghi chú ba trang mô tả một số ý tưởng mà nhóm phần mềm host của ARPANET đang thảo luận. Anh đặt tên là “Request for Comments” — không phải Specification (Đặc tả), không phải Standard (Tiêu chuẩn) — vì anh sợ rằng một “đặc tả” do một nghiên cứu sinh viết sẽ xúc phạm các nhà nghiên cứu cao cấp. Cái tên rụt rè đó đã được giữ lại. Năm mươi bảy năm và gần 10.000 tài liệu sau, mọi giao thức quan trọng trên internet — TCP, IP, SMTP, HTTP, DNS, TLS, QUIC — đều được định nghĩa qua cùng quy trình mà một nghiên cứu sinh đầy lo âu đã phát minh ra để không nghe có vẻ độc đoán.

#Tình huống tháng 4 năm 1969

Mạng ARPANET bốn nút vẫn còn tám tháng nữa mới đi vào hoạt động. BBN đang xây dựng các IMP. Các đường dây đang được lắp đặt. Nhưng chưa ai quyết định cách các máy tính host — SIGMA 7 của UCLA, SDS 940 của SRI, IBM 360/75 của UCSB, PDP-10 của Utah — sẽ thực sự nói chuyện với nhau qua mạng mới.

ARPA chưa chỉ định ủy ban nào. Không có nhóm làm việc chính thức. Chỉ có một nhóm lỏng lẻo các nghiên cứu sinh từ bốn địa điểm đã gặp gỡ không chính thức, brainstorm các giao thức có thể. Họ tự gọi mình là Network Working Group (NWG).

Ai đó cần viết xuống những gì họ đã thảo luận. Crocker tình nguyện, rồi ngay lập tức bắt đầu lo lắng.

#Nhà tắm, bồn tắm, và tiêu đề

Crocker đã kể câu chuyện này nhiều lần sau đó. Anh đang ở nhà một người bạn. Bạn cùng phòng đang ngủ. Anh muốn làm việc mà không làm phiền ai, nên anh lấy sổ tay và vào nhà tắm viết vào ban đêm dưới ánh sáng không làm phiền người khác.

Sự lo âu là có cấu trúc. Crocker 24 tuổi. Anh không có tư cách gì để ban hành đặc tả cho một lĩnh vực đầy các nhà nghiên cứu cao cấp từ nửa tá tổ chức. Nếu anh viết “Đặc tả phần mềm host” hay “Tiêu chuẩn giao thức ARPANET,” mọi người ở Harvard và MIT hoàn toàn có lý do để hỏi anh nghĩ mình là ai.

Nên anh làm cho nó nhẹ nhàng hơn. Mọi đoạn văn đều dè dặt. Tiêu đề làm cho toàn bộ tài liệu rõ ràng chỉ là tạm thời:

Request for Comments 7 tháng 4, 1969 Host Software Stephen D. Crocker UCLA

Cách đóng khung này là một động thái kỹ thuật xã hội. Bạn không thể phản đối ai đó đang yêu cầu ý kiến. Và khi các ý kiến đến, mọi người đã đóng góp đều ngầm trở thành người tham gia. Một đặc tả áp đặt. Một Request for Comments mời gọi. Năm mươi năm quản trị internet đã dựa vào sự khác biệt đó.

#Nội dung thực sự của RFC 1

Đọc hôm nay, RFC 1 là một tài liệu lạ. Nó không phải thiết kế của một giao thức — nó là thiết kế của một cuộc trò chuyện về một giao thức. Nó đề xuất một số điều không tồn tại được, phác thảo một số ý tưởng vẫn còn với chúng ta, và để mở hầu hết các câu hỏi thực sự một cách có chủ ý.

Nôm na, tài liệu lập luận:

  • Giao tiếp host-to-host nên được phân tầng. Có subnet IMP bên dưới, do BBN cung cấp, và có phần mềm host bên trên. Hai phần nên được tách biệt rõ ràng.
  • Mỗi host nên chạy một chương trình gọi là Network Control Program quản lý các kết nối với các host khác.
  • Các kết nối nên là song công đầy đủ, được xác định bởi một cặp socket được đặt tên. Các mục đích cao cấp hơn — đăng nhập từ xa, truyền tệp — sẽ chạy như người dùng của kết nối cơ bản đó.
  • Nên có sự phân biệt giữa kết nối chính (ngắn, hướng điều khiển) và kết nối phụ (dài, nặng dữ liệu). Sự tách biệt này tồn tại ngắn ngủi trong NCP ban đầu và sau đó bị loại bỏ.
  • Điều khiển luồng quan trọng nhưng không được đặc tả ở đây. Ai đó nên viết RFC tiếp theo về điều đó.

Phần quan trọng không phải nội dung kỹ thuật — phần lớn trong đó đã sai, và đã bị thay thế trong vòng một năm bởi các RFC tiếp theo và cuối cùng bởi TCP/IP. Phần quan trọng là định dạng: một tài liệu có ngày, được đánh số, có chữ ký, đề xuất, giải thích, và mời phản hồi.

#Điều RFC 1 đã khởi động

Network Working Group tiếp tục viết. Đến cuối năm 1969, họ đã tạo ra khoảng 20 RFC. Đến năm 1971, con số lên hàng trăm. Mỗi cái được xây trên hoặc thay thế một cái trước đó. Các quy tắc của thể loại này cứng lại một cách tự nhiên:

  • Được đánh số tuần tự, không bao giờ tái sử dụng. RFC 3 làm cho RFC 2 lỗi thời; RFC 2 ở lại trong kho lưu trữ. Không có gì bị xóa. Đây là cách tập đặc tả internet trở thành một bản ghi phân tầng về sự tiến hóa của chính nó — bạn vẫn có thể đọc RFC 821 (SMTP gốc, 1982) bên cạnh RFC 5321 (bản thay thế của nó, 2008).
  • Bất cứ ai cũng có thể viết một cái. RFC được biên tập, không bị kiểm soát cổng bởi tổ chức. Pat Lyall tại một công ty điện thoại, một nghiên cứu sinh tại Berkeley, và một kỹ sư Cisco đều trải qua cùng quy trình đánh giá.
  • Văn bản thuần, không đánh dấu. Cho đến gần đây, RFC là ASCII 72 cột, để đọc được trên bất kỳ terminal nào. Ràng buộc đó đã mất giờ đây, nhưng văn hóa “một tệp, không phụ thuộc, đọc được mãi mãi” vẫn còn.
  • “Chúng tôi từ chối các vị vua, tổng thống, và việc bỏ phiếu. Chúng tôi tin vào đồng thuận thô và code đang chạy.” Dòng đó — từ Dave Clark tại một cuộc họp IETF năm 1992 — trở thành hiến pháp de facto của IETF. Một tiêu chuẩn được hoàn thiện khi đủ những người triển khai đồng ý và ít nhất hai triển khai tương thích tồn tại.

#Tai nạn quản trị

RFC 1 vô tình giải quyết một vấn đề mà các cơ quan tiêu chuẩn đã thất bại trong suốt một thế kỷ. Các tiêu chuẩn viễn thông quốc tế, được duy trì bởi cái giờ là ITU, là đối lập của mô hình Crocker: chính phủ cử đại biểu, tài liệu được viết song song bằng tiếng Pháp và tiếng Anh, phê chuẩn mất nhiều năm, và các đặc tả kết quả tốn tiền để đọc. Các nhà cung cấp triển khai những gì họ muốn và gọi nó là tuân thủ.

Quy trình RFC là ngược lại:

  • Miễn phí đọc, miễn phí trích dẫn, miễn phí triển khai.
  • Từ dưới lên, được thúc đẩy bởi bất cứ ai quan tâm đủ để xuất hiện.
  • Tăng dần — một RFC đề xuất một thay đổi nhỏ có thể trở thành tiêu chuẩn trong vài tháng.
  • Ưu tiên triển khai — nếu code không chạy, RFC không được công bố.

Khi ISO sau đó cố gắng tiêu chuẩn hóa stack mạng bảy tầng của riêng mình (mô hình OSI) qua quy trình từ trên xuống truyền thống, nó đã thua toàn diện trước TCP/IP, thứ đã lặp đi lặp lại qua các RFC trong một thập kỷ vào lúc OSI ra mắt. Mô hình OSI giờ chủ yếu tồn tại như một công cụ giảng dạy. Mô hình RFC vận hành internet.

#Tài liệu không phải là một mệnh lệnh

Mẹo của RFC 1 — lý do cách diễn đạt của Crocker vẫn chi phối — là nó từ chối yêu cầu thẩm quyền mà nó không có. “Request for Comments” là một thể loại được xây cho những người đóng góp sau này sẽ hóa ra là sai. Nó sống sót qua việc sai một cách duyên dáng. Một đặc tả có thể bị vi phạm. Một request for comments chỉ có thể bị thay thế.

Đó hóa ra là thiết kế đúng cho một quy trình tiêu chuẩn sẽ cần tiếp tục tiến hóa qua năm mươi năm, sáu thế hệ phần cứng, và tăng quy mô chín bậc độ lớn. Bạn không thể biết câu trả lời đúng trước khi bạn đang thiết kế thứ sẽ chạy trên mọi thứ từ một Honeywell 900 pound đến một máy điều nhiệt thông minh. Bạn có thể biết cách giữ cho cuộc trò chuyện tiếp tục.

Bài viết ARPANET coi RFC 1 như một giai thoại thú vị về một nghiên cứu sinh lo lắng. Nó cũng là mục đầu tiên trong tập tiêu chuẩn thành công nhất trong lịch sử kỹ thuật — và là tài liệu quản trị duy nhất trong danh sách này được viết, một cách có chủ ý, để không nghe như một tài liệu quản trị.