MSS નિયમ રાઉટર પર કામ કરે છે, પણ Squid સુધી પહોંચતો નથી

એક એડમિનિસ્ટ્રેટર FORWARDમાં TCPMSS ક્લેમ્પિંગ ઉમેરે છે. સીધું રૂટ કરેલ ટ્રાફિક સુધરે છે, પણ સ્થાનિક Squid ઇન્સ્ટન્સ દ્વારા ડાઉનલોડ હજી અટકી જાય છે. પ્રોક્સીનું વેબસાઇટ કનેક્શન એ ફક્ત ક્લાયન્ટનું TCP કનેક્શન તે સાંકળમાંથી પસાર થવું નથી.

સામાન્ય સમાપ્ત કરતા ફોરવર્ડ પ્રોક્સીમાં ક્લાયન્ટ તરફનું કનેક્શન સ્થાનિક રીતે સમાપ્ત થાય છે. પ્રોક્સી મૂળ અથવા પેરેન્ટ તરફ બીજું TCP કનેક્શન બનાવે છે. Linux પર તે કનેક્શન માટે બનેલા પેકેટ સ્થાનિક આઉટપુટ માર્ગ અનુસરે છે.

તેથી ફક્ત FORWARD માટેનો નિયમ સંપૂર્ણ કાર્યરત હોઈ શકે અને છતાં જે હેન્ડશેક સુધારવાનો હતો તે ચૂકી જાય. હૂક પસંદ કરતા પહેલાં વાસ્તવિક કનેક્શન અને SYNની દિશા નકશામાં ઉતારો. કન્ટેનર કે અલગ નેમસ્પેસ વધુ એક રૂટેડ સેગમેન્ટ ઉમેરી શકે છે, તેથી યોગ્ય સ્થાન પ્રક્રિયા ક્યાં ચાલે છે તેના પર આધાર રાખે છે.

PMTU નંબર સીધો MSSમાં ન મૂકો

પાથ MTU એ IP પેકેટનું કદ છે. TCP MSS એ TCP પેલોડ વર્ણવે છે અને સંબંધિત હેડરો ધ્યાનમાં લેવા જોઈએ. તે જ પ્રમાણે, ping પેલોડની લંબાઈ સંપૂર્ણ IP પેકેટની લંબાઈ નથી. જાણીતું 28 બાઇટનું ઉમેરણ મૂળભૂત IPv4 ICMP echo ગોઠવણ સાથે જોડાયેલું છે, દરેક એડ્રેસ ફેમિલી કે એન્કેપ્સ્યુલેશન સાથે નહીં.

TCPMSS લક્ષ્ય સ્પષ્ટ મૂલ્યો અને PMTU ક્લેમ્પિંગનું દસ્તાવેજીકરણ કરે છે. ક્લેમ્પિંગ હજી પણ રૂટની MTU માહિતી પર આધાર રાખે છે; તે પાથ શોધ સ્વસ્થ છે તેનો પુરાવો નથી, કે જરૂરી ICMP સંદેશા મંજૂર કરવાનો વિકલ્પ નથી.

લક્ષણને સિદ્ધાંત સાથે પણ મેળવો. પૂર્ણ થયેલ હેન્ડશેક પછી મોટા ટ્રાન્સફરમાં અટકવું પેકેટ કદની તપાસને ન્યાયી ઠેરવી શકે. વારંવાર જવાબ વગરના SYN કે તાત્કાલિક resetને વિશાળ સમજૂતીની જરૂર છે; નાના પેકેટ નિષ્ફળ થવાથી વધુ પડતું મોટું ડેટા સેગમેન્ટ સાબિત થતું નથી.

કામ કરતું સીધું કનેક્શન અને નિષ્ફળ પ્રોક્સી કનેક્શન રેકોર્ડમાં અલગ રાખો. એક જ મશીન પરથી પણ તેઓ જુદા સ્રોત, રૂટ અને એન્કેપ્સ્યુલેશન વાપરી શકે છે.