端口號(hào)都說(shuō)不明白，別說(shuō)自己懂網(wǎng)絡(luò)！

嵌入式專欄

點(diǎn)擊左上方藍(lán)色“一口Linux”，選擇“設(shè)為星標(biāo)”
第一時(shí)間看干貨文章
?【干貨】嵌入式驅(qū)動(dòng)工程師學(xué)習(xí)路線?【干貨】Linux嵌入式知識(shí)點(diǎn)-思維導(dǎo)圖-免費(fèi)獲取?【就業(yè)】一個(gè)可以寫到簡(jiǎn)歷的基于Linux物聯(lián)網(wǎng)綜合項(xiàng)目?【就業(yè)】找工作簡(jiǎn)歷模版


1


每當(dāng)看到有人的簡(jiǎn)歷上寫著熟悉 tcp/ip, http 等協(xié)議時(shí), 我就忍不住問(wèn)問(wèn)他們: 你給我說(shuō)說(shuō), 端口是啥吧! 可惜, 很少有人能說(shuō)得讓人滿意... 所以這次就來(lái)談?wù)劧丝?port), 這個(gè)熟悉的陌生人.
在此過(guò)程中, 還會(huì)談?wù)勯g接層, naming service 等概念, IoC, 依賴倒置等原則以及 TCP 協(xié)議的一些重點(diǎn)知識(shí).
常見(jiàn)端口在我們的日常開發(fā)過(guò)程中, 特別是后端的開發(fā)人員, 即便他沒(méi)有真正理解端口的細(xì)節(jié), 他還是會(huì)聽(tīng)過(guò)見(jiàn)過(guò)各類的端口, 這個(gè)東西幾乎無(wú)處不在,

比如:
mysql 缺省用的 3306 端口,
redis 的 6379 端口,
tomcat 默認(rèn)用的 8080 端口,
ssh 用的 22 端口,
等等...
當(dāng)然我們最關(guān)注的還是 web 相關(guān)的端口, 涉及的主要為 80 和 443 兩個(gè)端口, 下面就來(lái)重點(diǎn)說(shuō)說(shuō).
端口是必須的嗎?在本地 web 開發(fā)調(diào)試過(guò)程中, 我們可能都碰到過(guò)端口, 比如或許是/最著名的 8080 端口, 一般我們會(huì)這樣去訪問(wèn)本地的 web 程序:
localhost:8080
但一旦 web 程序部署到了正式的網(wǎng)站中, 端口似乎就消失了, 正式的網(wǎng)址中就不需要端口了嗎? 答案是否定的, 在這里起作用的是缺省值.
比如你訪問(wèn)我的網(wǎng)站: https://xiaogd.net, 這個(gè) url 中似乎沒(méi)有端口, 但其實(shí)是有的, 它有一個(gè)默認(rèn)值 443, 所以完整的形式實(shí)際是這樣的:
https://xiaogd.net:443.
你可以通過(guò) Chrome 的開發(fā)人員調(diào)試工具看到這一點(diǎn):


可以看到, ip 地址后面跟著一個(gè) 443
如果你輸入一個(gè)錯(cuò)誤的端口, 比如 80, 像這樣: https://xiaogd.net:80, 結(jié)果就是無(wú)法訪問(wèn).
但是如果你改成 http://xiaogd.net:80, 它又可以訪問(wèn)了.
注意, 因?yàn)槲曳��?wù)器后臺(tái)配置了 http 自動(dòng)跳轉(zhuǎn) https 的 301 重定向, 所以最終瀏覽器會(huì)再次跳轉(zhuǎn)到 https://xiaogd.net:443.
注意勾選 'Preserve log' 以保留日志, 可以看到第一個(gè) 80 端口的請(qǐng)求會(huì)被響應(yīng)一個(gè) 301 跳轉(zhuǎn), 并指示跳轉(zhuǎn)目標(biāo), 也即是 Location 字段中的 https 請(qǐng)求, 瀏覽器接收此跳轉(zhuǎn)指示并重新發(fā)起 https 請(qǐng)求, 也即是圖中第二個(gè) xiaogd.net 的請(qǐng)求. 所以地址欄最終還是會(huì)變成 https 的, 特此說(shuō)明.
此時(shí)如果你輸入 http://xiaogd.net:443, 它又不能訪問(wèn)了...
那么原因是什么呢? 你找到規(guī)律了沒(méi)有?
注意一個(gè)是 http, 一個(gè)是 https.
協(xié)議的缺省端口當(dāng)你沒(méi)有顯式的在 url 中輸入端口時(shí), 瀏覽器實(shí)際上會(huì)根據(jù)所用的協(xié)議來(lái)為你指定一個(gè)缺省端口:
如果是 http 協(xié)議, 就使用 80 端口
如果是 https 協(xié)議, 就使用 443 端口
如果你自己輸入端口呢? 那就用你輸入的端口, 你輸入啥就是啥, 輸錯(cuò)了, 訪問(wèn)不了那就是你的責(zé)任了, 誰(shuí)讓你瞎搞來(lái)著?
本來(lái)不用你勞神的, 你偏要脫褲子放屁, 搞不好自然就是畫蛇添足, 弄巧成拙了.
比如上面的用了 http 卻輸入了 443, 或者用了 https 卻輸入了 80, 就無(wú)法成功訪問(wèn)了.
另外, 如果你胡亂地輸入一個(gè)比如 9527, http://xiaogd.net:9527, 自然也是無(wú)法訪問(wèn)的, 原因也很簡(jiǎn)單, 因?yàn)槲业姆��?wù)器上根本沒(méi)有在 9527 端口上進(jìn)行監(jiān)聽(tīng).
即便我有在 9527 端口上監(jiān)聽(tīng), 提供的也未必是 web 服務(wù), 使用的協(xié)議可能既不是 http, 也不是 https, 所以你用瀏覽器試圖去訪問(wèn)也可能會(huì)碰壁的.
當(dāng)然了, 我是完全可以在服務(wù)器上的 9527 端口上再部署一個(gè) web 服務(wù)的, 比如放一個(gè) apache 或 tomcat server 之類的 web server 監(jiān)聽(tīng)在那個(gè)端口上, 再放通防火墻, 安全組之類的, 也是可以訪問(wèn)的. 只是我沒(méi)有這么去做而已.
那么為啥大家都不在那些奇奇怪怪的端口上提供 web 服務(wù)呢? 原因其實(shí)也很簡(jiǎn)單, 為了方便用戶, 同時(shí)也減輕了用戶的認(rèn)知負(fù)擔(dān).
其實(shí)關(guān)于用戶, 你只要記住兩點(diǎn)就好了:
用戶是傻瓜
用戶是懶漢
[/ol]深刻地理解了這一點(diǎn), 你才可能成為一個(gè)好的程序員(包括但不限于產(chǎn)品經(jīng)理, 設(shè)計(jì)師...)
其實(shí)呀, 何止了省略了端口呀, 你看看現(xiàn)在的地址欄, 不但 http, https 這些協(xié)議省了, 最末尾的斜杠 / 省了, 甚至連 www 都省了...
是的, 我也幫你們省了 www, 事實(shí)上你通過(guò) https://www.xiaogd.net/ 也能訪問(wèn)到, 但如果通過(guò) https://xiaogd.net/ 就能訪問(wèn)到, 又何苦去再去錄入三個(gè)達(dá)不溜呢?
必須得承認(rèn), 缺省的存在是有很大的幫助的, 這其實(shí)是進(jìn)步; 但另一方面, 這些缺省有時(shí)也會(huì)給不明就里的開發(fā)人員帶來(lái)了一些困惑, 好像端口不是必要的, 但其實(shí)不是這樣的.
為什么需要端口?那為什么一定要端口這個(gè)東西呢? 它到底起了什么作用, 想必很多同學(xué)想要了解, 下面就來(lái)說(shuō)說(shuō)為什么, 而一個(gè)首先需要了解的概念就是進(jìn)程間通訊(所謂的 IPC(inter-process communication)
進(jìn)程間通訊(IPC)你在瀏覽器地址欄輸入某個(gè)網(wǎng)站的域名, 然后回車, 就生成了一次請(qǐng)求, 然后服務(wù)器響應(yīng)你的請(qǐng)求, 瀏覽器再把結(jié)果渲染出來(lái), 你就能最終看到到一個(gè)網(wǎng)頁(yè).
如果你曾經(jīng) ping 過(guò)一個(gè)域名, 比如你現(xiàn)在 ping 我的域名 xiaogd.net, 你就能得到一個(gè) ip 地址, 118.89.55.54:


有了 ip, 瀏覽器自然就能找到我的主機(jī), 但還是有個(gè)問(wèn)題, 我的主機(jī)上運(yùn)行著好多的進(jìn)程, 好多的服務(wù), 除了最常見(jiàn)的 web 服務(wù), 我可能還有 ftp 服務(wù), mysql 服務(wù)等等不一而足.
簡(jiǎn)單地講, 如果一個(gè)請(qǐng)求只有 ip 地址這一信息, 操作系統(tǒng)將不知道把這個(gè)請(qǐng)求交給哪個(gè)進(jìn)程去處理, 如果是你來(lái)設(shè)計(jì)整個(gè)系統(tǒng), 你想象一下, 是不是這樣?
如果你僅僅是輸入域名, 經(jīng)過(guò) DNS 解析后, 只能得到一個(gè) IP 地址.
所謂的一次請(qǐng)求, 從一個(gè)比較底層的角度去看, 就是一次進(jìn)程間的通訊.


它可以是 navicat 客戶端與 mysql 數(shù)據(jù)庫(kù)服務(wù)的一次通訊, 也可以是 winScp 客戶端與 vsftpd FTP 服務(wù)的一次通訊等等.
以上面的具體為例, 可以說(shuō)就是 Chrome 瀏覽器這個(gè)本地操作系統(tǒng)上的進(jìn)程與我的服務(wù)器上的一個(gè)叫做 Nginx 的進(jìn)程間的一次通訊.
那么, 所謂的端口, 其實(shí)可以簡(jiǎn)單地視作為進(jìn)程 ID.
當(dāng)然, 它與進(jìn)程 ID 還是有不同的, 下面再分析, 或者目前你可以認(rèn)為端口就是進(jìn)程 ID 的影子.
也即是說(shuō), 如果僅有域名(ip), 是無(wú)法定位到一個(gè)進(jìn)程的, 通訊的發(fā)起方不但需要給出 ip, 還需要給出端口, 只有這樣, 服務(wù)器才能知道由哪個(gè)進(jìn)程去響應(yīng).
端口, 一個(gè)間接層那么問(wèn)題又來(lái)了, 為什么引入端口, 而不是直接使用進(jìn)程 ID 呢? 這個(gè)原因想想也不難明白, 大概有這么幾點(diǎn)原因:
作為客戶端無(wú)法知道服務(wù)端對(duì)應(yīng)進(jìn)程的 ID
服務(wù)端對(duì)應(yīng)進(jìn)程重啟后 ID 會(huì)改變
一個(gè)網(wǎng)站的 web 進(jìn)程 ID 是這個(gè), 另一個(gè)網(wǎng)站的可能又是另一個(gè)
[/ol]自然, 原因是很多的, 我也是隨便的列舉了一些, 你或許還能想到更多. 而為了解決這些個(gè)問(wèn)題, 就引入了端口這一間接層(indirection).
計(jì)算機(jī)世界里有一句名言: 任何計(jì)算機(jī)問(wèn)題均可通過(guò)增加一個(gè)間接(indirection)層來(lái)解決.(Any problem in computer science can be solved with another layer of indirection. -- David Wheeler)
這個(gè)名言其實(shí)還有后面一句: But what usually will create another problem.(但通常會(huì)帶來(lái)另一個(gè)問(wèn)題)
這里所謂另一個(gè)問(wèn)題, 比如它會(huì)使得層次結(jié)構(gòu)復(fù)雜化, 交互效率下降等等. 當(dāng)然了, 這就是架構(gòu)師們要去權(quán)衡的問(wèn)題了, 很多時(shí)候, 架構(gòu)就是關(guān)于平衡的藝術(shù). 打死都不肯引入任何的間接層, 這是一個(gè)極端; 而一上來(lái)就引入好多個(gè)間接層, 這又是另一個(gè)極端.
如果沒(méi)有這個(gè)間接層, 客戶端要與服務(wù)端通訊, 就要知道服務(wù)端對(duì)應(yīng)進(jìn)程的 ID, 也即是客戶端是依賴于服務(wù)端的:
顯然, 這種模式對(duì)于 web 這種一個(gè)服務(wù)端對(duì)應(yīng)大量客戶端訪問(wèn)的情形是極不適應(yīng)的, 你都不知道有誰(shuí)可能會(huì)來(lái)訪問(wèn)你的網(wǎng)站! 你根本無(wú)法告訴它們.
而有了端口這一間接層, 對(duì)于 web 的情形, 這種依賴被倒置了, 客戶端總是把請(qǐng)求發(fā)送到 80(或443) 端口, 這些成為標(biāo)準(zhǔn)的一部分, 并要求服務(wù)端反過(guò)來(lái)去適應(yīng), 服務(wù)端去監(jiān)聽(tīng)端口的通訊并處理, 變成了一種反向依賴.


如果一個(gè)進(jìn)程想要提供 web 服務(wù), 它啟動(dòng)之后就要去綁定(binding) web 相關(guān)的端口,
如果端口已經(jīng)被其它進(jìn)程綁定了(即所謂占用了), 就會(huì)綁定失敗; 又或者被自身前一個(gè)未完全退出的進(jìn)程占據(jù)著, 也會(huì)綁定失敗, 在開發(fā)過(guò)程中你可能會(huì)遇到類似的問(wèn)題, 一個(gè) web 進(jìn)程沒(méi)有關(guān)閉, 你又試圖啟動(dòng)另一個(gè), 而兩者都用了相同的端口, 就會(huì)產(chǎn)生沖突.
并在其上持續(xù)的監(jiān)聽(tīng)(listen), 同時(shí)在有請(qǐng)求到來(lái)的時(shí)候去響應(yīng)(response). 這樣一來(lái), 進(jìn)程 ID 的問(wèn)題就消解了:
這類似于一個(gè)接口回調(diào), 瀏覽器只需要面向接口索取服務(wù), 而無(wú)需知道接口服務(wù)的具體提供者, 這些細(xì)節(jié)被端口層所封裝并隱藏起來(lái)了.
端口這一間接層的存在解耦(decouple)了客戶端與服務(wù)端之間的強(qiáng)依賴, 整個(gè)體系變得很靈活.
可以把端口視作一般編程概念中的接口(interface), 而想 Nginx, apache, tomcat 等等可以認(rèn)為是這個(gè)接口的不同實(shí)現(xiàn)(Implementation).
端口與現(xiàn)實(shí)世界的一個(gè)類比為加深理解, 可以舉一個(gè)現(xiàn)實(shí)世界中的例子. 相信大家都有過(guò)去市民中心辦事的經(jīng)歷, 比如去辦理居住證, 護(hù)照, 社保等等業(yè)務(wù), 你通常會(huì)收到一個(gè)小紙條讓你去某個(gè)窗口辦理對(duì)應(yīng)業(yè)務(wù), 這個(gè)窗口其實(shí)就類似于端口了:
比如 80 窗口就對(duì)應(yīng)港澳臺(tái)通行證業(yè)務(wù)
那么你要辦港澳臺(tái)通行證, 你就奔向 80 號(hào)窗口就完了. 你不要去問(wèn)門口保衛(wèi)處的王大爺, 到底是哪位同志辦理這個(gè)業(yè)務(wù).
今天可能是小明在辦理, 隔了幾天, 小明可能受傷了, 流血了, 又輪到小紅在那里辦理, 又過(guò)段時(shí)間, 小紅也出意外了, 流產(chǎn)了, 又輪到小張?jiān)谵k理, 又過(guò)段時(shí)間, 小張被發(fā)現(xiàn)在辦理業(yè)務(wù)過(guò)程中徇私舞弊, 流放了...
等等, 如果此時(shí)你的同事問(wèn)你怎么辦港澳臺(tái)通行證, 你需要知道這些個(gè)人事變動(dòng)的細(xì)節(jié)嗎? 根本不需要呀, 你只需告訴他去 80 號(hào)窗口辦理就好了...
市民中心的整個(gè)體系, 會(huì)確保有個(gè)會(huì)辦理這些業(yè)務(wù)的人員坐在那個(gè)窗口下面, 你唯一需要做的, 就是到那個(gè)窗口下請(qǐng)求服務(wù)即可.
端口與名稱服務(wù)(naming service)通過(guò)上面現(xiàn)實(shí)世界類比的例子, 對(duì)于端口的機(jī)制, 相信你已經(jīng)理解得比較深入了. 廣義上講, 端口層也可以視作一個(gè) naming service(名稱服務(wù)), 這與比如 spring cloud 中的 eureka 里的機(jī)制本質(zhì)上是一樣的, 只是這個(gè) name 就是一個(gè)抽象的數(shù)字, 比如 80. 80 就代表了一個(gè) web 服務(wù), Nginx 之類的 web server 綁定并監(jiān)聽(tīng)就相當(dāng)于把自身提供的 web 服務(wù)注冊(cè)于其上.
DNS 域名系統(tǒng)其實(shí)也是 naming service, 你通過(guò) xiaogd.net 這個(gè)名字(name), 就能獲取到我所提供給你的網(wǎng)頁(yè)服務(wù).
類似的還有 java 里的 JNDI 等, 把一個(gè)名字與一個(gè)服務(wù)關(guān)聯(lián)起來(lái), 比如一個(gè)名字就代表一個(gè)數(shù)據(jù)源(數(shù)據(jù)庫(kù)連接)之類的.
端口與 IoC(控制反轉(zhuǎn))廣義上, 端口的上述機(jī)制也是控制反轉(zhuǎn)(Ioc: Inversion of Control)思想的一種體現(xiàn), 如果客戶端需要知道服務(wù)端的進(jìn)程 ID, 實(shí)際上就被服務(wù)端控制了, 畢竟我服務(wù)端在哪個(gè) ID 上提供服務(wù), 你就得把你的請(qǐng)求發(fā)到相應(yīng)的 ID 上來(lái);
而有了端口這一中間層呢? 作為客戶端, 總是把請(qǐng)求發(fā)到對(duì)應(yīng)端口上, 并要求服務(wù)端綁定并監(jiān)聽(tīng)那些端口以及作出響應(yīng), 你服務(wù)端是反過(guò)來(lái)被我客戶端所控制, 我客戶端發(fā)到哪個(gè)端口, 你服務(wù)端就要去相應(yīng)端口上監(jiān)聽(tīng)并響應(yīng).
大家可以體會(huì)一下這種轉(zhuǎn)變. 這種設(shè)計(jì)或思想在編程領(lǐng)域其實(shí)是特別重要的, 在很多其它地方都有體現(xiàn).
因?yàn)闉g覽器總是把 web 請(qǐng)求發(fā)到了 80 或 443 端口, 這就要求一個(gè) web server 進(jìn)程去監(jiān)聽(tīng)這些端口. 比如在我的服務(wù)器上, web server 是 Nginx, 它啟動(dòng)之后就會(huì)去監(jiān)聽(tīng) 80 和 443 端口, 任何想要訪問(wèn)我的主頁(yè)的人, 并不需要知道我的 Nginx 進(jìn)程 ID 是啥, 借助于端口這一間接層, 你就能夠與我的 Nginx 進(jìn)程通訊, 并獲取你想要的東西.
事實(shí)上你可以這么認(rèn)為, 瀏覽器實(shí)際上只是在與端口通訊, 端口層再把這些請(qǐng)求委托(delegate)或代理(proxy)給相應(yīng)的 web server 去處理, 端口的角色就是一個(gè)中間人, 一個(gè)間接層.
再論缺省端口現(xiàn)在, 我們應(yīng)該明白了, 端口是必要的了, 當(dāng)然, 對(duì)最終的用戶來(lái)說(shuō), 則不需要知道這些實(shí)現(xiàn)的細(xì)節(jié), 對(duì)于他們, 應(yīng)該遵循最小知識(shí)原則, 知道得越少越好.
如果你一定要讓用戶在輸入 url 的過(guò)程中輸入端口, 又或者要輸入個(gè) www 等等, 用戶就要給你扔過(guò)來(lái)"十萬(wàn)個(gè)為什么"了...
為什么要加個(gè) 443?
為什么不是 334, 443是啥意思?
為什么一會(huì)兒是 80, 一會(huì)兒又是 443?
為什么加個(gè) www, 啥意思?
為什么末尾還加個(gè)斜杠, 不加會(huì)死嗎?
...
惹不起, 惹不起...
還記得前面說(shuō)的, 用戶是笨蛋, 用戶是懶漢嗎?
這里又要引用一句計(jì)算機(jī)世界的名言了: 程序員和上帝打賭要開發(fā)出更大更好連傻瓜都會(huì)用的軟件, 而上帝卻總能創(chuàng)造出更大更傻的傻瓜。目前為止，上帝贏了。
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.
說(shuō)句心里話, 很多時(shí)候, 用戶能記住你的域名就阿彌陀佛了, 你就該燒高香了, 你還想用戶記住你的端口, 真的想多了...
另一方面, 說(shuō)到這里我們應(yīng)該也能明白了, 那就是理論上, web 服務(wù)實(shí)際上可以構(gòu)建在任何端口之上. 比如在本地開發(fā)的時(shí)候, 用戶只有你自己, 那當(dāng)然你可以隨便挑一個(gè)端口, 比如 8080, 只要自己知道就好了或頂多告訴另一個(gè)與你配合的前端同事.
同理, 其它非 web 的服務(wù), 比如 ftp 服務(wù), 也不一定說(shuō)非得在 21 端口上等等; mysql 服務(wù)的端口同樣可以調(diào)整為 3306 之外的端口.
又或者說(shuō), 你想提供一個(gè)服務(wù), 但只想小范圍內(nèi)的人知道, 你可以挑一個(gè)很偏門的端口, 這樣一般人只輸一個(gè)域名就沒(méi)法訪問(wèn)到你的服務(wù)了.
比如有人想偷偷提供一些服務(wù), 放一些廣淫民群眾喜聞樂(lè)見(jiàn)的小視頻啥的...刑法警告, 后果自負(fù)!! 別說(shuō)我沒(méi)有提醒你.
端口與 TCP/UDP 協(xié)議前面一直在說(shuō), 什么 3306 端口, 80 端口, 443 端口, 其實(shí)嚴(yán)格來(lái)說(shuō), 端口是分 TCP 端口和 UDP 端口的, 不過(guò)多數(shù)時(shí)候遇到的都是 TCP 端口, 但 TCP 80 端口和 UDP 80 端口是不同的端口.
UDP 的 80 端口, 包括 443 端口其實(shí)被保留了, 目前的 http 協(xié)議只構(gòu)建在 TCP 協(xié)議之上.
當(dāng)然, 理論上講, 在 UDP 上構(gòu)建 http 也不能說(shuō)就完全不行, 畢竟, 無(wú)論 UDP 還是 TCP 都是構(gòu)建在 IP 協(xié)議之上, 總之呢, 計(jì)算機(jī)的世界沒(méi)什么是不可能的, 而且似乎真有人在做這些嘗試, 不過(guò)這就屬于兩小母牛對(duì)屁股--比較牛逼的范疇了, 深水區(qū)了, 咱也不懂, 不多說(shuō)了.
還有一點(diǎn), 對(duì)于進(jìn)程間的端口通訊, 實(shí)際上是對(duì)稱的, 也即是說(shuō), 服務(wù)器的響應(yīng)也是先回到一個(gè)客戶端的端口上.
如果你用 Windows 10 系統(tǒng), 可以在 任務(wù)管理器 > 性能 > 打開資源監(jiān)視器 > 網(wǎng)絡(luò) > TCP 連接, 點(diǎn)擊下遠(yuǎn)程端口可以按照從小到大排列, 通常就可以看到 443 的相關(guān)連接了, 可以看到左邊有一欄本地端口, 一個(gè) TCP 連接總是有一個(gè)遠(yuǎn)程端口, 一個(gè)本地端口:
當(dāng)發(fā)起一個(gè) TCP 連接時(shí), 客戶端首先自己先隨機(jī)挑選一個(gè)沒(méi)有被使用的端口作為服務(wù)器響應(yīng)的接收端口, 比如 38672. 在一個(gè) TCP 的包里, 無(wú)論是握手包還是后續(xù)的數(shù)據(jù)包, 包頭部分最重要的兩個(gè)字段, 一個(gè)就是源端口(source port), 比如 38672; 另一個(gè)就是目標(biāo)端口(destination port), 比如 80, 或者 443.
可以這樣看, 服務(wù)器的響應(yīng)也是先回到源端口, 比如 38672 上, 源端口再轉(zhuǎn)給最終的進(jìn)程, 比如瀏覽器.
而對(duì)于一個(gè) IP 包, 同樣的, 包頭部分最重要的兩個(gè)字段, 一個(gè)就是源IP(source IP); 另一個(gè)就是目標(biāo) IP(destination IP).
而 TCP 包會(huì)作為 IP 包的數(shù)據(jù)包被打包到 IP 包里面, 也一個(gè) IP 包里其實(shí)包含了 IP + 端口.
IP 加端口再加上端口與進(jìn)程間的關(guān)聯(lián), 分屬兩個(gè)不同主機(jī)間的進(jìn)程就能通過(guò) TCP(UDP)/IP 協(xié)議愉快地進(jìn)行進(jìn)程間的通訊(IPC)了.
當(dāng)然了, 同一個(gè)主機(jī)間的進(jìn)程也同樣可以利用這套機(jī)制. 但同一個(gè)主機(jī)間還可以有其它選擇, 這個(gè)具體看各個(gè)操作系統(tǒng)是否提供相關(guān)機(jī)制及支持. 而 TCP/IP 屬于廣泛應(yīng)用的標(biāo)準(zhǔn)協(xié)議, 從而得到了廣泛支持.
因?yàn)槠�幅關(guān)系, 關(guān)于這樣 TCP 協(xié)議等的細(xì)節(jié), 以及包括 Socket, 連接等概念, 以及虛擬主機(jī), 反向代理等等就不再展開去說(shuō), 如果你感興趣, 歡迎留言, 后續(xù)會(huì)考慮再寫一些文章去介紹.
同樣因?yàn)槠�幅的原因以及同時(shí)我也不是計(jì)算機(jī)網(wǎng)絡(luò)及協(xié)議方面的專家, 關(guān)于端口方面的, 如果有什么說(shuō)得不到位, 或不正確的地方, 歡迎留言指正, 關(guān)于端口方面的介紹就到這里.
end

一口Linux

關(guān)注，回復(fù)【1024】海量Linux資料贈(zèng)送
精彩文章合集
文章推薦
?【專輯】ARM?【專輯】粉絲問(wèn)答?【專輯】所有原創(chuàng)?【專輯】linux入門?【專輯】計(jì)算機(jī)網(wǎng)絡(luò)?【專輯】Linux驅(qū)動(dòng)?【干貨】嵌入式驅(qū)動(dòng)工程師學(xué)習(xí)路線?【干貨】Linux嵌入式所有知識(shí)點(diǎn)-思維導(dǎo)圖