• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            tqsheng

            go.....
            隨筆 - 366, 文章 - 18, 評論 - 101, 引用 - 0
            數(shù)據(jù)加載中……

            slickedit 宏設(shè)置

                 摘要: <br>#define DefineProHInit(_Struct_) DefineVal(_Struct_); \        void Init##_Struct_(void); \        struct...  閱讀全文

            posted @ 2012-09-24 12:55 tqsheng 閱讀(581) | 評論 (0)編輯 收藏

            cpu 親和力

              與“soft affinity”相對的是“hard affiinty”(硬相關(guān)),使用它可以控制哪個CPU運行哪些線程。

              在系統(tǒng)引導(dǎo)的時候,系統(tǒng)決定該計算機中有幾個CPU可以被使用。在應(yīng)用程序中,可以呼叫GetSystemInfo函數(shù)來取得CPU的數(shù)量。

              一般地,線程可以運行在任何一個CPU上,當(dāng)然,你可以使用Windows自帶的“soft affinity”機制,讓W(xué)indows自動分配CPU給一個線程。

              或許,你更希望能夠?qū)Ψ峙浣o線程的CPU有一些限制,使用“hard affinity”機制。

              SetProcessAffinityMask函數(shù)限制一個特定的進程只能運行在CPU的一個子集上。

             

            BOOL SetProcessAffinityMask(
               HANDLE hProcess,
               DWORD_PTR dwProcessAffinityMask);

             

              該函數(shù)得第一個參數(shù)指明了要被限制的進程,第二個參數(shù)是一個“位屏蔽”數(shù)據(jù),里面的每個位表示一個CPU代號(從0開始標(biāo)號),比如0x00000001表示選中CPU 0,也就是“該進程中的線程”只能運行在CPU 0上了;0x00000005表示同時選中CPU 0和CPU 2。

              一個進程中的子進程可以繼承該進程的相關(guān)性,也可以使用作業(yè)內(nèi)核對象對某些進程限制在要求的一組CPU上執(zhí)行。

             

              可以調(diào)用GetProcessAffinityMask函數(shù)來取得一個進程相關(guān)性屏蔽信息。

             

            BOOL GetProcessAffinityMask(
               HANDLE hProcess,
               PDWORD_PTR pdwProcessAffinityMask,
               PDWORD_PTR pdwSystemAffinityMask);

              該函數(shù)通過第二個參數(shù)返回指定進程的CPU的相關(guān)性信息,同時可以通過第三個參數(shù)返回系統(tǒng)相關(guān)性信息。系統(tǒng)相關(guān)性指明系統(tǒng)的哪些CPU可以處理線程,進程的相關(guān)性始終是系統(tǒng)相關(guān)性的子集。

             

              以上討論的是如何把一個進程中的所有線程限制在一組CPU上。有的時候想要把進程的一個具體線程限制在一組CPU上。

              SetThreadAffinityMask函數(shù)可以限制某一個線程只能運行在一組CPU上。

            DWORD_PTR SetThreadAffinityMask(
               HANDLE hThread,
               DWORD_PTR dwThreadAffinityMask);

             

              該函數(shù)的第二個參數(shù)的意義和SetProcessAffinityMask函數(shù)中的第二個參數(shù)相同。也必須指明了一個正確的CPU子集,限制指定的線程只能運行在這個CPU子集上。該函數(shù)返回原來的線程的相關(guān)信息。

              比如,現(xiàn)在有4個線程和4個可用的CPU,你想讓線程1獨占CPU 0,讓其他3個線程只能運行在CPU 1、CPU 2、CPU 3上,可以如下編碼:

            SetThreadAffinityMask(hThread0, 0x00000001);
            SetThreadAffinityMask(hThread1, 0x0000000E);
            SetThreadAffinityMask(hThread2, 0x0000000E);
            SetThreadAffinityMask(hThread3, 0x0000000E);

              使用“hard affinity”機制來強行限制一個線程只能運行在一組CPU上往往是不當(dāng)?shù)摹_@樣會降低CPU的利用率。

              可用將一個理想的CPU分配一個線程。SetThreadIdealProcessor函數(shù)可用做到這一點:

            DWORD SetThreadIdealProcessor(
               HANDLE hThread,
               DWORD dwIdealProcessor);

              該函數(shù)的第二個參數(shù)不是位屏蔽數(shù)據(jù),而是一個0~31(32位系統(tǒng))或0~63(64位系統(tǒng))的整數(shù)。該數(shù)據(jù)指明首選的CPU。也可以傳遞MAXIMUM_PROCESSORS表明當(dāng)前沒有理想的CPU。

             

              可以在一個程序的開始階段處理相關(guān)性,代碼類似如下的代碼:

            // 加載一個EXE文件映像
            PLOADED_IMAGE pLoadedImage = ImageLoad(szExeName, NULL);


            // 取得剛才加載的EXE文件的配置信息

            IMAGE_LOAD_CONFIG_DIRECTORY ilcd;
            GetImageConfigInformation(pLoadedImage, &ilcd);

            // 更改進程親掾性

            ilcd.ProcessAffinityMask = 0x00000003; // I desire CPUs 0 and 1

            // 保存新的加載信息(包含剛才設(shè)置的親掾性)

            SetImageConfigInformation(pLoadedImage, &ilcd);
            ImageUnload(pLoadedImage);     // 從內(nèi)存卸載映像

            posted @ 2012-09-19 23:19 tqsheng 閱讀(491) | 評論 (0)編輯 收藏

            字號、pt(點數(shù)或磅)、px(像素)、inch(英寸)、cm(厘米)之間關(guān)系對照表

            字號、pt(點數(shù)或磅)、px(像素)、inch(英寸)、cm(厘米)之間關(guān)系對照表

            在印刷排版中,“point”是一個絕對的單位,它等于 1/72 英寸,可以用尺子丈量的,物理的英寸。但在 CSS 中 pt 的含義卻非如此,例如我們指定一個字體是 9pt,我們會以為按照 CSS 規(guī)范,它等于:

              9 * 1/72 = 1/8 inch

              這是一個誤解,因為我們的顯示器被分割為了一個個的像素,單個像素只能有一種顏色 (為了簡化,這里暫不討論次像素反鋸齒技術(shù)),要在屏幕上顯示,必須先把以 pt 為單位的長度轉(zhuǎn)換為以像素為單位的長度,這個轉(zhuǎn)換的媒介,就是 DPI (事實上,這里的所謂的 DPI,是操作系統(tǒng)和瀏覽器中使用的術(shù)語,即為 PPI, pixels per inch,和掃描儀、打印機、數(shù)碼相機中的 DPI 是不同的概念)。

              例如,無論在哪個操作系統(tǒng)中,F(xiàn)irefox 瀏覽器默認(rèn)的 DPI 都是 96,那么實際上 9pt = 9 * 1/72 * 96 = 12px。

              所以,雖然“DPI”中的“I”和“1pt 等于 1/72 inch”中的“inch”,都不代表物理上的英寸,但這兩個單位互相之間是相等的,也就在相乘中約掉了。

              那么,真實的物理長度怎么計算呢?請拿出一把尺子,丈量你的顯示器的可見寬度 (我這里是 11.2992 英寸),除以橫向分辨率 (我這里是 1024 像素),得到的就是每個像素的物理長度。

              現(xiàn)在我們可以回答這樣一個問題,網(wǎng)頁上 9pt 的字體究竟占用了多寬的空間?
                  答案是:

              9 * 1/72 * 96 * 11.2992 / 1024 = 0.1324 英寸 = 0.3363 厘米。


            CSS相對長度單位(relative length unit)

              CSS相對長度單位中的相對二字,表明了其長度單位會隨著它的參考值的變化而變化,不是固定的。

              以下是CSS相對長度單位列表:

            CSS相對長度單位 說明
            em 元素的字體高度The height of the element's font
            ex 字母x的高度The height of the letter "x"
            px 像素Pixels
            % 百分比Percentage

            CSS絕對長度單位(absolute length unit)
            絕對長度單位是一個固定的值。比如我們常用的有mm,就是毫米的意思。

            以下是CSS絕對長度單位列表:

            CSS絕對長度單位 說明
            in 英寸Inches (1 英寸 = 2.54 厘米)
            cm 厘米Centimeters
            mm 毫米Millimeters
            pt 點Points (1點 = 1/72英寸)
            pc 皮卡Picas (1 皮卡 = 12 點)


            字號

            1. 企業(yè)名稱(TRADE NAME):通常指自然人如個體工商戶或個人合伙經(jīng)營的店名。
            2. 名聲
            3. 是指印刷用活字的大小,是從活字的字背到字腹的距離。

            我國的活字采用以點數(shù)制為輔、號數(shù)制為主的混合制來計量。

            ■ 點數(shù)制
            點數(shù)制又叫磅數(shù)制,是英文point的音譯,縮寫為P,既不是公制也不是英制,是印刷中專用的尺度。
            我國大都使用英美點數(shù)制。
            1點(1P)=0.35146mm

            ■ 號數(shù)制
            號數(shù)制是以互不成倍數(shù)的幾種活字為標(biāo)準(zhǔn),加倍或減半自成體系。
            字號的大小可以分為以下四個序列。
            [*]四號序列:一號、四號、小六號

            [*]五號序列:初號、二號、五號、七號

            [*]小五號序列:小初號、小二號、小五號、八號

            [*]六號序列:三號、六號

            ■ 號數(shù)、點數(shù)制對照表
            序號          字號            點數(shù)         尺寸(mm)
                                              72             25.305
                        大特號            63            22.142
                         特號              54            18.979
                         初號              42            14.761
                        小初號           36            12.653
                        大一號          31.5          11.071
                      一(頭)號      28             9.841
                         二號              21            7.381
                        小二號           18            6.326
            10            三號             16            5.623
            11            四號             14            4.920
            12           小四號           12           4.218
            13            五號            10.5          3.690
            14           小五號           9             3.163
            15            六號              8            2.812
            16           小六號        6.875        2.416
            17            七號           5.25         1.845
            18            八號            4.5          1.581

            ■ 說明
            從上表中可以看出,常用的MS-WORD軟件中字號的大小與印刷業(yè)中字號的大小是不一致的。如MS-WORD中的二號字是22磅,但在印刷業(yè)中應(yīng)該是21磅。

              一般表述字體大小的計量單位有兩種,一種是漢字的字號,如初號、小初、一號、…七號、八號;另一種是用國際上通用的“磅”來表示,如4、4.5、10、12、…48、72等。 
              
              中文字號中,“數(shù)值”越大,字就越小,所以八號字是最小的;在用“磅”表示的字號時,數(shù)值越小,字符的尺寸越小,數(shù)值越大,字符的尺寸越大。1磅有多大呢?2.83磅等于1毫米,所以28號字大概就是一厘米高的字,約相當(dāng)于中文字號中的一號字。
             
              我們常說的“宋體,9”,表示的單位其實是磅,也就是   9   磅的宋體。 
              
              關(guān)于像素和磅的關(guān)系,我們來換算一下。在小字體的時候,分辨率是   96dpi   ,也就是說一英寸能顯示   96   個像素;9   磅是   1/8   英寸,所以   96/8=12   像素。也就是說,我們通常見到的字體就是這種   12x12   點陣的字體了。

              另外,在大字體的時候,分辨率是   120dpi   ,9   磅是   1/8   英寸,所以   120/8=15   ,就是說大字體時,顯示的   9   磅字體其實是   15x15   點陣的字體。

            posted @ 2012-09-18 11:01 tqsheng 閱讀(434) | 評論 (0)編輯 收藏

            VC2005 編譯Win7以管理員權(quán)限啟動的可執(zhí)行程序

             

            VC2005 編譯Win7以管理員權(quán)限啟動的可執(zhí)行程序

                由于在Vista、Win7系統(tǒng)增加了UAC功能,導(dǎo)致很多程序啟動時需要用戶以手動點擊鼠標(biāo)右鍵,選擇“以管理員權(quán)限啟動”來啟動應(yīng)用程序。

                為了方便用戶,VC程序員可以自己在程序中添加以管理員權(quán)限啟動的功能,其實非常簡單,將以下代碼復(fù)制到記事本中,保存為.manifest后綴名的文件

            1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  
            2. <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">   
            3.   <assemblyIdentity version="1.0.0.0"  
            4.      processorArchitecture="X86"  
            5.      name="AnyNameYouWant"  
            6.      type="win32"/>   
            7.   <description>Description of your application</description>   
            8.   <!-- Identify the application security requirements. -->  
            9.   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">  
            10.     <security>  
            11.       <requestedPrivileges>  
            12.         <requestedExecutionLevel  
            13.           level="requireAdministrator"  
            14.           uiAccess="false"/>  
            15.         </requestedPrivileges>  
            16.        </security>  
            17.   </trustInfo>  
            18. </assembly>  

            然后進入該項目的屬性對話框,選擇“清單工具”的“輸入與輸出”,將此manifest文件附加進去重新生成即可。

            posted @ 2012-09-16 16:39 tqsheng 閱讀(405) | 評論 (0)編輯 收藏

            the best Open Source projects written in VC++/MFC.

            Introduction

            This article lists of some of the best Open Source projects written in VC++/MFC.

            Background

            CodeProject has the best source code repository for VC++ developers. But another site Sourceforge.net also has some of the best quality projects available for VC++. Here I list some of the best open source projects written in Visual C++. These are very good references for all VC++ programmers.

            List of Best Open Source Projects Written in VC++/MFC

            1. 7-Zip (http://sourceforge.net/projects/sevenzip/) 
              7-Zip is a file archiver with a high compression ratio. The program supports 7z, ZIP, CAB, RAR, ARJ, LZH, CHM, GZIP, BZIP2, Z, TAR, CPIO, RPM and DEB formats. Compression ratio in the new 7z format is 30-50% better than ratio in ZIP format.
            2. eMule (http://sourceforge.net/projects/emule/):
              eMule is a filesharing client which is based on the eDonkey2000 network but offers more features than the standard client.
            3. eMule Plus (http://sourceforge.net/projects/emuleplus/) :
              eMule Plus is an evolution of the original eMule project, created to improve its abilities and features, in both work efficiency and user interface.
            4. eMule Morph (http://sourceforge.net/projects/emulemorph/):
              eMule Morph Mod - eMule Modding Project.
            5. FileZilla (http://sourceforge.net/projects/filezilla/):
              FileZilla is a fast FTP and SFTP client for Windows with a lot of features. FileZilla Server is a reliable FTP server.
            6. KeePass Password Safe (http://sourceforge.net/projects/keepass/):
              KeePass Password Safe is a free, open source, light-weight and easy-to-use password manager for Windows. You can store your passwords in a highly-encrypted database, which is locked with one master password or key file.
            7. K-Meleon (http://sourceforge.net/projects/kmeleon/):
              K-Meleon is a fast and customizable web browser that can be used instead of Internet Explorer on Windows. Powered by the same Gecko engine as the Firefox and Mozilla browsers, K-Meleon provides users with a secure browsing experience.
            8. MiKTeX (http://sourceforge.net/projects/miktex/):
              MiKTeX is an up-to-date implementation of TeX & Friends for Windows (all current variants).
            9. MyNapster (http://sourceforge.net/projects/mynapster/):
              MyNapster is a Win32 client using Gnutella and IRC for chat. It is based on Gnucleus and utilizes MFC (works with WINE).
            10. Nokia Composer (http://sourceforge.net/projects/nokiacomposer/):
              This is a Win32, VC++ MFC application to manage Nokia mobile phones melodies. Includes VC++ source code and Rational Rose UML model.
            11. Peters Backup (http://sourceforge.net/projects/pbackup):
              Peters Backup is a program for backing up your important data files on to diskette, zip drive, fixed disk or CD/RW. It uses an extremely efficient compression algorithm. It keeps track of all versions of your files in full and incremental backups.
            12. Password Safe (https://sourceforge.net/projects/passwordsafe/):
              Password Safe is a password database utility. Users can keep their passwords securely encrypted on their computers. A single Safe Combination unlocks them all.
            13. RenFile (http://sourceforge.net/projects/renfile/):
              Rename files and folders in bulk using this VC++ .NET program.
            14. Shareaza (https://sourceforge.net/projects/shareaza/):
              Multi-network peer-to-peer file-sharing client supporting Gnutella2, Gnutella1, eDonkey2000/eMule and BitTorrent protocols. Using C++, MFC and ATL, for Windows.
            15. SunshineUN (http://sourceforge.net/projects/sunshineun/):
              SunshineUN is a free Napster based file sharing program for Opennap/Slavanap which allows you to share and download multiple files of different types for example music, pictures and videos. It is for Windows and it is written in C++ using MFC .
            16. TortoiseCVS (http://sourceforge.net/projects/tortoisecvs/):
              TortoiseCVS is an extension for Microsoft Windows Explorer that makes using CVS fun and easy. Features include: colored icons, tight integration with SSH, and context-menu interactivity.
            17. TortoiseSVN (http://sourceforge.net/projects/tortoisesvn):
              TortoiseSVN is a Subversion (SVN) client, implemented as a Windows shell extension. It's intuitive and easy to use, since it doesn't require the Subversion command line client to run. Simply the coolest Interface to (Sub)Version Control!
            18. WinDirStat: Windows Directory Statistics (http://sourceforge.net/projects/windirstat/):
              WinDirStat (WDS) is a disk usage statistics viewer and cleanup tool for Windows. It shows disk, file and directory sizes in a treelist as well as graphically in a treemap, much like KDirStat or SequoiaView.
            19. WinDjView (http://sourceforge.net/projects/windjview):
              WinDjView is a fast, compact and powerful DjVu viewer for Windows with continuous scrolling and advanced printing options, based on free DjVuLibre library. MacDjView is a simple DjVu viewer for Mac OS X, also with continuous scrolling.
            20. C++ Library for Windows (http://sourceforge.net/projects/rulib):
              A C++ library for the Windows platform containing classes for MIME, video capture, socket, Windows registry, files, images, and other basic purposes.
            21. WinMerge (https://sourceforge.net/projects/winmerge/):
              WinMerge is a Win32 tool for visual difference display and merging, for both files and directories. Unicode support. Flexible syntax coloring editor. Windows Shell integration. Regexp filtering. Side-by-side line diff and highlights diffs inside lines.
            22. Disk Cleaner (http://sourceforge.net/projects/dclean/):
              Disk Cleaner is a tool to quickly and easily free disk space that is used by temporary files like the system temporary folder, the Internet Explorer Cache and Cookies folder, and the Recycle Bin. It can be expanded with text-based plug-ins & DLLs.
            23. Shared IIS Server Log/Bandwidth-Analyzer (http://sourceforge.net/projects/sharediis/):
              This utility is intended to be used to analyze and present a per-site (in case of WWW logs), or (in case of FTP logs) a per-web summary of bandwidth used, hits, and average bandwidth used.
            24. Remote Control Center (http://sourceforge.net/projects/remotectrlctr/):
              Remote Control Center is an application designed to help a system/network administrators taking control of remote devices in the network from a single GUI.
            25. RevConnect - Enhanced DC++ (http://sourceforge.net/projects/reverseconnect/):
              RevConnect is a file sharing program based on DC++. It is fully compatible with the Direct Connect network and made some major features.
            26. Show Traffic (http://sourceforge.net/projects/showtraf):
              "Show Traffic" monitors network traffic on the chosen network interface and displays it continuously. It could be used for locating suspicious network traffic or to evaluate current utilization of the network interface.
            27. War FTP Daemon Engine (http://sourceforge.net/projects/wfde/):
              A generic C++ class library for FTP server implementations, including a full-featured, mature FTP server.
            28. AxCrypt - File Encryption for Windows (http://sourceforge.net/projects/axcrypt/):
              AxCrypt - Personal Privacy and Security with AES-128 File Encryption and Compression for Windows 98/ME/NT/2K/XP. Double-click to automatically decrypt and open documents. Store strong keys on removable USB-devices.
            29. Open Source Firewall For Windows (http://sourceforge.net/projects/firewallpapi/):
              FirewallPAPI is an open source firewall for Windows 2000 and above. It is a simple utility for filter network traffic.
            30. MinkSonic Jukebox (http://sourceforge.net/projects/minksonic):
              MFC-based front-end to Winamp that provides jukebox behavior as well as "explorer-like" MP3 library management, a web-based network interface and MP3 frame error detection/correction.
            31. p2pfire: super p2p driver firewall (http://sourceforge.net/projects/p2pfire):
              Super P2P firewall 32/64 bits (driver + application).
            32. WABAccess (http://sourceforge.net/projects/wabaccess/):
              The WABAccess component gives an access to the Windows Address Book (or WAB) used by Outlook Express. It's a COM/ATL component that gives an access from Visual Basic language or Scripting language (VBS) to WAB.
            33. Yet Another Fractal Explorer (http://sourceforge.net/projects/yafe):
              Yet Another Fractal Explorer is an interactive fractal renderer for Windows. It features extremely simple and intuitive user interface and is capable of producing mathematically-sound renderings.
            34. CDDA Ripper XP (http://sourceforge.net/projects/cddarip):
              CDDA Ripper XP is an audio CD ripper program that provides support for NT/2000/XP natively (ASPI manager is optional). It supports WAV-MP3-OGG-FLAC-ACM codec encoding and can be used to rip multiple CDs. It uses newest encoders like LAME and Ogg/Vorbis.
            35. [ mp3 - explorer ] (http://sourceforge.net/projects/mp3explorer):
              [ mp3 - explorer ] is a MP3 Manager providing advanced features: multi-folders file scanning with cache - id3v1 and id3v2 tagging - Intellitag - HTML view of the tracks displaying album cover and Lyrics.
            36. ultraMaGE (http://sourceforge.net/projects/ultramage):
              ultraMage is a powerful dual-window file manager for Windows with many useful features like bookmarks, advanced file operations and folder synchronization. It is still very easy to use, because the user interface is similar to that of Windows Explorer.
            37. WinTarBall (http://sourceforge.net/projects/wintarball/):
              WinTarBall adds a control panel and an Explorer shell extension that allow users to compress directories into .tgz or .tbz files simply by right-clicking on them and choosing "compress to tarball".
            38. XML Explorer (http://sourceforge.net/projects/xpathexplorer/):
              A utility to query XML files using XPath and also extend XPath to more documents than one. Win32 platform/MFC.
            39. Emerge Desktop (http://sourceforge.net/projects/emerge/):
              Emerge is an alternate Windows shell. Its purpose is to replace Windows Explorer as your desktop user interface, providing similar functionality, with the additional plugins to provide even more.
            40. Folder Size for Windows (http://sourceforge.net/projects/foldersize/):
              Folder Size for Windows adds a new column to the Windows Explorer details view that displays the sizes of files and folders. A service scans your hard disk in the background and caches the results. Designed for performance!
            41. Rename-It! (https://sourceforge.net/projects/renameit/):
              Define some filters to apply to a list of files, which can be in multiple folders, to rename the whole list at once. It checks the file names, integrates in the Shell (via Explorer context menu), supports regular expressions, ID3 tags, and much more.
            42. ShellWM (http://sourceforge.net/projects/shellwm/):
              Windows skinning application to be used with a Win32 Shell replacement (like Litestep, geOshell, sharpE, etc.) or just native Explorer.
            43. Blackbox for Windows (http://sourceforge.net/projects/bb4win/):
              Blackbox for Windows is an alternative shell for Microsoft Windows. It is based stylistically on the Blackbox window manager for the X Window System, however it does not use the same codebase except for the gradient rendering code.
            44. HideThatWindow! (http://sourceforge.net/projects/hidethatwindow/):
              HideThatWindow! enables you to Hide or Show a window; minimize, maximize and restore its original size (or change the size to fit your needs). Disable the window's taskbar button or send it to tray. Other features are transparency, docking and top-most.
            45. Security & Privacy Complete 3 (http://sourceforge.net/projects/cmia/):
              Security & Privacy Complete is mainly a security tool for Windows. It can disable all services which might be a security-risk, harden registry settings... Also included privacy features for Internet Explorer, Media Player, and of course: Mozilla Firefox.
            46. TaskSwitchXP (http://sourceforge.net/projects/taskswitchxp/):
              TaskSwitchXP provides the same functionality as the existing application switching mechanism in Windows XP today. In addition to displaying an icon list, however, the application will also show a thumbnail preview of the window that will be switched to.
            47. Windows Process Tools (http://sourceforge.net/projects/winpstools):
              Command-line utilities to find, list, and terminate running processes under Windows, similar to the Unix ps and kill commands. Good for command-line folks who don't like to use the Windows Task Manager.
            48. OpenSTA (http://sourceforge.net/projects/opensta/):
              Open System Testing Architecture - a distributed software testing architecture designed around CORBA. The current toolset has the capability of performing scripted Web (HTTP and HTTPS) heavy load tests with performance measurements from Win32 platforms.
            49. MFC MUTE (http://sourceforge.net/projects/mfc-mute-net/):
              MFC MUTE is a Microsoft Windows *ONLY* client for the MUTE anonymous P2P network. This application derives from the original MUTE (mute-net.sourceforge.net) app supporting anonymous file sharing. The GUI is the best/most polished Windows MUTE available.
            50. DeepNetScanner (http://sourceforge.net/projects/nbtenum):
              This is a internet security scanner which scans a specified machine or a range of IPs for all possible information like NetBIOS enumeration, gathering sharelist, domain, os, lan manager, remote connection, SNMP walking, ...
            51. WinSCP (http://sourceforge.net/projects/winscp/):
              WinSCP is a SFTP and SCP client for Windows using SSH. Its main function is secure copying of files between a local and a remote computer. Beyond this basic function, WinSCP manages some other actions with files. Plugin to FAR manager is available too.
            52. winfingerprint (http://sourceforge.net/projects/winfingerprint/):
              Winfingerprint is a Win32 MFC VC++ .NET based security tool that is able to Determine OS, enumerate users, groups, shares, SIDs, transports, sessions, services, service pack and hotfix level, date and time, disks, and open TCP and UDP ports.
            53. Visual Component Framework (http://vcf-online.org/): The Visual Component Framework is an advanced C++ application framework that makes it easy to produce powerful C++ applications. The framework is a based on a thoroughly modern C++ design and has built in support for Rapid Application Development (RAD).

            Some Very Good VC++/MFC Resources Besides Codeproject.com

            1. http://www.naughter.com/ (VC++/MFC huge code repository)
              By PJ naughter Personally my favorite besides codeproject.com. This site contains a huge source code repository for MFC programmer. It has some of the best addon classes written for MFC programmers. What I like most about PJ naughter is that he keeps on improving these classes and fixes each and every bug in the code. Some of the classes are now in their 70 to 80th version.
            2. http://flounder.com/mvp_tips.htm (VC++/MFC)
              BY Joseph M. Newcomer
              This is very nice site containing lots and lots of VC++ tips, tricks and very detailed essays + great code examples. Main focus is on how to write the code in the right way.
            3. http://www.cheztabor.com/ (ATL/WTL)
              By cheztabor
              This site contains very nice code examples for ATL, WTL and Shell programming.
            4. http://www.viksoe.dk/code/ (ATL/WTL)
              By the author of Gmail Drive
              Although the code for GmailDrive is not provided, this site contains lots of other code examples covering MFC, ATL, WTL and Shell programming.
            5. http://www.codeguru.com/ (VC++/MFC/ATL and a lot more)
              Does not need any introduction. I think most of us already know about this site.
            6. http://programmerworld.net/personal/projects.htm (VC++/MFC )
              This is my personal web site. It has one firewall software with source code. I will be adding more code soon.
            7. http://vcfaq.mvps.org/ (VC++/MFC FAQs)
              This is the MVP's Frequently Asked Questions Page for Microsoft Visual C++. In here, you'll find answers to several commonly asked questions about Visual C++, MFC and Windows development in C/C++, as well as others.
            8. http://www.developersvoice.com/programming/article/vc-mfc (VC++/MFC)
              VC++/ MFC related FAQS
            9. http://www.functionx.com/ (VC++/MFC )
              A beginners site for VC++ and MFC programming. Contains some very nice beginner articles.
            10. http://www.softlookup.com/tutorial/vc++/index.asp A beginners site for VC++ and MFC programming. Contains some very nice beginner articles.
            11. http://www.mathcs.sjsu.edu/faculty/pearce/mfc/ A very nice web site. Very well written. One of the best resources for beginner in the field of VC++/MFC.

            Points of Interest

            I have written this article to provide all VC++ developers a place where they can find some of the best open source VC++/MFC applications. I personally find them very useful.

            Kindly help me in adding more good open source VC++/MFC projects in this list.

            You can find more articles and software projects with free source code on my web site:

            History

            Version 2.1: 2nd Sept, 2007

            1. Added two more resources for VC++ and MFC (No. 10 and 11)

            Version 2: 21st June, 2007

            1. Updated the article title as some of best open source projects
            2. Added some very good VC++/MFC resources besides Codeproject.com

            License

            This article, along with any associated source code and files, is licensed under The Microsoft Public License (Ms-PL)

            About the Author

            Sudhir Mangla

            Web Developer

            India India

            Member
            I am a B.E in Information Technology form Lingaya's Institute of Management and Technology Faridabad, India.Curently I am working as Lead Engineering in a software company in India.
            I has worked on VC++, MFC, VB, Sql Server. Currently I am working on VC++,MFC and C#.
             
            free source codes of my projects i.e. open source firewall for windows and other articles can be found athttp://Programmerworld.NET (Free Books and Source code)and athttp://DevelopersVoice.com (VC++ FAQ, MFC FAQ, C++ FAQ)

            posted @ 2012-08-30 19:52 tqsheng 閱讀(582) | 評論 (0)編輯 收藏

            從問題看本質(zhì): 研究TCP close_wait的內(nèi)幕

             * @author: ahuaxuan

             * @date: 2010-4-30

             */

             

            最近遇到的一個關(guān)于socket.close的問題,在某個應(yīng)用服務(wù)器出現(xiàn)的狀況(執(zhí)行netstat -np | grep tcp): 

            tcp        0      0 10.224.122.16:50158         10.224.112.58:8788          CLOSE_WAIT

            tcp        0      0 10.224.122.16:37655         10.224.112.58:8788          CLOSE_WAIT

            tcp        1      0 127.0.0.1:32713             127.0.0.1:8080              CLOSE_WAIT

            tcp       38      0 10.224.122.16:34538         10.224.125.42:443           CLOSE_WAIT

            tcp       38      0 10.224.122.16:33394         10.224.125.42:443           CLOSE_WAIT

            tcp        1      0 10.224.122.16:18882         10.224.125.10:80            CLOSE_WAIT

            tcp        1      0 10.224.122.16:18637         10.224.125.10:80            CLOSE_WAIT

            tcp        1      0 10.224.122.16:19655         10.224.125.12:80            CLOSE_WAIT

            ........................................

             

            總共出現(xiàn)了200個CLOSE_WAIT的socket.而且這些socket長時間得不到釋放.下面我們來看看為什么會出現(xiàn)這種大量socket的CLOSE_WAIT情況

             

            首先我們要搞清楚的是,這個socket是誰發(fā)起的,我們可以看到122.16這臺機器開了很多端口,而且端口號都很大,125.12 或者125.10上的端口都是很常見服務(wù)器端口,所以122.16上這么多CLOSE_WAIT

            的socket是由122.16開啟的,換句話說這臺機器是傳統(tǒng)的客戶端,它會主動的請求其他機器的服務(wù)端口.

             

            要搞清楚為什么會出現(xiàn)CLOSE_WAIT,那么首先我們必須要清楚CLOSE_WAIT的機制和原理.

             

            假設(shè)我們有一個client, 一個server.

             

            當(dāng)client主動發(fā)起一個socket.close()這個時候?qū)?yīng)TCP來說,會發(fā)生什么事情呢?如下圖所示.

             

            ?

             

             

            client首先發(fā)送一個FIN信號給server, 這個時候client變成了FIN_WAIT_1的狀態(tài), server端收到FIN之后,返回ACK,然后server端的狀態(tài)變成了CLOSE_WAIT.

            接著server端需要發(fā)送一個FIN給client,然后server端的狀態(tài)變成了LAST_ACK,接著client返回一個ACK,然后server端的socket就被成功的關(guān)閉了.

             

            從這里可以看到,如果由客戶端主動關(guān)閉一鏈接,那么客戶端是不會出現(xiàn)CLOSE_WAIT狀態(tài)的.客戶端主動關(guān)閉鏈接,那么Server端將會出現(xiàn)CLOSE_WAIT的狀態(tài).

            而我們的服務(wù)器上,是客戶端socket出現(xiàn)了CLOSE_WAIT,由此可見這個是由于server主動關(guān)閉了server上的socket.

             

            那么當(dāng)server主動發(fā)起一個socket.close(),這個時候又發(fā)生了一些什么事情呢.

            ?

             

            從圖中我們可以看到,如果是server主動關(guān)閉鏈接,那么Client則有可能進入CLOSE_WAIT,如果Client不發(fā)送FIN包,那么client就一直會處在CLOSE_WAIT狀態(tài)(后面我們可以看到有參數(shù)可以調(diào)整這個時間).

             

            那么現(xiàn)在我們要搞清楚的是,在第二中場景中,為什么Client不發(fā)送FIN包給server.要搞清楚這個問題,我們首先要搞清楚server是怎么發(fā)FIN包給client的,其實server就是調(diào)用了

            socket.close方法而已,也就是說如果要client發(fā)送FIN包,那么client就必須調(diào)用socket.close,否則就client就一直會處在CLOSE_WAIT(但事實上不同操作系統(tǒng)這點的實現(xiàn)還不一樣,

            在ahuaxuan(ahuaxuan.iteye.com)的例子中也出現(xiàn)了這樣的case).

             

            下面我們來做幾個實驗

            實驗一:

            環(huán)境:

            服務(wù)器端:win7+tomcat,tomcat的keep-alive的時間為默認(rèn)的15s.

            客戶端:mac os

            實驗步驟:服務(wù)器啟動后,客戶端向服務(wù)器發(fā)送一個get請求,然后客戶端阻塞,等待服務(wù)器端的socket超時.通過netstat -np tcp可以看到的情況是發(fā)送get請求時,服務(wù)器和客戶端鏈接是ESTABLISHED, 15s之后,客戶端變成了CLOSE_WAIT,而服務(wù)器端變成了FIN_WAIT_2.這一點也在我們的預(yù)料之中,而這個時候由于客戶端線程阻塞,客戶端socket空置在那里,不做任何操作,2分鐘過后,這個鏈接不管是在win7上,還是在mac os都看不到了.可見,FIN_WAIT_2或者CLOSE_WAIT有一個timeout.在后面的實驗,可以證明,在這個例子中,其實是FIN_WAIT_2有一個超時,一旦過了2分鐘,那么win7會發(fā)一個RST給mac os要求關(guān)閉雙方的socket.

             

            實驗二

            服務(wù)器端:ubuntu9.10+tomcat,tomcat的keep-alive的時間為默認(rèn)的15s.

            客戶端:mac os

            實驗步驟:服務(wù)器啟動后,客戶端向服務(wù)器發(fā)送一個get請求,然后客戶端阻塞,等待服務(wù)器端的socket超時.通過netstat -np tcp(ubuntu使用netstat -np|grep tcp)可以看到的情況是發(fā)送get請求時,服務(wù)器和客戶端鏈接是ESTABLISHED, 15s之后,客戶端變成了CLOSE_WAIT,而服務(wù)器端變成了FIN_WAIT_2.這一點也也在我們的預(yù)料之中,而這個時候由于客戶端線程阻塞,客戶端socket空置在那里,不做任何操作,1分鐘過后,ubuntu上的那個socket不見了,但是mac os上的socket還在,而且還是CLOSE_WAIT,這說明,FIN_WAIT_2確實有一個超時時間,win7上的超時操作可以關(guān)閉mac os上的socket,而ubuntu上的FIN_WAIT_2超時操作卻不能關(guān)閉mac os上的socket(其狀一直是CLOSE_WAIT).

             

            實驗三

            服務(wù)器端:mac os+tomcat,tomcat的keep-alive的時間為默認(rèn)的15s.

            客戶端:mac os

            實驗步驟:服務(wù)器啟動后,客戶端向服務(wù)器發(fā)送一個get請求,然后客戶端阻塞,等待服務(wù)器端的socket超時.通過netstat -np tcp可以看到的情況是發(fā)送get請求時,服務(wù)器和客戶端鏈接是ESTABLISHED, 15s之后,客戶端變成了CLOSE_WAIT,而服務(wù)器端變成了FIN_WAIT_2.這一點也在我們的預(yù)料之中,而這個時候由于客戶端線程阻塞,客戶端socket空置在那里,不做任何操作,4分鐘過后,mac os服務(wù)器端上的那個socket不見了,但是mac os客戶端上的socket還在,而且還是CLOSE_WAIT,這說明,FIN_WAIT_2確實有一個超時時間,win7上的超時操作可以關(guān)閉mac os上的socket,而ubuntu和mac os上的FIN_WAIT_2超時操作卻不能關(guān)閉mac os上的socket.

             

             

             

            總結(jié), 當(dāng)服務(wù)器的內(nèi)核不一樣上FIN_WAIT_2的超時時間和操作是不一樣的.

            經(jīng)查:控制FIN_WAIT_2的參數(shù)為:

            /proc/sys/net/ipv4/tcp_fin_timeout

            如 果套接字由本端要求關(guān)閉,這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠(yuǎn)不關(guān)閉連接,甚至意外當(dāng)機。缺省值是60秒。2.2 內(nèi)核的通常值是180秒,你可以按這個設(shè)置,但要記住的是,即使你的機器是一個輕載的WEB服務(wù)器,也有因為大量的死套接字而內(nèi)存溢出的風(fēng)險,F(xiàn)IN- WAIT-2的危險性比FIN-WAIT-1要小,因為它最多只能吃掉1.5K內(nèi)存,但是它們的生存期長些。參見tcp_max_orphans。

             

            實驗四

            服務(wù)器端:ubuntu9.10+tomcat,tomcat的keep-alive的時間為默認(rèn)的15s.

            客戶端:mac os

            實驗步驟:服務(wù)器啟動后,客戶端向服務(wù)器發(fā)送一個get請求,然后關(guān)閉客戶端關(guān)閉socket.通過netstat -np tcp可以看到的情況是發(fā)送get請求時,服務(wù)器和客戶端鏈接是ESTABLISHED, 客戶端拿到數(shù)據(jù)之后,客戶端變成了TIME_WAIT,而服務(wù)器端變成了已經(jīng)看不到這個socket了.這一點也也在我們的預(yù)料之中,誰主動關(guān)閉鏈接,那么誰就需要進入TIME_WAIT狀態(tài)(除非他的FIN_WAIT_2超時了),大約1分鐘之后這個socket在客戶端也消失了.

             

            實驗證明TIME_WAIT的狀態(tài)會存在一段時間,而且在這個時間端里,這個FD是不能被回收的.

             

            但是我們的問題是客戶端有很多CLOSE_WAIT,而且我們的服務(wù)器不是windows,而是linux,所以CLOSE_WAIT有沒有超時時間呢,肯定有,而且默認(rèn)情況下這個超時時間應(yīng)該是比較大的.否則不會一下子看到兩百個CLOSE_WAIT的狀態(tài).

             

            客戶端解決方案:

             

            1.由于socket.close()會導(dǎo)致FIN信號,而client的socket CLOSE_WAIT就是因為該socket該關(guān)的時候,我們沒有關(guān),所以我們需要一個線程池來檢查空閑連接中哪些進入了超時狀態(tài)(idleTIME),但進入超時

            的socket未必是CLOSE_WAIT的狀態(tài)的.不過如果我們把空閑超時的socket關(guān)閉,那么CLOSE_WAIT的狀態(tài)就會消失.(問題:像HttpClient這樣的工具包中,如果要檢查鏈接池,那么則需要鎖定整個池,而這個時候,用戶請求獲取connection的操作只能等待,在高并發(fā)的時候會造成程序響應(yīng)速度下降,具體參考IdleConnectionTimeoutThread.java(HttpClient3.1))

             

            2.經(jīng)查,其實有參數(shù)可以調(diào)整CLOSE_WAIT的持續(xù)時間,如果我們改變這個時間,那么可以讓CLOSE_WAIT只保持很短的時間(當(dāng)然這個參數(shù)不只作用在CLOSE_WAIT上,縮短這個時間可能會帶來其他的影響).在客戶端機器上修改如下:

            sysctl -w net.ipv4.tcp_keepalive_time=60(缺省是2小時,現(xiàn)在改成了60秒)

            sysctl -w net.ipv4.tcp_keepalive_probes=2

            sysctl -w net.ipv4.tcp_keepalive_intvl=2

            我們將CLOSE_WAIT的檢查時間設(shè)置為30s,這樣一個CLOSE_WAIT只會存在30S.

             

            3. 當(dāng)然,最重要的是我們要檢查客戶端鏈接的空閑時間,空閑時間可以由客戶端自行定義,比如idleTimeout,也可由服務(wù)器來決定,服務(wù)器只需要每次在response.header中加入一個頭信息,比如說名字叫做timeout頭,當(dāng)然一般情況下我們會用keep-alive這個頭字段, 如果服務(wù)器設(shè)置了該字段,那么客戶端拿到這個屬性之后,就知道自己的connection最大的空閑時間,這樣不會由于服務(wù)器關(guān)閉socket,而導(dǎo)致客戶端socket一直close_wait在那里.

             

            服務(wù)器端解決方案

             

            4.前面講到客戶端出現(xiàn)CLOSE_WAIT是由于服務(wù)器端Socket的讀超時,也是TOMCAT中的keep-alive參數(shù).那么如果我們把這個超時時間設(shè)置的長點,會有什么影響?

            如果我們的tomcat既服務(wù)于瀏覽器,又服務(wù)于其他的APP,而且我們把connection的keep-alive時間設(shè)置為10分鐘,那么帶來的后果是瀏覽器打開一個頁面,然后這個頁面一直不關(guān)閉,那么服務(wù)器上的socket也不能關(guān)閉,它所占用的FD也不能服務(wù)于其他請求.如果并發(fā)一高,很快服務(wù)器的資源將會被耗盡.新的請求再也進不來. 那么如果把keep-alive的時間設(shè)置的短一點呢,比如15s? 那么其他的APP來訪問這個服務(wù)器的時候,一旦這個socket, 15s之內(nèi)沒有新的請求,那么客戶端APP的socket將出現(xiàn)大量的CLOSE_WAIT狀態(tài).

            所以如果出現(xiàn)這種情況,建議將你的server分開部署,服務(wù)于browser的部署到單獨的JVM實例上,保持keep-alive為15s,而服務(wù)于架構(gòu)中其他應(yīng)用的功能部署到另外的JVM實例中,并且將keep-alive的時間設(shè)置的更

            長,比如說1個小時.這樣客戶端APP建立的connection,如果在一個小時之內(nèi)都沒有重用這條connection,那么客戶端的socket才會進入CLOSE_WAIT的狀態(tài).針對不同的應(yīng)用場景來設(shè)置不同的keep-alive時間,可以幫助我們提高程序的性能.

             

            5.如果我們的應(yīng)用既服務(wù)于瀏覽器,又服務(wù)于其他的APP,那么我們還有一個終極解決方案.

            那就是配置多個connector, 如下:

            <!-- for browser -->

             <Connector port="8080" protocol="HTTP/1.1" 

                           connectionTimeout="20000" 

                           redirectPort="8443" />

             

            <!-- for other APP -->

            <Connector port="8081" protocol="HTTP/1.1" 

                           connectionTimeout="20000" 

                           redirectPort="8443" keepAliveTimeout="330000" />

             

            訪問的時候,瀏覽器使用8080端口,其他的APP使用8081端口.這樣可以保證瀏覽器請求的socket在15s之內(nèi)如果沒有再次使用,那么tomcat會主動關(guān)閉該socket,而其他APP請求的socket在330s之內(nèi)沒有使用,才關(guān)閉該socket,這樣做可以大大減少其他APP上出現(xiàn)CLOSE_WAIT的幾率.

             

            你一定會問,如果我不設(shè)置keepAliveTimeout又怎么樣呢,反正客戶端有idleTimeout,客戶端的close_wait不會持續(xù)太長時間,請注意看上圖中標(biāo)紅的地方,一個是close_wait,還有一個是time_wait狀態(tài),也就是說誰主動發(fā)起請求,那么它將會最終進入time_wait狀態(tài),據(jù)說windows上這個time_wait將持續(xù)4分鐘,我在linux上的測試表明,linux上它大概是60s左右,也就是說高并發(fā)下,也就是服務(wù)器也需要過60s左右才能真正的釋放這個FD.所以我們?nèi)绻峁﹉ttp服務(wù)給其他APP,那么我們最好讓客戶端優(yōu)先關(guān)閉socket,也就是將客戶端的idleTimeout設(shè)置的比server的keepalivetimeout小一點.這樣保證time_wait出現(xiàn)在客戶端. 而不是資源較為緊張的服務(wù)器端.

             

            總結(jié):

                   本文中ahuaxuan給大家揭示了TCP層client和server端socket關(guān)閉的一般流程,并且指出異常情況下client和server端各自會發(fā)生的情況,包含了在不同平臺上出現(xiàn)了的不同情況, 同時說明了在應(yīng)用層上我們可以做什么樣的邏輯來保證socket關(guān)閉時對server端帶來最小的影響.

             

             

             

            下面是網(wǎng)上找到的一些資料:

             

             寫道



            /proc/sys/net/ipv4/tcp_keepalive_time
當(dāng)keepalive起用的時候,TCP發(fā)送keepalive消息的頻度。缺省是2小時。
            
/proc/sys/net/ipv4/tcp_keepalive_intvl
當(dāng)探測沒有確認(rèn)時,重新發(fā)送探測的頻度。缺省是75秒。
            
/proc/sys/net/ipv4/tcp_keepalive_probes
在認(rèn)定連接失效之前,發(fā)送多少個TCP的keepalive探測包。缺省值是9。這個值乘以tcp_keepalive_intvl之后決定了,一個連接發(fā)送了keepalive之后可以有多少時間沒有回應(yīng)。


            /proc/sys/net/ipv4/tcp_max_orphans
            系 統(tǒng)中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。如果超過這個數(shù)字,孤兒連接將即刻被復(fù)位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。This limit exists only to prevent simple DoS attacks, you _must_ not rely on this or lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value, and tune network services to linger and kill such states more aggressively. 讓我再次提醒你:每個孤兒套接字最多能夠吃掉你64K不可交換的內(nèi)存。

            /proc/sys/net/ipv4/tcp_orphan_retries
            本端試圖關(guān)閉TCP連接之前重試多少次。缺省值是7,相當(dāng)于50秒~16分鐘(取決于RTO)。如果你的機器是一個重載的WEB服務(wù)器,你應(yīng)該考慮減低這個值,因為這樣的套接字會消耗很多重要的資源。參見tcp_max_orphans。

            /proc/sys/net/ipv4/tcp_max_syn_backlog
            記 錄的那些尚未收到客戶端確認(rèn)信息的連接請求的最大值。對于有128M內(nèi)存的系統(tǒng)而言,缺省值是1024,小內(nèi)存的系統(tǒng)則是128。如果服務(wù)器不堪重負(fù),試 試提高這個值。注意!如果你設(shè)置這個值大于1024,最好同時調(diào)整include/net/tcp.h中的TCP_SYNQ_HSIZE,以保證 TCP_SYNQ_HSIZE*16 ≤tcp_max_syn_backlo,然后重新編譯內(nèi)核。

            /proc/sys/net/ipv4/tcp_max_tw_buckets
            系 統(tǒng)同時保持timewait套接字的最大數(shù)量。如果超過這個數(shù)字,time-wait套接字將立刻被清除并打印警告信息。這個限制僅僅是為了防止簡單的 DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,如果網(wǎng)絡(luò)實際需要大于缺省值,更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。

            posted @ 2012-08-27 16:39 tqsheng 閱讀(214) | 評論 (0)編輯 收藏

            slickedit

            http://www.cnblogs.com/russinovich/archive/2011/04/20/2023005.html 

            posted @ 2012-08-24 10:27 tqsheng 閱讀(407) | 評論 (0)編輯 收藏

            CLOSE_WAIT狀態(tài)的生成原因

            CLOSE_WAIT狀態(tài)的生成原因
            首先我們知道,如果我們的服務(wù)器程序APACHE處于CLOSE_WAIT狀態(tài)的話,說明套接字是被動關(guān)閉的!

            因為如果是CLIENT端主動斷掉當(dāng)前連接的話,那么雙方關(guān)閉這個TCP連接共需要四個packet:

                  Client --->  FIN  --->  Server 

                  Client <---  ACK  <---  Server 

             這時候Client端處于FIN_WAIT_2狀態(tài);而Server 程序處于CLOSE_WAIT狀態(tài)。

                  Client <---  FIN  <---  Server 

            這時Server 發(fā)送FIN給Client,Server 就置為LAST_ACK狀態(tài)。

                   Client --->  ACK  --->  Server 

            Client回應(yīng)了ACK,那么Server 的套接字才會真正置為CLOSED狀態(tài)。

            Server 程序處于CLOSE_WAIT狀態(tài),而不是LAST_ACK狀態(tài),說明還沒有發(fā)FIN給Client,那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其他事要做,導(dǎo)致沒有發(fā)這個FIN packet。

            通常來說,一個CLOSE_WAIT會維持至少2個小時的時間。如果有個流氓特地寫了個程序,給你造成一堆的CLOSE_WAIT,消耗

            你的資源,那么通常是等不到釋放那一刻,系統(tǒng)就已經(jīng)解決崩潰了。

            只能通過修改一下TCP/IP的參數(shù),來縮短這個時間:修改tcp_keepalive_*系列參數(shù)有助于解決這個問題。

             

            proc/sys/net/ipv4/下各項的意義

            /proc/sys/net/ipv4/icmp_timeexceed_rate
            這個在traceroute時導(dǎo)致著名的“Solaris middle star”。這個文件控制發(fā)送ICMP Time Exceeded消息的比率。
            /proc/sys/net/ipv4/igmp_max_memberships
            主機上最多有多少個igmp (多播)套接字進行監(jiān)聽。
            /proc/sys/net/ipv4/inet_peer_gc_maxtime
            求 助: Add a little explanation about the inet peer storage? Minimum interval between garbage collection passes. This interval is in effect under low (or absent) memory pressure on the pool. Measured in jiffies.
            /proc/sys/net/ipv4/inet_peer_gc_mintime
            每一遍碎片收集之間的最小時間間隔。當(dāng)內(nèi)存壓力比較大的時候,調(diào)整這個間隔很有效。以jiffies計。
            /proc/sys/net/ipv4/inet_peer_maxttl
            entries的最大生存期。在pool沒有內(nèi)存壓力的情況下(比如,pool中entries的數(shù)量很少的時候),未使用的entries經(jīng)過一段時間就會過期。以jiffies計。
            /proc/sys/net/ipv4/inet_peer_minttl
            entries的最小生存期。應(yīng)該不小于匯聚端分片的生存期。當(dāng)pool的大小不大于inet_peer_threshold時,這個最小生存期必須予以保證。以jiffies計。
            /proc/sys/net/ipv4/inet_peer_threshold
            The approximate size of the INET peer storage. Starting from this threshold entries will be thrown aggressively. This threshold also determines entries' time-to-live and time intervals between garbage collection passes. More entries, less time-to-live, less GC interval.
            /proc/sys/net/ipv4/ip_autoconfig
            這個文件里面寫著一個數(shù)字,表示主機是否通過RARP、BOOTP、DHCP或者其它機制取得其IP配置。否則就是0。
            /proc/sys/net/ipv4/ip_default_ttl
            數(shù)據(jù)包的生存期。設(shè)置為64是安全的。如果你的網(wǎng)絡(luò)規(guī)模巨大就提高這個值。不要因為好玩而這么做——那樣會產(chǎn)生有害的路由環(huán)路。實際上,在很多情況下你要考慮能否減小這個值。
            /proc/sys/net/ipv4/ip_dynaddr/proc/sys/net/ipv4/icmp_destunreach_rate

            如果你有一個動態(tài)地址的自動撥號接口,就得設(shè)置它。當(dāng)你的自動撥號接口激活的時候,本地所有沒有收到答復(fù)的TCP套接字會重新綁定到正確的地址上。這可以解決引發(fā)撥號的套接字本身無法工作,重試一次卻可以的問題。
            /proc/sys/net/ipv4/ip_forward
            內(nèi)核是否轉(zhuǎn)發(fā)數(shù)據(jù)包。缺省禁止。
            /proc/sys/net/ipv4/ip_local_port_range
            用于向外連接的端口范圍。缺省情況下其實很小:1024到4999。
            /proc/sys/net/ipv4/ip_no_pmtu_disc
            如果你想禁止“沿途MTU發(fā)現(xiàn)”就設(shè)置它。“沿途MTU發(fā)現(xiàn)”是一種技術(shù),可以在傳輸路徑上檢測出最大可能的MTU值。參見Cookbook一章中關(guān)于“沿途MTU發(fā)現(xiàn)”的內(nèi)容。
            /proc/sys/net/ipv4/ipfrag_high_thresh
            用 于IP分片匯聚的最大內(nèi)存用量。分配了這么多字節(jié)的內(nèi)存后,一旦用盡,分片處理程序就會丟棄分片。When ipfrag_high_thresh bytes of memory is allocated for this purpose, the fragment handler will toss packets until ipfrag_low_thresh is reached.
            /proc/sys/net/ipv4/ip_nonlocal_bind
            如果你希望你的應(yīng)用程序能夠綁定到不屬于本地網(wǎng)卡的地址上時,設(shè)置這個選項。如果你的機器沒有專線連接(甚至是動態(tài)連接)時非常有用,即使你的連接斷開,你的服務(wù)也可以啟動并綁定在一個指定的地址上。
            /proc/sys/net/ipv4/ipfrag_low_thresh
            用于IP分片匯聚的最小內(nèi)存用量。
            /proc/sys/net/ipv4/ipfrag_time
            IP分片在內(nèi)存中的保留時間(秒數(shù))。
            /proc/sys/net/ipv4/tcp_abort_on_overflow
            一個布爾類型的標(biāo)志,控制著當(dāng)有很多的連接請求時內(nèi)核的行為。啟用的話,如果服務(wù)超載,內(nèi)核將主動地發(fā)送RST包。
            /proc/sys/net/ipv4/tcp_fin_timeout
            如 果套接字由本端要求關(guān)閉,這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠(yuǎn)不關(guān)閉連接,甚至意外當(dāng)機。缺省值是60秒。2.2 內(nèi)核的通常值是180秒,你可以按這個設(shè)置,但要記住的是,即使你的機器是一個輕載的WEB服務(wù)器,也有因為大量的死套接字而內(nèi)存溢出的風(fēng)險,F(xiàn)IN- WAIT-2的危險性比FIN-WAIT-1要小,因為它最多只能吃掉1.5K內(nèi)存,但是它們的生存期長些。參見tcp_max_orphans。

            /proc/sys/net/ipv4/tcp_keepalive_time
            當(dāng)keepalive起用的時候,TCP發(fā)送keepalive消息的頻度。缺省是2小時。
            /proc/sys/net/ipv4/tcp_keepalive_intvl
            當(dāng)探測沒有確認(rèn)時,重新發(fā)送探測的頻度。缺省是75秒。
            /proc/sys/net/ipv4/tcp_keepalive_probes
            在認(rèn)定連接失效之前,發(fā)送多少個TCP的keepalive探測包。缺省值是9。這個值乘以tcp_keepalive_intvl之后決定了,一個連接發(fā)送了keepalive之后可以有多少時間沒有回應(yīng)。
            /proc/sys/net/ipv4/tcp_max_orphans
            系 統(tǒng)中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。如果超過這個數(shù)字,孤兒連接將即刻被復(fù)位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。This limit exists only to prevent simple DoS attacks, you _must_ not rely on this or lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value, and tune network services to linger and kill such states more aggressively. 讓我再次提醒你:每個孤兒套接字最多能夠吃掉你64K不可交換的內(nèi)存。
            /proc/sys/net/ipv4/tcp_orphan_retries
            本端試圖關(guān)閉TCP連接之前重試多少次。缺省值是7,相當(dāng)于50秒~16分鐘(取決于RTO)。如果你的機器是一個重載的WEB服務(wù)器,你應(yīng)該考慮減低這個值,因為這樣的套接字會消耗很多重要的資源。參見tcp_max_orphans。
            /proc/sys/net/ipv4/tcp_max_syn_backlog
            記 錄的那些尚未收到客戶端確認(rèn)信息的連接請求的最大值。對于有128M內(nèi)存的系統(tǒng)而言,缺省值是1024,小內(nèi)存的系統(tǒng)則是128。如果服務(wù)器不堪重負(fù),試 試提高這個值。注意!如果你設(shè)置這個值大于1024,最好同時調(diào)整include/net/tcp.h中的TCP_SYNQ_HSIZE,以保證 TCP_SYNQ_HSIZE*16 ≤tcp_max_syn_backlo,然后重新編譯內(nèi)核。
            /proc/sys/net/ipv4/tcp_max_tw_buckets
            系 統(tǒng)同時保持timewait套接字的最大數(shù)量。如果超過這個數(shù)字,time-wait套接字將立刻被清除并打印警告信息。這個限制僅僅是為了防止簡單的 DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,如果網(wǎng)絡(luò)實際需要大于缺省值,更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。
            /proc/sys/net/ipv4/tcp_retrans_collapse
            為兼容某些糟糕的打印機設(shè)置的“將錯就錯”選項。再次發(fā)送時,把數(shù)據(jù)包增大一些,來避免某些TCP協(xié)議棧的BUG。

            /proc/sys/net/ipv4/tcp_retries1
            在認(rèn)定出錯并向網(wǎng)絡(luò)層提交錯誤報告之前,重試多少次。缺省設(shè)置為RFC規(guī)定的最小值:3,相當(dāng)于3秒~8分鐘(取決于RIO)。
            /proc/sys/net/ipv4/tcp_retries2
            在殺死一個活動的TCP連接之前重試多少次。RFC 1122規(guī)定這個限制應(yīng)該長于100秒。這個值太小了。缺省值是15,相當(dāng)于13~30分鐘(取決于RIO)。
            /proc/sys/net/ipv4/tcp_rfc1337
            這個開關(guān)可以啟動對于在RFC1337中描述的“tcp的time-wait暗殺危機”問題的修復(fù)。啟用后,內(nèi)核將丟棄那些發(fā)往time-wait狀態(tài)TCP套接字的RST包。卻省為0。
            /proc/sys/net/ipv4/tcp_sack
            特別針對丟失的數(shù)據(jù)包使用選擇性ACK,這樣有助于快速恢復(fù)。
            /proc/sys/net/ipv4/tcp_stdurg
            使用TCP緊急指針的主機需求解釋。因為絕大多數(shù)主機采用BSD解釋,所以如果你在Linux上打開它,可能會影響它與其它機器的正常通訊。缺省是FALSE。
            /proc/sys/net/ipv4/tcp_syn_retries
            在內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量。
            /proc/sys/net/ipv4/tcp_synack_retries
            為了打開對端的連接,內(nèi)核需要發(fā)送一個SYN并附帶一個回應(yīng)前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設(shè)置決定了內(nèi)核放棄連接之前發(fā)送SYN+ACK包的數(shù)量。
            /proc/sys/net/ipv4/tcp_timestamps
            時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內(nèi)核接受這種“異常”的數(shù)據(jù)包。
            /proc/sys/net/ipv4/tcp_tw_recycle
            能夠更快地回收TIME-WAIT套接字。缺省值是1。除非有技術(shù)專家的建議和要求,否則不應(yīng)修改。
            /proc/sys/net/ipv4/tcp_window_scaling
            一般來說TCP/IP允許窗口尺寸達到65535字節(jié)。對于速度確實很高的網(wǎng)絡(luò)而言這個值可能還是太小。這個選項允許設(shè)置上G字節(jié)的窗口大小,有利于在帶寬*延遲很大的環(huán)境中使用。
            一旦內(nèi)核認(rèn)為它無法發(fā)包,就會丟棄這個包,并向發(fā)包的主機發(fā)送ICMP通知。
            /proc/sys/net/ipv4/icmp_echo_ignore_all
            根本不要響應(yīng)echo包。請不要設(shè)置為缺省,它可能在你正被利用成為DoS攻擊的跳板時可能有用。
            /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Useful]
            如果你ping子網(wǎng)的子網(wǎng)地址,所有的機器都應(yīng)該予以回應(yīng)。這可能成為非常好用的拒絕服務(wù)攻擊工具。設(shè)置為1來忽略這些子網(wǎng)廣播消息。
            /proc/sys/net/ipv4/icmp_echoreply_rate
            設(shè)置了向任意主機回應(yīng)echo請求的比率。
            /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
            設(shè)置它之后,可以忽略由網(wǎng)絡(luò)中的那些聲稱回應(yīng)地址是廣播地址的主機生成的ICMP錯誤。
            /proc/sys/net/ipv4/icmp_paramprob_rate
            一個相對不很明確的ICMP消息,用來回應(yīng)IP頭或TCP頭損壞的異常數(shù)據(jù)包。你可以通過這個文件控制消息的發(fā)送比率。

            ================================================================

             http://skylove.study-area.org/blog/2006/07/linuxip_29.html

            tcp_syn_retries :INTEGER
            默認(rèn)值是5
            對于一個新建連接,內(nèi)核要發(fā)送多少個 SYN 連接請求才決定放棄。不應(yīng)該大于255,默認(rèn)值是5,對應(yīng)于180秒左右時間。(對于大負(fù)載而物理通信良好的網(wǎng)絡(luò)而言,這個值偏高,可修改為2.這個值僅僅是針對對外的連接,對進來的連接,是由tcp_retries1 決定的)

            tcp_synack_retries :INTEGER
            默認(rèn)值是5
            對于遠(yuǎn)端的連接請求SYN,內(nèi)核會發(fā)送SYN + ACK數(shù)據(jù)報,以確認(rèn)收到上一個 SYN連接請求包。這是所謂的三次握手( threeway handshake)機制的第二個步驟。這里決定內(nèi)核在放棄連接之前所送出的 SYN+ACK 數(shù)目。不應(yīng)該大于255,默認(rèn)值是5,對應(yīng)于180秒左右時間。(可以根據(jù)上面的 tcp_syn_retries 來決定這個值)

            tcp_keepalive_time :INTEGER
            默認(rèn)值是7200(2小時)
            當(dāng)keepalive打開的情況下,TCP發(fā)送keepalive消息的頻率。(由于目前網(wǎng)絡(luò)攻擊等因素,造成了利用這個進行的攻擊很頻繁,曾經(jīng)也有cu的朋友提到過,說如果2邊建立了連接,然后不發(fā)送任何數(shù)據(jù)或者rst/fin消息,那么持續(xù)的時間是不是就是2小時,空連接攻擊? tcp_keepalive_time就是預(yù)防此情形的.我個人在做nat服務(wù)的時候的修改值為1800秒)

            tcp_keepalive_probesINTEGER
            默認(rèn)值是9
            TCP發(fā)送keepalive探測以確定該連接已經(jīng)斷開的次數(shù)。(注意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發(fā)送.次數(shù)默認(rèn)不需要修改,當(dāng)然根據(jù)情形也可以適當(dāng)?shù)乜s短此值.設(shè)置為5比較合適)

            tcp_keepalive_intvl:INTEGER
            默認(rèn)值為75
            探測消息發(fā)送的頻率,乘以tcp_keepalive_probes就得到對于從開始探測以來沒有響應(yīng)的連接殺除的時間。默認(rèn)值為75秒,也就是沒有活動的連接將在大約11分鐘以后將被丟棄。(對于普通應(yīng)用來說,這個值有一些偏大,可以根據(jù)需要改小.特別是web類服務(wù)器需要改小該值,15是個比較合適的值)

            tcp_retries1 :INTEGER
            默認(rèn)值是3
            放棄回應(yīng)一個TCP連接請求前﹐需要進行多少次重試。RFC 規(guī)定最低的數(shù)值是3﹐這也是默認(rèn)值﹐根據(jù)RTO的值大約在3秒 - 8分鐘之間。(注意:這個值同時還決定進入的syn連接)

            tcp_retries2 :INTEGER
            默認(rèn)值為15
            在丟棄激活(已建立通訊狀況)的TCP連接之前﹐需要進行多少次重試。默認(rèn)值為15,根據(jù)RTO的值來決定,相當(dāng)于13-30分鐘(RFC1122規(guī)定,必須大于100秒).(這個值根據(jù)目前的網(wǎng)絡(luò)設(shè)置,可以適當(dāng)?shù)馗男?我的網(wǎng)絡(luò)內(nèi)修改為了5)

            tcp_orphan_retries :INTEGER
            默認(rèn)值是7
            在近端丟棄TCP連接之前﹐要進行多少次重試。默認(rèn)值是7個﹐相當(dāng)于 50秒 - 16分鐘﹐視 RTO 而定。如果您的系統(tǒng)是負(fù)載很大的web服務(wù)器﹐那么也許需要降低該值﹐這類 sockets 可能會耗費大量的資源。另外參的考tcp_max_orphans 。(事實上做NAT的時候,降低該值也是好處顯著的,我本人的網(wǎng)絡(luò)環(huán)境中降低該值為3)

            tcp_fin_timeout :INTEGER
            默認(rèn)值是 60
            對于本端斷開的socket連接,TCP保持在FIN-WAIT-2狀態(tài)的時間。對方可能會斷開連接或一直不結(jié)束連接或不可預(yù)料的進程死亡。默認(rèn)值為 60 秒。過去在2.2版本的內(nèi)核中是 180 秒。您可以設(shè)置該值﹐但需要注意﹐如果您的機器為負(fù)載很重的web服務(wù)器﹐您可能要冒內(nèi)存被大量無效數(shù)據(jù)報填滿的風(fēng)險﹐FIN-WAIT-2 sockets 的危險性低于 FIN-WAIT-1 ﹐因為它們最多只吃 1.5K 的內(nèi)存﹐但是它們存在時間更長。另外參考 tcp_max_orphans。(事實上做NAT的時候,降低該值也是好處顯著的,我本人的網(wǎng)絡(luò)環(huán)境中降低該值為30)

            tcp_max_tw_buckets :INTEGER
            默認(rèn)值是180000
            系 統(tǒng)在同時所處理的最大 timewait sockets 數(shù)目。如果超過此數(shù)的話﹐time-wait socket 會被立即砍除并且顯示警告信息。之所以要設(shè)定這個限制﹐純粹為了抵御那些簡單的 DoS 攻擊﹐千萬不要人為的降低這個限制﹐不過﹐如果網(wǎng)絡(luò)條件需要比默認(rèn)值更多﹐則可以提高它(或許還要增加內(nèi)存)。(事實上做NAT的時候最好可以適當(dāng)?shù)卦黾釉撝?

            tcp_tw_recycle :BOOLEAN
            默認(rèn)值是0
            打開快速 TIME-WAIT sockets 回收。除非得到技術(shù)專家的建議或要求﹐請不要隨意修改這個值。(做NAT的時候,建議打開它)

             

            tcp_tw_reuse:BOOLEAN
            默認(rèn)值是0
            該文件表示是否允許重新應(yīng)用處于TIME-WAIT狀態(tài)的socket用于新的TCP連接(這個對快速重啟動某些服務(wù),而啟動后提示端口已經(jīng)被使用的情形非常有幫助)

            tcp_max_orphans :INTEGER
            缺省值是8192
            系統(tǒng)所能處理不屬于任何進程的TCP sockets最大數(shù)量。假如超過這個數(shù)量﹐那么不屬于任何進程的連接會被立即reset,并同時顯示警告信息。之所以要設(shè)定這個限制﹐純粹為了抵御那些簡單的 DoS 攻擊﹐千萬不要依賴這個或是人為的降低這個限制(這個值Redhat AS版本中設(shè)置為32768,但是很多防火墻修改的時候,建議該值修改為2000)

            tcp_abort_on_overflow :BOOLEAN
            缺省值是0
            當(dāng)守護進程太忙而不能接受新的連接,就象對方發(fā)送reset消息,默認(rèn)值是false。這意味著當(dāng)溢出的原因是因為一個偶然的猝發(fā),那么連接將恢復(fù)狀態(tài)。只有在你確信守護進程真的不能完成連接請求時才打開該選項,該選項會影響客戶的使用。(對待已經(jīng)滿載的sendmail,apache這類服務(wù)的時候,這個可以很快讓客戶端終止連接,可以給予服務(wù)程序處理已有連接的緩沖機會,所以很多防火墻上推薦打開它)

            tcp_syncookies :BOOLEAN
            默認(rèn)值是0
            只有在內(nèi)核編譯時選擇了CONFIG_SYNCOOKIES時才會發(fā)生作用。當(dāng)出現(xiàn)syn等候隊列出現(xiàn)溢出時象對方發(fā)送syncookies。目的是為了防止syn flood攻擊。
            注意:該選項千萬不能用于那些沒有收到攻擊的高負(fù)載服務(wù)器,如果在日志中出現(xiàn)synflood消息,但是調(diào)查發(fā)現(xiàn)沒有收到synflood攻擊,而是合法用戶的連接負(fù)載過高的原因,你應(yīng)該調(diào)整其它參數(shù)來提高服務(wù)器性能。參考:
            tcp_max_syn_backlog
            tcp_synack_retries
            tcp_abort_on_overflow
            syncookie嚴(yán)重的違背TCP協(xié)議,不允許使用TCP擴展,可能對某些服務(wù)導(dǎo)致嚴(yán)重的性能影響(如SMTP轉(zhuǎn)發(fā))。(注意,該實現(xiàn)與BSD上面使用的tcp proxy一樣,是違反了RFC中關(guān)于tcp連接的三次握手實現(xiàn)的,但是對于防御syn-flood的確很有用.)

            tcp_stdurg :BOOLEAN
            默認(rèn)值為0
            使用 TCP urg pointer 字段中的主機請求解釋功能。大部份的主機都使用老舊的 BSD解釋,因此如果您在 Linux 打開它﹐或會導(dǎo)致不能和它們正確溝通。

             

            tcp_max_syn_backlog :INTEGER
            對于那些依然還未獲得客戶端確認(rèn)的連接請求﹐需要保存在隊列中最大數(shù)目。對于超過 128Mb 內(nèi)存的系統(tǒng)﹐默認(rèn)值是 1024 ﹐低于 128Mb 的則為 128。如果服務(wù)器經(jīng)常出現(xiàn)過載﹐可以嘗試增加這個數(shù)字。警告﹗假如您將此值設(shè)為大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE ﹐以保持TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且編進核心之內(nèi)。(SYN Flood攻擊利用TCP協(xié)議散布握手的缺陷,偽造虛假源IP地址發(fā)送大量TCP-SYN半打開連接到目標(biāo)系統(tǒng),最終導(dǎo)致目標(biāo)系統(tǒng)Socket隊列資源耗 盡而無法接受新的連接。為了應(yīng)付這種攻擊,現(xiàn)代Unix系統(tǒng)中普遍采用多連接隊列處理的方式來緩沖(而不是解決)這種攻擊,是用一個基本隊列處理正常的完 全連接應(yīng)用(Connect()和Accept() ),是用另一個隊列單獨存放半打開連接。這種雙隊列處理方式和其他一些系統(tǒng)內(nèi)核措施(例如Syn-Cookies/Caches)聯(lián)合應(yīng)用時,能夠比較有效的緩解小規(guī)模的SYN Flood攻擊(事實證明<1000p/s)加大SYN隊列長度可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù),所以對Server來說可以考慮增大該值.)

            tcp_window_scaling :INTEGER
            缺省值為1
            該 文件表示設(shè)置tcp/ip會話的滑動窗口大小是否可變。參數(shù)值為布爾值,為1時表示可變,為0時表示不可變。tcp/ip通常使用的窗口最大可達到 65535 字節(jié),對于高速網(wǎng)絡(luò),該值可能太小,這時候如果啟用了該功能,可以使tcp/ip滑動窗口大小增大數(shù)個數(shù)量級,從而提高數(shù)據(jù)傳輸?shù)哪芰?RFC 1323)。(對普通地百M網(wǎng)絡(luò)而言,關(guān)閉會降低開銷,所以如果不是高速網(wǎng)絡(luò),可以考慮設(shè)置為0)

            tcp_timestamps :BOOLEAN
            缺省值為1
            Timestamps 用在其它一些東西中﹐可以防范那些偽造的 sequence 號碼。一條1G的寬帶線路或許會重遇到帶 out-of-line數(shù)值的舊sequence 號碼(假如它是由于上次產(chǎn)生的)。Timestamp 會讓它知道這是個 '舊封包'。(該文件表示是否啟用以一種比超時重發(fā)更精確的方法(RFC 1323)來啟用對 RTT 的計算;為了實現(xiàn)更好的性能應(yīng)該啟用這個選項。)

            tcp_sack :BOOLEAN
            缺省值為1
            使 用 Selective ACK﹐它可以用來查找特定的遺失的數(shù)據(jù)報--- 因此有助于快速恢復(fù)狀態(tài)。該文件表示是否啟用有選擇的應(yīng)答(Selective Acknowledgment),這可以通過有選擇地應(yīng)答亂序接收到的報文來提高性能(這樣可以讓發(fā)送者只發(fā)送丟失的報文段)。(對于廣域網(wǎng)通信來說這個選項應(yīng)該啟用,但是這會增加對 CPU 的占用。)

            tcp_fack :BOOLEAN
            缺省值為1
            打開FACK擁塞避免和快速重傳功能。(注意,當(dāng)tcp_sack設(shè)置為0的時候,這個值即使設(shè)置為1也無效)

            tcp_dsack :BOOLEAN
            缺省值為1
            允許TCP發(fā)送"兩個完全相同"的SACK。

            tcp_ecn :BOOLEAN
            缺省值為0
            打開TCP的直接擁塞通告功能。

            tcp_reordering :INTEGER
            默認(rèn)值是3
            TCP流中重排序的數(shù)據(jù)報最大數(shù)量 。 (一般有看到推薦把這個數(shù)值略微調(diào)整大一些,比如5)

            tcp_retrans_collapse :BOOLEAN
            缺省值為1
            對于某些有bug的打印機提供針對其bug的兼容性。(一般不需要這個支持,可以關(guān)閉它)

            tcp_wmem(3個INTEGER變量): mindefaultmax
            min
            :為TCP socket預(yù)留用于發(fā)送緩沖的內(nèi)存最小值。每個tcp socket都可以在建議以后都可以使用它。默認(rèn)值為4096(4K)。

            default:為TCP socket預(yù)留用于發(fā)送緩沖的內(nèi)存數(shù)量,默認(rèn)情況下該值會影響其它協(xié)議使用的net.core.wmem_default 值,一般要低于net.core.wmem_default的值。默認(rèn)值為16384(16K)。

            max: 用于TCP socket發(fā)送緩沖的內(nèi)存最大值。該值不會影響net.core.wmem_max,"靜態(tài)"選擇參數(shù)SO_SNDBUF則不受該值影響。默認(rèn)值為131072(128K)。(對于服務(wù)器而言,增加這個參數(shù)的值對于發(fā)送數(shù)據(jù)很有幫助,在我的網(wǎng)絡(luò)環(huán)境中,修改為了51200 131072 204800)

            tcp_rmem (3個INTEGER變量): mindefaultmax
            min:為TCP socket預(yù)留用于接收緩沖的內(nèi)存數(shù)量,即使在內(nèi)存出現(xiàn)緊張情況下tcp socket都至少會有這么多數(shù)量的內(nèi)存用于接收緩沖,默認(rèn)值為8K。

            default:為TCP socket預(yù)留用于接收緩沖的內(nèi)存數(shù)量,默認(rèn)情況下該值影響其它協(xié)議使用的net.core.wmem_default 值。該值決定了在tcp_adv_win_scaletcp_app_wintcp_app_win=0默認(rèn)值情況下,TCP窗口大小為65535。默認(rèn)值為87380

            max:用于TCP socket接收緩沖的內(nèi)存最大值。該值不會影響 net.core.wmem_max,"靜態(tài)"選擇參數(shù) SO_SNDBUF則不受該值影響。默認(rèn)值為 128K。默認(rèn)值為87380*2 bytes。(可以看出,.max的設(shè)置最好是default的兩倍,對于NAT來說主要該增加它,我的網(wǎng)絡(luò)里為 51200 131072 204800)

            tcp_mem(3個INTEGER變量):lowpressurehigh
            low:當(dāng)TCP使用了低于該值的內(nèi)存頁面數(shù)時,TCP不會考慮釋放內(nèi)存。(理想情況下,這個值應(yīng)與指定給 tcp_wmem 的第 2 個值相匹配 - 這第 2 個值表明,最大頁面大小乘以最大并發(fā)請求數(shù)除以頁大小 (131072 * 300 / 4096)。 )

            pressure:當(dāng)TCP使用了超過該值的內(nèi)存頁面數(shù)量時,TCP試圖穩(wěn)定其內(nèi)存使用,進入pressure模式,當(dāng)內(nèi)存消耗低于low值時則退出pressure狀態(tài)。(理想情況下這個值應(yīng)該是 TCP 可以使用的總緩沖區(qū)大小的最大值 (204800 * 300 / 4096)。 )

            high:允許所有tcp sockets用于排隊緩沖數(shù)據(jù)報的頁面量。(如果超過這個值,TCP 連接將被拒絕,這就是為什么不要令其過于保守 (512000 * 300 / 4096) 的原因了。 在這種情況下,提供的價值很大,它能處理很多連接,是所預(yù)期的 2.5 倍;或者使現(xiàn)有連接能夠傳輸 2.5 倍的數(shù)據(jù)。 我的網(wǎng)絡(luò)里為192000 300000 732000)

            一般情況下這些值是在系統(tǒng)啟動時根據(jù)系統(tǒng)內(nèi)存數(shù)量計算得到的。

            tcp_app_win : INTEGER
            默認(rèn)值是31
            保留max(window/2^tcp_app_win, mss)數(shù)量的窗口由于應(yīng)用緩沖。當(dāng)為0時表示不需要緩沖。

            tcp_adv_win_scale : INTEGER
            默認(rèn)值為2
            計算緩沖開銷bytes/2^tcp_adv_win_scale(如果tcp_adv_win_scale > 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(如果tcp_adv_win_scale <= 0)。

             

            tcp_rfc1337 :BOOLEAN
            缺省值為0
            這個開關(guān)可以啟動對于在RFC1337中描述的"tcp 的time-wait暗殺危機"問題的修復(fù)。啟用后,內(nèi)核將丟棄那些發(fā)往time-wait狀態(tài)TCP套接字的RST 包.

             

            tcp_low_latency : BOOLEAN
            缺省值為0
            允許 TCP/IP 棧適應(yīng)在高吞吐量情況下低延時的情況;這個選項一般情形是的禁用。(但在構(gòu)建Beowulf 集群的時候,打開它很有幫助)

             

            tcp_westwood :BOOLEAN
            缺省值為0
            啟用發(fā)送者端的擁塞控制算法,它可以維護對吞吐量的評估,并試圖對帶寬的整體利用情況進行優(yōu)化;對于 WAN 通信來說應(yīng)該啟用這個選項。

             

            tcp_bic :BOOLEAN
            缺省值為0
            為快速長距離網(wǎng)絡(luò)啟用 Binary Increase Congestion;這樣可以更好地利用以 GB 速度進行操作的鏈接;對于 WAN 通信應(yīng)該啟用這個選項。

             

             

             

            # 以下一段為抵抗syn flood攻擊,平時建議關(guān)閉

            sysctl -w net.ipv4.tcp_syncookies=1              # tcp syncookie,默認(rèn)關(guān)閉

            sysctl -w net.ipv4.tcp_max_syn_backlog=1280   # syn隊列,默認(rèn)1024,> 1280可能工作不穩(wěn)定,需要修改內(nèi)核源碼參數(shù)

            sysctl -w net.ipv4.tcp_synack_retries=2             # syn-ack握手狀態(tài)重試次數(shù),默認(rèn)5,遭受syn-flood攻擊時改為1或2

            sysctl -w net.ipv4.tcp_syn_retries=2                  # 外向syn握手重試次數(shù),默認(rèn)4

             

             

            # 以下一段為應(yīng)對tcp connect連接耗盡攻擊,如果開啟iptables connlimit模塊可禁用

            # 有嚴(yán)重連接性能影響和不穩(wěn)定因素,慎用

            sysctl -w tcp_tw_recycle=1                           # 默認(rèn)0,tw快速回收

            sysctl -w tcp_tw_reuse=1                             # 默認(rèn)0,tw重用

            sysctl -w tcp_keepalive_intvl=60                    # 默認(rèn)75,tcp keeplive探測輪詢時間

            sysctl -w tcp_keepalive_probes=3                  # 默認(rèn)9,tcp keeplive探測輪詢次數(shù)

            sysctl -w tcp_keepalive_time=1800                # 默認(rèn)7200,tcp keeplive時間

            sysctl -w tcp_fin_timeout=30                        # 默認(rèn)60,tcp fin狀態(tài)超時時間

            #sysctl -w net.ipv4.tcp_retries1=2                     #

            posted @ 2012-08-22 09:51 tqsheng 閱讀(706) | 評論 (0)編輯 收藏

            Culturelle嬰幼兒益生菌

            5,Culturelle嬰幼兒益生菌,30袋(Culturelle Probiotics for Kids!, Probiotic Packets)

            Culturelle是美國益生菌行業(yè)領(lǐng)先品牌,所采用的益生菌菌株Lactobacillus rhamnosus GG是目前研究最充分的益生菌菌株之一,適合調(diào)節(jié)免疫,改善過敏。益生菌通過改善營養(yǎng)吸收,抑制有害微生物,去除腸道里產(chǎn)毒性大腸桿菌產(chǎn)生的腸毒素,刺激免疫球蛋白IgA,刺激淋巴細(xì)胞等方式,提高兒童免疫力,改善腹瀉便秘以及濕疹。

            3個月內(nèi)每天三分之一包,3~6個月每天半包,6~12個月每天三分之二包,12個月以上每天一包。

            Vitacost購買地址 $19.79

            Drugstore購買地址 $19.87

            Diapers購買地址 $23.49

            posted @ 2012-08-13 12:36 tqsheng 閱讀(134) | 評論 (0)編輯 收藏

            Culturelle嬰幼兒益生菌

            5,Culturelle嬰幼兒益生菌,30袋(Culturelle Probiotics for Kids!, Probiotic Packets)

            Culturelle是美國益生菌行業(yè)領(lǐng)先品牌,所采用的益生菌菌株Lactobacillus rhamnosus GG是目前研究最充分的益生菌菌株之一,適合調(diào)節(jié)免疫,改善過敏。益生菌通過改善營養(yǎng)吸收,抑制有害微生物,去除腸道里產(chǎn)毒性大腸桿菌產(chǎn)生的腸毒素,刺激免疫球蛋白IgA,刺激淋巴細(xì)胞等方式,提高兒童免疫力,改善腹瀉便秘以及濕疹。

            3個月內(nèi)每天三分之一包,3~6個月每天半包,6~12個月每天三分之二包,12個月以上每天一包。

            Vitacost購買地址 $19.79

            Drugstore購買地址 $19.87

            Diapers購買地址 $23.49

            posted @ 2012-08-13 12:36 tqsheng 閱讀(135) | 評論 (0)編輯 收藏

            開發(fā)工具

            http://www.hkaco.com/developmenttools/default.asp
            http://www.conitec.net/english/software.php 

            posted @ 2012-08-06 12:57 tqsheng 閱讀(112) | 評論 (0)編輯 收藏

            svn教程

            http://wenku.baidu.com/view/3bd3d1f7f90f76c661371a0f.html 

            posted @ 2012-07-30 12:02 tqsheng 閱讀(180) | 評論 (0)編輯 收藏

            mybase

            http://xbeta.info/mybase.htm

            posted @ 2012-07-29 20:27 tqsheng 閱讀(215) | 評論 (0)編輯 收藏

            我的個人知識管理工具 [PKM]

                 摘要: 我的個人知識管理工具 [PKM]# 這篇文章原本發(fā)表在個人博客。考慮到同步控和 GTDer 也有需求,因此特轉(zhuǎn)刊于此。GTDStudy 的 Yibie 說我無意中完成了完整工具鏈的構(gòu)造。其實什么工具鏈不工具鏈的,就是平時一點點使用經(jīng)驗的積累,個人的懶惰助長了我尋求工具借力的需求而已。之前曾寫過一篇《我的時間管理(GTD)工具》。應(yīng)網(wǎng)友要求,再分享一下我的個人知識管理(Personal K...  閱讀全文

            posted @ 2012-07-29 16:35 tqsheng 閱讀(343) | 評論 (0)編輯 收藏

            wikidpad

            http://xbeta.info/wikidpad-2.htm 

            posted @ 2012-07-29 13:39 tqsheng 閱讀(107) | 評論 (0)編輯 收藏

            僅列出標(biāo)題
            共25頁: First 5 6 7 8 9 10 11 12 13 Last 
            三级三级久久三级久久 | 久久久久一本毛久久久| 国产激情久久久久影院老熟女| 久久亚洲精品中文字幕三区| 人人狠狠综合久久亚洲婷婷| 人妻无码精品久久亚瑟影视| 人妻丰满AV无码久久不卡| 天天综合久久久网| 亚洲午夜无码久久久久| 国产精品狼人久久久久影院 | 婷婷久久五月天| 国产精品免费福利久久| 中文字幕精品无码久久久久久3D日动漫| 亚洲AV伊人久久青青草原| 国产精品久久久久久久| 久久久久久国产精品美女| 99精品伊人久久久大香线蕉| 亚洲AV日韩精品久久久久久| 麻豆久久| 久久国产精品无码网站| 2020最新久久久视精品爱 | 久久精品国产AV一区二区三区 | 亚洲AV日韩精品久久久久| 久久中文精品无码中文字幕| 青青青伊人色综合久久| 91精品国产综合久久婷婷| 色综合久久无码五十路人妻| 久久久国产视频| 亚州日韩精品专区久久久| 久久婷婷色综合一区二区| 99热成人精品免费久久| 99久久亚洲综合精品网站| 久久精品国产亚洲麻豆| 久久国产精品成人免费| 久久精品成人国产午夜| 久久精品国产69国产精品亚洲 | 久久精品国产福利国产琪琪| 大香网伊人久久综合网2020| 91亚洲国产成人久久精品网址| Xx性欧美肥妇精品久久久久久| 色综合久久综精品|