這是個不好定位的問題，當服務器連接數高時會出現。
問題現象：一臺同事的電腦無法打開一個域名，有時偶爾能打開一次。
分析過程:
1.頁面錯誤是網絡無法連接的錯誤頁面，分析是tcp三次握手沒有完成。
2.抓包發現請求頭比正常的請求多了 TSval 0, TSecr 0，
3.上網找到了timestamps參數（tcp 的時間戳），找到網友的相關問題處理http://www.mscbsc.com/bbs/archiver/index.php?tid-304644.html&
針對帶有時間戳的tcp syn包不響應的問題，查閱了相關資料。在網上中查到（[url]http://www.spinics.net/lists/linux-net/msg17195.html[/url]）相關內容，和我們遇到的非常相似，後來查到rfc1323中有相關內容。測試了下，已經解決了問題。產生問題的原因是 部分win7系統中的註冊表中有Tcp1323Opts這個選項，會導致其在發包時加入時間戳，經過nat之後，如果前面相同的端口被使用過，且時間戳大於這個鏈接發出的syn中的時間戳，服務器上就會忽略掉這個syn，不返會syn-ack消息，表現爲用戶無法正常完成tcp3次握手，從而不能打開portal頁面。在業務閒時，如果用戶nat的端口沒有被使用過時，就可以正常打開；業務忙時，nat端口重複使用的頻率高，很難分到沒有被使用的端口，從而產生這種問題。
4.發現問題電腦的註冊表Tcp1323Opts值爲3，而正常電腦值爲1
解決方法：
1.修改客戶端的註冊表Tcp1323Opts設置爲0。
2. 在服務器上修改變量 Sysctl –w net.ipv4.tcp_timestamps=0
三、測試結果
1.redhat AS 5.3的timestamps=1，沒有問題，不知是否是連接數低的原因，爲了避免，也改爲了0
2.redhat RHEL 6.2 timestamps=1是，連接數2千多，發現的問題，改爲0後正常。
這個跟系統應該有一定的關係,抓包發現AS5 發請求包時有 TSval 0, TSecr 0，但ack包卻不包含這兩個，tcp連接建立正常。 RHEL6.2 發請求包時有 TSval 0, TSecr 0，大部分不回ack包，無法建立連接，偶爾能建立連接ack回包也帶TSval , TSecr 這個，這就是和AS5的區別！