Learning IOS and JUNOS

看了這麼久的TCP Windows Size相關的文章，終於搞懂為何可以突破TCP Windows Size的最大值(2^16 = 0~65535 bytes)。之前我一直被TCP header長度的問題困擾，因為Windows Size欄位就只有16 bits，那麼要如何才能紀錄使用超過TCP Windows 65535 bytes長度的資料呢? 不過說也奇怪，明明是一個很簡單的理論，但是找來找去總是找不到一份很簡單的文章來說明為什麼? 透過一些相關文章的佐證，我就在這邊用比較淺顯易懂的文字來表達。 我們先來看看TCP Header的樣子： 我們可以看到在TCP header中共有20 bytes，其中包含了16 bits的Windows Size。因為原有的TCP Windows Size最大值無法超過65536 bytes，所以後來在IETF RFC 1323 中定義了TCP Windows scale option的功能，讓我們可以使用TCP options欄位(共32 bits)中的14 bits當成是延伸的Windows Size。因此我們現在的TCP Windows Size最大長度可以達到2^(16+14) = 1GB(1,073,741,824 bytes) 以下是摘錄自WiKi上的相關資料： TCP window scale option From Wikipedia, the free encyclopedia The TCP window scale option is an option to increase the TCP receive window size above its maximum value of 65,535 bytes. This TCP option, along with several others, is defined in IETF RFC 1323 which deals with Long-Fat Networks , or LFN. In fact, the throughput of a communication is limited by two windows: congestion window and receive window. The first one tries ...

With 5.0, we have SSL auto-discovery so that administrators can whitelist or blacklist peers very easily and the peers are automatically discovered upon the first SSL connection and appear in the self-signed peer gray list. You simply mark them as trusted. The connections are not optimized until after you move the peers to the trusted whitelist . Both the client-side and server-side Steelhead appliances must use RiOS 5.0 or later. • SSL Certificates and private keys copied to server-side Steelhead appliance (no certificate faking in branch offices) • Auto-discovery of SSL Steelhead peers with gray-list capability • Automatic optimization of SSL traffic • Support for certificate domain wildcards