關於連接埠共用

  以前整Socket編程(VB6.0)有時忘關閉Socket再次啟動時就報連接埠已經被用了，當時的辦法就是重啟系統，後來看到書上介紹一個連接埠唯一標識一個應用程式，於是就高興的認為一個連接埠只能被一個應用程式綁定，這樣和諧的過了一些年，直到有一天發現自己整了一年多的IIS其實可以多個進程(w3p.exe)共用一個80連接埠，於是俺的世界又不和諧了.

為瞭解決這一重大矛盾，作為一個2B程式員，我嘗試了平行宇宙理論，玄理論，直到上帝造物說...-_"，呵呵扯淡了。

下面談一下本人的YY,大神們看了表笑，還望不吝賜教。

 

關於連結的回憶

 小時候還記的廠裡有個總機室，師傅姓王，裡面有個電話交換器具體叫什麼也不清楚，就是一個合子後面連了很多電話線前面很多插空，這些電話線連到廠裡的多個辦公室，小王找小李時需要搖下電話打到總機叫王師傅接，王師傅晚上愛打麻將白天經常接錯線，接外線貌似要層層轉接很麻煩，好在廠裡電話主要用來各部門閑聊扯蛋的，（找遠方親戚一般是寫信或拍電報）由於大家上班無聊會用電話扯蛋，當時經常佔線，小張跟小李正聊到興頭上，現在吳廠張要找小李，但是王師傅說小李正跟小張接著，此時吳廠張發話了，給我拔掉，結果小張那頭突然掉線了，而小李突然發現小張怎麼變聲了.........，當然你可能會想（哥確實想過）為什麼不每個部門兩兩拉根線呢，這樣就不要王師傅轉接了，不過上完高中後（注意不是初中）哥發現這樣一來全國的電話網多少根線都拉不過來，而且就廠裡來說，如果有10個部門，需要每個部門都按十個電話。 哥對於串連的理解也就停留在這個水平上，以至一直誤解了TCP連結，不過看完本文後您會發現以前的電話是真正意義上的流串連（先不提波粒二象性這事了^_^)

TCP連結應該是幻覺

數字線路的關鍵是將資訊編碼後拆成資料包來一份一份發送，因此會有所謂的延遲（編碼解碼轉寄等時間），而以前的電話只要接通後就是按光速傳播的，呵呵

不管是TCP,還是UDP,都是走IP資料報然後由鏈路層轉物理層發送出去的，對IP層發送資料來說TCP跟UDP沒任何區別，TCP的三向交握更是神馬,當然話說的有點絕對了，IP層的資料報中有一個協議識別欄位，目的是在收到IP資料報後決定將這個資料報交TCP驅動還是UDP驅動來處理。從上面的流程說明可以看出所謂的TCP連結是一個幻覺，其本質應該是TCP驅動程式維護的一個結構體（裡面應該有源IP+連接埠，目標IP+連接埠，初始序號，以及上一次收/發資料包的序號等等欄位），而服務端應用程式綁訂連接埠本質是為了TCP驅動在收到TCP資料包時作為路由的標誌。

一個伺服器連接埠能同時跟很多瀏覽器建立TCP連結嗎？

一個服務端連接埠理論上可以建立無限個串連，通過 [Local-IP:Port跟Remote-IP:Port ]組合可以區分每個串連（注意用戶端--串連發起端，每次總使用一個未使用的隨機連接埠），但是由於每個連結需要一定的記憶體空間(包括緩衝視窗)，以及TCP驅動程式需要多個線程來維護這些連結（CPU資源），因此實際上不能同時保持很多個TCP串連。

同個連接埠多個網站怎麼收發資料包？

首先發應該不是問題，TCP驅動將資料包在對應的TCP連結上發回去，用戶端進程就能正確接收了（TCP用戶端不存在連接埠共用的說法）。
直接是收的問題，在TCP前序上沒有特殊的標識的情況(類似cookie的機制，當然正常情況下不應該去改已經存在的TCP協議實現），服務端能做的是在應用程式層上做處理即引進路由代理，根據種種跡象哥發現這個代理可能叫Http.Sys當然Net.TCP Port Sharing Service也很可疑。
好了在假設這個代理存在後，收資料的過程應該是這樣的： 當共用連接埠的某個TCP連結到資料包後，首先將資料包發給代理（就想TCP以前的作法一樣），接著代理根據TCP資料包中的資料具體應該是http協議中的Host前序（即IIS中設定的網站主機頭屬性），將資料轉寄給對應主機頭的網站（更可行的做法是將該Tcp連結的Socket控制代碼給對應的網站處理常式），但不管怎麼樣代理必須要對TCP資料包中的資料區段進行分析。
另外Net.TCP也應該在TCP資料報的資料區有額外標的識別，因為我們使用WCF的Net.TCP時，指定服務端點屬性其實類似IIS中的主機頭設定，當然以上都是YY。。。