網路概念與快遞物流

網路世界承載著太多的期許和重任。整個計算機的發展，因為網路的實現而勢不可擋地飛速前行。無數的東西，慢慢變成輕量化的服務，存在於網路的雲端，而最讓人炫目的黑客技術，也幾乎特指網路中的自由馳騁。而：

這一系列撲朔迷離的故事，都讓networks披上了神秘的外衣。

就我自己的角度來講：

網路的根本作用，就是完成資訊的交流，也即是完成位元(bit)流0、1的數字交換。

只不過，物流公司運輸的是實實在在的「物體」，而網路運載的是抽象的資訊流，也即是那一堆0、1數字。

讓我們先達成乙個共識。在如今的數字時代，幾乎所有的資訊，都能夠被轉換為0、1數字流（也即是位元流）在計算機中儲存、交換。所謂的資訊化、數位化，也就是把各種形式的資訊（文字、聲音、影象等等），都轉換成為數字流。

那麼，對網路這個關於資訊的物流行業來講，如果實現了對0、1數字流的運輸和物流，也就實現了對所有形式的、抽象的「資訊」的物流。

如此，在開頭對網路作用的定義就可以替換為：完成0、1數字流的運輸物流。

那麼，在這樣的視角之下，很多看似不同的網路應用，其實都是一回事：

網路遊戲，無非是把自己遊戲角色的當前屬性、位置座標，和伺服器端做交換。

使用**購物，無非是把自己選中的商品資訊和**的伺服器端做交換。

傳送email，無非是把email的文字、資訊和收件人做交換。

而物流這樣的基礎設施，其最基本的模型無非是：從a點通過一條路徑，把貨物（位元流）運輸到b點。

也即是兩個點a和b，以及連線它們的一條線。

那為什麼又需要「網路分層」的概念呢？如果讓我們繼續考察現實生活中的物流，或許就能夠很輕鬆地理解這個必要性了。

雖然我們都知道，運輸我們要寄送的貨物是需要落實到最後的「汽車運輸、火車運輸、輪船運輸、飛機運輸」這樣乙個終端環節。但如果我們每次寄送一件貨物，都需要去關心這些終端運輸環節，就太麻煩了。

那麼實際的解決方案是什麼呢？

而在接受端，待在家裡或者公司的我們，並不需要走到屋外，快遞小哥會把寄給我們的貨物，呈送到我們門前。

在這樣的視角下，似乎寄送東西這件事情，只需要有物流小哥就夠了，別的什麼飛機、貨車、以及運輸標籤都是不需要的。物流小哥就像是乙個空間傳輸的蟲洞：扔給他一件物品，就能嗖地一下出現在接收端，把東西呈送給收件人。這一過程，可以對應到網路的應用層。

我們不用關心這個貨物，是通過飛機寄送的、還是輪船寄送的，又或是在寄送的過程中經過了哪些省、又繞過了哪些市。我們統統不需要關心。我們有且只需要和物流小哥對接，其它的服務和瑣碎的事情，就由快遞小哥及他所在的物流公司代替我們去操心和完成。

網路的應用層也如是。我們不需要關心「按下的【下單】按鈕」，是通過stream的方式傳送的還是通過datagram的方式傳送的，又或是「下單」這個指令繞過了多少路由器、走過了全世界多少個國家、穿越了多少個海底隧道，我統統不用關心，我只需要把我的需求告訴應用層，別的細節自有它對應的底層去關心和完成。

對我們一般使用者來講，關心應用層，也即是快遞小哥，這個介面就夠了。可如果想要操控更多的細節，例如程式設計師更精細地控制資訊的傳送與交換（對應到：協助乙個公司，組織批量的貨物寄送，這就需要更多地了解和談判運送方式和時間限制），你就不得不深入直下，去**「快遞」這乙個過程更多的細節。

對於初次了解網路分層的人來講，在每一層新增資料報的header，將上一層作為整體打包成為這一層資料的過程，會顯得異常古怪。幹嘛非要這麼繁瑣地做資料打包呢？它的好處又在**呢？

同樣，要理解這個事情，我們只需要考察一下現實生活中的快遞是如何被寄送出去的過程就行了。

例如，我們考慮將乙個包裹，從「蘇州」寄往「綿陽」，看看它會經歷哪些過程。

一般來講，快遞都會經歷乙個聚合的過程（大家可以留意一下每次快遞移動的地理位置記錄）：先從乙個省的某個城市匯集到這個省的省會城市。再從省會城市發往另外乙個省會城市。再在另乙個省會城市，發往相應的所在地。（這一預設規則，也就是網路中類似法律條文的protocol了）

那麼，如果要從蘇州發往綿陽，或許這個包裹經歷的第乙個過程就是要把整個包裹先貼上乙個標籤——「寄往成都」（這個標籤其實就是header，而「被寄送的東西」連同最開始的標籤「寄往綿陽」一起，被用作這一層的package內容去打包）。

為何要「新增寄往成都」這個標籤？因為綿陽屬於四川，而成都是四川的省會。按照上面這一段的規則（也即是按照protocol的規定）：要想成功寄送到綿陽，就必須先把貨物送到四川的省會城市成都。

而到了四川成都後，又會按照剛才的相反順序，一層層地將「四川」「成都」的標籤拿掉，最終寄送到目的地綿陽。

上述過程，也就是網路分層裡面常常遇到的「打包新增header」和「拆包去掉header」的過程。從物理世界的物流管理來講，其實很容易明白這套繁瑣手續背後的動機和考慮。將各個不同的路徑，以統一整合的方式去匯集和轉送，能夠極大地提高整體系統的運輸效率。

每乙個層次只需要負責一小段的點對點的傳送，能夠將任務均衡地分配給每乙個小隊，並且還能把「系統複雜度」獨立地分攤到這些小隊。而整體上，又能將這些分散的職能銜接起來，覆蓋各式各樣的複雜運輸需求。

至於裡面的細節，為什麼要新增header，為什麼要把整個上一層的「header+package內容」作為這一層的package內容？那只不過是現實世界的「套袋打包、再貼標籤」的對應罷了。

有了這樣的「位元流的物流運輸」模型，我們幾乎可以理解網路世界的一切東西。例如，那個神秘而又深奧的「架設梯子」的原理，我們也可以做一番清晰的**。

按照物流運輸模型，所謂的牆，無非就是當我想從所在的a國，同b國交換資訊的時候，發現中間的道路被人為控制了。對應到的傳送快遞的例子是：當我想把「b國的東西」運送回「我所在的a國」時，卻發現負責運輸這個貨物的貨車，在過海關時被攔截下來了。因為a國的邊境有一條規則，凡是從b國發出來的貨物，均不允許通過。（而反過來從a國發往b國的貨物，也不允許通過。）

那怎麼辦呢？

作為a國的海關邊境，它應該存至少乙個允許貨物進入的國家，例如c國。也即是，凡是從c國運輸過來的東西，我a國是允許進入的。（而a國的貨物，也能夠被發往c國。）

而這個時候，如果c國又恰好允許b國的貨物進入它的國內。這時，從b國發出來的貨物，就有辦法被運送到我們自己的a國了。

如何操作呢？

那就很簡單了：先讓這個b國的貨物傳送到c國。然後，再以c國的名義傳送到a國就好了。（而反過來，如果要把a國的東西運輸出去，只需要先傳送到c國，再從c國傳送給b國就好了。）

那麼，網路世界的梯子是怎麼回事呢？就是把剛才那個運輸過程的貨物，換成位元流就好了。既然我a國的網路無法接收到b國的網路所傳送出來的資訊（0、1數字流），那麼，我只需要在c國（能夠同時允許與a國和b國做網路資訊交換的國家），有乙個中轉的伺服器就好了。

這時候，我把對b國的網路訪問請求，直接先打包成傳送給c國伺服器的包裹，先寄送到c國的伺服器裡。再在c國的這個伺服器裡，拆開這層偽裝包裹，把真正發往b國的請求通過c國的伺服器傳送到b國。

接到服務請求的b國，把相應的「響應資訊」先打包成傳送給c國的包裹做中轉。c國的伺服器依舊拆開這個偽裝包裹，把裡面的資訊取出，再從c國伺服器把相應的「響應資訊」傳送到a國。

如此，就成功繞過了a國到b國不允許通行的「牆」限制，實現了「架設梯子」的功能。

希望這個「位元流的物流運輸」模型，能夠幫助你更好地理解這個網路世界。

近期回顧

《精湛技藝的祭品》

《向南的高速公路》

《讀《中國近代史》

vip讚賞專區

全國快遞物流查詢 快遞單號查詢介面api

電商，erp廠商可能需要物流資訊介面，對運單號的物流軌跡進行跟蹤，通常有些免費的不好用，及時性要求達不到，收費的也太貴了。最近發現乙個免費的api介面，及時性非常高，基本上就是實時返回。快遞查詢介面 物流跟蹤介面 是快遞鳥為使用者提供的定製化服務，使用者可將訂單資訊通過快遞鳥訂閱給快遞公司，快遞公司...

curl獲取快遞網物流資訊

最近在做專案中要使用到快遞的物流資訊展示，當時是使用的第三方的介面快遞鳥，但是昨天發現，現在快遞鳥查詢天天快遞的物流資訊是查詢不到的。同時客戶的商品物流運輸就是使用天天快遞，這就尷尬了。同時我發現快遞網這個 是可以動態查詢物流資訊 使用快遞網請求物流資訊的方式是快遞名稱 訂單號.html，我們在專案...

物流 快遞行業實名認證API

快遞實名制 向全國各地推行。翔雲人工智慧開放平台為廣大使用者提供優質身份證 手機號 銀行卡等實名認證 服務，助力解決快遞行業實名認證問題。中華人民共和國反恐怖主義法 以下簡稱 反恐法 中規定，對未落實安全查驗的快遞企業最高可處10萬元以上，50萬元以下罰款。自 反恐法 於2016年1月1日實施以來，...