• <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, 評(píng)論 - 101, 引用 - 0
            數(shù)據(jù)加載中……

            slickedit 宏設(shè)置

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

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

            cpu 親和力

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

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

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

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

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

             

            BOOL SetProcessAffinityMask(
               HANDLE hProcess,
               DWORD_PTR dwProcessAffinityMask);

             

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

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

             

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

             

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

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

             

              以上討論的是如何把一個(gè)進(jìn)程中的所有線程限制在一組CPU上。有的時(shí)候想要把進(jìn)程的一個(gè)具體線程限制在一組CPU上。

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

            DWORD_PTR SetThreadAffinityMask(
               HANDLE hThread,
               DWORD_PTR dwThreadAffinityMask);

             

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

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

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

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

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

            DWORD SetThreadIdealProcessor(
               HANDLE hThread,
               DWORD dwIdealProcessor);

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

             

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

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


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

            IMAGE_LOAD_CONFIG_DIRECTORY ilcd;
            GetImageConfigInformation(pLoadedImage, &ilcd);

            // 更改進(jìn)程親掾性

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

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

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

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

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

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

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

              9 * 1/72 = 1/8 inch

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

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

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

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

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

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


            CSS相對(duì)長(zhǎng)度單位(relative length unit)

              CSS相對(duì)長(zhǎng)度單位中的相對(duì)二字,表明了其長(zhǎng)度單位會(huì)隨著它的參考值的變化而變化,不是固定的。

              以下是CSS相對(duì)長(zhǎng)度單位列表:

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

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

            以下是CSS絕對(duì)長(zhǎng)度單位列表:

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


            字號(hào)

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

            我國的活字采用以點(diǎn)數(shù)制為輔、號(hào)數(shù)制為主的混合制來計(jì)量。

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

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

            [*]五號(hào)序列:初號(hào)、二號(hào)、五號(hào)、七號(hào)

            [*]小五號(hào)序列:小初號(hào)、小二號(hào)、小五號(hào)、八號(hào)

            [*]六號(hào)序列:三號(hào)、六號(hào)

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

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

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

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

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

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

             

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

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

                為了方便用戶,VC程序員可以自己在程序中添加以管理員權(quán)限啟動(dòng)的功能,其實(shí)非常簡(jiǎ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>  

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

            posted @ 2012-09-16 16:39 tqsheng 閱讀(407) | 評(píng)論 (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 閱讀(584) | 評(píng)論 (0)編輯 收藏

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

             * @author: ahuaxuan

             * @date: 2010-4-30

             */

             

            最近遇到的一個(gè)關(guān)于socket.close的問題,在某個(gè)應(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個(gè)CLOSE_WAIT的socket.而且這些socket長(zhǎng)時(shí)間得不到釋放.下面我們來看看為什么會(huì)出現(xiàn)這種大量socket的CLOSE_WAIT情況

             

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

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

             

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

             

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

             

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

             

            ?

             

             

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

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

             

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

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

             

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

            ?

             

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

             

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

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

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

             

            下面我們來做幾個(gè)實(shí)驗(yàn)

            實(shí)驗(yàn)一:

            環(huán)境:

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

            客戶端:mac os

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

             

            實(shí)驗(yàn)二

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

            客戶端:mac os

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

             

            實(shí)驗(yàn)三

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

            客戶端:mac os

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

             

             

             

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

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

            /proc/sys/net/ipv4/tcp_fin_timeout

            如 果套接字由本端要求關(guān)閉,這個(gè)參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時(shí)間。對(duì)端可以出錯(cuò)并永遠(yuǎn)不關(guān)閉連接,甚至意外當(dāng)機(jī)。缺省值是60秒。2.2 內(nèi)核的通常值是180秒,你可以按這個(gè)設(shè)置,但要記住的是,即使你的機(jī)器是一個(gè)輕載的WEB服務(wù)器,也有因?yàn)榇罅康乃捞捉幼侄鴥?nèi)存溢出的風(fēng)險(xiǎn),F(xiàn)IN- WAIT-2的危險(xiǎn)性比FIN-WAIT-1要小,因?yàn)樗疃嘀荒艹缘?.5K內(nèi)存,但是它們的生存期長(zhǎng)些。參見tcp_max_orphans。

             

            實(shí)驗(yàn)四

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

            客戶端:mac os

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

             

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

             

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

             

            客戶端解決方案:

             

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

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

             

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

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

            sysctl -w net.ipv4.tcp_keepalive_probes=2

            sysctl -w net.ipv4.tcp_keepalive_intvl=2

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

             

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

             

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

             

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

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

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

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

             

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

            那就是配置多個(gè)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" />

             

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

             

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

             

            總結(jié):

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

             

             

             

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

             

             寫道



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


            /proc/sys/net/ipv4/tcp_max_orphans
            系 統(tǒng)中最多有多少個(gè)TCP套接字不被關(guān)聯(lián)到任何一個(gè)用戶文件句柄上。如果超過這個(gè)數(shù)字,孤兒連接將即刻被復(fù)位并打印出警告信息。這個(gè)限制僅僅是為了防止簡(jiǎn)單的DoS攻擊,你絕對(duì)不能過分依靠它或者人為地減小這個(gè)值,更應(yīng)該增加這個(gè)值(如果增加了內(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. 讓我再次提醒你:每個(gè)孤兒套接字最多能夠吃掉你64K不可交換的內(nèi)存。

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

            /proc/sys/net/ipv4/tcp_max_syn_backlog
            記 錄的那些尚未收到客戶端確認(rèn)信息的連接請(qǐng)求的最大值。對(duì)于有128M內(nèi)存的系統(tǒng)而言,缺省值是1024,小內(nèi)存的系統(tǒng)則是128。如果服務(wù)器不堪重負(fù),試 試提高這個(gè)值。注意!如果你設(shè)置這個(gè)值大于1024,最好同時(shí)調(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)同時(shí)保持timewait套接字的最大數(shù)量。如果超過這個(gè)數(shù)字,time-wait套接字將立刻被清除并打印警告信息。這個(gè)限制僅僅是為了防止簡(jiǎn)單的 DoS攻擊,你絕對(duì)不能過分依靠它或者人為地減小這個(gè)值,如果網(wǎng)絡(luò)實(shí)際需要大于缺省值,更應(yīng)該增加這個(gè)值(如果增加了內(nèi)存之后)。

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

            slickedit

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

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

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

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

            因?yàn)槿绻荂LIENT端主動(dòng)斷掉當(dāng)前連接的話,那么雙方關(guān)閉這個(gè)TCP連接共需要四個(gè)packet:

                  Client --->  FIN  --->  Server 

                  Client <---  ACK  <---  Server 

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

                  Client <---  FIN  <---  Server 

            這時(shí)Server 發(fā)送FIN給Client,Server 就置為L(zhǎng)AST_ACK狀態(tài)。

                   Client --->  ACK  --->  Server 

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

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

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

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

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

             

            proc/sys/net/ipv4/下各項(xiàng)的意義

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

            如果你有一個(gè)動(dòng)態(tài)地址的自動(dòng)撥號(hào)接口,就得設(shè)置它。當(dāng)你的自動(dòng)撥號(hào)接口激活的時(shí)候,本地所有沒有收到答復(fù)的TCP套接字會(huì)重新綁定到正確的地址上。這可以解決引發(fā)撥號(hào)的套接字本身無法工作,重試一次卻可以的問題。
            /proc/sys/net/ipv4/ip_forward
            內(nèi)核是否轉(zhuǎn)發(fā)數(shù)據(jù)包。缺省禁止。
            /proc/sys/net/ipv4/ip_local_port_range
            用于向外連接的端口范圍。缺省情況下其實(shí)很小:1024到4999。
            /proc/sys/net/ipv4/ip_no_pmtu_disc
            如果你想禁止“沿途MTU發(fā)現(xiàn)”就設(shè)置它。“沿途MTU發(fā)現(xiàn)”是一種技術(shù),可以在傳輸路徑上檢測(cè)出最大可能的MTU值。參見Cookbook一章中關(guān)于“沿途MTU發(fā)現(xiàn)”的內(nèi)容。
            /proc/sys/net/ipv4/ipfrag_high_thresh
            用 于IP分片匯聚的最大內(nèi)存用量。分配了這么多字節(jié)的內(nèi)存后,一旦用盡,分片處理程序就會(huì)丟棄分片。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í),設(shè)置這個(gè)選項(xiàng)。如果你的機(jī)器沒有專線連接(甚至是動(dòng)態(tài)連接)時(shí)非常有用,即使你的連接斷開,你的服務(wù)也可以啟動(dòng)并綁定在一個(gè)指定的地址上。
            /proc/sys/net/ipv4/ipfrag_low_thresh
            用于IP分片匯聚的最小內(nèi)存用量。
            /proc/sys/net/ipv4/ipfrag_time
            IP分片在內(nèi)存中的保留時(shí)間(秒數(shù))。
            /proc/sys/net/ipv4/tcp_abort_on_overflow
            一個(gè)布爾類型的標(biāo)志,控制著當(dāng)有很多的連接請(qǐng)求時(shí)內(nèi)核的行為。啟用的話,如果服務(wù)超載,內(nèi)核將主動(dòng)地發(fā)送RST包。
            /proc/sys/net/ipv4/tcp_fin_timeout
            如 果套接字由本端要求關(guān)閉,這個(gè)參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時(shí)間。對(duì)端可以出錯(cuò)并永遠(yuǎn)不關(guān)閉連接,甚至意外當(dāng)機(jī)。缺省值是60秒。2.2 內(nèi)核的通常值是180秒,你可以按這個(gè)設(shè)置,但要記住的是,即使你的機(jī)器是一個(gè)輕載的WEB服務(wù)器,也有因?yàn)榇罅康乃捞捉幼侄鴥?nèi)存溢出的風(fēng)險(xiǎn),F(xiàn)IN- WAIT-2的危險(xiǎn)性比FIN-WAIT-1要小,因?yàn)樗疃嘀荒艹缘?.5K內(nèi)存,但是它們的生存期長(zhǎng)些。參見tcp_max_orphans。

            /proc/sys/net/ipv4/tcp_keepalive_time
            當(dāng)keepalive起用的時(shí)候,TCP發(fā)送keepalive消息的頻度。缺省是2小時(shí)。
            /proc/sys/net/ipv4/tcp_keepalive_intvl
            當(dāng)探測(cè)沒有確認(rèn)時(shí),重新發(fā)送探測(cè)的頻度。缺省是75秒。
            /proc/sys/net/ipv4/tcp_keepalive_probes
            在認(rèn)定連接失效之前,發(fā)送多少個(gè)TCP的keepalive探測(cè)包。缺省值是9。這個(gè)值乘以tcp_keepalive_intvl之后決定了,一個(gè)連接發(fā)送了keepalive之后可以有多少時(shí)間沒有回應(yīng)。
            /proc/sys/net/ipv4/tcp_max_orphans
            系 統(tǒng)中最多有多少個(gè)TCP套接字不被關(guān)聯(lián)到任何一個(gè)用戶文件句柄上。如果超過這個(gè)數(shù)字,孤兒連接將即刻被復(fù)位并打印出警告信息。這個(gè)限制僅僅是為了防止簡(jiǎn)單的DoS攻擊,你絕對(duì)不能過分依靠它或者人為地減小這個(gè)值,更應(yīng)該增加這個(gè)值(如果增加了內(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. 讓我再次提醒你:每個(gè)孤兒套接字最多能夠吃掉你64K不可交換的內(nèi)存。
            /proc/sys/net/ipv4/tcp_orphan_retries
            本端試圖關(guān)閉TCP連接之前重試多少次。缺省值是7,相當(dāng)于50秒~16分鐘(取決于RTO)。如果你的機(jī)器是一個(gè)重載的WEB服務(wù)器,你應(yīng)該考慮減低這個(gè)值,因?yàn)檫@樣的套接字會(huì)消耗很多重要的資源。參見tcp_max_orphans。
            /proc/sys/net/ipv4/tcp_max_syn_backlog
            記 錄的那些尚未收到客戶端確認(rèn)信息的連接請(qǐng)求的最大值。對(duì)于有128M內(nèi)存的系統(tǒng)而言,缺省值是1024,小內(nèi)存的系統(tǒng)則是128。如果服務(wù)器不堪重負(fù),試 試提高這個(gè)值。注意!如果你設(shè)置這個(gè)值大于1024,最好同時(shí)調(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)同時(shí)保持timewait套接字的最大數(shù)量。如果超過這個(gè)數(shù)字,time-wait套接字將立刻被清除并打印警告信息。這個(gè)限制僅僅是為了防止簡(jiǎn)單的 DoS攻擊,你絕對(duì)不能過分依靠它或者人為地減小這個(gè)值,如果網(wǎng)絡(luò)實(shí)際需要大于缺省值,更應(yīng)該增加這個(gè)值(如果增加了內(nèi)存之后)。
            /proc/sys/net/ipv4/tcp_retrans_collapse
            為兼容某些糟糕的打印機(jī)設(shè)置的“將錯(cuò)就錯(cuò)”選項(xiàng)。再次發(fā)送時(shí),把數(shù)據(jù)包增大一些,來避免某些TCP協(xié)議棧的BUG。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

             

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

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

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

            tcp_syncookies :BOOLEAN
            默認(rèn)值是0
            只有在內(nèi)核編譯時(shí)選擇了CONFIG_SYNCOOKIES時(shí)才會(huì)發(fā)生作用。當(dāng)出現(xiàn)syn等候隊(duì)列出現(xiàn)溢出時(shí)象對(duì)方發(fā)送syncookies。目的是為了防止syn flood攻擊。
            注意:該選項(xiàng)千萬不能用于那些沒有收到攻擊的高負(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擴(kuò)展,可能對(duì)某些服務(wù)導(dǎo)致嚴(yán)重的性能影響(如SMTP轉(zhuǎn)發(fā))。(注意,該實(shí)現(xiàn)與BSD上面使用的tcp proxy一樣,是違反了RFC中關(guān)于tcp連接的三次握手實(shí)現(xiàn)的,但是對(duì)于防御syn-flood的確很有用.)

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

             

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

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

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

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

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

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

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

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

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

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

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

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

            tcp_rmem (3個(gè)INTEGER變量): mindefaultmax
            min:為TCP socket預(yù)留用于接收緩沖的內(nèi)存數(shù)量,即使在內(nèi)存出現(xiàn)緊張情況下tcp socket都至少會(huì)有這么多數(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)存最大值。該值不會(huì)影響 net.core.wmem_max,"靜態(tài)"選擇參數(shù) SO_SNDBUF則不受該值影響。默認(rèn)值為 128K。默認(rèn)值為87380*2 bytes。(可以看出,.max的設(shè)置最好是default的兩倍,對(duì)于NAT來說主要該增加它,我的網(wǎng)絡(luò)里為 51200 131072 204800)

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

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

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

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

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

            tcp_adv_win_scale : INTEGER
            默認(rèn)值為2
            計(jì)算緩沖開銷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
            這個(gè)開關(guān)可以啟動(dòng)對(duì)于在RFC1337中描述的"tcp 的time-wait暗殺危機(jī)"問題的修復(fù)。啟用后,內(nèi)核將丟棄那些發(fā)往time-wait狀態(tài)TCP套接字的RST 包.

             

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

             

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

             

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

             

             

             

            # 以下一段為抵抗syn flood攻擊,平時(shí)建議關(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隊(duì)列,默認(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攻擊時(shí)改為1或2

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

             

             

            # 以下一段為應(yīng)對(duì)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探測(cè)輪詢時(shí)間

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

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

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

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

            posted @ 2012-08-22 09:51 tqsheng 閱讀(706) | 評(píng)論 (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個(gè)月內(nèi)每天三分之一包,3~6個(gè)月每天半包,6~12個(gè)月每天三分之二包,12個(gè)月以上每天一包。

            Vitacost購買地址 $19.79

            Drugstore購買地址 $19.87

            Diapers購買地址 $23.49

            posted @ 2012-08-13 12:36 tqsheng 閱讀(139) | 評(píng)論 (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個(gè)月內(nèi)每天三分之一包,3~6個(gè)月每天半包,6~12個(gè)月每天三分之二包,12個(gè)月以上每天一包。

            Vitacost購買地址 $19.79

            Drugstore購買地址 $19.87

            Diapers購買地址 $23.49

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

            開發(fā)工具

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

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

            svn教程

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

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

            mybase

            http://xbeta.info/mybase.htm

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

            我的個(gè)人知識(shí)管理工具 [PKM]

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

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

            wikidpad

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

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

            僅列出標(biāo)題
            共25頁: First 5 6 7 8 9 10 11 12 13 Last 
            色综合久久久久网| 香蕉久久久久久狠狠色| 91精品无码久久久久久五月天| 国产激情久久久久影院小草| 无码人妻久久一区二区三区蜜桃 | 2021精品国产综合久久| 免费精品国产日韩热久久| 亚洲乱码中文字幕久久孕妇黑人| 国产农村妇女毛片精品久久| 色婷婷久久久SWAG精品| 久久996热精品xxxx| 色综合久久天天综合| 久久精品国产亚洲AV蜜臀色欲| 九九久久精品无码专区| 欧美丰满熟妇BBB久久久| 色偷偷偷久久伊人大杳蕉| 久久久99精品成人片中文字幕| 久久美女网站免费| 久久精品国产AV一区二区三区| 亚洲综合精品香蕉久久网97| 久久只有这精品99| 久久丝袜精品中文字幕| 亚洲午夜精品久久久久久浪潮| 色婷婷噜噜久久国产精品12p| 久久91精品国产91久久小草| 久久国产乱子精品免费女| 亚洲午夜久久久影院伊人| 久久精品国产亚洲AV电影| …久久精品99久久香蕉国产| 狼狼综合久久久久综合网| 久久这里都是精品| 亚洲一区精品伊人久久伊人 | 久久久久国产精品嫩草影院| 久久免费国产精品一区二区| 97久久超碰成人精品网站| 国产亚洲综合久久系列| 久久99精品久久久久久水蜜桃| 精品久久人妻av中文字幕| 国产精品99久久免费观看| 久久精品国产亚洲一区二区| 狠狠狠色丁香婷婷综合久久俺|