細節決定成敗, 做技術的尤其如此，今天我們繼續分享乙個和負載均衡相關的排障案例:
之前系列:
細節決定成敗2: 鏈路負載均衡遇到ips
細節決定成敗1: 負載均衡和應用層面的結合
七層伺服器負載均衡時，http header的大小限制
客戶報障，使用a10裝置配置了七層應用交換，在經過負載均衡後訪問同一臺內部伺服器的不同頁面，乙個可以正常開啟，另外乙個無響應。
在明確的確是相同客戶端通過負載均衡裝置訪問相同的後台伺服器出現的問題後；很顯然這個問題和網路互通基本上無關，通常這種問題是比較難處理的。這種情況下無非回歸到根本，從客戶端，負載均衡和伺服器三處同時抓包進行詳盡的分析：
訪問該頁面時，客戶端傳送請求；負載均衡**應答後，客戶端傳送http請求，但未接收到任何後續的響應報文
伺服器：可以接收到客戶端的請求並正確返回響應報文
負載均衡：接收到伺服器的請求並正確**給伺服器；成功接收來自伺服器的報文但未**給前段客戶端：
看過我們之前有關pmtu文章的讀者，可能會馬上考慮到這個是不是pmtu的問題，經過報文的詳細分析排除；在進一步排查時發現，伺服器的詳細響應報文是這樣的(通過wireshark分析伺服器響應報文, follow tcp產生）
經過確認，是由於伺服器響應報文中http header中的乙個set cookie長度過長；超過了常用的16k位元組；而負載均衡裝置通常為能快速處理7層報文，對整個伺服器響應中http header的內容會放入系統buffer中處理； 在http header的長度超過該buffer大小時會丟棄，造成上面提到的訪問故障。
需要提到的是，iis系統等web中介軟體對使用者的http請求，和伺服器的http響應都有大小的限制，不同的版本設定值不同；在** 叔同的"大型互聯**效能優化
在此再次提醒諸位：四層和七層的應用對負載均衡/應用交付來講是完全不同的機制；七層由於應用上的種種細節，就有可能存在類似這篇文章提到的細枝末節的問題；何時採用四層部署，何時又應該使用七層功能，請大家務必根據應用需求仔細定奪。
(j.l.)
細節決定成敗
剛剛結束asp的期末考，深刻體會那句細節決定成敗的至理名言。巨長的程式題寫的有種要崩潰的感覺，結果一交卷猛然發現，忘了寫單引號。其實這事情在人家來說是粗心，在對我來說，絕對是對細節的在意，導致低智商型錯誤的頻發。說道細節這事，班裡有三個女生，乙個太在意細節性，以至於一件很快能完成的東西，在其手裡作品...
細節決定成敗？
以下文字摘自donews資深作者 郭子威。1 拍 鐵達尼號 的時候，有八卦說，詹姆斯.卡梅隆要求在船上裝載來自歐洲的瓷器，然後在顛簸中全部摔碎，因為 歐洲貨才能還原現場氣氛 結果憑空多出來幾十萬美金的成本。最後 鐵達尼號 賣了18億刀票房。這則八卦，很容易聯想到 細節決定成敗 等偉大的格言。不過你想...
細節決定成敗
在程式設計師的世界裡，細節對於一位程式設計師來說是至關重要的，稍微乙個小的疏忽輕則會浪費大量的時間去定位 而對於一些應用在 重要領域的裝置上的軟體而言，這種重要性更加不言而喻了，醫療，軍事，這些方面的裝置的故障率是0容忍度的 對與很多剛入行甚至已經時行業大牛級別的人物來說，細節的關注 性都是必要的，...