Aurrealdeko proxy batek ez ditu TCP segmentuen mugak gordetzen
Bereizi TCP segmentazioa, socket irakurketak eta HTTP markatzea aurrealdeko proxy baten bi aldeetako trafikoa aztertzean.
Demagun HTTP erantzun bat Squid-etik igaro ondoren harrapatutako hainbat TCP segmentutan agertzen dela. Hori TCPren ohiko jokabidea izan daiteke, eta ez erantzuna gaizki zatitu zenaren froga.
Aurrealdeko proxy batek normalean bi konexio ditu:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originKonexio bakoitzak bere TCP egoera, sekuentzia-zenbakiak eta paketizazioa ditu. Proxyak konexio batetik datuak irakurri eta bestera idatz ditzake, jatorrizko segmentu-tamainak gorde gabe. Bufferrak, bidaltze-denbora, kongestioak eta bidearen tamaina-mugek beste taldekatze bat sor dezakete.
Bereiz mantentzea merezi duten hiru muga
| Muga | Zerk zehazten duen |
|---|---|
| TCP segmentua | Garraio- eta sare-bidea |
| Socket irakurketaren emaitza | Eskuragarri dauden fluxu-byteak eta deitzailearen buffera |
| HTTP mezua edo markoa | HTTP protokoloaren markatze-arauak |
Irakurketa batek goiburu baten zati bat, goiburu osoa gorputz-byteekin edo aplikazio-mailako muga bat baino gehiago zeharkatzen duten datuak eduki ditzake. TCPk ez du «HTTP erantzunaren amaiera» irakurketa arrakastatsu baten amaierari lotzen.
Beraz, HTTP/1.1 analizatzaileak goiburuak metatzen ditu eta gorputzaren markatze-arau egokiak aplikatzen ditu, besteak beste luzera, transferentzia-kodifikazioa edo onartutako konexio-ixtea. HTTP/2 markoa protokolo-egitura bat da, bera TCP segmentuak zeharka ditzakeena; ez da sare-pakete baten beste izen bat.
CONNECT tunel arrakastatsu batek tunelatutako byte-fluxua gordetzen du, baina TCP hanka bi erabiltzen jarraitzen du. Bere segmentu-mugak desberdinak izan daitezke proxyak tunelaren barruko byteak aldatu ez dituenean ere.
Kalteak ikertzean, alderatu berriz muntatutako aplikazio-datuak. Pakete-kontuak alderatzeak edo bi aldeetan pakete-luzera berdinak espero izateak TCPri ematen ez duen muga-bermea eskatzen dio.