第七層負載平衡（layer-7 load balancing）
想像兩種替進來的郵件分類的方式。一位動作快的櫃員只看信封外面的地址就把每封信分流——很快，但對裡面的內容一無所知。一位較慢、較聰明的櫃員則拆開每封信、讀信、再依主題分流——到帳務、到客服、到業務。第七層負載平衡就是那位較聰明的櫃員。它實際讀取應用層內容（HTTP 請求本身）來分配請求，而不是像第四層平衡那樣只看傳輸層的位址與連接埠。
因為它懂 HTTP，第七層平衡器能做以內容為基礎的路由決策：把對 /images/* 的請求送往圖片伺服器、把 /api/* 送往 API 伺服器；依 Host 標頭路由，讓許多網站共用一台平衡器；讀取工作階段 Cookie 把使用者固定在某一台後端；或為 A／B 測試切分流量。為了做到這些，它終結用戶端的 TCP（與 TLS）連線、剖析請求，再開啟自己對所選後端的連線——所以它以完整中間者的身分存在，也能改寫標頭、壓縮、快取、並保護後端。相對地，第四層平衡按 IP 與連接埠轉送整條連線而不檢查內部：較快且與協定無關，卻無法依 URL 或 Cookie 路由。
為什麼重要：第七層是現代網路負載平衡大多發生的地方，正因為「依應用內容路由」是微服務與多站台代管所需要的。這也是反向代理與 CDN 邊緣派發請求時用的同一種智慧。取捨是誠實的：讀取每個請求比第四層的盲目轉送多花 CPU 與一點延遲，且終結 TLS 意味著平衡器會看到解密後的流量，使它成為一個受信任、對安全敏感的點。當你需要原始速度與協定獨立性時選第四層；當你需要依「請求實際說了什麼」來路由時選第七層。
一台第七層平衡器作為整個平台的前端。對 /video/ 的請求被路由到串流叢集、/checkout/ 到金流叢集、而 Host 標頭為 blog.example.com 的請求到部落格伺服器——全都來自檢查那個 HTTP 請求。
依「請求說了什麼」路由，而不只是「它被定址到哪裡」。
第七層並非絕對優於第四層——它能力更強，但較重。對非 HTTP 協定或追求最大吞吐量時，第四層平衡常是對的工具；這些層是選擇，不是品質的高下排序。