Алдыңкы прокси TCP сегменттеринин чектерин сактабайт
Алдыңкы проксинин эки жагындагы трафикти текшерүүдө TCP сегменттөөнү, сокет окууларын жана HTTP каптоосун өзүнчө караңыз.
Squid аркылуу өткөндөн кийин HTTP жообу бир нече жазылып алынган TCP сегментинде көрүнөт дейли. Бул TCPнин кадимки жүрүм-туруму болушу мүмкүн, жооп туура эмес бөлүнгөн деген далил эмес.
Алдыңкы проксинин адатта эки байланышы болот:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originАр бир байланыштын өз TCP абалы, иреттик номурлары жана пакеттелиши бар. Прокси бир байланыштан маалымат окуп, экинчисине жаза алат, баштапкы сегмент өлчөмдөрүн сактабастан. Буферлөө, жөнөтүү убактысы, тыгын жана жолдун өлчөм чектери башка топтоону пайда кылышы мүмкүн.
Өзүнчө кармоого татыктуу үч чек
| Чек | Аны эмне аныктайт |
|---|---|
| TCP сегменти | Ташуу жана тармак жолу |
| Сокет окуусунун натыйжасы | Жеткиликтүү агым байттары жана чакыруучунун буфери |
| HTTP билдирүүсү же кадры | HTTP протоколунун каптоо эрежелери |
Бир окуу баш сөздүн бир бөлүгүн, толук баш сөздү дене байттары менен бирге же бирден ашык колдонмо деңгээлиндеги чекти кесип өткөн маалыматты камтышы мүмкүн. TCP «HTTP жообунун аягын» ийгиликтүү окуунун аягына байлабайт.
Ошондуктан HTTP/1.1 талдоочусу баш сөздөрдү чогултуп, колдонулуучу дене каптоо эрежелерин колдонот, алардын ичинде узундук, өткөрүү коддоосу же уруксат берилген байланышты жабуу бар. HTTP/2 кадры өзү TCP сегменттерин кесип өтө алган протоколдук түзүлүш; ал тармак пакетинин башка аталышы эмес.
Ийгиликтүү CONNECT туннели туннелденген байт агымын сактайт, бирок дагы эле эки TCP бутун колдонот. Прокси туннелдин ичиндеги байттарды өзгөртпөгөн учурда да анын сегмент чектери башкача болушу мүмкүн.
Бузулууну иликтегенде кайра куралган колдонмо маалыматтарын салыштырыңыз. Пакеттердин санын салыштыруу же эки жакта бирдей пакет узундугун күтүү TCPден ал бербеген чек кепилдигин суроо болуп саналат.