常識一：檔案控制代碼限制

在linux下編寫網路伺服器程式的朋友肯定都知道每一個tcp連線都要佔一個檔案描述符，一旦這個檔案描述符使用完了，新的連線到來返回給我們的錯誤是“Socket/File:Can'topen so many files”。

這時你需要明白作業系統對可以開啟的最大檔案數的限制。

• 程序限制

  • 執行ulimit -n 輸出1024，說明對於一個程序而言最多隻能開啟1024個檔案，所以你要採用此預設配置最多也就可以併發上千個TCP連線。

  • 臨時修改：ulimit -n1000000，但是這種臨時修改只對當前登入使用者目前的使用環境有效，系統重啟或使用者退出後就會失效。

  • 永久修改：編輯/etc/security/limits.conf 檔案， 修改後內容為

    * soft nofile 1000000

    * hard nofile 1000000

• 全侷限制

  • 執行 cat/proc/sys/fs/file-nr 輸出9344 0592026，分別為：1.已經分配的檔案控制代碼數，2.已經分配但沒有使用的檔案控制代碼數，3.最大檔案控制代碼數。但在kernel2.6版本中第二項的值總為0，這並不是一個錯誤，它實際上意味著已經分配的檔案描述符無一浪費的都已經被使用了 。

  • 我們可以把這個數值改大些，用 root 許可權修改 /etc/sysctl.conf 檔案:

    fs.file-max = 1000000

    net.ipv4.ip_conntrack_max = 1000000

    net.ipv4.netfilter.ip_conntrack_max = 1000000

常識二：埠號範圍限制？

作業系統上埠號1024以下是系統保留的，從1024-65535是使用者使用的。由於每個TCP連線都要佔一個埠號，所以我們最多可以有60000多個併發連線。我想有這種錯誤思路朋友不在少數吧？（其中我過去就一直這麼認為）

我們來分析一下吧

• 如何標識一個TCP連線：系統用一個4四元組來唯一標識一個TCP連線：{local ip, local port,remoteip,remoteport}。好吧，我們拿出《UNIX網路程式設計：卷一》第四章中對accept的講解來看看概念性的東西，第二個引數cliaddr代表了客戶端的ip地址和埠號。而我們作為服務端實際只使用了bind時這一個埠，說明埠號65535並不是併發量的限制。

• server最大tcp連線數：server通常固定在某個本地埠上監聽，等待client的連線請求。不考慮地址重用（unix的SO_REUSEADDR選項）的情況下，即使server端有多個ip，本地監聽埠也是獨佔的，因此server端tcp連線4元組中只有remoteip（也就是client ip）和remoteport（客戶端port）是可變的，因此最大tcp連線為客戶端ip數×客戶端port數，對IPV4，不考慮ip地址分類等因素，最大tcp連線數約為2的32次方（ip數）×2的16次方（port數），也就是server端單機最大tcp連線數約為2的48次方。

要寫網路程式就必須用Socket，這是程式設計師都知道的。而且，面試的時候，我們也會問對方會不會Socket程式設計？一般來說，很多人都會說，Socket程式設計基本就是listen，accept以及send，write等幾個基本的操作。是的，就跟常見的檔案操作一樣，只要寫過就一定知道。


對於網路程式設計，我們也言必稱TCP/IP，似乎其它網路協議已經不存在了。對於TCP/IP，我們還知道TCP和UDP，前者可以保證資料的正確和可靠性，後者則允許資料丟失。最後，我們還知道，在建立連線前，必須知道對方的IP地址和埠號。除此，普通的程式設計師就不會知道太多了，很多時候這些知識已經夠用了。最多，寫服務程式的時候，會使用多執行緒來處理併發訪問。


我們還知道如下幾個事實：

1。一個指定的埠號不能被多個程式共用。比如，如果IIS佔用了80埠，那麼Apache就不能也用80埠了。

2。很多防火牆只允許特定目標埠的資料包通過。

3。服務程式在listen某個埠並accept某個連線請求後，會生成一個新的socket來對該請求進行處理。


於是，一個困惑了我很久的問題就產生了。如果一個socket建立後並與80埠繫結後，是否就意味著該socket佔用了80埠呢？如果是這樣的，那麼當其accept一個請求後，生成的新的socket到底使用的是什麼埠呢（我一直以為系統會預設給其分配一個空閒的埠號）？如果是一個空閒的埠，那一定不是80埠了，於是以後的TCP資料包的目標埠就不是80了--防火牆一定會組織其通過的！實際上，我們可以看到，防火牆並沒有阻止這樣的連線，而且這是最常見的連線請求和處理方式。我的不解就是，為什麼防火牆沒有阻止這樣的連線？它是如何判定那條連線是因為connet80埠而生成的？是不是TCP資料包裡有什麼特別的標誌？或者防火牆記住了什麼東西？


後來，我又仔細研讀了TCP/IP的協議棧的原理，對很多概念有了更深刻的認識。比如，在TCP和UDP同屬於傳輸層，共同架設在IP層（網路層）之上。而IP層主要負責的是在節點之間（End 

to End）的資料包傳送，這裡的節點是一臺網路裝置，比如計算機。因為IP層只負責把資料送到節點，而不能區分上面的不同應用，所以TCP和UDP協議在其基礎上加入了埠的資訊，埠於是標識的是一個節點上的一個應用。除了增加埠資訊，UPD協議基本就沒有對IP層的資料進行任何的處理了。而TCP協議還加入了更加複雜的傳輸控制，比如滑動的資料傳送視窗（Slice Window），以及接收確認和重發機制，以達到資料的可靠傳送。不管應用層看到的是怎樣一個穩定的TCP資料流，下面傳送的都是一個個的IP資料包，需要由TCP協議來進行資料重組。


所以，我有理由懷疑，防火牆並沒有足夠的資訊判斷TCP資料包的更多資訊，除了IP地址和埠號。而且，我們也看到，所謂的埠，是為了區分不同的應用的，以在不同的IP包來到的時候能夠正確轉發。


TCP/IP只是一個協議棧，就像作業系統的執行機制一樣，必須要具體實現，同時還要提供對外的操作介面。就像作業系統會提供標準的程式設計介面，比如Win32程式設計介面一樣，TCP/IP也必須對外提供程式設計介面，這就是Socket程式設計介面--原來是這麼回事啊！


在Socket程式設計接口裡，設計者提出了一個很重要的概念，那就是socket。這個socket跟檔案控制代碼很相似，實際上在BSD系統裡就是跟檔案控制代碼一樣存放在一樣的程序控制代碼表裡。這個socket其實是一個序號，表示其在控制代碼表中的位置。這一點，我們已經見過很多了，比如檔案控制代碼，視窗控制代碼等等。這些控制代碼，其實是代表了系統中的某些特定的物件，用於在各種函式中作為引數傳入，以對特定的物件進行操作--這其實是C語言的問題，在C++語言裡，這個控制代碼其實就是this指標，實際就是物件指標啦。


現在我們知道，socket跟TCP/IP並沒有必然的聯絡。Socket程式設計介面在設計的時候，就希望也能適應其他的網路協議。所以，socket的出現只是可以更方便的使用TCP/IP協議棧而已，其對TCP/IP進行了抽象，形成了幾個最基本的函式介面。比如create，listen，accept，connect，read和write等等。


現在我們明白，如果一個程式建立了一個socket，並讓其監聽80埠，其實是向TCP/IP協議棧聲明瞭其對80埠的佔有。以後，所有目標是80埠的TCP資料包都會轉發給該程式（這裡的程式，因為使用的是Socket程式設計介面，所以首先由Socket層來處理）。所謂accept函式，其實抽象的是TCP的連線建立過程。accept函式返回的新socket其實指代的是本次建立的連線，而一個連線是包括兩部分資訊的，一個是源IP和源埠，另一個是宿IP和宿埠。所以，accept可以產生多個不同的socket，而這些socket裡包含的宿IP和宿埠是不變的，變化的只是源IP和源埠。這樣的話，這些socket宿埠就可以都是80，而Socket層還是能根據源/宿對來準確地分辨出IP包和socket的歸屬關係，從而完成對TCP/IP協議的操作封裝！而同時，放火牆的對IP包的處理規則也是清晰明瞭，不存在前面設想的種種複雜的情形。


明白socket只是對TCP/IP協議棧操作的抽象，而不是簡單的對映關係，這很重要！