端口與TCP/UDP協議的重點知識

每當看到有人的簡歷上寫著熟悉 tcp/ip, http 等協議時, 我就忍不住問問他們: 你給我說說, 端口是啥吧! 可惜, 很少有人能說得讓人滿意... 所以這次就來談談端口(port), 這個熟悉的陌生人.

在此過程中, 還會談談間接層, naming service 等概念, IoC, 依賴倒置等原則以及 TCP 協議的一些重點知識.

常見端口

在我們的日常開發過程中, 特別是后端的開發人員, 即便他沒有真正理解端口的細節, 他還是會聽過見過各類的端口, 這個東西幾乎無處不在,?

比如:

mysql 缺省用的 3306 端口,

redis 的 6379 端口,

tomcat 默認用的 8080 端口,

ssh 用的 22 端口,

等等...

當然我們最關注的還是 web 相關的端口, 涉及的主要為 80 和 443 兩個端口, 下面就來重點說說.

端口是必須的嗎?

在本地 web 開發調試過程中, 我們可能都碰到過端口, 比如或許是/最著名的 8080 端口, 一般我們會這樣去訪問本地的 web 程序:

localhost:8080

但一旦 web 程序部署到了正式的網站中, 端口似乎就消失了, 正式的網址中就不需要端口了嗎? 答案是否定的, 在這里起作用的是缺省值.

比如你訪問我的網站: https://xiaogd.net, 這個 url 中似乎沒有端口, 但其實是有的, 它有一個默認值 443, 所以完整的形式實際是這樣的:

https://xiaogd.net:443.

你可以通過 Chrome 的開發人員調試工具看到這一點:

可以看到, ip 地址后面跟著一個 443

如果你輸入一個錯誤的端口, 比如 80, 像這樣: https://xiaogd.net:80, 結果就是無法訪問.

但是如果你改成 http://xiaogd.net:80, 它又可以訪問了.

注意, 因為我服務器后臺配置了 http 自動跳轉 https 的 301 重定向, 所以最終瀏覽器會再次跳轉到 https://xiaogd.net:443.

注意勾選 'Preserve log' 以保留日志, 可以看到第一個 80 端口的請求會被響應一個 301 跳轉, 并指示跳轉目標, 也即是 Location 字段中的 https 請求, 瀏覽器接收此跳轉指示并重新發起 https 請求, 也即是圖中第二個 xiaogd.net 的請求. 所以地址欄最終還是會變成 https 的, 特此說明.

此時如果你輸入 http://xiaogd.net:443, 它又不能訪問了...

那么原因是什么呢? 你找到規律了沒有?

注意一個是 http, 一個是 https.

協議的缺省端口

當你沒有顯式的在 url 中輸入端口時, 瀏覽器實際上會根據所用的協議來為你指定一個缺省端口:

如果是 http 協議, 就使用 80 端口

如果是 https 協議, 就使用 443 端口

如果你自己輸入端口呢? 那就用你輸入的端口, 你輸入啥就是啥, 輸錯了, 訪問不了那就是你的責任了, 誰讓你瞎搞來著?

本來不用你勞神的, 你偏要脫褲子放屁, 搞不好自然就是畫蛇添足, 弄巧成拙了.

比如上面的用了 http 卻輸入了 443, 或者用了 https 卻輸入了 80, 就無法成功訪問了.

另外, 如果你胡亂地輸入一個比如 9527, http://xiaogd.net:9527, 自然也是無法訪問的, 原因也很簡單, 因為我的服務器上根本沒有在 9527 端口上進行監聽.

即便我有在 9527 端口上監聽, 提供的也未必是 web 服務, 使用的協議可能既不是 http, 也不是 https, 所以你用瀏覽器試圖去訪問也可能會碰壁的.

當然了, 我是完全可以在服務器上的 9527 端口上再部署一個 web 服務的, 比如放一個 apache 或 tomcat server 之類的 web server 監聽在那個端口上, 再放通防火墻, 安全組之類的, 也是可以訪問的. 只是我沒有這么去做而已.

那么為啥大家都不在那些奇奇怪怪的端口上提供 web 服務呢? 原因其實也很簡單, 為了方便用戶, 同時也減輕了用戶的認知負擔.

其實關于用戶, 你只要記住兩點就好了:

用戶是傻瓜

用戶是懶漢

深刻地理解了這一點, 你才可能成為一個好的程序員(包括但不限于產品經理, 設計師...)

其實呀, 何止了省略了端口呀, 你看看現在的地址欄, 不但 http, https 這些協議省了, 最末尾的斜杠 / 省了, 甚至連 www 都省了...

是的, 我也幫你們省了 www, 事實上你通過 https://www.xiaogd.net/ 也能訪問到, 但如果通過 https://xiaogd.net/ 就能訪問到, 又何苦去再去錄入三個達不溜呢?

必須得承認, 缺省的存在是有很大的幫助的, 這其實是進步; 但另一方面, 這些缺省有時也會給不明就里的開發人員帶來了一些困惑, 好像端口不是必要的, 但其實不是這樣的.

為什么需要端口?

那為什么一定要端口這個東西呢? 它到底起了什么作用, 想必很多同學想要了解, 下面就來說說為什么, 而一個首先需要了解的概念就是進程間通訊(所謂的 IPC(inter-process communication)

進程間通訊(IPC)

你在瀏覽器地址欄輸入某個網站的域名, 然后回車, 就生成了一次請求, 然后服務器響應你的請求, 瀏覽器再把結果渲染出來, 你就能最終看到到一個網頁.

如果你曾經 ping 過一個域名, 比如你現在 ping 我的域名 xiaogd.net, 你就能得到一個 ip 地址, 118.89.55.54:

有了 ip, 瀏覽器自然就能找到我的主機, 但還是有個問題, 我的主機上運行著好多的進程, 好多的服務, 除了最常見的 web 服務, 我可能還有 ftp 服務, mysql 服務等等不一而足.

簡單地講, 如果一個請求只有 ip 地址這一信息, 操作系統將不知道把這個請求交給哪個進程去處理, 如果是你來設計整個系統, 你想象一下, 是不是這樣?

如果你僅僅是輸入域名, 經過 DNS 解析后, 只能得到一個 IP 地址.

所謂的一次請求, 從一個比較底層的角度去看, 就是一次進程間的通訊.

它可以是 navicat 客戶端與 mysql 數據庫服務的一次通訊, 也可以是 winScp 客戶端與 vsftpd FTP 服務的一次通訊等等.

以上面的具體為例, 可以說就是 Chrome 瀏覽器這個本地操作系統上的進程與我的服務器上的一個叫做 Nginx 的進程間的一次通訊.

那么, 所謂的端口, 其實可以簡單地視作為進程 ID.

當然, 它與進程 ID 還是有不同的, 下面再分析, 或者目前你可以認為端口就是進程 ID 的影子.

也即是說, 如果僅有域名(ip), 是無法定位到一個進程的, 通訊的發起方不但需要給出 ip, 還需要給出端口, 只有這樣, 服務器才能知道由哪個進程去響應.

端口, 一個間接層

那么問題又來了, 為什么引入端口, 而不是直接使用進程 ID 呢? 這個原因想想也不難明白, 大概有這么幾點原因:

作為客戶端無法知道服務端對應進程的 ID

服務端對應進程重啟后 ID 會改變

一個網站的 web 進程 ID 是這個, 另一個網站的可能又是另一個

自然, 原因是很多的, 我也是隨便的列舉了一些, 你或許還能想到更多. 而為了解決這些個問題, 就引入了端口這一間接層(indirection).

計算機世界里有一句名言: 任何計算機問題均可通過增加一個間接(indirection)層來解決.(Any problem in computer science can be solved with another layer of indirection. -- David Wheeler)

這個名言其實還有后面一句: But what usually will create another problem.(但通常會帶來另一個問題)

這里所謂另一個問題, 比如它會使得層次結構復雜化, 交互效率下降等等. 當然了, 這就是架構師們要去權衡的問題了, 很多時候, 架構就是關于平衡的藝術. 打死都不肯引入任何的間接層, 這是一個極端; 而一上來就引入好多個間接層, 這又是另一個極端.

如果沒有這個間接層, 客戶端要與服務端通訊, 就要知道服務端對應進程的 ID, 也即是客戶端是依賴于服務端的:

顯然, 這種模式對于 web 這種一個服務端對應大量客戶端訪問的情形是極不適應的, 你都不知道有誰可能會來訪問你的網站! 你根本無法告訴它們.

而有了端口這一間接層, 對于 web 的情形, 這種依賴被倒置了, 客戶端總是把請求發送到 80(或443) 端口, 這些成為標準的一部分, 并要求服務端反過來去適應, 服務端去監聽端口的通訊并處理, 變成了一種反向依賴.

如果一個進程想要提供 web 服務, 它啟動之后就要去綁定(binding) web 相關的端口,

如果端口已經被其它進程綁定了(即所謂占用了), 就會綁定失敗; 又或者被自身前一個未完全退出的進程占據著, 也會綁定失敗, 在開發過程中你可能會遇到類似的問題, 一個 web 進程沒有關閉, 你又試圖啟動另一個, 而兩者都用了相同的端口, 就會產生沖突.

并在其上持續的監聽(listen), 同時在有請求到來的時候去響應(response). 這樣一來, 進程 ID 的問題就消解了:

這類似于一個接口回調, 瀏覽器只需要面向接口索取服務, 而無需知道接口服務的具體提供者, 這些細節被端口層所封裝并隱藏起來了.

端口這一間接層的存在解耦(decouple)了客戶端與服務端之間的強依賴, 整個體系變得很靈活.

可以把端口視作一般編程概念中的接口(interface), 而想 Nginx, apache, tomcat 等等可以認為是這個接口的不同實現(Implementation).

端口與現實世界的一個類比

為加深理解, 可以舉一個現實世界中的例子. 相信大家都有過去市民中心辦事的經歷, 比如去辦理居住證, 護照, 社保等等業務, 你通常會收到一個小紙條讓你去某個窗口辦理對應業務, 這個窗口其實就類似于端口了:

比如 80 窗口就對應港澳臺通行證業務

那么你要辦港澳臺通行證, 你就奔向 80 號窗口就完了. 你不要去問門口保衛處的王大爺, 到底是哪位同志辦理這個業務.

今天可能是小明在辦理, 隔了幾天, 小明可能受傷了, 流血了, 又輪到小紅在那里辦理, 又過段時間, 小紅也出意外了, 流產了, 又輪到小張在辦理, 又過段時間, 小張被發現在辦理業務過程中徇私舞弊, 流放了...

等等, 如果此時你的同事問你怎么辦港澳臺通行證, 你需要知道這些個人事變動的細節嗎? 根本不需要呀, 你只需告訴他去 80 號窗口辦理就好了...

市民中心的整個體系, 會確保有個會辦理這些業務的人員坐在那個窗口下面, 你唯一需要做的, 就是到那個窗口下請求服務即可.

端口與名稱服務(naming service)

通過上面現實世界類比的例子, 對于端口的機制, 相信你已經理解得比較深入了. 廣義上講, 端口層也可以視作一個 naming service(名稱服務), 這與比如 spring cloud 中的 eureka 里的機制本質上是一樣的, 只是這個 name 就是一個抽象的數字, 比如 80. 80 就代表了一個 web 服務, Nginx 之類的 web server 綁定并監聽就相當于把自身提供的 web 服務注冊于其上.

DNS 域名系統其實也是 naming service, 你通過 xiaogd.net 這個名字(name), 就能獲取到我所提供給你的網頁服務.

類似的還有 java 里的 JNDI 等, 把一個名字與一個服務關聯起來, 比如一個名字就代表一個數據源(數據庫連接)之類的.

端口與 IoC(控制反轉)

廣義上, 端口的上述機制也是控制反轉(Ioc: Inversion of Control)思想的一種體現, 如果客戶端需要知道服務端的進程 ID, 實際上就被服務端控制了, 畢竟我服務端在哪個 ID 上提供服務, 你就得把你的請求發到相應的 ID 上來;

而有了端口這一中間層呢? 作為客戶端, 總是把請求發到對應端口上, 并要求服務端綁定并監聽那些端口以及作出響應, 你服務端是反過來被我客戶端所控制, 我客戶端發到哪個端口, 你服務端就要去相應端口上監聽并響應.

大家可以體會一下這種轉變. 這種設計或思想在編程領域其實是特別重要的, 在很多其它地方都有體現.

因為瀏覽器總是把 web 請求發到了 80 或 443 端口, 這就要求一個 web server 進程去監聽這些端口. 比如在我的服務器上, web server 是 Nginx, 它啟動之后就會去監聽 80 和 443 端口, 任何想要訪問我的主頁的人, 并不需要知道我的 Nginx 進程 ID 是啥, 借助于端口這一間接層, 你就能夠與我的 Nginx 進程通訊, 并獲取你想要的東西.

事實上你可以這么認為, 瀏覽器實際上只是在與端口通訊, 端口層再把這些請求委托(delegate)或代理(proxy)給相應的 web server 去處理, 端口的角色就是一個中間人, 一個間接層.

再論缺省端口

現在, 我們應該明白了, 端口是必要的了, 當然, 對最終的用戶來說, 則不需要知道這些實現的細節, 對于他們, 應該遵循最小知識原則, 知道得越少越好.

如果你一定要讓用戶在輸入 url 的過程中輸入端口, 又或者要輸入個 www 等等, 用戶就要給你扔過來"十萬個為什么"了...

為什么要加個 443?

為什么不是 334, 443是啥意思?

為什么一會兒是 80, 一會兒又是 443?

為什么加個 www, 啥意思?

為什么末尾還加個斜杠, 不加會死嗎?

...

惹不起, 惹不起...

還記得前面說的, 用戶是笨蛋, 用戶是懶漢嗎?

這里又要引用一句計算機世界的名言了: 程序員和上帝打賭要開發出更大更好連傻瓜都會用的軟件, 而上帝卻總能創造出更大更傻的傻瓜。目前為止，上帝贏了。

Programmers are in a race with the Universe to create bigger and better idiot-proof programs. The Universe is trying to create bigger and better idiots. So far the Universe is winning.

說句心里話, 很多時候, 用戶能記住你的域名就阿彌陀佛了, 你就該燒高香了, 你還想用戶記住你的端口, 真的想多了...

另一方面, 說到這里我們應該也能明白了, 那就是理論上, web 服務實際上可以構建在任何端口之上. 比如在本地開發的時候, 用戶只有你自己, 那當然你可以隨便挑一個端口, 比如 8080, 只要自己知道就好了或頂多告訴另一個與你配合的前端同事.

同理, 其它非 web 的服務, 比如 ftp 服務, 也不一定說非得在 21 端口上等等; mysql 服務的端口同樣可以調整為 3306 之外的端口.

又或者說, 你想提供一個服務, 但只想小范圍內的人知道, 你可以挑一個很偏門的端口, 這樣一般人只輸一個域名就沒法訪問到你的服務了.

比如有人想偷偷提供一些服務, 放一些廣淫民群眾喜聞樂見的小視頻啥的...刑法警告, 后果自負!! 別說我沒有提醒你.

端口與 TCP/UDP 協議

前面一直在說, 什么 3306 端口, 80 端口, 443 端口, 其實嚴格來說, 端口是分 TCP 端口和 UDP 端口的, 不過多數時候遇到的都是 TCP 端口, 但 TCP 80 端口和 UDP 80 端口是不同的端口.

UDP 的 80 端口, 包括 443 端口其實被保留了, 目前的 http 協議只構建在 TCP 協議之上.

當然, 理論上講, 在 UDP 上構建 http 也不能說就完全不行, 畢竟, 無論 UDP 還是 TCP 都是構建在 IP 協議之上, 總之呢, 計算機的世界沒什么是不可能的, 而且似乎真有人在做這些嘗試, 不過這就屬于兩小母牛對屁股--比較牛逼的范疇了, 深水區了, 咱也不懂, 不多說了.

還有一點, 對于進程間的端口通訊, 實際上是對稱的, 也即是說, 服務器的響應也是先回到一個客戶端的端口上.

如果你用 Windows 10 系統, 可以在 任務管理器 > 性能 > 打開資源監視器 > 網絡 > TCP 連接, 點擊下遠程端口可以按照從小到大排列, 通常就可以看到 443 的相關連接了, 可以看到左邊有一欄本地端口, 一個 TCP 連接總是有一個遠程端口, 一個本地端口:

當發起一個 TCP 連接時, 客戶端首先自己先隨機挑選一個沒有被使用的端口作為服務器響應的接收端口, 比如 38672. 在一個 TCP 的包里, 無論是握手包還是后續的數據包, 包頭部分最重要的兩個字段, 一個就是源端口(source port), 比如 38672; 另一個就是目標端口(destination port), 比如 80, 或者 443.

可以這樣看, 服務器的響應也是先回到源端口, 比如 38672 上, 源端口再轉給最終的進程, 比如瀏覽器.

而對于一個 IP 包, 同樣的, 包頭部分最重要的兩個字段, 一個就是源IP(source IP); 另一個就是目標 IP(destination IP).

而 TCP 包會作為 IP 包的數據包被打包到 IP 包里面, 也一個 IP 包里其實包含了 IP + 端口.

IP 加端口再加上端口與進程間的關聯, 分屬兩個不同主機間的進程就能通過 TCP(UDP)/IP 協議愉快地進行進程間的通訊(IPC)了.

當然了, 同一個主機間的進程也同樣可以利用這套機制. 但同一個主機間還可以有其它選擇, 這個具體看各個操作系統是否提供相關機制及支持. 而 TCP/IP 屬于廣泛應用的標準協議, 從而得到了廣泛支持.

審核編輯：黃飛

?