• <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
            數據加載中……

            slickedit 宏設置

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

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

            cpu 親和力

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

              在系統引導的時候,系統決定該計算機中有幾個CPU可以被使用。在應用程序中,可以呼叫GetSystemInfo函數來取得CPU的數量。

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

              或許,你更希望能夠對分配給線程的CPU有一些限制,使用“hard affinity”機制。

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

             

            BOOL SetProcessAffinityMask(
               HANDLE hProcess,
               DWORD_PTR dwProcessAffinityMask);

             

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

              一個進程中的子進程可以繼承該進程的相關性,也可以使用作業內核對象對某些進程限制在要求的一組CPU上執行。

             

              可以調用GetProcessAffinityMask函數來取得一個進程相關性屏蔽信息。

             

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

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

             

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

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

            DWORD_PTR SetThreadAffinityMask(
               HANDLE hThread,
               DWORD_PTR dwThreadAffinityMask);

             

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

              比如,現在有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上往往是不當的。這樣會降低CPU的利用率。

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

            DWORD SetThreadIdealProcessor(
               HANDLE hThread,
               DWORD dwIdealProcessor);

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

             

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

            // 加載一個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

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

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

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

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

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

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

              9 * 1/72 = 1/8 inch

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

              例如,無論在哪個操作系統中,Firefox 瀏覽器默認的 DPI 都是 96,那么實際上 9pt = 9 * 1/72 * 96 = 12px。

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

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

              現在我們可以回答這樣一個問題,網頁上 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. 企業名稱(TRADE NAME):通常指自然人如個體工商戶或個人合伙經營的店名。
            2. 名聲
            3. 是指印刷用活字的大小,是從活字的字背到字腹的距離。

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

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

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

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

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

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

            ■ 號數、點數制對照表
            序號          字號            點數         尺寸(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軟件中字號的大小與印刷業中字號的大小是不一致的。如MS-WORD中的二號字是22磅,但在印刷業中應該是21磅。

              一般表述字體大小的計量單位有兩種,一種是漢字的字號,如初號、小初、一號、…七號、八號;另一種是用國際上通用的“磅”來表示,如4、4.5、10、12、…48、72等。 
              
              中文字號中,“數值”越大,字就越小,所以八號字是最小的;在用“磅”表示的字號時,數值越小,字符的尺寸越小,數值越大,字符的尺寸越大。1磅有多大呢?2.83磅等于1毫米,所以28號字大概就是一厘米高的字,約相當于中文字號中的一號字。
             
              我們常說的“宋體,9”,表示的單位其實是磅,也就是   9   磅的宋體。 
              
              關于像素和磅的關系,我們來換算一下。在小字體的時候,分辨率是   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 閱讀(431) | 評論 (0)編輯 收藏

            VC2005 編譯Win7以管理員權限啟動的可執行程序

             

            VC2005 編譯Win7以管理員權限啟動的可執行程序

                由于在Vista、Win7系統增加了UAC功能,導致很多程序啟動時需要用戶以手動點擊鼠標右鍵,選擇“以管理員權限啟動”來啟動應用程序。

                為了方便用戶,VC程序員可以自己在程序中添加以管理員權限啟動的功能,其實非常簡單,將以下代碼復制到記事本中,保存為.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 閱讀(403) | 評論 (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 閱讀(580) | 評論 (0)編輯 收藏

            從問題看本質: 研究TCP close_wait的內幕

             * @author: ahuaxuan

             * @date: 2010-4-30

             */

             

            最近遇到的一個關于socket.close的問題,在某個應用服務器出現的狀況(執行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

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

             

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

             

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

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

             

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

             

            假設我們有一個client, 一個server.

             

            當client主動發起一個socket.close()這個時候對應TCP來說,會發生什么事情呢?如下圖所示.

             

            ?

             

             

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

            接著server端需要發送一個FIN給client,然后server端的狀態變成了LAST_ACK,接著client返回一個ACK,然后server端的socket就被成功的關閉了.

             

            從這里可以看到,如果由客戶端主動關閉一鏈接,那么客戶端是不會出現CLOSE_WAIT狀態的.客戶端主動關閉鏈接,那么Server端將會出現CLOSE_WAIT的狀態.

            而我們的服務器上,是客戶端socket出現了CLOSE_WAIT,由此可見這個是由于server主動關閉了server上的socket.

             

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

            ?

             

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

             

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

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

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

             

            下面我們來做幾個實驗

            實驗一:

            環境:

            服務器端:win7+tomcat,tomcat的keep-alive的時間為默認的15s.

            客戶端:mac os

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

             

            實驗二

            服務器端:ubuntu9.10+tomcat,tomcat的keep-alive的時間為默認的15s.

            客戶端:mac os

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

             

            實驗三

            服務器端:mac os+tomcat,tomcat的keep-alive的時間為默認的15s.

            客戶端:mac os

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

             

             

             

            總結, 當服務器的內核不一樣上FIN_WAIT_2的超時時間和操作是不一樣的.

            經查:控制FIN_WAIT_2的參數為:

            /proc/sys/net/ipv4/tcp_fin_timeout

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

             

            實驗四

            服務器端:ubuntu9.10+tomcat,tomcat的keep-alive的時間為默認的15s.

            客戶端:mac os

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

             

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

             

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

             

            客戶端解決方案:

             

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

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

             

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

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

            sysctl -w net.ipv4.tcp_keepalive_probes=2

            sysctl -w net.ipv4.tcp_keepalive_intvl=2

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

             

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

             

            服務器端解決方案

             

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

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

            所以如果出現這種情況,建議將你的server分開部署,服務于browser的部署到單獨的JVM實例上,保持keep-alive為15s,而服務于架構中其他應用的功能部署到另外的JVM實例中,并且將keep-alive的時間設置的更

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

             

            5.如果我們的應用既服務于瀏覽器,又服務于其他的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之內如果沒有再次使用,那么tomcat會主動關閉該socket,而其他APP請求的socket在330s之內沒有使用,才關閉該socket,這樣做可以大大減少其他APP上出現CLOSE_WAIT的幾率.

             

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

             

            總結:

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

             

             

             

            下面是網上找到的一些資料:

             

             寫道



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


            /proc/sys/net/ipv4/tcp_max_orphans
            系 統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。如果超過這個數字,孤兒連接將即刻被復位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,更應該增加這個值(如果增加了內存之后)。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不可交換的內存。

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

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

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

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

            slickedit

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

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

            CLOSE_WAIT狀態的生成原因

            CLOSE_WAIT狀態的生成原因
            首先我們知道,如果我們的服務器程序APACHE處于CLOSE_WAIT狀態的話,說明套接字是被動關閉的!

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

                  Client --->  FIN  --->  Server 

                  Client <---  ACK  <---  Server 

             這時候Client端處于FIN_WAIT_2狀態;而Server 程序處于CLOSE_WAIT狀態。

                  Client <---  FIN  <---  Server 

            這時Server 發送FIN給Client,Server 就置為LAST_ACK狀態。

                   Client --->  ACK  --->  Server 

            Client回應了ACK,那么Server 的套接字才會真正置為CLOSED狀態。

            Server 程序處于CLOSE_WAIT狀態,而不是LAST_ACK狀態,說明還沒有發FIN給Client,那么可能是在關閉連接之前還有許多數據要發送或者其他事要做,導致沒有發這個FIN packet。

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

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

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

             

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

            /proc/sys/net/ipv4/icmp_timeexceed_rate
            這個在traceroute時導致著名的“Solaris middle star”。這個文件控制發送ICMP Time Exceeded消息的比率。
            /proc/sys/net/ipv4/igmp_max_memberships
            主機上最多有多少個igmp (多播)套接字進行監聽。
            /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
            每一遍碎片收集之間的最小時間間隔。當內存壓力比較大的時候,調整這個間隔很有效。以jiffies計。
            /proc/sys/net/ipv4/inet_peer_maxttl
            entries的最大生存期。在pool沒有內存壓力的情況下(比如,pool中entries的數量很少的時候),未使用的entries經過一段時間就會過期。以jiffies計。
            /proc/sys/net/ipv4/inet_peer_minttl
            entries的最小生存期。應該不小于匯聚端分片的生存期。當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
            這個文件里面寫著一個數字,表示主機是否通過RARP、BOOTP、DHCP或者其它機制取得其IP配置。否則就是0。
            /proc/sys/net/ipv4/ip_default_ttl
            數據包的生存期。設置為64是安全的。如果你的網絡規模巨大就提高這個值。不要因為好玩而這么做——那樣會產生有害的路由環路。實際上,在很多情況下你要考慮能否減小這個值。
            /proc/sys/net/ipv4/ip_dynaddr/proc/sys/net/ipv4/icmp_destunreach_rate

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

            /proc/sys/net/ipv4/tcp_keepalive_time
            當keepalive起用的時候,TCP發送keepalive消息的頻度。缺省是2小時。
            /proc/sys/net/ipv4/tcp_keepalive_intvl
            當探測沒有確認時,重新發送探測的頻度。缺省是75秒。
            /proc/sys/net/ipv4/tcp_keepalive_probes
            在認定連接失效之前,發送多少個TCP的keepalive探測包。缺省值是9。這個值乘以tcp_keepalive_intvl之后決定了,一個連接發送了keepalive之后可以有多少時間沒有回應。
            /proc/sys/net/ipv4/tcp_max_orphans
            系 統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。如果超過這個數字,孤兒連接將即刻被復位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,更應該增加這個值(如果增加了內存之后)。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不可交換的內存。
            /proc/sys/net/ipv4/tcp_orphan_retries
            本端試圖關閉TCP連接之前重試多少次。缺省值是7,相當于50秒~16分鐘(取決于RTO)。如果你的機器是一個重載的WEB服務器,你應該考慮減低這個值,因為這樣的套接字會消耗很多重要的資源。參見tcp_max_orphans。
            /proc/sys/net/ipv4/tcp_max_syn_backlog
            記 錄的那些尚未收到客戶端確認信息的連接請求的最大值。對于有128M內存的系統而言,缺省值是1024,小內存的系統則是128。如果服務器不堪重負,試 試提高這個值。注意!如果你設置這個值大于1024,最好同時調整include/net/tcp.h中的TCP_SYNQ_HSIZE,以保證 TCP_SYNQ_HSIZE*16 ≤tcp_max_syn_backlo,然后重新編譯內核。
            /proc/sys/net/ipv4/tcp_max_tw_buckets
            系 統同時保持timewait套接字的最大數量。如果超過這個數字,time-wait套接字將立刻被清除并打印警告信息。這個限制僅僅是為了防止簡單的 DoS攻擊,你絕對不能過分依靠它或者人為地減小這個值,如果網絡實際需要大于缺省值,更應該增加這個值(如果增加了內存之后)。
            /proc/sys/net/ipv4/tcp_retrans_collapse
            為兼容某些糟糕的打印機設置的“將錯就錯”選項。再次發送時,把數據包增大一些,來避免某些TCP協議棧的BUG。

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

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

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

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

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

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

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

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

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

            tcp_retries2 :INTEGER
            默認值為15
            在丟棄激活(已建立通訊狀況)的TCP連接之前﹐需要進行多少次重試。默認值為15,根據RTO的值來決定,相當于13-30分鐘(RFC1122規定,必須大于100秒).(這個值根據目前的網絡設置,可以適當地改小,我的網絡內修改為了5)

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

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

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

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

             

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

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

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

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

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

             

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            一般情況下這些值是在系統啟動時根據系統內存數量計算得到的。

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

            tcp_adv_win_scale : INTEGER
            默認值為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
            這個開關可以啟動對于在RFC1337中描述的"tcp 的time-wait暗殺危機"問題的修復。啟用后,內核將丟棄那些發往time-wait狀態TCP套接字的RST 包.

             

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

             

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

             

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

             

             

             

            # 以下一段為抵抗syn flood攻擊,平時建議關閉

            sysctl -w net.ipv4.tcp_syncookies=1              # tcp syncookie,默認關閉

            sysctl -w net.ipv4.tcp_max_syn_backlog=1280   # syn隊列,默認1024,> 1280可能工作不穩定,需要修改內核源碼參數

            sysctl -w net.ipv4.tcp_synack_retries=2             # syn-ack握手狀態重試次數,默認5,遭受syn-flood攻擊時改為1或2

            sysctl -w net.ipv4.tcp_syn_retries=2                  # 外向syn握手重試次數,默認4

             

             

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

            # 有嚴重連接性能影響和不穩定因素,慎用

            sysctl -w tcp_tw_recycle=1                           # 默認0,tw快速回收

            sysctl -w tcp_tw_reuse=1                             # 默認0,tw重用

            sysctl -w tcp_keepalive_intvl=60                    # 默認75,tcp keeplive探測輪詢時間

            sysctl -w tcp_keepalive_probes=3                  # 默認9,tcp keeplive探測輪詢次數

            sysctl -w tcp_keepalive_time=1800                # 默認7200,tcp keeplive時間

            sysctl -w tcp_fin_timeout=30                        # 默認60,tcp fin狀態超時時間

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

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

            Culturelle嬰幼兒益生菌

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

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

            3個月內每天三分之一包,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是美國益生菌行業領先品牌,所采用的益生菌菌株Lactobacillus rhamnosus GG是目前研究最充分的益生菌菌株之一,適合調節免疫,改善過敏。益生菌通過改善營養吸收,抑制有害微生物,去除腸道里產毒性大腸桿菌產生的腸毒素,刺激免疫球蛋白IgA,刺激淋巴細胞等方式,提高兒童免疫力,改善腹瀉便秘以及濕疹。

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

            Vitacost購買地址 $19.79

            Drugstore購買地址 $19.87

            Diapers購買地址 $23.49

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

            開發工具

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

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

            svn教程

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

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

            mybase

            http://xbeta.info/mybase.htm

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

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

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

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

            wikidpad

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

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

            僅列出標題
            共25頁: First 5 6 7 8 9 10 11 12 13 Last 
            久久婷婷国产综合精品| 久久国产精品视频| 伊人久久大香线蕉亚洲| 久久本道久久综合伊人| 伊人久久大香线蕉精品不卡| 亚洲国产精品久久久久网站 | 亚洲精品国精品久久99热| 久久综合视频网| 久久夜色精品国产噜噜亚洲a| 欧美一区二区三区久久综 | 偷偷做久久久久网站| 久久综合成人网| 色天使久久综合网天天| 久久九九免费高清视频| 久久99国产乱子伦精品免费| 狠狠狠色丁香婷婷综合久久五月 | 久久久精品人妻无码专区不卡 | 久久精品中文无码资源站| 久久精品国产色蜜蜜麻豆| 精品国产青草久久久久福利| 国产精品无码久久久久久| 最新久久免费视频| 精品久久人人爽天天玩人人妻 | 久久中文字幕人妻熟av女| 草草久久久无码国产专区| 久久久久久国产精品美女| 久久久久四虎国产精品| 久久夜色精品国产www| 色综合久久中文综合网| 久久久无码精品亚洲日韩按摩| 99999久久久久久亚洲| 久久国产精品免费一区| 国产精品免费久久| 日本精品久久久久中文字幕| 91久久精一区二区三区大全| 久久久久久国产精品免费无码| 精品久久久无码人妻中文字幕 | 久久精品这里热有精品| 91久久精一区二区三区大全| 国产精品久久久久影院色| 狠狠色丁香久久婷婷综|