> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 波斯特爾定律

> 波斯特爾定律（健壯性原則）要求實作嚴格發送、寬容接收以互通。了解RFC淵源與現代安全邊界。

<Info>
  **類別**：定律<br />
  **類型**：網路／系統互操作性原則<br />
  **來源**：喬恩·波斯特爾；TCP 規範（如 **RFC 793**，**1981**）<br />
  **別名**：健壯性原則
</Info>

<Note>
  **快速回答** — **波斯特爾定律**（Postel's Law）即健壯性原則：**發送時保守，接收時寬容**（不同文獻措辭略異）。它幫助早期網際網路協定在實作不完美時仍能互通。今天它仍是設計啟發式，也備受爭議——因為寬容若不與安全審查配對，可能固化缺陷並擴大攻擊面。
</Note>

## 什麼是波斯特爾定律？

**波斯特爾定律**（Postel's Law）給協定實作一條指引：**發出的位元組嚴格符合規範**，但在仍能恢復語意時**對輸入解析更寬容**。目標是規範演進、實作各異時的互操作。它與 [康威定律](/zh-hant/laws/conways-law)（系統結構映射協作結構——維度不同）相鄰；與 [布魯克斯定律](/zh-hant/laws/brookss-law)（加人增協調成本——正交，但都影響交付）可對照。不同於 [墨菲定律](/zh-hant/laws/murphys-law)，波斯特爾是**規範性**原則，而非宿命論。

> 發送嚴謹、接收包容曾撐起早期網路——直到模糊性變成可利用面。

### 波斯特爾定律的三層理解

* **入門**：舊客戶端可能送來古怪空白；伺服器仍可拒絕非法訊框，但對無害差異可正規化處理。
* **實踐者**：輸出走**規範編碼**；輸入用**白名單**校驗、記錄異常並顯式版本化行為。
* **進階**：把寬容當作**安全預算**——當代討論警告「按 bug 互通」會在生態裡固化漏洞。

## 起源

**喬恩·波斯特爾**在早期 TCP/IP 工作中提出健壯性原則。廣泛引用的表述見於 **RFC 793**（《傳輸控制協定》，**1981 年 9 月**），要求 TCP 實作在發送行為上保守、在符合規範意圖的前提下對接收分段保持健壯。措辭在後續文件中有演變，但**嚴格生成與寬容消費成對出現**成為協定、解析器與 API 工程的底層俗語。

## 核心要點

用波斯特爾最大化相容性——再測量寬容何時傷害安全。

<Steps>
  <Step title="互通優先">
    異構廠商與部分部署需要寬容的接收端，網路才可用。
  </Step>

  <Step title="輸出走規範形">
    「保守發送」把複雜度集中到經過充分測試的編碼器。
  </Step>

  <Step title="寬容需要邊界">
    沒有模式、模糊測試與監控，寬容解析易成漏洞溫床。
  </Step>

  <Step title="生態效應主導">
    一旦多數對等端依賴怪癖，修復需要協同變更——**按 bug 相容**的壓力。
  </Step>
</Steps>

## 應用場景

映射到現代 API 與平台設計。

<CardGroup cols={2}>
  <Card title="協定與解析器" icon="network-wired">
    發出嚴格的 JSON 或 protobuf；接收層用驗證**儘早拒絕**含糊或過大輸入。
  </Card>

  <Card title="Web 前端" icon="desktop">
    儲存時正規化使用者輸入；渲染仍要**跳脫**——寬容體驗不是 SQL 注入赦免。
  </Card>

  <Card title="協作規範" icon="users">
    你對外承諾要精確；對同事表述方式可在約定標準內保留善意彈性。
  </Card>

  <Card title="向後相容" icon="clock-rotate-left">
    API 顯式版本化；用公布時間表廢棄寬容路徑，而非默默永遠相容怪癖。
  </Card>
</CardGroup>

## 經典案例

該原則的制度錨點是文本：**RFC 793**（1981）把 TCP 的健壯性指引寫進必須共存的廠商實作——可引用的 **RFC 編號與年份**，而非實驗室指標。後續工程討論（包括 **2000–2020 年代** ACM *Queue* / *Communications of the ACM* 等）反思寬容是否固化了互通 bug——指標是爭論從「能否連上」轉向「安全不變量在寬容預設時是否成立」。

## 邊界與失效場景

**邊界 1：安全打破天真寬容**\
攻擊者會在解析器「猜意圖」之處構造歧義輸入。

**邊界 2：標準已成熟**\
現代協定常偏好顯式失敗，而非靜默修復。

**常見誤用**：無限寬容且無遙測——怪癖成刪不掉的遺產。

## 常見誤區

把慷慨與放任分開。

<AccordionGroup>
  <Accordion title="誤區：要友好就全收">
    **實情**：寬容解析仍拒絕非法狀態；善意受安全與規範意圖約束。
  </Accordion>

  <Accordion title="誤區：波斯特爾禁止嚴格校驗">
    **實情**：保守發送常與分層校驗配對（語法／語意）。
  </Accordion>

  <Accordion title="誤區：已過時">
    **實情**：權衡演變；生態仍需互通之處仍有其影。
  </Accordion>
</AccordionGroup>

## 相關概念

在相容與正確之間取捨時一併閱讀。

<CardGroup cols={3}>
  <Card title="康威定律" icon="sitemap" href="/zh-hant/laws/conways-law">
    系統結構映射溝通結構——協調定義了「相容」的意義。
  </Card>

  <Card title="布魯克斯定律" icon="users" href="/zh-hant/laws/brookss-law">
    加人增溝通成本——修復遺產怪癖也耗時間。
  </Card>

  <Card title="墨菲定律" icon="triangle-exclamation" href="/zh-hant/laws/murphys-law">
    可能出錯終會出錯——校驗要據此設計。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  對外發出走規範形；對接收做校驗——設明限與指標，而非無限猜測。
</Tip>