常見的基礎類問題，然後經常有人冒出各種雷人的言論什麽埠復用，什麽鏈路復用出來。
首先埠是個什麽玩意兒？這貨是跟協定相關的，最常見就TCP和UDP協定定義了埠。什麽IP協定埠這種話一出口就說明是外行。
然後埠是幹啥的？埠最早出現在TCP，它的確就是用來標記連線的。一個TCP連線用四個參數區分，倆終端IP和倆終端埠。
所以埠限制指的是什麽？是兩個IP終端之間可以建立的最大的TCP連線數量。而不是某一個終端對不同終端可以建立的連線數量。
也就是說，這個限制是特定的兩台機器A和B可以建立的連線數量，而且這個連線數量的理論上限也不是65536，而是65536的平方，因為兩個終端之間的連線兩邊都可以用任意埠，兩兩組合有四個G的數量。
但是考慮到埠和服務是繫結的，例如一般情況下只有在HTTP伺服器80埠建立的連線，才用於發送HTTP請求。還有很多埠被系統保留起來不用於建立一般的TCP連線。所以實際可以用的埠組合數量遠低於理論數值，但那也是一個難以企及的數量，壓根兒不用擔心……
真正會造成埠不夠用的情況，一般只會出現在NAT、閘道器、負載均衡器這些東西上。這些東西的特點是，後面很多台終端/伺服器，對外只有一個IP地址。這樣就會讓這個IP地址上的埠壓力山大。
舉個例子，有兩個互相不通的內網，每個內網裏面有一千台終端。這兩個內網各自都只有一個公網IP，兩個內網之間的通訊只能走公網。這時候，這個天文數位的連線數量限制就成了兩個一千台終端內網之間的連線數量限制，一下子就感覺壓力上來了……
這也是為什麽我們要盡快推動IPv6的普及的根本原因。IP地址用盡短期內不會造成什麽影響，但是隨著網路終端的越來越多，不僅僅是埠資源，網路裝置轉發帶來的延遲和資源損耗占用，都會成為問題。
最後簡單聊聊監聽埠。
如上文所述，通常情況下埠限制的TCP連線數量是一個天文數位，是不可能達到的。但是有一個更麻煩的事情就是監聽埠限制。
的確兩個終端之間可以建立的TCP連線理論上限是4G，但是要與另一台伺服器的 特定套用/ 建立 特定用途 的TCP連線，最常見的方法就是 約定埠 。
例如我們約定80埠用於建立HTTP連線，這個時候當我們與伺服器的80埠建立TCP連結的時候，伺服器就知道這個連線是用於傳輸HTTP請求和響應的。更重要的是，伺服器要知道是由WebServer套用來處理這個埠上建立的連線。
那麽伺服器是怎麽知道要由WebServer套用來處理這個埠上建立的連線呢？這就是所謂的監聽所幹的事情。監聽，本質上就是給作業系統發個註冊資訊：「所有在XXXX埠上建立的連線，都讓我來處理。」
當然，你可以不使用80埠，也可以不使用約定埠的方式來建立特定用途的連線。但是不得不承認這是目前最成熟的使用方式，並且幾乎所有的軟體都遵循這套原則。
但在這套原則下就會存在一些問題：
首先顯而易見的就是埠沖突，你IIS是WebServer、我Apache也是WebServer、tomcat說我也是，他們預設啟動都要去監聽80埠，但是作業系統只可能把一個埠上的連線給發送到一個套用上去，作業系統也不知道這個連線到底要發送給哪個WebServer。這就是最典型的一個問題，埠沖突。
接下來是客戶端的問題，我們存取一個網站事實上不可能只建立一個TCP連線，我們會同時開啟很多網頁，也會同時下載很多資源。一般來說，瀏覽器會控制對同一個網站同時開啟的連線數不超過5-10個，但是如果我們是什麽多點傳輸的下載檔，我開一百個連線同時下載多個位置的檔內容行不行？當然可以。
但是，正如同一台伺服器上可以執行多個服務套用一樣，一台客戶端也可以執行多個客戶端應用程式。如果這些客戶端應用程式都要與同一伺服器的同一埠建立連線，那又該怎麽辦呢？最簡單的方式就是使用一定範圍內的隨機埠來建立連線。
但是並不是所有的埠都能被拿來建立連線。如果有些埠被監聽了，那麽這些埠是不能被拿來建立連線的。還有一些埠可能目前沒有被監聽，但是通常他們被保留來用作一些特殊用途，例如80埠，通常會被保留用於HTTP協定的連線。
所以 對於同一伺服器的提供的同一服務，埠的數量的確也會限制你可以建立的連線的數量 。
但通常來說這不會成為問題。除非，是閘道器、NAT、負載均衡，這些裝置上，這個問題就會出現的更加頻繁了……
